The Distributed File System

One of the problems with file sharing and networks is that users often have difficulty finding the files on the network that they need to access. If you have a single file server on your network, this problem might be inconsequential. However, when you start adding multiple file servers in multiple locations, helping users find the appropriate shares can become a full-time job.

The Distributed file system (Dfs) was designed to help alleviate this dilemma while also providing such benefits as load balancing, additional fault tolerance, and conservation of intrasite network bandwidth. Dfs achieves these goals by hiding the underlying structure of file shares inside a virtual folder structure such that users see a single contiguous folder structure, which in reality might consist of folders residing on a dozen different servers scattered across your organization. To help you make the most of Dfs, the following sections explain its advantages, define its concepts, outline its structure, and then show you how to set up Dfs and administer it.

You can download Dfs version 4.x to use in Microsoft Windows NT 4. However, this version is considered beta software. Dfs version 5, which is included with Windows 2000, works much better and has considerably more functionality than earlier versions.

Advantages

The principal advantage of Dfs is its single point of access to all network shares. Another benefit is that it allows you to organize file shares and to manage increased availability and fault tolerance as well as load-balancing functionality. In addition, security is easy with Dfs. The next sections elaborate on these advantages and why you might want to use Dfs on your network.

One Point of Access for All Network Files

Dfs makes it easier for users to find and access the file shares they need. Without Dfs, users often must connect to a number of different shares on multiple file servers to obtain the files they need. Unless the users know which servers and file shares to look in, they might not find the files at all. Dfs permits the creation of a virtual, hierarchically organized collection of file shares so that users can simply connect to a single server (the host server for the Dfs structure) and access all important shared folders, even though the folders are actually stored on multiple servers, as shown in Figure 17-1.

Figure 17-1. The folder structure a user sees when using Dfs, and the actual folder structure.

Unfortunately, the current implementation of Dfs in Windows 2000 doesn't provide enough flexibility when creating a virtual folder hierarchy because midlevel junctions—Dfs links from a folder other than the Dfs root—are unsupported. See the section entitled Structure and Topology, later in this chapter, for more information on this limitation (Microsoft Windows .NET Server is expected to remove this limitation by allowing multiple Dfs roots per server).

High Availability and Better Performance

Dfs offers better availability and performance than your garden-variety shared folder. It accomplishes this in three ways: by hiding the underlying folder structure from users, by leveraging Active Directory service for replication and site optimization, and by using replicas for load balancing.

First, Dfs shields the actual file shares from users. Thus, users navigate the Dfs folder structure oblivious to where the files they access are coming from. This permits things like taking a server offline for maintenance without taking any shares offline: simply change the affected Dfs links to point to another server with a copy of the folder shares and no one will be the wiser (except you, of course).

If your intranet Web site makes use of shared folders on the network (instead of residing on the Web server itself), create your Web site in a shared folder, create a Dfs link to the shared folder, and configure Internet Information Services (IIS) to use the Dfs link to the folder for the Web site. If you need to take down the server that is storing the shared folder, just change the Dfs link to point to a copy of the shared folder on another server—no hyperlinks are broken by doing this.

Second, domain-based Dfs roots automatically make use of Active Directory to replicate the Dfs topology and can also use file replication service (FRS) to replicate the actual Dfs root, or individual shared folders, as shown in Figure 17-2. This provides fault tolerance and automatically synchronizes the Dfs root and individual shared folders, permitting access to up-to-date content even if a server goes down.

Figure 17-2. The folder structure a user sees when using Dfs and load balancing, and the actual folder structure.

Finally, setting up replication for the Dfs root, shared folders, or both also provides a performance boost to clients by utilizing load balancing and site awareness: clients connect randomly to a root target and shared folder target in their local site, spreading the load over however many servers in the site are set up to replicate the Dfs root or shared folders (targets and root targets are the individual servers set up to replicate shared folders and Dfs roots).

Security

Another advantage to Dfs is that it doesn't add any complexity to security. You set the permissions for the Dfs root—who can access and modify the Dfs structure—but all other security is handled by the NTFS file system. This arrangement makes sense because Dfs provides only a virtual structure to the existing set of file shares. The same security settings that apply to accessing file shares directly apply to accessing the file shares using the Dfs tree.

Concepts and Terminology

