By Tom Yager

Microsoft's Distributed File System makes (more) sense for Windows NT networking

Questions regarding this article should be sent to the author at tyager@maxx.net .

If you spend the more than the $800 that Microsoft asks for Windows NT 4.0, you'll be immersed in technology that looks as shiny and appealing as new-car chrome. But beneath the high-gloss exterior lies a networking design that dates back to the earliest days of interconnected PCs. A few of us still remember LAN Manager. What we learned back then about managing a LAN-Manager network we find we can still apply to Windows NT.

Microsoft's NetBEUI (or NetBIOS if you prefer) networking has been enhanced to provide nearly effortless connections. You can drop a Windows NT, Windows 95, or Windows for Workgroups PC on a desk, hook up its network cable and get on the LAN in minutes. All you need to do is give the machine an unique name and provide the name of an existing workgroup or Windows NT domain. NetBEUI will find that domain, query its other members and--without effort--the PC has access to the LAN's resources.

Until now, NetBEUI networking has been a least-capable-client affair. Microsoft has had to worry about DOS and 16-bit Windows clients connecting to resources. Resource names--we've been warned--need to stay DOS friendly. And when you connect to a remote shared file resource--regardless of the operating system you're running--that resource appears on your machine as a lettered drive. Each remote resource you attach appears as a driv e of its own.

That's fine for a small network. On a LAN with multiple servers, however, it gets more complicated. Administrators have the nightmarish task of managing scripts that attach clients to resources on different servers. Upgrade or phase out a server, add or change drives, or rearrange directory structures and chances are you'll be fixing the scripts on every client in the building. Point-and-click doesn't make this any easier.

The Unix Network File System (NFS) offers a more elegant solution. With symbolic links and cross-server mounts, an administrator can set up a hierarchy of shares that a user can access with a single mount command. You can use links to create aliases and hide the complexity of your network's structure from users.

Dfs Finally Arrives

Dfs is Microsoft's Distributed file system, which has the features listed here (<URL:http://www.microsoft.com/windows/common/a587.ht m>). In brief, it lets you create a hierarchy of shared resources. The hierarchy combines shares from any number of servers. Your clients may tap into the hierarchy at any level and see all the levels beneath. With appropriate permissions, a client can make a single mount and see a massive tree of shared resources. Instead of each share having its own drive letter on the client, all network shares can be organized to appear to the client under a single drive letter.

Server-side administrative tools give you control over the hierarchy. Each root of the Dfs hierarchy resides on one of the server's drives. Beneath it you build a tree of shares, local and remote. You may alias any remote share name to a name that makes more sense. Microsoft refers to these aliases as replicas. The hierarchy may grow as deep as you like; the only restriction is that the fully-qualified path name cannot exceed 260 characters.

Dfs' uses are innumerable. Using replicas and single-point client mounts gives y ou the flexibility to reconfigure resources transparently. Let's say you choose to phase out the accounting department's fileserver. Before you put it out to pasture you copy its files to a new server. Under the old NetBEUI model you'd have to reconfigure the clients to point them at the new server. You might even need to alter applications to point to new drive letters or subdirectory names.

With Dfs, the switch is easy. No client-side changes are needed. You simply change the Dfs replica to point to a different remote share. The client uses the same name as before to mount the share, but Dfs redirects it to the new server.

Dfs also gives you the ability to do crude load balancing among servers. Each Dfs replica can point to more than one share. If you have two shares defined for one replica, Dfs will alternate between them. The first client to mount the replica gets redirected to the first listed server. The second client gets redirected to the second server, and the third client gets the first server again. You may define as many shares as you like under a single Dfs entry.

You might use this feature to balance the load of heavily-used directories across servers. If you keep the servers' contents synchronized, users won't know (or care) which server they're using. This works best for read-only directories. Otherwise, a client could write a file, detach from the share and reattach to a different server (using the same Dfs replica). The file would seem to disappear.

Dfs Administration

The server side of Dfs installs on a Windows NT Server machine. It's a Windows NT networking service, installed through the network icon in control panel. The Dfs service's properties let you create a new Dfs root. This is a special share that anchors future Dfs hierarchies. It's very NFS-like in that any valid directory may host a Dfs root.

