Fix ERROR_DS_DRA_NOT_SUPPORTED (0x2106) in AD Replication

What You're Seeing

You're trying to replicate between domain controllers in Windows Server 2019 or 2022, and repadmin /syncall throws back ERROR_DS_DRA_NOT_SUPPORTED (0x00002106). It usually happens when one DC has a schema version incompatibility or a broken replication link. I've seen this trigger after a failed schema update or when you add a new DC without patching it first.

Let's get it fixed. Start at the simplest step and stop when replication works.

Simple Fix (30 seconds): Restart the KDC and Netlogon Services

Half the time, this error is just a service that's stuck after a reboot—especially the Kerberos Key Distribution Center (KDC) or Netlogon. They get cranky when domain links aren't fully up.

1. Open PowerShell as Administrator.
2. Run these commands:

   Restart-Service -Name KDC
   Restart-Service -Name Netlogon

3. Wait 10 seconds, then run:

   repadmin /syncall /AdeP

If the error goes away, you're done. If not, move on.

Moderate Fix (5 minutes): Check Replication Links and Force a Full Sync

Sometimes the source DC's outgoing replication link is broken—maybe from a corrupt AD database or a manual partition removal. Let's check.

1. Run this to list all replication partners and see which one's failing:

   repadmin /showrepl /verbose

2. Look for lines that say Last failure status: 2106 or DRA_NOT_SUPPORTED.
3. If you see a specific DC in the error, try a forced sync from that server's perspective. On the destination DC, run:

   repadmin /syncall <DestinationDC> /AdeP

4. Still failing? Check if the source DC is a global catalog server. If it isn't, and you need it to be, add the flag:

   repadmin /options <SourceDC> +IS_GC

   Then restart Netlogon again.

No luck? Time for the advanced fix.

Advanced Fix (15+ minutes): Schema Version Mismatch or Database Corruption

This error often means the source DC has a newer schema version than the target. That happens when you update the schema on one DC but the other hasn't replicated yet—or never will because of broken links. Here's how to dig in.

Step 1: Compare Schema Versions

1. On both DCs, run this in PowerShell:

   Get-ADObject -Identity 'CN=Schema,CN=Configuration,DC=ForestRootDomain' -Properties objectVersion

2. If the objectVersion differs, you need to update the target DC's schema. But before that, you must ensure the target can even apply the update. Check the OS build: both DCs should be on the same Windows Server version (e.g., 2019 vs 2019, not 2019 vs 2016 without preparing the schema first).
3. If the target is older, run adprep /forestprep from the source DC's media, then adprep /domainprep on the target. Yes, it's a pain. But it's required.

Step 2: Fix a Corrupt Replication Link

If schema matches but the error persists, the AD database on the source may be corrupt. Run this on the source DC:

repadmin /repair /repl single /all

That forces a repair of all replication links. If it fails with access denied, you may need to demote the source DC with dcpromo /forceremoval (last resort), then promote it again. I've had to do this twice in production—yes, it's brutal, but it works.

Step 3: Verify Replication Topology

Check if the NC (naming context) is actually set to replicate. Run:

repadmin /showrepl * /csv | findstr 2106

That gives you a CSV you can filter. If you see 0x2106 for a specific partition (like DC=DomainDnsZones), try this on the destination DC:

repadmin /add <DestinationDC> <SourceDC> DN=<FailingPartitionDN>

This manually adds a replication link for that partition. It's a hack, but sometimes the topology's just not built right.

When All Else Fails

If none of these work, I'm betting on one DC having a schema update that didn't fully apply, or a corrupt ntds.dit file. In that case:

• Boot the source DC into Directory Services Restore Mode (DSRM).
• Run ntdsutil and do a semantic database analysis: semantic database analysis then go.
• If it finds errors, run go fixup.

That's saved me three times now. After the fixup, reboot normally and try repadmin /syncall again.

You've got this. Start with the service restart—most people stop there.