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:

1. Log on to the dedicated migration server created in Part 1 and open ADMT.
2. Right-click Active Directory Migration Tool and choose User Account Migration Wizard, as Figure 1 shows.

   

3. Enter the source and target domains. The domain controllers (DCs) you choose should have fast connections to each other.
4. 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.
5. Select the target organizational unit (OU) that users will reside in on the new domain.
6. 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.
7. 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.
8. Be sure to check the Migrate user SIDs to target domains check box. This is a very important step.
9. Enter the domain administrator and password for the source domain.
10. Select the Update user rights and Fix users' group memberships check boxes on the Group Options page of the wizard.
11. Don't exclude any properties on the Group Object page of the wizard—leave all check boxes cleared.
12. 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:

1. 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.
2. Log on to the migration server and open ADMT.
3. Right-click Active Directory Migration Tool, and choose Computer Migration Wizard.
4. Enter the source and target domains.
5. 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.
6. 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.
7. 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.
8. Leave the Replace checkbox selected for Security Translation Options. Click OK to open the User Rights Translate in Add Mode Only dialog box.
9. Choose a value for Minutes before computer restart after wizard completion. This setting gives users a warning before their computer is rebooted.
10. Don't exclude any properties on the Group Object wizard page—leave all check boxes cleared.
11. Don't migrate the source object if there's a conflict.
12. Click Finish.
13. 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.

14. 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.
15. 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.