If you don't have an existing directory to host Dfs, you can create a new directory on any of the server's drives. The Dfs service's properties interface lets you create a new directory and a share that advertises it; just supply the names and you're in business. Your new directory will become the Dfs root. If you use an existing directory, users mounting the Dfs root will see the Dfs shares as well as files in the directory hosting the Dfs root.

The Dfs server install places the Dfs administrator utility in the Start menu's administrative tools section. The interface is easy to operate: to create a new Dfs share, you supply an replica name and a share location. The replica name is the path the user supplies to mount the share. The share location is the path to the remote share. Both are expressed as UNC (universal naming convention) paths. A new replica on a Windows NT Server system named ``server3'' might take on the name \\server3\OurDfsRoot\users . That replica could point to an already-defined share on server3, or to another server's share: \\rufus\DriveC\users .

Dfs lets you de fine hierarchies of replicas. If you specify a replica that is a subdirectory of an existing replica, a client can view lower-level replicas from the parent. Each subordinate replica is shown to the client as a subdirectory with the same name as the last element of the replica (the file name portion).

While Dfs publishes its roots using Windows-native NetBEUI networking, it doesn't care what method you use to attach remote share nodes to the Dfs tree. If you have Gateway Services for Netware (a standard component in Windows NT Server) installed, Dfs replicas can point to Netware server shares. If you have an NFS client that complies with LAN Manager/Windows NT redirector specifications, you can create a Dfs replica that points to a remote NFS server. Dfs will redirect to any remote share as long as it's accessible to Windows NT's networking scheme.

Dfs Client Access

A Dfs root published by a Windows NT Server 4.0 system looks like an ordinary share. Windows NT Workstation 4.0 ( and the workstation component of Windows NT Server) ships with Dfs client support built-in. Windows 95 does not, and Dfs support isn't available for 16-bit Windows or DOS. A Windows 95 client without Dfs support can't see past the Dfs root. With the Dfs support loaded, the Windows 95 client can browse the entire Dfs hierarchy starting from the root, as long as the user has access rights.

I worked with a beta release of Dfs downloadable from Microsoft (<URL:http://www.microsoft.com/windows/common/a2263.htm>), which was missing support for multiple Dfs roots. The documentation hints that such support may come later. When I tried creating a second root, Dfs destroyed the first one.

I expected each replica in a Dfs hierarchy to be separately advertised and mountable. At least in this release, only the root is advertised. Using ``network neighborhood'' (the 32-bit Windows graphical-network browser) gives you a chance to mou nt the Dfs root, but subordinate replicas are not offered as distinct shares. You can only mount the root; you apparently can't mount any children of the root. I'm not sure whether this behavior will change with the next release of Dfs.

My tests showed Dfs is just about ready to go. I had some trouble with one replica, trouble that disappeared (inexplicably) when I deleted the replica and recreated it as a subdirectory of another replica. I was also reminded that while combining the shares of multiple servers, one must be mindful of access rights and user name/password authentication. A replica is a reference to a remote share. It doesn't override that share's security. A client still needs access rights to the target share even if it has full access to the Dfs server.

Dfs creates a subdirectory on the server for each replica in the Dfs tree. A replica directory is empty by default, but any files you deposit into one of these directories will be available to clients. Replicas can only point to drives or directories, not specific files, so there's no danger of local files conflicting with remote ones.

Dfs doesn't behave like NFS. A replica definition does not mount a remote share onto the Dfs server. With a Dfs tree defined, you can display the server's replica directories and see only empty folders. The files magically appear when a client browses the Dfs tree from the network. Of course you can mount your server's own Dfs tree to see what it looks like to clients.

The first access to a Dfs replica takes a few seconds while the Dfs server redirects the link. The client then caches the target of the redirection. Subsequent references to the same replica are much quicker.

Dfs doesn't make DOS lettered drives go away. I'll rejoice on that day, but I'll lift a glass to Dfs. In the hands of an imaginative administrator, it can make a multi-server environment easier to manage. Anything that keeps us from having to walk to each workstation and change its settings i s a blessing. Does Microsoft still need to give us hierarchical local storage? Absolutely. I still can't add a drive to a Windows NT system and call it, say, /users/accounting as I can with Unix. But Dfs is a worthwhile step. Any shop with more than a handful of PCs should plan to use it.