Fix ERROR_DS_EXISTS_IN_RDNATTID (0X00002196) in AD Schema

You're trying to deactivate or delete an attribute from the Active Directory schema, and you get this gem:

ERROR_DS_EXISTS_IN_RDNATTID
0X00002196
Schema deletion failed: Attribute is used in rDNAttID

I've seen this maybe a dozen times in the last decade. The first time was for a client's custom attribute they'd added to hold employee badge numbers. They wanted to clean it up after a merger. Took me an afternoon to untangle because the attribute was also being used as a naming attribute on a custom class they'd created for org charts.

The error literally means the attribute you're trying to remove is still referenced in the rDNAttID of some class. Every object class in AD has a mandatory relative distinguished name (RDN) attribute. By default, that's cn for most classes. But if someone built a custom class and set its RDN to your attribute, the schema won't let you delete it until that reference is gone.

Cause 1: The attribute is set as the RDN on a custom class

This is what you'll hit 90% of the time. Someone created an auxiliary or structural class and specified your attribute as its rDNAttID. You won't see this in the ADUC GUI; you need to dig into the schema with ADSI Edit or PowerShell.

Here's how to find which class references your attribute. Replace yourAttributeName with the LDAP display name you're trying to delete.

# Get the schema path
$schemaPath = (Get-ADRootDSE).schemaNamingContext

# Search classes for rDNAttID containing your attribute
Get-ADObject -SearchBase $schemaPath -Filter "objectClass -eq 'classSchema'" -Properties * | `
    Where-Object { $_.rDNAttID -and $_.rDNAttID.ToString().Contains('yourAttributeName') } | `
    Select-Object Name, rDNAttID, governsID

If that returns nothing, you might be dealing with a case where the RDN is set on the attribute itself—yes, that's a thing. An attribute can be its own RDN for certain classes. But let's assume you found a class.

The fix is to change that class's rDNAttID back to cn (or the original RDN). If the class is in use, you might need to temporarily remove it from being an auxiliary class on any object that uses it. I usually do this with ADSI Edit:

1. Open ADSI Edit, connect to the Schema naming context.
2. Navigate to CN=Schema,CN=Configuration,DC=yourdomain,DC=com.
3. Find the class that references your attribute (the one you found with PowerShell).
4. Right-click, Properties. Look for rDNAttID.
5. Change its value to cn (or whatever the class originally used).
6. Apply, then try your deletion again.

One thing: if the class is structural, you'll have to make sure no objects exist that rely on it. But for the schema deletion to work, just clearing the RDN reference is enough.

Cause 2: The attribute is referenced by a class's mustContain or mayContain

This one's sneaky. The error message says rDNAttID, but sometimes the underlying issue is that the attribute is also listed in mustContain or mayContain of a class. The schema service checks all references, and even though the error is specifically about rDNAttID, you might have multiple issues.

I had a client last month whose custom attribute was in the mayContain of an auxiliary class. The auxiliary class wasn't attached to any objects, but the schema still refused to delete until it was removed from that list.

To check, run this:

# Find any class that lists the attribute in mustContain or mayContain
Get-ADObject -SearchBase $schemaPath -Filter "objectClass -eq 'classSchema'" -Properties * | `
    Where-Object { $_.mayContain -contains 'yourAttributeName' -or $_.mustContain -contains 'yourAttributeName' } | `
    Select-Object Name, mayContain, mustContain

If you get hits, you need to remove the attribute from those lists. ADSI Edit again, find the class, and edit the mayContain or mustContain multi-valued property. Remove the offending value.

Be careful with mustContain—if there are live objects using that class, removing a mandatory attribute could cause problems. But honestly, if you're deleting the attribute anyway, someone already messed up the schema design.

Cause 3: The attribute is still enabled or the schema cache isn't updated

Sometimes the error isn't about a reference at all. It's just that the attribute is still active. If you're trying to delete an attribute that's still in isDefunct = FALSE, the schema won't let you. You must deactivate it first.

Here's the sequence:

1. Set isDefunct to TRUE on the attribute (via ADSI Edit or PowerShell).
2. Wait for the schema cache to replicate (or force it with repadmin /syncall if you're in a pinch).
3. Then attempt deletion.

Also, I've seen the error pop up because the schema cache on the domain controller you're working against hasn't refreshed after you made a change elsewhere. Reboot the DC or run Update-ADFSchemaCache if you're on a lab.

One more thing: make sure you're not trying to delete a system attribute. Some attributes are marked as 'system' and can't be removed, even if you clear references. You'll get a different error usually, but it's worth checking.

For the record, the quickest way to see if the attribute is actually defunct and has no references is to use the AD Schema snap-in with 'Schema' added to MMC. But I'll stick with PowerShell because it's scriptable and you can copy-paste the output to the client.

Quick reference

After you clear the references and the attribute is defunct, you can delete it with:

# Once you've cleaned up references, deactivate and delete
Get-ADObject -SearchBase $schemaPath -Filter "Name -eq 'yourAttributeName'" | Set-ADObject -Replace @{isDefunct=$true}
# Wait for replication, then
Get-ADObject -SearchBase $schemaPath -Filter "Name -eq 'yourAttributeName'" | Remove-ADObject -Confirm:$false

That last step usually only works if you're in a lab or you know what you're doing. In production, you can't actually delete a defunct attribute—you just leave it disabled. The error you're seeing might be from someone trying to delete rather than just deactivate. If that's the case, do the deactivation and move on with your life.