Save Time! Have All Your Meetings End Early

Posted on Leave a commentPosted in calendar, exchange online, Exchange Server, monthly channel, Office 365, Office 365 ProPlus, Outlook, semi-annual channel

I am sure you have been in a meeting, where the meeting end time rolls around and there is a knock at the door from the people who want the meeting room now, as their meeting time has started and yours has finished.

What if you could recover five, eight, ten or more minutes per meeting so that the next meeting party can get into the room on time, and you have time to get out and get to your next meeting, and be on time.

Well since the beginning of 2019, Microsoft have come to your rescue.


The above are the new calendar “End appointments and meetings early” option. It is available in Outlook for Windows that is part of Office 365 ProPlus and you need to have a version of the software released new in 2019 for the feature to be available – more on the version and what to do in the technical section below.

The above option is found from File > Options > Calendar and then looking under Calendar Options as shown.

Check the option ”End appointments and meetings early” and then choose the time that a meeting under 1 hour will end early, and you can choose 5, 8 or 10 minutes, and then a second option for meetings over 1 hour – these can end 5, 10 or 15 minutes early. You can also enter your own preferred end early time.

Click OK and go create a new meeting. It should not matter how you create the meeting.

As you can see from my options above, my default meeting is 30 minutes – so on creating a new meeting I see the following:


I’ve highlighted the new end time – its 25 minutes after the meeting starts! The adjustment applies to the default meeting length and shortens it for me.

If for this meeting I want it to be the full 30 minutes, I can just write in the new time – all Outlook is doing is setting a new adjustable default for me.

For meetings where you drag out a custom duration in your calendar – it works here as well:


As you can see I have dragged out 1pm to 4pm on Thursday. Look what happens when I enter some text for the meeting subject:


The meeting is created with an end time ten minutes early (my preferred time saving duration for meetings over one hour). As with the above, I can adjust the time of this meeting to the full hour if I want to very easily – just drag the meeting block to the full hour and it is kept. Its just the default time when I first create the meeting that is adjusted.

Note that existing meetings are not changed – but if you go into an existing meeting and look at the end time drop down, you will see suggestions for the duration that take the early end time into consideration:


So, that’s how you can save time on your meetings (or at least one way, being prepared for them is another and technology cannot help there – yet!)

Changing The Defaults For Everyone

But what if you are the HR department or the representative of the department for digital change – what if you want to try and improve company culture and change these defaults across the board – well this is a job for IT, but they can easily roll out a setting to all your computers that set a end early time for both short and longer meeting durations.

They need to deploy a group policy setting that changes the registry at HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\Calendar and updates both EndEarlyShort and EndEarlyLong values as well as the EndEventsEarly key. EndEarlyShort is of course the value that affects meetings under one hour – and you do not need to accept the Microsoft suggested durations of 5, 8 and 10 minutes. For example if I edit this DWORD registry key and set the value to 3, upon restarting Outlook my new meetings under one hour end three minutes early:


The EndEventsEarly value is the setting that turns the feature on. So as well as setting the end early times, you need to set this value to 1 as well.

If you want to roll out this change centrally and ensure that the end user cannot set their own custom end early time then you can change the registry key policy settings via HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Options\Calendar. Changes in this registry location mean the user cannot adjust the end early times.


You can disable this option centrally as well by setting EndEventsEarly DWORD value to 0 – this has the effect of disabling the check box and so users cannot turn the option on.

All these three settings are included in the latest update to the Office365 Administrative Templates, available on Microsoft Download Center: as well.

Checking Your Outlook Version

Version 1812 or later in use on the Monthly Channel is required before you can use this feature. In most businesses you are probably using the Semi-Annual channel, and this has features deferred by at least six months. So to check, click File > Office Account in any Office application (shown below). To the right hand side you will see the below. You need to check you are running the Subscription Product and that under About Outlook (or whatever Office app you are checking), it reads Version 1812 or later and Monthly Channel. The Semi-Annual Channel is released in January and July each year and is deferred by at least six months, so as this feature was released in Dec 2018, this feature will not appear in the Semi-Annual Channel until at least July 2019 – build 1812 of the Semi-Annual Channel (and possibly not until build 1907). More on this release cycle can be found at


Too Many Folders To Successfully Migrate To Exchange Online

Posted on 1 CommentPosted in activesync, android, email, exchange, exchange online, Exchange Server, iPad, iPhone

Exchange Online has a limit of 10,000 folders within a mailbox. If you try and migrate a mailbox with more than this number of folders then it will fail – and that would be expected. But what happens if you have a mailbox with less than this number and it still fails for this reason? This is the problem, with resolution, I outline below.

I was moving some mailboxes to Exchange Online when I came across the following error in the migration batch results:

Data migrated: 18.18 MB ‎(19,060,890 bytes)‎
Migration rate: 0 B ‎(0 bytes)‎
Error: MigrationMRSPermanentException: Error: Could not create folder 2288. –> MapiExceptionFolderHierarchyChildrenCountQuotaExceeded: Unable to create folder. ‎(hr=0x80004005, ec=1253)‎ Diagnostic context: Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=204] Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=468][latency=1] Lid: 52176 ClientVersion: 15.20.1730.17 Lid: 50032 ServerVersion: 15.20.1730.6019 Lid: 35180 Lid: 23226 — ROP Parse Start — Lid: 27962 ROP: ropCreateFolder [28] Lid: 17082 ROP Error: 0x4E5 Lid: 25953 Lid: 21921 StoreEc: 0x4E5 Lid: 27962 ROP: ropExtendedError [250] Lid: 1494 —- Remote Context Beg —- Lid: 38698 Lid: 29818 dwParam: 0x0 Msg: f28f1e21-62aa-4999-977f-ce310efea309-61f0997f-74d5-4421-9050-64f8272e5ac2[9]-28A06 Lid: 29920 dwParam: 0xB Lid: 29828 qdwParam: 0x2711 Lid: 29832 qdwParam: 0x2710 Lid: 45884 StoreEc: 0x4E5 Lid: 29876 StoreEc: 0x4E5 Lid: 30344 StoreEc: 0x4E5 Lid: 54080 StoreEc: 0x4E5 Lid: 56384 StoreEc: 0x4E5 Lid: 38201 StoreEc: 0x4E5 Lid: 35904 Lid: 45434 Guid: f12f3e45-67aa-89012-345f-ce678efea901 Lid: 10786 dwParam: 0x0 Msg: 15.20.1730.017:VI1PR0502MB2975:145a3769-3902-4e6b-9fe4-6db564e4eb92 Lid: 1750 —- Remote Context End —- Lid: 31418 — ROP Parse Done — Lid: 22417 Lid: 30609 StoreEc: 0x4E5 Lid: 29073 Lid: 20369 StoreEc: 0x4E5 Lid: 64464 Lid: 64624 StoreEc: 0x4E5

