Fixing Windows Server Replication Error 8606: A Comprehensive Troubleshooting Guide

Table of Contents

Active Directory replication is a cornerstone of a healthy Windows Server environment. When replication issues arise, they can lead to inconsistencies, service disruptions, and potential data loss. One common and critical error encountered is Active Directory replication error 8606, which manifests as “Insufficient attributes were given to create an object.” This guide provides a detailed approach to understanding, diagnosing, and resolving this specific replication problem.

Understanding Active Directory Replication Error 8606¶

Error 8606, “Insufficient attributes were given to create an object,” signals a fundamental discrepancy in the Active Directory database between two domain controllers. Specifically, it occurs when a source domain controller attempts to replicate an update for an object that no longer exists on the destination domain controller. The object in question has likely been deleted and subsequently garbage collected on the destination, while it still persists or is being updated on the source.

This error is often indicative of lingering objects, which are objects that have been deleted from the Active Directory database on some domain controllers but remain on others due. Such inconsistencies can be detrimental to the integrity of the directory service and require prompt attention. Resolving error 8606 involves a thorough investigation into the state of the Active Directory database across your domain controllers and a systematic cleanup process.

Symptoms of Replication Error 8606¶

Identifying the presence of replication error 8606 typically involves reviewing various Active Directory diagnostic tools and event logs. The error can manifest in several distinct ways, each pointing to the underlying issue of inconsistent object states. Understanding these symptoms is crucial for accurate diagnosis.

Symptom 1: DCDIAG Reports¶

The DCDIAG utility, a primary tool for diagnosing domain controller health, often reports the failure of Active Directory replication tests when error 8606 is present. The output will clearly state the error, providing details about the source and destination domain controllers involved.

You might see a message similar to this:

