ERROR_DS_REFUSING_FSMO_ROLES (0X000020F1) Fix

When does this error hit?

You're staring at a command prompt on a domain controller that's been offline for three days. You've already forced a demotion on the old DC, or it crashed and never recovered. Now you're trying to seize the FSMO roles—maybe the PDC emulator, the RID master, or the schema master—and boom: ERROR_DS_REFUSING_FSMO_ROLES (0x000020F1).

I've seen this most often in two scenarios:

• You're trying to seize roles from a DC that still thinks it's alive but unreachable (a "zombie" DC).
• You're running ntdsutil roles - connections - connect to server and the server you're connected to—the one you're on—refuses the seizure because it detects another DC already holds the role.

This error is infuriating because it feels like Active Directory is saying "nope" for no reason. But there's a reason—it's just buried in AD's internal checks.

Root cause in plain English

Active Directory's FSMO role seizure mechanism is intentionally cautious. When you attempt a seizure, the target DC must first try to contact the current role holder. If the current holder is still listed in AD but unreachable, the seizure fails with 0x000020F1. This prevents accidental role duplication, but it also means you can't just brute-force seize a role from a dead server.

Also, if you're connected to a DC that already holds the role you're trying to seize (maybe you're standing on the PDC emulator trying to seize the PDC emulator role), the command fails immediately. That one's a logic error, not a networking issue.

Fix it: Force the seizure the right way

Step 1: Identify the role holder and your target DC

Open an elevated command prompt on the DC where you want to hold the roles. Run:

netdom query fsmo

This shows where each FSMO role currently lives. Write down the names. If the server listed for a role is the one you're on, don't try to seize that role—you already have it.

Step 2: Connect to the target DC with explicit credentials

If you're logged in with domain admin credentials, that's fine, but sometimes a stale Kerberos ticket causes the refusal. Run klist purge first, then:

ntdsutil
roles
connections
connect to server <YourTargetDC>.yourdomain.local
quit

Replace <YourTargetDC> with the FQDN of the DC where you want the roles. Don't use the current role holder—you'll get the refusal immediately if you do.

Step 3: Seize each role one at a time

Still inside ntdsutil at the FSMO maintenance prompt, run these in order:

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

You'll get a warning dialog for each one. Click Yes to confirm. The seizure will proceed even if the old role holder is unreachable. This bypasses the refusal check because you're seizing, not transferring.

If you get 0x000020F1 during the seizure, you're still connected to the wrong server or that server already holds the role. Disconnect and reconnect to a different DC.

Step 4: Verify the roles moved

After all five roles are seized, run netdom query fsmo again. The list should show your target DC as the new owner for each role.

If the error still appears after the fix

Three things to check:

• DNS resolution: Can your target DC resolve its own FQDN? Run nslookup yourdc.yourdomain.local. If it fails, fix DNS first—check the NIC's DNS server setting points to a working DC, not itself.
• Time sync: Active Directory is vicious about time. If the target DC's clock is more than 5 minutes off from other DCs, FSMO operations fail. Sync it manually: w32tm /resync. If that fails, point it to an external time source like time.windows.com.
• Stale DC metadata: If the old role holder was removed improperly, its metadata still lives in AD. Use ntdsutil metadata cleanup to remove the dead server's references. After cleanup, the seizure should work.

One last thing: I've seen this error when the Windows Server version is mismatched between DCs—like trying to seize roles from Server 2008 R2 to Server 2022. It's rare, but if everything else checks out, consider upgrading all DCs to the same functional level.

You've got this. FSMO role seizures are always a bit tense, but once you know the trick—connect to the target DC, not the old holder—it's straightforward.