Because Dfs is such a new technology to Windows, a brief primer on the most important concepts and terms is in order. The next sections cover the Dfs client and server components and consider Dfs on stand-alone servers as well as servers belonging to a Windows 2000 domain. Then you'll learn how a Dfs structure is created and what components make up the Dfs topology.

Dfs Clients

To access the Dfs folder structure, you need a Dfs client. Table 17-1 shows the type of Dfs client support that is provided by various operating systems. Note that clients that don't have a Dfs client installed can't access the Dfs tree and gain the benefits of Dfs; however, they can access the file shares just as they would if Dfs weren't set up on the network. In terms of support for Dfs, if you're running an operating system that doesn't include "Microsoft" in the title, you're out of luck for now.

Table 17-1. Operating system support for Dfs access

Operating System	DFS Client Support
Non-Microsoft, Macintosh, Unix, OS/2	None
MS-DOS	None
Windows 3.x	None
Windows 95	Downloadable client for Dfs 4.x and 5
Windows 98/98 Second Edition	Dfs 4.x and 5 stand-alone client included, Dfs 5 domain-based client downloadable
Windows NT 4 with Service Pack 3	Dfs 4.x and 5 stand-alone client included, Dfs 5 domain-based client downloadable
Windows 2000, Windows XP	Full support built in

Use Windows 2000 or Microsoft Windows XP for client access to Dfs. Although earlier Microsoft operating systems can work, they have more problems with Dfs than do the newer Microsoft operating systems.

Dfs Servers

Any Windows 2000 server can host a Dfs root, either in domain-based mode (if the server belongs to a domain) or stand-alone mode (if the server is in a workgroup). Windows NT 4 Server with Service Pack 3 or later and some varieties of UNIX running Samba can also host Dfs roots, but only the stand-alone variety.

Any computer using an operating system that can be resolved by a Windows server using a Universal Naming Convention (UNC) path can contribute file shares to a Dfs tree, including Microsoft Windows 98, Novell NetWare, UNIX, and Mac OS X (keep in mind that users need adequate permissions on a share to be able to use it, and this applies to UNIX and NetWare shares as well).

To use the folder synchronization feature of Dfs to keep two file shares identical, the Dfs root needs to be domain based and the file shares need to be hosted on NTFS partitions on a domain controller (which is fine, because using FAT partitions for file shares is kind of like climbing flagpoles during thunderstorms—not a good idea).

Dfs In and Out of Domains

Dfs comes in two flavors: stand-alone and domain based. Those astute readers who figured out that these two variations depend on whether the server hosting the Dfs root is a stand-alone server or a server belonging to a Windows domain can take a free coffee break.

Stand-alone Dfs can't use Active Directory, with the net result that stand-alone Dfs roots can't perform automatic replication of targets (shared folders), nor can they replicate Dfs roots (root targets) in any way. Stand-alone Dfs roots can be hosted on any Windows server, and even though they don't make use of Active Directory, they can be hosted on servers belonging to Active Directory domains.

Domain-based Dfs roots differ from stand-alone Dfs in a couple of ways. First, domain-based Dfs roots predictably must be hosted on a member server or domain controller of an Active Directory domain. Second, domain-based Dfs roots automatically publish the Dfs topology in Active Directory. This provides fault tolerance and network performance optimization by directing clients to the nearest target, as discussed in the next section. Active Directory also allows domain-based Dfs to automatically synchronize targets and root targets.

Domain-based Dfs roots are limited to 5000 links, whereas stand-alone Dfs roots can host 10,000 links. To support more than 5000 links, use a stand-alone Dfs root (which can be created even on member servers and domain controllers). To support more than 10,000 links, use multiple stand-alone Dfs servers.

Using Dfs Without NetBIOS or WINS

Dfs relies on NetBIOS to resolve share names. If your network has NetBIOS over TCP/IP disabled, or has eliminated WINS (you lucky dog), you'll need to enable fully qualified Dfs names in the registry of each Dfs server before creating the Dfs namespace (note that you shouldn't perform this procedure unless you don't use NetBIOS addressing on your network).

To do so, follow these steps on every server that will host a Dfs root:

1. Open the Registry Editor by choosing Run from the Start menu, typing regedit, and then clicking OK.
2. Open the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFS 

3. Change the DFSDnsConfig value to have the value data of 1 (0 disables fully qualified name resolution). If the value doesn't exist, create it using the following information:

   Value Name: DfsDnsConfig

   Data Type: REG_DWORD

   Value Data: 1

Structure and Topology

