ADMT is designed to be a complete domain migration tool. In reality there are several shortcomings and a few quirks that require careful use.
Intraforest migrations move user and group objects. In other words, the object in the source domain is deleted. This happens without warning. This must happen in order to propagate sidhistory.
User and group migrations need to be planned carefully, because
a complete migration of a single user is dependent on migrating
all that user's groups. And to migrate the user's
groups, you must migrate all the users who are members of those groups. And so
on. In mathematical terms, you must migrate a closed
set of users and groups.
You can choose to migrate a user
or group in an incomplete manner. In other words, choose to not migrate the groups that a user belongs to. Or to not migrate
the users that are members of a group. If you are doing an interforest
migration, you can later choose to re-migrate the user
or group and fix the group memberships.
The documentation implies that a closed set is required. This isn't true. We discovered this in the midst of some of our initial ADMT usage. You can migrate users without migrating all their groups. However, the users would lose any domain global group memberships (global groups can only have users from the same domain). This can be circumvented by elevating all global groups to universal groups.
It's important to keep in mind that sidhistory is set for both users and groups. This means that full access is maintained for resources in both domains.
Passwords can be migrated. This requires an agent on one of source DCs. Alternately complex passwords are written to a log file.
Excerpt from the ADMT readme:
To set up your Password Export Server:
1. Create a key that protects the password list:
a. Run ADMT.exe from the command line using the key operation. The syntax for this command is ADMT.exe key Source_Domain_Name folder: [Password] (Type ADMT.exe key at the command line for more usage information).
b. Give the location of the key when prompted. Provide a matching password if one was given when you created the encryption key.
2. Check the value of the AllowPasswordExport registry entry (located in HKLM\ SYSTEM\CurrentControlSet\Control\Lsa on the PES). The value must be set to 1 to allow ADMT to use that PES for password migration. You can disable a PES from supporting password migration by setting the value to 0.
3. Add the Everyone system group to the “Pre-Windows 2000 Compatible Access” group on the target domain. If this is not done, ADMT will log an “Access Denied” error. To do this, use the Active Directory Users and Computers snap-in, or use the following syntax at the command prompt on a target domain controller:
NET LOCALGROUP "Pre-Windows 2000 Compatible Access" Everyone /ADD
4. In the Active Directory Users and Computers snap-in, verify permissions on the PES server object. The PES requires that the “Pre-Windows 2000 Compatible Access” group has “Read All Properties” rights on the following object:
CN=Server,CN=System,DC=<domain_name>
5. If you are running ADMT on a server running Windows Server 2003, add ANONYMOUS LOGON to the “Pre-Windows 2000 Compatible Access” group on the target domain. If this is not done, ADMT will log an “Access Denied” error. To do this, use the Active Directory Users and Computers snap-in, or use the following syntax at the command prompt on a target domain controller:
NET LOCALGROUP "Pre-Windows 2000 Compatible Access” ANONYMOUS
LOGON/ADD
Relevant KB article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;322981
Service account migration is a two step process.
First, you enumerate services with service accounts with the Service Account Migration wizard. You feed it computers to check, it adds service accounts and the location of the services with that service account to the ADMT database. It accomplishes this by sending an agent to the computer (this agent has the same problems as listed in the computer section below). By default, each service it finds is marked as included for later updates. This is good, unless you enumerate something you don't plan to migrate.
Second, you migrate the service account with the User Migration wizard, just as you would a normal user. However, for accounts that have a service enumerated, additional windows will prompt you whether to update the services that have been previously enumerated. An agent updates the service to run as the migrated account. The agent does not stop the service or restart it. This is good.
This process has a known bug: replication latency. The computer with the service on it won't accept the new account if it asks a DC that hasn't heard about the newly migrated account. And since the timing is so rapid there is a non-trivial number of times that this might happen. If you get an error during the agent part of the second step, then all is not lost. The account has been migrated. The services are all still running. You can even fix things up without manually touching all the boxes. First, force replication on the target domain's DCs. Then, run the Service Account Migration wizard again. Choose to 'use already gathered info'. Select the computers that failed in the list. Click the cryptic button labeled 'Update SCM'. This reruns the agent to update the account on the service. This is the same process you'd use if the computer was unreachable when you migrated the account.
Computer migration is dependent on user and group migrations. The key benefits of using ADMT for computer migration are reACLing and automation. Without user and group migration, the reACLing doesn't happen. In fact, the reACLing is dependent on the fact that you have migrated the users and groups with ADMT running on the same computer. ADMT uses an Access database to remember what it's done. You can copy the database to another computer if you need to use a different computer to migrate computers. Or you can hack the db, fooling the local copy of ADMT into thinking that it has migrated things that it hasn't.
The computer migration operation is a minefield of problems.
First, you must be running ADMT with an account that has domain admin privs in the source domain (i.e. local admin on the computers to be migrated ) and is a member of the administrators group in the target domain. Easiest thing to do is to add source\domain admins to target\administrators, then use your source DA account. Doing the converse won't work, w/o explicitly adding your target domain admin account to the source domain admins group. Any scripts or group policy that checks/removes members of domain admin and administrators needs to updated to reflect this.
ADMT copies the computer account (inter or intra forest), then deploys an agent to the computers. The agent installs itself as a service, and launches an process (admtagent.exe if I recall correctly). But …
ADMT zeroes in on the dnshostname attribute in order to locate the computer. And the dnshostname attribute is false most of the time. If there is no dnshostname attribute, then it tries netbios. In order for netbios resolution to work, the following must be true:
No firewalls between the ADMT computer and the destination computers. This includes SP2 firewalls.
The ADMT computer and the computers to be migrated must either be on the same network or share a WINS server.
File and printer sharing for MS networks must be enabled.
Netbios of TCP/IP must be enabled.
Deleting the dnshostname attribute just prior to migration, then forcing replication is the best course of action. Some actions on the computers can recreate the dnshostname attribute, so you want to delete the attribute as close to the migration time as possible. If the DNS name is correct and resolves, then no need to worry.
I found that using ldp.exe, with the modify operation, delete dnshostname attribute and just changing the DN of the target object was fairly quick for the Computer Training labs. But that was largely because the computer names (and the DN) only differed by a character or two. For a large migration, we'll want a script for this. There's also a hotfix that changes this behavior. But it still tries DNS resolution first, which would introduce a substantial delay into the agent deployment process as you wait for DNS resolution to fail. So I think the best option is to kill the attribute.
If you migrate a computer but the agent fails, then you'll have to re-check the dnshostname attribute. And you need to kill it on the destination computer accounts too. Experience shows that ADMT will use both the source and target dnshostname attribute. And make sure you choose the 'replace accounts with same name' option or the migration will fail because of the collision. But first you need to resolve whatever caused the agent to fail. Double-check the above issues, including replication. Check your local netbios/DNS cache and clear as necessary.
Agent errors can occur, but for the most part they are harmless. Sometimes a registry key can't be accessed for reACLing. Usually that's because something else has it open. Open user profiles are another common source of error. Good to have everyone logged out, or at least the primary user logged out. Occasionally, the agent fails to change the domain affliation with an access denied error. This is the only real error I've seen to worry about. In my experience, this error disappears on a subsequent migration attempt.
You can close the computer migration wizard prior to finish, but you get a double-negative dialog that is confusing. If you close it, you won't get any more status reports in the wizard, but the agents continue working. You can check that all finished OK by consulting logs on the remote computer.
ADMT has a command line version if you don't like the GUI. You can't do anything with the command line that you can't with the GUI. See the help file for syntax.
Cloneprincipal (CP) and Movetree (MT) are command line tools that are used to migrate security principals. CP is for interforest only. MT is for intraforest only. MT moves the object, deleting the source. Sidhistory is used in both cases. CP doesn't copy passwords, MT does. CP requires that you run it from the destination domain controller (W2k+).
Movetree use is discouraged by Microsoft in favor of ADMT.
For that matter, there isn't much reason to use either of these tools, when compared to ADMT.
Can be used to reACL computers. This tool is useful for server migrations where there are a large number of files with ACLs. Simple servers are best migrated with ADMT, whereas subinacl has a speed advantage over ADMT on large file servers.
Strictly speaking, because of sidhistory, reACLing isn't necessary. But because sids are resolved to human names, and because the behavior is to first consult the domain authority for the sid's domain prefix, there is a performance issue at hand. Sidfiltering also introduces implications. Sidfiltering is used to protect against elevation of privilege attacks via sidhistory. When a principal from a trusted domain tries to access a resource in the trusting domain, it can't use any sids that don't have the same sid domain prefix as the trusted domain. Consult http://download.microsoft.com/download/1/4/8/148e2a0c-5e6e-4d34-899e-d2454c535e82/SIDHist.doc for more details on sidfiltering.
/changedomain replaces sids from the old domain with the corresponding sid from the new domain.
/migratetodomain adds sids from the new domain while preserving the sid from the old domain.
The export/import features of the Group Policy Management Console can be used to migrate group policy. GPMC even provides a mechanism so that you can map an account in the source domain to an account in the target domain. Since some parts of group policy are based on display names instead of SIDs, this is very helpful. There's also the point that built-in accounts are never migrated (regardless of the tool), and they are the only accounts used in default group policy. I've never checked this out, but I suspect you can't use sidhistory on built-in accounts. Depending on what access you want those built-in accounts to have and whether you have modified the default GPOs, you may need to make some manual modifications.
Here are the gotchas: