Fix ERROR_DS_SCHEMA_UPDATE_DISALLOWED (0x213D)

You just got the yellow warning triangle, right?

You're running an AD schema update — maybe to prep for Exchange 2019, or to install a new version of Windows Server, or apply a security hotfix from Microsoft that touches the schema. And boom, instead of completing, the command or GUI throws ERROR_DS_SCHEMA_UPDATE_DISALLOWED (0X0000213D). The message says it clearly: this DC isn't the schema FSMO role owner. But what you really need is the fix, not the explanation.

I saw this last month when a client's junior admin tried to run adprep /forestprep from a read-only domain controller. The error's the same whether you're running from a full DC or not — if you're not the one holding the schema operations master role, you're locked out.

Why this happens — the short version

Only one domain controller in the entire forest can write to the schema. That's the schema FSMO (Flexible Single Master Operations) role owner. All other DCs are read-only for schema changes. When you try to update schema attributes or classes from a DC that isn't the role owner, AD slaps you with 0x213D. It's a safety feature — prevents schema corruption from simultaneous writes.

Had a client last month whose entire print queue died because of this — they'd run a schema update from their backup DC thinking it didn't matter. It matters. A lot.

Fix: Three approaches, pick the one that fits

Option 1: Run the schema update directly on the schema master

Find out which DC holds the schema master role. Open a command prompt as admin and run:
```
netdom query fsmo
```
Look for the line that says "Schema master" — it'll show the server name.
RDP into that server (or use remote PowerShell).
Run your schema update command or tool directly on that server. For adprep, that means running it from an elevated command prompt on the schema master.
Wait for it to complete. Schema updates usually take under a minute unless you're updating a huge forest.

Option 2: Transfer the schema FSMO role to a different DC

Use this if your schema master is offline, patched, or you want to move the role permanently.

On any DC (preferably the one you want as the new owner), open an elevated command prompt.
Type:
```
ntdsutil
activate instance ntds
roles
connections
connect to server <targetDCHostname>
quit
seize schema master
quit
quit
```
Replace <targetDCHostname> with the hostname of the DC that should own the role. The seize command forcibly transfers it even if the old owner is offline. If the old owner is online, use transfer schema master instead of seize.
After the command completes, verify with netdom query fsmo again.
Now run your schema update on that DC.

Option 3: Use ADSI Edit to connect directly to the schema master

This is for advanced users who need to make schema changes remotely but still hit the correct DC.

Open ADSI Edit.
Right-click ADSI Edit in the left pane, choose "Connect to".
Under Connection Point, select "Select a well-known naming context" and pick "Schema".
Check "Advanced" and enter the hostname of your schema master DC in the Server field.
Click OK. Now every change you make goes directly to the schema master.

Still getting the error? Check these

Firewall between DCs: Schema updates need RPC connectivity. If ports 135 and dynamic RPC ports are blocked, even the schema master might fail. Test with Test-NetConnection <schemaMaster> -Port 135.
Account permissions: You must be a member of Schema Admins group (plus Enterprise Admins for forest-wide changes). Run whoami /groups to confirm.
Replication latency: If you just transferred the role, wait a few minutes for replication to catch up. Force replication with repadmin /syncall if you're impatient.
Schema version mismatch: If the schema master runs an older OS than the update requires, you'll get other errors. Check dsquery * cn=schema,cn=configuration,dc=domain,dc=com -scope base -attr objectVersion and compare against the update's requirements.

Most of the time, option 1 is the fastest. I've never had a case where running the update on the schema master didn't resolve it — unless someone forgot they weren't an admin. Don't be that guy.