Fix ERROR_DS_EXISTS_IN_MAY_HAVE (0x000020C2) in AD

You get this error when you try to delete a custom attribute from the Active Directory schema, but the schema master says "nope — this attribute is still referenced by at least one class in its mayContain list." This typically happens after you've extended the schema with custom attributes, then try to clean up old ones. The trigger is almost always an ldap_delete or a right-click delete in the Schema Management snap-in that returns error 0x000020C2.

What's actually happening

Every attribute in the schema can be attached to a class (like user or computer) in two ways: mustContain (required) or mayContain (optional). The error specifically says the attribute is in a mayContain list — not mustContain. This is important because the fix differs. The schema master checks this before allowing deletion, and it refuses because removing the attribute would break the class definition's integrity.

The real pain point: you don't know which class holds the reference. The error message only tells you the attribute ID, not the class. You have to hunt it down.

The fix — step by step

You need Schema Admins membership and a machine with ADSI Edit installed (it's part of RSAT). Do this on the schema master or a DC with the schema FSMO role.

Find the linked attribute's LDAP display name.
Open ADSI Edit. Connect to the Schema naming context. Navigate to CN=Schema,CN=Configuration,DC=<yourdomain>,DC=<com>. Find your attribute — it'll be an object of class attributeSchema. Right-click it, go to Properties. Note the ldapDisplayName value. For this example, let's say it's myCustomAttr.
Hunt down which class references it.
Still in ADSI Edit, browse the CN=Schema container. You're looking for classSchema objects. You can't do this with a GUI search in ADSI Edit directly — the best method is using PowerShell on the schema master:
```
Get-ADObject -Filter {objectClass -eq 'classSchema'} -SearchBase 'CN=Schema,CN=Configuration,DC=<yourdomain>,DC=<com>' -Properties mayContain | Where-Object { $_.mayContain -contains 'myCustomAttr' } | Select-Object Name, DistinguishedName
```
This returns the display name and DN of every class that lists your attribute in mayContain. Usually it's one class, but it can be multiple if you reused the attribute.
Remove the attribute from that class's mayContain list.
In ADSI Edit, find the class object (e.g., CN=MyCustomClass). Right-click → Properties. Find the mayContain attribute. Double-click it, select your attribute's ldapDisplayName from the list, and click Remove. Apply.

If you're doing this via PowerShell:
```
$class = Get-ADObject 'CN=MyCustomClass,CN=Schema,CN=Configuration,DC=<yourdomain>,DC=<com>'
$newList = $class.mayContain | Where-Object { $_ -ne 'myCustomAttr' }
Set-ADObject $class -Replace @{mayContain = $newList}
```
You must replace the entire multivalue list — you can't remove a single entry with Remove-ADObject directly.
Now delete the attribute.
Back on the attribute object, right-click → Delete. This time it should work. If it still fails, you missed a class — run the PowerShell search again to be sure.

Why step 3 works

The schema doesn't store the attribute-to-class relationship as a separate link. It's stored as a multivalued string list (mayContain) directly on the class object. The schema master does a reverse lookup: when you delete an attribute, it scans every classSchema object for that attribute's LDAP display name in both mustContain and mayContain. If it finds a match, it refuses. By removing the value from the list, you break that reference, and the deletion proceeds.

Still failing? Check these

Read-only replicas: The schema change might not replicate immediately. Wait 15 seconds or force replication with repadmin /syncall.
Schema cache: The schema master caches schema objects. If you just removed the reference but the server hasn't refreshed, try running repadmin /syncall /AdeP to force a sync.
System attributes: If the attribute is flagged as systemOnly: TRUE, you cannot delete it regardless — even as Schema Admin. This is rare but Microsoft ships a handful of these for protected schema objects. Check the attribute's systemFlags — if bit 0x00000001 is set, you're stuck. Don't try to hack that, it'll break AD.
Schema FSMO on a different DC: The error might come from a different DC than the one you're connected to. Make sure you're modifying the schema FSMO holder directly, or use Set-ADObject -Server <FSMO holder>.