The domain file system in Windows 2000 lets you set up a logical representation of network shares. Here’s how to build a new namespace that’s easier for users to traverse.

Dfs Development

The domain file system in Windows 2000 lets you set up a logical representation of network shares. Here’s how to build a new namespace that’s easier for users to traverse.

• By Michael Chacon
• 10/01/2000

Last month I discussed the new features in NTFS and left off with the Volume Mount Points concept. Volume Mount Points allow you to add local or remote partitions to an empty directory on a local NTFS drive. The main benefit is that you can dynamically increase disk space by adding an available partition from another server. However, Volume Mount Points only support the attachment of the root of the partition attached to a local file directory. Useful, but not flexible.

The next development in this technology concept is called a Directory Junction. Directory Junctions expand upon the limited functionality of Volume Mount Points by permitting the merging of a remote directory structure, rather than just the root from one server to the client. While this broadened functionality is useful, Directory Junctions still have limitations. Directory Junctions are designed to attach network shares to a local NTFS partition, so, while building logical views, they’re still individually user-centric.

Therein comes the next step up in this development—the domain file system or Dfs, first made available as an add-on service for Windows NT. Dfs lets the administrator build a logical representation of network shares. Fundamentally, Dfs gives you an opportunity to create a new namespace that’s easier for users to traverse.

In most networks, shares are scattered throughout the organization on the physical servers. The shares are usually collected and locally mounted through logon scripts to each user as drive letters that the user then navigates through via Explorer. Explorer is aptly named because it forces users to look almost blindly for the shares and information they want. The fact that you need foreknowledge to locate useful information has always been a weak area with NT.

The Architecture of Dfs

Architecturally, Dfs is a classic example of a new service built on the shoulders of predecessors; it takes advantage of lower-level services that are essentially unchanged from different versions of NT. It’s really this maturation of higher-level abstracted services relying on lower-level fundamental services that makes Win2K such an interesting and practical operating system. Dfs exploits the underlying RPCs, SMBs, and file protocols to establish sessions between servers. In fact, Dfs even uses the classic NET USE command to establish the links as clients traverse the Dfs logical trees. Dfs only changes the view of resources, not the underlying structure of physical locations.

To illustrate the Dfs concept, let’s look at a simple example. The shares and their respective servers shown in Figure 1 each need a separate mapping command executed so the user can access the information on each share.

Figure 1. The shares as mapped by the administrator (top) and as they appear to the unwitting user (on the right).

With the logical overlay of Dfs shown in Figure 1 these shares can be presented as one topology attached to the client as one drive letter.

F: \\SRV1\HR
G: \\SRV2\ACCOUNTING
H: \\SRV3\SALESNA
I: \\SRV4\SALESEUR

This gives the user several prominent benefits, such as a logical hierarchy of information built from scattered resources, but independent of physical location. Another benefit is that replicas of the Dfs directories can be created, providing fault tolerance and distributed availability.

With the release of the Win2K version, Dfs now comes in two flavors. Stand-alone Dfs, or version 2, is the legacy NT 4.x that stores the Dfs topology information in the local registry. While important to the development of the new Dfs version, this storage characteristic limits version 2 scalability. The new more interesting version 3 type, which I’ll discuss here, is the domain-based Dfs that comes with Win2K. One of the main enhancements domain-Dfs gives you is the opportunity to store configuration information in Active Directory.This central, yet distributed, storage capability allows the Dfs topology to be published across multiple locations and facilitates the creation of information replicas to provide redundancy.

Building a Dfs Tree

With that brief overview in mind let’s look at how to build a Dfs tree. As with most Win2K services the installation of Dfs is facilitated through a Wizard. First, you need to add the MMC Dfs snap-in to your Administrative menu as you do with any other Administrative tool. Once the snap-in is in place, you select Action | New Dfs Root as shown in Figure 2 to bring up the Wizard.

Figure 2. The first step in building a Dfs tree is to add the MMC Dfs snap-in to the Administrative menu.

After stepping by the Dfs Wizard introduction screen, you’re presented with your first decision as shown in Figure 3. Is this Dfs root going to be domain-based or stand-alone-based? As I mentioned previously, the stand-alone version is for version 2 backward-compatibility for NT and 9x clients and lacks the functionality of the new version. A domain-based Dfs root takes advantage of AD and supports replica-based root redundancy.

