ERROR_DS_INVALID_DMD (0x20A8) Fix for Active Directory

You're running dcpromo or trying to promote a new domain controller, and it tanks with ERROR_DS_INVALID_DMD (0x000020A8) - The schema object could not be found. Or maybe you're mid-restore of a virtualized DC and AD replication is throwing a fit. This one shows up most often after a snapshot rollback on a Hyper-V or VMware DC, or after an authoritative restore gone sideways. The DC thinks it's part of a forest but can't locate the schema naming context.

What's actually happening: the Directory Service Agent (DSA) is trying to read the schema container from the directory database (ntds.dit), and it isn't there. Not missing a single attribute — the entire CN=Schema,CN=Configuration,DC=... object. Without it, AD has no idea what object classes exist, so it refuses to do anything useful.

Why this error pops up

The culprit here is almost always one of three things:

Restored from a snapshot that predates the schema partition. Classic with VMs. Someone snaps a DC, does a bunch of AD work, reverts the snapshot, and now that DC has a stale USN and a schema that doesn't line up with the rest of the forest.
Interrupted replication or dirty shutdown during schema operations. Schema updates only replicate to the schema master first, then out. If replication breaks mid-way, some DCs end up with incomplete schema state.
Dead schema FSMO holder. The schema master role got seized or lost, and one or more DCs can't pull schema updates. Eventually the local schema object references go stale.

Don't bother with dcdiag /fix right away — it rarely touches this. The schema partition isn't something DCDIAG repairs by itself.

Fixing it — step by step

Work from a healthy DC if you have one at all. If every DC is broken, this gets ugly and you're looking at a forest recovery. Assume you have at least one working DC.

Confirm which DC is broken. On the failing DC, run:
```
dcdiag /v /test:advertising /test:knowsofroleholders
repadmin /showrepl
```
Look for schema partition failures in the output. If repadmin /showrepl shows the schema NC failing to replicate, that's your smoking gun.
Verify the schema master is reachable. From any DC:
```
netdom query fsmo
```
The schema master should respond to ping and LDAP. If it doesn't, seize the role to a healthy DC:
```
ntdsutil
roles
connections
connect to server HEALTHYDC
quit
seize schema master
quit
quit
```
Force schema replication to the broken DC. From a healthy DC:
```
repadmin /replicate BROKENDC HEALTHYDC "CN=Schema,CN=Configuration,DC=yourdomain,DC=com"
```
If this succeeds, restart the AD DS service on the broken DC and re-run dcdiag. Fixed.

If replication won't work, demote the broken DC. Don't try to be clever. If the schema partition is toast, you can't repair it in place reliably. Force demote:

dcpromo /forceremoval

Then clean up metadata from a healthy DC:

ntdsutil
metadata cleanup
connections
connect to server HEALTHYDC
quit
select operation target
list domains
select domain 0
list servers in site
select server 0
quit
remove selected server
quit
quit

Rebuild and repromote. Wipe the server (or at least the AD DS role), rejoin the domain, and promote it fresh. It'll pull a clean schema copy from the schema master on promotion.

If it still fails after all that

Check these, in this order:

Event log on the failing DC. Look at Directory Service events. Event ID 2089 (backup latency) and 1863 (replication) tell you whether replication is even attempting.
DNS. Yes, it's always DNS. The failing DC needs to resolve the schema master by GUID-based CNAME under _msdcs.yourdomain.com. Run nslookup against the schema master's FQDN from the broken DC.
Time skew. Kerberos breaks past 5 minutes. Schema replication needs Kerberos. If the DC's clock is off, nothing replicates. Check with w32tm /query /status.
Firewall. RPC dynamic ports between DCs. If someone tightened things down, replication silently fails. Port 135 plus the RPC range, plus 389, 636, 3268, 3269.
USN rollback. If this DC was ever restored from a snapshot without proper VM-GenerationID support (pre-2012 DCs on Hyper-V, or older VMware), you have a USN rollback and the DC is permanently broken. Demote and rebuild, no exceptions.

One more thing: disable snapshots on all DC VMs going forward. If your backup product uses snapshots to back up DCs, switch it to a proper AD-aware backup or use wbadmin with system state. Snapshot-based DC backups are how this error gets born in the first place.