Fix ERROR_DS_DRA_SCHEMA_CONFLICT (0x215F) in AD Replication

Quick answer

If you're in a hurry: run adprep /forestprep and adprep /domainprep on the schema master, then use repadmin /syncall to force replication. If that doesn't work, seize the schema master role to a newer DC.

What's actually going on here

This error (0X0000215F — also known as ERROR_DS_DRA_SCHEMA_CONFLICT) shows up when two domain controllers can't replicate because their schema versions don't match. Think of the schema as the blueprint for Active Directory — it defines what objects (users, computers, groups) look like. When you add a new DC or upgrade the OS (say from Server 2012 R2 to Server 2019), the schema gets updated. If the DC that holds the schema master role hasn't been updated, the other DCs won't replicate with it.

Had a client last month who added a Server 2022 DC to a 2012 R2 domain without running adprep first. The new DC couldn't replicate inbound, and the old ones threw this exact error in the event log. Took me 20 minutes to clean up.

Fix steps

1. Identify the schema master
   Open a command prompt as admin on any DC and run:
   netdom query fsmo
   Look for "Schema master" — that's your target. If it's the same DC throwing the error, you need to seize the role (see alternative fix below).
2. Update the schema
   On the schema master DC, insert the Windows Server installation media for the newest OS in your environment. Open an admin CMD and run:
   adprep /forestprep
adprep /domainprep
   If you have read-only domain controllers, also run:
   adprep /rodcprep
   Yes, you need to do this even if you think the schema is already updated — I've seen the version number stay the same but the schema engine not sync correctly.
3. Force replication
   Back on your DC with the error, run:
   repadmin /syncall /AdeP
   This syncs everything from the schema master. If it works, you'll see a success message. If not, check the event log for additional errors.
4. Verify
   Open Active Directory Sites and Services, right-click your domain, and select "Check Replication Topology" — no errors across all DCs means you're fixed.

Alternative fix: seize the schema master role

If the schema master DC is dead or can't be updated (say it's running an old OS you can't upgrade), you need to move the role to a healthy DC.

1. On a working DC, open an admin CMD and run:
   ntdsutil
roles
connections
connect to server <yourWorkingDC>
quit
seize schema master
   This forces the role to the new DC. Use this only if the original schema master is unrecoverable — it's not a clean transfer.
2. Then run adprep /forestprep on the new schema master to ensure the schema is current.

One thing: if you're running a mixed environment (Server 2008 R2 with Server 2019), you might hit schema update blocks. I've seen adprep fail because the old DC didn't have the right SP or hotfix. In that case, patch the old DC first or decommission it.

Prevention tip

Before adding any new DC to your domain, always run adprep /forestprep and domainprep from the new OS media on the schema master. Don't assume the domain is "up to date" — schema versions vary by OS build. A quick repadmin /showrepl on each DC before deployment can save you hours.

Real-world example: I once spent two days troubleshooting this error across a 20-site company. Turned out someone had upgraded the PDC emulator to Server 2016 but never updated the schema. Ran adprep, forced replication, and everything synced within 10 minutes. The lesson: schema updates are not optional — they're the foundation of AD health.

If you're still stuck after these steps, check the event log for error IDs 1989 or 1992 — those usually point to network-level replication issues, not schema problems.