ADMT password migration issue

Question

ADMT password migration issue

Stefano Colombo 221

We're using ADMT to migrate users and computer account between two forest.

We're having issue with the password migration, either for users and computer account.

The PES service is up and running but when migrating the user we got the following error

2026-09-24 14:13:18 WRN1:7557 Failed to copy the password for XXX . A strong password has been generated instead. Unable to copy password. Access is denied.

The target DC is 2025 the source 2019.

The users and computer anyway are correctly created

thanks

0 comments

2 answers

Your answer

Answer 1

James Gamble 170

Hola Stefano,

The fact that ADMT is successfully creating users and computers, while password migration alone is failing with WRN1:7557, helps narrow this down quite a bit.

The first thing I'd keep in mind is that ADMT 3.2 is now a legacy tool. Microsoft's current support statement states that ADMT hasn't been updated to support Windows Server 2016, 2019, 2022, or later and that the codebase is deprecated.

That means your Server 2019 source and, especially, your Server 2025 target are outside the combinations ADMT was originally designed and tested for.

The most important item I'd check first is LSA Protection on the source Server 2019 domain controller that hosts the Password Export Server. Microsoft specifically documents that ADMT password migration only works when LSA Protection is disabled on the PES server. That makes sense technically because PES has to interact very closely with LSASS to export password data, while LSA Protection, also called RunAsPPL, is specifically designed to prevent untrusted or legacy components from interacting with LSASS.

From an elevated PowerShell prompt on the source DC, run Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name RunAsPPL -ErrorAction SilentlyContinue | Select-Object RunAsPPL

You can also check directly with reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL & reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPLBoot

If RunAsPPL returns 1, LSA Protection is enabled. If the value doesn't exist, it usually means it hasn't been explicitly enabled via that registry value, though I'd still check Group Policy or other security configurations if there's any doubt.

There's also an older Microsoft-documented cause that matches the exact WRN1:7557 "Access is denied" message. On the target domain controllers, Microsoft has historically required HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous = 0, and the Pre-Windows 2000 Compatible Access group must have the required Read and Enumerate Entire SAM Domain permissions on CN=Server,CN=System,DC=<TargetDomain>,DC=<TLD>

That requirement exists because ADMT password migration still relies on older SAM/RPC access patterns that modern Windows security defaults intentionally restrict. I'd be careful about weakening those settings broadly, especially on Server 2025. They exist for good security reasons, so any required changes should be treated as temporary migration-specific exceptions and restored afterward.

I also wouldn't start by assuming the PES service account simply needs more privileges. Since the user and computer objects are already being created successfully, the basic migration permissions and trust path appear to be working. Your exact error is more consistent with the legacy security requirements around PES, LSA Protection, or anonymous/SAM access.

One other thing to keep in mind is Credential Guard and other virtualization-based security features on the system running ADMT. Microsoft documents compatibility issues there as well, and Server 2025 has much stronger security defaults than the platforms ADMT was originally built for.

If you can post the output of these two commands from the source DC hosting PES, that'll probably tell us very quickly whether LSA Protection is part of the problem:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPLBoot

Thanks,

James

Stefano Colombo 221 Reputation points

2026-09-24T14:41:33.1633333+00:00

Hello @James Gamble
thanks for the tips.

the two commands you suggested returned the following error message
PS C:\Windows\system32> reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL

ERROR: The system was unable to find the specified registry key or value.
PS C:\Windows\system32> reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPLBoot

ERROR: The system was unable to find the specified registry key or value.

how ever running
PS C:\Windows\system32> reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa
I noticed something that might be source of the issue. ( see the attached picture)
I'm thinking of changing the key hilighted
James Gamble 170 Reputation points

2026-09-24T14:57:07.9633333+00:00

Hola Stefano,

That screenshot may have found the issue.

The missing RunAsPPL and RunAsPPLBoot values indicate that LSA Protection is not explicitly enabled through those registry keys so that I wouldn’t create or change them just for ADMT. The more important entry in your screenshot is: AllowPasswordExport REG_DWORD 0x0

For PES password migration to work, that value must be 1 on the source server running Password Export Server. Microsoft’s legacy ADMT/PES guidance explicitly calls this out: the AllowPasswordExport control determines whether the PES server can export passwords for migration.

You can change it from an elevated command prompt with:

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v AllowPasswordExport /t REG_DWORD /d 1 /f

After changing it, restart the source server or, at a minimum, restart the PES service if your change procedure allows it. Historically, Microsoft’s ADMT guidance recommends restarting the computer after enabling password export.

I would not change restrictionanonymoussam based on what you’ve shown. That is a separate security setting, and your immediate problem is that PES is currently configured to prevent password export entirely.

Thanks,

James
Stefano Colombo 221 Reputation points

2026-09-25T07:00:36.8+00:00

Hello, I changed that registry "allowpasswordexport" to 1 and rebooted the server but did not solve the issue
James Gamble 170 Reputation points

2026-09-25T12:28:55.6+00:00
Hola Stefano,

Thanks for testing that. Since AllowPasswordExport is now set to 1, the server was rebooted, and you're still getting the same WRN1:7557 "Access is denied" error, I'd move on to the target-domain checks that Microsoft has documented for this exact message. Microsoft's ADMT guidance for WRN1:7557 says to verify two things on the target side:

