Considerations When Merging Active Directory Forests While Office 365 is Being Used

A pre-existing Office 365 environment AND a need to migrate from one Active Directory to another.

Here we present an all-too brief primer on how to move Active Directory accounts to a new forest while Office 365 is deployed without also having to carry out extensive work on the backend.

This post focuses solely on the issue of moving an account to another forest, and how it affects Office 365. I deliberately exclude the far larger issue of reconfiguring the on-premises environment for access to such things as file shares and corporate applications.

Picture the scenario: you control two Active Directory forests and due to a desire to do an email migration and consolidation before collapsing the Active Directory first, you leverage the Azure AD Connect tool in order to sync two (or more) forests with one tenant. It’s not the worst situation, but what you’ve decided you really want to do is to have a new unified Active Directory forest and bring everything together. This is to help you maintain, if nothing else, a single set of security groups for access to resources. Then there’s also the matter of a single set of distribution groups without having to create cloud-based groups and next individual groups from different forests.

So how on earth do you bring two Active Directory forests together without doing a hugely complicated mailbox/OneDrive/SharePoint/Teams’ migration?

There isn’t currently a supported method of disconnecting a user mailbox in Office 365 and reconnecting it to a different Active Directory account. While that always was, and remains, possible in on-premises AD/Exchange, it’s not an option in Office 365.

You can do it for one person if you really have a need, but it’s not the kind of process you would employ for any more than a handful of cases: https://www.e-apostolidis.gr/microsoft/office-365/how-to-disconnect-a-mailbox-re-assign-it-to-new-user-in-a-hybrid-scenario/

The answer isn’t as complicated as you might imagine. Well, ok, it is, but it’s the steps that are complicated rather than the technology.

You’re going to do two separate things: remove Azure AD Connect and migrate Active Directory accounts from the old forest to the new.

Firstly, execute: “Set-MsolDirSyncEnabled –EnableDirSync $false”. This will disconnect the relationship between Azure AD and on-premises AD. The objects in Azure AD will change from being synched to being Cloud-Only. The user IDs and passwords are all the same and users can log on to email, etc., and send and receive just as they had been doing up until now.

This enables you to focus on your Active Directory transition project without the worry that in 20 minutes you’ll have users breathing down your neck and clamoring to be in their Office 365 resources.

You need to use some tool to migrate the user accounts and other objects between forests.

Which one you choose is dependent on the time-frame and the budget. It’s the usual IT triangle: Cheap/Quick/Right – choose two.

Your options are (at least) three:

1. ADMT from Microsoft: https://www.microsoft.com/en-us/download/details.aspx?id=19188
2. Migration Manager from Quest: https://www.quest.com/products/migration-manager-for-active-directory/
3. Active Directory Pro from Binary Tree: https://www.binarytree.com/products/active-directory-pro/

What all of these tools do is to take the Active Directory objects from one forest and place them in another. The accounts go across with passwords as well so there’s no worry about things not matching up. Once you’re comfortable that you have user accounts, distribution and other groups migrated, you can take the next step, which is to do a fresh, clean installation of Azure AD Connect which is tied to the one forest only and do a resynchronization.

But aren’t I just going to get two objects in Azure where previously there was one? How do I ensure there are no duplicates?

Azure AD Connect has come a long way over the years. The applicable feature in this case is SMTP Matching: https://support.microsoft.com/en-us/help/2641663/use-smtp-matching-to-match-on-premises-user-accounts-to-office-365. The key factor in the migration process is to make sure the migrated source object in Active Directory and the target object in Azure AD have the same UPN and SMTP addresses. If the object you’re sending to Azure AD has the same UPN and/or SMTP address, the account will change from being cloud-only to being synchronized with the new Active Directory.

There you have it. You have successfully migrated accounts from one forest to another without having to do a lot of heavy lifting between Active Directory and Azure AD – and by extension Exchange Online and other Office 365 resources. That is one thing off your long list of things to worry about; the migration of your on-premises services is another matter and will be the topic of a future post. Finally, if your organization needs help with any aspect of Office 365, please reach out to us. We’d love to help you get started.