Although Dfs mimics a normal file system, the terminology it uses is different, and there are some unique wrinkles to understand. The following sections talk about Dfs roots, which are analogous to drives in a normal file system; Dfs links, which are analogous to folders; targets (picture a RAID volume); and the creation of hierarchies in Dfs, similar to creating a folder tree.

Dfs Roots

The structure of a Dfs tree begins with a Dfs root, similar to the way the Windows file system starts with a drive. The Dfs root is the shared folder that serves as the root for a particular Dfs tree. Because Dfs is only a virtual file system, the Dfs root can be any shared folder, although it really should be on an NTFS partition. The Dfs root can contain normal files and subfolders, although you can't create links from subfolders, so be careful when designing your folder structure (more on this later). The server that stores the Dfs root is called the host server.

Windows NT 4 and Windows 2000 servers only support one Dfs root per server, making it difficult to create hierarchies of file shares in Dfs. Windows .NET servers don't have this limitation.

Links

By itself, a Dfs root is nothing more than just another file share. The beauty of Dfs is its ability to link to other file shares, called Dfs links, which appear as subfolders of the Dfs root. When a Dfs client opens a Dfs link (which appears as a normal subfolder), they seamlessly open the linked file share. Whether it's a different folder on the same server or a file share on a server in an entirely different department, users are never aware that the folder they opened is anything but a normal subfolder of the Dfs root.

Replicas (Targets)

Dfs links have a really cool feature: they don't have to link to just one folder. Instead, a Dfs link can link to a maximum of 32 identical folders, called replicas or shared folders (or targets in Windows .NET Server). The client sees only a single, ordinary folder.

Dfs clients automatically choose a replica in their site, if available, reducing intersite network utilization. If more than one replica is available on the client's site, each client randomly selects a replica, allowing the load to be spread evenly across all available servers. If a replica goes down, the client automatically picks a different replica. In this way, replicas provide fault tolerance, load balancing, and WAN link optimization.

You can create replicas for normal file shares as well as for the Dfs root, and you can set them up to automatically synchronize with all other replicas. The only prerequisites are that the Dfs roots need to be domain-based, and the replicas need to be hosted on Windows servers running the file replication service (which is started automatically on domain controllers but can be started manually on member servers as well; just go into the Services console).

Creating a Tree Hierarchy

So far, we've covered creating links from the Dfs root, as well as creating Dfs root and Dfs link replicas that are transparent to users. However, this still leaves the Dfs tree only two levels deep: the Dfs root and any linked file shares.

To create deeper layers in Dfs, you might be tempted to use Windows Explorer to create subfolders of the folder that serves as the Dfs root. However, these subfolders won't show up in the Dfs management console, and you can't host additional Dfs links from these subfolders, so this is a bad idea.

To get deeper layers of Dfs structure, create links to other Dfs roots hosted on other servers (or on the same server if running Windows .NET Server). These links are called inter-dfs links (Figure 17-3), and currently they are the only way of creating Dfs trees deeper than a single level. Inter-dfs links are also the way to link different DNS namespaces, as all normal Dfs links must be to file shares within the same DNS namespace.

To create an inter-dfs link, create a normal Dfs link but choose a Dfs root as the replica folder instead of a normal file share. Create as many Dfs roots as necessary to support the desired hierarchy.

Figure 17-3. The various components of a Dfs tree.

When a user opens a new folder in a Dfs structure, he or she is likely connecting to a new server, which entails some delay. Because of this, it's important to minimize the number of "wrong turns" users make opening folders that don't contain the files they are looking for. To help users find the data they want with as little delay as possible, establish a consistent and intuitive naming structure for Dfs links, and consider creating a site map at key levels of the Dfs tree.

Setup

Setting up Dfs is simple. Just create or open a Dfs root and then add Dfs links for any file shares you want to appear in the Dfs root. Of course, before doing this, check with your users and compile a list of network shares to which they need access. Dfs is useless if the right network shares aren't part of the Dfs tree.

Creating or Opening a Dfs Root

The first step in working with Dfs is to create a Dfs root (or open an existing root). To do so, follow these steps:

1. Launch the Distributed File System MMC snap-in from the Administrative Tools folder.
2. If a Dfs root exists, open it by choosing Display An Existing Dfs Root from the Action menu. Use the Display An Existing Dfs Root dialog box to enter the host server's name or browse to the Dfs root.

   If no Dfs root exists, create one by choosing New Dfs Root from the Action menu and then clicking Next. The New Dfs Root Wizard opens, as shown in Figure 17-4.

   

   Figure 17-4. The New Dfs Root Wizard.

