Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

License Error 8606

Error 8606 lingering objects: clearing stale AD data that blocks replication

13 min read Updated October 4, 2026 Windows Server: AD, DNS & Group Policy

Fix it now

Error 8606 is published as insufficient attributes being given to create an object, which may not exist because it was deleted and already garbage collected. A source DC is sending updates for objects this DC has already removed. Purge them against a DC with a correct writable copy, then put strict consistency back on.

Run these from a healthy DC, in an elevated Command Prompt

repadmin /showobjmeta <fqdn of source DC> "<GUID=object guid from the 1988 event>"
repadmin /removelingeringobjects <DC holding them> <GUID of the reference DC> "<naming context DN>" /advisory_mode
  1. Filter the Directory Service log for Event ID 1988 on each DC reporting 8606, and collect the object and object GUID from each one.
  2. Note carefully which DC to clean: the first argument is the DC that holds the lingering objects, which is the source DC named in the 1988 event, not the DC that logged it.
  3. The second argument is the DSA object GUID of a DC hosting a writable, correct copy of that partition. Get it wrong and you delete good data instead of stale data.
  4. Run with /advisory_mode first, read what it reports in the Directory Service log, and only then run the same command without it.
  5. Repeat for every affected partition, then enable strict replication consistency everywhere: repadmin /regkey * +strict

The DC being cleaned must be able to connect directly to TCP 389 on the DC hosting the writable copy. If it cannot, the command fails for a reason that has nothing to do with the objects.

If advisory mode comes back empty and replication is running, stop here. The next section explains how a deleted object comes back and why one registry value decides whether you get an outage or a silent resurrection.

Why it happens

When an object is deleted, a marker replicates so every controller learns of the deletion, and after the tombstone lifetime garbage collection removes the marker. A controller that was disconnected for that whole period never saw the marker, so it still holds the original object. When it reconnects and sends an update for that object, its partners have nothing to apply the update to. That mismatch is 8606, published as insufficient attributes being given to create an object which may not exist because it may have been deleted and already garbage collected.

What happens next is decided by one registry value. With strict replication consistency enabled, the destination blocks replication of the entire directory partition containing that object from that source, and logs Event ID 1988: the source DC contains a lingering object which does not exist on the local DC’s database, and this replication attempt has been blocked. With strict consistency disabled, the destination logs Event ID 1388 instead, re-requests the object with a full attribute set, and re-creates it locally. That is how a deleted account quietly reappears across an entire forest.

Both events matter when you are working out how far this has spread. A forest full of 1988 entries has a replication outage and a containable problem. A forest with 1388 entries has already reanimated objects, and they will be sitting on controllers that never reported an error at all, which is why the purge has to be run against every controller rather than only the noisy one.

A controller returned after a long disconnection

You have this one if Event ID 1988 started appearing shortly after a controller came back online, was restored, or had a long-broken link repaired.

  1. Identify from the 1988 events which DC is named as the source. That is the DC holding the lingering objects and the one to clean.
  2. Choose a reference: a DC hosting a writable, correct copy of the partition, and get its DSA object GUID from repadmin /showrepl.
  3. Run the removal in advisory mode against the holder for each naming context in turn, and read the Directory Service log.
  4. Repeat without the advisory switch, then force replication and confirm the queue drains.

If that controller was also past the tombstone lifetime, purging its lingering objects is only part of the answer; read the 8614 article as well.

Strict replication consistency was turned off

You have this one if Event ID 1388 rather than 1988, and objects you know were deleted are present again.

  1. Purge from every controller, not only the ones reporting errors. A controller that received a reanimated object reports nothing at all.
  2. Use the same reference DC throughout so you are converging on one truth rather than several.
  3. Re-enable strict consistency across the forest: repadmin /regkey * +strict
  4. Audit the accounts and groups that came back, particularly anything that was disabled or deleted for a security reason.

The registry value is Strict Replication Consistency under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, REG_DWORD, 1 enabled. It defaults to 1 on new installations.

You are pointing the command at the wrong DC

