Lingering Objects Blocking Replication — Event 1988

What the Error Looks Like

Event 1988 appears in the Directory Service event log on the destination DC — the one that has stopped accepting replication. The event body identifies the source DC, the object DN, and the object GUID:

Log Name:      Directory Service
Source:        NTDS Replication
Event ID:      1988
Level:         Error

The local domain controller has attempted to replicate the following
object from the following source domain controller.

Source domain controller: <GUID-based CNAME of source DC>
Object: CN=JohnSmith,OU=Users,DC=corp,DC=example,DC=com
Object GUID: {a1b2c3d4-...}

This object is not present on the local domain controller because
it may have been deleted and already garbage collected.

Source domain controller:
<dc02.corp.example.com>

At the same time, repadmin /showrepl will show a persistent failure with error 8606 (“Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected.”) on one or more naming contexts.

What It Actually Means

Think of a lingering object like a revoked access card that one security guard still has on file. Every other guard was told the card was revoked months ago and has destroyed their copy. But this one guard missed the memo — and now when he tries to wave the card through, the system at the door refuses because it knows the card no longer exists.

In AD terms: an object was deleted on most DCs, became a tombstone, and was eventually garbage-collected (permanently purged). But the source DC was offline, or replication was broken, for longer than the tombstone lifetime. When replication resumed, that DC tried to propagate changes for an object that the destination had already permanently deleted. Strict replication consistency — the correct default posture — refuses to reanimate it, so replication halts.

The alternative (loose replication consistency) would silently reanimate the deleted object on the destination. That is a worse outcome: deleted users, computers, or security groups would re-appear in the directory as live objects, potentially with stale group memberships and permissions.

How to Diagnose

The diagnosis is straightforward. The 1988 event itself gives you most of what you need. Run these commands from an elevated command prompt on any healthy DC.

# Check replication status across the forest — look for 8606 errors
repadmin /showrepl * /errorsonly

# Show the full replication summary, useful for spotting the affected naming context
repadmin /replsum

# Get the GUID of any healthy DC to use as your reference in the removal step
# (look for the "DSA object GUID" line in the output)
repadmin /showrepl dc01.corp.example.com

# Check the tombstone lifetime for the forest — default is 180 days on modern forests
repadmin /showattr "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com" /atts:tombstonelifetime

# Retrieve metadata on the lingering object to understand when it was deleted
# Use the Object GUID from the 1988 event
repadmin /showobjmeta dc02.corp.example.com "<GUID=a1b2c3d4-...>"

In the repadmin /showobjmeta output, look at the LastKnownParent date stamp (when the object was deleted) and the IsDeleted version number. A version of 1 means it was deleted once and never reanimated. An even-numbered version means it was deleted and then auth-restored at least once. That distinction matters for deciding whether the object should exist at all.

Common Causes

The Fix

There are three tools for removing lingering objects. Use them in the order shown — advisory mode first, always.

Option 1 — repadmin (command line, recommended for targeted cleanup)

# Step 1: Run in advisory mode first — this reports what would be removed without touching anything.
# Replace dc02 with the source DC holding lingering objects (named in the 1988 event).
# Replace the GUID with the DSA object GUID of any healthy reference DC (from repadmin /showrepl).
# Replace the DN with the naming context from the 1988 event.
repadmin /removelingeringobjects dc02.corp.example.com {healthy-dc-guid} "DC=corp,DC=example,DC=com" /advisory_mode

# Review the Directory Service event log on dc02 for Event 1388 entries
# (advisory mode logs what it would remove without acting).

# Step 2: Run without /advisory_mode to perform the actual removal.
repadmin /removelingeringobjects dc02.corp.example.com {healthy-dc-guid} "DC=corp,DC=example,DC=com"

# Repeat for the Configuration partition if needed.
repadmin /removelingeringobjects dc02.corp.example.com {healthy-dc-guid} "CN=Configuration,DC=corp,DC=example,DC=com" /advisory_mode
repadmin /removelingeringobjects dc02.corp.example.com {healthy-dc-guid} "CN=Configuration,DC=corp,DC=example,DC=com"

# After removal, force replication and verify it succeeds.
repadmin /syncall /AdeP

Option 2 — Lingering Object Liquidator (GUI, recommended for forest-wide cleanup)

Microsoft’s Lingering Object Liquidator (LOL) is a free download from the Microsoft Download Center (search “Lingering Object Liquidator”). It provides a GUI that scans the entire forest for lingering objects and removes them in bulk. It requires .NET Framework 4.5.2 and Domain Administrator credentials, and it must be run from a machine with network access to all DCs. For environments with multiple affected DCs or multiple naming contexts, LOL is considerably faster than running repadmin per-partition per-DC.

Option 3 — Trigger garbage collection manually (transient objects only)

# If the lingering objects are transient (already deleted, not yet garbage-collected),
# you can trigger the garbage-collection daemon immediately rather than waiting up to 12 hours.
# Run this from an elevated command prompt on the source DC.
repadmin /setattr "" "" doGarbageCollection add 1

Strict Replication Consistency

Strict replication consistency is what causes Event 1988 in the first place — and it is exactly what you want. It has been enabled by default on domain controllers since Windows Server 2003 SP1. On older forests, it may have been left off; check the value on all DCs and enable it if it is missing.

# Check the current value on a DC — 1 = strict (correct), 0 = loose (vulnerable)
reg query "HKLM\System\CurrentControlSet\Services\NTDS\Parameters" /v "Strict Replication Consistency"

# Enable strict replication consistency if not already set (run on each DC that lacks it)
reg add "HKLM\System\CurrentControlSet\Services\NTDS\Parameters" /v "Strict Replication Consistency" /t REG_DWORD /d 1 /f

How to Prevent It

Lingering objects form when replication is broken long enough for garbage collection to outpace it. Prevention is therefore a matter of monitoring replication health continuously and acting before any DC falls silent for longer than the tombstone lifetime.

Final Thoughts

Lingering objects are almost always the consequence of something else that already went wrong — a DC that was offline too long, a snapshot restored carelessly, or a clock that jumped forward. Event 1988 is not the root cause; it is AD telling you that strict consistency is working as designed and that you have debt to repay from an earlier failure.

The cleanup itself is mechanical once you have identified the affected DC and naming context. The more important work is understanding how the gap opened in the first place and closing it so replication health does not degrade silently again. That is what the daily repadmin /showrepl monitoring is for — catching the gap when it is hours old, not months.

For the broader picture of how AD replication works and why it is designed around tombstone lifetimes, see Active Directory — Part 7 — Active Directory Replication.