Fix ERROR_DS_MISSING_REQUIRED_ATT (0X0000207C) in Active Directory

The Short Version

0X0000207C shows up when you try to create an object in Active Directory (or replicate one) and a mandatory attribute is missing from the schema or from the object itself. The culprit here is almost always a schema mismatch between domain controllers — someone added an attribute somewhere but forgot to replicate the schema change. Or you've got a corrupt attribute in a specific object.

I've seen this most often after a failed schema extension (think Exchange or ADFS install) or when a DC was rebooted mid-replication. The fix depends on whether it's a single object or the whole directory.

30-Second Fix: Check Replication Health

Don't dive into schema surgery yet. Run this from an elevated command prompt on the DC showing the error:

repadmin /replsummary

Look for any DCs with failures. If you see 0X0000207C in the error column, you've got a replication partner that's missing the attribute definition. Next, check which attribute is causing the grief:

repadmin /showobjmeta * "DN_of_failing_object"

Replace DN_of_failing_object with the Distinguished Name from the error message. That'll show you the attribute that's missing its metadata.

If the attribute shows up but with weird version numbers — like it's stuck at version 0 — you're looking at a schema replication failure. Jump to the advanced fix below.

If replication looks clean but you still get the error on object creation, it's likely a missing objectClass attribute in the schema itself. Move to the moderate fix.

5-Minute Fix: Force Schema Replication

Schema updates don't replicate automatically the same way normal data does. They require a separate sync trigger. Here's the quickest way to push a schema change across all DCs:

1. Open ADSI Edit on a DC that already has the schema attribute. Connect to the Schema naming context.
2. Find the attribute listed in the error (usually something like ms-DS-ConsistencyGuid or ms-Exch-*).
3. Right-click the attribute and pick Properties. Verify attributeID and attributeSyntax are populated.
4. If they're empty, that's your problem. The schema master didn't properly add the attribute.

Now force the schema replication manually:

repadmin /syncall /AdeP

Then check if the error resolves. If the schema master itself doesn't have the attribute defined, you'll need to fix the schema definition there first. Use ADSI Edit on the schema master to add the missing attribute.

I've had cases where the attribute existed in the schema but the objectClass for the parent class (like user or group) didn't include it as mustContain. That's a schema design issue — you'll need to add it to mustContain if it's mandatory for that class.

15+ Minute Fix: NTDSUtil Recovery & Schema Cleanup

When the above doesn't work, you've got a deeper problem. Either the attribute's metadata is corrupt or the NTDS database itself has an issue.

Step 1: Check the attribute metadata

repadmin /showattr * "CN=Schema,CN=Configuration,DC=domain,DC=com" /filter:"(cn=failingattribute)" /attrs:cn,attributeID,attributeSyntax,isMemberOfPartialAttributeSet

If the output shows attributeID: , you need to recreate the attribute. But don't do that manually — it's a nightmare with GUIDs and OIDs. Instead, export the schema from a healthy DC and import it on the broken one:

ldifde -f schema_export.ldf -s healthyDC -n -d "CN=Schema,CN=Configuration,DC=domain,DC=com"

Then on the broken DC:

ldifde -i -f schema_export.ldf -s brokenDC

Step 2: Run semantic database analysis

If the attribute was defined but the database is corrupt, run this on the DC:

ntdsutil
activate instance ntds
semantic database analysis
verbose on
go

Fix any errors it reports. Then run a consistency check:

repadmin /rehost

Step 3: Tombstone or delete the bad object

If a single object is corrupt and can't be fixed, remove it. Open ADSI Edit, find the object, check the checkbox Delete associated objects (if available), then delete. Recreate the object from scratch. This is a last resort — you lose all attributes tied to that object.

Step 4: Rebuild the DC

If you've tried everything and the error persists, demote the DC, clean up metadata, and promote it fresh. Use ntdsutil to remove the DC metadata if demotion fails:

ntdsutil
metadata cleanup
connections
connect to server validDC
quit
select operation target
list domains
select domain X
list sites
select site X
list servers
select server X
quit
remove selected server

Then rebuild. It's a nuclear option, but sometimes the schema is too trashed to repair without a full reinstall.

One More Thing

If you're running AD LDS (ADAM), the fix is similar but you're working with a different schema. Use adamschema context in ADSI Edit for that. Same steps otherwise.

Don't waste time running chkdsk or sfc /scannow — this is a schema issue, not filesystem corruption. I've seen people chase that rabbit for hours. It never helps.