Fix ERROR_DS_INCORRECT_ROLE_OWNER (0X00002012) - 3 Causes

What This Error Means

ERROR_DS_INCORRECT_ROLE_OWNER (0X00002012) pops up when a domain controller tries to write to Active Directory but points to the wrong FSMO role owner. Usually happens during demotion, promotion, or when you move FSMO roles and don’t clean up properly. The DC thinks the role owner is a server that’s dead, unreachable, or never existed.

Cause #1: Stale NTDS Settings for a Dead Domain Controller

This is the most common culprit. You’ve removed a domain controller — maybe it crashed, maybe you decommissioned it — but its NTDS settings object still lingers in AD. When another DC tries to replicate or validate roles, it hits that old entry and throws 0X00002012.

I see this most often after a forced demotion with dcpromo /forceremoval on Server 2008 R2 or 2012 R2. The server’s gone, but AD metadata says otherwise.

How to Fix It

Open ADSI Edit. Connect to the CN=Configuration,DC=yourdomain,DC=com partition.
Navigate to: CN=Services,CN=Microsoft Exchange,CN=yourorg,CN=Administrative Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Servers — wait, wrong tree. For AD, go to: CN=Sites,CN=Default-First-Site-Name,CN=Servers,CN=your-old-DC,CN=NTDS Settings.
Right-click the NTDS Settings object under the dead DC and choose Delete.
Confirm the deletion. You’ll get a warning — ignore it.
If ADSI Edit won’t let you delete it, run ntdsutil from an elevated command prompt:

ntdsutil
metadata cleanup
remove selected server
connections
connect to server your-valid-DC.yourdomain.com
quit
select operation target
list domains
select domain 0
list sites
select site 0
list servers in site
select server 0
quit
remove selected server

Pick the dead DC from the list and remove it. This nukes the stale metadata.

Pro tip: Don’t skip the list servers in site step. I’ve seen admins accidentally remove a live DC. Always double-check the server name.

Cause #2: Replication Failures After a FSMO Role Transfer

You moved the Schema Master or Domain Naming Master from one DC to another, but replication didn’t complete before someone tried to use it. The error surfaces when a DC contacts the old role owner, which either doesn’t have the latest changes or is offline.

I’ve seen this most often on Server 2016 environments where firewalls block RPC ports (135, 49152-65535) between sites. Replication fails silently, and the error shows up days later.

How to Fix It

Check replication status on the new role owner:

repadmin /showrepl

Look for Last success times. If any inbound replication from the old role owner shows fail, that’s your problem.

Fix replication with the old DC (if it’s still online):

repadmin /syncall your-new-DC /AdeP

If the old DC is dead, seize the FSMO roles cleanly. Run on a surviving DC:

ntdsutil
roles
connections
connect to server your-new-DC.yourdomain.com
quit
seize schema master
seize naming master
seize RID master
seize infrastructure master
seize PDC
quit
quit

Using seize (not transfer) is safe here — it forcefully takes the role and removes the old owner from AD. Do this even if you think the old DC might come back. Don’t wait.

Note: The Infrastructure Master role is tricky. If your domain is single-domain (no child domains), it’s fine on any DC. If you have multiple domains, keep it on a DC that’s not a global catalog server.

Cause #3: Corrupted NTDS Database on a Replica DC

Less common, but I’ve hit it twice on Server 2012 R2. The NTDS.DIT file gets corrupted — maybe from a dirty shutdown, a disk error, or a bad VSS snapshot. The DC tries to update its local copy, finds the role owner mismatch, and throws 0X00002012.

You’ll usually see this alongside event ID 1126 (NTDS) in the event log: “The attempt to update the Active Directory database has failed with error 8451.”

How to Fix It

First, rule out hardware. Check the disk where NTDS.DIT lives with chkdsk /f. No point fixing AD on a dying drive.
Run a database integrity check in Directory Services Restore Mode (DSRM):

ntdsutil
files
integrity

If it finds corruption, run:

repair

This can take an hour for large databases. Be patient.

If integrity passes but the error persists, do a semantic database analysis:

ntdsutil
semantic database analysis
go

If all else fails, promote a new DC and demote the broken one. That’s the nuclear option, but it’s fast and reliable. Use dcpromo /forceremoval if the DC won’t demote cleanly, then clean up metadata as in Cause #1.

Quick-Reference Summary Table

Cause	Common Scenario	Fix
Stale NTDS settings	Dead DC still in AD after forced demotion	ADSI Edit deletion or ntdsutil metadata cleanup
Replication failure after FSMO transfer	Firewall blocks RPC; old DC offline	Seize roles with ntdsutil, fix replication
Corrupted NTDS.DIT	Dirty shutdown or disk error on replica DC	Run integrity/repair in DSRM; re-promote DC if needed

One last thing: always check DNS before diving into these fixes. A DC that can’t resolve the role owner’s name will throw 0X00002012 too. Clear the DNS cache with ipconfig /flushdns and verify the SRV records for _ldap._tcp.dc._msdcs.yourdomain.com point to the right DCs. Nine times out of ten, it’s stale metadata. Start there.