Let's assume a domain controller has been disconnected from the AD environment and stayed offline for more that the value specified as the tombstone lifetime attribute. Then it was again reconnected to the replication topology. The objects that were deleted from AD during the time that particular domain controller stayed offline, will remain as lingering objects in it.
When the object was deleted using one domain controller, it was replicated to other domain controllers as a tombstone object. It contains a few attribute values but it cannot be used for active operations. It remains in the domain controllers until it reaches the time specified by the tombstone lifetime value. Then the tombstone object will be permanently deleted from the directory. The tombstone time value is a forest-wide setting and depends on the operating system running. For operating systems after Windows Server 2003, the default tombstone value is 180 days. ;
The problem occurs when the domain controller with a lingering object is involved with an outbound replication. In such a situation, one of the following can happen:
- If the destination domain controller has strict replication consistency enabled, it will halt the inbound replication from that particular domain controller
- If the destination domain controller has strict replication consistency disabled, it will request a full replica and will reintroduce it to the directory
Events 1388, 1988, and 2042 are clues for lingering objects in the Active Directory Infrastructure:
|
;Event id |
Event Description |
|
1388 |
Another domain controller (DC) has attempted to replicate into this DC an object which is not present in the local AD DS database. The object may have been deleted and already garbage-collected (a tombstone lifetime or more has passed since the object was deleted) on this DC. The attribute set included in the update request is not sufficient to create the object. The object will be re-requested with a full attribute set and re-created on this DC. Source DC (Transport-specific network address): xxxxxxxxxxxxxxxxx._msdcs.contoso.com Object: CN=xxxx,CN=xxx,DC=xxxx,DC=xxx Object GUID: xxxxxxxxxxxxx Directory partition: DC=xxxx,DC=xx Destination highest property USN: xxxxxx |
|
1988 |
AD DS replication encountered the existence of objects in the following partition that have been deleted from the local domain controllers (DCs) AD DS database. Not all direct or transitive replication partners replicated in the deletion before the tombstone lifetime number of days passed. Objects that have been deleted and garbage collected from an AD DS partition but still exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog servers in other domains in the forest are known as lingering objects. This event is being logged because the source DC contains a lingering object which does not exist on the local DCs AD DS database. This replication attempt has been blocked. The best solution to this problem is to identify and remove all lingering objects in the forest. Source DC (Transport-specific network address): xxxxxxxxxxxxxx._msdcs.contoso.com Object: CN=xxxxxx,CN=xxxxx,DC=xxxxxx,DC=xxx Object GUID: xxxxxxxxxxxx |
|
2042 |
It has been too long since this machine last replicated with the named source machine. The time between replications with this source has exceeded the tombstone lifetime. Replication has been stopped with this source. The reason that replication is not allowed to continue is that the two machine's views of deleted objects may now be different. The source machine may still have copies of objects that have been deleted (and garbage collected) on this machine. If they were allowed to replicate, the source machines' might return objects which have already been deleted. Time of last successful replication: <date> <time> Invocation ID of source: <Invocation ID> Name of source: <GUID>._msdcs.<domain> Tombstone lifetime (days): <TSL number in days> The replication operation has failed. |