In the above I have highlighted some of the errors I was seeing – with the “could not create folder” message, the first indicator is that I have too many folders to migrate or I have a corrupt mailbox. Running Get-MoveRequestStatistics and including a full report (with -IncludeReport) shows in part the below. This was run to get more info on the move request. This was run from Exchange Online:

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​26/03/2019 17:10:09 [VI1PR0502MB3855] ‘MigrationService (on behalf of ‘’)’ created move request.
26/03/2019 17:10:15 [DB8PR05MB6025] The Microsoft Exchange Mailbox Replication service ‘’ (15.20.1730.17 ServerCaps:01FFFFFF, ProxyCaps:07FFFFC7FD6DFDBF5FFFFFCB07EFFF, MailboxCaps:, legacyCaps:01FFFFFF) is examining the request.
26/03/2019 17:10:15 [DB8PR05MB6025] Content from the Shard mailbox (Mailbox Guid: f12f3e45-67aa-89012-345f-ce678efea901, Database: cc980daf-4402-4645-b26c-2a83760b161c) will be merged into the target mailbox.
26/03/2019 17:10:15 [DB8PR05MB6025] Connected to target mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’, database ‘EURPR05DG090-db014’, Mailbox server ‘’ Version 15.20 (Build 1730.0).
26/03/2019 17:10:20 [DB8PR05MB6025] Connected to source mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’, database ‘DB’, Mailbox server ‘’ Version 15.0 (Build 847.0), proxy server ‘’ 15.0.847.40 ServerCaps:, ProxyCaps:, MailboxCaps:, legacyCaps:1FFFCB07FFFF.
26/03/2019 17:10:21 [DB8PR05MB6025] Request processing started.
26/03/2019 17:10:21 [DB8PR05MB6025] Source mailbox information:
Regular Items: 8443, 905.4 MB (949,422,345 bytes)
Regular Deleted Items: 1149, 189.9 MB (199,115,692 bytes)
FAI Items: 4651, 11.72 MB (12,285,701 bytes)
FAI Deleted Items: 9, 19.26 KB (19,721 bytes)
26/03/2019 17:10:21 [DB8PR05MB6025] Cleared sync state for request 2c065e32-3bd5-4524-9aac-03880fa8e961 due to ‘CleanupOrphanedMailbox’.
26/03/2019 17:10:21 [DB8PR05MB6025] Mailbox signature will not be preserved for mailbox ‘\f12f3e45-67aa-89012-345f-ce678efea901 (Primary)’. Outlook clients will need to restart to access the moved mailbox.
26/03/2019 17:11:20 [DB8PR05MB6025] Stage: CreatingFolderHierarchy. Percent complete: 10.
26/03/2019 17:12:38 [DB8PR05MB6025] Initializing folder hierarchy from mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’: 29048 folders total.
26/03/2019 17:21:21 [DB8PR05MB6025] Folder creation progress: 1102 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:31:22 [DB8PR05MB6025] Folder creation progress: 2730 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:41:22 [DB8PR05MB6025] Folder creation progress: 4535 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:51:23 [DB8PR05MB6025] Folder creation progress: 6257 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:01:23 [DB8PR05MB6025] Folder creation progress: 7919 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:11:23 [DB8PR05MB6025] Folder creation progress: 9570 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:14:15 [DB8PR05MB6025] Fatal error StoragePermanentException has occurred

The move request logs show an increasing folder count, and when this exceeds 10,000 a storage error occurs.

So the next thing to do is to check what I have on-premises. I have generally two options to try and fix a mailbox I am moving to Exchange Online. One is to move the mailbox elsewhere on-premises (on the basis that I discard errors on-premises and then move a cleaner mailbox to the cloud) or run repairs on the mailbox. Note that running repairs on-premises is part of the move to the cloud anyway as Exchange Server does this as part of the move.

But this revealed nothing! The move request logs on-premises showed the same – there was over 10,000 folders (indeed some of my mailboxes had over 20,000 folders) and this was enumerated in the move request logs. A New-MailboxRepairRequest did nothing either. But interestingly, Get-MailboxFolderStatistics | Measure showed only 200 folders! Each of my failing mailboxes had between 150 and 263 folders – nothing like the +10,000 that the move request was finding!

So I opened the mailbox in Outlook having granted myself permissions to it – again nothing.

So I opened MFCMapi and had a look at the folders. Now MFCMapi shows everything in the mailbox, and not just items under the “top of the information store” folder. I went about expanding each subfolder I could find and I came across a subfolder that everytime i expanded it, MFCMapi would hang. I would close and restart MFCMapi and the same thing!


I had found my suspect folder – its a iPhone device that had created the +10,000 folders. Now that I had a good candidate for my issue, the fix was easy. I listed the active-sync devices using Get-MobileDevice -Mailbox “Richard Redmond” | FL Identity and then removed the suspect device using Remove-ActiveSyncDevice “ Redmond/ExchangeActiveSyncDevices/iPhone§A9BCDE7FG57HIJ81KL1M08NOPQ” -Confirm:$false where the device identity was returned in the Get-MobileDevice cmdlet run just before.

This Remove-ActiveSyncDevice (or Remove-MobileDevice) cleans up this mailbox and deletes the partnership with the device.