Starting test: Replications
[Replications Check, <Destination DC>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context: <directory partition DN path>
The replication generated an 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
The failure occurred at <date> <time>
The last success occurred at <date> <time>

This DCDIAG report is a clear indication that a replication attempt has failed due to an object state mismatch. The presence of “This object may not exist because it may have been deleted and already garbage collected” specifically points to the lingering object problem. It highlights the exact naming context affected and the timing of both the failure and the last successful replication.

Symptom 2: Active Directory Sites and Services Snap-in (DSSITE.MSC)¶

When attempting to manually trigger replication using the “Replicate Now” command within the Active Directory Sites and Services snap-in (DSSITE.MSC), the operation may fail with error 8606. This interactive failure provides immediate feedback of the replication issue.

Upon right-clicking a connection object from a source domain controller and selecting “Replicate now,” an error dialog box will appear. The dialog typically displays “Access is denied” along with the detailed message:

Dialog title text: Replicate Now
Dialog message text: The following error occurred during the attempt to synchronize naming context <%active directory partition name%> from domain controller <source DC> to domain controller <destination DC>:

Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected.

The operation will not continue

This interactive error confirms that the destination domain controller is unable to process the incoming replication due to the presence of a conflicting object state. It directly references the specific naming context and the involved domain controllers, making it straightforward to identify the scope of the problem.

Symptom 3: Repadmin.exe Command Failures¶

Various repadmin.exe commands, indispensable for monitoring and managing Active Directory replication, will also fail when encountering error 8606. These failures underline the pervasive nature of the replication issue throughout the environment.

Commands such as repadmin /add, repadmin /replsum, repadmin /showrepl, and repadmin /syncall may all report error 8606. The output of these commands will usually include the standard error message, indicating that objects cannot be created due to insufficient attributes or because they have been deleted and garbage collected. This widespread failure across different repadmin functions suggests that the underlying cause is impacting core replication processes.

Symptom 4: Event 1988 Logging¶

Event 1988, an NTDS Replication event, is often logged shortly after specific critical events within the Active Directory environment. These events often signal conditions that can lead to lingering objects and subsequent 8606 errors.

Such events include the initial deployment of the first domain controller in a new forest or any updates made to the partial attribute set. These operations can sometimes create or expose lingering objects, especially in environments where replication has been inconsistent. The logging of Event 1988 in these contexts serves as an early warning of potential replication problems.

Symptom 5: NTDS Replication Event 1988¶

A detailed NTDS Replication Event 1988 may be logged in the Directory Service event log on domain controllers attempting to inbound-replicate Active Directory. This event provides specific information about the lingering object that is preventing replication.

The event log entry will typically have the following characteristics:

Type: Error
Source: NTDS Replication
Category: Replication
Event ID: 1988
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: <hostname of DC that logged event, aka the "destination" DC in the replication attempt>
Description: The local domain controller has attempted to replicate the following object from the following source domain controller. This object is not present on the local domain controller because it may have been deleted and already garbage collected.
Source domain controller:
<fully qualified GUIDED CNAME of source DC>
Object:
<DN path of live object on source DC>
Object GUID:
<object GUID of object on source DCs copy of Active Directory>

This comprehensive event message is a cornerstone for troubleshooting, as it directly identifies the specific object (by DN path and GUID) and the source domain controller from which it is attempting to replicate. The clear statement that “This object is not present on the local domain controller because it may have been deleted and already garbage collected” precisely explains the nature of the lingering object issue.

Root Causes of Error 8606¶

Error 8606 is fundamentally caused by a mismatch in the state of an object between a source and a destination domain controller, combined with a strict replication policy. Understanding these underlying conditions is key to resolving the error effectively.

The error is logged when two primary conditions are met:
1. Source DC sends an update for an object that is already gone on the destination DC: A source domain controller attempts to replicate an update (not an originating object creation) for an object that has already been created, deleted, and then reclaimed by garbage collection from the destination domain controller’s copy of Active Directory. This means the destination DC considers the object non-existent.
2. Destination DC operates with strict replication consistency: The destination domain controller is configured to run in “strict replication consistency” mode. In this mode, the DC will refuse to accept updates for objects it believes are deleted. If the destination domain controller were configured for “loose replication consistency,” the object would have been “reanimated” on the destination’s copy of the directory, potentially masking the underlying inconsistency but avoiding the 8606 error.

Specific variations that can lead to error 8606 include:
* A permanently lingering object: This is an object whose removal requires administrative intervention because it has persisted on some domain controllers beyond its expected tombstone lifetime (TSL).
* A transient lingering object: This type of lingering object will correct itself automatically when the source domain controller performs its next garbage collection cleanup cycle. Known causes for this condition include the introduction of the first domain controller into an existing forest or any updates to the partial attribute set (PAS).
* An object undeleted or restored at the cusp of tombstone lifetime expiration: If an object is restored or undeleted on a source DC just as its tombstone lifetime is expiring or has expired on other DCs, it can lead to replication conflicts.

When troubleshooting 8606 errors, several critical points should be considered:

• Problem Object Location: Although error 8606 is logged on the destination domain controller, the problematic lingering object that is blocking replication actually resides on the source domain controller. This source DC, or a transitive replication partner of the source, likely failed to inbound-replicate knowledge of a deleted object within the tombstone lifetime period.
• Lingering Object Characteristics: Lingering objects can exist in various forms. They might appear as “live” objects, as conflict-mangled objects (e.g., CNF objects), or even within the deleted objects container on the source domain controller. They can reside in any directory partition except the schema partition (which does not support deletes), with read-only domain partitions on Global Catalog (GC) servers being common locations.
• Searching by Object GUID: It is crucial to search for potentially lingering objects by their object GUID rather than their Distinguished Name (DN) path. This approach ensures that objects can be located regardless of their host partition or parent container. Searching by GUID also allows for finding objects within the deleted objects container without needing specific LDAP controls for deleted objects.
• Event 1988 Scope: The NTDS Replication 1988 event typically identifies only one specific object on the source domain controller that is currently blocking incoming replication from a strict-mode destination domain controller. However, it is highly probable that additional lingering objects exist “behind” the one referenced in the 1988 event, queued for replication.
• Replication Queue Impact: The presence of lingering objects on a source domain controller directly prevents or blocks strict-mode destination domain controllers from inbound-replicating “good” changes that are further down the replication queue. This can lead to a buildup of replication backlog.
• Transient Lingering Objects: Due to the independent garbage collection schedules of domain controllers (which typically runs every 12 hours from the last startup), some lingering objects causing 8606 errors may be transient. These objects might be removed during the next garbage collection cycle, usually within 12 hours of the problem’s onset.
• Intentional Deletions: The lingering object in question was likely intentionally deleted by an administrator or an application. This factor must be carefully considered in your resolution plan. Exercise caution to avoid inadvertently reanimating objects, especially security principals, that were deliberately removed.

Comprehensive Resolution Steps¶

Resolving Active Directory replication error 8606 requires a systematic approach, starting with identification of the problem object and culminating in its removal. The process involves leveraging various diagnostic tools and understanding the lifecycle of objects in Active Directory.

Step 1: Identify the Forest-Wide TombstoneLifeTime (TSL)¶

The TombstoneLifeTime (TSL) setting dictates how long deleted objects (tombstones) are retained in Active Directory. This value is critical for determining whether an object is truly lingering or simply awaiting garbage collection.

To find the current TSL value for your forest, execute the following command:

repadmin /showattr "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=forest root domain,DC=TLD" /atts:tombstonelifetime

Understanding the TSL is fundamental because lingering objects are those that have been deleted on some domain controllers for longer than the TSL, yet still exist on others. This knowledge helps differentiate between objects that are legitimately gone and those that are stuck.

Step 2: Filter Directory Service Event Logs for Event 1988¶

On each destination domain controller that is logging the 8606 error, diligently filter the Directory Service event log for NTDS Replication Event 1988. This event is the primary source of information about the specific objects causing the replication failures.

Reviewing these events will provide crucial details such as the object’s Distinguished Name (DN) path, its GUID, the source domain controller attempting to replicate it, and the error description. Each unique Event 1988 entry represents a specific lingering object preventing replication.

Step 3: Collect Object Metadata for Each Unique Object¶

For every unique object cited in an NTDS Replication Event 1988, gather comprehensive metadata. This information is essential for understanding the object’s history and determining the appropriate course of action.

Create a table to organize this metadata, including the following columns:

Object DN path	Object GUID	Source DC	Host partition	Live or deleted?	LastKnownParent	IsDeleted value

Columns 1 through 5 can be directly populated from the fields within the NTDS Replication 1988 events logged on the destination domain controllers. To determine the date stamps for the LastKnownParent and IsDeleted columns, use the repadmin /showobjmeta command, referencing the object’s GUID as cited in the 1988 event.

Use the following syntax:

repadmin /showobjmeta <fqdn of source DC from 1988 event> "<GUID=GUID of object cited in the 1988 event>"

The date stamp associated with LastKnownParent typically indicates when the object was last moved or parent changed, but in the context of deletions, it can often align with the object’s deletion date. The date stamp for IsDeleted reveals when the object was last deleted or reanimated. The version number for IsDeleted indicates whether the last modification was a deletion (version 1) or a reanimation (odd numbers greater than 1, e.g., version 2 for undelete after an initial delete). Even-numbered values for IsDeleted (like 2, 4, 6…) usually denote subsequent reanimations or undeletes of the object.

Step 4: Choose Appropriate Action Based on Object Metadata¶

Based on the metadata collected in the table from Step 3, you can select the most appropriate action to resolve the lingering object issue. Error 8606 / NTDS Replication event 1988 is most often caused by long-term replication failures that prevent domain controllers from replicating knowledge of all originating deletes in the forest, resulting in lingering objects on one or more source domain controllers.

• If the object in the 1988 event is live on the source domain controller but has been deleted on the destination domain controller for longer than the tombstone lifetime expiration: This indicates a permanent lingering object that requires manual intervention. Refer to the “How to remove lingering objects” section for remediation steps.
• If deleted objects were prematurely purged from the deleted objects container due to a system time jump on the destination domain controller: Investigate and correct any time synchronization issues first. Review the “Check for Time Jumps” section.
• If the object cited in the 1988 event exists in the deleted objects container of the source domain controller, and its delete date is at the cusp of tombstone lifetime expiration: This suggests a transient lingering object. It may have been garbage collected by some destination domain controllers and will likely be garbage collected by the source domain controller during its next cleanup cycle. You can either wait for the next garbage collection execution (which occurs roughly every 12 hours) or manually trigger garbage collection on the source domain controller. Refer to “How to manually start garbage collection.” This condition is often seen after the introduction of the first domain controller in an existing forest or after any change in the partial attribute set.
• If the repadmin /showobjmeta output for the object indicates a LastKnownParent value of 1 (object was deleted) and an IsDeleted value of 2 (or another even number indicating reanimation), and the date stamps for these values are near the TSL number of days apart: This signifies that the object was deleted and then undeleted/authoritatively restored while it was still live on the source domain controller but had already been reclaimed by garbage collection on destination domain controllers logging error 8606 / Event 1988. Refer to the “Reanimations at the Cusp of TSL Expiration” section for specific guidance.

Methods for Removing Lingering Objects¶

While multiple approaches exist for addressing lingering objects, three primary tools are commonly employed by administrators: Lingering Object Liquidator (LoL), Repadmin, and Repldiag. Each offers distinct capabilities for detecting and removing these problematic objects.

Lingering Object Liquidator (LoL)¶

The Lingering Object Liquidator (LoL) is designed to simplify and automate the cleanup process for lingering objects across an Active Directory Forest. This tool provides a user-friendly graphical interface, making it an accessible option for many administrators. LoL can efficiently scan the current Active Directory Forest, detect existing lingering objects, and facilitate their removal. It aims to streamline a process that can otherwise be complex and time-consuming.

Repadmin Commands¶

Repadmin.exe is a powerful command-line tool for Active Directory replication management, and it includes commands specifically for dealing with lingering objects. Two key commands are particularly useful for this purpose.

The repadmin /removelingeringobjects command is used to remove lingering objects from both writable and read-only directory partitions on source domain controllers. Its syntax is as follows:

repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/ADVISORY_MODE]

