Fix ERROR_DS_SOURCE_DOMAIN_IN_FOREST (0X00002156)

You're stuck with this error, and it's a pain

You tried to move a domain from one forest to another using ADMT or PowerShell, and got ERROR_DS_SOURCE_DOMAIN_IN_FOREST with code 0X00002156. I've seen this happen most often when someone accidentally selects the same source and destination forest — or when trusts aren't configured right. Let's fix it.

First thing — check your source and destination are in different forests

This error literally means "the source domain is in the same forest as the destination." Sounds obvious, but I've watched people pick the wrong dropdown. Here's what to check:

1. Open Active Directory Domains and Trusts on a domain controller in the source forest.
2. Right-click Active Directory Domains and Trusts and select Change Forest. Enter the destination forest name.
3. Now expand both forests. Look at the domain tree under each. Are they under the same forest root? If yes — that's your problem. You can't move a domain within the same forest using ADMT. You need a separate forest.

If they're in different forests, move to the next step.

Set up a two-way trust — this is the real fix

ADMT requires a two-way trust between the source and destination forests. Without it, the migration wizard won't even let you select the destination properly. Here's how to set it up:

1. On a DC in the source forest, open Active Directory Domains and Trusts.
2. Right-click the source domain name, select Properties, then the Trusts tab.
3. Click New Trust and follow the wizard.
4. Choose Trust with a forest (not domain).
5. Enter the destination forest root domain. For example, if your destination is contoso.com, enter that.
6. Select Two-way trust and Forest-wide authentication.
7. Enter credentials with Enterprise Admin rights in both forests when prompted.
8. After the wizard finishes, verify the trust. You should see it listed in both forests' Trusts tab.

Now repeat the same steps on the destination forest side — you need the trust showing in both places. After applying, you should see the trust status as "Verified" with no errors.

Run ADMT again — now it should work

With the trust in place, re-run your ADMT migration wizard. When you get to the source and destination selection, make sure:

• Source domain is from the source forest (e.g., oldcorp.local)
• Destination domain is from the destination forest (e.g., contoso.com)

Click Next. The error 0X00002156 should be gone. If it's not, the trust isn't working — go back and verify the trust credentials.

Why this error happens — the real reason

Behind the scenes, ADMT checks whether the source domain's domainID matches any domain in the destination forest's crossRef container. If they're in the same forest, ADMT refuses to move it — because moving a domain within the same forest would break the existing global catalog and replication topology. Microsoft designed it this way to prevent accidental corruption. The trust is what tells ADMT "these are two separate forests, it's safe to proceed."

Less common variations of this issue

Sometimes the error appears even when you're sure the forests are separate. Here's what I've seen trip people up:

• Stale trust records — An old trust that was deleted but still shows in the configuration partition. Run repadmin /syncall on both sides, then check with nltest /trusted_domains.
• Source domain accidentally joined to destination forest — Rare but happens. Go to System Properties > Computer Name tab > Change and verify the domain membership.
• DNS resolution mismatch — The source DC can't resolve the destination domain's _kerberos SRV record. Test with nslookup -type=srv _kerberos._tcp.destination-domain.com.
• Using ADMT version 3.2 on Server 2019 or later — Old ADMT versions have bugs with newer Windows. Use ADMT 3.2 from Windows Server 2016, or use PowerShell with Migrate-ADObject cmdlets instead.

Prevention — stop this error before it starts

Next time you plan a domain migration, do this upfront:

• Create a separate forest for the destination — never try to move a domain into the same forest.
• Build the two-way forest trust before you even open ADMT. Document the credentials you'll use.
• Test with a single test user account first. Use ADMT's Test Migration mode to verify connectivity and permissions.
• Keep your ADMT version matched to your Windows version. I've seen ADMT 3.1 fail on Server 2022 — upgrade to 3.2 or use PowerShell.

One last tip: if you're still stuck, run admt connect from an elevated command prompt to manually test the trust — it'll tell you exactly where the connection breaks.