Active Directory replication failed because the tombstone lifetime was exceeded
The Active Directory Domain Services cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.
A destination domain controller has not successfully inbound-replicated a directory partition from one or more source domain controllers for longer than the forest's tombstone lifetime (typically 60 or 180 days). Active Directory deliberately quarantines the DC at this point to prevent lingering objects — deleted objects that still exist on the out-of-date DC — from being reintroduced into the directory if replication resumes.
The Active Directory Domain Services cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.
Why it happens
A domain controller was offline, isolated from the network, or experiencing continuous replication failures for longer than the tombstone lifetime without the issue being resolved.
System clock skew caused the DC's clock to jump forward by an amount equal to or exceeding the tombstone lifetime, making the replication engine incorrectly conclude that the tombstone lifetime has elapsed.
An underlying replication error (such as 1722, 8524, or 8453) went unresolved long enough for the tombstone lifetime window to expire.
A domain controller was restored from a backup older than the tombstone lifetime without an authoritative restore procedure, creating an apparent gap exceeding the tombstone period.
The tombstone lifetime value has been customised to a non-default value and is shorter than expected, causing DCs to hit the threshold more quickly.
How to fix it
Run `repadmin /showrepl` and `dcdiag /test:replications` to confirm the affected DC and identify how long it has been out of replication contact.
Check for a system time jump on the destination DC: `w32tm /query /status`. Correct time sync if the clock is significantly skewed, ensure the PDC Emulator is configured as an authoritative NTP source (`w32tm /config /manualpeerlist:time.windows.com /syncfromflags:manual /reliable:yes /update`), then restart the Windows Time service.
Check for and remove lingering objects before re-enabling replication. Use `repadmin /removelingeringobjects <DestDC> <SourceDCGuid> <NC> /advisory_mode` to detect them first, then remove with `repadmin /removelingeringobjects <DestDC> <SourceDCGuid> <NC>`.
If lingering objects have been removed, clear the replication quarantine by enabling the Allow Replication With Divergent and Corrupt Partner registry value: `reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v "Allow Replication With Divergent and Corrupt Partner" /t REG_DWORD /d 1`. Re-enable replication, verify it completes successfully, then remove this registry value.
Resolve any underlying network, DNS, or authentication replication failures that caused the original gap before re-enabling replication.
If the DC cannot be recovered (e.g., the gap is extremely large and data loss has occurred), force-demote it using `dcpromo /forceremoval`, clean up metadata with `ntdsutil` metadata cleanup, and repromote the DC. Note: force demotion may result in loss of any originating updates made on that DC since the last successful replication.
