Manage Learn to apply best practices and optimize your operations.

How to complete a multi-forest hybrid Exchange setup

Once you know how multi-forest hybrid environments work, finish the setup process for custom domains and Azure AD Sync Services.

As companies continue to show an interest in the cloud, it's no surprise that hybrid deployments are increasing...

in popularity. Businesses use hybrid deployments for a number of reasons, especially to take advantage of some of the cloud's features without having to commit to a full migration.

One possible hybrid deployment is something called a multi-forest hybrid Exchange deployment, which includes one Office 365 tenant and several Active Directory (AD) environments with Exchange installed in each environment. The hybrid part happens when Exchange 2013 is installed in every forest in upgrades or "bridges" to the cloud, allowing the Hybrid Configuration Wizard to perform once in each forest.

Once you understand when to use a multi-forest hybrid Exchange setup and what's required to implement it, you can look at adding custom domains to Office 365 and then configuring Azure AD Sync Services to connect all AD domains to Office 365. While we do this, we'll use a few tricks to make life easier when implementing Office 365.

Use PowerShell to implement multiple custom domains

If you have few custom domains to add to Office 365, it's often easy to add them through the portal Web interface. Most multi-forest organizations have a larger number of custom domains to add, so using PowerShell can save a lot of time.

Download the Windows Azure Active Directory Module for PowerShell from the Office 365 portal and then use Connect-MSOLService to begin a new session as a Global Administrator. Next, add each accepted domain from each domain you plan to configure against the multi-forest hybrid setup. As with a single hybrid Exchange setup, admins must add every accepted domain in use to Office 365.

New-MsolDomain -Name
New-MsolDomain -Name
New-MsolDomain -Name

Usually when a custom domain is added via the Web portal, a page shows the domain name system (DNS) text record used to verify the new domain. Admins can retrieve all of these values with a single PowerShell snippet, allowing them to bulk-add the changes to an external DNS provider:

Get-MsolDomain -Status Unverified |foreach { Get-MsolDomainVerificationDns -DomainName $_.Name -Mode DnsTxtRecord | Select Label,Text }

The command's output includes two columns -- Label, which represents the custom domain, and Text, which shows the DNS record to add (Figure 1).

DNS validation records in PowerShell
Use PowerShell to retrieve DNS validation records.

Before configuring hybrid Exchange in each forest, synchronize each AD with Office 365. To perform the sync, use Azure Active Directory Sync Services installed on a server in the AD forest named GMI forest.

Create Azure AD Sync Services accounts

We'll need to create a service account in each forest that will read AD information and write back a small amount of information. In the example domains, create a standard AD account named adds (the acronym for Azure AD Sync) and then run the PowerShell script below to automate granting the correct rights for a hybrid Exchange setup and Password Hash Sync using the dsacls command:

$Account = "DOMAIN\aads"

$RootDSE = [ADSI]"LDAP://RootDSE"

# Contact and Group Write-Back

dsacls.exe "$($RootDSE.DefaultNamingContext)" /I:S /G "$($Account):WP;proxyAddresses;Contact" "$($Account):WP;proxyAddresses;Group"

# User Write-Back

dsacls.exe "$($RootDSE.DefaultNamingContext)" /I:S /G "$($Account):WP;proxyAddresses;User" "$($Account):WP;msExchArchiveStatus;User" "$($Account):WP;msExchUCVoiceMailSettings;User" "$($Account):WP;msExchSafeRecipientsHash;User" "$($Account):WP;msExchSafeSendersHash;User"

# Exchange 2013 Only

dsacls.exe "$($RootDSE.DefaultNamingContext)" /I:S /G "$($Account):WP;msExchUserHoldPolicies;User"

# Password Hash Sync

dsacls.exe  "$($RootDSE.DefaultNamingContext)" /G "$($Account):CA;Replicating Directory Changes" "$($Account):CA;Replicating Directory Changes All"

The script will grant the correct permissions to the GMI\adds account (Figure 2). Repeat the same procedure in each domain.

