Fix ERROR_DS_BAD_RDN_ATT_ID_SYNTAX (0X000020C8)

If you're seeing ERROR_DS_BAD_RDN_ATT_ID_SYNTAX (0X000020C8) during a schema update, you're probably in the middle of an Exchange, Lync, or third-party product installation. This error is infuriating because it stops the whole process dead, and the error message gives you almost nothing to work with. Let me save you some time.

The core problem is that an attribute in your schema is marked as an RDN attribute (used in distinguished names) but doesn't have the syntax that Active Directory expects for RDN attributes. RDN attributes must be one of a few specific syntaxes — like DirectoryString, IA5String, or NumericString — and if some earlier schema change altered the syntax, you'll hit this error.

Most Common Cause: The rdnAttId Attribute Has an Invalid Syntax

The number one trigger I've seen in production is a schema attribute where the rdnAttId value points to an attribute whose attributeSyntax was incorrectly set during a previous manual edit. For instance, a cn attribute should have syntax 2.5.5.12 (DirectoryString), but if someone used ADSI Edit to tweak it and accidentally changed it to something like 2.5.5.8 (Boolean), you're going to get this error.

The fix: Correct the attribute syntax back to a valid RDN syntax. You'll need to temporarily enable schema snap-in registration, then use ADSI Edit or PowerShell.

First, register the schema management DLL if you haven't:

regsvr32 schmmgmt.dll

Then run this PowerShell to find the offending attribute. Replace YourAttributeName with the attribute mentioned in your error or the one you suspect.

Get-ADObject -SearchBase ((Get-ADRootDSE).SchemaNamingContext) -Filter {Name -eq "YourAttributeName"} -Properties attributeSyntax,oMSyntax,rdnAttId

Look at the attributeSyntax and oMSyntax values. For a valid RDN attribute (like cn or ou), you should see:

• attributeSyntax: 2.5.5.12
• oMSyntax: 64

If they differ, you'll need to correct them. Since you can't directly edit these with PowerShell, use ADSI Edit:

1. Open adsiedit.msc
2. Connect to the Schema naming context (right-click ADSI Edit, choose "Connect to", then select "Schema" under Naming Contexts).
3. Navigate to CN=Schema,CN=Configuration,DC=..., find your attribute, right-click and open Properties.
4. Edit attributeSyntax to 2.5.5.12 and oMSyntax to 64.

If the attribute is an RDN attribute (like cn), this should resolve the error. But careful — if the attribute is already in use, changing syntax can cause issues. Only do this if you know the original value.

Second Cause: Wrong Attribute Designated as RDN

Another common scenario is when a new attribute gets created with isRDNAttr set to TRUE but its syntax isn't a valid RDN type. Some applications during schema update incorrectly set this flag. The error might reference a specific attribute that has no business being an RDN.

Fix: Remove the isRDNAttr flag from that attribute. Again, using PowerShell:

Get-ADObject -SearchBase ((Get-ADRootDSE).SchemaNamingContext) -Filter {Name -eq "ProblemAttribute"} | Set-ADObject -Replace @{isRDNAttr="FALSE"}

Replace ProblemAttribute with the one from your error. Then retry the schema update.

I've seen this happen with attributes created by early beta versions of software that later got corrected. If you're upgrading from an older version of a product, check its documentation for known schema issues.

Third Cause: Schema Cache Not Refreshed

Sometimes the actual schema is fine, but the schema cache on the domain controller is stale. This is less common but happens when you've made schema changes and then immediately run an update that expects the fresh schema. The error can appear misleading.

Fix: Force a schema cache reload. On the domain controller where you're running the update, open an elevated command prompt and run:

regsvr32 /i schmmgmt.dll

That triggers a cache reload. Alternatively, restart the Active Directory Domain Services service (on a DC that's not the global catalog if possible, to avoid disruption). After the restart, retry your schema update.

Also, make sure you're running the schema update on the schema operations master (FSMO role holder). If you're not, you'll get a different error usually, but sometimes it manifests oddly.

Quick-Reference Table

Start with cause #1 because that's where I see 80% of these errors come from. Check the specific attribute name in the error, verify its syntax, and correct it. You'll be back to your install in minutes.