When migrating a mailbox to Exchange Online via a remote move request, you’ll occasionally encounter an issue where the mailbox has moved successfully but the on-premises mailbox object has not changed to a remote mailbox. If you’re using migration batches, you’ll see a status of “Completed with Errors” for the batch and “Completed with Warning” for the mailbox.
The migration logs will show something similar to the following:
7/16/2014 3:09:27 PM [BLUPR01MB326] Target mailbox 'tenant.onmicrosoft.com\6790e869-ce6b-4d2c-b267-0cab833b53af (Primary)' was successfully reset after the move.
7/16/2014 3:09:27 PM [BLUPR01MB326] Post-move cleanup failed. The operation will try again in 30 seconds (1/481).
.481 attempts later…
.
7/16/2014 7:54:33 PM [BLUPR01MB326] Target mailbox 'User, Test' was updated on domain controller 'CO1PR01A001DC06.NAMPR01A001.prod.outlook.com'.
7/16/2014 7:54:34 PM [BLUPR01MB326] Failed to convert the source mailbox 'tenant.onmicrosoft.com\6790e869-ce6b-4d2c-b267-0cab833b53af (Primary)' to mail-enabled user after the move. Attempt 479/481. Error: NotConnectedPermanentException.
7/16/2014 7:54:34 PM [BLUPR01MB326] Post-move cleanup failed. The operation will try again in 30 seconds (479/481).
7/16/2014 7:55:08 PM [BLUPR01MB326] Target mailbox 'User, Test' was updated on domain controller 'CO1PR01A001DC06.NAMPR01A001.prod.outlook.com'.
7/16/2014 7:55:09 PM [BLUPR01MB326] Failed to convert the source mailbox 'tenant.onmicrosoft.com\6790e869-ce6b-4d2c-b267-0cab833b53af (Primary)' to mail-enabled user after the move. Attempt 480/481. Error: NotConnectedPermanentException.
7/16/2014 7:55:09 PM [BLUPR01MB326] Post-move cleanup failed. The operation will try again in 30 seconds (480/481).
7/16/2014 7:55:44 PM [BLUPR01MB326] Target mailbox 'User, Test' was updated on domain controller 'CO1PR01A001DC06.NAMPR01A001.prod.outlook.com'.
7/16/2014 7:55:44 PM [BLUPR01MB326] Unable to update Active Directory information for the source mailbox at the end of the move. Error: NotConnectedPermanentException.
7/16/2014 7:55:45 PM [BLUPR01MB326] Waiting for mailbox changes to replicate.
7/16/2014 7:56:12 PM [BLUPR01MB326] Request is complete.
Yes, Exchange Online will actually try and convert the mailbox 481 times before giving up. At the conclusion of the 4-5 hours of retry attempts, you’ll often be left with a mailbox in the cloud and a mailbox on-premises.
In the situation where the cloud mailbox is accessible via OWA but the user’s Outlook profile has not cutover (as it’s still finding the on-premises mailbox), you’ll likely need to complete the conversion. Microsoft has posted the following KB article recommending the process for doing so: “A user can’t access a mailbox by using Outlook after a remote mailbox move from an on-premises Exchange Server environment to Office 365“.
Unfortunately, the recommended process of running “Disable-Mailbox” will result in the user losing their proxy addresses and X500 addresses which will certainly create some headaches.
Looking at the differences between a mailbox and a remote mailbox, I put together a script to make what should be the necessary changes. I would recommend evaluating the attributes yourself before using the script however I have run this in several environments without issue. Feel free to expand on the script to include logging of the changed values.
At a high level, the script clears the following attributes:
homeMTA
msExchHomeServerName
And sets the following:
msExchRecipientDisplayType
msExchRecipientTypeDetails
msExchRemoteRecipientType
targetAddress
The script for this post can be found in the Microsoft Script Center at the following link: Complete-Conversion.ps1
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Awesome!!! Can’t thank you enough. You saved Time!
I get a “The Try statement is missing its Catch or Finally block” error when running from the OnPrem server EMS. Exchange 2010 SP3 Ru8
Joseph-
Make sure you have the full script. You should see a “catch {}” there which your error seems to be referencing.
Thanks
Joe
Yea downloaded it from here, and I do see the Catch {} statement as well. Taking a look through ISE:
Looks like it’s missing a closing bracket somewhere
Will this grab ALL mailboxes in limbo, for example if I did a 100 mailbox migration from using O365 and not EMC. Right now they are all failing with Completed with Warning. When last week they were completing just fine.
Disabling and enabling remote mailbox one by one is impossible for the next 1200 users I have to do
Joseph-
Looks like the closing bracket was in fact missing from the try block. I’ve corrected the copy in the gallery, thanks.
The script should only be necessary in the case of a failures, the remote mailbox move process with hybrid should convert the objects automatically. I wouldn’t expect you to hundreds of errors, I’ve probably seen 50 across thousands and thousands of moves.
If you did have multiple to process, the script takes an individual user as a command line argument so you could just import a list and use a “foreach”.
But when you disable mailbox on-premise all attributes information will be lost again. When should i run this script before or after disabling mailbox ?
An issue that arises from the failure is that while the process makes it’s way towards 480 retries, the on-premises mailbox is still potentially accepting mail. There is an initial sync, but nothing after that point. 4 hours later, you likely have an out of sync mailbox that is then being disabled. Potentially a step needs to be included where the new mail is being PST’d out before disabling. Premier Support has told us that there is no process that they provide to manually sync the mailboxes if you need to use these steps for a manual cutover.
To track back on this, a Premier Support Engineer had actually seen a case like this solved. The fix is to Stop/Wait/Start the EWS AppPool. This spawns a new worker process. A reset does not work. It can be done while the batch is in this retry state. YMMV, but we have found that the AppPool degrades fairly quickly so that about 18 hours after the fix, migrations were back to failing on retries.
Something to add..
If msExchArchiveDatabaseLink is populated it will also need to be cleared.
If it still has the users old on premises archive path everything in 365 will work but on premises autodiscover will fail to redirect the request to the o365 autodiscover service.
It gives Error 603 “The user does not have an Exchange mailbox.”