Cross-Forest Microsoft Exchange to Exchange email migrations are the most common type of email migration project that I encounter as a consultant. The usual type is a migration from an existing Exchange platform (2007 or 2010) to the latest, such as Exchange 2013. There are plentiful Microsoft white papers on this scenario, Microsoft tools, and 3rd Party Tools from Dell, and Binary Tree (to name a few).
This blog post concerns the corporate merger (or acquisition) event that triggers a cross-forest Exchange to Exchange email migration project. But with a twist. That twist is when users have a mailbox in the source, and also in the target Exchange environments. The Microsoft (and 3rd Party) tools do not cover this scenario, expecting only a source Exchange mailbox to deal with. These email migration projects can turn out to be the most complex ones.
Two Active Mailboxes = Problem
However, in the real world of email migration consulting this does happen. Company A buys Company B, and creates mailboxes for all staff from Company B within it’s email platform, just to keep the Human Resources department happy. Then the email migration project has to migrate the legacy Exchange mailboxes across from Company B to Company A, over a coexistence period, and not disrupt the business. Oh, and the business wants a common Global Address Book, no NDR emails, and Calendar Free Busy….
This presents a more complex scenario than any other email migration project, even one from Domino (or GroupWise) to Exchange 2013 or Office 365. Especially as a merger can also mean other related IT migration activities taking place, such as data migration and a new Windows Desktop to deploy. And don’t forget all the new requirements that appear during the course of the migration project.
The Source Exchange environment (Company B) will typically have Mail Contacts representing mailboxes from Company A – generated via EMS, powershell, or maybe FIM. The Target Exchange environment (Company A) is best setup with the pre-created Exchange mailboxes for Company B being hidden, with a forwarder to a Mail Contact. Again, the Mail Contact can be created via a powershell process, EMS, or FIM.
The Microsoft process for cross-forest Free Busy (for Trusted, or untrusted) can be used for this setup – follow the documented Microsoft process for this carefully.
The next part is the tricky bit. The user migration process. It is possible to use a combination of the Microsoft process (prepare-moverequest & new-moverequest) and powershell scripting (before and after the Microsoft steps), to migrate the mailboxes from Company B into Company A.
User Migration Process: Example Technical steps are as follows (for each user):
- Create a CSV input file containing key values for each user from the source and target domains. Examples are SAMAccountName, ContactAlias, ExchangeAlias
- Delete the Mail Contact from Company A (used to forward mail to mailbox in Company B), after storing the SMTP, X500 and legacyexchange DN values.
- Mail enable the AD user account in Company A (representing the user from Company B), and add back all the SMTP, X500 and legacyexchangeDN values.
- Feed the above into the Microsoft prepare-newmoverequest and new-moverequest EMS cmdlets. This will initiate a cross-forest mailbox move.
- The Source mailbox will become a Mail-Enabled User, and retain the SMTP, X500 and legacyexchangeDN values.
- Import the PST file back into the new mailbox in Company A
- Add back all the mail attributes from Step 1 back into the new mailbox in Company A.
The EMS code and powershell required to achieve the required outcome is not published here.
Exchange to Exchange Migration Consulting
However, if this will help your email migration project, then please get in touch to hire our consulting services to help. It is possible to make a robust, repeatable process for your Exchange to Exchange email migration, even with two active mailboxes. We have completed several such email migrations successfully.
