Plan and Execute an Active Directory Merger, Part 2

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 old\user permission will be changed to new\user. 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:

1. Right-click ADMT, and choose Security Translation Wizard.
2. Choose Previously migrated objects.
3. Enter the source and target domains.
4. Select the computers you just migrated from the new domain. If you created a MigratedPC OU for use in the prior step 6, they'll be easy to find.
5. Select the target OU under the new domain.
6. Leave all of the check boxes checked on the Translate Objects page of the wizard.
7. Select the Add option on the Security Translation Options wizard page.
8. Don't exclude any properties on the Group Object wizard page—leave all check boxes cleared.
9. Select the Do not migrate source object if there is a conflict check box.
10. Click Finish.
11. Wait for the Active Directory Migration Tool Agent Dialog window to open.
12. Choose one computer to migrate for testing purposes and run the pre-check by clicking Start. This can take a minute.
13. If the Pre-check passes, choose Run pre-check and agent operation, then click Start.

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 domain\user, 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:

1. Disable email forwarding and let the email queue up on the gateway.
2. Copy the mailboxes from the old Exchange server to the new organization.
3. Enable email forwarding and let email flow to the new email server.

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:

1. Copy the mailboxes from the old Exchange server to the new organization. Use a date range and copy email messages only from today. This step creates a mailbox in the destination email server and configures the user account for email.
2. Point the email gateway to the new server. Internet email now flows to the new server.
3. Run a second email migration, but this time don't specify a date range. This step brings the remaining messages over to the new server, skipping the duplicates.

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.