Summary: What are the requirements to use the Active Directory Migration Tool
Date: Around 20012
Refactor: 20 February 2025: Checked links and formatting.
We are planning to do an Active Directory Migration using the ADMT tool provided by Microsoft. The requirements however are not well explained and certainly not at one place. This page will provide all the requirements with extra information if needed.
Note that this article will keep the following versions in mind:
Both the source and target domains must be running on Windows Server 2003, 2008 or 2008 R2.
The ADMT Agent (installed on computers in source domain) runs on:
The following databases can be used (must be pre-installed):
The SQL installation must be configured for Windows Authentication Mode.
By default, when you setup a domain trust SID Filtering will be enabled. This means you can't use the migrated SID History attributes. If you do want to use this feature you have to explicitly enable this. There are two methods, depending on what kind of trust you have. Note that you need to be domain or enterprise admin.
If you have an external trust run this command from the target domain PDC:
Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:No /usero:domainadmin /passwordo:domainadminpwd
If you have a forest trust run this command from the target domain PDC:
netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /EnableSIDhistory:yes /usero:domainadmin /passwordo:domainadminpwd
You can also query the current status if you use the /EnableSIDhistory without yes or no.
Note: TrustingDomainName = source domain name; TrustedDomainName = target domain name
Disabling SID filtering requires a level of trust between the two forests, and ultimately those who are responsible for Active Directory. With SID Filtering disabled, a rogue domain administrator could clone a SID from the other domain and add it to their SID History, granting them unauthorized rights.
Before SIDhistory will work it has a few requirements of it's own. However, ADMT will set them for you the first time it runs. If you do not want this, you can set these requirements manually:
In the source domain, create a local group called SourceDomain$$$, where SourceDomain is the NetBIOS name of your source domain, for example, Boston$$$. Do not add members to this group; if you do, SID history migration will fail.
regedit and click OK.Repeat these steps in the source domain.
You should just use the domain or enterprise admin accounts, but if you want to go deeper see the resource link for Migration Accounts from the Micrsoft knowledgebase.
The PES service can be installed on any writable domain controller in the source domain that supports 128-bit encryption (default on both Windows Server 2003 / 2008).
The PES Service should be installed after ADMT.
PES requires an encryption key to be created on the computer running ADMT in the target domain.
Command to create key:
admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> /keypassword:{<password> / *}
To import the key in the sourcedomain (should be done in the wizard while installing but just in case):
admt key /option:import /sourcedomain:sourcedomain.local /keyfile:key.pes
| Value | Description |
|---|---|
| <SourceDomain> | Specifies the name of the source domain in which the PES service is being installed. Can be specified as either the Domain Name System (DNS) or NetBIOS name. |
| <KeyFilePath> | Specifies the path to the location where the encrypted key is stored. |
| {<password> / *} | A password, which provides key encryption, is optional. To protect the shared key, type either the password or an asterisk (*) on the command line. The asterisk causes you to be prompted for a password that is not displayed on the screen. |
PES service should be running as an authenticated user in the target domain.
The PES service should only run during password migrations.
After the installation of PES the DC will have to be restarted.
Use these examples to query for SIDs:
dsquery * -filter "&(objectcategory=user)(samaccountname=sjoerd.hooft)" -attr objectsid dsquery * -filter (samaccountname=sjoerd.hooft) -attr sIDHistory
Now Sharepoint proved to be a migration and project by itself. We have a 2007 farm which was out of support and out of maintenance. Seriously out of maintenance. When testing the migration we found that about 40% could not be migrated because of the error:
Cannot complete this action. Please try again.
Of course, trying again did not meant the error was gone. Also, the error would show up for the same users again and again. We did found the error at the end, with the help of Microsoft support but I decided to create a separate page for it, because of the amount of information:
Sharepoint User Domain Migration using Stsadm
I also came across this bug where stsadm -o migrateuser doesn't work in a sharepoint 2003 environment. We didn't come across this issue, it's just here for reference:
There is an issue on Sharepoint 2003 where migrated users could not access their resources using the SID History. Newer sharepoint versions should not have this problem, but anyhow, you can use this command to fix it on user basis:
stsadm -o migrateuser -oldlogin DOMAIN\user -newlogin DOMAIN\user [-ignoresidhistory]
After migrating AD User Accounts between Active Directory Domains, and enabling the SID history, some users were not able to logon anymore. This is because the Kerberos token size is too big so users cannot access their profile anymore, cannot access their network mappings and policies are not applied anymore. I created a separate page for it, again, because there is a lot of information:
Fix: After ADMT Migration Users Cannot Logon - Profile Errors - Kerberos - MaxTokenSize