Figure 3. Decision No. 1: Do you want a Domain Dfs root, to take advantage of AD or a standalone Dfs root for backward compatibility with NT and 9x clients?

Since we’re discussing the Win2K domain-based root, we have to choose the domain that will host the configuration information. After the domain choice, shown in Figure 4, you’ll be presented with a screen that allows you to choose the actual server in the domain that you want to use as the root share for the Dfs tree.

Figure 4. Next, designate the host domain for the Dfs root.

Next you specify the share that will become the Dfs root (Figure 5). You can use an existing share, which is quite common, since many Dfs trees are built to create a new namespace around existing shares. However, if you want to create a new one, the path and share name you enter here will become the root name. You want to be thoughtful here, as this is the beginning of the new namespace that you’re creating.

Figure 5. Then you designate the share that will become the Dfs root. An existing share creates a namespace around existing shares; a new share begins a new namespace.

As you finish working your way through the screens you are finally presented with an overview page that displays the Dfs information in one place for your review (Figure 6). You can always go back here to modify any information that doesn’t reflect what you intended.

Figure 6. The summary screen displays the Dfs information you’ve designated along the way.

After you verify the information and click on finish, you’re returned to the Dfs administrative snap-in where you now manage the existing Dfs roots you’ve created. The Dfs snap-in shows the logical structure as it develops on the left, with the physical mappings displayed in the right pane (Figure 7).

Figure 7. The logical structure of the Dfs roots appears on the left in this snap-in, and the physical mappings on the right.

Since the whole point of the Dfs is to bring different physical locations under one logical view, the next step is to add child nodes to the existing Dfs root. You accomplish this by selecting the Action | New Link menu option, which brings up the dialog box in Figure 8.

Figure 8. Adding child nodes to an existing Dfs root involves specifying a “Link name,” to identify for users what kind of information they’ll find in a given folder.

Here you specify the Link name, which will be displayed to the client, and the UNC name that Dfs will use to connect to the share. The Link name is the next level in the new namespace that you’re creating, so take care to make it useful for reflecting the type of information the user will find. The Client cache refers to how long this referral will remain in the client’s local cache so it won’t have to look up the information in AD. As with all caching, there’s a trade-off between more efficient response times and accuracy in the cached information. However, network shares tend to be more stable than other types of cached information. After creating a couple of child nodes that point to different locations, you can view the results in the Dfs snap-in as shown in Figure 9.

Figure 9. How the new Link names look to the administrator...

Figure 10. ...and how the client side views them.

As specified in the Wizard, the root is located in the ADLAB domain and is called Business Data. There are two child nodes: Working Area and Applications. From the client side, you get the view shown in Figure 10. The Business Data root name is shown as a share, and the Applications and Working Area are displayed alongside the regular directory folders presenting the seamless logical Dfs view.

As I mentioned previously, Dfs relies upon existing network services to provide this view. In this example, when a client selects the Business Data root, the Dfs server uses Server Message Blocks (SMBs) to negotiate with the client—communicated to the client as encountering a junction point. The client then proceeds to look in AD for a referral to the lowest-cost replica connection and simply issues a NET USE command to the appropriate UNC to complete the setup of the session.

If you don’t have a replica set up and the share point is unavailable for some reason, then, of course, you’ll get an error message. To set up a replica, you just create a share on another server and select it as the replica location.

You then choose between manual and automatic replication. When the replication is complete, you have two physical locations that can be used for redundancy and availability. If a client chooses the Working Area junction, Dfs will use the existing services in Win2K to choose the lowest-cost Dfs connection; if that’s unavailable, the client will follow the other connection.

Take Advantage of AD

Win2K Dfs is a significant step toward completing the abstraction of the physical structure of the information network from the client and presenting it as a logical view of information to the users of the network. It’s also one of the first services to take advantage of AD by removing the Dfs configuration information from the registry and placing it in the distributed AD architecture. This allows Dfs trees to be available to all of the Win2K clients.

I should note that Dfs in Win2K allows the collection of non-Win2K shares to be incorporated into the Dfs tree. This means that file resources from NetWare or Solaris, for example, could be accessed through the Win2K Dfs tree in one logical view. This is true, of course, so long as the proper file protocols and redirectors are in place for the clients who want to reach those operating systems. Dfs is a high-level service that rides on the services we’ve spent years putting in place, and it’s a welcome addition to the quiver of services available for providing practical views of information to our users.