Here, <Dest_DSA_LIST> refers to the domain controller(s) containing the lingering objects (e.g., the source DC cited in Event 1988). <Source DSA GUID> is the GUID of a domain controller that holds a writable copy of the directory partition from which lingering objects are to be removed, and to which the Dest_DSA_LIST DC has network connectivity. The DC being cleaned up must directly connect on port 389 to the DC specified as the “Good Source.” <NC> is the Distinguished Name path of the directory partition suspected of containing lingering objects, as indicated in a 1988 event. The optional /ADVISORY_MODE allows you to preview which objects would be removed without actually performing the deletion, which is highly recommended for initial runs.

The repadmin /rehost command is specifically designed for removing lingering objects from domain controllers that host a read-only copy of a domain directory partition, such as Global Catalog servers. Its syntax is:

repadmin /rehost DSA <Naming Context> <Good Source DSA Address>

In this command, DSA is the name of a domain controller hosting a read-only domain directory partition for a non-local domain (e.g., a GC in root.contoso.com can rehost its read-only copy of child.contoso.com). <Naming Context> is the DN path of the read-only domain directory partition residing in the global catalog. <Good Source DSA Address> is the name of a domain controller that holds a writable copy of the <Naming Context> and is network-available to the DSA computer. If the lingering object reported in the 1988 event is not removed by repadmin, it may indicate a more complex scenario, such as an object created in a USN gap or the originating domain controller not being present in the source domain controller’s up-to-dateness vector. These cases might require deeper investigation into replication metadata.

