Migrating Windows NT to Windows Server 2003 using the Active Directory Migration Tool

Microsoft first introduced the Active Directory Migration Tool (ADMT) as a way to migrate from Windows NT to Window 2000. Since shipping Windows Server 2003, Microsoft has made some changes to the program. Here's how you can use ADMT to easily migrate from Windows NT to Windows Server 2003.

Before you begin
ADMT will also work for migrating from Windows 2000 to Windows Server 2003. The reason I'm using Windows NT is because most of the time, if a company already has Windows 2000 in place, it's easier for them to do an in-place upgrade than a migration.

Before you jump into the actual migration, you should understand some of the prep work that's required. You can theoretically jump in and use ADMT with minimal preparation. However, doing so almost guarantees that you'll get a lot of migration errors. ADMT is a very finicky tool and unless you adequately prepare both systems, you'll get a lot more frustration than results.

Obviously, there are as many migration scenarios as there are different kinds of networks in the world. For the purposes of this article, I'm going to assume that you have a Windows NT domain and a Windows Server 2003 domain already in place, and that you want to migrate user accounts, groups, computers, etc. from the Windows NT domain to the Windows Server 2003 domain. If by chance you do have a Windows 2000 domain that you want to migrate into a Windows 2003 domain, you can do so using nearly the same procedure, but it's usually easier to simply upgrade your server's operating systems than to try to migrate a domain.

With that said, the first thing you'll need to do is verify that your Windows 2003 domain is running the appropriate functional level. Unless the Windows 2003 domain is running a functional level of Windows 2000 Native or Windows 2003, the migration will fail.

After you've verified the functional level, I recommend taking some time to point all of the computers and servers involved toward a common set of WINS and DNS Servers. This may sound a little strange at first, but you must remember that Windows 2003 domains are completely dependant on DNS. Likewise, Windows NT domains are dependant on WINS.

Since you're migrating from Windows NT to Windows 2003, you'll need to ensure that all servers and workstations involved in the migration can access both WINS and DNS. After the migration completes, you can remove all of the WINS references from the domain controllers in your Windows 2003 domain. Of course, removing DNS references from the servers in the Windows NT domain isn't even an issue, since you're doing away with that domain by migrating it into an existing Windows 2003 domain. Rather than having to remove DNS references from those servers later on, you'll probably just reformat those servers and use them for something else.

Establishing a trust relationship
Now that you've verified that your Windows 2003 domain is set to the correct functional level and that name resolutions won't be a problem, the next step in the migration process is to establish a two-way trust relationship between the two domains.

As you probably expect, the migration process will not work unless this trust relationship is in place and functional. Therefore, before moving on, it's a good idea to test the trust relationship. The easiest way to do so is to create a test account in each domain. For example, you might create an account called NTTEST in the Windows NT domain and an account called 2003TEST in the Windows 2003 domain.

Once you have created these accounts, go to a machine that's a member of the Windows 2003 domain and try to log in as NTTEST. If you can log in, then at least one side of the trust relationship is working. Now, go to a machine that is a member of the Windows NT domain and log in as 2003Test. If that login works as well, then the trust relationship is functional and it's time to move on with the rest of the preparation work.

The prep work
Now that you've created a trust relationship between the two domains, you need to configure each domain so that the Domain Admins group from the other domain has administrative privileges. Although this is a simple operation, I'll take a moment to explain the process because the naming issues can be a bit tricky.

Start by logging into the Windows NT server and opening User Manager For Domains. Once the console is open, double-click the Administrators group and add the Domain Admins group from your Windows 2003 domain. As you do, keep in mind that Windows NT doesn't recognize Active Directory-style names. Therefore, if your Windows 2003 domain were named production.com, Windows NT wouldn't recognize the name production.com. Instead, it would refer to it by its NetBIOS name, Production.

In the Windows Server 2003 domain, adding the Domain Admins group from the Windows NT domain is pretty straightforward. There are no tricky naming issues to deal with.

The next step in the preparation for migration is to enable auditing within both domains. ADMT offers several different migration status reports. Much of the information used in these reports comes directly from the audit logs of both domains. Therefore, if you don't enable auditing or don't audit the correct things, the migration process might work, but you may have a tough time determining which objects were actually migrated.

Within the Windows NT domain, you'll want to enable success and failure auditing for User and Group management. This can be done through User Manager For Domains. In the Windows Server 2003 domain, you'll need to modify the Default Domain Controller Policy. Once you have opened the group policy editor with the default Domain Controller Security policy loaded, navigate to Security Settings | Local Policies | Audit Policy.

When you select Audit Policy, you'll see a list of the various auditing options in the column to the right. Double-click on Audit Account Management, and you'll see the Audit Account Management Properties dialog box. Select all of the check boxes on this dialog box and click OK. This will enable account management auditing.

Now that you have enabled auditing, there is a permission that needs to be loosened while you're in the Default Domain Controller Security console. Navigate to Security Settings | Local Policies | Security Options. Within the Security Options container you'll find numerous policies, most of which are not enabled. Locate a policy named Network Access: Let Everyone Permissions Apply To Anonymous Users.

This policy is undefined by default. Double-click the policy to reveal the Network Access: Let Everyone Permission Apply To Anonymous dialog box. Within the dialog box select the Define This Policy Setting check box, then select the Enabled button and click OK. You may now close the Default Domain Controller Security Settings dialog box.

