After installation, you open the ADMT as an MMC snap-in on the target domain controller. Your target domain must be in domain native mode. User and computer accounts get migrated in separate steps; then you remotely run an “agent” on the workstations that you’re migrating to join them to the new domain and reset all the necessary file/registry permissions.
In order for this agent to run, your user account in the target domain must have local admin rights on the workstations. Automating the process may be the topic of another post. I did it manually by adding \\gold\Domain Admins to \\silver\Trusted-Admins
I couldn’t add \\gold\Domain Admins to \\silver\Domain Admins because both groups are global. Remember that global groups are great travelers, but poor hosts. Also found that I couldn’t place an individual user account from one domain in another domain’s group.
If you don’t have local admin rights to the workstations, the ADMT agent will report “access is denied” to the ADMIN$ share. The workstations also need need to have the same primary DNS server as the target domain controller(s).
By the way, during the course of this exercise I raised my forest functional level and learned that the Enterprise Admins group only exists on domain controllers in the “root domain” of a forest. You have to be in that group to make any schema changes (e.g. modifying the forest).
By default, the ADMT does not migrate user passwords; instead is sets the migrated user accounts to “change password at next login”.
After the ADMT agent runs, it reboots the workstation & viola! You’re finished! This is so cool.
