Over the past few months, I have been working on a consolidation project, where Company A (the Parent) acquired Company B (the Child). The consolidation activities included both an Active Directory migration between forests and moving the Child on-premises mailboxes homed on Exchange Server 2013 to the Parent’s Office 365 tenant. The focus of this article is on how we uniquely solutioned the mailbox migration effort.
The Parent had a deeply integrated identity management solution that would pre-provision all Child Active Directory user accounts in the Parent domain with Exchange mailboxes. With this limitation in mind, and knowing we would synchronize these Parent accounts to Office 365 using Azure AD Connect, we first considered migrating the Child mailboxes to Office 365 using a third party tool. Tools-based migrations, while very useful, can introduce some challenges to the end user:
- A new Outlook profile will need to be created
- Mobile devices will need to have their mail account removed and re-added
- Outlook Autocomplete Cache does not always migrate over
- Categories in Outlook do not migrate over
- And more…
It is always ideal to do an Exchange Hybrid migration when possible to account for the end user experience, so it was time to think outside the box. I had a colleague come to me with an interesting idea in what he called a Pseudo-Hybrid migration. The secret behind the Hybrid mailbox move process is to have an exact match of the msExchMailboxGUID attribute between the on-premises mailbox and its corresponding Mail-Enabled User object in Office 365. What if we could copy the msExchMailboxGUID attribute, along with other supporting mail attributes, from the Child AD account to the newly created Parent AD account that is then synchronized up to Office 365? Wouldn’t that allow us to perform a successful Hybrid mailbox move from the Child Exchange organization even though the required attributes for a Hybrid move were synchronized from the Parent AD? The answer happens to be Yes.
We proceeded to test through the process and were able to validate that it works as expected. For the Active Directory migration, Quest Migration Manager for Active Directory software was already in place and synchronizing Active Directory attributes between the matching Child and Parent accounts. The first modification we made to the process was to the Parent provisioning system. We altered the Parent provisioning system to not provision a mailbox for the newly created Parent account thus keeping the Exchange-specific attributes free from any values. We then worked with the Quest engineer and had him include the needed Exchange attributes in his Quest synchronization process. These include the following:
- mailNickname
- targetAddress
- proxyAddresses
- msExchMailboxGuid
- msExchArchiveGuid
Our Quest engineer also wrote a custom script that would translate the existing legacyExchangeDN attribute from the Child mailbox to an X500 value on the Parent AD user object to allow for proper reply-ability of messages once the mailbox had been migrated.
Azure AD Connect would now synchronize the Parent AD user objects into Office 365 with a valid msExchMailboxGUID. When we setup a Migration Endpoint within Exchange Online to the Child Exchange Server 2013 servers, we were able to successfully migrate a mailbox to Office 365.
One a mailbox has been migrated, we would set a few additional attributes on the Parent user object to make it look like a Remote Mailbox on the Parent Exchange system. These include the following:
For User Mailboxes
- msExchRemoteRecipientType = 4
- msExchRecipientTypeDetails = 2147483648
- msExchRecipientDisplayType = -2147483642
For Shared Mailboxes
- msExchRemoteRecipientType = 100
- msExchRecipientTypeDetails = 34359738368
- msExchRecipientDisplayType = – 2147483642
Knowing that the Child AD will soon be retired, this unique solution has allowed us to perform a full fidelity Hybrid migration from an on-premises Exchange system to Office 365 without having to configure Azure AD Connect in a ‘Multiple forests, single Azure AD tenant’ topology.
