Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Plan and Execute an Active Directory Merger, Part 2
When your prep work is done, let the migration begin
Eric B. Rux
November 9, 2009
14 Min Read
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:
Log on to the dedicated migration server created in Part 1 and open ADMT.
Right-click Active Directory Migration Tool and choose User Account Migration Wizard, as Figure 1 shows.
Enter the source and target domains. The domain controllers (DCs) you choose should have fast connections to each other.
Select the users from the domain. Because the user objects are copied, not moved, I suggest migrating the users in large groups or even all at once.
Select the target organizational unit (OU) that users will reside in on the new domain.
Migrate passwords. Note that the Password Export Server (PES) setup performed in Part 1 is required to migrate passwords. Also, ensure that the PES service is running on the source DC; this NT Service is set to Manual by default.
Set Target Account State to Target same as source. You can also choose to disable the accounts from the source domain if you want to prevent the users from logging on to the old domain.
Be sure to check the Migrate user SIDs to target domains check box. This is a very important step.
Enter the domain administrator and password for the source domain.
Select the Update user rights and Fix users' group memberships check boxes on the Group Options page of the wizard.
Don't exclude any properties on the Group Object page of the wizard—leave all check boxes cleared.
Don't migrate the source object if there's a conflict.
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:
Move the computer object in the Microsoft Management Console (MMC) AD Users and Computers snap-in to your special MigrationPrep OU, then reboot the PC. As you'll recall from Part 1, this procedure turns off the Windows Firewall and adds the appropriate users or groups to the Local Administrator Group.
Log on to the migration server and open ADMT.
Right-click Active Directory Migration Tool, and choose Computer Migration Wizard.
Enter the source and target domains.
Select the computers you want to migrate from the domain. I recommend migrating only one computer the first few times until you're comfortable with the process. In my experience, a team of two people can migrate a group of 30 computers in about an hour (assuming that the computers are close together). You'll have to experiment to see what works for you.
Select the target OU that the computers will reside in on the new domain. I create a MigratedPC OU to I keep track of these machines.
Don't select any of the check boxes on the Translate Objects screen. We'll translate the computer's security to the new domain in a separate step.
Leave the Replace checkbox selected for Security Translation Options. Click OK to open the User Rights Translate in Add Mode Only dialog box.
Choose a value for Minutes before computer restart after wizard completion. This setting gives users a warning before their computer is rebooted.
Don't exclude any properties on the Group Object wizard page—leave all check boxes cleared.
Don't migrate the source object if there's a conflict.
Click Finish.
Check for and resolve errors on the Migration Progress page by viewing the error log.
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.
In the Active Directory Migration Tool Agent Dialog, run the pre-check by clicking Start. The two most common reasons the pre-check fails are firewall and permissions problems.
If the pre-check passes, select Run pre-check and agent operation and click Start to add the computer to the new domain and reboot it. Be sure that you've communicated with your users so that you don't surprise them.
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:
Right-click ADMT, and choose Security Translation Wizard.
Choose Previously migrated objects.
Enter the source and target domains.
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.
Select the target OU under the new domain.
Leave all of the check boxes checked on the Translate Objects page of the wizard.
Select the Add option on the Security Translation Options wizard page.
Don't exclude any properties on the Group Object wizard page—leave all check boxes cleared.
Select the Do not migrate source object if there is a conflict check box.
Click Finish.
Wait for the Active Directory Migration Tool Agent Dialog window to open.
Choose one computer to migrate for testing purposes and run the pre-check by clicking Start. This can take a minute.
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 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:
Disable email forwarding and let the email queue up on the gateway.
Copy the mailboxes from the old Exchange server to the new organization.
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:
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.
Point the email gateway to the new server. Internet email now flows to the new server.
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.
About the Author
You May Also Like
