0X000020DB

Fix ERROR_DS_MISSING_EXPECTED_ATT (0x000020DB)

Windows Errors Intermediate 👁 6 views 📅 May 28, 2026

Active Directory can't find an attribute it expected in the directory schema. This usually means a schema update failed or a replication issue.

Quick Answer

Run repadmin /syncall /AdeP on the domain controller showing the error, then check the schema master for incomplete attribute definitions using ldp.exe. If that doesn't work, force-reload the schema cache with ntdsutil.

What's Going On?

Error 0x000020DB shows up when Active Directory tries to read an attribute from the directory schema — but that attribute's definition is incomplete or missing. Think of it like a dictionary missing a word you're trying to look up. This usually happens after a schema update (like installing Exchange, Skype for Business, or a Windows Server upgrade) that didn't finish cleanly, or when replication between domain controllers got interrupted mid-sync. You'll often see this in the Directory Service event log with Event ID 16651 or 1655, and it can cause LDAP queries to fail, or even crash services that depend on AD.

Fix Steps

  1. Check which attribute is missing.
    Open Event Viewer (eventvwr.msc). Go to Windows Logs > Directory Service. Look for events with ID 16651 or 1655 that mention "missing expected attribute." The event details will name the attribute (like msExchMailboxSecurityDescriptor or msRTCSIP-UserRoutingGroupId). Write that down.
  2. Verify the schema master is healthy.
    Log into the domain controller holding the Schema Master role (FSMO). Open Command Prompt as Admin. Run:
    netdom query fsmo
    If the schema master is offline, transfer the role to another DC.
  3. Force replication from schema master.
    On the affected domain controller, run:
    repadmin /syncall /AdeP
    Wait for it to complete. You should see "SyncAll completed successfully." If you get errors, run:
    repadmin /replicate <destination-DC> <source-schema-master-DC> DN=Schema,CN=Configuration,DC=<domain>,DC=<tld>
    Replace placeholders with your actual DC names and domain.
  4. Reload the schema cache.
    Open an elevated command prompt on the schema master. Type:
    ntdsutil
    At the ntdsutil prompt, type:
    schema management
    Then:
    load schema
    Wait for it to say "Schema loaded." Then type:
    reload schema cache
    After it completes, type quit twice to exit. This forces AD to rebuild the schema cache from the actual definitions.
  5. Restart AD services.
    On the affected DC, restart the Active Directory Domain Services service (NTDS) and the Kerberos Key Distribution Center service. Open Services.msc, right-click each, choose Restart. After that, run:
    repadmin /showrepl
    Check that replication shows "Last success" with a recent timestamp.

Alternative Fixes

If step 4 doesn't help: The schema master might have a corrupted attribute definition. Use ldp.exe to manually inspect the attribute. Run ldp.exe, connect to the schema master on port 389, bind as admin. Go to View > Tree, set BaseDN to CN=Schema,CN=Configuration,DC=<domain>,DC=<tld>. Find the attribute named in the event log. If it's missing the attributeID, attributeSyntax, or attributeSchema values, you'll need to delete and re-add it using ADSI Edit — but only if you have the exact schema definition from a backup or the original installation media. This is risky. Safer option: restore the schema master from a good backup.

Another alternative: Promote a new domain controller that replicates from a healthy DC, then demote the broken one. This rebuilds the schema from scratch.

Prevention Tip

Before any schema update (hotfix, Exchange, Skype, or feature upgrade), always take a System State backup of the schema master. After the update, run repadmin /syncall /AdeP on each DC and verify replication is clean within 24 hours. If you see replication warnings, fix them immediately — they rarely fix themselves.

Was this solution helpful?