Once this was done, I moved the mailbox again and it was ~200 folders and moved without further issue.

From the users perspective, if the phone is an active device and is syncing email, then removing the phone causes it to create a new partnership. If the server allows any device then this is seamless to the user. If the server requires authorization to add a new device, then the user will be told this and you need to approve it again. So if Allow/Block/Quarantine (ABQ) is not enabled on the server, one wonders if deleting all active sync partnerships before migrating any mailbox is an idea worth considering – there could be mailboxes I have moved that are <10,000 folders but not far from that number.

Exchange Move Requests | Large Items | And Setting TCP KeepAliveTime To A Large Value

Posted on Leave a commentPosted in exchange online, Exchange Server, mailbox, move, networking

I have seen this situation a number of times. A large mailbox (or mailbox and archive) wont move to the target because the process of checking what the changes are in the mailbox take too long, the network or Exchange Server times out the users move and then reports the mailbox is locked.

The fix for this is counter though to everything else you read online about this. Often you will see to reduce the TCP KeepAliveTime and reboot the server. This is the opposite – increase the value and do not reboot the server. Here is why:

First make sure no bad items in your failed moves – this is not a fix for bad items, this is a fix where things timeout:

Get-MoveRequest -MoveStatus failed | Get-MoveRequestStatistics | fl badite*

View the Move Request Statistics log for one of your failed mailbox moves:

Get-MoveRequestStatistics "&lt;name&gt;" -IncludeReport | fl | Out-File movereport.txt

Search the report that you have saved in the above cmdlet and search for “Error” in the text file. If you get the following then the mailbox is probably too large for a successful move, which means the source server or network has not got the resources. What can happen is the move is progressing and a check happens for changes to the source mailbox – this takes a long time to complete and something times out. When target Exchange tries to connect again, the source has lost the TCP port and so a new move is started, but the mailbox is still locked for the old move. Therefore the move cannot continue.

I have found that by increasing TCP KeepAliveTime (contrary to all the advise online) that this solves the issue. Now I need to be clear here – all I am doing is changing the registry key for this setting and restarting the MRS service on the source Exchange Server. I am NOT restarting Windows, and so I am not changing the KeepAliveTime for the entire network stack. I think MRS checks the registry key to see the KeepAliveTime and sets this to the lock time on the mailbox during the move. If I can lock the mailbox for longer, moves don’t timeout and fail is the theory behind why this happens

The error I get in the MailboxStatistics report (see above for cmdlet) reads:

Message                                : Error: Couldn’t switch the mailbox into Sync Source mode.
                                          This could be because of one of the following reasons:
                                            Another administrator is currently moving the mailbox.
                                            The mailbox is locked.
                                            The Microsoft Exchange Mailbox Replication service (MRS) doesn’t have the correct permissions.
                                            Network errors are preventing MRS from cleanly closing its session with the Mailbox server. If this is the case, MRS may continue to encounter this error for up to 2 hours – this duration is controlled by the TCP KeepAlive settings on the Mailbox server.
                                          Wait for the mailbox to be released before attempting to move this mailbox again. –> An error occurred while saving the changes on the folder “FolderID/”. Error details: Failed, Property: [0x66180003]
                                          InTransitStatus, PropertyErrorCode: AccessDenied, PropertyErrorDescription: .
                                          –> Property: [0x66180003] InTransitStatus, PropertyErrorCode: AccessDenied,
                                          PropertyErrorDescription: .

Of interest in the error is the point that says “MRS may continue to encounter this error for up to 2 hours ”. This time value matches the default TCP KeepAliveTime value. Raising this in the registry and restarting the MRS service (not the server) changes the lock timout, which means that when the long job that is happening on the target finishes (and takes longer than two hours), the source server is still waiting for the connection and does not throw the above error.

Once you have your mailboxes moved, delete the registry value (to put it back to the default of two hours) and avoid rebooting the server when this key is set to a different value. If you started with a different value return to that one instead of deleting the registry value.

The KeepAliveTime setting is found at \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, and its a DWORD value called KeepAliveTime. The value is in milliseconds, so 7200000 is two hours and 86400000 is 24 hours (which is the value I tend to use to resolve this issue). This change is made on the mailbox server and the service restarted on that server (or servers if you have more than one).

bin/ExSMIME.dll Copy Error During Exchange Patching

Posted on Leave a commentPosted in 2013, 2016, exchange, Exchange Server, update, upgrade

I have seen a lot of this, and there are some documents online but none that described what I was seeing. I was getting the following on an upgrade of Exchange 2013 CU10 to CU22 (yes, a big difference in versions):

     The following error was generated when “$error.Clear();
           $dllFile = join-path $RoleInstallPath “bin\ExSMIME.dll”;
           $regsvr = join-path (join-path $env:SystemRoot system32) regsvr32.exe;
          start-SetupProcess -Name:”$regsvr” -Args:”/s `”$dllFile`”” -Timeout:120000;
         ” was run: “Microsoft.Exchange.Configuration.Tasks.TaskException: Process execution failed with exit code 3.
    at Microsoft.Exchange.Management.Tasks.RunProcessBase.InternalProcessRecord()
   at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
    at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)”.

The Exchange Server setup operation didn’t complete. More details can be found
in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.

In this error the file ExSMIME.dll fails to copy. You can find the correct copy of this file in the CU source files at …\CU22\setup\serverroles\common. I copy the ExSMIME.dll file from here directly into the \Program Files\Microsoft\Exchange Server\v15\bin folder and then restart the upgrade.

I have found that the upgrade fails again here if it things there is a pending reboot due to other installations and I have also seen at this point the detection for the VC++ runtime fails. I have documented this elsewhere, and the workaround for the is found at

A reboot later and the installation is successful. The error somehow seems to think that the file is not where it is looking for it. In the ExchangeSetup.log file it records the issue as “Error 3”, which generally means “not found”!

CRM Router and Dynamics CRM V9 Online–No Emails Being Processed

Posted on Leave a commentPosted in crm, Dynamics, exchange, exchange online, Exchange Server, router

