STATUS_DS_INCORRECT_ROLE_OWNER (0XC00002A9) – Fix FSMO Role Ownership

You're staring at 0XC00002A9, and it's not going away on its own.

The event log shows something like Active Directory Domain Services could not transfer the remaining data from the following server. Or maybe replication fails with STATUS_DS_INCORRECT_ROLE_OWNER. Here's the short version: a domain controller — likely the one holding a Flexible Single Master Operation (FSMO) role — is dead, unreachable, or has a corrupted copy of the partition. AD won't let you proceed with operations that depend on that role until it's reassigned.

The Fix: Seize the Stuck FSMO Role with ntdsutil

You need to be a Domain Admin on a live DC. Run PowerShell or cmd as Administrator. The target DC — the one that's alive — will become the new role owner.

1. Find out which role is stuck. Open an elevated command prompt and run:

netdom query fsmo

Look for any role where the owner is a server you know is dead or unreachable. You'll see something like Schema master: dead-dc.contoso.com. Make a note of that server name.

2. Open ntdsutil. In the same prompt, run:

ntdsutil
roles
connections
connect to server live-dc.contoso.com
quit

Replace live-dc.contoso.com with the name of the DC you're currently on. You're telling ntdsutil to target that server for the role change.

3. Seize the role. Type one of these commands depending on which role is stuck:

seize schema master
seize domain naming master
seize infrastructure master
seize RID master
seize PDC

You'll get a warning: Are you sure you want this server to become the role owner? Type yes. The command will try to transfer gracefully first; if the old owner doesn't respond, it forces the change.

4. Verify. Run netdom query fsmo again. The dead server should be gone from the list.

Why This Works

The reason ntdsutil's seize command works is because it operates on the actual directory partition that holds the role — the CN=Infrastructure container in the configuration partition. When the old role owner is offline, a normal transfer (via Active Directory Sites and Services or ntdsutil transfer) fails because AD tries to contact the old owner to negotiate the handoff. The seize command bypasses that handshake entirely. It writes the new role owner directly into the partition on the live DC, then replicates the change out to other DCs when they come back online. The old owner, if it ever returns, will detect that it's no longer the role owner and step down — but only if the old DC's copy of that partition is still consistent. If it's corrupt, you'll want to demote it instead.

Less Common Variations of the Same Issue

Not every 0XC00002A9 is a dead DC. Here are two scenarios that caught me off guard:

• Replication latency after a graceful transfer. You moved the role via GUI to another DC, but the old DC still shows as owner in some tools. This happens because AD replication is not instant — it can take 15 minutes or more across sites. The error appears transiently on the old DC until its inbound replication completes. No fix needed; just wait.
• Schema master on a DC that was forcibly demoted. If you ran dcpromo /forceremoval on a DC that held the schema master, Active Directory still believes that server owns the role — even though the server no longer exists. The seize command above is the only clean way out. Do not try to manually edit the fSMORoleOwner attribute in ADSI Edit unless you're comfortable with low-level directory surgery. One typo and you've hosed the partition.

Prevention: Don't Let This Happen Again

The root cause is almost always a DC that went down permanently without you transferring its roles first. Here's how to avoid the second time:

• Monitor FSMO health with a script. I run a PowerShell one-liner daily that checks each role owner responds to a ping and a lightweight LDAP query:

$roles = @('Schema', 'DomainNaming', 'PDC', 'RID', 'Infrastructure')
foreach ($role in $roles) {
  $owner = (Get-ADDomain | Select-Object "${role}Master")."${role}Master"
  if (-not (Test-Connection -ComputerName $owner -Count 1 -Quiet)) {
    Write-Warning "$role master $owner is unreachable!"
  }
}

• Plan decommissioning properly. Before you turn off a DC permanently, run ntdsutil roles transfer to move roles to another DC. If it won't boot, use the seize command while it's still on the network — before it's completely gone.
• Keep at least two DCs per domain. This is not just for redundancy; it ensures you have a live fallback to seize roles onto without scrambling to bring up a replacement.

One final note: 0XC00002A9 can also appear during domain join operations if the target domain's infrastructure master is offline. Same fix — seize the role on a reachable DC. I've seen this trip up sysadmins who assumed the error was on the client side. Nope. It's always a DC problem.