Let's assume a domain controller has been disconnected from the AD environment and stayed offline for more than the value specified as the tombstone lifetime attribute. Then, it was reconnected to the replication topology again. The objects that were deleted from AD during the time it was 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 OS that is running. For OSes after Windows Server 2003, the default tombstone value is 180 days.
A 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, then it will halt the inbound replication from that particular domain controller.
- If the destination domain controller has strict replication consistency disabled, then it will request a full replica and will reintroduce it to the directory.
Events 1388, 1988, and 2042 suggest lingering objects in the AD infrastructure:
Event ID |
Event description |
1388 |
Another domain controller has attempted to replicate an object that is not present in the local AD DS database into this domain controller. The object may have been deleted and already garbage collected (a tombstone lifetime or more has passed since the object was deleted) on this domain controller. 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 domain controller. The source domain controller (transport-specific network address) is 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 controller's AD DS database. Not all direct or transitive replication partners are replicated in the deletion before the number of days in the tombstone lifetime have 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 domain controller contains a lingering object that does not exist in the local domain controller's 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. The source domain controller (transport-specific network address) is 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 why 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, then the source machines might return objects that 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. |