Fix ERROR_DS_EXISTS_IN_SUB_CLS (0X000020CA): Class used as subclass

Quick answer

Delete or reclassify all schema classes that have the failing class in their subClassOf attribute, then delete the target class.

Why you're seeing this

Active Directory schemas form a hierarchy. Each class can have one parent (the subClassOf attribute) and multiple children. When you try to delete a class that still has child classes pointing to it, the schema engine throws ERROR_DS_EXISTS_IN_SUB_CLS (0X000020CA). It's a safety mechanism—deleting the parent would orphan those subclasses.

This typically happens when cleaning up custom schema classes after decommissioning an application or during a schema migration gone wrong. I've seen it most often with Exchange or Lync/Skype schema extensions that weren't fully removed.

Don't try to force-delete the class with LDAP commands—you'll just get the same error. You have to fix the inheritance chain first.

Before you start

• You need Schema Admins group membership. This isn't optional—standard Domain Admins won't cut it.
• Enable the Schema Management snap-in. Run regsvr32 schmmgmt.dll from an elevated command prompt, then add the snap-in to MMC.
• Back up your schema. In MMC, right-click Active Directory Schema and select Back Up Schema. Store the backup somewhere safe.
• Have a rollback plan. Schema changes are replicated to all domain controllers and are permanent unless you restore from backup.

Fix steps

Step 1: Identify the problem class

Open the Schema snap-in. Expand the tree, click Classes, and find the class that matches the error. Write down its name exactly—case matters in LDAP.

Step 2: Find all subclasses

Right-click the class and select Properties. Go to the Relationships tab. The Possible superiors list shows parent classes—ignore those. You need the Subclass of field, which shows the parent. But you're looking for children.

The Schema snap-in doesn't show children directly. Use ADSI Edit instead:

1. Open ADSI Edit (if not installed, add it via RSAT).
2. Right-click ADSI Edit and choose Connect to.
3. In the Connection Settings, under Select a well known Naming Context, pick Schema.
4. Navigate to CN=Schema,CN=Configuration,DC=yourdomain,DC=com.
5. Expand the tree. You'll see all schema objects.
6. Find your problem class—look for CN=YourClassName.

Now run this LDAP query to find all classes that list your class as their parent:

(&(objectClass=classSchema)(subClassOf=CN=YourClassName,CN=Schema,CN=Configuration,DC=yourdomain,DC=com))

In ADSI Edit, right-click the Schema container, choose Find, paste that query, and search. The results show all direct subclasses. Write down each one.

Step 3: Remove or reclassify each subclass

For each subclass, you have two options:

• Delete it — if the subclass is no longer needed (e.g., from an uninstalled app).
• Re-parent it — change its subClassOf attribute to a different class, like top.

To re-parent a subclass using ADSI Edit:

1. Right-click the subclass object and choose Properties.
2. Find the subClassOf attribute. Double-click it.
3. Replace the current DN with the DN of the new parent class, for example: CN=Top,CN=Schema,CN=Configuration,DC=yourdomain,DC=com.
4. Click OK and then Apply.

I usually re-parent to top instead of deleting, unless I'm sure the app is gone. Deleting a subclass can break object instances that use that class.

Step 4: Delete the original class

Once all subclasses are removed or re-parented, go back to the Schema snap-in. Right-click your target class and choose Delete. Confirm the prompt. The error should be gone.

Alternative fix: Use LDIFDE

If you prefer command-line or need to script this across multiple domain controllers, use LDIFDE:

1. Export the schema class you want to delete:
   ldifde -f export.ldf -d CN=YourClassName,CN=Schema,CN=Configuration,DC=yourdomain,DC=com
2. Edit the exported .ldf file. Change changetype: add to changetype: delete.
3. Run the import:
   ldifde -i -f export.ldf

This won't work if subclasses still exist—you'll get the same error. But it's useful for bulk operations once you've cleaned up the hierarchy.

Prevention tip

Before you delete a schema class, always check dependencies first. Use the LDAP query from Step 2 as a quick pre-flight check. I also recommend keeping a running list of all custom schema classes with their parent-child relationships—documenting this when you install an application saves you hours of hunting later.

If you're decommissioning an application, run its official uninstaller first. Apps like Exchange and Skype for Business have cleanup scripts that remove their schema extensions. Relying on those scripts is safer than manual deletion.