Fix ERROR_DS_UNKNOWN_OPERATION (0X000020AD)

What's happening here

Error 0X000020AD means the domain controller received a request it couldn't process — the operation code didn't match anything it understands. Most of the time this shows up during replication, group policy updates, or when a tool like Active Directory Users and Computers throws a generic failure. The actual trigger is often a stale DNS record pointing to a retired DC, a replication partner that's out of sync, or a corrupted LDAP filter passed by a misconfigured app.

I've seen this on Windows Server 2016 and 2019 after a DC was demoted improperly — its DNS records lingered, and another DC tried to replicate to a ghost.

30-second fix: Quick DNS sanity check

Most cases of 0X000020AD start with a DNS lookup returning the wrong IP. Run this from the affected server or client:

nslookup -type=SRV _ldap._tcp.dc._msdcs.<yourdomain>.com 2>nul | findstr /i "srv hostname"

Replace <yourdomain> with your actual domain. You're looking for one valid DC name per SRV record. If you see multiple entries pointing to the same IP (a load balancer) or an IP that no longer exists, that's your problem.

Fix it by clearing the bad record from forward lookup zones. Open DNS Manager, find the stale A or SRV record, delete it. Then run this to force a reregister on the good DC:

ipconfig /registerdns

If that alone resolves the error, you're done. Skip the rest.

5-minute fix: Replication health check

If DNS is clean but the error persists, replication is the next suspect. Run this on the problematic DC:

repadmin /showrepl

Look for any line that says Last attempt failed or shows a timestamp from days ago. The error code in the failure column might be 0X000020AD itself, or something like 8453 (access denied) or 1722 (RPC unavailable).

The root cause here is often a lingering object — a DC that was deleted but its metadata remains in the configuration partition. Check with:

repadmin /removelingeringobjects <DC-name> <partition-DN> /advisory_mode

Run it in advisory mode first — that tells you what it would remove without doing anything. If it lists objects, run it again without /advisory_mode. Then restart the NTDS service on the affected DC:

net stop ntds && net start ntds

After the restart, run repadmin /syncall /AdeP to force a full sync. If the error goes away, you found it.

15+ minute fix: Metadata cleanup and schema recovery

When the first two steps didn't help, you're dealing with a deeper problem — corrupted metadata or a schema mismatch. This happens when a DC was force-removed from the domain without using dcpromo /forceremoval or ntdsutil cleanup.

First, identify the orphaned server. On a working DC, open an admin command prompt:

ntdsutil
metadata cleanup
connections
connect to server <working-DC>
quit
select operation target
list sites
select site 0
list servers in site
select server <orphaned-DC-index>
quit
remove selected server

That deletes the metadata for the dead DC. After that, check the schema version:

dsquery * cn=schema,cn=configuration,dc=<yourdomain>,dc=com -scope base -attr objectVersion

The value should match your forest functional level. For Windows Server 2019, it's 88. If it's lower (like 69 for Server 2012), you need to extend the schema with adprep /forestprep and adprep /domainprep — run those from the installation media on the schema master.

Still failing? The LDAP filter itself might be corrupt. Use ADSI Edit to connect to the Configuration partition, browse to CN=Configuration,CN=<yourdomain>,CN=Partitions, and check CN=<problem-DC> for any attribute with a value that looks like binary garbage (hex strings where you expect text). If you find one, note the attribute name and use ldifde to export, edit, and reimport that object.

Last resort: demote and repromote the affected DC. Back up the System State first. Run dcpromo /forceremoval from an elevated prompt, then clean metadata using the steps above, then run dcpromo again to add it back. This rebuilds the database from scratch.

Why step 3 works

The ntdsutil metadata cleanup removes the dead DC from the replication topology. Without that, the remaining DCs keep trying to contact the ghost, which responds with 0X000020AD because the operation it's being asked to do no longer makes sense on that removed server. The schema check is about compatibility — if the schema version is mismatched, the DC can't interpret newer LDAP controls, so it rejects them with this error. Schema update synchronizes the understanding across all DCs.

One gotcha: if you're using a third-party LDAP application that sends custom OID requests, check whether it's asking for an operation that your forest functional level doesn't support. Test by running the same request from LDP.exe against a known-good DC — if it fails there too, it's the app, not the DC. Patch the app or upgrade the functional level.