What if you could consolidate all the files in your organization into one share point? Your users would never have to remember server names, and you could significantly decrease the number of mapped drives. Think it’s just a dream? With Windows 2000 Distributed File System (Win2K Dfs), it can be a reality.
Get the skinny on Dfs first
This article assumes that you already have an understanding of what Dfs is, how it works, and how to configure domain-based Dfs roots and links. The following articles can help you get up to speed:
- Getting to know the Windows 2000 Distributed File System, by Troy Thompson
- Simplify networking with the Win2K Distributed File System, by Steven Warren
While Dfs wasn’t designed to offer a single file access share point, with a little planning, it can do just that. There are some requirements though.
First, all your clients must be Windows 2000 or better. If your environment contains legacy workstations, you can go back to bed now, because you’re still dreaming. Microsoft does provide legacy support for Dfs; there is a Dfs client available for Windows 95/98 systems, and Windows NT 4.0 had some support built in. However, the functionality in these clients is limited, and won’t work with the implementation we’ll discuss here.
Next, the solution presented here is intended for a single domain. If your organization has multiple Windows 2000 domains, this solution will require deeper thought and planning.
So, if you have a single domain consisting of Windows 2000 or better, read on.
Overview of Dfs
A Dfs Root is basically a share point that allows you to consolidate other share points (Dfs Links). A Dfs Link is just a link to a share; the share can be on the same server, or another server. Using these two objects, we’re only really allowed a single-level hierarchy Dfs structure. Dfs Links aren’t recursive; you can’t create Dfs Links beneath other Dfs Links.
However, you can nest Dfs Roots by creating a Dfs Link which points to another Dfs Root on another server. It must be on another server because each server can only host one Dfs Root. This special nesting process is called an Inter-Dfs Link.
Since the terminology may be confusing, let's look at an example. Acme Insurance is a vehicle insurance company headquartered in Seattle with offices in Minneapolis, Denver, and Los Angeles. Figure A shows the network configuration of the organization. Site configuration and server function are irrelevant for this example, but will need to be taken into consideration for load handling in a real scenario. Each location will keep its own files on one or more of its servers.
There are several ways to implement the overall file structure; you can organize by location, by department function, or a combination of both. Figure B shows one possibility, which we’ll use for the remainder of the example.
Due to the wide distribution of file shares, and due to the fact that not all shared files at each location will be on the same server, we need to think creatively about how to set up the DFS structure. Before we completely construct the Dfs system, let’s look at share locations.
- Information Systems share is on ACMESEAT03
- Claims share is on ACMESEAT02
- Accounting and Administration shares are on ACMESEAT04
- Claims share is on ACMEMINN01
- Accounting and Administration shares are on ACMEMINN02
Where will we need Dfs Roots, Inter-Dfs Links, and Dfs Links? First, we’ll need a “global” root for the file system. Let’s create this Dsf Root on ACMESEAT01. The UNC (Universal Naming Convention) path for this root will be \\ACME.COM\DFS.
Next, we look at the sites to determine which can be Dfs Links. Los Angeles and Denver both have all their shares residing on one server, and so can be normal Dfs Links. We’ll create two Dfs Links in our “global” root (ACMESEAT01); one will point to \\ACMEDENV02\SHARES, and one will point to \\ACMELOSA01\SHARES.
Seattle and Minneapolis each have shares on multiple servers, which means that each of those sites will need its own Dfs Roots. We’ll then incorporate these Dfs Roots into our master structure as Inter-Dfs Links. We’ll create a new Dfs Root on ACMESEAT02 with a UNC path of \\ACME.COM\SEAT, and another new Dfs Root on ACMEMINN01 with a UNC path of \\ACME.COM\MINN. We’ll create four Dfs Links on our Seattle root; one will point to \\ACMESEAT03\INFOSYS, one will point to \\ACMESEAT02\CLAIMS, one will point to \\ACMESEAT04\ADMIN, and the remaining one will point to \\ACMESEAT04\ACCTNG. We’ll also create three Dfs Links on our Minneapolis root; one will point to \\ACMEMINN01\CLAIMS, one will point to \\ACMEMINN02\ACCTNG, and one will point to \\ACMEMINN02\ADMIN.
Last, we’ll create two Inter-Dfs Links (Remember, these are just Dfs Links that point to another Dfs Root instead of a standard server share.) on our “global” Dfs Root. One link will point to \\ACME.COM\MINN, and the other will point to \\ACME.COM\SEAT.
This is actually a fairly simple example. There are many issues that can complicate your design, such as terminal services users and limited bandwidth between sites.
What if you have to expand?
Considering the example above, what happens when you need to segregate data to other file servers, due to space constraints? Let’s say that the server in Los Angeles (ACMELOSA01) has run out of disk space, and rather than add more hard drives, management has decided to add another server. For simplicity, we’ll say that the Claims department can easily segregate its data into “Current” and “Historical”, and all the “Current” data is moved to the new server (ACMELOSA02).
Given our current Dfs structure, we can’t create a new Dfs Link to point to the current data. However, we can create a new Inter-Dfs Link. First, we’ll create a new Dfs Root on ACMELOSA01, with a UNC path of \\ACME.COM\LOSA. Then, we’ll create two Dfs Links on the Los Angeles root; one will point to \\ACMELOSA01\HISTORY, and one will point to \\ACMELOSA02\CURRENT. Last, we’ll remove the Los Angeles Dfs Link from our “global” root, and create a new Inter-Dfs Link that will point to \\ACME.COM\LOSA.
That’s it. We’ve now incorporated the new server shares into our existing Dfs file structure.
It is possible
Whether you can use Dfs to create this kind of global file structure in your organization is dependent on a lot of things, not the least of which is an all Windows 2000 environment. Thanks to Dfs technology and a little ingenuity, having a single, consolidated file structure is no longer a dream.
Are you planning on using Dfs?
Would you like the ability to move all the files in your organization into one share point? Send us some mail or post a reply.