Get in Sync with DFSR

Any administrator who manages a distributed network knows what a pain it is to distribute data around the network to where it's needed and keep it all in sync. Historically, data distribution hasn't been a strong point of Windows: Most administrators use the old Robocopy utility to do their replication and synchronization work because the built-in File Replication Service (FRS) just isn't up to the task.

Robocopy works great, but it's just a simple command-line utility with limited features. Now, you have a better alternative. One of the coolest new features of Windows Server 2003 Release 2 (R2) is DFS Replication (DFSR). DFSR is a complete reworking of FRS, with none of the limitations of its predecessor. Using DFSR with R2's improved DFS (now called DFS Namespaces), it's really easy to set up a replicated, fault-tolerant data-publication system.

The Basics of DFS and DFSR
DFS is a utility that abstracts Universal Naming Convention (UNC) names into a folder hierarchy using names you choose. For example, you can take a collection of shares such as \\flaserver1\reports, \\tx-server4\reports, and \\caserver2\reports and create a namespace out of it. A namespace is a virtual tree of folders that begins with \\ServerOrDomainName\RootName. In our example, the namespace would have a top-level folder named Reports and three subfolders: Florida, Texas, and California. Thanks to DFS, an employee looking for Texas reports could simply connect to \\domain\reports and click the Texas folder, instead of trying to remember which server the share resides on.

You can also use DFS to make data easily accessible by grouping it under a common UNC name, regardless of which server the data is stored on. DFS does this grouping when you map a DFS folder to multiple network shares (aka link targets) scattered in different locations. Because DFS is Active Directory (AD) site aware, a Windows XP or Windows 2000 client accessing a DFS folder will attempt to find the closest link target—a process Microsoft calls the data distribution scenario. (To learn about how DFS and AD integrate with each other, see the sidebar "How DFS and AD Work Together", page 34.) For the data distribution scenario to work properly, users must see the same files regardless of which link target they connect to, so all the network shares to which a folder is mapped must contain identical data.

DFSR is a multimaster replication engine used to distribute copies of data across multiple servers. It can run with or without DFS Namespaces, but its most popular use is to ensure that every member of a set of servers—a replica set—contains identical data and that replication is fast and bandwidth-efficient. It has many features, including bandwidth management, replication scheduling, and an innovative compression algorithm, that together dramatically decrease the amount of network bandwidth needed to keep data synchronized across your network. Microsoft reports that using DFSR results in up to a 300 percent improvement in the speed of large-file replication and 40 percent less administrative time spent managing the replication set.

A DFSR Scenario
Let's take a hypothetical software distribution system that uses DFS and FRS and rebuild it using DFS Namespaces and DFSR. HardwareTX is a small company with offices in Houston, Fort Worth, and Sweetwater, Texas. One of the services it provides to its clients is installing customized OS builds on notebooks, desktops, and servers. To support this service, the company has a software distribution system that keeps copies of CD-ROM and DVD ISO images at each office. When a build needs to be updated, the home office in Houston changes the master copy, creates a new image of it, and copies the image to the distribution system's local share at each location.

FRS keeps the network shares at the Fort Worth and Sweetwater branches synchronized. FRS is so troublesome, however, that Emily, the distribution system administrator, planned to use Robocopy instead. However, with the availability of Windows 2003 R2, she scrapped those plans and will use DFSR.

Prep Work
Before Emily can start using DFSR, her IT colleagues need to upgrade the company's AD schema to Windows 2003 R2 by running the Adprep utility. This schema upgrade, or extension, is necessary to support DFSR's required classes and attributes. (See the x86\setup\CMPNENTS\R2\ADPREP\SCH31.LDF file on the distribution media for more information about the schema changes.)

While she waits for the schema extension, Emily must upgrade her distribution servers to R2. If you're already running Windows 2003 and you've installed Service Pack 1 (SP1), you'll find R2 installation a snap. (For instructions on installing R2, see the Web-exclusive article "How do I install Windows Server 2003 R2 on a Windows 2003 Service Pack 1 installation?" March 2006, InstantDoc ID 49716.) Then, she needs to install DFS from the Windows Components section of the Add/Remove Programs Control Panel applet.

Like AD replication, DFSR is designed for a "read mostly" environment. Because the replication engine is loosely coupled, updates to a file on one member of a replica set don't lock that file on other members, nor are the updates transmitted immediately. Therefore, DFSR isn't suited for a highly active, update-rich system. You might work around this technical restriction by using business processes to restrict updates of a particular set of files to one replica member; file locking will then ensure that changes are made in a sustainable manner.

Namespace Considerations
After the schema and distribution servers are upgraded, Emily chooses to remove, restructure, and rebuild her DFS namespace to a simpler configuration than the current production version. She isn't required to rebuild her namespace; previous versions are compatible with R2 and can take advantage of new features when the participating servers are upgraded. Because she has to upgrade all of her servers, however, she takes advantage of this opportunity to restructure the DFS Namespace's logical configuration.

Before rebuilding her namespace on R2, she has to install the Microsoft Management Console (MMC) DFS Management snap-in. (If she's going to use the snap-in on a server other than the namespace servers—say, a management server—she first needs to upgrade that server to R2.) She goes to the Windows Components section of the Add/Remove Programs Control Panel applet, chooses Distributed File System, clicks the Details button, then selects the DFS Management and DFS Replication Diagnostic components and clicks OK.