Now that you have granted anonymous users the same access as the Everyone group has, you must give everyone access to the local group Pre-Windows 2000 Compatible Access. The easiest way to accomplish this is to open a Command Prompt window and enter the following command:

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

Upon entering this command, you should get a message indicating that the command has completed successfully.

Installing the Active Directory Migration Tool
Most of the prep work is now done and it's time to install the Active Directory Migration tool. To do so, create a folder named ADMT on your Windows 2003 Server. Next, insert your Windows Server 2003 installation CD and navigate to \I386\ADMT. Once in ADMT folder, double-click the ADMIGRATION.MSI file. Doing so will launch the installation program for ADMT. The installer asks all of the usual questions, including a question about where ADMT should be installed. When the installer asks you for the installation path, enter the ADMT folder that you created in the previous step.

ADMT and passwords
If you ever used the version of ADMT that came with Windows 2000, you know that the previous version wouldn't allow you to migrate passwords from one domain to the next. The Windows 2003 version of ADMT will allow you to migrate user passwords, but doing so takes some work. Before ADMT will be able to migrate passwords, you'll have to create a password encryption file on your Windows 2003 Server and then copy that file to the Windows NT Server. Unfortunately, there is no option in the GUI for creating a password encryption file, so you'll have to create it from the command line.

Earlier you created a folder called ADMT and installed the ADMT software into it. Begin by opening a command prompt window and navigating to the ADMT folder. After doing so, you'll have to enter the ADMT command followed by some parameters that tell ADMT how to create the password encryption file. The parameters include the word KEY, the name of the Windows NT domain, and the file's destination. The syntax is as follows:

ADMT KEY

I personally like sending the password encryption file to a floppy disk because doing so makes it very easy to copy the password encryption file to a Windows NT Server. If your Windows NT domain was named OLD_NT and you were sending the password encryption file to a floppy disk, then the command that you would enter is:

ADMT KEY OLD_NT A:

Now that you've created the password encryption file, remove the Windows Server 2003 installation CD from the Windows 2003 Server and insert it into the Windows NT Server. Now, reboot your Windows 2003 Server. The reboot is extremely important because the rest of the process will not work if you don't reboot.

While the Windows 2003 Server is rebooting, go to your Windows NT Server, which should now contain the Windows 2003 installation CD. Insert the floppy disk containing the password encryption file. Now, navigate to the CD's \I386\ADMT\PWDMIG folder. Double-click the PWDMIG.EXE file. This will launch the Password Migration DLL Installation Wizard. The Wizard will automatically detect the password encryption file that's stored on the floppy disk. Click Next a couple of times, followed by Finish, and the necessary DLL files will be copied to your Windows NT Server. The Wizard will prompt you to reboot the NT Server, but don't reboot just yet. You need to make a minor change to the server's registry first.

Keep in mind that modifying the registry incorrectly can destroy Windows and/or your applications. Therefore, it's a good idea to backup the server prior to modifying the registry. Open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA.

In the LSA container you should see a registry key called AllowPasswordExport. This key has a default value of 0, but you'll need to change the key's value to 1 to enable password exports. While you're in the LSA container, you'll also need to create a new registry key called TcpipClientSupport. This new key should be a REG_DWORD, and should be assigned a value of 1. After creating this registry key, close the registry editor, remove the Windows Server 2003 installation CD and the password encryption key disk, and reboot the NT Server.

Performing the migration
Now that you have done all of the preparation work, it's time for the actual migration. As you may recall, you installed ADMT earlier. You can access it by going to your Windows 2003 Server, and selecting the Active Directory Migration Tool command from the Administrative Tools menu.

When ADMT console opens, you may be surprised by how empty it is. There is nothing except for an Active Directory Migration Tool container that contains an empty Reports container. However, if you right-click the Active Directory Migration Tool container, you'll see a shortcut menu with lots of migration options. Each of these migration options uses its own separate wizard.

Space doesn't permit me to discuss each of the migration options in detail. Even so, the wizards are pretty self-explanatory and there is help available if you get stuck. One thing that I do want to mention, though, is that any time you begin a migration, ADMT gives you the option of either performing a test migration or a real migration. As I explained in the beginning of this article, ADMT is finicky and if you haven't done the prep work exactly right (and sometimes even if you have), things will go wrong. Since ADMT's behavior tends to be a bit unpredictable, I strongly recommend performing a test migration prior to trying to migrate anything for real.

SID histories
I'd be negligent if I didn't tell you about how ADMT uses SID histories. Anytime that you migrate a user group or anything other than a computer object, there will come a point about half way through the migration wizard in which you'll see a screen similar to the one shown in Figure E. You'll notice in the figure that there is an option to migrate SIDs to the target domain. Selecting this option is basically the same as telling ADMT to create a SID history for the object.

Although the process of creating new ACLs is fairly simple, there are a few tricks that you need to be aware of in order for it to work correctly. First, you cannot migrate the PDC from the old domain, so you need to copy any shared resources to a member server prior to the migration.

Second, when you migrate computer accounts or do anything that involves assigning new ACLs, you must do it from the PDC emulator in the Windows 2003 domain. Otherwise the process won't work.

Finally, when you are done you can use the Security Translation Wizard to update all ACLs of all migrated objects. This must be done prior to taking the old PDC offline.

TechRepublic originally published this article on 29 March 2004.