Manage Learn to apply best practices and optimize your operations.

More replication improvements for DFS in Windows Server 2003 R2

Advances in the areas of replication and file availability make DFS an ideal solution for low-bandwidth branch office environments.

While the Distributed File System (DFS) has been around since the days of Windows NT 4.0, improvements made to DFS in Windows Server 2003 R2 make it much more attractive for Windows system administrators.

In a previous article I discussed how advances in the areas of replication and file availability in particular make DFS an ideal solution for low-bandwidth branch office environments. In that article we focused on target priority, client failback and delegated authority. In this article we'll look at some of the other improvements in DFS-Replication (DFS-R) in Windows Server 2003 R2:

Bandwidth throttling and replication scheduling. To further enhance your control over the use of your bandwidth, you can specify replication schedules similar to those you'd set up between sites in Active Directory. You can specify these schedules for an entire replication group, or create a custom schedule for an individual replication connection. You can also put a cap on the amount of bandwidth that DFS-R replication can take up.

Support for replication groups. You can configure one or more sets of data and servers as a replication group with a common configuration for replicated folders, replication schedule, and bandwidth throttling. Each DFS server can support a maximum of 256 replication groups, and each of these groups can contain up to 256 replicated folders.

Collecting data for backup purposes. You can also use replication groups to collect data from branch sites to perform centralized backups. Rather than relying on remote sites to maintain their own backup hardware and perform their own backups, you can create a separate replication group to replicate their data to a central location. By disabling replication from the hub site back to the branch server, you'll create a "one-way" replication agreement that will prevent any inadvertent changes made at the backup site from replicating back to the remote server.

Note: DFS-R can replicate data across multiple forests within the same forest; you're not restricted to replicating within a single domain.

Cross-file RDC. This takes the performance improvement of RDC to the next logical level. Say you have a file stored in a DFS namespace called "2006 Board of Directors.doc," detailing the names and biographical information of your company's board for that year. You need to create a similar file for the 2007 board, so you do a FileSave As on the 2006 file, saving it as "2007 Board of Directors.doc" and making a few changes to reflect two new board members.

Now there's a new file that needs to be replicated within the DFS namespace…but is it really brand-new? By using cross-file RDC, DFS can use the contents of the 2006 Board of Directors file to seed replication for the new file, using the "chunking and hashing" method we've already described to only send over the wire the information that's different between the two files. (This feature is possible because comparing the MD4 hashes created by two files is far more efficient than comparing the actual contents of the files.)

File and subfolder filters. You can specify individual sub-folders or filenames that should not be included in DFS replication, either by explicitly listing the name of the file or folder or by using the * wildcard symbol. By default, DFS-R will not replicate any folder that begins with the tilde (~) character, as well as any files with a .TMP file extension.

The following files and file types will always be excluded from DFS Replication:

  • Any EFS-encrypted files.
  • Any file that has had the temporary attribute set.
  • Any reparse points used by Single Instance Storage or Hierarchical Storage Management. (The reparse points used by DFS itself are not affected by this.)
  • Any NTFS-mounted drive paths where you've added a new drive to a system and assigned its space as a folder within an existing drive letter, rather than assigning it a drive letter of its own.

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:

Dig Deeper on Windows Server storage management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.