You have this one if The removal runs, reports nothing, and the errors continue.

  1. Re-read the argument order: repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/advisory_mode].
  2. The first argument is the DC that contains the lingering objects, which is the source DC cited in the 1988 event on your failing destination.
  3. The second is the GUID of a DC hosting a writable copy of the partition, which is your reference for what should exist.
  4. Confirm the first DC can reach TCP 389 on the second. Microsoft calls that out as a requirement and it is a common silent failure.

This is the single most common way this procedure is run to no effect: aimed at the machine that logged the error rather than the machine that holds the stale data.

Only some partitions were cleaned

You have this one if The domain partition is clean but errors continue, or replication is still blocked for the configuration partition.

  1. Work through the partitions that can actually hold lingering objects. Microsoft states all directory partitions except the schema partition can contain them.
  2. They are most frequently found in read-only domain partitions on global catalogs, and also occur in writable domain partitions and the configuration partition.
  3. For a read-only partition on a global catalog, repadmin /rehost <DSA> <naming context> <good source DSA> is the documented route.
  4. Only re-enable strict consistency once every partition shows a recent success, so you are not blocking replication you have just repaired.

Do not spend time cleaning the schema partition. Microsoft states it cannot hold lingering objects.

Full reference

The command, argument by argument

Argument What it must be
<Dest_DSA_LIST> The DC that contains the lingering objects. In practice, the source DC cited in the NTDS Replication 1988 event
<Source DSA GUID> The DSA object GUID of a DC hosting a writable, correct copy of the directory partition
<NC> The distinguished name of the partition suspected of containing lingering objects
/ADVISORY_MODE Optional. Scans and reports without removing anything. Always run this first

Choosing the wrong reference DC reverses the direction of the operation and deletes good data instead of stale data. Run advisory mode, read what it reports, and be certain the reference holds the correct copy before you run it for real.

Which partitions can hold them

  • All directory partitions except the schema partition can contain lingering objects.
  • They are most frequently found in read-only domain partitions on global catalog servers.
  • They also occur in writable domain partitions and in the configuration partition, which is the one most often forgotten.
  • For a read-only partition on a global catalog, repadmin /rehost DSA <naming context> <good source DSA address> is the documented alternative to a removal.

The two events, and what each one means for your day

Event What it means Consequence
1988 Strict replication consistency is on. The source contains a lingering object and this replication attempt has been blocked A replication outage, and a contained problem
1388 Strict consistency is off. The object is re-requested with a full attribute set and re-created on this DC No error anywhere, and a deleted object is back

Microsoft’s own text for 1988 ends with the sentence worth taking as the instruction: the best solution to this problem is to identify and remove all lingering objects in the forest. Not the ones on the DC that is complaining – all of them.

Strict replication consistency

Detail
Registry path HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Value name Strict Replication Consistency
Type REG_DWORD
Data 1 enabled, 0 disabled
Default 1 on new Windows Server installations; otherwise 0
repadmin form repadmin /regkey <DC_LIST> +strict, or -strict to disable

<DC_LIST> accepts a single fully qualified name, * for every DC, or gc: for the global catalogs. In a forest that was upgraded from Windows 2000, new DCs may not pick this up automatically, so check rather than assume.

Finding the objects in the first place

  1. Read the forest’s tombstone lifetime: repadmin /showattr "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root>,DC=<tld>" /atts:tombstonelifetime
  2. For each destination DC logging 8606, filter the Directory Service log on NTDS Replication event 1988.
  3. For each unique object cited, run repadmin /showobjmeta <fqdn of source DC from the 1988 event> "<GUID=object guid>".
  4. Decide the reference DC and get its DSA object GUID from repadmin /showrepl.
  5. Run the removal in advisory mode, read the log, then run it for real.
  6. Monitor afterwards with repadmin /showrepl * /csv, treating DCs that have not replicated within 50 percent of the tombstone lifetime as needing attention and those past 90 percent as candidates for demotion.

