Plan and Execute an Active Directory Merger, Part 2

Your company has just joined with another company, and suddenly you find yourself needing to combine your IT infrastructures. In "Plan and Execute an Active Directory Merger, Part 1," I described a scenario in which the smaller company's domain, Old.local, was being merged into the larger company's domain, New.local. You can follow the steps in that article to prepare for your migration. Now it's time to start merging the Active Directory (AD) and Exchange Server networks of the two companies.

Migrate the Users and PCs
If you've performed all the preparation outlined in Part 1, you should now be ready to migrate the AD objects from the Old.local domain to the New.local domain. It's important that you go slowly so that you have time to work through any problems that arise. When you're ready, start by moving yourself, then move on to the other users and computers in the IT department. If you start with yourself, you’ll be sure to have all of the kinks worked out before migrating the rest of the company.

The first time you attempt to migrate an object from one domain to the other, the Active Directory Migration Tool (ADMT) prompts you for some additional setup tasks that ADMT will take care of for you. Accept the pop-ups so that auditing will be turned on, and so that a special group, Domain$$$, can be created. After the first time you migrate an object, you won't be prompted for these actions again.

To migrate users, follow these steps:

The migration takes only a few seconds for each user object; when migration is complete, you get a report showing the number of objects that were examined and copied as well as any that had errors. After you migrate a few users, verify that the SID History attribute was populated correctly by viewing users' properties in ADSI Edit; you can see an example in Part 1.

After the users have been migrated, you can migrate their computers. Keep in mind that user migration copies data to the new domain but computer migration moves data to the new domain. For this reason, you need to plan the move to the new domain ahead of time and communicate it well with your users. It might be a good idea to briefly explain to them what you are doing. Give them a screen shot of how to log on to the new domain to ensure they log on to New.local.

Follow these steps to migrate machines to the new domain:

Up to this point, migrating computers is very similar to migrating users. However, after the computer object in AD has been copied to the new domain, there's one additional step to complete: The computer needs to be joined to the New.local domain. You can do this manually or you can let ADMT do it for you. After the objects have been copied, click Close on the Migration Progress window in ADMT, which will bring up the Active Directory Migration Tool Agent Dialog that lets you remotely add multiple computers to the new domain.

There's still one more process to run. Before users log on for the first time, run the Security Translation Wizard using ADMT. This wizard updates the security settings on the workstation; any file or folder that was assigned an olduser permission will be changed to newuser. Users' profiles are also translated to the New.local domain. If users log on to a computer before you run the security translation, a new profile is created and all of their settings are left in the old profile. If this happens, don't panic. Simply log on as a user with local administrator privileges, delete the new profile, then run the Security Translation Wizard.

Use the following steps to run the Security Translation Wizard:

After all users and their computers have been migrated to the new domain, you can perform the migration of the servers and any associated service accounts. This process is similar to migrating users and computers. ADMT has a Service Account Migration Wizard, but I found it easier to migrate the service accounts like typical users, then manually fix the NT services (e.g., SLQ Server service). If you have a lot of servers with service accounts, using the Service Account Migration Wizard might be worth your time.

Copy the Exchange Mailboxes
Unlike the users' computers and the back-office servers, you don't want to migrate your Exchange servers to the new domain. Modern versions of Exchange are deeply integrated with AD. If you migrated the Exchange organization to the New.local domain, there would be no way for you to connect the mailboxes in the mail store to the user objects in AD. Instead of migrating Exchange servers, you'll want to copy the individual mailboxes from the old Exchange organization to a new Exchange organization in the New.local domain.

Exchange 2003 and later have a built-in migration wizard that does a great job of copying multiple mailboxes from one Exchange organization to another—even if they're in different AD forests. Here's the simple procedure for copying from one Exchange 2003 organization to another Exchange 2003 organization:

1. Log on to an Exchange server in the New.local domain.

2. Click Start, Microsoft Exchange, Deployment, Migration Wizard.

3. Choose Migrate from Microsoft Exchange.