This one is an interesting one – and it was only resolved by a call to Microsoft Support, who do not document that this setting is required.

The scenario is that you upgrade your CRM Router to v9 (as this is required before you upgrade Dynamics to V9) and you enable TLS 1.2 on the router server as well (also documented as required as part of the upgrade).

Dynamics is updated and all your email that is processed using the Router stops. Everything was working before and now it is not!

The fix is simple though – and complex as well. The simple thing is that it is a a single check box you need to set. The complex thing is that as this is a GDPR setting, each user needs to do it themselves and it cannot be enabled in bulk!

The option each user needs to allow is “Allow other Microsoft Dynamics 365 users to send email on your behalf” and that this was checked. This option is located in CRM > Options > Email > Select whether other users can send email for you


Once each user does this, the router will start to process emails for this user again.

Exchange Server Dependency on Visual C++ Failing Detection

Posted on Leave a commentPosted in exchange, Exchange Server, install, vc++

Exchange Server for rollup updates and cumulative updates at the time of writing (Feb 2019) has a dependency on Visual C++ 2012. The link in the error message you get points you to the VC++ 2013 Redistributable though, and there is are later versions of this as well.

I found that by installing all versions VC++ 2011, 2012 and 2014 I was able to get past the following error – which I had on only one out of many servers.

Performing Microsoft Exchange Server Prerequisite Check

    Configuring Prerequisites                                 COMPLETED
     Prerequisite Analysis                                     FAILED
      Visual C++ 2012 Redistributable Package is a required component. Please ins
tall the required binaries and re-run the setup. Use URI
om/download/details.aspx?id=30679 to download the binaries.
      For more information, visit:

So regardless of what you see in the error and the download site you go to, you need another version.

I found this article lists all versions:

And I specifically installed the following versions which then put some DLL’s onto the server to get past the error:

image image image

451 4.7.0 Temporary server error. Please try again later. PRX2

Posted on 1 CommentPosted in DNS, error, Exchange Server

There are a few articles online about this error, but none were correct for the scenario i found a clients network in.

Not that I think the specifics matter, but this was Exchange Server 2016, Windows Domain Controllers running 2012 R2 and Exchange Hybrid. All the mailboxes had already moved to the cloud and the Exchange Server is used for attribute management and SMTP relay.

Sometimes, randomly it would seem, the applications fail to send email and get back the above error. So what does it mean! Lets dive into the Exchange logs to find out more.

In my example, TCP 25 is listening on a number of separate IPs on two different network cards on a server hosted in Azure (maybe all that matters for this case?)

Protocol Logs (Frontend)

In the Exchange Transport logs I turned on Protocol Logging for all connectors and sent some emails and had them rejected with the PRX2 error in the title. After 5 or so minutes the protocol logs contained the erroring session as shown below:

2019-01-31T13:45:09.477Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,0,,,+,,
2019-01-31T13:45:09.478Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,1,,,&amp;gt;,220 COMPANY Relay Connector SERVER,
2019-01-31T13:45:09.479Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,2,,,&amp;lt;,HELO,
2019-01-31T13:45:09.479Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,3,,,&amp;gt;,250 Hello [],
2019-01-31T13:45:09.480Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,4,,,&amp;lt;,MAIL FROM: &amp;lt;;gt;,
2019-01-31T13:45:09.480Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,5,,,*,08D68772EDC476C6;2019-01-31T13:45:09.477Z;1,receiving message
2019-01-31T13:45:09.480Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,6,,,&amp;gt;,250 2.1.0 Sender OK,
2019-01-31T13:45:09.482Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,7,,,&amp;lt;,RCPT TO: &amp;lt;;gt;,
2019-01-31T13:45:09.482Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,8,,,&amp;gt;,250 2.1.5 Recipient OK,
2019-01-31T13:45:09.483Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,9,,,&amp;lt;,RCPT TO: &amp;lt;;gt;,
2019-01-31T13:45:09.483Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,10,,,&amp;gt;,250 2.1.5 Recipient OK,
2019-01-31T13:45:09.484Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,11,,,&amp;lt;,DATA,
2019-01-31T13:45:09.484Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,12,,,&amp;gt;,354 Start mail input; end with &amp;lt;CRLF&amp;gt;.&amp;lt;CRLF&amp;gt;,
2019-01-31T13:45:09.498Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,13,,,*,,Proxy destination(s) obtained from OnProxyInboundMessage event. Correlation Id:80e0d560-be23-4910-bcb0-43139bee131f
2019-01-31T13:45:09.501Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,14,,,*,,Message or connection acked with status Retry and response 451 4.4.0 DNS query failed. The error was: DNS query failed with error InfoNoRecords -&amp;gt; DnsQueryFailed: InfoNoRecords
2019-01-31T13:45:09.501Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,15,,,&amp;gt;,451 4.7.0 Temporary server error. Please try again later. PRX2 ,
2019-01-31T13:45:09.503Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,16,,,&amp;lt;,QUIT,
2019-01-31T13:45:09.503Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,17,,,&amp;gt;,221 2.0.0 Service closing transmission channel,
2019-01-31T13:45:09.503Z,SERVER\From Internal Servers (Relay),08D68772EDC476C6,18,,,-,,Local

