Normally at this point we would be configuring the Exchange hybrid, but before we get into that I want to describe a couple of sync issues you may come across and some details on how to fix them.
This first issue is where multiple accounts are created in AAD. Before we get into the problem and how to fix it, I want to first discuss an attribute value called msDSConsistencyGUID. Previously, AAD Connect used the attribute ObjectSID as the sourceAnchor. The sourceAnchor uniquely identifies an object as being the same object in on-premises AD and in Azure AD. The attribute is also called immutableId and the two names can be used interchangeably. Newer versions of AAD Connect now use the msDSConsistencyGUID attribute as the sourceAnchor. The benefit of this change is that, unlike ObjectGuid, the msDSConsistencyGUID attribute is writable.
If you experience issues where multiple accounts for a single user were created in AAD. Generally, this is caused by a problem with the objects not being matched correctly across the two forests. If AAD Connect is configured to use the msDSConsistencyGUID as the sourceAnchor, run through the following steps to remediate the issue:
- Move the problem object to a non-synced OU in on-premises AD
- Hard delete the second AAD account from Office 365
- Update the msDSConsistencyGUID attribute so that the objects in both on-premises forests have the same value, and that value matches the immutableID value of the appropriate AAD account
- Move the object back to its original OU in on-premises AD and sync the account.
In a typical scenario the object in the account forest is the primary account for the user, so I would recommend performing the above steps on the object in the resource forest.
The second issue is a mailbox that already exists(ed) in Exchange Online for a user. This is especially prevalent on accounts that have been used to “kick the tyres” on Office 365 and have had an Exchange Online license assigned to them. If this is done prior to installing and configuring AAD Connect, an Exchange Online mailbox is automatically created for the user account. If you then decide to implement an Exchange hybrid, and thus AAD Connect, you will have a scenario where this account now has a mailbox in Exchange Online and a mailbox in Exchange on-premise. Not ideal! Hopefully, you will be in a position to simply delete the online mailbox as it has only been used for testing purposes. To do this, simply remove the Exchange Online license from the user, then permanently delete the mailbox (you can use something like Get-Mailbox -SoftDeletedMailbox | Remove-Mailbox -PermanentlyDelete with Exchange Online PowerShell to do this). Now, you may think all is good after doing this and you can continue on with your mailbox migration, but unfortunately that’s not the end of our remediation requirements. Because Exchange Online keeps pointers that indicate that there used to be a mailbox in the cloud for this user, re-assigning an Exchange Online license will always lead to Exchange Online trying to re-connect the mailbox in the cloud. This means the account can’t be licensed in preparation for the mailbox migration. To remove this pointer, you need to run the following cmdlet in Exchange Online PowerShell:
Set-User <UPN> -PermanentlyClearPreviousMailboxInfo
You will now be able to successfully assign the Exchange Online license to the user without Exchange Online attempting to re-connect a deleted mailbox.
On a side note, if you are having trouble deleting the mailbox, don’t forget that you must also remove any Litigation Hold or In-Place Hold configured on the mailbox and exclude the user from any retention policies that apply to the Exchange email location.
If you do need to retain the data in both mailboxes, you should export the Exchange Online mailbox data to PST using the Outlook client (unfortunately the New-MailboxExportRequest cmdlet does not work in Exchange Online), then import it into the on-premises mailbox after performing the above steps.
Once you’ve remediated these issues you can now run the hybrid configuration wizard and start migrating your mailboxes. Because there is no difference between running the hybrid configuration wizard in an Exchange resource forest scenario as from a normal, single forest Exchange implementation, I won’t discuss this here. The next blog will focus on what to do once all the mailboxes have been migrated.
