Shared Namespace After an Acquisition With No Trust
Fabrikam acquires Northwind, which runs Exchange 2019 in a separate AD forest with no trust. Northwind has 900 mailboxes and a heavily used free/busy culture. Both companies market under fabrikam.com; Northwind users currently use northwind.com addresses, but sales wants everyone to appear as @fabrikam.com within 60 days. Fabrikam already uses fabrikam.com in Exchange Online; Northwind will remain on-premises for at least a year. There is no third-party address-rewriting product and no budget for one. Fabrikam has 5,000 mailboxes and uses a cloud GAL. The acquisition team wants a single GAL, cross-forest free/busy, and mail routing between the two organizations without opening SMTP relay to the internet. Northwind's firewall blocks inbound port 25 from Fabrikam's cloud. Northwind uses a single Exchange server and no Edge Transport role.
1. Explain why assigning @fabrikam.com as the primary SMTP address to Northwind mailboxes in both forests will fail, and propose a routing and addressing design that meets the sales requirement without address rewriting.
Read the worked answer
You cannot assign fabrikam.com as the primary SMTP address to mailboxes in both forests. Exchange uses SMTP proxy addresses for routing and recipient resolution; duplicate primary addresses across two organizations create ambiguous recipients, mail loops, and NDRs, and Exchange Online will treat the on-premises object as a conflicting recipient. Adding fabrikam.com as a secondary address does not solve it either, because the duplicate still exists.
Without an address-rewriting product, the realistic options are:
- Migrate the Northwind mailboxes that must appear as @fabrikam.com into Exchange Online, where fabrikam.com is authoritative, and leave the rest on northwind.com.
- Make Northwind's namespace a subdomain such as northwind.fabrikam.com, which is honest but does not meet the sales requirement.
- Use a shared namespace with one side authoritative and remote mailboxes or contacts, which requires directory integration.
For 900 mailboxes and a one-year timeline, push back on the 60-day 'everyone @fabrikam.com' requirement and phase it: move customer-facing sales mailboxes to Exchange Online first, keep northwind.com as an accepted domain for coexistence, and do not create duplicate proxies. Address rewriting is not a native Exchange feature.
2. Design mail routing between the forests and to the internet given no trust and firewall restrictions. Specify connectors and authentication.
Read the worked answer
With no trust and inbound port 25 blocked from Fabrikam's cloud, you need an explicit SMTP path. Put Northwind behind a DMZ relay or an Exchange Edge Transport server that can accept TLS from Exchange Online and forward to the internal Exchange 2019 server. In Exchange Online, create a Send connector scoped to Northwind recipients or a remote domain with the smart host set to the DMZ relay and TLS required; in Northwind, create a Send connector to Exchange Online using tenant.mail.protection.outlook.com. Authenticate and encrypt both legs with a public certificate whose name matches the connector FQDN. Open the firewall only to the Exchange Online Protection IP ranges on port 25, not to the internet.
For Fabrikam-to-Northwind mail, address the recipients as [email protected] and let the Exchange Online connector route them; do not create duplicate fabrikam.com proxies. Test with message tracking on both sides. If the firewall team cannot allow the EOP ranges, the fallback is a pull-based or third-party relay, which is outside native Exchange. Document that this is routed coexistence, not a hybrid deployment, because there is no shared directory or trust.
3. Recommend a GAL and free/busy approach that works without a trust, and state which requirement you would push back on.
Read the worked answer
A single GAL across two forests without a trust is not a native Exchange capability. The workable options are directory synchronization with a metaverse product (Microsoft Identity Manager or a third-party GAL sync tool) that creates contacts in each forest, or making Exchange Online the central GAL and syncing Northwind users as mail contacts. Both require a server and ongoing ownership; a script that exports contacts is cheaper but will drift.
For free/busy, the native cross-forest option is federation: create a federation trust in each organization, configure an organization relationship, and allow availability sharing. That does not require an AD trust, but it does require the federation trust to be healthy and the domains to be verified. If federation is not approved, use Exchange Online as the free/busy bridge or calendar sharing via ICS, which is less real-time.
Push back on 'single GAL and full free/busy with no trust, no sync tool, and no budget' because those requirements are mutually inconsistent. Propose a phased scope: GAL sync for the sales teams first and free/busy for executive assistants only.