Causes beyond the obvious one

  • A source DC that was offline or failing replication for a tombstone lifetime. The headline case.
  • An object at the cusp of tombstone expiry, already garbage collected on a strict-mode destination, particularly after a partial attribute set update.
  • A time jump on a destination DC that sped up garbage collection prematurely.
  • An object reanimated at the cusp of expiry, for instance by an authoritative restore of a system state backup.
  • A USN bubble, where an object did not outbound-replicate while the bubble was open, and its later changes then arrive looking like lingering objects.

8240, and why it is here

8240 is published as ERROR_DS_NO_SUCH_OBJECT, “There is no such object on the server”. It turns up in repadmin output for operations aimed at an object the target does not hold, which is why it keeps company with 8606. Microsoft’s 8606 page does not name it, though, so do not treat the two as interchangeable: 8606 is a specific replication refusal with a specific remedy, and an 8240 on its own may be nothing more than a command pointed at an object that is not there.

When a licence is the actual fix

The purge itself costs nothing: the removal tool ships with the AD DS management tools and the whole procedure uses software you already own. What tends to come with it is a decision about the controller that caused the problem, because a machine that spent months disconnected is usually old, forgotten, and running a build you would rather not keep. If you rebuild it, the replacement needs a Windows Server 2025 licence, and Arco can supply that and confirm whether an agreement you already hold covers the machine first. Standard limits the number of Windows virtual instances you may run on the licensed hardware and Datacenter does not, so if the rebuild is also the moment you consolidate onto one host, it is worth working the arithmetic before choosing.

Every code this article covers

Code What it points at Source
8606 ERROR_DS_INSUFFICIENT_ATTR_TO_CREATE_OBJECT: insufficient attributes were given to create an object, which may not exist because it may have been deleted and already garbage collected Microsoft Learn
8240 ERROR_DS_NO_SUCH_OBJECT: there is no such object on the server. Published on its own terms; Microsoft’s 8606 guidance does not name it, so do not read the two as the same fault Microsoft Learn
Event ID 1988 The source DC contains a lingering object which does not exist on the local DC’s database, and this replication attempt has been blocked Microsoft Learn
Event ID 1388 Another DC attempted to replicate in an object not present locally; the object will be re-requested with a full attribute set and re-created on this DC Microsoft Learn

Confirm the fix worked

  1. Re-run the removal in advisory mode for each partition and confirm it reports nothing left to remove.
  2. repadmin /replsummary shows every partner with a recent success.
  3. Strict replication consistency is enabled on every controller, including any promoted recently.
  4. Search the directory for the specific accounts or groups you know were deleted and confirm they are gone everywhere, not just on the DC that reported the error.
  5. Re-check repadmin /showrepl * /csv a week later to confirm nothing is drifting back.

Questions people ask about this

Which DC do I run the removal against?

The one that holds the lingering objects, which is the source DC named in the 1988 event, not the DC that logged the error. Microsoft documents the first argument as the DC containing the lingering objects and the second as a DC hosting a writable, correct copy. Aimed the wrong way round the command does nothing useful.

Do I need to clean the schema partition too?

No. Microsoft states that all directory partitions except the schema partition can contain lingering objects. Spend the time on the configuration partition instead, which is the one people actually forget.

Does the Active Directory Recycle Bin help here?

No. The recycle bin changes how deleted objects are stored and recovered within their lifetime. It does nothing about copies held on a controller that missed the deletion entirely.

Should I run this against every controller or just the one reporting errors?

Every controller, once you know reanimation has happened. A controller that received a reanimated object under Event ID 1388 reports nothing at all, so the quiet ones are exactly the ones to check.

The command fails immediately. What am I missing?

Check connectivity. Microsoft states the DC being cleaned must be able to connect directly to port 389 on the DC hosting the writable copy of the partition. If that path is blocked, the command cannot do its job and the failure looks unrelated to the objects.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

License Error Error 8610: FSMO role ownership cannot be verified until the partition replicates License Error Event ID 2095 USN rollback: a domain controller restored from a snapshot Free Fix Error 1722 RPC server unavailable between DCs: ports, firewalls and mappers License Error DFSR Event ID 5002: SYSVOL partners cannot hold an RPC session open
← Back to Knowledge Base