Fix ERROR_DS_MUST_BE_RUN_ON_DST_DC (0X0000216E) on Windows Server

Cause 1: Attempted restore on a non-destination DC (most common)

I know this error is infuriating — you're trying to bring a domain controller back online after a failure, and Windows just throws up the 0X0000216E error with the message “For security reasons, the operation must be run on the destination DC.” The real trigger is almost always this: you initiated a nonauthoritative restore from backup on a DC that wasn't the target of the restore operation.

Let me break that down. When you restore AD from backup on a DC that's still part of the replication topology, the directory service agent (DSA) on that DC checks whether it's the intended destination for the restore. If it sees another DC with a higher USN (update sequence number) — meaning the source is more up-to-date — it refuses to start. You get the error.

The fix: You need to perform the restore on the destination DC directly, not on the source. But if that source DC is dead and gone, there's a workaround.

1. Boot the target DC into Directory Services Restore Mode (DSRM). For Windows Server 2016/2019/2022, press F8 during startup and pick Directory Services Restore Mode.
2. Restore the AD database from backup using ntdsutil or your backup software (like Windows Server Backup).
3. After restore, boot normally. If you still get the error, run the following command from an elevated command prompt:

ntdsutil
activate instance ntds
set DSA to destination dc
quit
quit

That command tells AD that this DC is the destination. I've used this on Server 2019 DCs after a failed hardware swap — it saved me from rebuilding the whole domain.

Cause 2: The source DC is offline and the destination DC can't replicate

This one's trickier. You might get the error even after a clean restore if the source DC's metadata is still in Active Directory. The DSA on the destination DC tries to contact the source for replication metadata, finds nothing, and throws the error.

Real-world scenario: You decommissioned an old Windows Server 2012 R2 DC six months ago, but someone forgot to remove its NTDS Settings from AD Sites and Services. Now you're trying to promote a new Server 2022 DC, and bam — error 0X0000216E.

The fix: Clean up the dead DC's metadata using ADSI Edit or ntdsutil. Here's the ntdsutil route (I prefer it — fewer mouse clicks):

1. Open an elevated command prompt.
2. Type ntdsutil and press Enter.
3. Type metadata cleanup and press Enter.
4. Type connections and press Enter.
5. Type connect to server <destination_DC_name> — replace with the actual name.
6. Type quit to exit the connections menu.
7. Type select operation target and press Enter.
8. Type list domains — note the domain index (usually 0).
9. Type select domain 0 (or the correct index).
10. Type list sites — note the site index.
11. Type select site <site_index>.
12. Type list servers in site — find the dead DC's index.
13. Type select server <dead_DC_index>.
14. Type remove selected server — confirm the prompt.
15. Type quit repeatedly to exit.

After that, reboot the destination DC. The error should be gone.

Cause 3: Nonauthoritative restore performed on a DC that wasn't the last to replicate

This one tripped me up the first time too. You did a restore on the correct DC, but the backup you used was from a different DC — one that wasn't the last to replicate a critical partition (like the schema or domain partition). AD sees the USN mismatch and blocks the operation.

When it happens: You restore a DC from a backup made on another DC in the same domain. The backup was a week old, and the domain partition has new objects. The destination DC can't reconcile the USN gap and throws error 0X0000216E.

The fix: Do an authoritative restore of the specific partition using ntdsutil. This marks the restored objects as authoritative, forcing other DCs to accept them as the source of truth.

1. Boot the destination DC into DSRM.
2. Restore the AD database as usual.
3. After restore, but before booting normally, open a command prompt.
4. Type ntdsutil and press Enter.
5. Type activate instance ntds and press Enter.
6. Type authoritative restore and press Enter.
7. Type restore subtree "DC=domain,DC=com" — replace the DN with your domain's distinguished name.
8. Type quit twice to exit.
9. Reboot normally.

I've used this exact procedure on a Server 2016 DC that had a corrupt copy of the domain partition. After the authoritative restore, replication kicked in and the error never came back.

Pro tip: If you're still stuck, check the event logs under Directory Service for event ID 1926 — it often logs the source DC name that's causing the conflict. Use that name in step 13 of the metadata cleanup.

Quick-reference summary table

I've been managing AD since Windows Server 2003, and this error still catches me off guard when I'm in a hurry. The key takeaway: always verify which DC is the destination before you start a restore. If you're unsure, check the dSASignature attribute in ADSI Edit — the destination DC's GUID should match the one in the backup. That extra minute of checking saves you an hour of debugging.