ADMT (Active Directory Migration Tool) and USMT (User Setting)
Microsoft offer three utilities to assist with migrating to Windows Server 2003.
This is a great tool for copying user account information from one Windows domain to another Windows domain. I first used ADMT for transferring users in an NT 4.0 domain into a new domain in Windows 2003. These days ADMT is popular for migrating from Windows 2000 to Windows Server, particularly where you want to start with a brand new Active Directory forest. The prerequisite for using ADMT in Windows 2000 is that the domain has to be in Native mode.
The crucial attribute is the sIDHistory, this enables the user object to be identified in the old and new domain. In addition to copying users, this utility also copies groups and even computer accounts. Conveniently, you can also copy the passwords. If you have scripting experience then you can use your skills to manipulate precisely what to migrate, ADMT provides a scripting interface.
You will also need to create a trust so that the source (NT 4.0 or old domain) accounts trust the Windows 2003 domain. As a result the old accounts can be copied across to their new domain. Let me just clarify that the ADMT copies not moves the accounts, and that it is a one time move without any synchronization. Should you need account synchronization then deploy the ADC (Active Directory Connector).
To obtain the Active Directory Migration Tool dig out the Window Server 2003 cd and drill down to the \i386\ADMT sub-folder. Check the readme file and seek the .msi file. Alternatively, you can download all the files from Microsoft’s site, if you take this option, look out for ADMT v 3.0.
ADMT is a well behaved program and the installation is straight forward. I am assuming that you have total administrative control of both domain, in particular you know the administrator passwords. If you use the actual administrator you can be sure that it is a member of groups such as Enterprise Admins and Schema admins. Those who struggle to differentiate between their right and left hands have trouble identifying which is their target and which is their source domain. Only you know the answer to these questions. One sneaky pre-requisite is that both source and target servers must have a C$ and Admin$ share.
I like thePermissions Monitor because it enables me to see quickly WHO has permissions to do WHAT. When you launch this tool it analyzes a users effective NTFS permissions for a specific file or folder, takes into account network share access, then displays the results in a nifty desktop dashboard!
Think of all the frustration that this free utility saves when you are troubleshooting authorization problems for users access to a resource. Give this permissions monitor a try – it’s free!
1. Log on as an administrator at the computer where you installed ADMT.
2. At a command prompt, run the ADMT KEY sourcedompath [* | password] command to create the password export key file (.pes). In this example, sourcedom is the name of the source domain and path is the location where ADMT creates the key. The path must be local. If you type the password at the end of the command, ADMT protects the .pes file with that password. If you precede with an asterisk (*), ADMT prompts for a password, and the system will not echo it as it is typed.
3. Copy the .pes file you created in step 2 to the Password Export Server in the source domain. This can be any domain controller.
4. Run Pwmig to install the Password Migration DLL on the Export Server. You will find Pwmig .exe in the I386\ADMT folder
5. When you are prompted to do so, specify the path to the .pes file that you created in step 2. This must be a local file path. After the installation completes, you must restart the server.
7. Change the following registry key to DWORD 1.
The User State Migration Tool (USMT) is another Microsoft utility for copying user settings, files, and documents, (rather than user accounts). Then you restore these settings on the new machine so users do not have to reconfigure their desktop settings. It works best for XP and Windows 2000 Professional clients and you do need the client machine to be connected to a domain controller.
There are two command line utilities scanstate and loadstate that control the procedure.
This wizard found on the XP CD includes the same functionality as USMT but does not allow for the fine tuning of the settings that you get with scanstate and loadstate.
See more on Active Directory Attributes