Cannot Migrate Mailboxes via third-party tools in synchronized environment

  • Article

I happened to run into the same issue twice in one week--once with a large customer, and once with one of our partners.

Here's a synopsis of the issue:

Mailboxes cannot be migrated via 3rd-party tools because msExchMailboxGuid attribute in cloud is populated due to DirSync/AADSync.

In my customer's scenario, they were using ILM 2007 and populating the msExchHomeServerName attribute for a user object with an invalid value--which caused the on-prem Exchange environment to generate a value for msExchMailboxGuid.  This caused the objects to be seen as on-premises mailboxes (even though they weren't really mailboxes), which, in turn, caused AADSync to tell Office 365 that they were on-premises mailboxes.  In a synchronized environment, on-premises Exchange mailboxes can only be migrated via Mailbox Replication Service (MRS) or a staged migration.

In the partner scenario, they had an existing on-premises Exchange 2010 environment and were trying to migrate to Office 365.  Normally, this would be accomplished via a hybrid mailbox move, but the on-premises Exchange environment had a non-functional Exchange Control Panel and couldn't complete the Hybrid Configuration Wizard successfully.  You can work around the msExcmailboxGuid issue by disabling directory synchronization, removing all of the cloud IDs and manually creating them (or configuring sync to block the msExchMailboxGuid attribute flow), but there was a significant amount of SharePoint and OneDrive for Business data there, and it wasn't feasible to back it up and recreate.

In both scenarios, the solution is very similar--we have to make Office 365 think that there is no on-premises mailbox for the synchronized object.

Here's how I solved the problem in both scenarios.

Customer

Since the objects being flagged as mailboxes were not actually mailboxes, I had a lot more freedom to modify the accounts.  After clearing the Exchange Online license for the user objects in the Office 365 portal, I wrote a PowerShell script to clear the on-premises msExchMailboxGuid object and quickly forced a synchronization to Office 365:

Get-ADUser -Filter * -SearchBase "OU=SecondLevelOU,OU=TopLevelOU,DC=domain,DC=tld" | Set-ADObject -clear msExchMailboxGuid

Once synchronized, I was able to re-assign an Exchange Online license and a mailbox was created.

Partner

This one was much trickier.  My partner organization had an existing on-premises Exchange 2010 environment, so the solution I used for my customer wouldn't work (since it would disconnect the mailbox).  But, where there's a will, there's a way.  And where there's a virtualization environment on-hand, the way is even quicker.

WARNING

The goal of this procedure is to replicate a blank msExchMailboxGuid attribute to Office 365 for purposes of migration.  Do *NOT* perform this procedure in the production environment, as it will result in disconnected mailboxes.

  1. Promote a new domain controller (name it something like NewOfflineDC) into the production environment.  Promote it to global catalog, and then restart.
    1. This is necessary to obtain a copy of the current state of the objects.
  2. Disconnect NewOfflineDC from the production environment.
    1. We will make changes on this DC that *must not* be replicated back into the production environment.
  3. Uninstall existing DirSync/AADSync instance in production environment.
  4. Configure NewOfflineDC in a standalone network/VLAN that has ONLY internet access and *cannot* communicate with the production environment.
  5. Launch DSSITE.MSC in Production environment and force delete NewOfflineDC.
    1. Verify that all inbound connection objects are also removed.
  6. Launch DSSITE.MSC on NewOfflineDC and remove connection objects to all DCs.
  7. Unlicense EXO service plan in Office 365 for initial test mailbox.
  8. Install DirSync on NewOfflineDC and configure to synchronize with Office 365.
  9. Launch AD PowerShell on NewOfflineDC and run:
    1. Get-ADUser <samaccountname of test object> | Set-ADObject -Clear msExchMailboxGuid
  10. Force DirSync.
  11. Launch Azure AD PowerShell and run:
    1. Get-Recipient <test account> | FL *guid*
    2. Verify that ExchangeGuid value is blank or all zeroes.
  12. License EXO service plan in Office 365 for initial test mailbox.
  13. Verify new mailbox creation.
  14. Repeat procedure for additional mailboxes, and then migrate using third-party tools as necessary.
  15. Destroy NewOfflineDC.
  16. Convert on-premises Exchange mailboxes to Mail Enabled Users (to preserve proxy Addresses)
  17. Reinstall and reconfigure AADSync / DirSync in production environment.