4. Choose the destination server and Information Store where you want the mailboxes to be migrated.

5. Clear the check box for Exchange 5.5 server, and enter the information for the source Exchange server. Note that you must enter the administrator account as domainuser, as Figure 2 shows.

6. Specify a date range (if applicable).

7. Choose one or more mailboxes that you want to migrate. You can select all, or select individual mailboxes by using the Ctrl key.

The mailboxes then start to copy from the old domain to the new one. Depending on the size of each user's mailbox, this process can take anywhere from a few minutes to a couple of hours (or even days). I've also noticed a big difference in a defragged Information Store versus a fragmented one. For example, if you take an empty mailbox and send 3,000 messages to it, it will migrate in just a few minutes. However, a well-used mailbox that has 3,000 messages that have been received over the past year will take significantly longer because the messages aren't contiguous (written one after the other) in the Information Store. Other factors such as system and network performance can also greatly affect the speed of the mailbox copy, so be sure to run a few tests with mailboxes so you'll have an idea of how long this process will take.

Prep and Go
Email is an essential part of business communications, so you'll want to be extra careful when you switch to the new email system. You might be able to kick users out of Outlook long enough to move the mailboxes, but you have no control of the email that will continue to flow to your email gateway. No matter what you do, external messages keep coming. I've seen two methods that work for swapping to the new system.

Queue method. The queue method works best for companies with few users and small Information Stores. Follow these steps to implement this method:

Prep Method. The prep method is best for companies with large Information Stores or with mail gateways that can't hold much email in queue. Here are the steps for this method:

Public Folders
As I mentioned in Part 1, you can use the Inter-Organization Replication tool to migrate public folders from one Exchange organization to another. Another option is to simply export each public folder to a PST, then import them into the new organization. Whichever method you choose, be sure to allow plenty of time because these migrations can be very slow. Identify which public folders you want to migrate early in the project, and don't put it off until the last minute.

Although messages in mailboxes copy over with little difficulty, the configuration of the SMTP addresses can be a bit more problematic. For example, if you have a shared calendar with a user called ITCalendar and a public folder called ITCalendar, one probably had an SMTP address of ITCalendar.old.com and the other was ITCalendar2.old.com. When you migrate these objects, whichever one gets migrated first gets the address without the number 2. If you migrate the public folder first and the user second, the user and the public folder will both have the wrong SMTP address. When you try to correct the address, Exchange informs you that the address you want is already in use. This situation will no doubt drive you nuts as you try to find where these addresses are used.

To find the rogue address and who or what is using it, use Active Directory Users and Computers to perform a custom search as follows: proxyAddresses=smtp: ITCalendar.new.com. Figure 3 shows an example of this custom search.

Point Outlook to the New Exchange Server
When you move Exchange mailboxes within an Exchange organization, Outlook and Exchange communicate in the background and the users' Outlook profiles are updated automatically. However, when you move mailboxes to a different Exchange organization, Outlook has no way of knowing where the mailboxes were moved to. This is where the Microsoft Exchange Server Exchange Profile Redirector (ExProfRe.exe) comes in. This free, handy utility helps fix your users' Outlook profiles via a logon script.

To use ExProfRe, create a Group Policy Object (GPO) with a logon script. Copy the ExProfRe.exe file to the GPO, and create a simple CMD script with the following command:

exprofre.exe /targetgc=NEWDC1
  /v /n /logfile=c:UpdateProfile.log 

Although the code breaks here for space, you would enter it all on one line. You can download ExProfRe from the Microsoft Download Center. In my experience, ExProfRe is very fast and can change a user's Outlook profile before the user starts Outlook—even if Outlook is in the Start Menu's Startup folder.

A Successful Ending Begins with Planning
A project of this size takes a lot of planning and practice in a lab environment. Document every hiccup that you come across, and write clear, how-to procedure documents that anyone in your IT department could follow. Many of the step-by-step guides in this article are from my own documentation, so I know they work. Set up a lab for yourself and write down everything that you learn. You'll find that a successful migration begins with excellent planning.