The protocol logs contain a number of columns to the left. The interesting ones for this are the connector name (“SERVER\From Internal Servers (Relay)”), the session ID (08D68772EDC476C6) and the sequence number (each item on the protocol has a incrementing sequence number, in the above it goes from 0 where the session connects (which is the + at the end) to 18, where it disconnects (the – at the end of the last line).

This log looks no different from a session that works (as it was random as I said above), but we see more about the error. Specifically we see the following:

Proxy destination(s) obtained from OnProxyInboundMessage event. Correlation Id:80e0d560-be23-4910-bcb0-43139bee131f
Message or connection acked with status Retry and response 451 4.4.0 DNS query failed. The error was: DNS query failed with error InfoNoRecords -&amp;gt; DnsQueryFailed: InfoNoRecords
451 4.7.0 Temporary server error. Please try again later. PRX2 ,

So we see that it is DNS. Online there are articles about this being to do with IPv6, AAAA records and invalid responses to those queries and fixes include using external DNS settings or smarthost values. None of this worked in this example.

So lets follow down the logs some more

Connectivity Logs

In the connectivity logs we search the same date/time/hour log for the session number, which in this case is 08D68772EDC476C6 from the above logs. In the connectivity logs we see a session that matches for this ID and its for “internalproxy”

2019-01-31T13:45:09.499Z,08D68772EDC476C7,SMTP,internalproxy,+,Undefined 00000000-0000-0000-0000-000000000000;QueueLength=&amp;lt;no priority counts&amp;gt;. Starting outbound connection for inbound session 08D68772EDC476C6
2019-01-31T13:45:09.501Z,08D68772EDC476C7,SMTP,internalproxy,&amp;gt;,DNS server returned InfoNoRecords reported by [Domain:Result] =;
2019-01-31T13:45:09.501Z,08D68772EDC476C7,SMTP,internalproxy,-,Messages: 0 Bytes: 0 (The DNS query for&amp;nbsp; 'Undefined':'internalproxy':'00000000-0000-0000-0000-000000000000' failed with error : InfoNoRecords)

Internalproxy is what Exchange users to send email from the frontend transport service to the hub transport service. But which hub transport service are we going to use? If does not matter if you have 1 or x number of Exchange Servers in your site, it will use DNS to look up the IP of one of these servers. So even if you have a single Exchange box, DNS is vital.

In the above log we see that DNS returns InfoNoRecords when queried for the Exchange Servers own name.

So I resort to nslookup to check DNS from this Exchange server. I have two DNS server, .20 and .21. The error appears to be related to .21 in this case.

To I enter “nslookup” which means look up the name of the server using the DNS server I got back a message saying cannot find Query refused.

When I tried the other DNS server I got back a successful response and the IP address of the server.

So for immediate fix, I removed as an option for DNS for this server. Exchange immediately went back to work and PRX2 errors where not displayed and email got to its destination.

Now to go and see who has broken DNS!

Public Folder Migrations and the Changing Cmdlets

Posted on 1 CommentPosted in exchange, exchange online, Exchange Server, migration, Public Folders

To complete a public folder migration from Exchange 2013/2016 to Exchange Online you need to run

Set-OrganizationConfig -PublicFolderMailboxesLockedForNewConnections $true

But if you look at lots of the documentation that is out there with their tips and tricks etc. you will see that lots of them say:

Set-OrganizationConfig –PublicFoldersLockedForMigration $true

So very near – but its the wrong cmdlet now and it does nothing. It does not lock out the public folders and in the cloud all you get is:

PS C:\Users\BrianReid> Complete-MigrationBatch PublicFolderMigration
The public folders in the source environment are not ready for finalizing the migration. Make sure that public folder
access is locked on the source Exchange server, and there are no active public folder mailbox moves or public folder
moves in the source.
     + FullyQualifiedErrorId : [Server=VI1PR09MB2909,RequestId=ca0ffb4a-cc9f-4195-94fd-e3dd060587e6,TimeStamp=13/12/2018 18:03:00] [FailureCategory=Cmdlet-MigrationBatchCannotBeCompletedException] 2FB8651C,Microsoft.Exchange.Management.Migration.MigrationService.Batch.CompleteMigrationBatch
     + PSComputerName        :

And there is nothing useful on the web for this error, so I wrote this to help you get out of this hole!

Run the correct cmdlet and migrations will start!

Test Connectivity Website and TLS 1.2

Posted on Leave a commentPosted in certificates, exchange online, Exchange Server, Kemp, SSL

An excellent resource for Microsoft Exchange Server and Exchange Online administrators and consultants is the Remote Test Connectivity website at or

Here I am going to document an error that indicated that the Exchange Server (in this case) was not working, but we could see that the phone was connecting fine to the server. The error we say was:

“The certificate couldn’t be validated because SSL negotiation wasn’t successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.”

and also

“The Microsoft Connectivity Analyzer wasn’t able to obtain the remote SSL certificate”

The error looked like the following:

exrca tls 10 support[96033]

This error occurs when TLS 1.0 is disabled either on the end server or on a load balancer in front of the server. In my case this as the case with the Kemp load balancer we were using – TLS 1.0 was disabled under SSL Properties. Once we restored TLS 1.0 the Remote Connectivity Test tool, the tool worked instantly:

TLS Kemp setting[96034]

Public Folder Sync–Duplicate Name Error

Posted on Leave a commentPosted in AADConnect, exchange, exchange online, Exchange Server, migration, Office 365, Public Folders

I came across this error with a client today and did not find it documented anywhere – so here it is!

When running the Public Folder sync script Sync-ModernMailPublicFolders.ps1 which is part of the process of preparing your Exchange Online environment for a public folder migration, you see the following error message:

UpdateMailEnabledPublicFolder : Active Directory operation failed on O365SERVERNAME.)365DATACENTER.PROD.OUTLOOK.COM. The
object ‘CN=PublicFolderName,,OU=Microsoft Exchange Hosted
Organizations,DC=)365DATACENTER,DC=PROD,DC=OUTLOOK,DC=COM’ already exists.
At C:\ExchangeScripts\pfToO365\Sync-ModernMailPublicFolders.ps1:746 char:9
+         UpdateMailEnabledPublicFolder $folderPair.Local $folderPair.Remote;
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
     + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,UpdateMailEnabledPublicFolder

This is caused because you have a user or other object in Active Directory that has the same name as the mail enabled public folder object.

