Understanding and Using the Microsoft Active Directory Migration Tool 2.0 (ADMT v2)

The Active Directory Migration Tool (ADMT) is an effective way to migrate users, groups, and computers from one domain to another. It is robust enough to migrate security permissions and Exchange mailbox domain settings, and it supports a rollback procedure in the event of migration problems. ADMT is composed of several components and functions:

• ADMT Migration Wizards ADMT includes a series of wizards, each specifically designed to migrate specific components. Different wizards exist for migrating Users, Groups, Computers, Service Accounts, and Trusts.

• Low Client Impact ADMT automatically installs a service on source clients , which negates the need to manually install client software for the migration. In addition, after the migration is complete, these services are automatically uninstalled .

• SIDHistory and Security Migrated Users will continue to maintain network access to file shares, applications, and other secured network services through migration of the SIDHistory attributes to the new domain. This preserves the extensive security structure of the source domain.

• Test Migrations and Rollback Functionality An extremely useful feature in ADMT v2 is the ability to run a mock migration scenario with each migration wizard. This helps identify any issues that might exist prior to the actual migration work. In addition to this functionality, the most recently performed user , computer, or group migration can be "undone," providing rollback in the event of migration problems.

ADMT v2 installs very easily, but requires knowledge of the various wizards to properly use. In addition, a best-practice process should be used when migrating from one domain to another.

The migration example illustrated in the following sections describes the most common use of the ADMT, an inter-forest migration of domain users, groups, and computers into another domain. This procedure is by no means exclusive, and many other migration techniques can be used to achieve proper results. Matching the capabilities of ADMT with the migration needs of an organization are important.

Deploying ADMT in the Lab

ADMT v2 comes with unprecedented rollback capabilities. Not only can each wizard be tested first, the last wizard transaction can also be rolled back in the event of problems. In addition to this, however, you should reproduce an environment in a lab setting and test a migration in advance, to mitigate potential problems that might arise.

The most effective lab can be created by creating new domain controllers in the source and target domains, and then physically segregating them into a lab network, where they cannot contact the production domain environment. The Operations Master (OM) roles for each domain can then be seized for each domain using the ntdsutil utility, which creates exact replicas of all user, group, and computer accounts that can be tested with the ADMT.

Installing and Configuring ADMT

The installation of the ADMT component should be accomplished on a domain controller in the target domain to which the accounts will be migrated. To install, follow these steps:

1. Insert the Windows Server 2003 CD into the CD drive of a domain controller in the TARGET domain.

2. Select Start, Run, type X :\i386\admt\admigration.msi (where X: is the CD drive), and press Enter.

3. At the welcome screen, click Next to continue, as illustrated in Figure 14.3.

   Figure 14.3. Installing ADMT v2.

   

4. Accept the EULA and click Next to continue.

5. Accept the default installation path and click Next to continue.

6. When ready to begin the installation, click Next at the next screen.

7. After installation, click Finish to end the Wizard.

Domain Migration Prerequisites

As previously mentioned, the most important prerequisite for migration with ADMT is lab verification. Testing as many aspects of a migration as possible helps establish the procedures required and identify potential problems before the procedures are done in the production environment.

There are several functional prerequisites that must be accomplished before the ADMT can function properly. Many of these requirements revolve around the migration of passwords and security objects, and are critical for this functionality.

Creating Two-Way Trusts Between Source and Target Domains

The source domain and the target domains must be able to communicate with each other and share security credentials. Consequently, it is important to establish trusts between the two domains before the ADMT can be run.

Assigning Proper Permissions on Source Domain and Source Domain Workstations

The account that will run the ADMT in the target domain must be added into the Builtin\Administrators group in the source domain. In addition, each workstation must include this user as a member of the local administrators group for the computer migration services to be able to function properly. Domain group changes can be easily accomplished, but a large workstation group change must be scripted, or manually accomplished, prior to migration.

Creating a Target OU Structure

The destination for user accounts from the source domain must be designated at several points during the ADMT migration process. Establishing an OU for the source domain accounts can help simplify and logically organize the new objects. These objects can be moved to other OUs after the migration and this OU can be collapsed , if desired.

Modifying Default Domain Policy on Target Domain

Unlike previous versions of Windows Operating Systems, Windows Server 2003 does not support anonymous users authenticating as the Everyone group. This functionality was designed to increase security. However, for ADMT to be able to migrate the accounts, this must be disabled. After the process is complete, the policies can be reset to the default levels. To change the policies, follow this procedure:

1. Open the Domain Security Policy (Start, All Programs, Administrative Tools, Domain Security Policy).

2. Navigate to Console Root, Default Domain Policy, Windows Settings, Security Settings, Local Policies, Security Options.

3. Double-click on Network access: Let Everyone permissions apply to anonymous users.

4. Check Define this policy setting and choose Enabled, as indicated in Figure 14.4. Click OK to finish.

   Figure 14.4. Allowing Anonymous Access for ADMT.

   

5. Repeat the procedure for the Domain Controller Security Policy Snap-In.

Exporting Password Key Information

If current passwords will be migrated, a 128-bit encrypted password key from the target domain should be installed on a server in the source domain. This key allows the migration of password and SIDHistory information from one domain to the next.

To create this key, perform the following procedure from the command prompt of a domain controller in the target domain where ADMT was installed:

1. Insert a floppy disk into the drive to store the key (the key can be directed to the network but, for security reasons, is better off directed to a floppy).

2. Change to the ADMT directory by typing cd program files\active directory migration tool and pressing Enter.

3. Type admt key SOURCEDOMAINNAME a: password and press Enter (where SOURCEDOMAINNAME is the NetBIOS name of the source domain, a: is the destination drive for the key, and password is a password that is used to secure the key). Refer to Figure 14.5 for an example.

   Figure 14.5. Creating a password export key.

   

4. Upon successful creation of the key, remove the floppy disk and keep it in a safe place.

Installing Password Migration DLL on Source Domain

A special Password Migration DLL should be installed on a domain controller in the source domain. This machine will become the Password Export Server for the source domain. The following procedure outlines this installation:

1. Insert the floppy disk with the exported key from the target domain into the disk drive of the server.

2. Insert the Windows Server 2003 CD into the CD drive of the domain controller in the source domain where the Registry change was enacted.

3. Start the Password Migration Utility by selecting Start, Run, and typing X :\i386\ADMT\Pwdmig\Pwdmig.exe (where X: is the drive letter for the CD).

4. At the welcome screen, click Next.

5. Enter the location of the key that was created on the target domain; normally this will be the A: drive, as indicated in Figure 14.6. Click Next to continue.

   Figure 14.6. Accessing the password export key.

   

6. Enter the password twice that was set on the target domain and click Next.

7. At the Verification page, click Next to continue.

8. Click Finish after the installation is complete.

9. The system must be restarted; click Yes when prompted to automatically restart. Upon restart, the proper settings will be in place to make this server a Password Export Server.

Setting Proper Registry Permissions on the Source Domain

The installation of the proper components creates special Registry keys, but leaves them disabled by default, for security reasons. A specific Registry key should be enabled to allow passwords to be exported from the Password Export Server. The following procedure outlines the use of the Registry Editor to perform this function:

1. On a domain controller in the source domain, open Registry Editor (Start, Run, Regedit).

2. Navigate to

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa  

3. Double-click on the AllowPasswordExport DWORD value.

4. Change the properties from to 1 - Hexadecimal .

5. Click OK and close Registry Editor.

6. Reboot the machine for the Registry changes to be enacted.

At this point in the ADMT process, all prerequisites have been satisfied and both source and target domains are prepared for the migration.