In the first blog post of this series, I provided an introduction on how companies undergoing carve-outs can effectively migrate of all their IT resources and services to a new entity. In this blog, I discuss the steps required to establish and maintain Exchange mail-flow coexistence between the Parent and NewCo organizations.
In lieu of a big-bang-style weekend migration where all mailboxes are migrated at once, cross-forest Exchange coexistence is required. Because MX records cannot be changed until all of the migrations are complete, the coexistence design must involve all mail flowing through the Source Exchange environment. Once the mail comes in, it must go directly to the inboxes of those users who have not yet been migrated or get routed to the Target domain for those users who have been migrated. This could be achieved by changing the receive connector for TargetX.com to Internal Relay on both the Source and Target domains, however this could also cause a mail loop when an email is sent to a user who does not exist in either domain.
The solution, therefore, is to use Mail Enabled User objects (MEUs) on the Source domain to essentially forward mail for migrated users. When a user is migrated, the Mailbox object is replaced with an MEU having an external email address of TargetX.net, which is a previously unused email domain. This external email address is essentially a forwarding address, so rather than delivering the email to a mailbox, Exchange sends it to the external email address. This domain is also not made public via MX records, however, so a send connector for TargetX.net also needs to be created on the Source hub transport servers in order to route all mail sent to TargetX.net to the Target Exchange servers. The overall coexistence design is illustrated below:
The use of MEUs on the Source domain will therefore enable cross-forest mailflow for migrated users. The only additional consideration to make is migrated users replying to old emails or using their auto-complete (nickname) cache in Outlook. Both of these actions use the Distinguished Name (DN) of the recipient instead of the standard SMTP address. In order to accommodate this functionality, MEUs for all users will also need to be created on the Target domain, and they must contain X500 records which match the DN from the Source environment and also have an external email address of SourceY.com. The easiest way to “stamp” these MEUs with the proper X500 record is using powershell, but the syntax will depend on the DN format in the Source domain. Essentially these MEUs are used to translate the DN back into a SMTP email address so that it can be properly routed using either a send connector to the Source domain or via MX records. Either way will work, however the use of a send connector will improve mailflow efficiency.With MEUs created on both sides, mailflow coexistence should be functional. Here is a mailflow matrix which can be used to test all possible cross-forest mailflow scenarios.
In part 3 of this carve-out migration guide, I will be discussing the permissions and access requirements of the selected migration tools and how to best approach these requests with the Parent organization.