Active Directory Role Transfer Fails With 0X000020F3

When Does This Error Show Up?

You're trying to move the FSMO roles from a domain controller that's failing. Maybe it crashed. Maybe it's offline for good. Or maybe it's sitting there with a corrupted OS refusing to boot. You open 'Active Directory Users and Computers', right-click the new DC, pick 'Operations Masters', and try to transfer the RID master or PDC emulator role. Then you get this error: 0X000020F3 (ERROR_DS_UNABLE_TO_SURRENDER_ROLES).

I had a client last month whose 2012 R2 DC had a hard drive failure. They replaced the drive but couldn't recover the old server. When they tried to move the schema master role to a new 2019 server, this error stopped them cold. The old DC was dead, but AD still thought it was alive and wouldn't let the roles go.

What's Really Going On?

The error means the current role holder can't give up the role. It's supposed to be simple: you ask it to transfer, it says okay, role moves. But when the DC is offline, stuck, or corrupted, it never sends that 'okay' signal. Windows won't force the transfer because it's waiting for a proper handshake from the old DC. That handshake never comes, so you get the error.

This happens in two common situations:

• The old DC is completely dead — no network, no boot.
• The old DC is alive but has a broken Active Directory database — it can't process the transfer request.

Either way, you can't transfer roles normally. You have to seize them instead of transferring them. Seizing forcibly takes the role from the old DC without asking permission.

How to Fix It: Seizing the FSMO Roles

This fix uses the command-line tool ntdsutil.exe. It's built into Windows Server. Don't worry — it's straightforward. You'll do this on the new domain controller that you want to hold the roles.

1. Open an Elevated Command Prompt

   Press Windows Key + X and pick 'Command Prompt (Admin)' or 'Windows PowerShell (Admin)'. You need admin rights on the new DC.

2. Start ntdsutil

   Type ntdsutil and press Enter. You'll see the ntdsutil prompt.

   ntdsutil

3. Go to the Roles Section

   Type roles and press Enter.

   roles

4. Connect to the New DC

   Type connections, then press Enter.

   connections

   Now type connect to server YOUR_NEW_DC_NAME (replace with the actual server name, like DC2). Press Enter.

   connect to server DC2

   Type quit to go back to the roles menu. Press Enter.

   quit

5. Seize Each Role

   Now you'll take the roles one by one. Start with the PDC emulator. Type seize pdc and press Enter. A warning will pop up — type yes to confirm.

   seize pdc

   Repeat for the other roles:

   seize rid master
   seize infrastructure master
   seize schema master
   seize naming master

   For each one, confirm with yes. The naming master is also called the domain naming master in some docs — same thing.

6. Clean Up

   Type quit twice to exit ntdsutil.

   quit
   quit

That's it. The roles are now on your new DC. You didn't ask the old DC for permission — you just took them. This is the right move when the old DC is gone for good.

What If It Still Fails?

Seizing roles almost always works. But if the seize command itself fails, here's why:

• Network issue: Make sure your new DC can reach the old DC's IP. Even if the old DC is dead, sometimes a firewall or DNS problem blocks the connection. Check with ping OLD_DC_IP and nslookup OLD_DC_NAME. If you can't reach it, you can still force the seize by adding the /force flag in some cases, but the normal seize command should work.
• Old DC is still alive but broken: If the old DC is booted but has a corrupt AD database, you might need to demote it first. But since you're seizing, this shouldn't block you. Seize doesn't require the old DC to respond. If it does fail, reboot the old DC (if you can) and try the seize again. Sometimes a reboot clears a stuck state.
• Replication issue: If AD replication between DCs is broken, the seize might succeed but changes won't replicate. Run repadmin /syncall on the new DC to force replication after the seize.

After seizing, check that the roles are on the new DC. Open 'Active Directory Users and Computers', go to Operations Masters, and look at each tab. If you see your new DC listed, you're good.

One Last Thing

Seizing roles is a last resort. It basically tells AD 'the old DC is dead, stop waiting'. But if the old DC ever comes back online without being properly demoted, it can cause conflicts. So once you've seized the roles, make sure the old DC is either demoted cleanly (if it's still usable) or completely off the network forever. I've seen a zombie DC come back and start handing out old passwords — not fun.

If the old DC is still running but broken, you can demote it safely. On the old DC, run dcpromo /forceremoval (if it's 2008 or 2008 R2) or use Server Manager to remove AD DS (2012 and later). This cleans up its metadata. But if it's dead, just seize and move on.