How can i use ADMT to perform an intraforest migration of Windows 10 and 11 computers?

Question

How can i use ADMT 3.2 to perform an intraforest migration of Windows 10 and 11 computers?

I have tried and it fails to author the SPN as it already exists in the forest.

Computers appear to have domain suffix change just fine, but SecureChannel is broken at end of migration process.

Also finding that no files have security translation success--all show 'access is denied' as error in the Agent logs.

Single Forest with two single-label domains at Windows 2008 R2 functional level.

Source DCs are Windows Server 2016.
Target DCs are Windows Server 2022.

DNS zones for Source are present on Source DCs as they are also DNS servers.
DHCP server for forest resides on Source DC.

DNS zones for Target are present on Target DCs as they are also DNS servers.

ADMT logs show successful resolution of DNS for Source and Target.

Target DCs have events pointing to duplicate SPN and SPN value change failure.
Using setspn -l <accountname> shows SPN values in Source, and shows suggestion there should be values showing in Target, but no values showing.

Answer 1

Hello Allen Lester,

Thank you for posting in Microsoft Community forum.

Before proceeding, note that ADMT 3.2 is an older tool that wasn’t originally designed with Windows 10/11 in mind. That said, it may be successful under these circumstances, provided extra care is taken.

We can see the supported OS about ADMT in the link below.

 Download Active Directory Migration Tool version 3.2 (has known problems and limited support) from Official Microsoft Download Center

And we can see some known issues for ADMT.

Support policy and known issues for ADMT - Windows Server | Microsoft Learn

Here are some suggestions about the questions.

1.Duplicate SPN Issues

1.The error that ADMT “fails to author the SPN” because it already exists indicates that the SPN value on the source computer account is still “live” when ADMT tries to update the target account.

2.In AD, computer accounts often have SPNs in the form of HOST/computername, etc. In intra‐forest moves, you generally have two copies (one in each domain) competing for the same SPN if they are not cleaned up.

Suggested fixes:

Before migration, search for duplicate SPNs. Using a tool like    

setspn –L computername

on both source and target accounts may pinpoint conflicts.  

3.Remove or modify the SPNs on the source account (for example, after you confirm that the target account has its own computer object) so that the “new” object can safely claim the SPN.   An alternative (if you don’t want to remove the source SPN immediately) is to precreate (or “pre-stage”) the target computer account and manually set the correct SPN values; then tell ADMT to use the existing account during the migration, thus avoiding an SPN creation conflict.

2. Secure Channel Breaks

ADMT normally “fixes” the secure channel after a computer account has been migrated. The broken secure channel you’re seeing is likely a direct result of the SPN update failure.

Suggestions:

1.Once you resolve the SPN conflicts (step 1), the secure channel fix should complete properly.  

Alternatively, use additional tools (for example, NETDOM reset or the PowerShell cmdlet Reset-ComputerMachinePassword) on a test computer post-migration to re-establish the secure channel.  

2.Verify that the ADMT “post-migration” step (which “fixes” the secure channel) is running with appropriate permissions.

3. “Access is Denied” in Security Translation (or File Translation) Logs

The “access is denied” errors in file/registry translation often mean that the ADMT agent on the computer does not have sufficient rights to modify local security or that the account you’re using for the translation does not have local administrator rights on the source/target machine.

Troubleshooting tips:

1.Ensure that you are running the ADMT agent (i.e. the ADMT Migrator Service) under a context that has local admin privileges on the target computer.  

2.Verify that the account performing the migration has full administrative privileges in both source and target domains.  

3.In some cases, these errors may also appear if local security policies or UAC restrictions on Windows 10/11 are interfering. Test by temporarily disabling UAC (or running the ADMT agent “elevated”) on a sample test machine.  

4.Confirm that no antivirus software or local firewalls is blocking the translation process (keeping in mind that port requirements for ADMT must be met).

Setspn | Microsoft Learn

I hope the information above is helpful.

If you have any question or concern, please feel free to let us know.

Best Regards,

Daisy Zhou

Answer 2

Some good news:

I had success by staging the computer account and modifying all domain-specific SPN values in the target domain.

I turned Defender OFF during the migration.

Upon migrating, the Agent installed and created its log file. In the log file, it showed again that there was 'access denied' for the security translation steps on files and registry keys.

Ultimately, though, the domain suffix changed on the computer, and it restarted after Agent activities. I was then able to login to the computer with a network account from the TARGET and SOURCE domains!

I was also able to go to SOURCE network file shares and access the files for the SOURCE account and modify those files. I was also able to map a network printer.

I have asked other users to try the same for me on this same computer and will update this query later.

Upon testing the SPN presence in the TARGET domain, there are not updates to the SPN values before or after any of the users logged into the computer. I suspect I will need to manually fix those later.

Updates to follow, but leaving this question open in hopes of other technical answers to provide end-to-end success.

Answer 3

Hello

Greetings!

OK, I will keep this thread open.

I am so glad to hear the good news from you. Thank you so much for your update and sharing.

Best Regards,
Daisy Zhou