Export (0) Print
Expand All

Troubleshooting Dfs Problems

Most Dfs problems can be divided into the following categories:

  • Access to the Dfs namespace

  • Finding shared folders

  • Access to Dfs links and shared folders

  • Security-related issues

  • Replication latency

note-icon Note

Dfs and FRS are closely intertwined. Problems with fault-tolerant Dfs functions are often FRS replication problems. For more information about solving FRS problems, see "File Replication Service" in this book.

Gaining Access to the Dfs Namespace

If a Dfs namespace is not accessible, check the following:

  • Make sure that the Dfs service is running on all domain controllers.

  • Make sure that the Dfs service is running on all servers that are hosting the Dfs namespace. (A server that "hosts" the Dfs namespace contains the Dfs root or a replica of it.)

  • Make sure that the Net Logon Service is running on all servers that are hosting the Dfs namespace.

  • Run the Active Directory administrative console to see if Active Directory is readable. Verify that an entry shows up in the Dfs-Configuration container under Users and Computers that corresponds to the Dfs namespace. The data is stored as a "blob," so you cannot obtain any further details by using the administrative console.

  • Run the Dfs administrative console, specify Connect to a Dfs Root , and verify the configuration associated with a selected root. If you can connect to a Dfs root with the administrative tool, this also confirms that you are able to retrieve data from Active Directory.

Tracking Shared Folders

It is recommended that one of the first things that you determine when tracking an access-related issue with Dfs is the name of the underlying shared folder that the client has been referred to. In Windows 2000, there is a shell extension to Windows Explorer for precisely this purpose. When you right-click a folder that is in the Dfs namespace, there is a Dfs tab available in the Properties window. From the Dfs tab, you can see which shared folder you are referencing for the Dfs link. In addition, you can see the list of replicas that refer to the Dfs link, so you can disconnect from one replica and select another. Finally, you can also refresh the referral cache for the specified Dfs link. This makes the client obtain a new referral for the link from the Dfs server.

The Dfs tab is available only to Windows 2000–based clients. There are no client-side or server-side tools available for clients using earlier versions of Windows that readily provide the name of the shared folder to which they have been referred. To mount the drive containing the Dfs root on a local computer, enter the following on the command line:

net use * \\ domain_name \ root_name

Keep in mind that at the protocol level, on the wire, the client still connects to and communicates with the server hosting the shared folder as if the client had gained access to the folder directly. A network sniffing tool such as Network Monitor can still be used to capture communications between the client and other Dfs components. For more information, see "Monitoring Dfs" earlier in this chapter.

Gaining Access to Dfs Links and Shared Folders

If a client cannot gain access to a shared folder specified by a Dfs link, check the following:

  • Use the Dfs administrative tool to identify the underlying shared folder.

  • Check status to confirm that the Dfs link and the shared folder (or replica set) to which it points are valid. For more information, see "Checking Shared Folder Status" earlier in this chapter.

  • The user should go to the Windows Explorer Dfs property page to determine the actual shared folder that he or she is attempting to connect to. For more information, see "Tracking Shared Folders" earlier in this chapter.

  • The user should attempt to connect to the shared folder directly by way of the physical namespace. By using a command such as ping , net view , or net use , you can establish connectivity with the target computer and shared folder.

  • If the Dfs link has a replica set configured, then be aware of the latency involved in content replication. Files and folders that have been modified on one replica might not yet have replicated to other replicas.

Security-Related Issues

If a client is experiencing security-related problems with a Dfs link, check the following:

  • First, identify the actual shared folder to which the client is gaining access. See "Tracking Shared Folders" earlier in this chapter.

  • Be aware that users might not see objects at intermediate points in the Dfs namespace if they do not have access to them.

  • Because ACLs are applied to the actual shared folders, verify client connectivity to the physical shared folder and troubleshoot the security access problem as if the user were gaining access to the folder through the physical namespace (that is, confirm User account, check ACLs on the shared folder and files, check group membership, and so forth).

  • If the Dfs link has a replica set configured, be aware of the latency involved in content replication. ACLs might have been modified on one replica but not yet been replicated to other replicas.

Replication Latency

Be aware of the latency issues already discussed regarding replication of Dfs namespace knowledge. Because the topology knowledge is stored in the domain's Active Directory, there is some latency before any modification to the Dfs namespace is replicated to all domain controllers.

From an administrator's perspective, remember that the Dfs administrative console connects directly to a domain controller. Therefore, the information that you see on one Dfs administrative console might not be identical with the information about another Dfs administrative console (which might be obtaining its information from a different domain controller).

From a client's perspective, you have the additional possibility that the client itself might have cached the information before it was modified. So, even though the information about the modification might have replicated to all the domain controllers, and even if the Dfs servers have obtained updates about the modification, the client might still be using an older cached copy. The ability to manually flush the cache before the referral time-out has expired, which is done from the Dfs tab in the Properties window in Windows Explorer, can be useful in this situation.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft