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!

Comments

  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_).

    ReplyDelete
    Replies
    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.

      Delete
  2. This article is very attractive. Those who need this information, it's very informative and understandable good for those all. Thanks for this information. Oracle Manufacturing Cloud training in bangalore

    ReplyDelete

Post a comment

Popular posts from this blog

Install AWS CLI on WSL Ubuntu

On Premise Mailbox user missing in Exchange Online GAL