I recently worked on a project where a company was using an AD/Exchange hosting provider, and had purchased their own servers, and needed to port their users and mailboxes to a new AD forest. The catch? No software budget, so everything would need to be done with freely available software. The second catch? They wanted to migrate a test group first to make sure everything would work, so coexistence needed to be part of the plan. I've done Exchange migrations before, but they usually involved an upgrade from 5.5 to 2000/2003, or an acquisition where one company was being assimilated into another's infrastructure. This was a little different from those scenarios and presented some design challenges specific to this type of situation. Mainly, their primary email domain name would need to be in use in two separate Exchange organizations.
When I first started this project, I thought that surely someone else in the world had tackled this problem and would have made a nice post about it somewhere that I could just follow. As it turns out, that wasn't the case. There were pieces of the answer to be found in various places, but not all the issues seem to have been covered, and definitely in one place, so I just had to piece together all that I could, and fill in the rest of the blanks myself.
I started my research by reading a document on TechNet about deploying Exchange in a multiple forest environment, which provided a nice broad overview. At this point, I knew which tools I would be needing for this migration:
1. The Identity Integration Feature Pack - This is a free version of the Gal Sync module from Identity Integration Server. It allows you to keep two or more separate GALs in sync by creating contacts for users in one or more foreign Exchange organizations. There is also an update that needs to be installed to get some critical bug fixes. Also, if you've never used it before, Microsoft provides some scenarios, one of which is for Gal Sync, that walk you through setting it up and deploying it which are very helpful.
2. The Inter-Organizational Replication Tool - This is a free Exchange tool that will synchronize both Free/Busy data and Public Folder data between two Exchange organizations. One caveat, it will not carry over permissions, other than Default and Author, on Public Folders, those will all have to be recreated manually. If you were thinking about doing an audit of who has access to which Public Folders, a migration such as this is a great time to do it.
3. The Exchange Migration Wizard - This tool is included with Exchange and can copy the contents of a mailbox from a foreign mail system to a mailbox in its own Exchange organization.
4. The Active Directory Migration Tool - Another free tool from Microsoft. This tool will migrate users, passwords, groups, service accounts, and computers from one domain to another. It will also update profiles on workstations to allow users to log into the new domain while still keeping their old profile.
5. The Active Directory Account Cleanup Wizard - This tool is optional depending on whether you migrate mailboxes or users first. If you migrate users first, the Exchange Migration Wizard will attach the mailbox it is copying over to the migrated user account that it was associated with in the old domain. If you copy the mailboxes first, Exchange will create disabled user accounts to attach the mailboxes to. When you later migrate the users, there will be two user accounts for each actual user, the migrated account, and the disabled user account created by Exchange. This tool will search Active Directory, locate the accounts that refer to the same user, and merge them into one account.
I am not going to go into the minutia of installing, configuring, and using these tools, there are many existing documents that provide excellent instruction, including the help files that come with the tools. Just open up your favorite search engine and you'll be able to find more than enough documentation to get you going.
I decided a virtual version of this migration to do testing with would be a good idea, so using Virtual PC, I built two AD forests and installed all the tools, created some users and groups in the simulated hosting company forest, which I will refer to as ForestA. At this point, I had to figure out how I was going to go about sharing the SMTP namespace between ForestA and the new forest, which I will refer to as... you guessed it, ForestB. The problem is that only one forest can be authoritative for an SMTP domain.
For example, in this case, let's say that ForestA is authoritative for domain.com. UserA is in ForestA and UserB is in ForestB. ForestB can set up an SMTP connector (steps for creating that connector can be found here) pointing back to ForestA for delivering email to domain.com. Any email sent to an @domain.com address that doesn't resolve locally in ForestB will be forwarded to ForestA. So if UserB sends an email to UserA, Exchange will realize that email address does not exist locally and pass it off to ForestA, and UserA will get the email. However, if UserA tries to reply, since Exchange is authoritative for domain.com in ForestA, Exchange will look in its address table, realize that address doesn't exist, and return an NDR. UserB will never receive the email.
After doing some more searching I found this article detailing my problem. It lists two methods for achieving a shared SMTP namespace. Method 1 pretty much details the scenario I just described, which will work for emails inbound from the Internet, which is all they mention, but it will not work if users from the two forests need to email each other. Method 2 involves using contacts, which I'm going to have anyway, since I'm using the IIFP. It indicates that ForestB will need to have a unique domain name associated with it so that contacts in ForestA can be created with this unique domain name, at which point users in ForestA will be able to send email to ForestB. Setting up users in ForestB with a unique domain name simply involves changing the recipient policy to include a domain name that doesn't exist in ForestA and making ForestB authoritative for that domain. I chose migration.local. I set up ForestB with that domain name, migrated a user and his mailbox over, then ran the IIFP. A contact was created back in ForestA with the targetAddress of User@migration.local. Then once I set up forwarders in each Forest to point to the domain name of the other forest, users from ForestA and ForestB were able to send each other email with no issues.
That's all well and good, but what if User@migration.local wants to email someone out on the Internet? That brings us to tool number six, a tool that will rewrite email headers. That functionality is not included in Exchange 2003 and earlier out of the box, but Microsoft does provide an Address Rewrite Tool. (Exchange 2007 will have that feature built in.) However, the company already had a third-party SMTP relay program in use that had the ability to rewrite email headers, so we just used that instead. If you are not familiar with the concept, what happens on the SMTP relay server is that a rule is set up that examines the SMTP address of all outgoing email. If an email is found with an @migration.local address, the relay server changes it to an @domain.com address. That way, replies will come back to the sender instead of getting thrown in the bit bucket. Of course, you will also need to have @domain.com in the ForestB recipient policy so that users in ForestB will be able to receive the email that comes back from re-written SMTP headers, just make sure that @migration.local is the primary SMTP address.
Once that was up and working, there was only one item left to figure out: distribution groups, and how to keep them updated between domains. Once a user is migrated from ForestA to ForestB, a contact is created in ForestA to refer back to the user now in ForestB, but the IIFP does not place the contact in the distribution groups that the original user account was a member of, which causes the user not to receive any emails sent to any distribution groups that he was formerly a member of. I searched and searched and searched and I found a Usenet article describing my problem exactly. Unfortunately, that article did not have a solution associated with it, so it was of no help. After hours of searching, I came to the conclusion that this would have to be done manually, as no free tools seem exist for this issue. Fortunately, our test user group was only about 10 people, so manually putting their contact in the appropriate distribution groups was not a huge issue. However, if you are migrating more than a handful of people during the testing phase, or are doing the migration in small phases over a long period of time, I would highly recommend using a third-party migration suite, as many of them are able to keep users in their appropriate distribution groups during the migration process.
In the end, we ended up with users in ForestA having a primary SMTP address of domain.com and users in ForestB having a primary SMTP address of migration.local and a secondary SMTP address of domain.com. ForestB was authoritative for migration.local and ForestA was authoritative for domain.com. SMTP connectors were set up as described forwarding email from the non-authoritative forest to the authoritative forest. Email inbound from the Internet was delivered to ForestB, and in the event that the address was not in ForestB, the email was forwarded to ForestA for processing.
One last item which is not necessary, but is best practice and will keep your logs from filling up with errors, is to set up SMTP authentication between the two forests. Instructions for that process can be found here.