Maintaining the Dfs Configuration

By using the Dfs administrative console, you can manage multiple domain-based and stand-alone Dfs roots from the same console. After you have established a console for the Dfs namespaces for which you are responsible, save the console for future use.

Checking Shared Folder Status

As you begin to build up an extensive, distributed Dfs namespace, be aware that, over time, some of the underlying shared folders might be retired or their server or folder names altered. If the Dfs link is not modified to reflect these changes, the result is references in the system to nonexistent shared folders.

With the Dfs administrative snap-in, you can check the status of individual shared folders as well as check the links that specify them in the Dfs namespace. Essentially, you can verify that Dfs can see both the server and the shared folders and that the shared folders are valid. Your operational plan for Dfs must include the periodic running of the Check Status function on frequently used shared folders.

Table 17.6 is a list of the possible status indicators for Dfs links and shared folders.

Table   17.6 Dfs Status Flags

Taking Resources Offline

By using the Dfs administrative tool, the administrator can temporarily take a replica offline, to perform maintenance, for example. When a replica is offline, the Dfs server does not hand out the shared folder during the referral process. It is a good idea to keep the replica offline until FRS or another means of replication has reproduced the changes in all linked replicas.

You might want to be aware of what is going on behind the scenes and how a client finds out about a replica in the first place. When a replica is taken offline, the Dfs knowledge in Active Directory is updated. There is some latency before this information has replicated to all of the domain controllers. The servers that host the Dfs namespace are then notified about the updates to the Dfs knowledge. Finally, the Dfs client itself might already have this Dfs link cached locally. The client does not go back to the Dfs server for a new referral (which includes the knowledge that a server is offline) until its referral cache time-out for that Dfs link has expired.

Depending on all these factors, by the time a client has learned that a replica has been brought offline, it might already have been brought back online. Therefore, in some situations, the offline feature might be useful only when a replica is taken offline for an extended period of time.

Note that, even if a shared folder was taken offline as described previously, but the client did not find out about it, the Dfs client still handles the situation gracefully. When the client next tries to gain access to the underlying shared folder, it times out and then selects another replica from the referral list.

Removing Dfs

Windows 2000–based servers and domain controllers store Dfs configuration information in the registry and Active Directory. In some situations, it might be useful to return to a known state. To do this, you must delete Dfs configuration data in the registry and Active Directory.

Caution

Do not use a registry editor to edit the registry directly unless you have no alternate. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings that might degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

Stand-alone Dfs Configuration

If a stand-alone Dfs root configuration is damaged and you are unable to stop hosting a Dfs namespace using the Dfs administrator tool, you can delete the Dfs configuration on this computer with the following procedure:

To remove a stand-alone Dfs root

1. On the Start menu, click Run .

2. Type cmd and then type net stop dfs .

3. Start a registry editor (either Regedit.exe or Regedt32.exe). (For more information about these editors, see Windows 2000 Server Help.)

4. In Regedit or Regedt32, go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.

5. Delete the DFSHost subkey. (The subkeys it contains are also deleted.)

6. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSDriver\LocalVolumes. Delete any subkey in the LocalVolumes subkey. Do not delete the LocalVolumes subkey.

7. Close the registry editor, and use Computer Management to restart the Dfs service.

Domain-based Dfs Configuration

If a domain-based Dfs root configuration is damaged and you are unable to stop hosting a Dfs namespace by using the Dfs administrative tool, you can delete the Dfs configuration on this computer and from Active Directory by using the following procedure:

To remove a domain-based Dfs root

1. Perform the steps listed in the preceding procedure ("To remove a stand-alone Dfs root") without restarting Dfs.

2. In the Active Directory Users and Computers console, on the View menu, click Advanced Features .

3. Under the System folder, open the Dfs-configuration container.

4. Delete the Dfs root in the right pane.

5. Restart Dfs by using the Dfs administrative tool.

Configuration changes are immediately effective for the computer on which the changes are made. For another computer in the domain, you must wait for replication to occur to see the changes or force replication by restarting the other computer.