Fix ERROR_DS_EXISTS_IN_AUX_CLS (0X000020C9) Active Directory

This error is a pain — I know

You're cleaning up your Active Directory schema, trying to delete a class, and bam — error 0X000020C9: Class is used as an auxiliary class. I've been there. It's frustrating because the error doesn't tell you which class is blocking it. Let's fix that.

Step-by-step fix

1. Open ADSI Edit — go to Server Manager > Tools > ADSI Edit. Connect to the Schema partition (right-click ADSI Edit > Connect to... > select Schema).
2. Find the class you want to delete — expand CN=Schema,CN=Configuration,DC=yourdomain,DC=com. Look for the class under CN=Class-Schema.
3. Check the auxiliaryClass attribute — right-click the class > Properties. Look for the attribute auxiliaryClass (not subClassOf). If it's set to some class, that class is blocking your delete. Write down the value.
4. Find the blocking class — search for that auxiliary class name in the schema tree. Open it, check its possSuperiors attribute — that lists all classes that use it as an aux class. Remove your target class from that list.
5. Delete the auxiliary class reference — in the blocking class, clear the auxiliaryClass attribute value. Set it to <not set>.
6. Now delete your original class — go back, right-click, Delete. Should work this time.

Why this works

Active Directory schema doesn't let you delete a class that's still referenced as an auxiliary class by another class. It's a safety thing — otherwise you'd break all objects using that aux class. The auxiliaryClass attribute on the blocking class is the link. Once you remove it, the schema says "okay, nothing depends on this class, you can delete it."

I've seen this mostly happen when someone manually edited schema (like adding a custom attribute to user class) and then tried to undo their work. The auxiliaryClass attribute is the culprit 9 times out of 10.

Less common variations

Sometimes the blocking class isn't directly listed in auxiliaryClass. Check the systemAuxiliaryClass attribute too — that's for system-defined classes. If that's set, you can't delete it without first disabling the schema modification's safety net. Don't do that unless you're on a lab environment.

Another rare case: the class is used as a subClassOf for another class. If you try to delete a parent class that still has subclasses, you'll get a different error (0x000020C8 usually). But the fix is similar — remove the subclass references first.

I once spent two hours hunting this because the blocking class was in a different OU — I forgot I'd moved it. Lesson: always check the full schema tree. Use the cn attribute to search broadly.

Prevent this from happening again

• Always plan schema changes — before adding an auxiliary class, know which classes will use it. Document it in a spreadsheet.
• Use a lab first — test schema changes in a sandbox AD before touching production. You can roll back easily there.
• Remove references before deleting — when you're done with a custom class, always check auxiliaryClass and systemAuxiliaryClass on all classes that might reference it. Then remove them.
• Don't edit schema manually unless you have to — use scripts or tools like the Schema Manager MMC snap-in. They prompt you before breaking things.

That's it. You should be able to delete that class now. If you still see the error, double-check you didn't miss any possSuperiors references — those can also hold a reference. Good luck.