Previously, I authored a couple of articles in this space regarding troubleshooting the File Replication Service...
(FRS). I thought it would be appropriate, therefore, to give a few pointers on the new replication engine for the Distributed File System (DFS) that is now available in the R2 release of Windows 2003. R2 is an interim or "upgrade" release of Windows 2003. It is an optional upgrade, but has some very nice features such as the new DFS. Look here for more details on R2.
Before we continue this discussion, it is important to note that "DFS" previously referred to shares and namespace management. Beginning with the Windows Sever 2003 R2 release, "DFS" is an umbrella term that refers to both namespaces and replication. The term "DFSR", at lease as it is used at this time, refers to the new replication engine.
FRS is used to replicate SYSVOL content (Group Policy) as well as DFS data which is defined and configured by the System Administrator. After years of trying to patch the very problematic FRS, Microsoft made an important strategic move and started from scratch to build a more efficient, reliable replication engine to replace FRS. They added a new DFS component in the Windows Server 2003 release of R2 that uses DFSR for replication of DFS folders. This new engine, called DFSR (Distributed File System Replication), is used in R2 for replicating DFS Namespace data. Unfortunately they didn't get time to implement it for SYSVOL replication, but it will be implemented for SYSVOL in the Longhorn release of Windows.
The only bad thing about DFSR is its name. It makes it very confusing to refer to the replication engine that has the same name (DFS) as the namespace. So there is an old DFS, a new DFS with DFSR and a new management console. However, once you dig into the new console, it is easy to distinguish them.
DFS Management Console
One of the hardest things about DFS has been figuring out the terminology. Terms like DFS root, root target, root replica, link, link target, etc. are not intuitive and are difficult to understand. The new management console is much more simplistic. Figure 1 shows the new console. Note the left column shows two items: Namespace and Replication. Wow -- terms that actually make sense! You can see the namespaces defined (formerly known as DFS Roots) under Namespaces, and under Replication, you see the folders replicated (formerly known as Links). In Figure 1 you can also see the servers that host this namespace (formerly known as Root Targets or replicas).
There is a cool replication wizard that lets you configure the replication with common sense terms, and you can monitor the replication status all within this console. This is shown at least in part in Figure 2 where we can see the properties of the replicated folder, DATA. Note the tabs:
- Memberships -- List of all servers replicating this folder (formerly known as Link targets) along with the path of the folder, if replication is enabled or disabled on that member, and the staging quota size
- Connections -- Data about replication (who is the sending member, who is the receiving member, their respective sites, etc.)
- Replicated Folders -- The name of the replicated folder, publication status and namespace path
- Delegation -- Security (who has permissions to the folder and how it was granted)
Interoperability between W2K3 and W2k3/R2 DFS
It should be fairly obvious that with a new DFS replication engine, namespaces can only use one or the other -- not both. Even with the new DFS installed, you can still use FRS to replicate DFS data just like you always did. Note in Figure 3, if you look in Administrative Tools, you'll see the old DFS Management snap-in, called Distributed File System in the tools list, as well as the new R2 console, called DFS Management. Simply use DFS Management to configure with the DFSR replication engine, and use Distributed File System snap-in (the old one) to use FRS.
For example, let's say you have five Windows 2003 SP1 DFS servers hosting a folder called Documents. You want to start upgrading them to R2 and eventually use the new DFS. You can upgrade them at whatever schedule you see fit and just not change anything. They will still replicate using FRS under the old definitions. Once they are all upgraded, install DFS from the Windows Components under Control Panel \ Add-Remove Programs on each one. Open up the new DFS Management console and add the namespace just like you did in the old snap-in. No need to reconfigure the namespace. Just right click on the Replication option in the left panel of the console and answer the wizard's questions to configure replication.
NOTE: It is possible -- thought not recommended -- to have two different replication topologies for a single namespace, but on different servers. Suppose in the previous scenario you upgrade servers S1, S2 and S3 but it will be a while before you can upgrade S4 and S5 and you want to try out the new DFS. So you install the new DFS on S1, S2 and S3, then go into the new DFS Management snap-in on S1 and configure replication for the Documents folder for S1, S2 and S3. You now have a split brain replication. S1, S2 and S3 will replicate their Documents folder with each other and S4 and S5 will replicate their documents folder between themselves. However, if you add files to the directory on S4, it won't replicate to S1 and vise-versa. The problems here are obvious. The recommendation then, is to replicate folders with like data in either the old DFS or the new DFSR, but not both. Be careful during migration to plan your move and not have this happen.
I ran through the wizard and configured replication topology for a folder. It was very easy, very intuitive and it didn't use the words Root, Replica, link or target once. I highly recommend you migrate to the new DFS to take advantage of these features as well as the new "Remote Differential Compression" which allows sending only the changes made to a file rather than the whole file -- a huge improvement in performance and reduction of network load.
There are many other reasons you'll like the new DFS that we'll discuss in future articles. Check out the FAQ and the other information on the Microsoft web site noted at the start of this article.
Try it -- you'll like it!
More tips from Gary Olsen:
- Large group membership can cause authentication failure
- Getting more FRS debug help from FRSDiag
- Debugging NTFRS using FRSDiag and the Propagation File Tracer
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.