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.
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.