Repldiag¶

Repldiag is another advanced diagnostic tool for Active Directory replication. It is often used in more complex scenarios where standard repadmin commands may not fully resolve the issue. While not a direct object removal tool like repadmin /removelingeringobjects, repldiag can play a crucial role in identifying the root causes of replication errors, including those that lead to lingering objects. It is particularly useful for comprehensive analysis and can assist in preparing the environment for a successful cleanup using other methods.

For those seeking guided, hands-on practice in troubleshooting replication errors like 8606, resources such as on-demand labs are available. These labs often incorporate tools like repadmin and repldiag.exe to walk participants through the entire troubleshooting, analysis, and implementation process for common Active Directory replication issues.

Proactive Replication Health Monitoring¶

Preventing error 8606 and other replication issues is far more efficient than reacting to them. Daily monitoring of Active Directory replication health is a crucial proactive measure to ensure the stability and consistency of your directory service.

If error 8606 / Event 1988 was triggered because a domain controller failed to replicate Active Directory changes for longer than the tombstone lifetime, it underscores the need for continuous vigilance. Replication health can be monitored using dedicated monitoring applications or through more straightforward methods, such as regularly analyzing the output of the repadmin /showrepl * /csv command in a spreadsheet application like Microsoft Excel. This command provides a detailed, comma-separated value report of replication status across all domain controllers, which can then be easily filtered and sorted to identify issues.

