One of the major drawbacks when using AADSync or Dirsync is that the remote mailboxes are not created when a local mailbox exists. This could prove difficult when migrating to Office 365 due to the mailboxes not existing simultaneously.
For instance we use third party migration tools that require the remote mailbox to exist. In a normal situation when assigning a office 365 exchange license to a user a mailbox is automatically created. When this user still has an on premises mailbox this will not happen due to the msExchMailboxGuid property that has been set in active directory. Removing this property also marks the mailbox for deletion in Exchange as it no longer is able to find the correct GUID for the user.
To resolve this we have 2 options, both require some work – It just depends on which you personally prefer
Option 1; Disable Dirsync or AADSync and create the mailboxes online.
The first option is quite simple and requires manual intervention, this option is best if the following statements are both true;
- you are not working in the Cloud environment yet and the users have never logged in.
- You are phasing out the local directory you are syncing from or are planning to remove Exchange locally on short notice.
If these are not true, I’d advise you to use option 2 which gives you more of a solution
First you remove licenses from all the users you have synced with Active Directory. Then disable Active Directory Sync. Your synchronized users will be converted into Cloud objects and you will be able to reassign licenses. When reassigning licenses an online mailbox will be created.
After 24 hours you can re-enable Active Directory Sync and the users Office 365 mailboxes will exist and ignore the msExchMailboxGuid
Option 2; Change the Dirsync or AADSync settings to prevent msExchMailboxGuid replication.
Another option is to prevent the synchronization of the msExchMailboxGuid – I often prefer this as I do not need to make any modifications to the already setup Cloud environment and it gives me more freedom when creating new users locally – I often incorporate auto provisioning script for mailboxes and other specialized items so I am still able to use these local scripts and not worry that the hosted mailbox will not be created.
As always, Please be careful when preforming these tasks. Do so at your own risk;
- Launch X:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe (where X: is the drive you installed the sync tool.)
- Click on “Management Agents”
- Right click on “Active Directory Connector” and click on “Configure Attribute Flow”
- Open the ObjectType:User property.
- Find the to msExchMailboxGuid.
- Click the Delete button to remove the mapping to the msExchMailboxGuid.
- Click Ok to save the changes
- Close the MIIClient.
We have now prevented new objects from syncing the msExchMailboxGuid property to the cloud – The problem that remains is that existing objects have already replicated this property to the Office 365 Azure Active Directory. To make sure that at the next import job we clear this property on the hosted side we will need to perform a few SQL tasks. First we use SQL Management studio to connect to the Servername\MSONLINE SQL instance. When connected we run the following query;
UPDATE mms_metaverse SET msExchMailboxGuid = NULL WHERE (msExchMailboxGuid IS NOT NULL)
When this query runs the status of the msExchangeMailboxGuid in the SQL database is set to NULL. Your local active directory object is not changed. Now you can force a full import using the miisclient or using the Dirsync powershell module.
After a successful sync we are able to reassign a license and the hosted mailbox will be created! That way the local and hosted mailbox coexist and you are able to replicate the data using third party tools.
Have fun migrating!