In Exchange Online PowerShell if you run Get-User PublicFolderName you should not get anything back, as its a Public Folder and not a user, but where you see the above error you do get a response to Get-User (or maybe Get-Contact or any other object that is not a Public Folder. This class of object name (common name or cn) means the script can create the public folder in the cloud, but not update it on subsequent runs of the script.

The easiest fix is to rename the common name of the public folder object in Active Directory for all clashing public folders, unless you know you do not need the other object that clashes – as renaming that and letting AADConnect sync process the change is another way to resolve this.

To rename the mail public folder, in Exchange Server management shell run Set-MailPublicFolder PublicFolderName –Name NewPublicFolderName

I have changed my names to start with pf, so PublicFolderName becomes pfPublicFolderName and then the script runs without issue.

CannotEnterFinalizationTransientException On Exchange Move Request

Posted on Leave a commentPosted in error, exchange, exchange online, Exchange Server, migration, move

Did not find a lot on the internet on this particular error, so I guess it does not happen very often, but in my case it delayed to move of the mailbox in question by a week or so until I could resolve it.

When a mailbox is moving to a different Exchange organization (cross-forest or to/from Exchange Online) the move process copies the mailbox data to the target database and then right at the end of the move updates Active Directory in both the source and target forest. In the source it changes the object type from mailbox to mailuser (or remotemailbox if Exchange Online is in play, though this is really a special form of mailuser) and in the target, updates the mailuser to become a mailbox.

This particular error occurs at this stage. The Get-MoveRequest cmdlet reports Failed as the status, and Get-MoveRequestStatistics reports FailedOther as the status. If you get the move logs (Get-MoveRequestStatistics <name> -IncludeReport | FL | Out-File <filename.txt>) then in the logs you will see CannotEnterFinalizationTransientException as the error repeated many times until the move fails.

The fix for this issue is as follows:

1. Check that the Exchange System account has permission to the Active Directory object in question. In Active Directory Users and Computers choose View > Advanced to enable the Security tab and then view the security tab on the object in question. Edit > Advanced and then check or click “Enable Inheritance” option or button (depending upon version of AD tools). If inheritance is already set to enabled there is probably no harm in disabling inheritance, copying permissions and then enabling inheritance again.

2. Move the mailbox to a different database in the source Exchange Organization (New-MoveRequest <name>) and waiting for that to complete.

3. Removing and restarting the move in the target forest. If you do not remove and restart the move in the target you will see both MailboxIsNotInExpectedMDBPermanentException and SourceMailboxAlreadyBeingMovedTransientException. The first of these is because the mailbox is not where the target move expects it to be, and the second of these is becuase the source is currently being moved and so cannot be moved to the correct target forest at the same time.

This should resolve your ultimate move request – it did for me! 

Exchange Server Object ID Error With Windows Server 2016 Domain Controllers

Posted on 1 CommentPosted in 2010, 2013, 2016, active directory, ADDS, error, Exchange Server

Saw this error the other day:


When you open Exchange Control Panel and view the Mailbox Delegation tab of any user account you get the following:

The object <name> has been corrupted, and it’s in an inconsistent state. The following validation errors happened: The access control entry defines the ObjectType ‘9b026da6-0d3c-465c-8bee-5199d7165cba’ that can’t be resolved..

You do not see this error on any mailboxes that you have moved to Office 365 in hybrid mode, that is you do not see it on any RemoteMailbox objects.

The issue is because ObjectType ‘9b026da6-0d3c-465c-8bee-5199d7165cba’ is the GUID of the DS-Validated-Write-Computer Control Access Right introduced in WS2016 AD DS which is new to your Active Directory upon installing your first 2016 domain controller. Exchange Server reads this access control list when you open the Mailbox Delegation tab in Exchange Control Panel or when you run Get-ADPermission on the mailbox. This error is cosmetic, but to remove it you just need to reboot all your Exchange Servers in turn (relying on your database availability groups and load balancers to maintain service). Once you have rebooted each server, the error goes away when you are connected to that server for administrative functions. There is no impact on user connectivity whilst this error is in place, though it may impact you ability to assign permissions without error.

Therefore recommend that you reboot one server as soon as you can and then use that server as your target for administration until you can reboot the remaining servers.

Copy Links and Backlinks Between Users and Shared Mailboxes (automapping)

Posted on 1 CommentPosted in cross-forest, Exchange Server, mailbox, migration, msExchDelegateListBL, msExchDelegateListLink, shared mailbox

Automap for shared mailboxes does not work across forests when moving mailboxes.

When the user is granted permission to a shared mailbox, the default behaviour of automapping means that the shared mailbox has msExchDelegateListLink set to the DN of the user, and the backlink (hidden in AD by default) on the user is populated with the DN of the shared mailbox. Whenever the link attribute is updated, the backlink is automatically updated as well. For more on back links see

That is, is UserMailbox is granted full access to SharedMailbox you will see the following in Active Directory (Advanced View) > Attribute Editor > msExchDelegateListLink = “CN=UserMailbox,OU=etc” (on the SharedMailbox). And for the UserMailbox in Active Directory (Advanced View) > Attribute Editor > msExchDelegateListBL = “CN=SharedMailbox,OU=etc”.

When you migrate mailboxes across forests you make use of Prepare-MoveRequest.ps1 to copy all the attributes. The msExchDelegateListLink is not part of this attribute set and the msExchDelegateListBL is auto populated so we can ignore it for now – if msExchDelegateListLink was copied and updated to the new forest name, then msExchDelegateListBL would be filled in automatically.

So how do we copy the msExchDelegateListLink value for each user and then write it to the mail user object in the target forest before the mailbox is migrated (or if you have already done your migration and found this property missing and so automapping of shared mailboxes having failed (though the permissions have been copied fine), how can you grab the data from the old source forest and apply it to the mailboxes in the target?

Using PowerShell and the ActiveDirectory module is how.

First you need to export a list of all the automapped shared mailboxes each user has (this is the msExchDelegateListBL values for the user mailboxes you have migrated). There are two cmdlets to run here, the first does the entire source directory and the second filters the output to an OU and its child OU’s (so you can export a subset of data) using SearchBase. Only one of these two cmdlets is needed.

This code is PowerShell and needs to be run from any domain joined computer.

Import-Module ActiveDirectory
Get-ADUser -Properties msExchDelegateListBL,msExchDelegateListLink -LDAPFilter "(msExchDelegateListBL=*)" | Select name,DistinguishedName,@{Name='SharedMailbox';Expression={$_.msExchDelegateListBL -Join ";"}} | Export-csv automap-userlist.csv -NoTypeInformation -NoClobber -Encoding UTF8
Get-ADUser -Properties msExchDelegateListBL,msExchDelegateListLink -LDAPFilter "(msExchDelegateListBL=*)" -SearchBase 'OU=Sales,DC=domain,DC=local' | Select name,DistinguishedName,@{Name='SharedMailbox';Expression={$_.msExchDelegateListBL -Join ";"}} | Export-CSV automap-userlist.csv -NoTypeInformation -NoClobber -Encoding UTF8

These cmdlets return a CSV file listing each mailbox that has an automapping to a shared mailbox and what that shared mailbox is.

The CSV file then needs copying to the target AD forest, and as the target forest is very unlikely to contain the same OU structure and domain names, the DN of each object in the CSV file needs updating. This can be done with Find/Replace in Excel or Notepad quite easily.

For example, in a CSV I might see:


“First User”,”CN=First User,OU=Sales,DC=domain,DC=local”,”CN=SharedMailbox,CN=Users,DC=domain,DC=local CN=AnotherSharedMailbox,OU=Shared Mailboxes,OU=Exchange,DC=domain,DC=local”

“Second User”,”CN=Second User,CN=Users,DC=domain,DC=local”,”CN=Sales,OU=Shared Mailboxes,OU=Exchange,DC=domain,DC=local”

In this I have the DN of the mailbox and the DN of the shared mailbox in the source forest. Use Find and Replace to change all the source DN’s (or the OU/DC bits) to suit the location of the matching object in the target forest. For example, my above “second user” was as shown, but after updating the DN might be “CN=Second User,OU=Migrated,DC=target,DC=forest”. So in that case I find/replace “CN=Users,DC=domain,DC=local” for “OU=Migrated,DC=target,DC=forest”.

For my examples that follow on from here, I have saved the edited CSV file as automap-userlist-target-dn-updated.csv

Once I have the CSV file updated for the values in the target forest, I need to split each row where a user has more than one shared mailbox listed into multiple rows. This is simple with PowerShell:

Import-Csv -Path automap-userlist-target-dn-updated.csv |
% {$row = $_; $_.SharedMailbox.split(";")} |
% {$row.SharedMailbox=$_; $row} |
Export-Csv automap-userlist-target-dn-updated-split.csv -NoClobber -NoTypeInformation -Encoding UTF8

Now that I have a row in the CSV for each Shared Mailbox to User Mailbox mapping, I can set the msExchDelegateListLink value on each shared mailbox for the DN of the user that has access to it. This will update the msExchDelegateListBL on the user object automatically.

Import-Module ActiveDirectory
Import-CSV "automap-userlist-target-dn-updated-split.csv" | % {
Write-Host Add $_.DistinguishedName to $_.SharedMailbox
Get-ADUser -identity $_.SharedMailbox | Set-ADUser -Add @{msExchDelegateListlink=$_.DistinguishedName} 

In terms of errors in the above, if you get “get-aduser : Directory object not found” then the DN value for the Shared Mailbox is wrong, and if you see “set-aduser : The name reference is invalid” then the DN value for the user who has access to the shared mailbox is wrong (the DistinguishedName column in the CSV). The script can be run multiple times, so you are safe to fix the CSV file and import the entire list again. It will only add a given DN once in total per shared mailbox.

If your target (or source) forest has more than one domain, run the script from a server in the correct domain or use “-Server DC-name” in both the Get-ADUser and the Set-ADUser cmdlets.

Anonymous Emails Between On-Premises and Exchange Online

Posted on 1 CommentPosted in Authentication, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, hybrid, smtp, spam

When you set up Exchange Hybrid, it should configure your Exchange organizations (both on-premises and cloud) to support the fact that an email from a person in one of the organizations should appear as internal to a recipient in the other organization. In Outlook that means you will see “Display Name” at the top of the message and not “Display Name” <email address>. An email from the internet is rightly treated as anonymous and so should appear as “Display Name” <email address> but when it comes from your on-premises environment or your cloud tenant it should be authenticated.

In the email headers you should see a header called AuthAs that reads internal. The SCL (Spam Confidence Level) should always be –1 and you should not have a header called X-CrossPremisesHeadersFilteredBySendConnector visible on internal emails.

Your hybrid setup can be incorrectly configured and cause this, and depending upon what Exchange Server version you are running and when you last ran the hybrid wizard you can end up with different results.

Lets take a quick view to some of the settings you should see:

  1. Exchange Server 2010 (with or without Edge Server 2010)
    1. Hybrid wizard will use Remote Domains to control internal vs external and authentication state. You should have a Remote Domain for that shows TNEFEnabled, TrustedMailOutboundEnabled, TargetDeliverDomain, and IsInternal all set to True on-premises
    2. TrustedMailnboundEnabled attribute is set to True on Get-RemoteDomain in the cloud
    3. The AllowedOOFType, which controls Out Of Office is set to InternalLegacy
  2. Exchange Server 2013 and later
    1. Your “Outbound to Office 365” send connector on-premises should have CloudServicesMailEnabled set to True
    2. The Remote Domains matter for Out of Office and moderated emails/voting buttons, but not for authentication as mentioned in #1 above
    3. The Inbound Connector for “Inbound from GUID” should have CloudServicesMailEnabled set to True
  3. Exchange Server 2010 with Exchange Server 2013 or later Edge (no 2013 on-premises, only Edge)
    1. The setting CloudServicesMailEnabled needs to be True, but 2010 does not support this setting, so you need to edit the directory using ADSIEdit and change the msExchSmtpSendFlags on the send connector from 64 to 131136. All this does is tell the 2013 or later Edge to enable CloudServicesMailEnabled
    2. See for the steps to do this
  4. As #3 but with 2010 and 2013 on-premises – run the cmdlets and hybrid wizard from the 2013 server and not connected to the 2010 server!

Send-On-Behalf Permissions in Exchange Online

Posted on 2 CommentsPosted in exchange, exchange online, Exchange Server, hybrid, permissions, send-on-behalf

This document is up to date as of November 2018 and is therefore unlike many earlier documents on this issue as this feature set is in the process of changing.

First, Send-On-Behalf is changing so that it is supported across a hybrid Exchange Server to Exchange Online connection. At the time of writing this is in the process of being rolled out, so it might well be in your tenant by the time you read this.

But even if the config for this is enabled in the cloud, there is config that is needed on-premises. In Exchange Server 2013 you need to be on the latest CU and then run Set-OrganizationConfig  -ACLableSyncedObjectEnabled $True (as mentioned in For Exchange 2010, this is not an option (and the ACL sync needs to be done manually) and for Exchange 2016 it is documented that this cmdlet is already enabled. But this is not true; Exchange Server 2016 needs treating in the same way as Exchange Server 2013 regardless of what the Microsoft article says at the time of writing.

[Note: Update Nov 2018 – if you are using Exchange Server 2016 and you set the OrganizationConfig setting to true this does not make all mailboxes moved to the cloud after this date ACLable. I have recently discovered that about 1/10 to 1/3 of my mailboxes do not get converted to the correct recipient type property on migration. This means I need to treat Exchange Server 2016 like I treat Exchange Server 2010, I need to run the script to update the recipient type after each migration]

So what does -ACLableSyncedObjectEnabled $True do – well it changes Exchange Server so that all MoveRequests completed after the change leave behind a RemoteMailbox object where msExchRecipientDisplayType is -1073741818. For reference before the change to the OrganizationConfig this value on a RemoteMailbox was -2147483642.

msExchRecipientDisplayType Value




An ACLableSyncedMailboxUser is one that can have Send-On-Behalf permissions set or maintained across on-premise and the cloud – that is once your tenant is  updated as well.

This though leaves a few issues – the main one is that the RemoteMailbox left behind by the MoveRequest is only set to -1073741818 where the RemoteMailbox is made by a MoveRequest. If once you have moved all your users you start provisioning users directly in the cloud, then New-RemoteMailbox or Enable-RemoteMailbox will not set msExchRecipientDisplayType to -1073741818.

Therefore provisioning of users directly into the cloud with –RemoteMailbox will need the addition of Set-ADUser to update the msExchRecipientDisplayType after the RemoteMailbox is created. The cmdlet for this is the same cmdlet that you need to run if you are using Exchange 2010. This cmdlet is Get-AdUser <Identity> | Set-AdObject -Replace @{msExchRecipientDisplayType=-1073741818}

This  cmdlet would need to be added to your provisioning scripts, and if you don’t have scripts to provision users in AD and have a mailbox in the cloud, then now is the time to look at this as the number of moving parts is growing.

If you do not do the msExchRecipientDisplayType change then some of your remote mailboxes in Exchange Online will be able to be granted permissions for Send-On-Behalf and other permissions as they are added to the cloud, as they are ACLable (as in we can set them in Access Control Lists, ACLable!), and others users will not be. To make these changes you need to change the msExchRecipientDisplayType on-premises to -1073741818 and wait for this to sync to Azure AD and then wait for that to sync from Azure AD in the Forward Sync process to your Exchange Online directory.

420 4.2.0 RESOLVER.ADR.Ambiguous; ambiguous address

Posted on Leave a commentPosted in active directory, exchange, exchange online, Exchange Server, migration, smtp

This error can turn up in Exchange Server when Exchange Server is trying to resolve the object that it should deliver a message to. Exchange queries Active Directory and expect that if the object exists in the directory, that the object exists only once. If the object exists more than once, this is the error – as Exchange does not know who to deliver the email to.

The error is visible when running Get-Queue in Exchange Management Shell, and seeing that there are lots of emails in the Submission Queue. If you run Get-Message –Queue servername\Submission | FT Identity,FromAddress you can pick one to look at, and for that one run Get-Message server\submission\ID | FL where server\submission\ID is the Identity value from Get-Message cmdlet. Here you will see LastError and Recipients showing the ambiguous address error.

There are a number of articles on the internet covering this issue, but I came across a unique one today.

The easy way to search for the issue is to find the address that is in duplicate. This will be listed in Event Viewer under MSExchangeTransport as the source and Event ID 9217. The Task Category will be Categorizer, as the job of working out who is going to get the message is the role of the Categorizer.


An example of this error is shown.

So the fix. Often suggested is to do a custom AD query for “” where is the email address shown in the event log error. If this returns two or more recipients, and this will be across all the domains in the forest, then you need to decide which is the primary one and carefully delete the rest.

By carefully I mean that you want to leave either one contact, or one mail user or one mailbox etc. If the duplicate is two contacts, then find the one with the most correct information on it and carefully delete the other. If you find two mailboxes, work out which the user is actually logging into and has email in it – and carefully delete the other etc.

And by carefully, here I also mean that on the object you are going to delete, copy the legacyExchangeDN value and then delete the object. Then find the real correct object and add a new x500 email address to the proxyAddresses attribute of the correct user. The value of the x500 address will be the legacyExchangeDN that you copied from the deleted contact.

This will ensure that users who have previously emailed the now deleted contact before, will still be able to email the remaining object.

But what is unique about that? At the customer I am working on at the moment the issue was that doing the search only returned one object across the entire forest – what is duplicate about that? Well in my case, the user had added to their proxyaddresses twice – they were the duplicate object to themselves.


Opening this user via the search results as shown above, and with Advanced Features enabled from the View menu, you can see the Object tab:


Opening the object value directly, redacted in the picture above, I can change to the Attribute Editor tab and open proxyAddresses attribute. Here i saw the following: (used as a target for forwarding emails from another system)

x500:legacyExchangeDN from Exchange 2007 migration

Note that the value, the one in error in the logs, appears twice but not starting SMTP (primary address) or smtp (secondary address) but without an address protocol at all!

Querying the user in Exchange Administration Console returned:


And also then opening the user in Exchange Management Console showed that the address without the smtp: value was shown with it.

Remove one of the two addresses and within ten minutes the emails queued to this user in the submission queue will be delivered. Restarting the transport service will also kick start the submission queue as you cannot use Retry-Queue against this queue.