Domain controllers that have not inbound-replicated successfully for 50 percent of the tombstone lifetime should be placed on a watch list. These servers require priority administrative attention to restore their replication functionality. Furthermore, any domain controllers that remain unable to replicate successfully within 90 percent of the TSL period should be considered for force demotion. Continuing to operate with severely outdated replication partners poses a significant risk to the directory’s integrity.

It’s important to remember that replication failures appearing on a destination domain controller can stem from issues with the destination domain controller itself, the source domain controller, or problems within the underlying network and DNS infrastructure. A holistic monitoring approach helps pinpoint the exact area requiring remediation.

Investigating Time Jumps¶

Inaccurate system time can severely disrupt Active Directory replication, leading to errors like 8606, particularly by prematurely garbage collecting objects. Investigating for “time jumps” is a critical step in diagnosing the root cause of certain lingering object scenarios.

To determine if a time jump has occurred, carefully examine date stamps in various event and diagnostic logs on destination domain controllers that are logging error 8606 or NTDS Replication 1988 events. This includes Event Viewer logs, repadmin /showreps output, Netlogon logs, and DCDIAG reports. Look for anomalous date stamps such as:
* Dates that predate the operating system’s release (e.g., a 2003 timestamp on a 2008 OS).
* Dates that predate the installation of the operating system within your forest.
* Date stamps set far into the future.
* Significant gaps in events logged within a given date range.

Instances have been observed where production domain controllers’ system clocks incorrectly jumped by hours, days, weeks, years, or even decades into the past or future. If inaccurate system time is identified, correct it immediately. More importantly, investigate why the time jump occurred to prevent recurrence. Consider the following questions:
* Was the forest root PDC configured with a reliable external time source?
* Are reference online time sources available on the network and correctly resolvable via DNS?
* Is the Microsoft or any third-party time service running and functioning without errors?
* Are domain controllers configured to use the NT5DS hierarchy for time synchronization, ensuring they source time appropriately?
* Was time rollback protection implemented to prevent DCs from accepting invalid time samples?
* Do the system clocks on domain controllers, including those running on virtual host computers, have good batteries and accurate time in their BIOS settings?
* Are virtual host and guest computers configured to source time according to the hosting manufacturer’s recommendations (e.g., disabling time synchronization from the host on guest DCs if the host itself is not a reliable time source)?

After correcting any time synchronization issues, re-check for lingering objects using repadmin /removelingeringobjects /advisorymode. Remove any detected objects as required. In certain situations, it may also be necessary to temporarily relax “Allow replication with Divergent and corrupt partner” settings on the destination domain controller to allow replication to proceed after the time issue is resolved, though this should be done with caution and reverted once consistency is re-established.

Manually Initiating Garbage Collection¶

In scenarios where lingering objects are transient and expected to be cleared by the next garbage collection cycle, you may choose to manually trigger garbage collection on a specific domain controller to expedite the cleanup. This can be useful for quickly addressing objects that are at the cusp of tombstone lifetime expiration.

There are a couple of ways to manually initiate garbage collection:

Method 1: Using Repadmin
Execute the following command on the target domain controller:

repadmin /setattr "" "" doGarbageCollection add 1

This command modifies an attribute in the directory service, signaling it to immediately perform a garbage collection cycle.

Method 2: Using LDIFDE
You can also use the LDIFDE utility to perform this action. First, create a text file named dogarbage.ldif with the following content:

dn:
changetype: modify
replace: DoGarbageCollection
dogarbagecollection: 1
-

Important Note: The final hyphen “-” character in the dogarbage.ldif file is a required element and must be included exactly as shown.

Once the file is created, run the following command from the command prompt on the domain controller where you want to trigger garbage collection:

ldifde /s <server> /i /f dogarbage.ldif

