Share via

Active Directory replication failure, Tombstone lifetime exceeded, FSMO roles on stale DC, Metadata cleanup / domain recovery

TDN 0 Reputation points
2026-05-05T18:29:51.75+00:00

We have an Active Directory environment with two domain controllers. Replication has been broken for over the tombstone lifetime. One domain controller (DC1) has not replicated since 2023 and still holds all FSMO roles. The other DC (DC2) has more recent data but no FSMO roles. We are seeing errors like 8614 (tombstone exceeded) and 0x80090322 (target principal name incorrect). We need guidance on safely recovering the domain — specifically FSMO seizure and cleanup of the stale DC and add a replacement DC and decommission the bad. I tried several number

Windows for business | Windows Server | Directory services | Active Directory
0 comments No comments

2 answers

Sort by: Most helpful
  1. Scott Nguyen 1,150 Reputation points Independent Advisor
    2026-05-05T19:23:52.28+00:00

    Hello, since DC1 has exceeded the tombstone lifetime and error 8614 confirms it is essentially a dead node, you should permanently power it off without reconnecting it to prevent objects from corrupting your recent data. You will then need to log into DC2, open an elevated command prompt, and run ntdsutil to forcefully seize all five FSMO roles, followed by a thorough metadata cleanup in Active Directory Sites and Services to wipe out DC1's obsolete NTDS settings and DNS records. After confirming DC2 is healthy and fully owns the domain topology, you can safely promote your new server to replace the old one.

    0 comments No comments

  2. Q&A Assist
    2026-05-05T18:30:22.3266667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Because replication has been broken longer than the tombstone lifetime and DC1 (with all FSMO roles) is stale, DC1 must be treated as a permanently failed domain controller and removed from the environment. Recovery is done by isolating/removing the stale DC, cleaning up its metadata, and then rebuilding/replacing it, with FSMO roles moved to a healthy DC.

    A high‑level, safe recovery path based on the provided guidance is:

    1. Treat DC1 as failed and isolate it
      • Remove DC1 from the production network (disconnect or place on a private network) so it can no longer participate in replication or service clients.
      • Do not attempt to reintroduce DC1 into the domain, because it has exceeded tombstone lifetime and will contain lingering objects and inconsistent data.
    2. Clean up DC1 from Active Directory (metadata cleanup)
      • Follow the standard metadata cleanup procedure to remove the failed DC’s server object, NTDS Settings object, and related references from AD DS so that it cannot be revived and replication attempts to it stop. The guidance explicitly states that for DCs that have been offline longer than tombstone lifetime, the solution is to move the server off the network, forcefully remove AD or reinstall the OS, and then remove server metadata so the server object cannot be revived.
      • This prevents automatic revival of the NTDS Settings object (which can occur for up to 14 days) and avoids persistent replication errors.
    3. Ensure DC2 is healthy and resolve replication/lingering issues Since DC2 is the only remaining DC and has more recent data, it becomes the basis for recovery:
      1. Check tombstone lifetime configuration
        • Use repadmin /showattr <DC2> "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<forest root>,DC=<tld>" to see whether a nondefault TombstoneLifetime is configured. If the attribute is absent, the internal default (typically 60 or 180 days) applies.
      2. Verify and fix replication state (even though DC1 is being removed)
        • Run repadmin /showrepl on DC2 to confirm there are no remaining replication partners or partitions referencing DC1. Any remaining references should be cleared as part of metadata cleanup.
      3. Check for time jumps and lingering objects
        • The 8614 error and Event ID 2042 are associated with replication failures beyond tombstone lifetime and possible time jumps. The guidance for 8614/2042 is to:
          • Check for time jumps on the DC.
          • Detect and remove lingering objects.
        • Use the preferred method for lingering object detection/removal (Lingering Object Liquidator v2) or repadmin /removelingeringobjects in advisory mode, using DC2 as the authoritative source.
      4. Address the 0x80090322 (target principal name incorrect) error
        • The guidance for this error is to:
          • Use repadmin /showobjmeta on the source DC and the KDC to check for differences in password‑related attributes for the DC’s computer account.
          • Use netdom resetpwd /server:<DC> /userd:<user> /passwordd:<password> on the affected DC to reset the machine account password.
        • In this scenario, once DC1 is removed and DC2 is the only DC, ensure DC2’s machine account is consistent by using netdom resetpwd if needed.
    4. Seize FSMO roles to DC2 After DC1 is isolated and treated as failed, FSMO roles must be seized to DC2 so the domain can function:
      • Use the standard FSMO seizure procedure (for example, via ntdsutil or equivalent tools) to seize all FSMO roles (Schema Master, Domain Naming Master, RID Master, PDC Emulator, Infrastructure Master) to DC2.
      • Because DC1 is permanently failed and removed, this is a seizure, not a transfer.
    5. Add a replacement domain controller Once DC2 is healthy and holds all FSMO roles:
      • Build a new server (DC3) with a fresh OS installation.
      • Join it to the domain and promote it to a domain controller.
      • Verify replication between DC2 and DC3 using repadmin /showrepl and ensure no errors such as 8614, 2042, or 0x80090322 appear.
    6. Decommission the old DC1 host
      • After metadata cleanup and FSMO seizure, DC1 must never be brought back into the domain with its old AD database.
      • Either:
        • Reinstall the OS on DC1 and join it as a new member server or new DC (if needed), or
        • Permanently decommission the hardware/VM.
    7. Ongoing checks and prevention
      • Use the Active Directory replication troubleshooting guidance to monitor for common replication issues (network, DNS, authentication, replication topology) so that replication failures do not again exceed tombstone lifetime.
      • Ensure time synchronization is correct to avoid time jumps that can cause 8614/2042.

    This approach aligns with the documented guidance for:

    • Handling replication failures that exceed tombstone lifetime (Event ID 2042, error 8614).
    • Treating long‑offline DCs as failed, removing them, and cleaning up metadata.
    • Resolving “target principal name is incorrect” replication errors via machine account password reset.

    References:

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.