Searching for the Missing Link: Distributed Link Tracking

Download the authoritative guide: Data Center Guide: Optimizing Your Data Center Strategy

Download the authoritative guide: Cloud Computing: Using the Cloud for Competitive Advantage

by Marcin Policht

Distributed Link Tracking is a service in Windows 2000, XP, and .NET servers designed to resolve problems with outdated shortcuts. Marcin Policht's latest article covers the advantages and potential pitfalls of utilizing the service.

Distributed Link Tracking is a service that was introduced in Windows 2000 and is now also available in Windows XP and .NET servers (including the most recent post beta-3 release). The service was intended to resolve problems with outdated shortcuts. These problems applied to both shell shortcuts (such as ones located in Desktop, Favorites, Start Menu, and Recent folders) as well as OLE application links (such as an Excel spreadsheet stored within a Word document).

A mechanism to search for missing targets of shell shortcuts was first implemented in Windows NT, but its logic was flawed and its capabilities limited. Microsoft decided to completely redesign it by employing two new services that form a client/server relationship and using their respective databases for storing shortcuts information. A Distributed Link Tracking Client, configured to start automatically at startup, runs on every Windows 2000, .XP, and .NET system, storing link information in a local tracking database. A Distributed Link Tracking Server is installed on Windows 2000 domain controllers and is configured to start automatically at the startup of Windows 2000 but disabled by default on the .NET platform. The Tracking Server uses one of the Active Directory containers as its storage.

Clients collect the information locally on any system that has NTFSv5-formatted volumes. The client service keeps track of link targets using their GUIDs (a Globally Unique Identifier, assigned to each object on NTFSv5 volumes). These GUIDs are also stored in the Master File Table on each volume. This way a target can be found by referencing local file system database as long as it is moved locally within the same volume. If the target is moved to another volume or another system, the Distributed Link Tracking client relays information about the change to DLT Servers on domain controllers. For each link, DLT Server creates linkTrackOMTEntry object in the Active Directory container CN=ObjectMoveTable,CN=FileLinks,CN=System,DC=domainname (where DC entry vary depending on your domain name). You can take a look at the content of the container in your Active Directory using standard administrative tools:

  •  In Active Directory Users and Computers, select the Advanced Features option from the View menu. Then drill down the AD hierarchy through System, File Links, and ObjectMoveTable folders.

  •  In the Active Directory Administration Tool (also known as LDAP utility) included in the Windows 2000 Support Tools available on the Windows 2000 installation CD, Connect and Bind to your domain, and then from the View menu select the Tree option and type the path to the target container (CN=ObjectMoveTable;CN=FileLinks;CN=System;DC=domainname - where the DC entry varies depending on your domain name).

In both cases you will most likely see a long listing of linkTrackOMTEntry objects. The VolumeTable container (located uder FileLinks) contains the listing of all NTFS volumes for the domain.

Having broken shortcuts be fixed automatically, as long as the targets reside somewhere within a domain, seems like a good idea. Unfortunately, there are significant drawbacks to this solution.

One problem surfaces in situations where shortcut targets are restored from backups to a new location (different from original). This creates duplicate GUIDs and might result in shortcuts pointing to incorrect targets. A more serious problem is caused by substantial growth of the Active Directory database. This becomes especially acute in environments where auditing and custom permissions are set on Active Directory objects (which affects the size of individual objects). This impacts negatively both the size of Active Directory database and the amount of intradomain replication.

If you experience these types of symptoms, refer to the MS Knowledge Base article Q312403 (Distributed Link Tracking on Windows-Based Domain Controllers) for instructions on changing this behavior. The article gives you a detailed description of necessary steps, but here is a short synopsis:

  •  After logging on with administrative account, stop Distributed Link Tracking Server services on all Windows 2000 and .NET server domain controllers and change their startup mode from Automatic to Manual (this can be accomplished by configuring a Group Policy object on Domain Controllers OU).

  •  Use the DltPurge.vbs script (available from Knowledge Base article Q315229) to delete existing DLT objects. When executing the script, apply -s and -d arguments to specify target domain controllers and targer domains respectively. The script tombstones DLT objects (marks them for deletion).

  • In order to see the benefit of space saving, you will need to wait out the tombstone lifetime interval (by default 60 days) and afterwards run the off-line defragmentation of the Active Directory database. This is performed by running NTDSUTIL.EXE in the Directory Services Restore mode.

Note, that while it is possible to change the default tombstone lifetime interval down to a minimum value of 2 days, Microsoft warns of setting it to anything lower than 30 days. The shorter tombstone lifetime interval might cause problems if some of the domain controllers are offline within that period or in case of replication delays. In addition, keep in mind that tombstone lifetime determines the maximum usability period of a backup of the Active Directory database.

This article was originally published on Apr 23, 2002
Page 1 of 1

Thanks for your registration, follow us on our social networks to keep up-to-date