Distributed File System: Namespace Client Questions

Updated: August 3, 2011

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2

This FAQ answers questions about clients of Distributed File System (DFS) Namespaces. For other questions, see DFS Namespaces: Frequently Asked Questions.

Namespace Client Questions

What can cause clients to be referred to unexpected targets?

Even when least expensive or same-site target selection is enabled, clients might still access high-cost or out-of-site targets. Also, when default target selection is enabled, a client computer might access a target server outside of its own site, even though a same-site target exists. These problems are typically caused by one of the following situations:

• The same-site target is temporarily unavailable (due to server or network issues), and the client fails over to the next target, which could be outside of the client's site.

• DFS uses the IP address-to-site mappings in Active Directory to determine the site of a target. If a target's IP address is not mapped to its current site, DFS cannot properly order that target in a referral. Incorrect site mappings can occur when subnets are not configured correctly or when a server or domain controller is moved to another site in the Active Directory Sites and Services snap-in, but the server's or domain controller's IP address still maps to the subnet of the previous site. Incorrect site mappings often occur when domain controllers are not moved to the site that corresponds to their IP address or when domain controllers are left in the default first site or the site where they originally belonged.

• If no same-site targets exist and a client unexpectedly chooses a high-cost target, it might be caused by an incorrect site cost setting.

• The client's IP address is not in a subnet that is defined in Active Directory and so DFS cannot obtain site information about the client.

• The target's IP address is not in a subnet that is defined in Active Directory and so DFS cannot obtain site information about the target.

• DNS lookup issues on the DFS root server are causing DNS name-to-IP address mappings to fail. The problem might be caused by DNS issues or when a server has multiple IP addresses but not all of those addresses are mapped to sites in Active Directory.

• The client is using a cached referral that has become outdated due to target change, site changes, or both. For example, a target was added or removed from a link or root, or a target was moved from one site to another. The client will obtain an updated referral and after the referral expires, the client's cache is cleared (using the Dfsutil.exe /pktflush command), or the client is rebooted.

• Site information has changed, but the old site information is still cached on the root server or domain controller in the target site cache, client site cache, or site cost cache.

• The DFS object is not up-to-date when the root server polls a domain controller. This can be caused by Active Directory replication latency or failure.

• The Bridge all site links option is disabled. (This option is available in the Active Directory Sites and Services snap-in) Turning off Bridge all site links can affect the ability of DFS to refer client computers to target computers that have the least expensive connection cost. An Intersite Topology Generator that is running Windows Server 2003 relies on the Bridge all site links option being enabled to generate the intersite cost matrix that DFS requires for its site-costing functionality. If you turn off this option, you must create site links between the Active Directory sites for which you want DFS to calculate accurate site costs. Any sites that are not connected by site links will have the maximum possible cost. For more information about site link bridging, see Active Directory Replication Topology Technical Reference.

• Site awareness is not working correctly because the restrictanonymous registry entry located at HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Lsa is set to 2 on Windows 2000 domain controllers. If this registry entry is set to 2, DFS root servers that are not domain controllers (and are running either Windows 2000 Server or Windows Server 2003) randomly sort the targets in a referral, regardless of the namespace type (stand-alone or domain-based), target selection method, or client operating system.

• Domain controllers do not consistently provide site-costed SYSVOL referrals because the SiteCostedReferrals registry entry was not set on all domain controllers.

• The network contains one or more Network Address Translation (NAT) products that change the source IP address of packets sent from a client computer to match the subnet of another site. These NATs are typically part of third party WAN compression appliances.

• IPv6 has been incorrectly disabled on folder targets hosted on Windows Server 2008 file servers. For more information, see article 2003961 in the Microsoft Knowledge Base.

What is DFS client “stickiness”?

Client "stickiness" refers to the behavior that occurs after a client receives a refreshed referral after the current referral expires. DFS looks to see if the current active target is also in the new referral. If it is, the target is marked active in the new referral, and the client "sticks" to this target, even if more desirable (for example, lower cost) targets appear in the new referral.

