Second Time Around

Windows Server 2003 R2 and the new DFS.

When Microsoft released Windows Server 2003 R2, more commonly referred to as simply "R2," it posed a challenge to IT managers. After all, the far-reaching release has created a storm of interest and confusion. With the much-anticipated Longhorn Server OS now at beta 2 and looming large in planner's minds, many IT managers struggle to place R2 in the context of the Windows Server release life cycle.

They needn't worry. Since 2003, Microsoft has worked to make its OS and software releases conform to predictable, two-year intervals. Two years after the initial shipment of a new product, an R2 release is scheduled to extend features, roll up bug and security fixes, and provide a fully updated foundation for new releases. Two years after that, according to the roadmap, a full-version release of the software is due.

"Windows Server Release Cycle" below shows the overall life cycle as Microsoft currently defines it. Thus, the next major release of Windows Server will be Longhorn, followed by Longhorn R2 two years later, and followed next by Blackcomb. There are currently R2 releases for System Management Server (SMS), Virtual Server, Small Business Server (SBS), and Windows Storage Server (WSS). Microsoft says all products should have an R2 release.

Windows Server Release Cycle
[Click on image for larger view.]
Windows Server Release Cycle

By definition, R2 releases are a big deal, but few are as big as Windows Server 2003 R2. In addition to an extensive set of feature upgrades affecting everything from storage management to Active Directory administration, IT managers will welcome the addition of powerful Windows SharePoint Services. But no single feature looms as large as the newly minted distributed file system and replication technology cooked into R2.

Touring R2
No doubt about it, Windows Server 2003 R2 is a significant release. This version has a large number of product add-ons that greatly expand the reach of the original Windows 2003 Server OS. It offers IT managers ample reason to consider an upgrade ahead of the long-awaited Longhorn Server OS.

In fact, when I first installed R2, the long list of add-ons reminded me of the old Windows NT 4 Option Pack, which at the time combined product add-ons such as Routing and Remote Access Services and Terminal Services. With Windows Server 2003 R2, IT managers will encounter an impressive list of add-ons, including:

  • Active Directory Application Mode (ADAM)
  • Identity Management for Unix (NIS)
  • Active Directory Federation Services (ADFS)
  • Distributed File System (DFS)
  • DFS Management
  • DFS Replication Service (DFSR)
  • DFS Replication Diagnostic and Configuration Tools
  • File Server Management
  • File Server Resource Manager
  • Hardware Management
  • Print Management Component
  • Storage Manager for SANs
  • Microsoft Services for NFS (formerly included in Services for Unix)
  • Subsystem for Unix-based Applications
  • Windows SharePoint Services

Many of these add-ons were separate downloads from Microsoft, others are completely new, and some have morphed from existing products. Note that Services for Unix (SFU) has now been wrapped into the R2 components.

The all new DFS
[Click on image for larger view.]
Figure 1. The new Distributed File System component is selected for installation.

From a licensing standpoint, R2 is included with the Software Assurance (SA) or the Enterprise Agreement (EA) license. If you don't have either the SA or EA agreements, you can purchase R2 as a new server license. There are no new Client Access Licenses (CALs) for R2 because it uses the Windows Server 2003 CAL. R2 shares a support lifecycle with Windows Server 2003, which is scheduled to sunset in 2013.

Migration Walk Through

Let's say we have an existing DFS Namespace called SalesData that is hosted on Windows Server 2003 servers. After the R2 upgrade, we can open the Distributed File System snap-in and still see and manage that namespace -- there's nothing to install or change. If we want to take advantage of the new DFSR in R2, how do we migrate the data from the old namespace to the new?

It's simple. Let's say the namespace SalesData is hosted on four Windows Server 2003 servers, named SRV1, SRV2, SRV3, and SRV4. The migration steps are as follows:

  1. Upgrade each server to Windows Server 2003 R2, and then install Distributed File System via the Add or Remove Programs interface. R2 supports FRS and the legacy DFS namespace, so the existing DFS structure will continue to work as it did before the R2 upgrade.
  2. Once the servers are upgraded to R2 and the R2 DFS, open the DFS Management snap-in on one server and add the existing SalesData namespace. The namespace will be displayed in the snap-in. There is no need to reconfigure the namespace unless you want to add new servers.
  3. At this point you need to configure the replication. There is a very intelligent wizard that guides you through this part. While I've been able to follow the prompts to a successful configuration, you should of course test your configuration in your lab first, to ensure that the setup will meet your requirements.

That's it! You're now using the new DFS for namespace and replication. Again, this does not affect SYSVOL, as it will continue to use FRS. -- G.O.

It's worth noting that R2 is not a required update, it's entirely optional. Because service packs and hot fixes are compatible between Windows Server 2003 and R2, there's no compelling maintenance reason to commit to or avoid an upgrade. Down the road, you'll be able to upgrade to Longhorn Server from either Windows Server 2003 or R2 when the next-generation server OS is released, probably in the second half of 2007.

Installing R2 is a straightforward process. The software comes as a two-CD set. The first CD is simply Windows Server 2003 plus Service Pack 1, which enables IT shops to quickly bring their machines up to grade to support the move to R2. If your systems are already at Windows Server 2003 SP1, you can ignore the first CD and simply install from the second CD.

The second CD contains all the components previously listed, adding them to the Windows Components displayed in the Add or Remove Programs area of the Control Panel. These are not installed by default, however. You need to open Add or Remove Programs and click Windows Components to see the components made available by the R2 setup. Check the components you want installed, as you would for any other component (see Figure 1).

The New DFS
For all the new features in R2, one stands out from the crowd: the new Distributed File System (DFS). DFS has been widely used in Windows environments to provide an orderly namespace, as well as redundant file resources. However, the replication engine behind this functionality, called the File Replication Service (FRS), has been fraught with problems since its inception in Windows 2000. FRS has staggered from hotfix to hotfix and is a more stable technology today, but it remains far from reliable.

With the R2 release of Windows Server 2003, it appears Microsoft has decided to start from scratch. Using a completely new approach, it re-wrote the replication engine from the ground up. There's no connection at all to the old FRS.

The confusing part of this is that the new replication engine named DFS or, as it is sometimes called, DFSR, only replicates DFS namespace data. The old FRS is still used to replicate SYSVOL, because Microsoft didn't have time to incorporate DFSR for replicating SYSVOL under R2. Of course, FRS is also used to replicate DFS namespaces built in Windows 2000 and 2003, because the new replication engine is not available in those older operating systems.

Clear as mud, right? Perhaps the best way to explain the DFS, DFSR and FRS relationship is with a quick summary of key points. We can then dig in a little deeper with some examples:

  • R2 DFS/DFSR is installed as a Windows component
  • FRS is the old replication service and is still used to replicate SYSVOL data in R2
  • FRS is also used in R2 to replicate legacy (Windows 2000 and 2003) DFS namespaces
  • DFSR is a much more efficient replication engine than the legacy FRS
  • The Legacy DFS and new R2-based DFS use different replication topologies
  • DFSR will be used to replicate SYSVOL data beginning with Longhorn
Keep in Mind:

Installation of the R2-based DFS component modifies the Active Directory schema. Make sure you use proper change control procedures before installing the component.

As indicated in this list, nothing has changed with respect to SYSVOL data. FRS replicated this data in Windows 2000 and 2003, and continues to replicate it in Windows Server 2003 R2. In addition, for compatibility purposes, R2 supports DFS namespaces built in Windows 2000 and 2003 by using FRS for replication. So if you upgrade a Windows Server 2003 DFS server to R2, the DFS functionality and management will still be the same and work as it did prior to the upgrade to R2. FRS will still be used to replicate this legacy DFS data.

Upgrading to the new DFS is simple. Once the second CD of the R2 installation media is installed, the Distributed File System shows up as a Windows Component in Add or Remove Programs under the Control Panel. Just check the box and install it as you would any other component.

Technology Change Up
Moving up to R2 doesn't replace the old replication engine with the new one. Rather, the legacy DFS and R2 DFS replication topologies exist side by side, as independent services for specific missions. Each DFS is managed by its respective snap-in, with the legacy DFS from Windows 2000 and 2003 being managed by the Distributed File System snap in, just as it was prior to the upgrade. The R2 DFS, meanwhile, is managed and configured by the DFS Management snap-in, which is created when you install R2 DFS.

With the R2 release of Windows Server 2003, it appears Microsoft has decided to start from scratch. Using a completely new approach, it re-wrote the replication engine from the ground up.

The new R2 DFS brings plenty of benefits in large part because Microsoft built the new DFSR replication engine from scratch. The crown jewel of the new DFS is definitely a technology called Remote Differential Compression (RDC). RDC allows only the changed bytes in a file to be replicated, as opposed to sending the whole file. The result is vastly reduced bandwidth requirements.

For instance, if I change the title on one slide in a 3.5MB PowerPoint file, FRS would have to send the entire file. DFSR only sends the bits reflecting the change to the title text. According to Microsoft, this can slash the amount of data transferred from 3.5MB to just 16KB. On a standard DSL connection, the time to transfer data reflecting the edit drops from over a minute for the entire file to less than a second for the 16KB of changed bits. Extrapolate that to hundreds or thousands of files that exist in some DFS environments, and you get a sense of the impact this improvement can have.

DFSR also fixes a long-running nuisance of DFS -- namely, the difficulty it had replicating data that changed frequently. While some shops got around the limitation by deploying more bandwidth, this brute-force solution was both expensive and tricky to manage. For example, IT managers had to specifically set aside the bandwidth for DFS replication rather than other tasks. With RDC in R2, you can replicate dynamic data extremely efficiently using much less bandwidth.

Easy as 1-2-3!
[Click on image for larger view.]
Figure 2. The new Distributed File System (DFS) uses common-sense terminology to describe replication processes.

One of the more welcome advancements in the replication space with R2 has more to do with vocabulary than technology. The new DFS eliminates ill-defined terms like Link, Target, Root and Root Replica, which made little sense to anyone who didn't use DFS on a regular basis. The new management tool, shown in Figure 2, uses common-sense terms like "Sending Member," "Receiving Member," "Sending Site," "Receiving Site" and "Schedule Topology," along with the connection status.

There isn't space here to print all the features and details about DFS under R2, but believe me it's easy and intuitive to manage. Remember that DFS now is an umbrella term that refers to namespaces and replication. I recommend highly that you move to the new DFS. If you use DFS now and are debating about whether to upgrade to R2, this would be excellent justification.


comments powered by Disqus

Subscribe on YouTube