Active Directory Migration Toolkit (latest version is v3.2) is a free tool that allows both Inter-Forest and Intra-Forest user, group and computer migration.
Installation ADMT Version 3.2 must be performed on a Windows 2008 R2 server (Member server highly recommended). It only requires SQL Express to be installed as a prerequisite.
An Inter-Forest migration is popular when an organization merges with another organization. An Inter-forest migration requires a forest trust between the two forests. This in itself requires name resolution between the domain controllers and implies WAN connectivity as well.
Objects can be continually be migrated and merged into the target over and over if it is necessary to edit the source object even after the new target object has been created. The ADMT guide goes through this in detail.
The trust relationship must be configured to permit SIDHistory to flow across the forest trust. This can be done with the following command:
Netdom trust <Sournce Doamin> /domain:<Target Domain> /EnableSidHistory:yes
Passwords can be migrated using the Password Export Server ((PES) v3.1) or new passwords can be generated. This is a separate download and is installed on the source domain controller.
PES performs an initial sync of the password and can be used for subsequent password updates but was not designed to be used as a password sync tool. For that you would need Forefront Identity Manager (FIM) and Password Change Notification Service (PCNS). PCNS has its own set of requirements, for example, it must be installed on each domain controller in the source domain whereas PES only needs to be installed on a single domain controller (the one you select as the source domain controller during ADMT migration).
It is a little tricky because you first must generate an encryption key on the ADMT member server located in the target domain.
http://technet.microsoft.com/en-us/library/cc974435(v=ws.10).aspx
Note: Microsoft recommends that you run the PES service as an authenticated user in the target domain. This way, you do not have to add the Everyone group and the Anonymous Logon group to the Pre–Windows 2000 Compatible Access group.
Notice the warning: You must reboot before ADMT’s Password Migration DLL will be operational.
After reboot, the service does not start automatically and needs to be started
You can then invoke the Password Migration Wizard on the ADMT member server. If you get an error “unable to establish a session with the password export server” – check to make sure the “Password Export Server Service” is running on the source domain controller.
Note: The flag “user must change password after first logon” will be set on the target user after migration with ADMT. The reason for this is because ADMT does not check the target domain’s password policy to see whether the source password is compliant. You can manually deselect this option if you have set the target domain policy with a weaker password policy (ex: password complexity disabled, and less or equal password length, etc). Otherwise the user will be required to change their password immediately after logging into the target domain.
After the users have been migrated it is necessary to run the Security Translation Wizard from within the ADMT tool against the source domain controller and resource servers (ex: File/Print Servers). This allows the users to access file and print resources in the source domain without error.
After the users have been migrated to the target domain, the next step is to migrate their computer accounts. This is recommended so that the user’s local profile (ex: desktop background wallpaper, files on desktop, mapped network drives, etc, to carry over so that there is minimal impact on the end user.
However, if Windows Firewall is enabled then the ADMT tool may not be able to connect to the machine to translate the user profile.
After resolving that issue, you may run into another error “unable to determine the local path for ADMIN share on the machine” – The solution is to make sure the target admins have sufficient permission on the source computers. For example, you could use group policy to add the new domain admins group into the local administrators group of the source computers. For testing you could manually add it as this blog article suggests:
http://msexchangetips.blogspot.com/2010/08/admt-32-err27674-unable-to-determine.html
ADMT Pushes an agent out to computers to perform the Security Translation activity. To verify that ADMT processes are running, you can use Task Manager to verify that ADMTAgnt.exe and DctAgentServices.exe are in the Processes tab. They will terminate upon completion. The local working directory for the agent is
%windir%\onepointdomainagent
The agent needs sufficient rights and dynamic TCP RPC ports range between 1024 and 5000 to be open so that it can write back to the ADMT member server in the target domain (c:\windows\ADMT\Logs accessed via the ADMIN$ share).
http://technet.microsoft.com/en-us/library/cc974403(v=ws.10).aspx
There are 3rd party tools that can simplify things by integrating the password synchronization and providing an undo option. The most popular tool is Quest Migration Manager for Active Directory:
http://www.quest.com/migration-manager-for-active-directory/
Best practice is to create a test lab and run through all the steps before making any attempts in a production environment.
Resources:
Screenshots of the blog article above as originally posted on my former blog:
ADMT v3.2 Download (free)
http://www.microsoft.com/en-us/download/details.aspx?id=8377
Password Export Server v3.1 x86 Download (free MSFT Tool)
http://www.microsoft.com/en-us/download/details.aspx?id=10370
x64 Download:
http://www.microsoft.com/en-us/download/details.aspx?id=1838
SQL 2008 SP3 (Free PreRequisite)
http://www.microsoft.com/en-us/download/details.aspx?id=27597
ADMT Guide
http://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx
Decent Video Walkthrough of the Installation
http://www.youtube.com/v/KHIWlWFf2AM?hd=1
The Cloud Technologist 