Fix ERROR_DS_COULDNT_CONTACT_FSMO (0X000020AF) in AD

You're stuck with this error and it's frustrating — let's get it fixed

I've seen this error a hundred times. It usually shows up when you're trying to transfer or seize an FSMO role, or when a domain controller boots up and can't find its master. The error message reads: "The requested Flexible Single Master Operations (FSMO) operation failed. The exact error code is: 0X000020AF." We're going to fix it in three steps, starting with the most likely culprit.

Step 1: Identify the FSMO role holder — and check if it's alive

First, you need to know which server holds the FSMO role you're trying to touch. Open Command Prompt as Administrator on any domain controller and run:

netdom query fsmo

After hitting Enter, you should see a list like this:

Schema master — DC01.domain.local
Domain naming master — DC01.domain.local
PDC — DC02.domain.local
RID pool manager — DC01.domain.local
Infrastructure master — DC02.domain.local

Make a note of which server holds the role you're having trouble with. Then ping that server by its fully qualified domain name (FQDN), like this:

ping DC01.domain.local

If you get replies, the server is alive. If you get "Destination host unreachable" or "Request timed out," that server is down or unreachable on the network. That's your problem.

Step 2: Check DNS — this is where 90% of FSMO errors live

If the server pings back fine, the next stop is DNS. The domain controller you're running the operation from has to resolve the role holder's DNS name correctly. Run this:

nslookup DC01.domain.local

Look at the response. If it returns an IP address that matches the actual IP of that server, you're good. If it returns a different IP, or no IP, or shows "server failed," DNS is misconfigured.

Here's the fix: open DNS Manager on the domain controller you're working from. Go to Forward Lookup Zones > your domain. Look for the host record (A record) for the FSMO role holder. If it's missing or points to the wrong IP, right-click and create it, or update it with the correct IP.

After making the change, run ipconfig /flushdns and then try your FSMO operation again. That usually clears it right up.

Step 3: The role holder is dead — seize the role

If the server is down and can't be brought back, you need to seize the role using ntdsutil. This is an advanced step, so be careful — you're forcing the role onto another controller.

Open Command Prompt as Administrator on the domain controller that will take the role.
Type ntdsutil and press Enter.
At the ntdsutil: prompt, type roles and press Enter.
At the fsmo maintenance: prompt, type connections and press Enter.
Type connect to server localhost and press Enter. You should see "Binding to localhost..." and then "Connected to localhost using credentials of locally logged on user."
Type quit to go back to the fsmo maintenance: prompt.
Now type the seize command for the role you need. For example, to seize the PDC role: seize PDC. Press Enter.

It'll warn you that this is a dangerous operation. Type y to confirm. After a few seconds, you'll see "Transfer of FSMO successful." Close ntdsutil by typing quit twice. Then reboot the server you seized it to — I've found that resolves lingering issues.

Why this worked

The error 0X000020AF happens because the domain controller making the request can't talk to the FSMO role holder over RPC (Remote Procedure Call). The most common reasons are DNS not resolving the name correctly, or the role holder being offline. By fixing DNS, you fix the routing. By seizing the role, you replace a dead server with a live one. That's it — it's not magic, it's networking.

Less common variations of the same issue

I've also seen this error pop up when: the firewall on the role holder is blocking RPC ports (TCP 135 and dynamic ports above 1024); the time is out of sync by more than 5 minutes between domain controllers; or the role holder's Netlogon service is stopped. Check each of these if the steps above didn't work.

Another oddball case: the domain controller you're on is itself the role holder, but its own DNS points to itself and the server's loopback IP is wrong. If you're running the command on the server that should hold the role, run ipconfig /all and make sure its DNS server is set to another domain controller, not the loopback address (127.0.0.1).

Prevention — keep this from coming back

Set up redundant DNS servers. Every domain controller should point to a different DC for DNS, not to itself. That way, if one goes down, you can still resolve the FSMO holder. Also, monitor your domain controllers' uptime. If a server has been offline for more than a few days, seize its roles proactively before you need them in an emergency. And finally, run dcdiag weekly. It'll catch DNS and connectivity issues before they turn into 0X000020AF.