Fix 0X00002157: Domain not in forest error during AD migration
This error means you're trying to move an object to a domain that isn't in the same Active Directory forest. The fix is to ensure both domains trust each other properly.
Quick answer
Verify the source and destination domains are in the same forest or have a two-way transitive trust. Then rerun the move.
What's actually happening here
The error 0X00002157 (ERROR_DS_DESTINATION_DOMAIN_NOT_IN_FOREST) pops up when you're moving an Active Directory object—usually a user or group—to a target domain, and the target domain isn't recognized as part of the same forest. This happens most often during inter-forest migrations using tools like Active Directory Migration Tool (ADMT) or PowerShell Move-ADObject, when someone tries to move objects across forest boundaries without a proper trust setup. The underlying cause: AD's logical tree structure enforces that moves only happen within a single forest's domain hierarchy. Cross-forest moves require a different approach—you're copying objects, not moving them.
I've seen this error on Windows Server 2012 R2 through 2022, usually when an admin creates a new child domain or adds an external domain but forgets to configure the forest trust between the two environments. The reason step 3 of the standard fix works is because the domain controller's location service relies on DNS resolution and trust routing to determine forest membership. Without that, it rejects the operation outright.
Fix steps
- Check forest membership. Log into a domain controller in the source domain. Open Active Directory Domains and Trusts (domain.msc). Right-click your domain, pick Properties, go to the Trusts tab. Verify the destination domain appears as a trust partner with type
Forest trust. If it's missing, you need to create the trust. - Verify both domains are in the same forest. Run
nltest /dsgetdc:destination.domain.comfrom the source DC. If it returnsERROR_NO_SUCH_DOMAIN, the destination isn't reachable. Then runnetdom query fsmoto see the forest root—both domains must share that root. If they don't, you're in a cross-forest scenario. - Create or fix the forest trust. In Active Directory Domains and Trusts, right-click the root domain name, select Properties, Trusts tab, New Trust. Follow the wizard to create a two-way transitive trust. Use the same credentials for both sides. Once done, test with
nltest /trusted_domains. You should see both domains listed. - Retry the migration tool. Open ADMT or your PowerShell script again. The operation should complete without 0X00002157. If it fails, check the tool's log files—ADMT writes to
%SystemRoot%\ADMT\Logs\Migration.log. Look for0x2157references.
Alternative fixes if the trust exists but error persists
- Check SID history filters. If the destination has the SID filtering quarantine feature on (enabled by default on external trusts), disable it temporarily. On the destination domain controller, run
netdom trust source.domain.com /quarantine:No /add. This allows SID history to flow during migration. Re-enable it after:netdom trust source.domain.com /quarantine:Yes. - Force DNS zone replication. Sometimes stale DNS records cause the DC locator to fail. On the source DC, open DNS Manager, right-click the forward lookup zone for the destination domain, and select Reload. Then run
ipconfig /flushdns && nltest /dsgetdc:destination.domain.com. - Use copy instead of move. If you're truly cross-forest, you can't move objects. Use ADMT with the
Intra-Forest Moveoption deselected, and enableCopy objects. This duplicates the user/group with a new SID and optionally migrates SID history via the trust. - Update ADMT schema. On the destination domain, run
admt schema /forestto ensure ADMT has the correct security principals. Reboot the domain controller if prompted.
Prevention tip
Before any domain migration, document your forest topology. Use netdom query trust to list all trusts and verify transitive trust paths between source and destination. If you're planning cross-forest moves, prepare a dedicated migration forest with a two-way trust and disable SID filtering only for the migration window. This keeps your production environment clean and avoids the 0X00002157 headache.
This error is a safety catch, not a bug. AD won't let you break forest integrity. The real fix isn't bypassing it—it's setting up the right trust infrastructure first.
Was this solution helpful?