Fix ERROR_DS_REPL_LIFETIME_EXCEEDED 0x21A6 (AD Replication)

This error hits when a DC has been offline past the tombstone lifetime and AD won't replicate with it. You can't just restart it. You usually have to forcibly demote it and clean up its metadata.

You walk in Monday morning and your monitoring dashboard is lit up. One of your branch office domain controllers — usually an old Server 2012 R2 box in a closet in a site nobody visits — hasn't replicated in months. You try repadmin /replsummary and see the dreaded pairing: ERROR_DS_REPL_LIFETIME_EXCEEDED (0x000021A6). Or you see Event ID 1988 in the Directory Service log on a partner DC saying replication with that server has been disabled because the deletion has already been tombstoned on the other side.

This isn't a network blip. It's not a firewall rule. It's the AD equivalent of coming home to find your house has been legally declared abandoned and repossessed while you were on vacation.

Why this error happens

Active Directory keeps deleted objects as "tombstones" for a set period — by default 180 days on Windows Server 2003 SP1 and later (it was 60 days on original 2000/2003 RTM forests). The tombstone is the marker AD uses to tell every other DC in the forest "this object used to exist, don't recreate it during replication."

Here's the problem. If a domain controller stays offline — powered off, isolated by a dead VPN, sitting in a box after a hardware failure, whatever — longer than the tombstone lifetime, it misses all those deletion records. When it finally comes back online and tries to replicate, the other DCs look at it and say: this server's USNs are ancient, and any objects it thinks exist may have already been deleted and tombstoned here. Replication is refused. Permanently. It's a one-way door — the DC won't ever catch up on its own.

Microsoft did not build a "resurrect this stale DC" button. The supported answer is to take it out and bring a clean one back. Anything else risks reanimating a lingering object and corrupting the entire directory.

Real scenario: a client's remote office had a DC behind a consumer-grade firewall. The site-to-site VPN tunnel to the datacenter was flapping for weeks. By the time anyone noticed, that DC had been isolated for 213 days. Repadmin summary showed 0x21A6 on every inbound pair. The forest was fine. That DC was poison.

The fix: forcibly remove the stale DC and clean up metadata

Don't waste time trying to fix replication on the broken DC. It's not going to happen. The real fix is to remove it from the forest using /forceremoval, then manually clean up its metadata on a healthy DC. You'll need Domain Admin or Enterprise Admin rights and access to a working DC with reliable replication.

Step 1: Confirm which DC is stale

On a healthy DC, run this and look at the summary output:

repadmin /replsummary

You should see the stale DC listed with a failure count and the 0x21A6 error. Make a note of its hostname and IP. Also check:

repadmin /showrepl <healthydc> <staledc>
repadmin /showobjmeta <healthydc> <staledc>$

The showobjmeta output will show the DC's own computer account with a last-modified date well past the tombstone lifetime. That's your confirmation.

Step 2: Make sure no FSMO roles live on the stale DC

Open an elevated PowerShell on a healthy DC:

netdom query fsmo

If any role is held by the stale server, seize it before you do anything else. Use ntdsutil or the Move-ADDirectoryServerOperationMasterRole cmdlet. Seizing is safe once you know the source DC is dead or unrecoverable.

Step 3: Check whether it's a GC and whether it hosts DNS

If the stale DC was a Global Catalog or ran DNS zones that aren't AD-integrated or replicated elsewhere, write that down. You'll want to stand up replacements after cleanup. Open DNS Manager on a healthy DC and check for any zones that only existed on the stale DC.

Step 4: Forcibly demote on the stale DC

Get on the stale DC itself if you can — physically or via a local admin account (not a domain account). Open an elevated command prompt and run:

dcpromo /forceremoval

On Server 2012 and later, it's:

Uninstall-ADDSDomainController -ForceRemoval -DemoteOperationMasterRole -Confirm:$false

Reboot when it finishes. The server reboots as a standalone member server or workgroup machine. After this point it will never be a DC again without a full re-promotion.

Step 5: Clean up metadata on a healthy DC

This step is easy to get wrong. Do it from an elevated command prompt on a healthy DC in the same domain:

ntdsutil
metadata cleanup
connections
connect to server <healthyDC>
quit
select operation target
list domains
select domain <number>
list sites
select site <number>
list servers in site
select server <number>
quit
remove selected server
quit
quit

After the server object is removed, wait about 15 minutes for intrasite replication to kick in, then check Sites and Services — the stale DC's NTDS Settings entry should be gone. Delete the server object itself from the Servers container if it's still hanging around.

Step 6: Clean up DNS, AD Sites, and any leftover records

Still on the healthy DC:

Open AD Sites and Services, expand the site the stale DC was in, and delete its server object if it's still there.
Open DNS Manager. Remove its A record from every forward lookup zone it existed in. Remove its CNAME in _msdcs.
Under _msdcs.contoso.com, _sites, _tcp, and _udp, delete any SRV records referencing its hostname. There will be several.
In AD Users and Computers, check the Domain Controllers OU — remove the computer account if it's still present.

You should see the DNS console refresh cleanly with no red X icons once you're done.

Step 7: Force replication and verify

repadmin /syncall /AdeP
repadmin /replsummary

The replsummary output should show zero failures and no mention of the old DC. Run dcdiag /v on each remaining DC to be sure. You're looking for clean passes on the Advertising, FrsSysVol (or DFSR), and Replications tests.

If it still fails

If replication errors persist after cleanup, check these:

Lingering objects. Run repadmin /removelingeringobjects against every remaining DC, referencing a known-good DC that's been offline for less than the tombstone lifetime. This is tedious but necessary if the stale DC was pushing data before you cut it off.
Duplicate SPNs or lingering computer accounts in other OUs. Search AD for the stale DC's name with Get-ADObject -Filter {Name -eq 'STALEDC01'} and remove anything that turns up.
DNS scavenging. If scavenging is off (and it often is), old records might still be resolving. Turn scavenging on with a 7-day no-refresh and 7-day refresh interval — 14 days total is sane for most shops.
Event ID 2042. If you see this on any DC, that DC has hit its own replication quarantine. It may need to be demoted and re-promoted rather than force-removed, depending on whether it can still reach a healthy partner.

Once everything's clean, drop a fresh Server 2019 or 2022 VM in that site, promote it, and move on. The whole point of tombstones is to protect the forest from old data. Respect the design and rebuild.