Tip

Key DFS improvements in Windows Server 2008 R2

Distributed File System (DFS) has been part of Windows Server for many years, and while it has matured with time, certain scalability problems have remained.

For example, while DFS can be scaled to work in large environments, you'll find that configuring, managing and troubleshooting the system becomes exponentially more complicated as the size of the deployment increases.

Fortunately, Microsoft has addressed these scalability and troubleshooting problems with Windows Server 2008 R2.

Scalability enhancements

For the most part, the scalability improvements made to DFS in Windows Server 2008 R2 are best suited for organizations with multiple branch offices.

    Requires Free Membership to View

More on Windows DFS

Tutorial:
Windows Distributed File System

Tips:
Use DFS to create file system virtualization in Server 2008

Windows DFS Namespace primer

These types of organizations often have a hub and spoke topology, which means their DFS servers are located in a main office – the hub – with the servers' contents replicated to smaller DFS servers in branch offices.

The problem with this type of architecture is that if a DFS server in the main office fails catastrophically, then all of the branch offices could be impacted.

While creating additional replicas in the main office would be one solution, depending on the replication topology's configuration, these additional replicas may not be able to push updates to the branch offices.

Another solution would be a full mesh topology; however, this path is often avoided because of the expense of the extra WAN links and the volume of replication traffic.

Ultimately, the answer for many organizations is to create a replication with two hub members. With this in mind, it's obvious why one of the most welcome new features in R2 is DFS support for failover clusters. Basically, clustering the hub servers in the main office can prevent the branch office replicas from becoming cut off by a hub server failure.

Another improvement in DFS with Windows 2008 R2 is the ability to create read-only replicated folders.

In the past, if you needed a user at a branch office to access data in a replicated folder -- but you didn't want them to change the data -- you needed to use access control lists (ACL) to grant the particular user read-only access. This requires a lot of administrative effort, especially if the branch offices have a high employee turnover.

A new alternative is to create DFS replicas in the branch offices that contain read-only replicated folders, which has the same effect as granting users read-only access to a traditional replicated folder.

New troubleshooting capabilities

In the updated version of DFS, Microsoft also extended the dfsrdiag.exe command line tool to include new functionalities.

The first of these extensions is the file hash function (DFSRDIAG.EXE FILEHASH). With this function you can compare the authoritative copy of a file against its replicated self by seeing if the file hashes are identical.

Furthermore, the new Replication State function (DFSDIAG.EXE REPLSTATE) allows you to analyze the current state of the replication service. With this, you can see what files are being updated on replication partners.

The basic idea behind another new function, ID Record (DFSRDIAG.EXE IDRECORD), is that every file and folder within a replicated folder has a corresponding ID record within the server's database, which is linked to valuable data like version and timestamp information.

With this function, you can determine a file or folder's record number and extract data bound to that record. This capability can be extremely helpful if you want to compare files stored on DFS replicas for consistency.

Overall, the changes Microsoft has made to DFS in Windows Server 2008 R2 should improve scalability and make the DFS easier to troubleshoot.

ABOUT THE AUTHOR
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.

This was first published in August 2009

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

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.