Tip

DFS upgrades in R2 target admins' storage needs

While the Distributed File System (DFS) has been around since the days of Windows NT 4.0, Microsoft has made numerous improvements to DFS in Windows Server 2003 R2 that make it a much more attractive feature for Windows system administrators. In particular, there have been several major improvements in the area of replication and file availability that can make DFS an ideal solution for low-bandwidth branch office environments. In a series of articles, I'll discuss the nuts-and-bolts of DFS, particularly the new enhancements that you'll find in R2, and how you can implement it to meet the ever-increasing storage needs of your organization.

The original intent of DFS was to make file access across multiple file servers more transparent to the end users in your organization. Let's consider a typical small network environment that contains three file servers named FS1, FS2 and FS3, containing the following file shares:

  • \\FS1
  • \\FS1\accounting
  • \\FS1\marketing
  • \\FS1\training
  • \\FS2
  • \\FS2\hr
  • \\FS2\payroll
  • \\FS3
  • \\FS3\systems
  • \\FS3\production

In this environment, users who required access to both the Accounting and the Payroll share (or even two shares on the same server) would need to maintain and remember two separate connections, either by manually specifying the UNC path of each share or by mapping

    Requires Free Membership to View

    Login

two separate drive letters within a logon script. This can become quite clumsy for users who need access to many different file shares, particularly if the locations of those shares need to change over time. For example, if the FS3 file share is running out of space and you need to move the Systems share to the new FS4 server, you would need to communicate this change to your users or modify the necessary logon scripts.

You can improve this situation by deploying the Distributed File Service, which can create a unified logical namespace across multiple physical file servers. In our current example, by deploying DFS, you can create a single DFS root that can then reference multiple file shares underneath it. A DFS root takes the format of \\\. For example, within the company.com domain, we can create a domain DFS root called \\company.com\shared. We can then create DFS links to the shares stored on the three physical servers, as follows:

  • \\company.com\shared
  • \\company.com\shared\Accounting
  • \\company.com\shared\Marketing
  • \\company.com\shared\Training
  • \\company.com\shared\HR
  • \\company.com\shared\Payroll
  • \\company.com\shared\Systems
  • \\company.com\shared\Production

As you can see, this greatly simplifies the view of shared folders on your network for your users; they can specify a single UNC name to access all of the shares configured beneath it, or have a single drive letter mapped within a logon script. If the Systems share needs to be moved from one physical server to another, its DFS link will remain the same regardless of its new physical location. This provides incredible flexibility in serving up shared files to your users, since you're no longer tied to a file or folder's physical location when providing access to it.

About the author: Laura E. Hunter (CISSP, MCSE: Security, MCDBA, Microsoft MVP) is a senior IT specialist with the University of Pennsylvania where she provides network planning, implementation and troubleshooting services for business units and schools within the university. Hunter is a two-time recipient of the prestigious Microsoft "Most Valuable Professional" award in the area of Windows Server-Networking. She is the author of the Active Directory Field Guide (APress Publishing).

More information on this topic:


This was first published in November 2006

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top