0X000020EF

Fix ERROR_DS_UNKNOWN_ERROR (0X000020EF) on Windows Server

Server & Cloud Intermediate 👁 9 views 📅 May 26, 2026

Active Directory replication fails with a generic unknown error due to lingering objects. Removing the offending DC from replication fixes it.

Quick Answer

Run repadmin /replsummary to find the failing DC, then use ntdsutil to remove it from Active Directory via metadata cleanup.

What's Actually Happening Here

ERROR_DS_UNKNOWN_ERROR (0X000020EF) shows up when a domain controller tries to replicate and hits a reference to an object that no longer exists — a lingering object. This usually means a server was demoted or died without cleanly removing its metadata from Active Directory. The directory service sees a replication partner in its site topology, tries to talk to it, and gets back nothing useful, so it throws this vague failure. I've seen this most often after someone force-removes a DC by just powering it off and running dcpromo /forceremoval without cleaning up.

Fix Steps

  1. Identify the failing DC
    Open an elevated command prompt on a functioning DC. Run:
    repadmin /replsummary. Look for any line showing a failure count next to a server name. That's your culprit.
  2. Check for lingering objects on that server
    On the same DC, run:
    repadmin /removelingeringobjects <FailingDCName> <NamingContext> /advisory_mode
    For example: repadmin /removelingeringobjects DC-SRV-01 "DC=yourdomain,DC=com" /advisory_mode. If it reports lingering objects, you'll need to force-remove them.
  3. Run metadata cleanup using ntdsutil
    This is the real fix. Open an elevated command prompt and run:
    ntdsutil
    Then at the ntdsutil: prompt:
    metadata cleanup
    connections
    connect to server <YourGoodDC>
    quit
    select operation target
    list domains
    select domain <number>
    list sites
    select site <number>
    list servers in site
    Find the failing server (often shows with GUID). Select it:
    select server <number>
    quit
    remove selected server
    Yes, confirm. Then type quit twice to exit.
  4. Force replication to propagate the change
    Run:
    repadmin /syncall /AdeP. This pushes the metadata cleanup to all other DCs.
  5. Verify replication is healthy
    Run repadmin /replsummary again. The error count should drop to zero.

Alternative Fixes If the Main One Fails

  • Use PowerShell to remove the AD object directly
    If ntdsutil throws errors, you can try:
    Remove-ADObject -Identity "CN=NTDS Settings,CN=<FailingDCName>,CN=Servers,CN=<SiteName>,CN=Sites,CN=Configuration,DC=yourdomain,DC=com" -Recursive. This is riskier — you're directly deleting AD objects. Only do this if ntdsutil refuses.
  • Lower the lingering object lifetime
    On a DC that still has extra dead references, you can temporarily set:
    repadmin /regkey <FailingDCName> +HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters LingeringObjectLifetime 0
    Then run repadmin /removelingeringobjects again without /advisory_mode. This forces removal, but reset that key to default (60 or 90 days) after.
  • Demote and re-promote the server
    If the failing DC is still online but broken, you can run dcpromo /forceremoval, then clean up metadata, then re-promote it fresh. This is a last resort — it's heavy but guaranteed to fix things.

Prevention Tip

Never force-demote a DC without cleaning up metadata. Always use dcpromo normally, or at minimum run ntdsutil metadata cleanup afterward. Also, check lingering objects quarterly with repadmin /removelingeringobjects * * /advisory_mode. Catches them before they become real problems.

Was this solution helpful?