Lingering objects

By | July 27, 2009

Lingering objects

When an object is deleted, Active Directory replicates the deletion as a tombstone object, which consists of a small subset of the attributes of the deleted object. By inbound-replicating this object, other domain controllers in the domain and forest become aware of the deletion. The tombstone is retained in Active Directory for a specified period called the tombstone lifetime. At the end of the tombstone lifetime, the tombstone is deleted from the directory permanently.
After the tombstone is removed permanently, the object deletion can no longer be replicated. Therefore, the tombstone lifetime defines how long domain controllers in the forest retain knowledge of a deleted object and thus the time during which a unique deletion must be received by all direct and transitive replication partners of the originating domain controller.

The default value of the tombstone lifetime depends on the version of the operating system that is running on the first domain controller that is installed in a forest, as follows:
Windows 2000 Server or Windows Server 2003: The default value is 60 days.
Windows Server 2003 with Service Pack 1 (SP1): The default value is 180 days

How Lingering Objects Occur

When conditions beyond your control cause a domain controller to be disconnected for a period that is longer than the tombstone lifetime, one or more objects that are deleted from Active Directory on all other domain controllers might remain on the disconnected domain controller. Such objects are called lingering objects. Because the domain controller is offline during the entire time that the tombstone is alive, the domain controller never receives replication of the tombstone.
When it is reconnected to the replication topology, this domain controller acts as a source replication partner that has an object that its destination partner does not have.
Replication problems occur when the object on the source domain controller is updated. In this case, when the destination attempts to inbound-replicate the update, the destination domain
controller responds in one of two ways:

If the destination domain controller has strict replication consistency enabled, it recognizes that it cannot update the object and locally halts inbound replication of the directory partition from that source domain controller.

If the destination domain controller has strict replication consistency enabled, it recognizes that it cannot update the object and locally halts inbound replication of the directory partition from that source domain controller.

Lingering objects can reside in writable or read-only partitions that are potentially replicated between domain controllers in the same or different domains in the same forest.

Causes of Long Disconnections

Indications That a Domain Controller Has Lingering Objects

• A domain controller is left in a storage room and forgotten, or shipment of a prestaged domain controller to its remote location takes longer than a tombstone lifetime.

• Replication fails and monitoring is not in place. Failures can occur as follows:

• A domain controller is started and connected to the corporate intranet but experiences inbound replication failure as a result of an underlying network connectivity failure, name resolution failure, or authentication failure that prevents replication from occurring.

• A bridgehead server is overloaded, and replication becomes backlogged. Excessively high replication load on a global catalog server, in combination with a short intersite replication interval, can result in updates not being replicated.

• Global catalog servers replicate read-only replicas of all domain directory partitions in the forest. The replication of read-only replicas has a lower priority than the replication of writable replicas. In addition, global catalog servers are often bridgehead servers, which adds to the replication load. If the replication load on global catalog servers acting as bridgehead servers is too high as a result of an extremely short replication interval, excessive numbers of concurrent outbound replication partners, or a combination of both, the replication queue can become backlogged. If the condition persists, read-only replicas can remain in the queue indefinitely. These conditions can result in lingering objects on a global catalog server.

• Wide area network (WAN) connections are unavailable for long periods. For example, a domain controller onboard a cruise ship might be unable to replicate because the ship is at sea for longer than the tombstone lifetime.

• The reported event is a false positive because an administrator shortened the tombstone lifetime to force tombstone deletion (garbage collection).

• The reported event is a false positive because the system clock on the source or destination domain controller is improperly rolled forward or back in time. Clock skews are most common following a system reboot and can have the following causes:

• System clock battery or motherboard problems.

• The time source for a computer is improperly configured, including a time source server configured with Windows Time service (W32time), third-party time servers, and network routers.

• The system clock is advanced or rolled back by an administrator attempting to extend the useful life of a system state backup or accelerate the garbage collection of deleted objects. Make sure that the system clock reflects the actual time and that event logs do not contain events from the future or invalid past.

Indications That a Domain Controller Has Lingering Objects
An outdated domain controller can store lingering objects with no noticeable effect as long as an administrator, application, or service does not update the lingering object or attempt to create an object with the same name in the domain or with the same user principal name (UPN) in the forest. However, the existence of lingering objects can cause problems, especially if the object is a security principal.
Symptoms Associated with Lingering Objects
The following symptoms indicate that a domain controller has lingering objects:

• A deleted user or group account remains in the global address list (GAL) on Exchange servers. Therefore, although the account name appears in the GAL, attempts to send e-mail messages result in errors.
• Multiple copies of an object appear in the object picker or GAL for an object that should be unique in the forest. Duplicate objects sometimes appear with altered names, causing confusion on directory searches. For example, if the relative distinguished name of two objects cannot be resolved, conflict resolution appends “*CNF:GUID” to the name, where * represents a reserved character, CNF is a constant that indicates a conflict resolution, and GUID represents the objectGUID attribute value.
• E-mail messages are not delivered to a user whose Active Directory account appears to be current. After an outdated domain controller or global catalog server becomes reconnected, both instances of the user object appear in the global catalog. Because both objects have the same e-mail address, e-mail messages cannot be delivered.
• A universal group that no longer exists continues to appear in a user’s access token. Although the group no longer exists, if a user account still has the group in its security token, the user might have access to a resource that you intended to be unavailable to that user.
• A new object or Exchange mailbox cannot be created, but you do not see the object in Active Directory. An error message reports that the object already exists.
• Searches that use attributes of an existing object incorrectly find multiple copies of an object of the same name. One object has been deleted from the domain, but it remains in an isolated global catalog server.

If an attempt is made to update a lingering object that resides in a writable directory partition, events are logged on the destination domain controller. However, if the only version of a lingering object exists in a read-only directory partition on a global catalog server, the object cannot be updated and this type of event will never be triggered.

Events that indicate that lingering objects are present in the forest

If a destination domain controller logs event ID 1388 or event ID 1988, a lingering object has been detected and one of two conditions exists on the destination domain controller:

• Event ID 1388: Inbound replication of the lingering object has occurred on the destination domain controller.

• Event ID 1988: Inbound replication of the directory partition of the lingering object has been blocked on the destination domain controller.

Event ID 1388

This event indicates that a destination domain controller that does not have strict replication consistency enabled has received a request to update an object that does not reside in the local copy of the Active Directory database. In response, the destination domain controller has requested the full object from the source replication partner. In this way, a lingering object has been replicated (“reanimated”) to the destination domain controller.

Event ID 1988
This event indicates that a destination domain controller that has strict replication consistency enabled has received a request to update an object that does not exist in its local copy of the Active Directory database. In response, the destination domain controller has blocked replication of the directory partition containing that object from that source domain controller. The event text identifies the source domain controller and the outdated (lingering) object. An example version of the event text is as follows:

Event ID 2042

If a domain controller has not replicated with its partner for longer than a tombstone lifetime, it is possible that a lingering object problem exists on one or both domain controllers. When this condition occurs, inbound replication with the source partner is stopped on the destination domain controller and event ID 2042 is logged in the Directory Services event log. The event identifies the source domain controller and the appropriate steps to take to either remove the outdated domain controller or remove lingering objects and restore replication from the source domain controller.

for more info http://support.microsoft.com/kb/910205

Leave a Reply

Your email address will not be published. Required fields are marked *