What’s So Great About R2? FRS! Kind of ...

I’ve been playing with Windows Server 2003 Release 2 (R2) off and on for the past year, and I've definitely found some things to like about Microsoft’s latest incarnation of its server OS. No, R2 hasn’t gotten much respect—particularly from people like me, who have been disappointed by the number of the features pulled from it for the sake of Longhorn Server—but that lack of respect might not be entirely fair when you consider one fact: R2 isn't the most minor Windows Server upgrade. Ah, but which version of Windows Server was the smallest upgrade?

Time’s up. The answer is Windows NT Server 3.51. Remember? I think its primary new feature was PC Card support. So, obviously, R2—with its dozen-plus new features—offers a bit more than that. However, this bit of good news is leavened by the fact that NT 3.51 appeared in the era in which we saw a new version of Windows Server every year, as well as the knowledge that R2 won't get the full period of support that Microsoft will offer Windows 2003. Microsoft’s new plan is to release a “big” version of Windows Server every 4 years, with minor R2 releases 2 years later, but to support both the “big” version and the R2 version for the same period of time.

Regardless of whether R2 is a good deal, one of its most interesting features is a new version of the Distributed File System (DFS) or, more accurately, a completely rebuilt version of the software that makes DFS possible—the File Replication Service (FRS). As you might know, one of DFS’s nice features is the notion of replicas. Here’s how they work. Suppose you’ve created a file share containing human resources (HR) data that you want everyone in your firm to be able to access. You have 10 locations and good (but not great) connectivity between those locations. You’d like to have a copy of that HR share at every location.

To accomplish your goal, you could create 10 shares on 10 separate servers. You would then tell the people in the Kempsville office that, to access the HR data, they need to go to \kempsvserverhrdata. And you would tell the folks in the Olney office to go to \olneyserverhrdata. And so on. Then, you’d have to create the original share on some server somewhere, put the HR data in it, and create nine other shares, and copy the HR data to those shares. And, of course, whenever things changed, you’d have to make those changes in one share, and copy the changes to the other nine shares. Ugh.

With DFS, which has been around since Windows 2000, you could first create the DFS root—something that looks like a share but is actually a kind of index of file shares. Then you would put the HR data share into the DFS root. Next, you would access the DFS root as you would any other share, and you would see a folder inside it. But that’s not a real folder, although it looks like one; instead, it’s a shortcut to the HR share, which could be on another system.

Even better, you could then “publish” the share in Active Directory (AD), which would let you refer to a file share not by its file name (e.g., \kempsvserver) but by its AD name (e.g., \myfirm.biz). That’s nice, because if you ever decommission the server that holds the HR data share and put the share somewhere else, people will have to learn that share’s new name. For example, say the old server’s name was \kempsvsvr, and the new one is \kemps2. If people previously referred to \kempsvsvrhrdata, now they’ve got to learn to use \kemps2hrdata to get to the share. In contract, you simply refer to an AD-published share as something like \myfirm.bizhrdata. Because there's no server named myfirm.biz, your system knows to take the extra step to find the actual server’s name in AD. That way, when the server’s name changes, the administrator needs only to inform AD about the change. To the use, it’s still just \myfirm.biz.

So far, so good. But it gets better. Now that you have that HR share running on one server, you tell DFS to create nine more replicas (in DFS terminology). Under your direction, DFS then puts copies of that HR file share on nine other servers of your choosing. It handles all the copying and keeps each copy in sync with the others—very nice. Even nicer, the end user doesn’t see 10 separate shares, nor does he or she have to choose between them. Nope, instead, AD offers the user just one share, with a name such as \myfirm.bizhrdata. When the user opens it, DFS uses AD's site-awareness information to pick the share that is closest to the user, connectivity-wise.

Again, this functionality has been around since Win2K, but many folks don’t use it. Or, rather, they don’t think they use it. In fact, however, every domain has at least one of these multiple-replica, site-aware, automatically synchronized DFS shares—Sysvol. The Sysvol share that you’re probably familiar with on every domain controller (DC) in your domain is site-aware, in that you get your logon scripts from the nearest DC rather than some random DC. It's synchronized, so if you modify a file in a Sysvol share on any DC, it will soon appear in that modified form on all other Sysvol shares on all other DCs.

So, what’s new about R2? Thus far, I’ve painted a somewhat unrealistically rosy picture of DFS and Sysvol. All that synchronizing between replicas requires some thinking, and the program that does that thinking is the FRS. The FRS has a tough job to do, and, sometimes it doesn’t do it so well, particularly across WAN links. R2’s version of the FRS fixes that.

First, there’s Remote Differential Compression (RDC). Suppose you have a 50MB file on a DFS share in Kempsville, and you change one byte in that file. Olney needs to know about the change, so FRS replicates the file. The whole file. All 50MB of the file. And over a slow or unreliable WAN link, FRS can get so confused that it simply stops working. With RDC in R2’s FRS, however, FRS just replicates the changes—in other words, just the one byte. This solution is less WAN-unfriendly and more manageable in data size.

Second, wouldn't it be helfpul to be able to tell FRS, “Yes, we have 10 offices, but I really only want Kempsville to communicate with the rest of the sites via Olney.” Doing that isn't easy with Windows 2003's or Win2K's FRS. With R2’s FRS, however, you can specify FRS replication partners by creating what it calls a replication group. But what if that link between Kempsville and Olney is a bit slow, and you don’t want FRS’s traffic to swamp that WAN link? R2’s FRS lets you throttle the amount of bandwidth that FRS uses on any given link, and you can schedule when FRS is allowed to use that link.

Third, remember what I said earlier, that to get this whole thing started we needed to first create that HR data share and copy it to the other nine offices? Again, WAN constraints might make that painful. R2’s FRS, however, just lets you pop all that HR data on a tape, DVD, or USB hard disk, take the media physically to the branch office, and create the initial replica from that media locally—so there are no WAN hits. Once you've set up the replica, from that point on, it gets subsequent updates over the WAN via FRS. Best of all, despite the new FRS’s greater robust design, a bunch of DFS replicas could get out of whack. That’s why the new FRS has self-healing algorithms built into it.

Can’t wait to see its benefits? I was too, until I found out that the new FRS comes with a nearly inexplicable catch. Recall that the single most popular use of FRS isn't for homemade DFS roots with replicas, but instead for the DFS share built into every DC—Sysvol. FRS’s current constraints are the reason that AD implementations face far more failures from Sysvol and FRS troubles than from the Extensible Storage Engine (ESE), the database that drives AD. So I was pretty excited to hear about R2. But what, I wondered, would happen with domains that consisted of a mixture of DCs based on Windows 2003 R2, Windows 2003, and Win2K? Would we get the benefits of the new Sysvol or not?

To find out, I attended one of Microsoft’s online talks during the R2 beta. In these online talks, you can type in questions and get immediate answers, and most of the events are pretty good. But when I asked about the Sysvol problem, the question was ignored, which was odd, because any attendee can see all the questions being asked, and it seemed that mine was the only one unanswered. No problem, I thought, I'll just ask it again. Silence. But as R2 was poised to ship, I finally got the story: R2’s Sysvol wouldn’t use the new DFS. Sure, it would appear in Longhorn, but not in R2.