Migrating Windows NT Accounts to Active Directory

In this section, we migrate Windows NT accounts to Active Directory. The first tool we use is the Active Directory Migration Tool (ADMT), which migrates accounts from the Windows NT SAM to the Windows Server 2003 forest. Install the ADMT tool on the Windows Server 2003, and then run the tool on the server. ADMT installs its snap-in under the Administration Tools for the server.

To run the ADMT tool, open the snap-in and then right-click the Active Directory Migration Tool folder. Figure 15-3 shows the default options. We’ll discuss the User Account Migration Wizard option in detail.

Figure 15-3: Default set of wizard choices in ADMT.

When you run the wizard, the first page asks whether you want to do the migration or just perform a test. Select the test option (Figure 15-4) and then click Next. You want to perform a test first to ensure that enough trial migrations are run to eliminate any problems before performing the actual migration.

Figure 15-4: Selecting the test option in the User Migration Account Wizard.

The Domain Selection page (Figure 15-5) appears next. This is where you select the source and target domains to perform the migration. This is also where this tool starts to shine. Until now, we’ve done very little (if any) prepping of either domain for the migration. A helpful aspect of this tool is that it will not run until both domains are adequately prepped and ready for a migration and, if necessary, the tool itself will perform the necessary configuration changes to prep each domain. When we click Next on the Domain Selection page, ADMT performs an internal audit of both domains and informs us that our Windows Server 2003 target domain (Trainsbydave) is not in native mode. Before you can migrate user accounts from Windows NT to Active Directory, your Active Directory domain will need to be in native mode.

Figure 15-5: Domain Selection page in the User Account Migration Wizard.

After you switch your Windows Server 2003 domain into native mode, you encounter the User Selection page. On the User Selection page, click the Add button to bring up the Select Users dialog box (Figure 15-6). In the Select Users dialog box, you can select the object type, source location, and names to migrate.

Figure 15-6: Entering source domain names manually on the User Selection page.

To display the source domain names, you can either enter them manually or click the Advanced button and the Find Now button (Figure 15-7), and then select the names for inclusion in the test migration.

Figure 15-7: Using the Find Now button to gather the user accounts from the Trains domain.

After you select the accounts, they appear in the User Selection page. Click Next to move to the Organizational Unit Selection page (Figure 15-8). Browse to select the target organizational unit (OU) named Employees, and then click Next.

Figure 15-8: Selecting the target organizational unit.

The next page is the Password Options page (Figure 15-9). This is where ADMT really shines. Notice in Figure 15-9 that you can select to have new passwords assigned to the migrated accounts, or you can migrate the account passwords, which eases your work because you don’t have to communicate new passwords to each of your users. For account passwords to migrate, you will need to do the following:

Figure 15-9: Options for migrating passwords.

• Change the Default Domain Controllers Policy to enable the Let Everyone permission to apply to anonymous users.

• Add the Everyone security group to the built-in group Pre-Windows 2000 Compatibility Access security group.

• Verify that the passwords of the source domain user accounts match the password policy of the target domain.

• Save the password file encryption key in the directory in which ADMT is installed using this syntax: admt key sourcedomainname driveletterandpath [password]. The password file that is created is randomly named with a .PES extension.

• In the source domain, run the pwdmig.exe tool, which is found on the Windows Server 2003 server CD in the \i386\admt directory. After installing this tool on your Windows NT PDC, reboot the server. You need the .PES file that you created earlier to get through this Password Migration Wizard.

• On the export server in the source domain, change the parameter of the HKLM/System/CurrentControlSet/Control/Lsa key from 0 to 1 for the AllowPasswordExport (REG_DWORD) value.

After completing each of the preceding steps, choose to migrate all the passwords. Then click Next.

The Account Transition Options page (Figure 15-10) appears next. On this page, you can configure the target account state (as enabled or disabled, or make it the same as the source account), configure the disabling values on the source account, and/or migrate the source account SIDs.

Figure 15-10: Configuring account information.

When the SIDs are migrated, they do not become the primary SIDs on the new account in Active Directory. Instead, a new SID is created when the new account is created, and the Windows NT SID is added to the SID History attribute of the account. This SID is still used to help build the user’s access token, but it is not the primary SID on the new user account.

