Fix AD Replication Error 0x0000210F (DRA Shutdown)

This error fires when Active Directory replication gets cut off mid-stream because the target domain controller is shutting down. Happens during reboots or power events.

When This Error Actually Hits

You're running repadmin /syncall or checking dcdiag /test:intersite and see ERROR_DS_DRA_SHUTDOWN (0x0000210F). The specific trigger is almost always a domain controller that was in the middle of receiving replication data when it started shutting down. That shutdown could be a scheduled reboot, a crash, or even a graceful shutdown from shutdown /s. The receiving DC (the one that was supposed to write the changes to its NTDS database) just stops accepting data mid-stream.

I've seen this most often after someone kicks off a Windows Update reboot on a DC without checking if replication is idle. Another common scenario: a failover cluster event that restarts the DC VM before the pending replication completes.

What's Actually Happening Inside

Active Directory replication uses a state-based model. The sending DC opens an RPC connection to the receiving DC's NTDS service and pushes updates in chunks. When the receiving DC starts its shutdown sequence, the NTDS service stops listening on port 135 and aborts all active replication sessions. The sending DC gets back 0x0000210F and marks that replication as failed.

The key point: this is not a data corruption error. The replicated objects are fine—they just didn't finish writing. The next replication cycle will pick up where it left off because the USN (Update Sequence Number) tracking will catch the gap. But you still need to verify that the receiving DC actually rebooted cleanly and that its database isn't in a dirty shutdown state.

The Fix

Check if the receiving DC is actually up. Run ping <DC-name> and Test-NetConnection <DC-name> -Port 389 from the sending DC. If it's unreachable, the error is stale—the shutdown already happened. If it's reachable, something else went wrong.
Run dcdiag on both DCs. On the receiving DC, execute dcdiag /v /c in an elevated command prompt. Look for any NTDS or KCC errors. The most common companion is NTDS Event ID 1168 (the database didn't shut down cleanly) or Event ID 1925 (replication link broken).
Force a replication. From the sending DC, run repadmin /syncall /AdeP. This forces all replication partners to attempt a full sync. Don't use /P (push-only) here—you want the full bidirectional check.
Check the NTDS database integrity on the receiving DC. If step 3 fails again with the same 0x0000210F, the receiving DC's database might be in a dirty state. Run ntdsutil → activate instance ntds → integrity. This can take 10-30 minutes depending on database size. Do this during a maintenance window.
Reboot the receiving DC cleanly. Use shutdown /r /t 0 and wait for it to come fully back. Yes, this sounds counterintuitive when the error is about shutdown—but a clean boot resets the NTDS service state. After reboot, run repadmin /syncall /AdeP again.

What to Check If It Still Fails

If you're still seeing 0x0000210F after a clean reboot, the problem is probably deeper:

Pending shutdown flag stuck in the registry. The NTDS service sets a registry key during shutdown that should clear on startup. Check HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters for a value named DSA Last Shutdown State. If it's non-zero, the service thinks it's still shutting down. You can manually set it to 0 and restart the service, but I'd only do that under Microsoft support guidance.
Intersite replication with a slow link. If the sending and receiving DCs are across a WAN link with high latency, the RPC timeout might fire before the shutdown event completes. Check the RPC Timeout setting in the site link object. Default is 45 seconds—bump it to 120 seconds if you see this pattern regularly.
Antivirus or firewall blocking RPC ports. The shutdown sequence can trigger a firewall rule change if the receiving DC's security software sees the NTDS service stopping and blocks the RPC endpoint mapper. Check Windows Defender Firewall logs or your third-party AV logs for blocked ports 135, 389, and 445 during the error window.

One last thing: if you have event logs from the time of the error, look for NTDS Event ID 1393—that's the actual shutdown initiation event. Cross-reference its timestamp with the 0x0000210F error. The gap should be less than a minute. If it's longer, something else is holding the shutdown.