This article provides updates about the status of the free Active Directory migration tools and documentation. The tools are Active Directory Migration Tool version 3.2 (ADMT v3.2) and Password Export Server version 3.1 (PES v3.1).
This article also describes the known problems and limitations of the tool set.
How to get these tools
The following tools are available from the Microsoft Download Center.
Active Directory Migration Tool version 3.2 (ADMT v3.2)
Provides an integrated toolset to facilitate migration and restructuring of tasks in an Active Directory Domain Services infrastructure.
Password Export Server version 3.1 (PES v3.1)
Enables password migration during account migration in an Active Directory Domain Services infrastructure.
Provides guidance for migration of domains by using the Active Directory Migration Tool.
ADMT has not been updated for Windows 8.1 and 10 workstation migration. Windows Server 2012, Windows Server 2012 R2 and later version of Windows Server have not been tested with modern applications and profile migrations. Your experience may vary, depending on many factors, including the Windows version that you are migrating. Use at your own risk.
An alternative to the ADMT tools suite is also available from Microsoft Services—Active Directory Migration Services (ADMS), which runs in the Azure Cloud. For entry-level information, see:
Known issues and limitations
Installing PES on Windows Server 2012 and newer
Old ADMT guides don't mention the need to run the pedmig.msi file from an elevated command prompt. The ADMT guide that is dated February 26, 2018, that's available from the Microsoft Download Center mentions this requirement.
Computer running ADMT must not use Credential Guard
The station driving the migration is not doing the migration by itself. The object movement is executed on the target domain controller (DC). It is delegating the user running the migration task when migrating a user from the source domain.
By default, domain controllers are set up for unconstrained delegation which is not allowed by Credential Guard anymore.
If you have ADMT installed on a Windows Server 2016 or a later version Windows Server-based member server, you must disable Credential Guard to perform migrations. Or you can move the ADMT installation to the target domain DC, where you don’t need to delegate. Also, Credential Guard is not supported on target DCs.
DC cannot use unconstrained delegation
Because of existing attack vectors, Microsoft is restricting and blocking the use of unconstrained delegation. This also affects DCs. ADMT logs the following error:
ADMT log error: Failed to move source object. Verify that the caller's account is not marked sensitive and therefore cannot be delegated. hr=0x8009030e No credentials are available in the security package
The change of behavior for Windows Server 2008 R2 is contained in March 12, 2019—KB4489885 (Security-only update).
You can configure the target domain DCs for constrained delegation and allow the target domain DCs to delegate to the source DCs (resource-based constrained delegation). This is only possible when your DCs are Windows Server 2012 or later version of Windows Server.
On Windows Server 2008 R2 or earlier version of Windows Server, you can only move the ADMT installation to a target domain DC. Then you don’t have the need to delegate.
Users running ADMT must not be member of an authentication silo
The user account that is used to drives the migration of SidHistory must not be in an authentication silo. When migrating SidHistory across forest, the target DC creates a network session to the source DC and authenticates by using NTLM. For the Admin user accounts that are in an authentication silo, in some OS, NTLM is not allowed for these user accounts by default, or is disabled by users.
Domains in the authentication flow of ADMT tasks must not restrict NTLM
For the same reason as avoiding authentication silos, the domains that are used for ADMT SidHistory migrations must not restrict the use of NTLM by one of the policies.
SQL Server versions
There is no version check for SQL Server versions with ADMT. The last tests were run in 2013. So, computers that are running SQL Server 2014 and later versions were not tested. Please perform your own testing of ADMT in a test environment before the tool is used for production migration.
Group Managed Service Accounts
As of February 27, 2018, the ADMT Guide describes how to handle Managed Service Accounts as implemented in Windows Server 2008 R2. There was no testing done for Group Managed Service Accounts (GMSA). So, given the special handling of these accounts in several places, you should:
- Not try to migrate GMSA across forest boundaries.
- Use caution when you try to move GMSA within a forest.
Client operating systems
Although the latest tool set was released after Windows 8.0 entered the market, there was no testing for Windows 8.x and 10.x computer account migration and in particular full migration of user profiles.
We found several migrations problems related to correct transition of user profiles, in particular with modern applications registrations and profile permissions.
Repeat migrations for password updates
Some customers are running repeat migrations of accounts to transfer a new password from a source account to a new account in another forest. ADMT is not designed for this approach. It tracks each migration job in its database. So over time, the ADMT database size increases. It might at some point experience the following:
- Exceed the licensed size of the database (for SQL Express Deployments).
- Exceed the available disk space on the computers that are running SQL Server.
- Running migration jobs slows, as the tool scans the migration history when you run a new job.
Note: If you intend to use ADMT in this manner for several weeks or months with a frequent synchronization schedule, we recommend a solution based on a synchronization solution such as Microsoft Identity Manager.