Fix ERROR_DS_AUX_CLS_TEST_FAIL (0X000020C5) Schema Update

What triggers this error

This error happens when you try to update the Active Directory schema — maybe you're adding a new attribute or modifying a class. The exact trigger is when a class in the auxiliaryClass list of another class doesn't exist or isn't actually an auxiliary class. For example, you might be extending the schema for an LDS application or a custom Exchange attribute.

The error code 0X000020C5 shows up as ERROR_DS_AUX_CLS_TEST_FAIL. You'll see it in the Event Viewer or in a tool like ldifde when importing a schema update file.

Cause 1: The class in the Aux Class list doesn't exist

This is the most common problem. You have a class definition that references an auxiliary class that isn't defined yet in the schema. The schema update process checks all class references, and if one is missing, it stops.

How to fix it

1. Open Active Directory Schema snap-in. You need Schema Admin rights. If you don't have the snap-in, register it with regsvr32 schmmgmt.dll on a Domain Controller.
2. Right-click Active Directory Schema and select Reload the Schema. This refreshes the cache.
3. Expand Classes and find the class you're trying to modify. Right-click it and go to Properties.
4. Click the Relationship tab. Look at the Auxiliary Classes list. Write down every class name in that list.
5. Now check each of those classes exists under Classes. If one is missing, that's your problem.
6. If a class is missing, you need to define it first. Use New -> Class and create that auxiliary class. Make sure you set its Class Type to Auxiliary.
7. After creating the missing class, try your schema update again. It should succeed now.

Cause 2: The class exists but isn't auxiliary

Sometimes the class is there, but it's defined as a structural or abstract class, not an auxiliary one. The schema only allows auxiliary classes in the Aux Class list.

How to fix it

1. In the Active Directory Schema snap-in, find the class that's in the Aux Class list.
2. Right-click it and select Properties.
3. Look at the Class Type dropdown. If it says Structural or Abstract, you can't use it as an auxiliary class.
4. You have two options here:

• Option A: Create a new auxiliary class that inherits from this class. Then use that new auxiliary class in your original class's Aux Class list.
• Option B: Change the existing class to auxiliary — but only if nothing else depends on it being structural. To change it, set the Class Type to Auxiliary. Then click Apply. You'll see a warning dialog saying this can break things. If you're sure, click Yes.

I prefer Option A because it's safer. You don't risk breaking other schema objects.

Cause 3: The Aux Class list has a typo or uses a display name

Schema updates often come from LDIF files. If someone hand-edited the file and typed the class name wrong, you get this error. Also, the Aux Class list uses the LDAP display name (the lDAPDisplayName attribute), not the common name or the friendly name.

How to fix it

1. Open the LDIF file you're importing with Notepad.
2. Search for auxiliaryClass: lines. These list the auxiliary classes.
3. Compare each name against the actual LDAP display names in the schema. You can get the LDAP display name by opening the class in the Schema snap-in and looking at the LDAP Display Name field.
4. Fix any typos in the LDIF file. Match the exact casing — LDAP display names are case-sensitive.
5. Save the file and try the import again.

One real-world example: I had a client whose LDIF file used userSecurityInformation instead of userSecurityInfo. The error was exactly 0X000020C5.

Quick-reference summary table

Once you fix the root cause, the schema update should apply without the error. If it still fails, check the Event Viewer under Directory Service for more details. The event ID is usually 1168 or 1169 for schema errors.