Active Directory Migration Tool 2.0

Microsoft released Active Directory Migration Tool (ADMT) 2.0 in conjunction with Windows Server 2003, and most of us associate the tool with migrating from one version of Windows to another. ADMT is, in fact, the tool of choice for large organizations that have migrated from earlier implementations of Windows to Windows 2003 or Windows 2000 Server. However, ADMT was designed to migrate an Active Directory (AD) schema from one forest to another whether or not a change in OSs is involved. ADMT supports not only migration from Windows NT 4.0 to AD but also interforest migration (i.e., consolidating domains that live in separate forests) and intraforest migration (i.e., migrating domains that are part of the same forest).

ADMT 2.0 has several new features, including a command-line interface and a slightly better interface for working with Microsoft Exchange Server. Additionally, ADMT 2.0 supports user-account password migration.

ADMT's role as a schema mover is important because after you implement an AD schema, you can't modify it directly. If you need to make a change, you must delete the structure and start from scratch, unless you use ADMT, which lets you migrate to a different schema without starting over.

That important point noted, I intend to demonstrate how to use ADMT 2.0 to migrate an NT 4.0 domain to Windows 2003. I created a simple virtual environment, then added an NT 4.0 source domain named IKDOM01 and a Windows 2003 target domain with the Fully Qualified Domain Name (FQDN) IKDOM2.ORG. ADMT must run on the target PDC. If the target directory is replicated, the selected server should also be the Operations Master for replication purposes (i.e., the server designated to hold the Flexible Single-Master Operation—FSMO—role).

ADMT 2.0 is compatible with both Windows 2003 and Win2K Server. You can download the tool at http://www.microsoft.com/downloads/details.aspx?familyid=788975b1-5849-4707-9817-8c9773c25c6c&displaylang=en. After downloading the admt2.exe file, extract its contents into a directory with a name such as ADMT. One of the extracted files, admigration.msi, installs ADMT on the selected server; by default, ADMT is installed in the system root in Program FilesActive Directory Migration Tool. After you've installed the tool, it's time to prepare the two domains for migration.

Preparing for Migration
Windows 2003 offers two modes of operation for AD: native and mixed. Windows 2003 offers some security features that earlier versions don't support. If your environment is controlled exclusively with Windows 2003, you can configure AD to run in native mode, which is more secure but isn't compatible with older DCs. Mixed, or compatibility, mode lets administrators run AD and NT 4.0 servers in a shared security environment but renders many of native mode's security enhancements unavailable. ADMT requires the new domain to run in native mode. If you aren't certain whether the new domain is using native mode, open a Microsoft Management Console (MMC) AD administration snap-in such as Active Directory Users and Computers and right-click the domain object. In the context menu, select Raise Functional Level if that option is available; otherwise, select All Tasks, Raise Functional Level. The resulting dialog box shows the domain's current functional level and lets you raise the level from compatibility to native mode. For more information about domain functional levels, see http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/standard/sag_levels.asp and the Microsoft article "HOW TO: Raise Domain and Forest Functional Levels in Windows Server 2003" (http://support.microsoft.com/?kbid=322692). Keep in mind that after you raise the level, you can't lower it.

Next, you need to create a two-way trust between the target and source domains. On the Windows 2003 system, open the MMC Active Directory Domains and Trusts console and right-click the target domain (IKDOM2.ORG) object. Select Properties from the context menu to open the Properties dialog box. On the Trusts tab, click New Trust to open the New Trust Wizard, which walks you through the steps of setting up the first half of your two-way trust with the NT 4.0 IKDOM01 domain.

To set up the second half of the trust (from the source domain to the target domain), on the NT 4.0 PDC for the IKDOM01 domain, open User Manager for Domains from the Administrative Tools menu. From the Policies menu, select the Trust Relationships option, then define a two-way trust relationship with the target domain. After modifying both domains, close the Active Directory Domains and Trusts console on the Windows 2003 PDC, but leave User Manager for Domains open on IKDOM01.

The next step is to ensure that the administrative user accounts that the migration process will use have rights in both domains. In User Manager for Domains, double-click the Administrators object under the IKDOM01 object, then add the administrators for the target domain (IKDOM2.ORGDomain Admins) to grant them permission on the source domain. The source domain configuration process has an option to create a group related to SID migration, but ADMT will automatically create this group on the source domain and name it after the domain (in my sample scenario, the name would be IKDOM01$$$). Close User Manager for Domains.

