The Active Directory Migration Tool

AD gets an eraser

On March 2000, Microsoft released the Active Directory Migration Tool (ADMT—you'll find it at http://www.microsoft.com/windows2000/library/ planning/activedirectory/admt.asp). Third-party migration tools are richer in features, but ADMT is free and is a must for anyone trying to design an Active Directory (AD) structure. The tool is only about a 2.5MB download, which you can obtain quickly—even if you don't have access to a Digital Subscriber Line (DSL) or cable modem.

AD is a pretty good offering, but it requires you to do a lot of designing and planning. And you'd better implement your plan right the first time because undoing things in AD is difficult—I often liken AD to a pencil without an eraser.

Now, ADMT serves as AD's eraser. ADMT mainly moves user accounts and similar information en masse from an existing Windows 2000 or Windows NT 4.0 domain into an existing Win2K domain. Being able to move accounts and related information from one domain to another is the key to domain consolidation.

The World Before ADMT
Suppose you have two NT 4.0 domains—FIRST and SECOND—that contain several thousand users (not to mention machine accounts), and some higher-up tells you to combine those two domains into one larger domain named ALLFOLKS. You'd have to recreate the FIRST and SECOND user accounts in ALLFOLKS. Now and then, you'd find that FIRST contained a user account whose name also appeared in SECOND, resulting in a collision. If both domains contain a johnsmith, one of those users will have to become johnsmith01 or some other variation.

How would you recreate all those user accounts? You could type them in one at a time or use a command-line tool such as the Adduser utility in the Microsoft Windows NT 4.0 Resource Kit. But Adduser isn't good at handling name collisions. Suppose further that ALLFOLKS is a Win2K domain, and you want to put all of the FIRST users in one organizational unit (OU) and the SECOND folks in another OU. Adduser won't help with that task either, but ADMT will.

A Timesaver
If you have ADMT, you can use it to copy the user accounts from the source domains (FIRST and SECOND) to the target domain (ALLFOLKS). To transfer the accounts, you first install ADMT. The Help file says you should install ADMT only on a Win2K domain controller in the target domain. However, I've successfully migrated user accounts while running ADMT on a Win2K Pro machine in the target domain. One restriction you must abide by, however, is that the target domain must be a native-mode Win2K domain.

Next, you'll need administrative powers in both the target and source domains. But ADMT is pickier than older cross-domain tools are. For example, if you used Netdom to move machine accounts from FIRST to ALLFOLKS, you could log on to an ALLFOLKS machine as an ALLFOLKS administrator. Then, to establish that you're simultaneously a FIRST administrator, you could execute a Net Use command to some resource on a FIRST domain controller.

ADMT, however, requires that you create a trust from ALLFOLKS to FIRST and another trust from FIRST to ALLFOLKS, then include your ALLFOLKS administrative account in the FIRST domain controllers' local Administrators group. I've found that many functions won't work on member servers in the source domain unless I take the extra step of placing the target domain's Domain Admins group into the member server's local Administrators group.

ADMT starts out in a standard Microsoft Management Console (MMC) window, but all of ADMT's tasks work as wizards and are pretty self-explanatory. The User Migration Wizard tells ADMT to copy user accounts to the target domain. Try this task (space prevents me from walking you through it), and you'll notice a few things.

First, ADMT has a test mode. In test mode, ADMT runs through the User Migration Wizard, doing everything except actually writing out the user accounts.

Second, although ADMT calls itself a migration tool, it's more of a "gradual account movement" tool. What I mean is this: ADMT doesn't move the user accounts from FIRST to ALLFOLKS—it copies them. The difference is significant. After you use ADMT, every user has both an old FIRST account and a new ALLFOLKS account. So, if you realize a couple of weeks later that something has gone terribly awry, you can just tell users to log on with their old accounts.

Third, apparently ADMT can't copy passwords when it copies user accounts. Instead, it must assign initial passwords to the new user accounts in the target domain. Users must log on with those passwords the first time, then immediately change them. ADMT lets you choose to either set the initial password equal to the username or have ADMT create a complex password for the new user account. ADMT then stores the new passwords in a text file, from which you can retrieve them and pass them on to the users.

After Moving Accounts
Now that you've copied the user accounts from FIRST and SECOND to ALLFOLKS, you want to take my suggestion and make the move a nice, gradual one that you can easily back out of if necessary. After the users have their new accounts, you'll need to tell the appropriate file and print servers about the new accounts. For example, you might have a large share on a server in FIRST that the people with user accounts in FIRST can get to, but you also want those users' new ALLFOLKS accounts to be able to access the old shares on FIRST. (Eventually, you'll move that share's server from the FIRST domain to the ALLFOLKS domain, so providing this accessibility is just an interim step.) In other words, if Oliver has a FIRST account that gives him read and write access to some share on a member server in FIRST and now he has an ALLFOLKS account, we want ADMT to tell that member server in FIRST to add Oliver's ALLFOLKS account to its share so that the ALLFOLKS account has read and write access to the share. ADMT uses the Security Translation Wizard to accomplish this task. This wizard can not only add the new target domain accounts to share permission lists but can also recreate user rights, NTFS permissions, user profiles, and local group memberships for the new ALLFOLKS account so that it has all the old account's abilities.

Consider how big a job it is to find all the share permissions, NTFS permissions, user rights, and the like that refer to Oliver's old FIRST account to be able to duplicate those attributes for his new ALLFOLKS account. Tracking down those attributes might be a slow process over the network, so ADMT remotely installs programs called agents to the servers that you direct ADMT to translate security settings for. In my experience, however, the process of remotely installing agents can cause a bit of trouble: My source domain's member servers often rejected ADMT's attempt to remotely install its agent unless I placed the target domain's Domain Admins group into the source domain's local Administrators group. Then, the agent installed fine.

ADMT does much more than I have room to tell you about, but I've explained its basic functions. I urge anyone charged with a Win2K migration to download ADMT today and play around with it.