I’ve seen three recent posts in our microsoft.public.windows.server.dfs_frs newsgroup from DFS Namespaces customers who are trying to determine why clients are being referred to unexpected targets. Here is one example: “We seem to having problems with our site referrals for DFS. Our root DFS “Global” has 6 links underneath for various parts of the business, some refer ok to their local site, some do not. We have ran Dfsutil/insite command on the root, but it has made little difference, with most important link still referring off site to standard 2003 DC.”
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.