You must now set up administration privileges on the Windows 2003 domain. Open the Active Directory Users and Computers snap-in on the Windows 2003 system, and expand the Builtin node (which contains the server's local groups) under IKDOM2.ORG. In the local Administrators group, add the domain administrators from the source domain (IKDOM01Domain Admins).

The next step in preparing for the migration is to edit the registry for TCP/IP client support on the IKDOM01 PDC. Open a registry editor, go to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa subkey, and add TcpipClientSupport as a new DWORD entry. Ensure that the new entry's value is set to 1, then restart the IKDOM01 PDC.

You're now ready to begin migrating user-account information. On the Windows 2003 PDC, open the MMC Active Directory Migration Tool snap-in. When the tool's MMC console is displayed, it looks fairly sparse. There's an Active Directory Migration Tool node, a placeholder node for reports, and little else on the screen. ADMT is a wizard-powered tool; you use one of 11 wizards to initiate every action that ADMT performs. Right-click the Active Directory Migration Tool node to see the list of available wizards, as Figure 1 shows. The wizards are as follows:

Some of the wizards, such as the Trust Migration Wizard, let you select the source domain, then display one screen that acts like a dialog box. Other wizards, such as the User Account Migration Wizard, are more involved, but all use the same basic process.

User Account Migration
I'll step you through using the User Account Migration Wizard, which migrates user accounts. (Migrating passwords is a separate activity.) After you start the User Account Migration Wizard, you see a title screen. The next screen offers the option of running the User Account Migration Wizard in test mode. This option, which none of the other wizards offer, lets you configure all the settings associated with migrating your users, test the migration, and see a report that shows any potential problems. I recommend that you run the wizard in test mode so that you can iron out any problems with the user-account migration first, then perform the password-migration configuration steps (which I describe in the next section), then run the User Account Migration Wizard again to migrate both user accounts and passwords.

Next, the User Account Migration Wizard asks you to provide the source and target domains. Note that the wizard looks only for AD domains and doesn't include the NT 4.0 domain with which we established a trust in the drop-down box of available domains. You must type in the NT 4.0 domain name.

The next screen lets you select user accounts. Clicking Add on this screen opens a rather limited dialog box for selecting AD objects. If you don't want to type in each user name, click Advanced to see an expanded Select Users dialog box, which Figure 2 shows. Click Find Now to list all the accounts in the target domain. Unfortunately, you can't filter out built-in accounts such as Administrator and Guest, so you need to either avoid selecting these accounts or remove them from the list when you return to the wizard.

After you've selected the accounts to migrate, the next step is to verify the location in the target domain in which you want to create those accounts. The wizard displays the FQDN of the location, and you can edit the target organizational unit (OU) for the accounts.

After you've specified the location, the next screen, which Figure 3 shows, lets you specify how to handle user account passwords. The default option, Complex passwords, creates new, complex passwords based on a random character sequence. Alternatively, you can choose to create passwords that are the same as the account names. With either of these options, the wizard creates a history file that associates each user account with its new password, and you should ask users to change their passwords after they log on to the domain. The third alternative is to migrate user-account passwords from the source domain, although until you've performed the steps described in the next section of this article, the Migrate passwords option isn't truly available. If you select it and click Next, you'll see error messages. For now, accept the default setting and move to the next wizard screen.

The next screen presents account activation options, as Figure 4 shows. I recommend selecting the Target same as source option so that ADMT will create accounts in the target domain with the same activation status as they have in the source domain. This setting gives you some assurance that even if you accidentally migrate an unwanted and deactivated account, the account will remain deactivated. You can also choose to have ADMT automatically flag the source accounts for deactivation. This screen also gives you the option of migrating user-account SIDs. By default, when ADMT creates a user account in the target domain, AD assigns the new account a new SID and disconnects from the new account the user's privileges and limitations as defined in the source domain. Selecting the Migrate user SIDs to target domain option copies a source account's SID into a history associated with the new account. Windows then uses this historical value to tie the new account to the old account and let the user maintain the same privileges and limitations that he or she had in the source domain. Selecting this option also triggers certain audit requirements, which the wizard automatically enables on the source and target domains. Obviously, migrating SIDs makes sense if you want privileges in the target domain for the same groups that are defined in the source domain.

Choosing to migrate SIDs introduces an additional step in the process, in which the wizard asks you to provide valid administrator credentials for the source domain (IKDOM01). ADMT needs explicit credentials because accessing account SIDs is a privileged operation.

The next User Account Migration Wizard screen, which Figure 5 shows, lets you define other user options, including two important group-related options. Select the first option—Migrate associated user groups—to migrate, along with user accounts, custom groups defined in the source domain that you haven't defined in the target domain. You should also select the accompanying suboption—Update previously migrated objects—to let ADMT know that after it creates a custom group for the first migrated user that's a member of the group, it should update that group rather than create a new group when it migrates subsequent users in that group. ADMT will automatically maintain users' memberships in the custom groups; if you're also migrating SIDs, all permissions will remain unchanged.

The second group-related option is Fix users' group memberships, which assigns user accounts to the appropriate existing groups in the target domain based on their source domain membership. (Thus, fix in this case means to attach rather than to repair.) For example, if a user account belongs to the Domain Administrators group in IKDOM01, the new account will have membership in the Domain Administrators group in IKDOM2 after the migration. ADMT is smart enough to not create duplicates of such built-in groups (when migrating groups) and gives you the option of deciding whether such assignments should be automatically transferred.

The final screen asks you to define a default option for renaming any user accounts that duplicate existing accounts in the target domain. After you do so, click Finish to begin the migration or test migration process. During migration, a status window shows what the wizard has migrated and any errors that have occurred. The wizard also generates a log file that you can review at the end of the migration. This log file is available only until you close the wizard display. After you close the display, you'll have access only to ADMT-generated reports.

Password Migration
One of ADMT 2.0's more interesting features is its ability to migrate passwords. ADMT's password migration merits special attention because it requires additional settings on both the source and target DCs and a service running on the source domain. The service relies on a key, which the target domain supplies to the source domain, to encode and decode password information. Separating the password migration configuration process from the user-account migration configuration tends to result in fewer problems, and you can isolate those problems much more quickly.

Password migration configuration starts on the target DC. The first step is to extend the permissions associated with the target domain's Everyone group to include anonymous users. To do so, open the MMC Domain Security Policy snap-in. Expand Local Policies and Security Options to get the list of available security options. Enable the Network access: Let Everyone permissions apply to anonymous users option, as Figure 6 shows.

The next step is to generate a password key file on the target DC (IKDOM2, in our sample scenario). ADMT provides a command-line utility for generating this key; a sample key-generating command is

admt key ikdom01 C:test *

in which key specifies that you want to generate a key, ikdom01 specifies the source domain, C:test specifies the folder in which to create the key file, and * triggers a prompt to enter a password for the key file during the key-generation process. Figure 7 shows that the sample command created the key file C:test4A662TSJ.pes. Also at the command line on the target DC, type on one line

net localgroup  "Pre-Windows 2000  Compatible Access"  Everyone /Add

then restart the target DC.

Now turn your attention to the source domain. Although we used the IKDOM01 domain PDC as the source machine during user-account migration, Microsoft recommends using a production BDC as the password export server. You have less exposure if an error occurs, the BDC typically has unused cycles, and the configuration requires a reboot, which you might rather do on your BDC than your PDC. However, using a BDC isn't mandatory; you can install the necessary software on a PDC. You'll find the software in the pwdmig subfolder of the folder that the admt2.exe file created when you ran the file on the target DC. Copy the pwdmig folder and the key file you generated on the target DC to the source DC, then run the password export server installation file on the source DC. On an NT 4.0 system, you must run the pwdmigpwdmig.exe file to install the password export server (on a Windows 2003 or Win2K system, you need to run the pwdmigpwdmig.msi file).

The password export server installation will prompt you for the path to the *.pes key file. The installation will also prompt you for the password (if any) that you specified for this file. After the password export server is installed, you need to reboot the system, but first edit the registry on the source DC so that you need to reboot only once. Set the DWORD value AllowPasswordExport under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa registry subkey to 1 to enable password export. After changing this setting, reboot the source DC.

After the reboot, you can use the User Account Migration Wizard on the target DC to migrate passwords along with user accounts. I've found the password migration process to be error prone, so I recommend reviewing the Microsoft article "How to Troubleshoot Inter-Forest Password Migration with ADMTv2" (http://support.microsoft.com/?kbid=322981) for troubleshooting advice.

Going Forward with ADMT
You've seen how to work with ADMT 2.0 from its GUI and, to a lesser extent, its command-line interface. One new capability of version 2.0 that I haven't shown you how to use is its scripting interface. This interface doesn't just give you the ability to reference ADMT's command-line command set from within a script—it exposes an entire set of object interfaces that administrative scripts can reference. If you want to use ADMT in a script, start with the sample script that's installed with the tool. Templatescript.vbs lists the standard parameters for working with the various interfaces in addition to providing sample code that creates and manipulates the ADMT.Migration interface.

ADMT 2.0 is a robust tool that supports not only the transition from one version of Windows to a newer version but also the ongoing maintenance and consolidation of domains within your enterprise. By leveraging its enhanced capabilities for migrating directory objects, you can support changes to your production directory and the dynamic growth of your enterprise infrastructure. Future versions of ADMT will undoubtedly enhance the ability to consolidate and eventually perhaps even separate elements of your directory structure. ADMT will continue as an important tool in your AD maintenance toolkit.