Distributed File System |
Most Dfs problems can be divided into the following categories:
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.
If a Dfs namespace is not accessible, check the following:
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.
If a client cannot gain access to a shared folder specified by a Dfs link, check the following:
If a client is experiencing security-related problems with a Dfs link, check the following:
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.