Lingering objects and replication quarantine

How an old object survives

Deleting an AD object leaves deletion information long enough for other replicas to receive it. If a DC misses that information and returns after it has been garbage-collected elsewhere, it can retain a live object that the rest of the directory has deleted. That is a lingering object.

The risk follows failed replication, not simply a powered-off server. A DC can remain online while a naming context fails to replicate for months. A partial replica on a GC can also contain lingering objects. See Microsoft’s lingering object overview.

Read the event precisely

Keep the source, destination, object GUID, and naming context from the event. You’ll need them to choose the reference and affected replicas. Microsoft’s event guide distinguishes 1388 from 1988, and its common error index covers 1311 and 2042.

Read the lifetime in this forest

Don’t assume every forest uses 60 days, or every newer forest uses 180. Check its creation history and any later changes.

$config = (Get-ADRootDSE -Server 'DC1.contoso.com').configurationNamingContext
Get-ADObject -Server 'DC1.contoso.com' `
    -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$config" `
    -Properties tombstoneLifetime, msDS-DeletedObjectLifetime |
    Select-Object tombstoneLifetime, msDS-DeletedObjectLifetime

An unset attribute uses the documented fallback; it doesn’t mean zero days. Recycle Bin also changes the deleted-object lifecycle, so keep deleted-object lifetime and tombstone lifetime separate. The ADAC management guide explains the defaults and their history.

Check protection without changing it

Run these read-only registry queries locally on the DC being checked:

reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "Strict Replication Consistency"
reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "Allow Replication With Divergent and Corrupt Partner"

An absent value needs interpretation against the documented default and forest history. The repadmin /regkey forms with a leading + or - change a setting, so keep those out of a routine collection script. Also check the policy for newly promoted DCs in a forest with old origins; raising a functional level does not itself fix strict-consistency settings.

Advisory comparison needs a trustworthy reference

First establish an up-to-date DC with a writable copy of the affected partition. Obtain its DSA object GUID, not its invocation ID. Then compare the suspect replica in advisory mode:

repadmin /removelingeringobjects DC2.contoso.com <reference-DSA-GUID> "DC=contoso,DC=com" /advisory_mode

Replace the placeholder before use. Advisory mode logs candidates without deleting them. Check the results and your choice of reference before removing anything; a wrong reference can turn cleanup into data loss.

Removal changes directory data. Use the current documented process for the actual condition and every affected partition/replica. Event 1388 needs particular attention because the object has already been reintroduced; a general lingering-object removal command is not a complete response to that state.

Do not make the error disappear by disabling protection

Allowing replication with a divergent partner doesn’t recover missed deletions. Work out the affected replicas, backups, and recovery plan first. Rebuilding an isolated DC may be preferable to reconnecting it, but check which unique changes or services you’d lose. Start with the 2042 procedure for that event.

Build a partition-specific reference map

A good reference for one domain NC is not necessarily a writable reference for another. For each affected partition, record the reference DC, whether its replica is writable, its last successful replication, and why its object history is trusted. Include GCs in the target inventory because their partial replicas can preserve a lingering object too.

repadmin /showrepl DC1.contoso.com /verbose
repadmin /showutdvec DC1.contoso.com "DC=contoso,DC=com" /latency

Use the DSA object GUID in the header for the reference in the removal command. The invocation ID shown nearby is a different identifier. Confirm the source field in an event too: the DC logging 1988 is the destination refusing data; the event identifies the source that supplied the suspect update. Microsoft’s 1988 procedure documents those parameter roles.

Use advisory findings to define removal scope

Save the Directory Service events from advisory mode, including object GUIDs and the exact NC. Compare each candidate by GUID on the reference and suspect DC. Names can be reused after deletion, so matching display names aren’t enough.

Deletes directory objects: after validating the reference and candidates, repeat the same specific comparison without /advisory_mode. Then repeat detection across the affected replicas and naming contexts. Record which command targeted which partition; a successful removal against one DC does not clean the forest automatically. If event 1388 has already reintroduced a writable object, follow that condition’s recovery analysis instead of assuming a comparison against another copy will identify it as lingering.

Restore the protection after a diagnosed 2042 recovery

For the case where cleanup is complete and the documented 2042 recovery calls for temporarily allowing the blocked source, the state-changing commands are scoped to the DC that logged the block:

repadmin /regkey DC1.contoso.com +allowDivergent

After successful replication and confirmation that the condition is resolved, reinstate the protection:

repadmin /regkey DC1.contoso.com -allowDivergent

These commands belong to the 2042 resolution. They aren’t a general repair for stopped replication. Check for clock jumps and restores too; a serious time jump can trigger elapsed-time protection without a long real outage.

Monitor the affected relationships for fresh successes and recurring errors. A successful test logon is useful, but it won’t tell you whether every naming context is healthy or all lingering objects are gone.

An abandoned object can defeat the ordinary comparison

A different history can leave an object only in a GC partial replica or RODC: a writable DC originates a creation or restore, sends it to read-only replicas, then disappears before the other writable replicas receive it. Those writable replicas never acquire the relevant creation/restore knowledge. This is an abandoned object, rather than merely a replica that missed an ordinary deletion.

Symptoms include a GC finding an object absent from the owning domain’s writable DCs, phantom name/SPN collisions, event 1084/1988, or error 8240. Ordinary lingering-object removal can leave such an object because its originating history lies outside the writable reference’s up-to-dateness scope. Repeating removal against the same reference does not change that history.

Keep the object GUID, owning NC, replicas containing it, deleted-state records on writable replicas, retired/current invocation IDs and promotion/removal history. Microsoft’s abandoned-object analysis has separate recovery paths depending on object type and whether a tombstone survives. Those procedures aren’t general undelete/delete or metadata-reset recipes for DC, RID or other dependent objects.