Exchange Multi-Forest Hybrid Tips and Tricks

Setting up Exchange hybrid between Office 365 and on-premises is a common and well-understood configuration. Chances are, you have this setup today.

But what if you have more than one Exchange forest?

Multiple forests, each with their own hybrid connection into a single Office 365 tenant, is supported from Exchange 2010 to 2019, although it does come with a unique set of challenges. This article assumes you have one Exchange organisation in hybrid and multiple Active Directory Domains synchronizing using Azure AD Connect already and are looking to add more Exchange Forests.

Key Considerations with Multi-Forest Exchange Hybrid

The basics still need to be in place for additional Exchange hybrid deployments. Azure Active Directory (AD) needs to successfully sync all users to the cloud (one per tenant, regardless of how many Active Directory forests), Sender Policy Framework (SPF) and Domain-based Message Authentication. Reporting & Conformance (DMARC) also needs to be configured correctly, and the Simple Mail Transfer Protocol (SMTP), Embedded Web Server (EWS), and Autodiscover on-premises endpoints need to be exposed properly. See here for more guidance.

You should also take care to ensure that all Autodiscover endpoints work for all – internal name resolution allows connections through internal firewalls and if Service (SRV) records are in use then Outlook Autodiscover prompts are suppressed.

One thing to note is that when all your organisations are in hybrid, the on-prem user’s global address list doesn’t change to include all other Exchange organizations. There are no immediate benefits such as mailbox sharing to users sourced from foreign Exchange environments.  To get the maximum collaboration, all users need to have their mailbox in Office 365.

Existing policies in Office 365 – Data Loss Prevention (DLP), archiving, transport rules. These all require assessment, especially when integrating different geographies or companies and departments with differing cultures and languages.

Hybrid Configuration Wizard – Special Considerations

Setting subsequent Exchange organisations into Federation can be achieved by the normal Hybrid Configuration Wizard (HCW), but some specialised configuration is required – this is discussed below. Should you ever need to re-run the HCW, then the guidance below still applies, and the steps will need repeating.

Centralised Mail Routing

Centralised mail routing is Microsoft’s term for sending outgoing emails via your on-prem environment. If this is present, or you wish your newly joined Exchange forest to perform centralised mail routing, then it’s necessary to take care to avoid unexpected mail routing.

When running the Hybrid Configuration wizard against subsequent Exchange forests never select the checkbox to enable centralised mail configuration. This is because the wizard ‘helpfully’ inserts a default mail route to your new hybrid Exchange environment for all Office 365 email, which would probably be a surprise when all external email routes via it.

The simplest answer is to not have any centralised mail routing and deliver email straight from Office 365 via the implicit deliver-via-MX-resolution route. Due to compliance and existing message hygiene products in use however, this is not always possible.

If you wish to achieve something like centralised mail transport for your new Exchange forest, or you already have centralised mail transport that you don’t wish the new Forest to be part of, after Hybrid Wizard has successfully completed perform the following:

• Setup a connector to your on-premises environment (from Exchange 365 to Partner) that only fires when triggered by a transport rule

• Setup a transport rule to ship external emails for senders from that company to the connector, unless the email is internal. If you cannot match on senders domain, consider using a group (and populating that group appropriately)

There are some exceptions. System generated email addresses will not follow the transport rule. For example, messages generated by Office Message Encryption (OME) that appear to come from the sender will not trigger that rule and still be sent via the default route, so that default route must have the ability to send email for that domain (SPF records and relay rights).

Organization Configuration Transfer

In the Hybrid Configuration wizard, there is an option to perform an ‘Organization Configuration Transfer’ which copies certain configurations like retention policies tags. Unless you have a comprehensive test environment to thoroughly test and assess the impact of meshing existing on-premises policies with existing tenant policies, it is probably safest to not select the ‘Organization Configuration Transfer checkbox and manually re-create once hybrid is complete.

Routing address

As part of the Hybrid Configuration wizard, your Exchange Address Policy generation default rule will be updated to include an Office365 routing address:

  @tennantname.mail.onmicrosoft.com 

Where %m = mailbox alias

This is done by modifying the default recipient policy. The challenge with approach (mailboxalias@tennantname.mail.onmicrosoft.com), is there is no check for uniqueness outside that Exchange forest.

If you’re lucky, your mailbox aliases across different Exchange environments will not and never will clash, so there’s nothing to worry about. If there’s a chance of a clash, then action is required. 

Modifying the default address generation rule with a forest-specific prefix may resolve the issue.

If you just let the Hybrid Configuration wizard run, it will likely end up with all your user accounts stamped with the default routing address, risking a clash. An approach to tackle this is to stop accounts from being updated by address book policy, run the Hybrid Configuration wizard, modify the address generation rules, then regress the address policy update.

To achieve this:

1. Disable Accounts from being updated by recipient Policy

Get a list of all accounts that Do Have ‘Automatically update email addresses based on e-mail address policy’.

get-mailbox * -resultsize unlimited | where {$_.EmailAddressPolicyEnabled -eq $true} | export-csv NoPolicyEnabled.csv -nti  

Assess the output and validate it is correct

2. Run the Hybrid Configuration wizard as normal

3. Modify the default address book policy to remove the HCW created routing address rule %m@tennantnname.mail.onmicrosoft.com and apply a new forest-specific policy, e.g. CompanyA-%m@tennnantname.mail.onmicrosoft.com

a) Take note of the current Email Address Templates:

get-EmailAddressPolicy "Default Policy" | Select-Object EnabledEmailAddressTemplates  

b) Update the address to include your new routing address scheme, and any other address

Set-EmailAddressPolicy "Default Policy" -EnabledEmailaddressTemplates "smtp:new-routing-email@tennantname.onmicrosoft.com","SMTP:%g@company.com","smtp:$s%g@company.com"  

c) Check the new rule is in place

get-EmailAddressPolicy "Default Policy" | Select-Object EnabledEmailAddressTemplates 

d) Regress the setting to return mailboxes to automatically updating email addresses using the CSV generated in the previous step

Use Email address from Company A in Company B

Once Exchange organisations are hybrid-enabled into the same tenant, it is possible for a user to have an email address based from another forest in the environment. For this to operate successfully the mailbox needs to be in Office 365, and in the ‘owning’ Exchange on-premises forest, the email domain needs to be set to internal relay. In other words, when the on-prem environment cannot find the mailbox, it must send it onwards rather than non-deliver the email.

Simply add the desired email address to the ProxyAddresses field of the on-premise mailbox.

Issues to be aware of

A key issue to be aware of is if you set User Principal Name (UPN) to be their email address, this will not work, as the UPN can only be owned by one forest in a typical corporate environment with trusts. Users who chose to have their reply address as a domain owned by another forest will need to know when to enter their UPN and when to enter their email address.

There are a few other issues. Firstly, the user and email address will never appear in the on-premises environment that owns that email domain which may be confusing if you have on-prem mailboxes.

Secondly, if you have a separate message hygiene product that looks up the directory to validate email addresses, it may reject the message, as the
Simple Mail Transfer Protocol (SMTP) address will not be in the directory it is looking at.

No checking for duplicate SMTP addresses will be done either, so it will be possible now to create a duplicate SMTP address. Whilst this will not sync into Office 365, it will be confusing so a process to ensure no duplicates needs to be implemented. Using MIM or similar to create contact objects in Company B from user accounts in Company A and vice-versa may resolve these three issues.

Conclusion

Once setup, multi-forest Exchange hybrid works really well. Whilst there is complexity in the initial setup, it’s a much faster and smoother than third-party tooling, or AD Domain consolidation to achieve true email collaboration in an organisation.