Client stickiness was designed into DFS for a purpose: to give end users a consistent experience as they read and write files on a target in the namespace. If the client computer were to connect to a different target each time the referral expired, the end user might see different files on the new target depending on whether replication has completed with respect to the previous target. In addition, any open handles to the previous target would be maintained (assuming Offline Files is not used), so clients could potentially access both targets while reading and writing different files.

In some situations, though, client stickiness is not desirable. For example, if a client fails over from a local server to a remove server (such as when the local server fails), the client will continue to access the remote server, even after the local server is restored. The client failback functionality introduced in Windows Server 2003 Service Pack 1 (SP1) was designed to give administrators more control over failback, allowing them to configure clients to fail back to a local target after the client’s referral expires. However, handles to the remote server will still be maintained if Offline Files is not used, so this feature should only be used when the need for clients to access a local server outweighs the issues described earlier.

Stickiness is also an important consideration for laptop computers that are taken from one site to another or frequently enter the sleep or hibernation power states. When a computer running Windows Server 2008 R2, Windows Server 2008, Windows® 7, or Windows Vista® comes out of sleep or hibernation, it clears its cache so that the computer will receive a fresh referral to the lowest cost (usually closest) target.

Which clients can access DFS namespaces?

For information about which operating systems can access DFS namespaces, see Review DFS Namespaces Client Requirements.

Non-Microsoft operating systems can access DFS namespaces if they implement their own DFS-SMB-CIFS clients. For more information, see the blog post Can Apple, Linux, and other non-MS operating systems connect to DFS Namespaces?. Details are provided by the operating system vendors.

Namespace Client Questions for Windows Server 2003

When a DFS client running Windows XP attempts to open an executable (.exe) file from a DFS path, the user is prompted to confirm whether to run the executable file. Why does DFS require the user to confirm whether to run the file?

Windows shell displays this message when you try to run an executable file from any path that includes a fully qualified domain name, regardless of whether the path is hosted by DFS. To prevent this message from occurring, add the domain to the list of trusted intranet zones on the client.

How has the Time to Live (TTL) value for referrals changed in DFS clients running Windows XP with Service Pack 2 (SP2) and Windows Server 2003 with Service Pack 1 (SP1)?

For DFS clients that are not running Windows XP with SP2 or Windows Server 2003 with SP1, the Time to Live (TTL) value for referrals determines the earliest time that a client will request a new referral if the existing cached referral expires before it is accessed again. Clients that use a cached referral will renew the TTL value of the referral and, thus, use the referral indefinitely until the client's referral cache is cleared or the client is restarted.

This behavior has changed for clients running Windows XP with SP2 or Windows Server 2003 with SP1. Specifically, the TTL value is not renewed each time a client accesses a target using a cached referral. Instead, the referral expires after the TTL value lapses. One benefit of this change is that DFS clients running Windows XP with SP2 or Windows Server 2003 with SP1 will more quickly discover changes to links and roots. For example, if the link targets of a link named Current are changed daily, DFS clients without Windows XP with SP2 or Windows Server 2003 with SP1 would refresh the TTL value each time they access the Current link, causing them to continue to reference stale link targets well beyond the TTL value associated with the initial referral request.

This change has several effects:

• Clients running Windows XP with SP2 or Windows Server 2003 with SP1 will request referrals more frequently than other DFS clients, which can cause a moderately increased load on the domain-based DFS root servers, stand-alone root servers, and domain controllers.

• Because DFS clients running Windows XP with SP2 or Windows Server 2003 with SP1 request new referrals more frequently, they will discover namespace updates more quickly than other DFS clients that are not running Windows XP with SP2 or Windows Server 2003 with SP1.

• In terms of DFS failover, this new behavior can cause DFS clients to fail over to a new target if the previously active target is not in the new referral, such as when the namespace is changed to remove the target that the client had accessed.