Multi-Forest with an Exchange Resource Forest and Going Hybrid

Complex and Supported

Not all organizations moving to Exchange Online come from an on-premises organization with a single Active Directory (AD) Forest. Organizations with one or more User Forests (UF) that access a trusted Exchange Resource Forest (ERF) will need to do some additional due diligence and discovery of mailboxes and their linked status, shared mailboxes, mail flow, SMTP domains, and more to ensure success. Organizations may have created this structure for security purposes or for Mergers, Acquisitions, and later spin-offs by keeping User Forests and Exchange Resource Forests separate. Adding Exchange Online can complicate things as now we have multiple forests, multiple user accounts, and data synced to another location – Azure AD (Entra ID). In this article, we discuss some good practices to help organizations prepare for a Hybrid Exchange Online sim in a multi-forest environment, including collapsing the ERF to create a simplified environment.

Multi-Forest with an Exchange Resource Forest and Going Hybrid

This article uses the following as the example environment:

• User Forest (UF): AD Forest / Domain Functional Level of Windows 2012 R2 or higher
• Exchange Resource Forest (ERF): AD Forest / Domain Functional Level of Windows 2012 R2 or higher
• Two-way trust between each forest
• Exchange 2019 (Latest CU / Security Update)
• Licensed Microsoft 365 tenant with Exchange Online
• User mailboxes – some are linked, some are not
• Shared Mailboxes, Contacts, and Distribution Groups in use with Exchange Server
• Public Folders (Hybrid preparation and Hybrid migration)
• Linked Mailbox: A mailbox in the ERF with its disabled user account is connected to an enabled user in the user Forest which is used for user authentication and access.

Where to Start

Our goal is to move objects to Exchange Online and to have users connect to Exchange Online mailboxes. As such, we need to perform multiple tasks and consider all the moving parts to make this successful. Here are some considerations to take into account for a multi-forest Hybrid configuration.

Azure AD Connect

A key component of a Hybrid environment is knowing where to place and configure AAD Connect to process all Forests in an environment. AAD Connect should be installed where it has access to all Forests that need objects synced to Entra ID. For example, if we have two Forests (User and Resource), AAD Connect can be placed in either forest and is authenticated by credentials for each Forest as entered in AAD’s configuration. The same rule applies in more complex environments (more Forests/trusts). With the correct matching attribute, we are able to match the disabled user in the ERF with the enabled user in the User Forest and sync to Azure AD, and in our case of Linked Mailboxes, ObjectSID (User Forest), and msExchMasterAccountSID (ERF) allow Azure AD Connect to match these accounts to a singular Azure AD User.

Uniquely identifying users

When Azure AD Connect is configured with multiple Forests and we need to combine objects, we need to make sure that in the ‘Identifying Users‘ configuration page, we select the option that users are represented once across all directories and choose the Source Anchor that is appropriate for your environment.

It is worth noting that if this is not done on installation, you must remove Azure AD Connect and reinstall it again to choose this option.

A user in the ERF tends to have a lot more attributes populated like email address, groups, address, manager, and more. Fully populated user objects are more important to an Exchange Organization because they appear in the Global Address List (GAL). The enabled users in the User Forest are not mail objects, resulting in fewer properties populated but may be added to groups for local resource access. Objects from the ERF and user forest are combined to create the object synced to Azure AD.

Caveats to Unique User Identification

ObjectSID matching is only for Users and does not work for Groups and contacts, and it also does not work if an account is not already linked. If an organization decides to collapse a multi-Forest Hybrid setup, the ObjectSID becomes rather important. If an environment remains a Multi-Forest Exchange Hybrid environment, then non-mailbox objects in the ERF will synchronize as expected to Exchange Online. Future mailboxes, groups, and contacts can be created and maintained in the ERF as well.

Good Practice: If all mailboxes are migrated to Exchange Online, it is possible to convert Exchange on-premises to a headless setup following these instructions from Microsoft. Before doing so, understand that PowerShell will be how you manage Exchange-related user attributes, or as an alternative, use the Exchange Recipient Admin Center (by MVP Steve Goodman).

Collapsing an Exchange Resource Forest