Replace <server> with the hostname or FQDN of the domain controller. This command imports the LDIF file, which then triggers the garbage collection process on the specified server. Manually triggering garbage collection can help clear transient lingering objects more quickly than waiting for the scheduled cycle, potentially resolving 8606 errors sooner.

Reanimations at the Cusp of TSL Expiration¶

A specific and complex scenario leading to error 8606 involves objects that are reanimated (undeleted or restored) just as their tombstone lifetime is expiring or has already expired on other domain controllers. This can create a conflict where some DCs believe the object is still alive, while others have already garbage collected it.

For this condition to be present, repadmin /showobject "<GUID=object guid for object in 1988 event>" executed on the destination domain controller should report that the object is “not found.” However, on the source domain controller, the object should still be reported as “live” (either a deleted or non-deleted object, but present).

A review of key fields from repadmin /showobjmeta on the source domain controller should confirm the following:
* The LastKnownParent attribute has a value of 1, and its date stamp is at the cusp of the TSL days in the past. This date stamp indicates the approximate time the object was originally deleted.
* The IsDeleted attribute has a version number of 2 (or another even-numbered value). Version 1 would represent the original deletion, while version 2 signifies the restore or reanimation. The date stamp for IsDeleted=2 should be approximately TSL number of days later than the last change date for LastKnownParent. This temporal relationship is crucial in identifying this specific scenario.

Once these conditions are confirmed, a critical decision must be made: should the object in question remain a live object, or should it be permanently deleted? If LastKnownParent shows a value of 1, it implies that something or someone explicitly deleted the object. If this deletion was intentional and not an accident, the most likely course of action is to delete the object from any source domain controllers that still hold a live copy.

If the object should exist on all replicas (meaning the reanimation was intentional and correct), the options to resolve the 8606 errors include:
* Enable loose replication consistency on the strict-mode destination domain controllers that do not possess the object. This will allow the reanimated object to be replicated to them, but it is generally a temporary measure as loose replication can hide underlying inconsistencies.
* Force-demote the domain controllers that have already garbage collected the object. This removes the inconsistent copy of Active Directory from the network.
* Delete the object and then re-create it. This ensures a clean creation of the object across all domain controllers, with a new originating timestamp, resolving any lingering object conflicts.

Deeper Insight into Lingering Object Causes¶

Understanding the specific scenarios that can lead to lingering objects and subsequent 8606 errors provides valuable context for troubleshooting. These examples illustrate how replication failures, time discrepancies, and administrative actions can collectively contribute to these issues.

Cause 1: Long-Term DC Offline and Updates¶

Consider a scenario where the CONTOSO.COM domain has two domain controllers, DC1 and DC2, with a Tombstone Lifetime (TSL) of 60 days. Both DCs are configured for strict replication consistency. If DC2 experiences a hardware failure and remains offline for 90 days, during this period, DC1 continues to originate deletions for stale security groups daily. When DC2 is brought back online after 90 days, it might originate a change (e.g., a DACL or SACL modification) on user accounts before it has the opportunity to inbound-replicate the 90 days’ worth of originating deletes from DC1. As DC1 attempts to replicate these originating deletes for security groups that DC2 still considers “live” (because it hasn’t received the delete notification), DC1 will log 8606 errors. This occurs for the security groups that were purged on DC1 during the initial 30 days that DC2 was offline (i.e., between 60 and 90 days offline, after their TSL expired on DC1).

Cause 2: In-Place Upgrade or Partial Attribute Set Update¶

In another scenario for CONTOSO.COM with DC1 and DC2 and a TSL of 60 days, both DCs replicate every 24 hours. DC1 originates daily deletions. If DC1 undergoes an in-place upgrade, this process often stamps new attributes on all objects within the configuration and writable domain partitions. This includes objects currently residing in the deleted objects container, some of which might have been deleted nearly 60 days ago and are at the cusp of tombstone expiration. Before the replication schedule opens with DC2, DC2 reclaims some of these objects by garbage collection that were deleted TSL days ago. When DC1 then attempts to replicate the attribute updates for these already-garbage-collected objects, DC2 will log error 8606. This error persists until DC1 itself reclaims these blocking objects through its garbage collection process. Any update to the partial attribute set, such as adding the first Windows Server 2008 R2 domain controller to an existing forest, can cause similar temporary lingering objects that will self-resolve once source domain controllers garbage-collect deleted objects near TSL expiration.

