Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Link Tracking Service

Do you spend days or weeks planning data moves because of the time it takes to coordinate with users who have shortcuts and compound documents linked to files buried deep in the directory structure under a share point? Relief is at hand in the form of the

Link Tracking Service , or LTS. This feature was introduced in Windows 2000.

The LTS keeps track of the location of source files for shortcuts and OLE applications. An example of an OLE link is a compound document in Word that contains a link to an Excel spreadsheet. A file with a link to another file is called a

link client . The target file for the link is called the

link source .

Typically, if the link source file is moved, the link client will fail to find it and give an error to the user. In Windows Server 2003, the Link Tracking Service finds the link source file automatically and changes the link client pointer to reference the new location. This works even if the link source has been moved to another server in the domain.

Classic Link Source Location

In NT4 and Windows 9x, Explorer falls back on a relatively clumsy search algorithm if the link client cannot find the link source. Essentially, Explorer behaves like a gopher that has lost a carrot. It looks down, it looks up, it looks around, and then it gives up and goes for another carrot. The search pattern is shown in Procedure 15.1.

Procedure 15.1 Classic NT Link Search Pattern

1. Look down four levels.

2. Move up one level then look down four levels again from that vantage point.

3. Go to the desktop and look down four levels.

4. Go to the root of each drive and look down four levels.

5. Repeat without the four-level limit until the client application times out or the user loses patience.

Link Tracking Functional Description

The Link Tracking Service eliminates all this scrabbling around looking for the link source file. The LTS maintains an index of all link source files in an NTFS volume. If one of them is moved, the index tells LTS where it is so it can update the link client.

To do this magic, the LTS needs a way of identifying source files unambiguously in an enterprise. Once again, we meet the

Globally Unique Identifier , or GUID. When a file or folder is specified as a link source by a link client, the system assigns the link source file a GUID.

The base portion of the GUID belongs to the host volume and is incremented for each new link source record. This enables the file system and Active Directory to index $Object_ID attributes by their source volume as well as their location in the MFT.

After the GUID is generated, it is stored in the file record of the link source using an attribute called $Object_ID. This attribute is indexed in the $ObjID metadata record. This record uses a standard directory format with the index store containing the GUID assigned to the link source and its MFT record number. Using this information, the system can find the any file record given its GUID.

Let's trace an example of how the LTS uses this index attribute to track down a link source file that has been moved. Figure 15.15 shows the components involved in a link tracking transaction. We'll create a link source/client pair by creating a shortcut in Explorer. A shortcut is an LNK file that defines an OLE link client, and the target file is the link source. Procedure 15.2 uses an experiment to demonstrate LTS functionality.

Procedure 15.2 Verifying Link Tracking Operation

1. Create a file on an NTFS volume.

2. Create a shortcut to the file on your desktop. When you do this, the file system creates a GUID for the file and puts it inside an $Object_ID attribute that is inserted into the file's MFT record.

3. The link client stores the GUID of the link source along with information about the link source itself such as its location, path, and type in the $Data attribute of the file.

4. Move the link source file to another directory on the same volume. This changes the file's directory, but the MFT record number remains the same. The $ObjID index entry does not change. However, the path to the link source file stored in the LNK file data is now incorrect.

5. Double-click the shortcut file. The link is invalid, so the link client cannot find the file. It puts in a frantic call to LTS, which does a lookup for the GUID in the $ObjID index. It uses the MFT record in the index to locate the file and then uses the back-link to the file's directory to determine the new directory path.

6. LTS reports the new path to NTFS, which updates the information in the shortcut file. The link client can now open the file.

If you move the file to another NTFS volume on the same machine, the lookup takes a little longer because LTS must search the $ObjID index on each volume looking for the source file's GUID. When it finds a match, it gets the necessary location information and path and updates the link client accordingly.

Link Tracking Across a Network

The situation gets a little more complex if you move the link source to an NTFS volume on another server. In this situation, the link tracking client needs help from a central repository of link information. This repository is in Active Directory.

Every Active Directory domain controller acts as an LTS Server. If you move a link source file to another server in an Active Directory domain, the LTS client on the originating member server sends an LDAP update to Active Directory.

Active Directory stores the update in a container called the Object Move Table. This container is located in cn=FileLinks,cn=System,dc=<domain_name>,dc=<root>. You can use the AD Users and Computers console to view this container, but first enable A

DVANCED F

EATURES from the V

IEW menu.

Armed with the information it gleans from the LTS Server, an LTS client can update the MFT record of the link client with the UNC name of the new location for the link source. This assumes, of course, that a useful UNC path exists. One of the functions of LTS is to determine if a share point exists that exposes the new file location. If one does not, it uses the administrative ($) share for the volume. Users do not have access to ($) shares, but Help Desk technicians can be trained to recognize the error message and figure out where to request a new share.

Link Tracking Highlights

Here are some additional key points to remember about link tracking:

• LTS works only on Windows 2000, Windows Server 2003, and XP.




• Network Link Tracking works reliably only within a domain. You may get "episodes of success" with machines in different domains or workgroups, but not to the extent necessary to deploy it in production.




• When an LTS client finds a new path to the link source file and updates a shortcut, only the Target entry for the shortcut is updated. The Start In entry in the shortcut remains in its original value. This can cause problems for applications that use the Start In entry to find support files.




• If you copy a file rather than move it, the $Object_ID attribute and its associated GUID stay with the original file.




• When you restore a file that is the source file of a link, the $Object_ID attribute is restored, as well. If you restore to a separate location, you end up with two files of the same name with the same GUID in the same domain. This may cause problems if you end up with links to the two files and the tracking system gets them confused. Treat all restores with extreme care because of this.