Microsoft released the LOL GUI tool for removing Active Directory lingering objects. Historically, removing lingering objects from AD had been a painful process.
Note that LOL is not a straightforward download. Follow the following steps to download:
- Log on to the Microsoft Connect site (using the Sign in) link with a Microsoft account:: http://connect.microsoft.com
Note: You may have to create a profile on the site if you have never participated in Connect.
- Open the Non-feedback Product Directory:
- Join the following program:
Product Azure Active Directory Connection Join link
- Click the Downloads link to see a list of downloads or this link to go directly to the Lingering Objects Liquidator download. (Note: the direct link may become invalid as the tool gets updated.)
- Download all associated files
- Double click on the downloaded executable to open the tool.
Why you should care about lingering object removal
Widely known as the gift that keeps on giving, it is important to remove lingering objects for the following reasons
- Lingering objects can result in a long term divergence for objects and attributes residing on different DCs in your Active Directory forest
- The presence of lingering objects prevents the replication of newer creates, deletes and modifications to destination DCs configured to use strict replication consistency. These un-replicated changes may apply to objects or attributes on users, computers, groups, group membership or ACLS.
- Objects intentionally deleted by admins or application continue to exist as live objects on DCs that have yet to inbound replicate knowledge of the deletes.
Lingering Object Liquidator automates the discovery and removal of lingering objects by using the DRSReplicaVerifyObjects method used by repadmin /removelingeringobjects and repldiag combined with the removeLingeringObject rootDSE primitive used by LDP.EXE. Tool features include:
- Combines both discovery and removal of lingering objects in one interface
- Is available via the Microsoft Connect site
- The version of the tool at the Microsoft Connect site is an early beta build and does not have the fit and finish of a finished product
- Feature improvements beyond what you see in this version are under consideration
From Microsoft KB 910205:
Lingering objects can occur if a domain controller does not replicate for an interval of time that is longer than the tombstone lifetime (TSL). The domain controller then reconnects to the replication topology. Objects that are deleted from the Active Directory directory service when the domain controller is offline can remain on the domain controller as lingering objects. This article contains detailed information about the events that indicate the presence of lingering objects, the causes of lingering objects, and the methods that you can use to remove lingering objects.
Tombstone lifetime and replication of deletions
When an object is deleted, Active Directory replicates the deletion as a tombstone object. A tombstone object consists of a small subset of the attributes of the deleted object. By inbound-replicating this object, other domain controllers in the domain and in the forest receive information about the deletion. The tombstone is retained in Active Directory for a specified period. This specified period is called the TSL. At the end of the TSL, the tombstone object is permanently deleted.
The default value of the TSL depends on the version of the operating system that is running on the first domain controller that is installed in a forest. The following table indicates the default TSL values for different Windows operating systems.
First domain controller in forest root Default tombstone lifetime Windows 2000 60 days Windows Server 2003 60 days Windows Server 2003 with Service Pack 1 180 days
Note The existing TSL value does not change when a domain controller is upgraded to Windows Server 2003 with Service Pack 1 (SP1). The existing TSL value is maintained until you manually change it.
After the tombstone is permanently deleted, the object deletion can no longer be replicated. The TSL defines how long domain controllers in the forest retain information about a deleted object. The TSL also defines the time during which all direct and transitive replication partners of the originating domain controller must receive a unique deletion.
How lingering objects occur
When a domain controller is disconnected for a period that is longer than the TSL, one or more objects that are deleted from Active Directory on all other domain controllers may remain on the disconnected domain controller. Such objects are called lingering objects. Because the domain controller is offline during the time that the tombstone is alive, the domain controller never receives replication of the tombstone.
When this domain controller is reconnected to the replication topology, it 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 partner tries 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, the controller recognizes that it cannot update the object. The controller locally stops inbound replication of the directory partition from the source domain controller.
- If the destination domain controller has Strict Replication Consistency disabled, the controller requests the full replica of the updated object. In this case, the object is reintroduced into the directory.
Causes of long disconnections
The following conditions can cause long disconnections:
- A domain controller is disconnected from the network and is put in storage.
- The shipment of a pre-staged domain controller to its remote location takes longer than a TSL.
- Wide area network (WAN) connections are unavailable for long periods. For example, a domain controller onboard a cruise ship may be unable to replicate because the ship is at sea for longer than the TSL.
- The reported event is a false positive because an administrator shortened the TSL to force the garbage collection of deleted objects.
- The reported event is a false positive because the system clock on the source or on the destination domain controller is incorrectly advanced or rolled back. Clock skews are most common following a system restart. Clock skews may occur for the following reasons:
- There is a problem with the system clock battery or with the motherboard.
- The time source for a computer is configured incorrectly. This includes a time source server that is configured by using Windows Time service (W32Time), by using a third-party time server, or by using network routers.
- An administrator advances or rolls back the system clock to extend the useful life of a system state backup or to accelerate the garbage collection of deleted objects. Make sure that the system clock reflects the actual time. Also, make sure that event logs do not contain invalid events from the future or from the past.
Removing lingering objects from the forest
Windows 2000-based forests
For more information about how to remove lingering objects in a Windows 2000-based domain, click the following article number to view the article in the Microsoft Knowledge Base:314282 Lingering objects may remain after you bring an out-of-date global catalog server back online
Windows Server 2003-based forests
For information about how to remove lingering objects from Windows Server 2003-based forests, visit the following Microsoft Web site:http://technet2.microsoft.com/WindowsServer/en/Library/77dbd146-f265-4d64-bdac-605ecbf1035f1033.mspx
For more information, click the following article number to view the article in the Microsoft Knowledge Base:892777 Windows Server 2003 Service Pack 1 Support Tools
Preventing lingering objects
The following are methods that you can use to prevent lingering objects.
Method 1: Enable the Strict Replication Consistency registry entry
You can enable the Strict Replication Consistency registry entry so that suspect objects are quarantined. Then, administrations can remove these objects before they spread throughout the forest.
If a writable lingering object is located in your environment, and an attempt is made to update the object, the value in the Strict Replication Consistency registry entry determines whether replication proceeds or is stopped. The Strict Replication Consistency registry entry is located in the following registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
The data type for this entry is REG_DWORD. If you set the value to 1, the entry is enabled. Inbound replication of the specified directory partition from the source is stopped on the destination. If you set the value to 0, the entry is disabled. The destination requests the full object from the source domain controller. The lingering object is revived in the directory as a new object.
The default value for the Strict Replication Consistency registry entry is determined by the conditions under which the domain controller was installed in the forest.
Note Raising the functional level of the domain or the forest does not change the replication consistency setting on any domain controller.
By default, the value of the Strict Replication Consistency registry entry on domain controllers that are installed in a forest is 1 (enabled) if the following conditions are true:
- The Windows Server 2003 version of Winnt32.exe is used to upgrade a Windows NT 4.0 primary domain controller (PDC) to Windows Server 2003. This computer creates the forest root domain of a new forest.
- Active Directory is installed on a server that is running Windows Server 2003. This computer creates the forest root domain of a new forest.
By default, the value of the Strict Replication Consistency registry entry on domain controllers is 0 (disabled) if the following conditions are true:
- A Windows 2000-based domain controller is upgraded to Windows Server 2003.
- Active Directory is installed on a Windows Server 2003-based member server in a Windows 2000-based forest.
If you have a domain controller that is running Windows Server 2003 with SP1, you do not have to modify the registry to set the value of the Strict Replication Consistency registry entry. Instead, you can use the Repadmin.exe tool to set this value for one domain controller in the forest or for all the domain controllers in the forest.
For more information about how to use Repadmin.exe to set Strict Replication Consistency, visit the following Microsoft Web site:
Method 2: Monitor replication by using a command-line command
To monitor replication by using the repadmin /showrepl command, follow these steps:
- Click Start, click Run, type cmd, and then click OK.
- Type repadmin /showrepl * /csv >showrepl.csv, and then press ENTER.
- In Microsoft Excel, open the Showrepl.csv file.
- Select the A + RPC column and the SMTP column.
- On the Edit menu, click Delete.
- Select the row that is immediately under the column headers.
- On the Windows menu, click Freeze Pane.
- Select the complete spreadsheet.
- On the Data menu, point to Filter, and then click Auto-Filter.
- On the heading of the Last Success column, click the down arrow, and then click Sort Ascending.
- On the heading of the src DC column, click the down arrow, and then click Custom.
- In the Custom AutoFilter dialog box, click does not contain.
- In the box to the right of does not contain, type del.
Note This step prevents deleted domain controllers from appearing in the results.
- On the heading of the Last Failure column, click the down arrow, and then click Custom.
- In the Custom AutoFilter dialog box, click does not equal.
- In the box to the right of does not equal, type 0.
- Resolve the replication failures that are displayed.