Migrating the SIDs is important for a couple of reasons. First, if your users will be authenticating in the next Windows Server 2003 domain but need access to resources in your Windows NT domain, migrating the SIDs enables them to access resources in the Windows NT domain, without additional configuration or administrative effort on your part, while being authenticated in your Windows Server 2003 domain. Second, if the users will be authenticating in the Windows Server 2003 domain and still use their Exchange 5.5 mailbox for a period of time, migrating the SIDs will make this configuration seamless and transparent to them. We advise migrating the SIDs of each account unless you have a specific reason not to.

In our example, choose to enable the target accounts so that your users start authenticating in the target domain right away. Also choose to expire the Windows NT accounts after 60 days so that your users can use their old accounts if necessary during the transition period. Also migrate the SIDs.

When you click Next in the Account Transition Options page, ADMT initiates a further audit of both the target and source domains. Because we have done very little prepping of either domain, ADMT notifies you of the following and offers to make these configuration changes for you:

• Auditing in the source and target domains must be enabled to migrate the SIDs.

• A local security group called domainname$$$ must exist in the source domain to migrate the SIDs. ADMT will create this group.

• Addition of the TcpipClientSupport registry key in the source domain. Again, SIDs will not be migrated without this registry key.

After you allow these configuration changes to be implemented by ADMT, the wizard will want to reboot the PDC. Be sure you reboot.

The next page is the User Account page (Figure 15-11). This page needs to be populated with a user account that has administrative rights on the source domain. Enter the appropriate information and click Next. ADMT will validate this account, so if you entered incorrect information, you’ll be prompted to re- enter the data.

Figure 15-11: Entering a user account with proper administrative permissions.

The next page is the User Options page (Figure 15-12). This is where you can configure roaming profiles, update user rights, migrate user groups as well as the user accounts that the accounts are members of, and rename migrated accounts with a prefix or suffix. You have several options, some of which are obvious choices in certain scenarios.

Figure 15-12: Migrating user groups, profiles, and security settings.

For example, if most of your users use roaming profiles, select the check box to translate those roaming profiles into a Windows Server 2003 platform version. The Fix Users’ Group Memberships option adds migrated user accounts to a target domain group if those users were members of that group when their accounts were in the source domain. A way to ensure that users don’t lose their group memberships is to select the Migrate Associated User Groups option, which migrates the groups that migrated user accounts belong to. This option should be used to maintain the group membership information in the target domain.

When you click Next in the User Options page, you’ll be presented with the Naming Conflicts page, shown in Figure 15-13. You have three choices: ignore conflicting accounts, replace conflicting accounts, or append a prefix or suffix to conflicting accounts. What you are really doing is telling ADMT how to handle a migrated account if that account already exists in Active Directory.

Figure 15-13: Choosing how to handle conflicting accounts.

You might wonder why an account would be pre-existing. If, for example, we used the Active Directory Connector before running ADMT, the ADC would have created disabled user accounts in Active Directory. When ADMT was run to migrate the same account, we would have a duplicate or conflicting account already existing in Active Directory.

If you want to know which accounts are in conflict, rename your accounts with a prefix of “aaa” so that they are listed first in the preview pane of Active Directory Users and Computers (ADUC). In our example, let’s rename conflicting accounts by adding the “aaa” prefix to them even though we don’t expect any conflicting accounts.

Click Next to display the Finish page. Click the Finish button to begin the migration. During the migration, a status box appears (Figure 15-14) that identifies the number of users, groups, and computers that were migrated. When the migration is over, the Status line displays Completed. Now you’re ready to move on to the next phase of the migration.

Figure 15-14: Reviewing the status of the migration.

Because we experienced no errors in our test migration, let’s migrate the user accounts to Active Directory. You can see in Figure 15-15 that these accounts now exist in Active Directory in the Employees OU. (To learn how to manage duplicate accounts, see the “Managing Duplicate Accounts” section later in this chapter.)

Figure 15-15: Migrating accounts in the Employee organizational unit.