3. If your server belongs to a Windows 2000 domain, select the Create A Domain Dfs Root option and click Next; otherwise, select the Create A Standalone Dfs Root option, click Next, and skip to step 5.
4. Select the host domain to use for the Dfs root on the next screen, and then click Next.
5. Enter the DNS name of the server to host the Dfs root on the next screen, or click Browse to search the network for the appropriate host. Click Next.
6. Choose an existing file share to use as the Dfs root, or create a new share to host the Dfs root by entering the path to the folder and the share name to use for the folder (Figure 17-5). Click Next.

   

   Figure 17-5. The Specify The Dfs Root Share screen of the New Dfs Root Wizard.

7. Enter a name for the Dfs root in the Dfs Root Name box, which Dfs users will see when they open the Dfs root. Enter any comments into the Comments box, and then click Next.
8. Review the settings and then click Finish to create the Dfs root.

If you frequently administer multiple Dfs roots, open a blank MMC, open the Distributed File System snap-in, open all the roots you want to use, and then save the console file. Then, when you need to access all the Dfs roots, launch the saved console file instead of the standard snap-in.

Adding Dfs Links

Dfs links are what make a Dfs root special. Without Dfs links, it's just another file share. Dfs links allow users to navigate from the Dfs root to other file shares on the network without leaving the Dfs structure. To create a Dfs link, follow these steps:

1. From the tree pane on the left, select the root to which you'd like to add a link.
2. Choose the New Dfs Link command from the Action menu. This displays the Create A New Dfs Link dialog box, shown in Figure 17-6.

   

   Figure 17-6. The Create A New Dfs Link dialog box.

