Error 1500 (Win32Err=5) during Computer & Profile Migration with External Domain Trust

When CopyRight2 Computer & Profile Migration prepares a client for migration, the client log may stop with CopyRight2 Error 1500, Access is denied, and Win32Err=5. Although the message looks like a permissions problem, this behavior occurs in the default trust-based migration configuration after RC4 was disabled by the April 2026 Windows updates because Windows does not route the target DC's host-based Kerberos request to the correct realm.

Why “Access is denied” can be misleading

In the default configuration, the target domain trusts the source domain. This trust direction lets CopyRight2 perform the migration without a separate join user: the source computer account is granted the permissions required to join on the target computer object. The CopyRight2 client is still joined to the source domain and contacts a target-domain controller across the external domain trust.

The CopyRight2 Computer & Profile Migration agent runs as LocalSystem, so Windows accesses the target DC using the source-domain computer account, not the interactive account of the currently logged-on user. During preparation, CopyRight2 retrieves information about the target domain, including its domain SID. When Kerberos cannot route the request correctly, this lookup fails and the client log reports error 1500 and Win32 error 5. The resulting Access is denied message is therefore misleading even though the required join permissions were assigned correctly.

The trust itself may still work. In a command prompt running as LocalSystem, Windows can successfully obtain the cross-realm ticket-granting ticket:

klist get krbtgt/TARGET.COM

However, Windows then fails to route the host-based service request for the target domain controller to the TARGET.COM realm:

klist get cifs/dstdc.target.com

The cross-realm TGT therefore succeeds while the CIFS service-ticket request fails. The same lookup works with a forest trust. This article addresses the external domain trust and default CopyRight2 workflow described above; other CopyRight2 Error 1500 cases can still have different causes.

Diagnose the issue as LocalSystem

You can reproduce the relevant checks without running the complete migration. Open a LocalSystem command prompt with Microsoft Sysinternals PsExec:

psexec.exe -accepteula -i -s cmd.exe

In the new prompt, confirm the security context and test both ticket requests:

whoami
klist get krbtgt/TARGET.COM
klist get cifs/dstdc.target.com

whoami should return nt authority\system. If the TGT request succeeds but the CIFS request for the target DC fails because Windows selects the wrong realm, apply a Kerberos Host-to-Realm mapping.

Resolution: Map the target DC to its realm

Run these commands in the LocalSystem prompt:

ksetup /addhosttorealmmap dstdc.target.com TARGET.COM
klist purge
klist get cifs/dstdc.target.com

Use the exact fully qualified domain name of the target domain controller that CopyRight2 contacts. The ksetup addhosttorealmmap command maps that hostname to the target Kerberos realm. Purging the LocalSystem ticket cache ensures that the next request uses the new mapping.

After the CIFS service ticket is issued successfully, the target-domain lookup completes, CopyRight2 retrieves the domain SID, and Computer & Profile Migration preparation continues.

A Host-to-Realm mapping only corrects Kerberos routing. It does not repair a broken trust, DNS resolution failure, blocked firewall traffic, selective-authentication restriction, or genuinely missing permission. Validate those conditions separately if the TGT request also fails or the mapped service request still returns an error.

The trust direction is the reverse of the one commonly used for SID-History. In the SID-History Kerberos troubleshooting article, the source domain trusts the target domain so a migrated target-domain user can access resources in the source domain. In the default CopyRight2 Computer & Profile Migration configuration described here, the target domain trusts the source domain, and a source-joined computer account accesses the target DC.