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.

Office 365 tenant with two hybrid email 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.

Don't enable centralised mail

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 connector to on-prem
  • 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)
Exchange Multi-Forest Hybrid Tips and Tricks

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.

Consider carefully before enabling organisation configuration transfer

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.

Exchange Multi-Forest Hybrid Tips and Tricks

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  
get email address default policy

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 
Check the new rule is in place example

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.

Exchange Multi-Forest Hybrid Tips and Tricks

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

Exchange Multi-Forest Hybrid Tips and Tricks

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.

Comments

  1. GP

    Hi,
    How to manage distribution groups and members are from different forest? Currently, I’m unable to add the other forest A user as a member to forest B user.

    1. Hooda

      Where you able to resolve this issue? I have the same issue both forests share the same SMTP domain name and they are both Syched to the same tenant.

  2. Lozano

    what about if the MX records are on premises for company A and B

  3. Kiran P

    Thanks Colin,

    we have hybrid two exchange forests and syncing to one tenant using aad connect and we have some mail contacts of forest2 users and they are part of Distrubution list and vice versa how can we proceed in that scenatio

  4. SJ

    Hi, great article. I have a unique situation that touches on the configuration in this article. We currently have two forest, two exchange forests with cross forest enabled, users in both, trusts, etc – the whole lot. Company A has half of its users in Office365, rest on-premise. Company B is completely in Office 365, same tenant. We now have a requirement to split the organisation move Company B to a new tenant. Tenant migration is fine and i understand that concept well. My concern is with Company A and Company B emailing post this migration. I imagine the GAL will be a complete mess. Any tips or things to do in this scenario?

  5. Ron

    Hey Colin,
    Is this article regardless of whether there is an AD Trust between Forests in place or is that not required? Thanks, Ron

  6. Brajesh

    So after this configuration when we want to consolidate both AD forests – migrating objects from the secondary forests to the central forest where AD Connect is located, how it reacts to the move Or is there a specific procedure to be followed?

  7. Clinton

    Hi Colin,

    Do you need license for both companies in your tenant?

  8. Lalit

    Hi All,

    Need your help. I have a environment where in Already Ex2016 + Office 365 is in hybrid. We have to setup another hybrid with Ex2016+Ex2010. Ad connect is setup between two forest.

    How can I achieve another hybrid with out disturbing the Existing Hybrid and its connectors.

    Thanks

  9. David

    Hi,

    Does Exchange hybrid supports exchange on premise SRV record auto discover direct

    Thanks
    David

  10. Jer Per

    MIM = Microsoft Identity Manager

    Also interested in the consistent GAL question?

  11. DR

    Pardon my ignorance, but what is MIM?

  12. Enrico Giacomin

    Thanks Colin for this useful article.
    I’m just dealing with an environment like this, and the issues I faced are challenging.
    Let me share the experience I did on mail flow. As you suggested, I made two outbound connectors based on transport rules using sender SMTP domain. The important is to configure an exclusion based on the IP addresses used by the on-premises Exchange Server’s send connector to O365 organization to avoid mail loop. Important, the IP address must be written as single IP, not as subnet addr/ netmask bit.
    In this way I configured an on-premises central mail flow on both organization based on sender SMTP domain.
    Now the question. How did you manage a consistent GAL in the three Exchange organisations and a full mesh free/busy. MIM is mandatory?
    Thank you.
    Enrico

Leave a Reply