3. In the Link Name box, enter the name users will see for the shared folder you're linking to.
4. Enter the shared folder's UNC or DNS path into the second text box, or click Browse to browse to the shared folder to link to.
5. Enter any comments you want other Dfs administrators to see into the Comment text box (comments aren't visible to clients).
6. Use the Clients Cache This Referral For text box to enter the length of time for clients to cache the referral before checking to see whether the referral is still accurate. Setting a longer time reduces network traffic, but it can lead to inaccurate referrals or interruption of service in the event that the Dfs link is changed—during a failover from one member of a replica set to another, or manually to prepare for maintenance for the server hosting the file share.
7. Click OK when you're finished.

Just as the text in a Web page hyperlink doesn't necessarily reflect the filename of the Web page that it's linking to, a Dfs link name can be completely different from the actual name of the shared folder to which it links.

Adding Replicas and Configuring Replication

A key feature of domain-based Dfs is the ability to set up Dfs links and the Dfs root with redundant file shares, called replicas or targets. When you create multiple replicas for a link or root, clients only see a single file share, but behind the scenes Dfs selects the proper file share from multiple servers based on which shares are close by and available.

In addition to this redundancy, you can set up replicas to automatically replicate with each other, although we recommend that you only set this up for Dfs links and not the Dfs root itself. (As mentioned before, enable fault tolerance for the Dfs root, but don't set up automatic replication for the root replicas, as this automatically replicates the entire Dfs tree.)

To set up replicas for the Dfs root, see the next section. To set up replicas and configure replication for another shared folder in the Dfs tree, skip to the Creating Replicas for Dfs Links section later in this chapter.

Creating Dfs Root Replicas

The Dfs root is the most important part of the Dfs tree to replicate because it hosts most of the Dfs links in the tree. Because of this, the first step in creating a more fault-tolerant Dfs tree is to create additional targets for the Dfs root.

To create Dfs root targets, follow these steps:

1. Launch the Distributed File System snap-in and display the Dfs root you want to replicate.
2. Choose New Root Replica from the Action menu.
3. The New Dfs Root Wizard appears, as shown in Figure 17-7. Enter the DNS name of the server you want to use to host the Dfs root replica, or click Browse to search the network for the appropriate host. Click Next.
4. Choose an existing file share to use as the Dfs root replica, or create a new share to host the Dfs root replica by entering the path to the folder and the share name you want to use for the folder. Click Finish.
5. Repeat steps 2 through 4 for any other shared folders you want to use as a replica for this Dfs root.

Microsoft recommends a maximum of 16 Dfs root targets.

Dfs roots can be hosted by server clusters using the Windows 2000 Server cluster service. See Chapter 16 for more information about the cluster service.

Figure 17-7. The New Dfs Root Wizard.

Real World

Don't Replicate Dfs Roots

Because domain-based Dfs is based on Active Directory, Dfs root targets automatically replicate the Dfs structure (that is, Dfs links), even if you don't set up automatic replication of the Dfs root targets.

You can configure replication for the root targets in the Distributed File System console, but doing so replicates the entire Dfs tree and all files within it. This is a somewhat awkward way of configuring replication, and it can consume a good chunk of network bandwidth as well. For these reasons, Microsoft recommends that you not configure replication for Dfs roots, and we agree. Set up replication on individual Dfs links instead; it's more flexible and uses less bandwidth.

Creating Replicas for Dfs Links

An easy-to-use, fault-tolerant, and high-performance file system isn't worth much if the data you want to access is unavailable. Creating replicas for the Dfs root ensures that the file system will be available even if one of the root replicas goes down, but that doesn't mean that the files will still be available. To ensure that files will be available to users even if a server goes down, create additional replicas for Dfs links.

To create replicas for Dfs links and set up automatic replication of the shared folder's content, use the following steps:

1. Select the Dfs link in the Dfs tree for which you want to add replicas.
2. Choose New Replica from the Action menu.
3. Enter the UNC path to the network share you want to use as a replica into the box provided, or click Browse to locate the share on the network (Figure 17-8).

   Domain-based Dfs leverages Active Directory for full, multimaster file replication; however, when you first create a replica set, you need to specify an initial master that will be used as the initial source folder with which the other targets synchronize.

   

   Figure 17-8. The Add A New Replica dialog box.

4. Choose whether you want the shared folder to be replicated automatically (by default, every 15 minutes) or manually. Click OK.
5. Repeat steps 2 through 4 for any other shared folders you want to add to the replica set, and then proceed to step 6.
6. Choose Replication Policy from the Action menu to display the Replication Policy dialog box.
7. Select the shared folder you would like to make the initial master for the replica set, and then click Enable.
8. Select each shared folder you would like to have participate in replication, and click Enable after selecting each one.
9. If you want to change the initial master for the replica set, select the shared folder and click Set Master.
10. Click OK when you're finished.

Don't set some shared folders in a replica set to replicate automatically and others to be replicated manually. You'll cause the shared folders to synchronize poorly.

Backing Up and Restoring the Dfs Database

The Dfs database for domain-based Dfs is stored in Active Directory and can be backed up and restored using Active Directory-aware backup methods.

To back up the structure of stand-alone Dfs roots to a batch (text) file, enter the following text at a command prompt (replace DomainName and DFSRootName with the name of the appropriate domain and Dfs root):

 DFScmd /view \\DomainName\DFSRootName /batch > DFS_backup.bat 

To back up the Dfs root without validating links and targets, use the following command:

 DFScmd /view \\DomainName\DFSRootName /batchrestore > DFS_backup.bat 

To restore this Dfs structure, use the following command:

 DFScmd /view \\DomainName\DFSRootName /restore > DFS.backup.bat 

In addition to backing up the Dfs topology, you should back up the contents of the actual file shares on a routine basis.

Dfs Command-Line Administration

Although you can remotely administer any Dfs root using the Distributed File System console, many administrators appreciate command-line administration capabilities, which is where the Dfscmd command comes in.

To use the command line to administer Dfs, open a command prompt and then type dfscmd, followed by the appropriate parameters. For example, to create a new Dfs link, you could type the following command:

 dfscmd /map \\dfs_root_name\dfs_share_name\path  \\server_name\share_name\path [comment] 

Here is a brief explanation of the parameters you can use with the Dfscmd command:

• /? Displays parameter help for Dfscmd (this works for all commands).
• /map Creates a new Dfs link to the specified path. The first path is the Dfs link path and the second is the UNC path to the network share.
• /unmap Removes a Dfs link.
• /add Adds a target to the Dfs link (or root) you specify.
• /remove Removes the specified target.
• /view Displays information on the specified Dfs root and share. You can append the /partial parameter to display comments or the /batch parameter to create a script that you can use to restore the Dfs root.

For example:

 dfscmd /map "\\scribes.local\Company Documents" \\srv2\documents 

Use quotation marks (not Microsoft Word's smart quotes) to enclose any paths that contain spaces.