As I've discussed in previous columns, when performing a Windows 2000 migration, domain reconstruction often makes sense because many Win2K features eliminate the reasons that led you to create multiple domains under Windows NT 4.0. Usually, a restructuring project lets you perform domain consolidation (i.e., reduce the total number of domains in your environment). As one reader put it, domain consolidation has some definite advantages, but it can seem overwhelming when you consider what's involved.
Active Directory Migration Tool
To help make domain consolidation more manageable, Microsoft has provided some useful tools on the Win2K Server installation CD-ROM and at the Microsoft Web site. One tool, the Active Directory Migration Tool (ADMT), is a GUI- driven utility that lets you migrate users, groups, and computers from an NT 4.0 domain to a Win2K native mode target domain, to another Win2K forest, or to another Win2K domain in the same forest. It's useful for performing inter-forest and intra-forest migrations. ADMT's interface is straightforward, and its Help file is very comprehensive. Overall, ADMT is a great migration tool, especially considering that it’s free.
Let’s assume that you want to use ADMT to migrate user accounts from an NT 4.0 account domain to a Win2K forest. After selecting the accounts you want to migrate, you can run a test migration to identify any errors that might occur during an actual migration. This test run lets you address potential problems before they occur.
ADMT provides several options for controlling how you create users in Active Directory (AD): You can specify a target organizational unit (OU), determine how the system assigns passwords to new accounts, control how the system handles duplicate names, copy roaming profiles, and assign to user accounts the same rights they had under NT 4.0. To allow resource access, you can migrate the users’ existing SIDs to populate the SIDHistory attribute, which I discussed last week. In this scenario, you're not actually affecting the accounts in the source NT 4.0 domain; instead you're creating replicas of the accounts in the AD, which gives you ample time to perform testing and gives you something to revert to if you run into trouble.
Before you perform any restructuring, you must address certain requirements for the source and target domains. First, you have to establish an explicit trust between the two domains, and you must have administrative privileges on each. Also, the target domain must be in native mode, you must enable auditing in both source and target domains, and you must create a local group called domainname$$$ (where domainname is the name of the source domain) in the source domain. Finally, you must create the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\LsaTcpipClientSupport:REG_DWORD:0X1 on the source domain PDC. If you're using ADMT, it creates the local group, enables auditing, and makes the registry change for you.
In addition to ADMT, Microsoft provides some command-line tools that aren’t as easy to use but are useful in certain situations, especially if you need to script your migration. Clone Principals is a tool that lets you copy users from an NT 4.0 domain to a Win2K domain; Netdom is a tool that lets you manage trust relationships from a command prompt; and MoveTree is a command-line utility that lets you move AD objects between domains in the same forest.
If these tools don’t provide the functionality you need, you can turn to several third-party tools from companies such as NetIQ and FastLane (Mission Critical, which merged with NetIQ, licensed ADMT to Microsoft). If you have experience with any third-party migration tools, post your reactions, both good and bad, in response to this article.