Dfs in Windows 2000

I'm certain of three things in life: death, taxes, and file servers going belly-up for no particular reason. As much as we'd all like 100-percent reliability in our systems, today's mix of complex hardware and OSs makes this dream impossible. Microsoft has gone to great lengths to increase Windows 2000 Server's (Win2K Server's) reliability, but your servers will sometimes still crash and leave your users without access to the files they need. Dfs helps you prevent these problems. (For information about Win2K's reliability, see Mark Minasi, "Windows 2000 Overview," page 54.)

Dfs Overview
In February 1998, I wrote about Dfs in Windows NT Server 5.0 Beta 1. (See "Get a Head Start on NT 5.0 with Dfs.") On a basic level, Dfs is a way of organizing file share resources across network servers into one logical structure that users can easily navigate. In the same way that Dfs lets you organize shares and directories on one server into a logical hierarchical structure for simplified navigation, Dfs lets you organize resources across multiple servers on your network.

You use Dfs to define a network file share that contains other file shares (as opposed to files and directories). These child (i.e., subordinate) shares and directories can be on any of your network servers—whether your systems are spread throughout your building or across the globe. When users navigate through the Dfs structure, they move from one server to another without realizing they've changed servers. Figure 1, page 102, shows a Dfs structure consisting of shares from multiple servers organized into one logical hierarchical structure. On a properly designed Dfs-enabled network, end users don't need to know which server a file is on.

Because Dfs lets you tie together file resources that are spread across different systems, you can define redundant locations for those resources. For example, if you have a shared directory of documents on server A, you can place a replica of those documents on server B in a Dfs replica set. After you define a replica set, Dfs automatically redirects users navigating to that directory to a server at another site if the closest replica isn't available.

When I experimented with Dfs in 1998, the service lacked a means of replicating file changes between the locations you define in the replica set. This deficiency was important because if a user makes a change to a document on one server and Dfs doesn't replicate the change to the copies of the document on the other servers in the replica set, data corruption and versioning problems will likely occur. In Windows 2000 (Win2K) beta 3, Microsoft used a new service called the File Replication Service (FRS) to solve this problem.

Prerequisites
For Dfs to work on your network, you need at least two Win2K Server machines. You can use just one server to perform minor tests, but you need more than one system to take advantage of Dfs's organization, fault-tolerance, and load-sharing capabilities. You also need to store the data that you want to include in a replicated Dfs structure on an NTFS 5.0 volume, rather than on a FAT or regular NTFS volume. Win2K Server monitors NTFS 5.0's journal date to determine when files in a directory that the replication service needs to replicate have changed.

According to Microsoft, Win2K client systems will be able to access fault-tolerant Dfs (also referred to as domain-based Dfs) roots, in addition to standalone Dfs roots. NT 4.0 clients can access standalone Dfs roots by default and fault-tolerant Dfs roots if you install Service Pack 6 (SP6). Windows 98 clients can access standalone Dfs roots out of the box, and you can add the Active Directory (AD) client pack to upgrade these clients to access fault-tolerant roots. Win95 clients can't access any type of Dfs structure on their own. With the AD client pack installed, Win95 clients can access both types of Dfs roots.

Start with the Root
All file systems and file shares have a starting point. In Dfs, the starting point is known as the Dfs root. The Dfs root is similar to the root directory on a hard disk because the Dfs root is the starting location for all other files and subdirectories. In early versions of Dfs, you could define multiple locations via replica sets to make child objects and containers redundant, but you couldn't make the root redundant. Thus, Dfs had a single-point-of-failure weakness. Microsoft revised Dfs so that you can now create redundant Dfs roots across servers. Redundant roots prevent your Dfs structure from going offline if one of your servers fails.

To create a redundant Dfs root, you need a working AD infrastructure. (For information about AD in Win2K, see Darren Mar-Elia, "Active Directory in Windows 2000," page 65.) Dfs uses AD's multimaster replication model to replicate data about the Dfs structure throughout the network, thus preventing the failure of one system from taking the Dfs structure offline.

Decide which servers will participate in the Dfs root, and create a share on each of these systems. After you define root shares on your servers, select Programs, Administrative Tools, Distributed File System from the Win2K Server Start menu to launch the Distributed File System window via the Microsoft Management Console (MMC). Then, select Distributed File System in the console's left pane, and choose New Dfs Root Volume from the Action menu (or right-click Distributed File System and select New Dfs Root Volume, as Screen 1 shows).

When the Create New Dfs Root Wizard window opens, you must supply the necessary information to create a Dfs root. You must first select the type of root (i.e., fault-tolerant or standalone), as Screen 2 shows. Dfs references fault-tolerant roots, which can span multiple systems, by client workstation via the domain name; Dfs references standalone roots, which exist on only one system, by the machine name hosting the Dfs root. Fault-tolerant roots are preferable, but they require a functioning AD infrastructure.

After you specify a fault-tolerant root, the wizard prompts you for the domain to host the Dfs structure. This domain becomes the first portion of the Uniform Naming Convention (UNC) that client workstations use to connect to the file system. In the example that Screen 3 shows, I chose the dewey.netarchitect .com domain. In this example, the UNC map is \\dewey.netarchitect.com\Dfs name.

   Previous  [1]  2  Next