Fix ERROR_DS_NONEXISTENT_POSS_SUP (0X000020C6) on AD Schema
AD schema update fails because a class in the possSuperiors list doesn't exist. Usually a bad schema extension or replication lag. Here's the fix.
Cause 1: Schema Extension References a Class That Doesn't Exist Yet
The culprit here is almost always a schema extension that lists a class in the possSuperiors attribute before that class has actually been added to the schema. I've seen this a dozen times — someone fires off an LDIF file that adds a new auxiliary class and a structural class at the same time, but the structural class references the auxiliary class in its possSuperiors list, and the LDIF processes the structural class first. That's a guaranteed crash.
The fix is straightforward: you need to check the order of operations in your LDIF file or script. The class that appears in possSuperiors must already exist in the schema when the referencing class gets added. If you're using an LDIF file, split it into two files — one that adds the parent class, then another that adds the child class. Apply them in that order.
How to check which class is missing
- Open ADSI Edit on a domain controller with schema admin rights.
- Connect to the Schema naming context (CN=Schema,CN=Configuration,DC=yourdomain,DC=com).
- Find the class that failed — it's usually the one you were trying to add. Look at its
possSuperiorsattribute. - Each DN in that list must point to an existing class in the schema. If any DN doesn't resolve, that's your missing class.
If the missing class was supposed to be added but didn't get created, you'll need to re-run just that part of the extension. Don't try to delete the failed class — just fix the order and re-apply.
Cause 2: Replication Lag Between Domain Controllers
Sometimes the class was added, but on a different domain controller that hasn't replicated yet. You run the schema update on a DC that's a few seconds behind, and it throws 0x000020C6 because it can't see the class. This is more common than you'd think in multi-site environments with slow links.
Don't bother with waiting for automatic replication — force it. On the DC where you got the error, run this command:
repadmin /syncall /AdeP
That syncs the schema partition from its source partner. Wait for it to complete, then try your schema update again. If you're still getting the error, check event logs for replication errors. A stuck replication queue will cause this every time.
One trick I use: run repadmin /showrepl on the DC and look for the last successful replication time for the Schema partition. If it's more than 15 minutes old, your replication's stuck. Fix that first — otherwise no schema update will work.
Cause 3: Corrupted or Manually Edited Schema Attributes
This one's rare, but I've seen it — someone with too much access went into ADSI Edit and deleted or renamed a class that other classes depended on. Now any new class that tries to reference the missing one in possSuperiors throws the error. The system won't tell you which class is missing unless you dig.
You can find the orphaned reference by scanning the schema with a PowerShell script. Here's one I use:
Get-ADObject -Filter {objectClass -eq 'classSchema'} -Properties possSuperiors |
Where-Object {$_.possSuperiors -ne $null} |
ForEach-Object {
$_.possSuperiors | ForEach-Object {
if (-not (Get-ADObject -Filter {distinguishedName -eq $_})) {
Write-Warning "Missing class in possSuperiors of $($_.Name): $_"
}
}
}
If you find a missing reference, you've got two options:
- Restore from backup — restore the missing class from a system state backup of the schema partition. This is the cleanest fix.
- Remove the reference — edit the
possSuperiorsattribute on the class that's pointing to a dead class. Remove the bad DN. This is risky and I don't recommend it unless you're absolutely sure the missing class isn't needed.
If you go with option 2, use ADSI Edit, but take a snapshot of the schema partition first. One wrong edit and you'll break AD for every object of that class.
Quick-Reference Summary
| Cause | Symptom | Fix |
|---|---|---|
| Missing class in possSuperiors | Error occurs during schema extension | Reorder LDIF — apply parent class first |
| Replication lag | Error on one DC, not others | Run repadmin /syncall |
| Corrupted schema (deleted class) | Error with orphaned references | Restore from backup or remove bad ref |
This error is annoying but 90% of the time it's just bad ordering. Don't overthink it. Check the LDIF, check replication, and you'll be done in 10 minutes.
Was this solution helpful?