Cause 3: Time Jump on a Destination Domain Controller¶

Imagine CONTOSO.COM with DC1 and DC2 replicating every 24 hours, TSL of 60 days, and strict replication. DC1 consistently originates daily deletions. If the reference time source used by DC1 (but not DC2) unexpectedly jumps forward to, say, the calendar year 2039, this will cause DC1 to adopt a system time in 2039. Consequently, DC1 will prematurely delete objects from its deleted objects container that were only recently deleted. Meanwhile, DC2, operating on correct time, continues to originate changes to attributes on users, computers, and groups that are live on DC2. However, these objects are now deleted and prematurely garbage collected on DC1. When DC1 next inbound-replicates these changes for the prematurely deleted objects from DC2, it will log error 8606.

Cause 4: Object Reanimation at the Cusp of TSL Expiration¶

In CONTOSO.COM with DC1 and DC2, TSL of 60 days, and strict replication, an Organizational Unit (OU) containing users, computers, and groups is accidentally deleted. A system state backup, made at the cusp of the TSL period in the past, is authoritatively restored on DC2. This backup contains objects that are live on DC2 but have already been deleted and reclaimed by garbage collection on DC1. When DC2 attempts to replicate the restored (reanimated) objects to DC1, DC1 will encounter these objects as unexpected creations for already-deleted entries, leading to error 8606.

Cause 5: A USN Bubble Triggers Error 8606¶

A USN (Update Sequence Number) bubble refers to a situation where changes are recorded with USNs that appear to be in the past relative to a replication partner’s high water mark. If an object is created within a USN bubble, it might not outbound-replicate immediately because the destination domain controller “thinks” it already possesses that object based on its current replication state. Once the USN bubble resolves and replication resumes, a subsequent change is made to that object on the source domain controller. This change, when finally replicated, is then presented to the destination domain controller as a lingering object, triggering error 8606 because the destination still believes it has the object, but the source is now sending an update for an object that’s effectively “stuck” in a prior state.

Understanding Active Directory Deletion Replication¶

Active Directory’s multi-master replication model is a sophisticated system where any domain controller holding a writable partition can originate a create, change, or delete operation for an object or attribute. The integrity of this system relies heavily on the consistent replication of these changes across the entire forest.

Crucially, knowledge of object and attribute deletions is persisted by the originating domain controller and subsequently by any domain controller that inbound-replicates this originating delete. This knowledge is maintained for a period equivalent to the Tombstone Lifetime (TSL) number of days. This mechanism ensures that deleted objects are eventually removed from all replicas.

For Active Directory to maintain its consistency, it requires end-to-end replication. This means that all originating deletes for all directory partitions must transitively replicate to all partition holders within the TSL period. A failure to inbound-replicate a directory partition in a rolling TSL number of days inevitably leads to the creation of lingering objects. A lingering object is, by definition, an object that was intentionally deleted by at least one domain controller but incorrectly persists on destination domain controllers that failed to inbound-replicate the transient knowledge of all unique deletions. These objects represent inconsistencies that can manifest as error 8606, disrupting replication and potentially impacting directory service operations.

Final Thoughts¶

Active Directory replication error 8606, characterized by “Insufficient attributes were given to create an object,” is a clear indicator of lingering objects within your Windows Server environment. Addressing this error is paramount for maintaining the health, consistency, and reliability of your Active Directory. Through systematic diagnosis, careful metadata analysis, and the strategic application of tools like Repadmin, Lingering Object Liquidator (LoL), and Repldiag, administrators can effectively identify and remove these problematic objects.

Beyond immediate resolution, proactive monitoring of replication health, meticulous investigation of potential time synchronization issues, and a deep understanding of object lifecycle and deletion replication are essential. By adopting these comprehensive practices, you can prevent the recurrence of error 8606 and ensure the robust operation of your Active Directory infrastructure.

Do you have experience with error 8606 or specific strategies that have worked for you? Share your insights and questions in the comments below!