PowerShell grants Azure AD Sync write-back permissions
Grant the Azure AD Sync account the correct write-back permissions.

Install and connect to Azure AD

The core installation of Azure AD Sync Services is fairly straightforward. Download the MicrosoftAzureADConnectionTool.exe from the Microsoft Download Center, run the downloaded executable file and choose Install on the first page of the configuration wizard. The underlying components include SQL Server Express and Azure AD Sync.

Those familiar with DirSync will remember MIISClient.exe. This part of Forefront Identity Manager (FIM) is still installed, but the new version no longer bears the FIM branding and is a next-generation product under Azure AD Sync.

After installing Azure AD Sync Services, you'll be prompted to connect to the Office 365 tenant and enter the credentials for a global administrator (Figure 3). We've used the admin account, but I recommend using a dedicated Azure AD Sync account in a production environment with a complex password that doesn't expire.

Login page for Azure AD Sync
Connect Azure AD Sync to Office 365.

Create sync Relationships and configure core features

To connect Azure AD Sync Services to each AD forest -- GMI, GMIUK and LJD -- go to the Connect to AD DS page of the wizard and enter each forest name with the Azure AD Sync service account details. 

Enter the information for the service account. Choose Add forest until each Exchange and AD forest is listed in the Forest section and then choose Next (Figure 4).

Connecting Azure AD Sync Services to each Active Directory forest
Connect to each AD and Exchange forest.

In the next step, Uniquely identifying your users, you must configure Azure AD Sync Services so it matches accounts and contacts across forests in a way that mimics a typical multi-forest hybrid Exchange setup.

Start with the Matching across forests section; the unique identifier across systems is the email address stored in the mail attribute. Therefore, a mailbox in the GMI forest should be linked to a contact in either GMIUK or LJD forests if the email address matches.

In the Matching with Azure AD section, the value to specify depends on your environment and plans for the future. For the sourceAnchor, which is used to link an account in AD to an account in Office 365, the simplest match is to use the objectGUID because it has the same value the single forest DirSync tool uses. This isn't a good value to use if you plan cross-domain moves, since the objectGUID will change, so use something that never changes. This environment won't be consolidated, so we'll use objectGUID.

The userPrincipalName attribute is the value Office 365 uses for the login ID. This typically uses the AD userPrincipalName attribute, though some simple environments that don't require hybrid Exchange setups might use something such as "Mail." We'll use the userPrincipalName attribute because we'll have the same login ID to work both on-premises -- when accessing AutoDiscover -- and when in Office 365, when accessing the mailbox (Figure 5).

On-premises Exchange and Office 365 account matches
Match on-premises accounts to Office 365 accounts.

Finally, on the Optional Features page, select the all-important value that enables admins to run the Hybrid Configuration Wizard in each forest -- Exchange Hybrid Deployment. We're also using Password hash sync for the deployment, rather than the complex Active Directory Federation Services, so check Password synchronization (Figure 6).

Password synchronization
Select hybrid Exchange and Password Sync options.

After entering the configuration details, move to the Configure page where the selected configuration will be implemented and saved. The final page of the wizard gives the option to synchronize the directories immediately.

About the author: 
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners. Goodman has worked extensively with Microsoft Exchange since version 5.5 and with Office 365 since its origins in Exchange Labs and Live@EDU.

Next Steps

This is part two in a series about multi-forest hybrid Exchange Server deployments. Click here for part one, which goes into detail about what a multi-forest hybrid setup is, when admins should use it, and what's required to implement it.

This was last published in January 2015

Dig Deeper on Exchange Server Deployment and Migration Advice



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Very nicely covered! Thanks Steve.
You say: In the Matching with Azure AD section, the value to specify depends on your environment and plans for the future. ....if you plan cross-domain moves, since the objectGUID will change, so use something that never changes. ...

Is it true that if I am going to put in my O365 tenant many Hybrid deployment, I have no problem with ObjGUID(s) because is inherently unique over the world, while I can have problems if I move the user outside the tenant?