Dfs: A Logical View of Physical Resources

The Microsoft Distributed File System (Dfs) for Windows NT Server is a utility, currently in public beta, that lets you create a single, hierarchical view of your network's physical resources. Don't confuse Dfs with other distributed file systems used in UNIX environments (for information about the differences see "Dfs vs. DFS,"). With Dfs, you can build a Dfs name space (or directory tree) so users view only one directory that spans all the file servers and server shares in the network, instead of a long list of servers and shares, each with a separate directory. You can position each network resource in the most logical place in your Dfs tree, regardless of where it is actually located in the network. Furthermore, Dfs is only software. No new file systems are created, so no extra security is required beyond native NT security. Screen 1 shows an example Dfs tree created in the Windows NT Magazine Lab.

Dfs adds a layer of abstraction to the physical \\server\share universal naming convention (UNC) name, so you can access network resources in a more intuitive manner. For example, suppose you need to find your human resources department's benefit information. Which search is easier: looking in \corpsrv3\hr\allinfo\pubinfo\1996\benefits (where you first have to hunt around for the server and share names), or looking in \\ntdfs\dfsroot\hr\benefit info (where you can search down the \dfsroot directory tree if necessary)?

Dfs Benefits
Dfs benefits are numerous. System administrators and designers will like how simple it is to consolidate server shares into a single tree that's easy to maintain. You can centrally manage a Dfs tree by controlling rights to the Dfs servers, and transparently add storage where it's needed. Users can connect to one or two Dfs network shares and easily locate data throughout the network without having to remember server or share names--you can assign logical, descriptive names to resources in the Dfs tree regardless of their names in the network. Because a Dfs tree is a virtual representation of physical shares, you can also move the physical location of each share without affecting what the user sees. The Dfs administrator needs to know where the new share physically resides, but your users access the data exactly as before.

Suppose you need to take down a server to upgrade it, but also keep its data available to users. With Dfs you can simply move the data from one server to another, point the Dfs tree at the new physical location (using the Dfs Administrator program shown in Screen 2), and upgrade the original server at your convenience.

A Dfs volume can increase data availability because you can use multiple servers (a.k.a. alternate paths) as duplicate storage points for any part of the Dfs tree. Any share in the Dfs tree can point to any number of duplicate data sources. Dfs doesn't replicate the data among the multiple data sources (so you need to use NT's directory replication services or other products to do that), but it does transparently distribute the load (shown in Screen 3). Every user is routed to a different physical resource in a round-robin fashion: The first user goes to duplicate resource A, the next user goes to duplicate resource B, and so on. Each user accesses the same data on physically different servers represented as one virtual directory. (All these maneuvers, of course, are transparent to the user.) With this capability, Dfs provides some measure of fault tolerance: If any of the duplicate resources fail, as long as at least one still functions, users can continue to access the data. Unfortunately, however, Dfs doesn't calculate connection costs; if you have a pair of alternate paths and one is across the country, Dfs will not favor the local path over the long-distance path.

Can your company benefit from Dfs? Before you spend any time planning what great things you can do with Dfs, you need to see whether your network can use it. Because Dfs uses an updated version of Microsoft's Server Message Block (SMB), you must have the newest network redirectors:

• Your servers must be running NT Server 4.0 to run the Dfs service, but Dfs will access existing network shares, called downlevel volumes, located on any server currently on your network. The servers that contain these ordinary network shares don't have to run NT Server 4.0; they can run NT 3.51, Win95, NetWare, LAN Manager, or even Windows for Workgroups (WFW) 3.11. If the Dfs server can establish a connection to the network share, the Dfs service can use it.
• Your clients must be running either NT Workstation (NTW) 4.0 or Win95 with the updated network redirector (included in the Dfs release).
• At this time, Dfs does not fully support NTW 3.51, Windows 3.1, and WFW 3.11 as clients. Amazingly, you cannot view or modify NTFS permissions anywhere along the Dfs tree. You even cannot view permissions for files that reside on a network share you ordinarily could modify if you'd connected using conventional methods. This shortcoming destroys the illusion of a seamless directory tree for users who must access the resource outside Dfs to modify its permissions. So Dfs won't be as useful in situations where Dfs users need to modify the data's NTFS permissions. This limitation shouldn't be a problem for resources where data is accessed by Dfs users but controlled by an administrative group that uses conventional network shares.

Thus, how your company benefits from Dfs depends on how many Win95 and NTW 4.0 clients your network includes. If your company plans to upgrade its clients to NTW 4.0 or Win95 in the near future, you can deploy a well-designed Dfs name space now so that it's ready and waiting as users upgrade. As clients upgrade to Win95 and NTW 4.0, they immediately can access the Dfs name space and take advantage of the benefits of Dfs (and entice other users to upgrade).