Fix ERROR_DS_DRA_SCHEMA_INFO_SHIP 0X0000215E

Quick Answer for Advanced Admins

Run repadmin /showrepl to identify the failing DC, then check DNS records for both source and destination DCs. If DNS is clean, open port 135 and the ephemeral RPC range (49152-65535) between the DCs. Still stuck? Force replication with repadmin /syncall /AdeP or seize the schema master FSMO role.

Why This Happens (The Real Story)

I've seen this error more times than I want to count—usually on a Monday morning after someone rebooted a domain controller that had been running for two years straight. The error code 0x0000215E means one DC tried to replicate schema information to another, but the connection flaked out midship. The schema info is basically the blueprint for your entire AD forest—without it, replication stalls dead.

Here's what's really going on: The destination DC can't reach the schema master (the DC holding the Schema FSMO role) or the source DC can't bind to a necessary RPC endpoint. The two most common triggers are a DNS record pointing to an old IP (I had a client last month whose entire print queue died because a stale A record pointed to a decommissioned server) or a firewall update that silently closed the RPC dynamic ports. Another gotcha is if the Schema Master itself is offline or unresponsive—maybe it's patching, maybe it crashed. Replication doesn't wait.

Step-by-Step Fix

Check DNS first. Log into the DC showing the error. Open DNS Manager. Look for the destination DC's A record. Ping it by name—does it resolve to the correct IP? If not, delete the stale record, run ipconfig /registerdns on the destination DC, then repadmin /syncall /AdeP from the source DC.
Verify the Schema Master is alive. Run netdom query fsmo to find the Schema Master. Check that server is online and AD services are running. If it's dead, use ntdsutil to seize the schema role onto another DC—but only if you're sure the original won't come back.
Open the right ports. The source DC needs to reach the destination DC on TCP 135 (RPC Endpoint Mapper) plus the ephemeral RPC range. On Windows Server 2012 and later, that's 49152-65535. Use netsh firewall show state or check Windows Firewall with Advanced Security. If a third-party firewall is in between, log in and verify those ports aren't blocked. I've fixed this exact error by adding one firewall rule.
Force replication. On the source DC, run repadmin /syncall /AdeP to push all pending changes. Then repadmin /showrepl to confirm the error clears. If it still fails, try repadmin /replicate destDC sourceDC DN with the specific naming context (e.g., DC=contoso,DC=com).
Restart the KCC and Netlogon services. On both DCs, run net stop kcc && net start kcc then net stop netlogon && net start netlogon. This rebuilds the replication topology and forces a new connection object.

If the Main Fix Doesn't Work

Sometimes the issue is deeper—a corrupted schema partition or a metabase mismatch. Try these alternatives:

Use repadmin /options +DISABLE_INBOUND_REPL and +DISABLE_OUTBOUND_REPL on the failing DC to stop replication from that server temporarily. Then run repadmin /removelingeringobjects to clean up orphaned attributes. Re-enable replication with repadmin /options -DISABLE_INBOUND_REPL -DISABLE_OUTBOUND_REPL.
Reset the computer account of the problematic DC. Demote it using Active Directory Installation Wizard, clean up metadata with ADSI Edit, then promote it again. This is your nuclear option—it takes about 30 minutes but has never failed me.
Check time sync. If the DCs are more than 5 minutes out of sync, Kerberos fails and RPC replication breaks. Run w32tm /query /status on both. Point them to the same authoritative time source (usually the PDC emulator).

How to Prevent This from Coming Back

Set up a weekly script that runs repadmin /replsummary and emails you the results—any failure gets caught early. Also, lock down DNS scavenging: configure aging and scavenging on all forward lookup zones (set no-refresh interval to 7 days, refresh to 7 days). And for the love of backups, never let your firewall team update rules without checking if AD ports are still open. One client learned that the hard way after a firewall upgrade took down replication across four sites.

Pro tip: If you're running Windows Server 2016 or later, enable the AD Preview feature in Event Viewer under Applications and Services Logs. It logs schema-level replication attempts and gives you a 15-minute head start on catching errant changes.