RestrictAnonymous is set to 0 on the target domain controllers.

The Pre-Windows 2000 Compatible Access group has Read and Enumerate Entire SAM Domain permissions on: CN=Server,CN=System,DC=<TargetDomain>,DC=<TLD>

On the Server 2025 target DC, I'd first check the registry value: reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RestrictAnonymous

You want to see RestrictAnonymous REG_DWORD 0x0

If it's 1 or 2, that can block the legacy SAM access ADMT uses during password migration.

I'd also check the trust configuration. There's another ADMT/PES case where password migration failed while object migration still worked because the forest/external trust was configured for Selective Authentication. Changing the trust to Domain-wide Authentication resolved the password migration in that case.

That's relevant because your objects are being created successfully, which indicates the general migration path is working, but the password migration uses additional legacy RPC/SAM access that can be blocked independently.

I'd avoid changing any of those settings until you verify their current values, especially on Server 2025. These are security-sensitive compatibility settings, and ADMT is relying on mechanisms that modern Windows increasingly locks down.

If you can post the output of reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RestrictAnonymous and let me know whether the trust is configured for Selective Authentication or Domain-wide Authentication, we can narrow down the next step.

Thanks,

James
Stefano Colombo 221 Reputation points

2026-09-25T13:09:31.6066667+00:00
Hello ,
this is the key on the 2025 DC
PS C:\Scripts> reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RestrictAnonymous

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

RestrictAnonymous REG_DWORD 0x0
James Gamble 170 Reputation points

2026-09-25T13:15:39.1766667+00:00

Hola Stefano,

Thanks, that confirms RestrictAnonymous is already set correctly, so I wouldn’t change anything there. At this point, I think we’ve ruled out the main documented PES configuration issues that would normally cause this exact failure.

Given that:

AllowPasswordExport is now enabled

LSA Protection doesn’t appear to be explicitly enabled through RunAsPPL

RestrictAnonymous is already 0

User and computer objects are migrating successfully

Only password migration is failing

The target domain controller is Windows Server 2025

I’m starting to think this may simply be an ADMT/PES compatibility issue rather than a configuration problem.

Because the password migration component depends on older LSASS/SAM/RPC behavior, Server 2025’s newer security defaults make that part of ADMT especially likely to break even when the rest of the migration still works.

I wouldn’t keep weakening security settings on the Server 2025 DC just to try to make PES work.

At this point, I’d open a Microsoft support case and ask specifically whether ADMT/PES password migration is supported at all with a Server 2025 target. If Microsoft confirms it isn’t, you may need to migrate the accounts without passwords or use a different migration method/tool that supports current Windows Server versions.

Thanks,

James

Answer 2

Hello Stefano,

Thank you for posting your question on Microsoft Windows Forum!

The error message:

" Failed to copy the password for XXX, A strong password has been generated instead, Unable to copy password and Access is denied"

suggests that ADMT can create the user account successfully, but Password Export Server (PES) is unable to read or transfer the password from the source domain.

Since the users and computer accounts are being created correctly, the trust and migration itself appears to be working. The problem is likely related to PES permissions, encryption key mismatch, or communication between ADMT and PES rather than the migration process itself.

Recommended Troubleshooting Steps

Step 1: Verify PES installation and encryption key

On the source domain controller:

Confirm that the Password Export Server service is running.
Verify that the PES encryption key currently installed on the source server is the same key that ADMT is using on the target server.

A mismatch between the PES key and the ADMT key commonly results in password migration failures.

Step 2: Verify PES service account permissions

The account running the migration should have:

Domain Admin privileges in the source domain.
Administrative permissions required by ADMT in the target domain.

Also verify that no recent password changes or permission changes were made to the service account used by ADMT.

Step 3: Review PES Event Logs

On the source server, check:

Event Viewer

Application Log

and

Event Viewer

System Log

Look for events generated by:

Password Export Server

PES

ADMT

around the exact time the migration failed.

These events usually provide more specific details than the ADMT console.

Step 4: Verify ADMT and PES compatibility

You mentioned:

Source DC: Windows Server 2019

Target DC: Windows Server 2025

Please confirm the exact versions of:

ADMT
PES

being used.

ADMT is a legacy tool and is no longer actively developed. Compatibility limitations may exist depending on the build and operating system versions involved.

Step 5: Test with a single new user

Create a temporary test account in the source domain with a simple password and attempt to migrate only that account with password migration enabled.

If the test account also receives:

Unable to copy password. Access is denied.

then the issue is very likely at the PES permission or configuration level.

For additional reference, you may review:

https://learn.microsoft.com/windows-server/identity/admt/admt-overview

https://learn.microsoft.com/troubleshoot/windows-server/active-directory/use-admt-migrate-users-computers-groups

I hope this answer has provided you with useful insight. If you find this answer useful, please feel free to click Accept Answer and consider upvoting it so I know it addressed your concern. If you have any additional information from the PES logs, please feel free to leave a comment.

Stefano Colombo 221 Reputation points

2026-09-24T14:08:42.5933333+00:00

Hello,

The PES service on the source PDC is running with the destination domain admin account.

ADMT is version 3.2 PES
We couldn't find any specific error message in events on the PES server