Since Windows Server 2003 has been out for a while now, it has lost a bit of its luster in the eyes of the media, which has turned most of its attention toward the upcoming release of Longhorn.
What gets lost, however, is that Windows Server R2 is really a sneak peak into Longhorn, as all the new functions introduced in R2 will be available in the new operating system, including new Distributed File System components and DFSr.
The birth of DFSr
Perhaps the most significant of these features are the new Distributed File System components, including the new replication engine DFSr.
There is little doubt that File Replication Service (FRS) was poorly implemented in Windows 2000. Administrators literally lived from hotfix to hotfix trying to patch FRS to make it work. Windows Server 2003 made some significant changes to FRS in an attempt to make it more tolerant of error conditions, but there was still no real fix for anything. It's possible that Microsoft simply gave up trying to patch FRS, because it rewrote the replication engine from scratch with R2. Thus, through the use of better design criteria and years of FRS experience to temper the decisions, DFSr was born.
DFSr has several key features, but the most important one is, arguably, remote differential compression (RDC). RDC replicates changes to a file, rather than the entire file itself as FRS did. For example, if I had a 3 MB Word document, and you edited a couple of lines, FRS would replicate the entire 3 MB file. RDC, on the other hand, replicates only the changes -- in this case, just a few bytes. Therefore, instead of taking several minutes for FRS to replicate this change, DFSr will replicate it in a few seconds (depending on the network speed).
Unfortunately, Microsoft only had time to add DFSr to replicate DFS data, and not the System Volume (SYSVOL), so SYSVOL still uses FRS for replication.
Migrating to R2/DFS
Migrating an existing Windows 2000 or 2003 Distributed File System structure to the DFS configuration couldn't be easier. Here is what you need to know:
- Upgrade DFS servers to R2. You don't need to upgrade all servers to R2 -- just the ones hosting the DFS namespace you want to migrate to R2.
- Note that installation of R2 requires a schema upgrade, so plan for that.
- Even after the R2 upgrade, your DFS namespace has not changed to the new R2 DFS namespace. You can still use the old DFS admin tool. Nothing has changed for DFS.
- After the R2 upgrade, you need to go into Add/Remove Programs, open Windows Components and install DFS, just like you would any other component, such as DNS for instance. Even after installing DFS, you'll still be using the old DFS namespace and FRS for replication.
- These steps must be performed on all servers that host or will host the DFS namespace.
- Once the R2 upgrade and DFS installation have been completed, it's time to migrate the old DFS namespace into the new DFS and configure DFSr replication.
To do this, open the new DFS management tool and you'll see the Namespaces and Replication icons in the left pane. Right-click on Namespaces and select Namespaces to Display. Just like the old DFS snap-in, it will then display all the defined namespaces, as shown in Figure 1. This is similar to what you would do prior to R2 to add an existing DFS namespace in the domain to the DFS snap-in. It will show all existing namespaces -- just select one to load it into the new snap-in.
7. Right click on Replication in the left-hand pane and select Replication Wizard. This wizard is extremely easy to use. There is no need to read white papers to figure out what a link, target, link target or root target is. I was able to configure replication without reading any help files, calling Microsoft Support or asking anyone else for help. This is especially true if you have previous DFS experience. Choose the replication configuration you want and complete the wizard. Figure 2 is a summary of the replication selected.
8. That's it! You have just moved your DFS structure to the new R2 environment, including using the DFSr replication.
Now that you are using the new Distributed File System, you will be able to note several new features right away, including:
- Better replication performance using DFSr.
- New options in configuring replication. As shown in Figure 3, there is the Data Collection option, which is used for replicating data from branch sites to a hub site. The other is the "Multi-purpose Replication group," which is for normal DFS sharing.
Easy to understand terminology. Just click on the name space and look in the upper-center pane.
I saw one situation where DFS had been constructed masterfully to back up data from the 100 branch sites to one of two servers in a hub site. To do that, the admins built a server for DFS in each of the branch offices. Using Windows 2003 DFS, they created links for each branch office with only one of two hub servers, as shown in Figure 4.
Each link had only two target servers -- one in the branch site and one in the hub site. This was done to take advantage of Microsoft's philosophy of branch office design. That is, replicate the data to the hub site and back up the hub.
However, the administrator reported a performance problem on one site that had a 62 GB share size, which is close to Microsoft's recommended maximum of 65 GB. When I recommended that they move to R2, they objected, saying they couldn't afford to upgrade all of the machines. My recommendation was to add an additional server at the remote site, add a DFS share to the new server and split the load between the servers. The next step would be to upgrade those two resources (site DFS servers in the remote site) to R2, and upgrade the hub server they connect to via DFS.
In this example, we would have also had to create a new namespace with the R2 servers. We could remove that link from the old DFS snap-in and create a new namespace in R2, then configure replication using R2's Data Collection mode. This would provide the benefits of R2 to a problematic site without having to do the upgrade on all servers.
The DFS functionality in the Windows Server 2003 R2 release has some powerful benefits that improve performance of DFS replication -- benefits that will also be included when Microsoft releases Longhorn. The really good news is that Longhorn will improve on this by using the DFSr replication engine to replicate SYSVOL as well.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Windows Server-File Systems.