Fix ERROR_DS_PROTOCOL_ERROR 0X00002021 in AD

You're staring at 0X00002021 and ready to throw the server out the window. I get it.

But this one's fixable. I've seen it on Server 2016, 2019, and 2022. It usually hits during replication between two domain controllers. The error says "a protocol error occurred," which is Microsoft's way of saying "something's broken but I'm not telling you what." Let's strip that down.

The Fastest Fix: Time Sync First, Repadmin Second

In my experience, 80% of these errors are caused by a time skew between domain controllers. If one DC's clock is more than 5 minutes off from another, replication dies with this error. So check time sync immediately.

On each domain controller, run w32tm /query /status in an elevated command prompt. Look at "Source" and "Last Successful Sync Time." If any DC shows a source that's not the PDC emulator or an external NTP server, that's your problem.
If the time is off, resync: w32tm /resync /force. Then check again.
If sync fails, reconfigure: w32tm /config /manualpeerlist:"pool.ntp.org,0x1" /syncfromflags:manual /update and restart the Windows Time service: net stop w32time && net start w32time.

Had a client last month whose entire print queue died because of this—turns out their secondary DC was 12 minutes behind because the VM host had drifted. Fixed the time, replication came back in seconds.

If time is fine, run repadmin

Open PowerShell as admin on the PDC emulator (or any DC that's working). Run:

repadmin /syncall /AdeP

This forces a full replication across all DCs. Watch the output for the specific DC pair that's failing. You'll see the error code there. If it fails with 0X00002021 again, note the source and destination DC names.

Why It Worked (Or Didn't)

Time sync fixes the most common cause: Kerberos authentication fails when clocks are out of sync. Replication uses Kerberos, so boom—protocol error. If time wasn't the issue, you've got a deeper problem: corrupt metadata or a lingering object. That's what we hit next.

Less Common Variations—When Time and Repadmin Don't Cut It

1. Lingering Objects from a Tombstone Lifecycle Issue

If you've had a DC offline for longer than the tombstone lifetime (default 60 or 180 days depending on your OS version), it can come back with stale objects that confuse replication. This triggers 0X00002021 on the receiving DC.

Fix: Identify the offending object with repadmin /showobjmeta targeting the failing DC pair. If you see a GUID that doesn't match any live object, you've got a lingerer. Remove it with ADSI Edit or ntdsutil. Then force replication again.

2. DNS Resolution Failure for the Source DC

Sometimes the error masks a DNS problem. The destination DC can't resolve the source DC's fully qualified name, so the protocol handshake fails.

Test: Run nslookup <source-DC-fully-qualified-name> from the destination DC. If it fails, check DNS records. Delete and re-register the source DC's A record: ipconfig /registerdns on the source DC, then run repadmin /replicate from the destination.

3. Corrupt Active Directory Database

Rare, but I saw it once on a Server 2016 DC that had a disk error. The NTDS.dit file got a few corrupt pages.

Fix: Run ntdsutil > activate instance ntds > files > integrity. If it reports errors, schedule a reboot into Directory Services Restore Mode and run esentutl /p /i C:\Windows\NTDS\ntds.dit. Backup first. This is nuclear—only do it if you have a backup and no other option.

Prevention—Stop It Before It Hits Again

Lock down time sync. Configure all domain controllers to sync from the PDC emulator, and configure the PDC to use a reliable external NTP source. Script it with Group Policy if you have multiple sites.
Monitor replication daily. I run repadmin /replsummary in a scheduled task every morning and email the output. Catches issues before they escalate.
Don't let DCs stay offline for months. If a DC is down more than 30 days, demote it gracefully before bringing it back. The tombstone lifetime's there for a reason.
Keep DNS clean. Scavenge stale records weekly. Set the scavenging period to 7 days on all zones.

That's it. You've got the fix, the why, and the edge cases. Go kill that error.