Fixing ERROR_DS_GOVERNSID_MISSING (0X000020DA) Fast

Cause 1: Schema Extension Import Broke the governsID

This is the most common reason you're seeing error 0X000020DA — someone imported a schema extension (like Exchange, Skype for Business, or a third-party app) that didn't properly define the governsID attribute on a class. It's almost always a bad LDIF file or a manual schema edit gone wrong.

The error hits when you run adprep /forestprep or try to upgrade a domain controller to a newer Windows Server version. The schema master tries to create or modify a class but can't find the governsID in the schema cache. This attribute is mandatory — it ties a class to its OID (Object Identifier). Without it, the class is orphaned.

The fix: You need to identify which class is missing the governsID and either repair it or delete the offending class. Here's the quick way to find it:

1. Open ADSI Edit on a schema master (preferably on the schema master itself). Connect to the Schema naming context.
2. Browse to CN=Schema,CN=Configuration,DC=<yourdomain>,DC=<com>.
3. Right-click the Schema container, choose Find. Search for governsID — this catches all classes that have this attribute set to a value (which they all should).
4. Look for any class where governsID is missing or blank. Most common culprits: classSchema objects from a failed Exchange 2013/2016 schema extension or a custom LDIF import.
5. If you find one, note its ldapDisplayName and cn. Then check if you can fix it by setting the correct OID. If you don't know the OID, delete the class entirely (backup the schema first!).

Deleting a class schema object is safe only if you're sure it's not used by any objects. In practice, these orphaned classes are from failed imports and have zero instances. Use this PowerShell one-liner on the schema master:

Remove-ADObject -Identity "CN=BadClass,CN=Schema,CN=Configuration,DC=contoso,DC=com" -Confirm:$false

After removing the bad class, run adprep /forestprep again. It should complete without the error.

Cause 2: Schema Master Permissions Are Locked Down

Sometimes it's not a corrupted class — it's that the schema master's security descriptor doesn't allow the update. I've seen this happen when someone tightened permissions on the Schema container using a GPO or a security template. The account running the schema update needs Schema Admins group membership and write access to the Schema container itself.

This error shows up with the exact same code 0X000020DA because AD attempts to write the governsID during the update and gets an access denied response, which it interprets as a missing attribute.

How to check: Open ADSI Edit on the schema master, right-click the Schema container, go to Properties → Security. Make sure Schema Admins has Full Control. Also verify the Enterprise Admins group has at least read/write. If you see CREATOR OWNER with weird permissions, reset them:

dsacls "CN=Schema,CN=Configuration,DC=contoso,DC=com" /reset /T /I:T

Then re-add the Schema Admins group with full control:

dsacls "CN=Schema,CN=Configuration,DC=contoso,DC=com" /G "CONTOSO\Schema Admins:GRGWGRCX"

If you're running the schema update from a non-schema-master DC (which you should never do, but people do), the replication between DCs can also cause permission propagation delays. Always run adprep directly on the schema master for the forest-level updates.

Cause 3: Schema Cache Is Stale or Corrupted

Less common but real — the schema cache on the schema master itself holds a bad copy. AD keeps a cached version of the schema in memory and on disk. If that cache gets corrupted, any schema update will fail with weird errors, including the governsID one. This typically happens after a hard crash, improper shutdown, or disk errors on the schema master.

Step 1: Force a schema cache refresh without a reboot. Open an admin Command Prompt on the schema master and run:

net stop ntds && net start ntds

That restarts the NTDS service, which reloads the schema cache. Then try your schema update again. If the error persists, move to step 2.

Step 2: Check the schema cache on disk at C:\Windows\NTDS. You'll see a file called schema.ini and possibly schupgrade.log. Look for entries like "Unable to find governsID for class X". If you see corruption, the nuclear option is to seize the schema master role to another DC and force a full synchronization. But that's a last resort — try the service restart first.

I've also seen this happen when the schema master is running Server 2012 and you're trying to prepare for Server 2022. The old schema cache doesn't know how to handle the new attributes. In that case, apply the latest schema updates in order — don't skip versions.

Quick-Reference Summary Table

Bottom line: 9 times out of 10, it's a bad LDIF import that left a class without a governsID. Find and delete it, and you're done. Don't waste time rebuilding DCs or restoring from backup until you've checked the schema classes first.