Fix ERROR_DS_NO_CHECKPOINT_WITH_PDC (0x2167)

Happens when a domain controller tries to replicate from a PDC but the PDC has no checkpoint. Means the USN rollback or corrupt state is blocking things.

You're in the middle of a routine replication check and 'repadmin /showrepl' throws back ERROR_DS_NO_CHECKPOINT_WITH_PDC (0x00002167). Or maybe DCPromo failed at the end with the same code. The exact trigger is almost always the same: the local domain controller is trying to replicate from the PDC emulator, but the PDC reports back that it doesn't have a checkpoint for that replication cycle. What's actually happening here is that the PDC's copy of the directory partition doesn't have a USN (Update Sequence Number) checkpoint written for the requesting DC. That checkpoint acts like a bookmark — without it, the PDC can't tell the client DC where to start syncing from.

The root cause is almost always one of two things: either the PDC itself suffered a USN rollback (bad restore from backup, hardware failure, or a VM snapshot rollback), or the PDC's database has a corrupt utd_vector (up-to-date vector). The latter happens when a DC was forcefully demoted or removed without proper metadata cleanup. Either way, the checkpoint value that should live in the PDC's NTDS.DIT is missing or zeroed out.

The Fix

Identify the PDC emulator. Run netdom query fsmo on any DC. Note the server listed as 'PDC'.
Check the PDC's replication status. On the PDC, open an admin command prompt and run repadmin /showrepl. Look for any ERROR_DS_NO_CHECKPOINT_WITH_PDC or other errors. If the PDC itself reports this error against another DC, you have a USN rollback scenario on the PDC.
Force a USN checkpoint creation. On the PDC, run:
```
repadmin /regkey <PDC_hostname> <partition_DN> +ISG
```
Replace <PDC_hostname> with the PDC's FQDN and <partition_DN> with the domain's DN (e.g., DC=contoso,DC=com). The +ISG flag forces the Knowledge Consistency Checker to immediately propagate a new checkpoint. Wait 5 minutes, then restart the NTDS service: net stop ntds && net start ntds.
Verify the checkpoint was written. On the PDC, run:
```
repadmin /showutdvec <PDC_hostname> <partition_DN>
```
You should see a non-zero USN for all DCs. If you still see 0 for the local DC, the checkpoint creation failed — proceed to step 5.
If checkpoint still missing, force a database repair. On the PDC, boot into Directory Services Restore Mode (DSRM). Run ntdsutil and use:
```
ntdsutil
activate instance ntds
files
check integrity
```
If it reports corruption, run recover. After that, run semantic database analysis and then go fixup to fix cross-ref issues. Reboot normally.
Force replication from the PDC to the affected DC. On the affected DC, run:
```
repadmin /syncall /APe
```
The /APe flag is critical here — it forces a push of all partitions including cross-refs. If you skip this, the checkpoint still won't be sent.
Monitor. Run repadmin /showrepl on the affected DC. The error should be gone. If it's still there, the PDC might need a full rebuild — see 'What to check if it still fails' below.

What to check if it still fails

The PDC itself might be too damaged. If step 5's repair doesn't fix the checkpoint, the PDC's NTDS.DIT has deeper corruption. The safest move is to transfer the PDC role to another DC with netdom query fsmo then ntdsutil roles connections. Demote the broken PDC, remove its metadata, and promote a fresh DC. Reason step 3 works in most cases: the ISG flag forces a new checkpoint generation, which bypasses the stale or missing vector. But if the database itself is corrupt at the page level, no amount of flagging helps.

Check for lingering objects. Run repadmin /removelingeringobjects <PDC_hostname> <partition_DN> /advisory_mode against the PDC. If you see lingering objects, remove them with the same command without /advisory_mode. Lingering objects can prevent checkpoint creation because the PDC refuses to set a checkpoint that references objects it can't account for.

Check time sync. If the PDC's time is off by more than 5 minutes from the affected DC, Kerberos authentication for replication can fail silently, and the checkpoint never gets written. Fix with w32tm /resync on both sides.

I've seen this error on Windows Server 2012 R2 and 2016 the most, but it also shows up on 2019 when someone restores a DC from a snapshot without proper backup. The fix is the same across versions — the USN checkpoint logic hasn't changed since Windows 2000.