Multi-Forest Migrations to Exchange Online

Over the past few years, I've migrated many mailboxes into Exchange Online. I've talked to customers with every possible set of requirements, and I've been able to accommodate most of them. Until recently, there has been one category of migration requirements that I haven't been able to accommodate: multi-forest migrations. For customers with two or more separate Active Directory (AD) forests, each with their own Exchange deployment, the supported solutions for moving to a single Office 365 tenant were very limited. They could either consolidate their on-premises AD forests into a single forest, or they could contact Microsoft Consulting Services (MCS) and develop a custom solution using Forefront Identity Manager.

With the recent release of the cumbersomely named Windows Azure Active Directory Sync Services (AAD Sync) and a change in the supported use of DirSync filtering, four new multi-forest Exchange Online migration scenarios are supported, without having to involve MCS or consolidate the on-premises AD forests. The four scenarios are separate topologies, full mesh, account and resource forest, and multi-tenant. After I describe these scenarios, I'll discuss the scenarios' migration requirements and explain how to use AAD Sync to successfully complete the migrations.

Scenario 1: Separate Topologies

The separate topologies scenario refers to an organization with multiple AD forests (each with its own Exchange deployment) with no trusts or federation setup. In this scenario, all AD forests are completely separate. This situation often results from a merger or acquisition. It can also result from an organization having multiple separate business units that historically have kept their IT infrastructures completely independent of each other.

With AAD Sync, migrating mailboxes from the separate Exchange deployments into Exchange Online is easy. There are two tasks you should perform before installing AAD Sync:

After you perform these tasks, you simply install AAD Sync in each forest (which I explain how to do in the "Setting Up AAD Sync" section) and proceed with two hybrid Exchange deployments to a single tenant.

It's important to note that there are some limitations with this configuration, which are best illustrated by an example. Suppose that a user named Mary has an on-premises mailbox in forest A. Mary won't have any users from forest B listed in her Global Address List (GAL). Her GAL will contain only users with on-premises mailboxes in her own forest, users who were created as on-premises mailboxes in her forest and migrated into Office 365, and users who were created as remote mailboxes in her on-premises forest. The same holds true for users with on-premises mailboxes in forest B through Z. To confuse the matter more, once Mary's mailbox is moved into Office 365, she will see everyone listed in her GAL. This happens because mail contacts are created in Exchange Online for every mailbox, but those mail contacts will never be synchronized with the on-premises AD forests. Maybe Microsoft will add a GAL synchronization solution into AAD Sync at some point, but I don't expect it to happen anytime soon.

Scenario 2: Full Mesh

The full mesh scenario refers to an organization with multiple AD forests (each with its own Exchange deployment) with trusts and federation setup. In this scenario, the organization might have a GAL synchronization solution set up to provide a unified GAL across all, or some, of the Exchange deployments.

In the full mesh scenario, you migrate mailboxes to Exchange Online the same way you migrate them in the separate topologies scenario, except you might have a GAL synchronization solution to set up. The GAL synchronization solution could be Forefront Identity Manager or a third-party solution. The GAL synchronization solution needs to be separate from AAD Sync because AAD Sync doesn't provide the capability to perform GAL synchronization between on-premises Exchange deployments. How you deploy the GAL synchronization solution depends on the solution chosen, so it's beyond the scope of this discussion.

Scenario 3: Account and Resource Forest

The third supported scenario is the account and resource forest configuration. In this scenario, the organization has a single resource forest that contains all the Exchange servers in addition to one or more account forests that contain the user accounts. All users will have active accounts in their respective accounts forests and disabled accounts in the resource forest.

The unified GAL problem found in the previous two scenarios isn't a problem in the account and resource forest scenario because the organization has only one on-premises Exchange deployment and one Office 365 tenant. Therefore, every user is going to see every other user in the GAL.

The hard part of this deployment is ensuring that AAD Sync properly recognizes the disabled accounts in the resource forest and properly associates them with the active accounts in the accounts forest. To ensure proper account associations, you need to carefully consider the configuration options used for their AAD Sync deployment. These options are discussed in the "Setting Up AAD Sync" section.

Scenario 4: Multi-Tenant

In the multi-tenant scenario, the organization has a single on-premises AD forest with a single Exchange deployment and wants to connect Exchange to multiple Office 365 tenants. This scenario will most likely come into play for international organizations that want to move to Office 365, but their users must stay in Office 365 data centers within their own regions.

AAD Sync isn't needed in this scenario. You can migrate mailboxes to Exchange Online using DirSync with some filtering setup. After you deploy one DirSync server in each region, you set up DirSync filtering to ensure that out-of-region users are excluded from their respective tenants. In addition, email address policies need to be configured so that users and contacts in each region are assigned the proper service routing addresses. This solution is easy to deploy, but I suspect that some organizations will have difficulty maintaining the necessary configurations.

Setting Up AAD Sync

The most important part of the AAD Sync deployment is ensuring that each user has only one account in one of the forests being connected to the Office 365 tenant (except in the case of the account and resource forest scenario, in which case you need to ensure all users have disabled accounts in the resource forest).

The requirements for installing AAD Sync are:

In addition, at least two accounts are required to complete the AAD Sync installation: one on-premises account that needs read access to AD (default permissions assigned to all user accounts) and one global admin account for your Office 365 tenant.

After you download AAD Sync, open the MicrosoftAzureADConnectionTool.exe file, which will start the wizard. On the Welcome page, you need to specify the install location of the AAD Sync files.

Figure 1: Specifying the Location to Install the AAD Sync Files

On the Azure AD Credentials page, you need to enter the global admin account for your Office 365 tenant, as Figure 2 shows.

Figure 2: Entering the Global Admin Account

On the AD DS Credentials page, you need to enter the Active Directory Domain Services (AD DS) account for your AD forest, as shown in Figure 3.

Figure 3: Entering the AD DS Account

The User Matching page presents you with the synchronization options. As Figure 4 shows, this page has two sections to complete.

Figure 4: Selecting the Synchronization Options

In the Matching across forests section, you're presented with the choice between the Your users are only represented once across all forests option and the Match using option. The option selected will determine how AAD Sync will match accounts from separate forests. If your users have only one account across all forests, the choice is easy. You select the former option. If your users are represented in multiple forests, you need to select the latter option, in which case you need to specify the criteria on which to match. Table 1 shows the possible matching criteria and their most common usage.

In the Matching with Azure AD section, you select the attributes you want to use as the source anchor and user principal name (UPN). The attribute chosen for the source anchor must never change for the lifetime of the object, including if this object is migrated between domains or across forests. This immutable attribute is used for identity federation. The default selection is the objectGUID attribute, but an organization can choose to use another attribute if that one isn't guaranteed to be unique and unchanging across all forests. Similarly, the selection for which attribute to use for the UPN defaults to the userPrincipalName attribute, but it can be changed if necessary.

As Figure 5 shows, on the Optional Features page, you can select three optional features:

Figure 5: Selecting Optional Features

On the Configure page, the wizard confirms your selections, as shown in Figure 6. Afterward, it starts the configuration.

Figure 6: Confirming Your Selections

After AAD Sync is installed, you need to repeat this process to install it in each forest you're connecting to your Office 365 tenant.

A Helpful New Tool

AAD Sync is a new tool from Microsoft that allows a number of new multi-forest migration scenarios to Office 365 to be accomplished fairly easily. With a little bit of planning, you should be able to accomplish these new migration types without any major problems.