Migrate Azure AD Connect Between AD Forests

Migrate Azure AD Connect Between AD Forests

I was recently involved in an AD forest migration project for one of our customers. As part of the requirements, we need to move the existing AD Connect server to a newly created AD forest. While the process itself is pretty straight forward, I do notice there aren't many online resource out there detail the whole process. So to make things even easier for the folks out there, I will share the steps I took to complete this AD Connect migration.

The details shown here are from my sandpit environment. 
The existing/source AD forest: old.contoso.com
The existing AD DC/AD Connect server: old-dc1.old.contoso.com
The new/target AD forest: new.contoso.com
The new AD DC/AD Connect server: new-dc1.new.contoso.com
UPN Suffix: briwave.com

Here's a simple diagram to help you visualize the whole setup.

Add New AD Forest to Existing AD Connect

First, we need to add the new forest new.contoso.com into the existing AD Connect sync scope.
Below are the steps to do so:

1. On old-dc1.old.contoso.com, open AD Connect. Under the Task, choose Customize synchronization options.
2. Enter the Azure AD Global Admin credential to connect.
3. Add the new AD forests into AD Connect.
4. Confirm the UPN Suffix is verified.
5. Record the OU Filtering settings for the forest. These settings will need to be applied to the new AD Connect later.

6. Record the settings here as well for later configuration on new-dc1.new.contoso.com.
7. Click Configure to apply the changes.
8. Click Exist to close.

To verify the configuration, open Synchronization Service on OLD-DC1 after run start-ADSyncSyncCycle and you should be able to see bunch of actions for new.contoso.com forest. If you check Azure Portal, you should also be able to see the newly provisioned users and groups from new.contoso.com AD.

Install AD Connect in Target AD Forest
The next step is to install and configure AD Connect in the new forest.
1. After download the AD Connect onto new-dc1.new.contoso.com, choose Custom install. 
2. Click Install to proceed.
3. Depend on the sign on method your organization use, you will need to choose the one accordingly. For my lab, I simply use the default password hash sync.
4. Put in Azure AD Global admin account to connect.
5. Add both forests to the scope.

6. Confirm UPN suffix and username option.

7. Select OU Filter for both forests, make sure it mirrors the current settings on Old-dc1
8. Choose Users are represented only once across all directories, as we will migrate the users across to the new forest later. With Source anchor, unless you use non default AD attribute for GUID, leave it unchanged.

9. Leave this unchanged, unless you use group based filtering.
10. With the optional features, you will want to keep the same settings as old-dc1 to avoid any unexpected issues.
11. Choose Enable staging mode... this will ensure that the AD Connect will not sync after complete the setup.

That's it. Click Install to finish the setup.
To confirm the staging mode setup, you can run start-ADSyncSyncCycle and check the log in Synchronization Service. As you can see below, there is no Export action to Azure.

Switch Sync Source From Old to New
The next step is to switch the synchronization from the old AD Connect to the new one.
To do this, we first turn AD Connect on OLD-DC1 to Staging mode.
Open AD Connect on OLD-DC1 and choose Configure staging mode (current state: disabled)

Tick the checkbox to enable Staging mode.
Uncheck Start the synchronization process when configuration completes. If you leave this checked, AD objects from OLD forest will still be synced to AD Connect metaverse(database), but will not be exported to Azure AD.

Once click Configure, the AD Connect will proceed to enable staging mode and stop sync to Azure AD.
Next, we disable staging mode on NEW-DC1. 
On NEW-DC1, launch AD Connect and select Configure staging mode (current state: enabled)

Put in Azure AD credential and uncheck Enable staging mode.

Check Start the synchronization process when configuration completes.
Click Configure to apply the changes.

Test AD Sync from NEW-DC1

Run Start-ADSyncSyncCyle Initial to kick off a AD Sync from NEW-DC1. From the result below you can see it picks up an update.

In the properties view of the update item, you can see ms-DS-ConsistencyGUID of Tony Zhang in NEW.contoso.com has now been added to Azure AD. It wasn't before because the user was just created when AD Connect in OLD.contoso.com did the sync.

So that's it. As simple as that, we have completed the migration of AD Connect from one AD forest to another!


  1. I have done multi-forest several times, but recently starter multi-forest as part of a forest migration (other times had multi-forest as an end-state). The old server, I didn't intend on establishing multi-forest with that server. However, We setup a new AAD Connect server connected to the new forest, and then added the old forest. Really weird, but the connector for the new forest kept trying to authenticated with the service account it created for the old forest even though the connector had the proper account in the MIISClient and when reviewing the configuration with the ADSync PowerShell module. I think we will uninstall it and add the new forest to the existing server and do the full forest migration, then step back through adding the new server.

    Just to illustrate it a bit more, the service account that Azure AD Connect makes is MSOL_. The account is the same name as it is derived from a hash of the server name (is my understanding). But, it is a separate account in each forest and it is listed as having the forest/domain name associated with their respective forests (e.g. OLD.FOREST\MSOL_ and NEW.FOREST\MSOL_).

    1. Well... that didn't work as expected. I have tags in there that were labeled Hash... anytime you see MSOL_, think MSOL_[Hash].

      Also, the error was that the service account for OLD.FOREST\MSOL_[Hash] does not have permissions to the domains in NEW.FOREST. We could potentially get around it all by granting those permissions, but that definitely isn't what we want to do as OLD.FOREST is going away.

  2. I have the same scenario where its a need to move Azure AD connect from one forest to another, the challenge that I see is the AD domain is same as public domain on new forest which I believe making it a bit complex to go for as this AD domain of new forest is authorized domain on Exchange server in old forest.

    xyz.com (new forest) <=> abc.com (old forest) - having Exchange on old forest with xyz.com as authoritative domain.

    Not sure how to handle it with above process except the one to break AD connect on old forest and then setup on new forest and do hard match with accounts.

    Please advise.

    1. Cant you setup a temp alternative UPN suffix on the new forest?

    2. Hello Tom,
      Thanks for your response.

      I thought about it, username to login will change with this step and later on when getting rid of it, user login will be changed back on 3565 to use xyz.com.

      I was thinking here to setup Azure AD sync and leave the email addresses on xyz.com and have each forest domain as authorized on O365, both abc.com and xyz.com. Since trust is present, it should also work. Your thoughts.


Post a Comment

Popular posts from this blog

Install AWS CLI on WSL Ubuntu

On Premise Mailbox user missing in Exchange Online GAL

Receive error: Target mailbox doesn't have an SMTP proxy matching '.mail.onmicrosoft.com' when move mailbox to Office 365