Email namespace sharing: How to quickly rebrand a new acquisition

As soon as a merger or acquisition deal closes, there is a great urgency to integrate the two companies on a single, unified Exchange environment. This allows everyone in the new company to appear in the same Global Address List (GAL) and enables all users to share calendars. More importantly, however, it brands everyone under the same @newcompany.com email address. When a new acquisition keeps using their old email address for an extended period, it appears that they are still operating as a two separate companies.

However, a full cross-forest Exchange migration can be a large undertaking. It is often accompanied by a domain migration which requires significant time and resources. It's often desirable to rebrand everyone's new email address ahead of completing a full cross-forest migration.

The quickest and easiest method to achieve this namespace sharing is by architecting a non-authoritative mail loop between the two (or more) Exchange organizations. The diagram below represents two companies sharing the "newco.com" email address namespace:

The key aspect of this design is that both Exchange organizations are non-authoritative for the newco.com namespace. This way, when Company A receives an email for a user in Company B, it will try and find the user locally, fail, and then forward the mail (via a send connector) to Company B where it will be successfully delivered to the user.

The potential downside to this design is that if an email is sent to a user who does not exist (for example, if the sender makes a typo) the email will bounce back and forth between the two Exchange organizations as neither of them will be able to find the recipient. Luckily, Exchange 2007 and later is able to detect these mail loops and will eventually email the sender a non-delivery report.

The first step to implement this design is to connect the two organizations via a secure point-to-point connection. Internal emails will be sent cross-organization, so they must be securely encrypted. Once the two Exchange organizations have full network connectivity, the following powershell commands can run (these have been tested on Exchange 2010) to establish non-authoritative mail routing:

Commands to run on Company A assuming there there are two servers with Hub Transport roles (Amail1 and Amail2 with IP addresses 192.168.10.1 and 192.168.10.2 respectively):

Commands to run on Company B assuming there there are two servers with Hub Transport roles (Bmail1 and Bmail2 with IP addresses 10.10.10.1 and 10.10.10.2 respectively): 

Running these four commands on each organization will create the necessary cross-forest send and receive connectors and add newco.com as an internal relay accepted domain. From here, you should point the MX record for newco.com at either organization (Company A in this example) and test cross-organizational mail flow.

It's important to be aware of any directory-based edge blocking being performed by a message hygiene service such as Forefront Online Protection for Exchange (FOPE) or Cisco Ironport. This feature will block emails sent to users in Company B because they are not seen in the directory of Company A. The message hygiene service will have to be reconfigured to synchronize with both directories in order to allow all users to receive mail from external senders. It is recommended to continue using directory-based edge blocking, however, to prevent spam and give senders a quick non-delivery report if they try to email a non-existent user.

With cross-forest mailflow fully tested for the newco.com namespace, every user can be given a newco.com email address as their new primary address. This can be performed with Email Address Policy or powershell depending on the situation. They should keep their old email address as a secondary so that they will continue to receive email at that address.

One known issue is when users "reply all" to an email on their Activesync smartphone, the phone will include them in the "reply all" recipients and so they will send a copy of the email to themselves. This will not occur in Outlook or OWA, but this can be annoying for heavy phone users. The fix for iPhone users is to simply change the email address on the account to @newco.com, but in my limited testing I found that Android phones needed to completely remove the Exchange account and re-add it with the @newco.com address. This can be especially tricky because the autodiscover record for newco.com can only point to one Exchange organization. For the other organization, users will have to manually specify their server settings in conjunction with their @newco.com email address.

This method is fast and simple, but does not enable a unified GAL and therefore does not support cross-forest calendar sharing. If those are strict requirements, a Galsync tool must be implemented between the two organizations to enable cross-organizational mail flow, synchronized GALs, and cross-forest availability.