Windows Server  ·  critical  ·  Active Directory deep faults

Lingering objects and replication event 1988

A controller that was offline longer than the tombstone lifetime holds objects the rest of the domain has deleted. Replication stops rather than resurrect them.

What you see

Event 2042 saying it has been too long since this machine replicated, or event 1988 naming a lingering object. Replication with that partner is halted.

What is actually wrong

A domain controller offline for longer than the tombstone lifetime — 180 days on most domains — then brought back. Its copy of the directory contains objects that were deleted while it was away.

Codes and articles

Event 1988Event 2042lingering objectIt has been too long since this machine last replicated8614

Fixes (2)

Identify and remove the lingering objects
Elevated PowerShell90 minuteshigh risknot reversible

The controller is otherwise healthy and you want to keep it.

  1. Find the tombstone lifetime for this forest — it governs everything below.

    PowerShell
    Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Properties tombstoneLifetime | Format-List tombstoneLifetime

  2. Check the replication state to see which partners are blocked.

    PowerShell
    repadmin /replsummaryrepadmin /showrepl * /csv | ConvertFrom-Csv | Where-Object 'Number of Failures' -gt 0 | Format-Table

  3. List the lingering objects without removing anything — the /advisory_mode flag is what makes this safe.

    PowerShell
    repadmin /removelingeringobjects DC02 <source-DC-GUID> dc=example,dc=local /advisory_mode

    Advisory mode writes event 1946 for every object it would remove, into the Directory Service log. Read that list before running it for real — this is a deletion and it is not reversible.

  4. Read the resulting events to see exactly what would go.

    PowerShell
    Get-WinEvent -LogName 'Directory Service' -MaxEvents 200 | Where-Object Id -in 1938,1942,1946 | Format-List TimeCreated,Id,Message

  5. Remove them once the list is understood.

    PowerShell
    repadmin /removelingeringobjects DC02 <source-DC-GUID> dc=example,dc=local

  6. Re-enable strict replication consistency so this cannot recur silently.

    PowerShell
    repadmin /regkey * +strictrepadmin /replsummary
Confirm it workedReplication resumes with no failures and no further 1988 events.
PowerShell
repadmin /replsummary; repadmin /showrepl DC02
If you need to undo itRemoved objects are gone. Restore from a system state backup if the wrong objects were removed.
Demote and rebuild rather than repair
Elevated PowerShell3–4 hourshigh risknot reversible

The controller was offline far beyond the tombstone lifetime. This is usually the right answer and it is often faster.

  1. Take it off the network first so it cannot replicate anything outward while you work.

  2. Move any FSMO roles it holds to a healthy controller, and check it is not the only global catalog or DNS server for a site.

    PowerShell
    netdom query fsmoGet-ADDomainController -Filter * | Format-Table Name,Site,IsGlobalCatalog,OperationMasterRoles

  3. Demote it forcibly, since it cannot replicate the demotion out.

    PowerShell
    Uninstall-ADDSDomainController -ForceRemoval -DemoteOperationMasterRole -LocalAdministratorPassword (Read-Host -AsSecureString) -Force

    A forced demotion does not tell the rest of the domain. That is why the metadata cleanup in the next step is mandatory rather than tidy-up — without it, every other controller keeps trying to replicate with a machine that no longer exists.

  4. Clean the metadata from a healthy controller.

    PowerShell
    Get-ADObject -Filter { Name -eq 'DC03' } -SearchBase (Get-ADDomain).DomainControllersContainer | Remove-ADObject -Recursive -Confirm:$false

  5. Rebuild the machine from clean media and promote it again.

    PowerShell
    Install-ADDSDomainController -DomainName example.local -InstallDns -Credential (Get-Credential) -SafeModeAdministratorPassword (Read-Host -AsSecureString)

  6. Verify the new controller replicates in both directions before putting it into service.

    PowerShell
    repadmin /showrepldcdiag /v | Select-String 'failed|passed test'
Confirm it workeddcdiag is clean, replication succeeds both ways, and SYSVOL is shared.
PowerShell
dcdiag /test:sysvolcheck /test:advertising /v | Select-String 'passed|failed'net share | findstr /i sysvol
If you need to undo itNone. Ensure a current system state backup of a healthy controller exists before starting.

Related faults

AD replication error 8524 — the DSA operation cannot continue (DNS lookup failure)Windows ServerUSN rollback — event 2095 and a controller that stops replicatingWindows ServerError 1722 — the RPC server is unavailableWindows ServerDNS event 4013 — waiting for Active Directory to signal it has completed initial synchronisationWindows ServerNTDS events 2087 and 2088 — DNS lookup failure caused replication to failWindows Server

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.