Article ID: 312403 - View products that this article applies to.
This article was previously published under Q312403
This article describes how you can use the Distributed Link Tracking services in Windows to track the creation and movement of linked files across NTFS-formatted volumes and servers.
An overview of Distributed Link TrackingYou can use the Distributed Link Tracking Server service and the Distributed Link Tracking Client service to track links to files on NTFS-formatted partitions. Distributed Link Tracking tracks links in scenarios where the link is made to a file on an NTFS volume, such as shell shortcuts and OLE links. If that file is renamed, moved to another volume on the same computer, moved to another computer, or moved in other similar scenarios, Windows uses Distributed Link Tracking to find the file. When you access a link that has moved, Distributed Link Tracking locates the link; you are unaware that the file has moved, or that Distributed Link Tracking is used to find the moved file.
Distributed Link Tracking consists of a client service and a server service. The Distributed Link Tracking Server service runs exclusively on Windows Server-based domain controllers. It stores information in Active Directory, and it provides services to help the Distributed Link Tracking Client service. The Distributed Link Tracking Client service runs on all Windows 2000-based and Microsoft Windows XP-based computers, including those in workgroup environments or those that are not in a workgroup. It provides the sole interaction with Distributed Link Tracking servers.
Distributed Link Tracking clients occasionally provide the Distributed Link Tracking Server service with information about file links, which the Distributed Link Tracking Server service stores in Active Directory. Distributed Link Tracking clients also may query the Distributed Link Tracking Server service for that information when a shell shortcut or an OLE link cannot be resolved. Distributed Link Tracking clients prompt the Distributed Link Tracking server to update links every 30 days. The Distributed Link Tracking Server service scavenges objects that have not been updated in 90 days
When a file that is referenced by a link is moved to another volume (on the same computer or on a different computer), the Distributed Link Tracking client notifies the Distributed Link Tracking server, which creates a linkTrackOMTEntry object in Active Directory. A linkTrackVolEntry object is created in Active Directory for every NTFS volume in the domain.
Note: In Windows Server 2008 and newer, the Distributed Link Tracking Server Service is not included in Windows anymore. So you can safely remove the objects from Active Directory.
Distributed Link Tracking and Active DirectoryDistributed Link Tracking objects are replicated among all domain controllers in the domain that is hosting the computer account and all global catalog servers in the forest. The Distributed Link Tracking Server service creates objects in the following distinguished name path:
CN=FileLinks,CN=System,DC=domain name container of Active DirectoryDistributed Link Tracking objects exist in the following two tables under the CN=FileLinks,CN=System folder:
If you disable Distributed Link Tracking and delete the Distributed Link Tracking objects from Active Directory, the following behavior may occur:
Distributed Link Tracking Server service defaults on Windows Server-based domain controllersIn Windows 2000, Windows XP, and Windows Server 2003, the start value for the Distributed Link Tracking Client service is set to Automatic. On Windows 2000-based servers, the Distributed Link Tracking Server service starts manually, by default. However, if you use Dcpromo.exe to promote a server to a domain, the Distributed Link Tracking Server service is configured to start automatically.
For Windows Server 2003-based servers, the Distributed Link Tracking Server service is disabled by default. When you use Dcpromo.exe to promote a server to a domain, the Distributed Link Tracking Server service is not configured to start automatically. When a Windows 2000-based domain controller is upgraded to Windows Server 2003, the Distributed Link Tracking Server service is also disabled during the upgrade. If you are an administrator and you want to use the Distributed Link Tracking Server service, you must either use Group Policy or you must manually set the service to start automatically. In addition, the Distributed Link Tracking Client service on computers that are running Windows Server 2003 or Windows XP SP1 does not try to use the Distributed Link Tracking Server service by default. If you want to configure those computers to take advantage of the Distributed Link Tracking Server service, enable the Allow Distributed Link Tracking clients to use domain resources policy setting. To do so, open the Computer Configuration/Administrative Templates/System node in Group Policy.
Microsoft recommendations for Distributed Link Tracking on Windows 2000-based serversMicrosoft recommends that you use the following settings with Distributed Link Tracking on Windows 2000-based servers:
How to delete Distributed Link Tracking objectsIt is not critical that you manually delete the Distributed Link Tracking objects after you stop the Distributed Link Tracking server service unless you have to reclaim the disk space that is being consumed by these objects as quickly as possible. Distributed Link Tracking clients prompt the Distributed Link Tracking server to update links every 30 days. The Distributed Link Tracking Server service scavenges objects that have not been updated in 90 days.
When you run the Dltpurge.vbs VBScript, all Active Directory objects that are used by the Distributed Link Tracking Server service are deleted from the domain where the script is run. You must run the script on one domain controller for each domain in a forest. To run Dltpurge.vbs:
A sample customer experienceThe worst-case scenario that is described in this section illustrates some issues to consider when you delete a large number of Distributed Link Tracking objects in a large production domain.
Trey Research, a fictitious Fortune 500 customer with over 40,000 employees worldwide deploys a single Active Directory forest that consists of an empty root domain with child domains that map major geographic regions of the world (North America, Asia, Europe, and so on). The largest domain in the forest contains about 35,000 user accounts and the same number of computer accounts.
The Ntds.dit files were placed on 18-gigabyte (GB) raid arrays. Since the initial deployment of Windows 2000, the global catalog files have grown to 17 GB.
Trey Research wants to deploy Windows Server 2003 within the next 10 days but needs at least 1.5 GB of available disk space on the database partition before they initiate the upgrade. They need this much disk space because Adprep.exe is known to add three to five inherited aces depending on the hotfixes and service packs that have been previously installed. The following conditions contribute to the large global catalog size or the lack of disk space:
After Trey Research upgraded the operating system to Windows Server 2003, more disk space was freed when the single instance store feature in Windows Server 2003 reduced database size to about 8 GB (you must perform an offline defragmentation procedure to get these results). More space was recovered after the TSL interval expired, Distributed Link Tracking objects were garbage collected, and they performed an offline defragmentation procedure.
Trey Research promoted a new replica Windows 2000-based domain controller into the domain and placed the computer account in a different organizational unit than they typically used. In two days, around 8,000 Distributed Link Tracking objects were present on the Windows 2000-based domain controller. Trey Research either stopped Distributed Link Tracking or created a policy to stop the service, and then linked the policy to organizational units that host Windows 2000-based domain controllers. Finally, Trey Research used Dltpurge.vbs to mark the remaining Distributed Link Tracking objects for deletion.
Anatomy of DLT object deletionDLT objects themselves contain very few attributes and use very little space in Active Directory. When an object is marked for deletion (tombstoned), all the unnecessary attributes are stripped away, except for those necessary to track the object until it is purged from Active Directory.
In the case of the link-tracking objects, marking the object for deletion only amounts to two attributes being removed: dscorepropagationdata and objectcategory. The deletion of the two attributes results in an initial savings of 34 bytes. However, the process of marking the link-tracking object for deletion also updates the object by adding an IS_DELETED attribute (4 bytes), and by mangling the RDN and the "common name" attributes, causing each of those attributes to grow by about 80 bytes. In addition, the "replication metadata" attribute also grows by about 50 bytes to reflect the updates performed on this object. So, by marking a link-tracking object for deletion, the object will end up growing by approximately 200 bytes. The NTDS.DIT will not exhibit a reduction in size until the deleted objects have tombstoned, been garbage collected and an offline defragmentation performed.
Note If the service is turned off as this article recommends, the autocleanup does not occur.
Article ID: 312403 - Last Review: November 18, 2011 - Revision: 10.0
Contact us for more help