We started off with an existing Multi-Forest Hybrid Exchange environment that has been migrated to Exchange Online, the ERF now contains pointers in an empty Exchange Organization. All mailboxes are in the cloud, all contacts are synced to the cloud, all distribution groups are in the cloud, and so on. Now what? Is it useful to have the ERF? If the purpose of the ERF was for the separation of users and Exchange for one or more organizations, we can do the same thing with User Forests, Azure AD Connect, and Exchange Online – without Exchange On-Premises.

The first step to collapsing an ERF is to introduce Exchange into the User Forest. This action will stamp mail objects with Exchange Attributes and allow the ‘anchoring’ of objects to this Forest instead of the Resource Forest. Let’s walk through each object to see how to handle them properly.

Linked Mailboxes/Share Mailboxes

Linked Mailboxes and Share Mailboxes are the easiest to handle and as the majority of attributes are in the ERF, we need to copy those attributes over. This can be accomplished with PowerShell (examples by fellow MVP Jaap Wesselius). The Key here is understanding what attributes are important (differs in each organization). At the least, these attributes are needed:

• PrimarySMTPAddress
• RemoteRoutingAddress
• ExchangeGUID
• DisplayName
• LinkedMasterAccount

We can also pull addresses, phone numbers, managers, and more if required from the disabled user object in the ERF. The steps to perform this task are as follows in the User Forest: mail enable the user, enable the remote mailbox, stamp the Exchange GUID, and stamp all email addresses.

Non-Linked Mailboxes (Shared as well)

Similar to the Linked Mailboxes above, non-Linked mailboxes need their attributes copied over. However, a few more steps are needed to complete the move process. The reason is the Source Anchor, as we need to reset this in Azure AD to anchor the Exchange Online Mailbox to the new account in the User Forest. A summary of steps for this conversion are: Move the ERF user to an OU that does not sync, run Azure AD delta sync, restore the soft deleted user in Azure AD, clear the immutable ID in Azure, the new user in User Forest is added to synced OU, Azure AD delta sync, enable remote mailbox, and then apply attributes to this new user.

Distribution Groups

Distribution Groups do not join attributes as a matching Distribution Group in the User Forest creates a new group entirely. The best option here is to make sure all mail objects are in the User Forest first, create Distribution Groups in a non-sync OU, add all mail-enabled objects, add ERF Distribution Group to an unsynchronized OU, run an Azure AD delta sync, move the new DG to a sync OU in the User Forest, run an Azure AD delta sync, and verify the new group is available. If there are work processes dependent on these groups, be sure to test this process as it may cause unforeseen issues.

Contacts

For contacts, the simplest way, as their attributes do not join like user objects, is to create a copy of them in a non-sync OU of the User Forest using PowerShell, move the ERF Contact in an unsynchronized OU, run an Azure AD delta sync, move the UF Contact to a synced OU, run an Azure AD delta sync, and validate contact is accessible. It is important to make sure all email addresses are copied.

Mail Flow Considerations

When collapsing the ERF, mail flow will have to be re-routed. If an outside third-party vendor provides Directory Based Edge Blocking (ProofPoint can do this for example), then considerations will need to be made for re-routing. Better yet, route all email to Exchange Online directly or via third-party provider.

Firewall

With the current state of Exchange and its security posture, such as Hafnium and the plentiful Exchange Server security patches released, it is highly recommended to restrict traffic to and from Exchange Hybrid so that it only communicates with Exchange Online. Follow this documentation for further information.

Azure AD Connect

After collapsing the ERF, make sure to remove it from Azure AD Connect to prevent any error messages or issues with future syncs. Export the configuration before and after this change to preserve the information (just in case).

Final Thoughts

A Multi-Forest Hybrid Exchange scenario is complicated and requires extensive planning. Because different types of Exchange objects need attention across Forests to handle post changes like mail flow, be mindful of the environment and document before, during, and after making changes in case a reversion is needed. Make sure that support entities are aware of these changes and know where to begin troubleshooting after each change. If at all possible, test thoroughly before making any changes. If using PowerShell to make changes, use error handling, logging, and transcripts for troubleshooting and reversal if needed.