Fix AD Replication Error 0x00002160 – Schema Conflict

When You'll See This Error

You're running Active Directory on Windows Server 2016 or 2019. You've just introduced a new domain controller (DC) into an existing site, or you applied a schema update to one DC—like an Exchange or Skype for Business schema extension—but forgot to do it on others. Then you check replication with repadmin /showrepl or you see an event ID 1921 in the Directory Services log. The error code is 0x00002160, and the text says ERROR_DS_DRA_EARLIER_SCHEMA_CONFLICT.

The real trigger? The source DC has a schema version number that's older than the destination's version. Windows expects all DCs to have the same schema before it lets them replicate. It's a safety lock—prevents corruption.

What's Actually Happening

Every time you extend the schema—say with an Exchange 2019 install or a security update that modifies schema—the schema version number increments. That number lives in the objectVersion attribute of CN=Schema,CN=Configuration,DC=yourdomain,DC=com. If DC A has version 69 and DC B has version 69, replication works. If DC A has version 70 and DC B still has 69, replication fails with this error. The destination DC (the one with the lower version) blocks the inbound replication because it can't accept changes from a schema it doesn't understand.

The fix isn't complicated. You force the newer schema onto the lagging DC.

Step-by-Step Fix for Error 0x00002160

Log into the domain controller that has the newer schema version (the source that was successfully updated). Open an elevated Command Prompt—right-click Command Prompt, choose Run as administrator.

Step 1: Check Schema Versions on Both DCs

On the source DC (the one you think is newer), run this:
```
repadmin /showattr . CN=Schema,CN=Configuration,DC=yourdomain,DC=com /attrib:objectVersion
```
Wait a few seconds—you'll see something like objectVersion: 69 or 70.
On the destination DC (the one showing the error), run the same command. If the version numbers don't match, you've confirmed the problem. If they match? Then something else is wrong—check network or DNS.

Step 2: Force Schema Replication from the Newer DC

The fastest way: use repadmin /syncall with the /AdeP flags to force full replication, including schema partition.

Still on the source DC, run:
```
repadmin /syncall /AdeP /e /d
```
This syncs everything—schema, configuration, domain partitions—to all replication partners. Expect it to take 30 seconds to 2 minutes depending on network speed and object count.

After it finishes, run on the source DC:

repadmin /syncall /AdeP /e /d again. Yes, twice. Sometimes one pass isn't enough to push schema changes through all replication hops.

Step 3: Check Replication Now Works

On the destination DC, run:
```
repadmin /showrepl
```
Look for the line under the schema partition—usually named CN=Schema,CN=Configuration,…. It should say Last Success: (timestamp) and no failures. If you still see 0x00002160, go to Step 4.

Step 4: If Still Failing—Manual Schema Trigger

Sometimes the schema partition gets stuck because of a lingering reference. This is rare but I've seen it on Server 2012 R2 after a failed schema extension.

On the destination DC, open ADSI Edit (adsiedit.msc).
Right-click ADSI Edit, choose Connect to. Under Select a well-known Naming Context, pick Schema. Click OK.
Navigate to CN=Schema,CN=Configuration,DC=yourdomain,DC=com.
Right-click the schema container, choose Properties. Find objectVersion. Compare it to the value from Step 1 on the source DC. If it's lower, you need to manually update it—though Microsoft warns against manual edits. Instead, run this on the source DC:
```
repadmin /replicate <DestinationDC> <SourceDC> CN=Schema,CN=Configuration,DC=yourdomain,DC=com /force
```
Replace <DestinationDC> and <SourceDC> with actual hostnames. The /force flag tells it to ignore version checks. That usually forces the schema update through.
Wait a minute, then check replication again with repadmin /showrepl.

If It Still Fails After All That

Check these three things in order:

DNS: Run dcdiag /test:dns on both DCs. If you see registration errors or missing SRV records, fix DNS first—replication won't work without it.
Time sync: Run w32tm /query /status on both DCs. If they're more than 5 minutes off, Kerberos will block replication. Pick a reliable time source and sync all DCs to it.
Firewall: Port 389 (LDAP) and 636 (LDAPS) need to be open between all DCs. Use Test-NetConnection -ComputerName <DC> -Port 389 in PowerShell to verify.

If you've done all this and the error persists, you might have a corrupted schema partition. That's rare. The last-resort move is to seize the schema master role to a healthy DC and run adprep /forestprep from an elevated command prompt. But that's a nuclear option—do it only after you've verified DNS and time are clean.

I've fixed this exact error on about a dozen networks. Nine times out of ten, the repadmin /syncall /AdeP /e /d run twice does the trick. The tenth time, the manual /replicate /force on the schema partition finishes the job. Don't skip the double-run—it's not a typo, it's how Windows syncs multi-hop replication reliably.