Fix ERROR_DS_CANT_ADD_ATT_VALUES (0X00002080)
This error means AD couldn't write an attribute to an object. Usually a schema mismatch or corrupted attribute. Let's fix it fast.
30-Second Fix: Check the Attribute Exists
This error pops up when something tries to write a value to an attribute that doesn't exist on the object. The culprit here is almost always a stale LDAP filter or a script that references a custom attribute that got deleted or renamed. You'll see this in event logs as 0X00002080 — usually from replication or a user creation script.
- Open Active Directory Users and Computers (dsa.msc).
- Enable Advanced Features under View.
- Right-click the object that failed, go to Properties, then the Attribute Editor tab.
- Search for the attribute name from your error — if you don't see it, the attribute's missing from this object's class.
If the attribute isn't listed, it's a schema or object class mismatch. Skip to the moderate fix below. If it is there but empty, you've got a corrupt attribute value — move to the advanced fix.
5-Minute Fix: Schema Check with ADSI Edit
Don't bother restarting services — that rarely helps here. The real fix is verifying the attribute exists in the schema and is assigned to the right class.
- Open ADSI Edit (adsiedit.msc).
- Right-click ADSI Edit in the console tree, choose Connect to.
- In Select a well-known Naming Context, choose Schema. Click OK.
- Navigate to CN=Schema,CN=Configuration,DC=...
- Find the attribute in the list — sort by CN if needed. If it's missing, someone deleted it. You'll need to re-add it from a backup or restore the schema.
- If the attribute exists, double-click it, check attributeID and attributeSyntax — make sure they match your application's expectation. For example, a string attribute should show 2.5.5.12 (Unicode string) for attributeSyntax.
- Also check objectClass on the object that's failing — right-click the object in ADSI Edit (choose Domain or Configuration context), go to Properties, and look at objectClass. If the class doesn't list the attribute in its possSuperiors or systemPossSuperiors, that's the problem.
Common scenario: A custom PowerShell script tries to set extensionAttribute1 on a user, but the user object was created under a custom class that doesn't inherit organizationalPerson.
15+ Minute Fix: Schema Conflict Resolution with Repadmin
If the above didn't work, you're dealing with a replication conflict where two DCs disagree about an attribute's definition. This happens when schema updates don't replicate fully — classic multi-DC environment issue.
- Open an elevated Command Prompt.
- Run
repadmin /showattr . "CN=Schema,CN=Configuration,DC=yourdomain,DC=com" /attribs:cn,attributeID,attributeSyntax /filter:"(cn=attribute_name)"— replaceattribute_namewith your attribute. - Run this against every DC:
repadmin /showattr DC2 "CN=Schema,CN=Configuration,DC=yourdomain,DC=com" /attribs:cn,attributeID,attributeSyntax /filter:"(cn=attribute_name)" - If any DC shows a different attributeSyntax or attributeID, you've got a schema divergence. The fix is to force replication:
repadmin /syncall /AdeP - If replication doesn't fix it, you need to manually correct the schema on the offending DC using ADSI Edit — connect to that DC's schema context and fix the attribute properties to match the schema master.
- Last resort: Authoritative restore of the schema partition. Boot one DC into Directory Services Restore Mode, then run
ntdsutil, authoritative restore, restore the Schema partition from a known-good backup.
I've seen this most often after a failed schema attribute addition using a third-party tool (like a ticketing system that modifies AD schema). Always test schema changes in a lab first — you can't roll them back easily.
Pro tip: Before touching anything, export the attribute's full metadata with repadmin /showobjmeta . "distinguishedName". That gives you version stamps to compare across DCs.
Still Stuck?
Rarely, this error comes from a corrupt database record. Run dcdiag /test:database to check. If that fails, schedule downtime and run ntdsutil — compact database to rebuild the AD database. That's a nuclear option, but it's saved my ass twice.
Was this solution helpful?