Fixing Replication Lingering Object Problems

Below article is taking from Microsoft TechNet explaining Lingering Object and related problems. The article ends with naming a tool which can be used to clean up the AD database (Repadmin.exe)In active directory a object's DN must be unique; two objects can't have the same DN (distinguish name). Let's take a look at real life scenario where Domain admin A creates user called "oz",, before the replication takes place lets think a scenario same user name has been added to .DIT database on another DC (Domain Controller). When Replication happens collusion occurs. Who will win is a good question. The object which was created first will be added "CNF" after its name. CNF is conflict so second created object will live. Now which one is good candidate for deletion, is up to you. Either delete the second one or rename the CFN to the original name of get rid of the first one.

I have also added another TechNet notes regarding to object name conflicts

• Active Directory supports multimaster replication of directory objects between all domain controllers in the domain. When replication of objects results in name conflicts (two objects have the same name within the same container), the system automatically renames one of these accounts to a unique name. For example, object ABC is renamed to be *CNF:guid, where "*" represents a reserved character, "CNF" is a constant that indicates a conflict resolution, and "guid" represents a printable representation of the objectGuid attribute value.
  
• This will cause an event ID 12292 to be logged in the system event log on the domain controller. You must clean up Active Directory to resolve this error.
  

I have recently find out we have 277.000 DLT object in our active directory. More than 70% of the AD seems to be polluted in this case. Of course the cause of this mess is not to have any maintenance plan at all when AD was stood up. The AD Engineers who designed where I work seem to forget about the health of the .DIT database and left KCC and replication problems to their own fate. The result is the numbers I have given earlier. Of course I don't have to mention about this number is taken from one child domain only, there are several child domains exist and AD pollution is all over the network.

• 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.
  
• See the
  Microsoft article about Tombstone Lifetime and Replication of Deletions
  

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.
  

Causes of Long Disconnections

• Unexpectedly long disconnections can be caused by the following conditions
  
• 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
  
• 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.
  
• 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

• 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
  

Luckily Microsoft comes into rescue

Use Repadmin.exe option /removelingeringobjects, which safely remove instances of lingering objects from both writable directory partitions and read-only directory partitions

Repadmin.exe provides the following

• Compares the directory database objects on a reference domain controller with the objects on the target domain controller, which contains (or is suspected to contain) lingering objects.
  
• If you use the /advisory mode parameter, events are logged in the Directory Service event log for the objects that are found.
  
• If you do not use the /advisory mode parameter, the found objects are deleted without replicating the deletions; that is, the deletions occur only on the target domain controller.
  

Best

Oz ozugurlu