Active Directory: Fix ERROR_DS_EXISTS_IN_POSS_SUP (0X000020CB)

What triggers this error

You get ERROR_DS_EXISTS_IN_POSS_SUP (0X000020CB) when you try to delete a class from the Active Directory schema because some other class still lists yours as a possible superior (possSuperior). The schema says “I can’t delete you — you’re still the parent of something.”

This usually happens when you’ve custom-extended the schema with new classes and later try to clean up. I had a client last month who tried to delete an old contoso-Device class and hit this. Turned out a custom contoso-Printer class still had contoso-Device in its possSuperiors list.

Cause #1: The class is listed in another class’s possSuperior attribute

This is the most common cause by far. Every class in AD has a possSuperiors attribute that lists which classes can be its parent in the hierarchy. If you’re trying to delete class A, but class B has class A listed as a possible superior, deletion fails.

How to find the offending class

1. Open ADSI Edit (install it via Server Manager if not already there).
2. Connect to the Schema naming context (CN=Schema,CN=Configuration,DC=yourdomain,DC=com).
3. Browse to CN=Schema,CN=Configuration,DC=yourdomain,DC=com.
4. Right-click the Schema container and choose Find.
5. In the search field, enter the ldapDisplayName of the class you’re trying to delete. (If you don’t know it, look in the CN=Schema folder — classes have ldapDisplayName values like user, group, contoso-Device.)
6. Double-click your class, go to the Attribute Editor tab, and scroll to possSuperiors. You’ll see a list of classes that are allowed as parents — but you need to find who lists *you*. That’s not here.

The real trick: run a query against all schema classes looking for yours in their possSuperiors list. Use this LDAP query:

(&(objectClass=classSchema)(possSuperiors=CN=Your-ClassName,CN=Schema,CN=Configuration,DC=yourdomain,DC=com))

Replace Your-ClassName with the CN (not ldapDisplayName) of your class. In ADSI Edit, right-click the Schema container, choose New > Query, paste the query, and run it. You’ll get a list of classes that reference your class.

Fix it

For each class returned:

1. Double-click that class in the results.
2. Go to the Attribute Editor tab.
3. Find possSuperiors and click Edit.
4. Remove the entry that references your class.
5. Click OK.

Now try deleting your original class again. It should work.

Cause #2: The class is referenced in systemPossSuperiors (read-only, but still blocks deletion)

This one’s rare but real. Microsoft hard-codes some classes as possible superiors for base schema classes like user or organizationalUnit. You cannot modify those via ADSI Edit — they’re marked as system-only. If your custom class is listed there, you’re stuck.

How to check: look at the systemPossSuperiors attribute on a system class. For example, right-click CN=Organizational-Unit, open Attribute Editor, and check systemPossSuperiors. If your class shows up, you can’t delete it without editing the schema directly via LDAP (which isn’t supported).

Real-world workaround

I’ve only seen this once, with a custom class that was added as a possible superior to organizationalUnit via a script. The only supported way out: restore from backup or use a supported schema modification tool like ldifde with a carefully crafted LDIF that removes the attribute. But honestly? If you’re here, you probably broke the schema in a lab. Wipe and rebuild is faster.

Cause #3: The class is being used by an existing object (unlikely but possible)

The error message specifically says “possSuperior,” not “in use.” But I’ve seen cases where an admin misread the error and chased ghosts. If you have an object in the directory that actually uses your class as its parent class (via objectClass), deletion will also fail — but with a different error code (0X000020CB is purely possSuperior).

To rule this out, search your domain for objects whose objectClass includes your class:

(objectClass=contoso-Device)

Replace with your class’s ldapDisplayName. If objects come back, delete them first, then retry.

Quick-reference table