About a year and a half ago, I was visiting the Microsoft
for the MVP Global Summit. During the summit, one of the speakers told the
attendees that Microsoft was working on a new version of Windows Server 2003
that was so top secret, that he couldn’t even tell us its name. He then went on
to tell the audience in his best
us by the letter “R” and the number “2”. Of course, he was
talking about the now widely publicized Windows Server 2003 R2. R2 hasn’t
actually been released yet, but I received an E-mail this morning indicating
that Release Candidate 1 was now available
for download. Since R2 has moved into the Release Candidate stages of
testing, now seems like an appropriate time to bring you up to speed on the
various features in R2.
What is R2 not?
The first thing that I want to say about R2 is that R2 is
not a service pack. I have seen a few Web sites referring to R2 as Windows
Server 2003 Service Pack 2. This is not the case though. R2 is not a service
pack, but rather a re-release of the Windows Server 2003 operating system.
Although Microsoft has never done anything like this before, Microsoft’s long
term road map for Windows Server operating systems has them alternating between
major releases (such as the original Windows Server 2003 and Windows Vista
Server) and minor releases such as R2. If Microsoft sticks with this roadmap,
then in about two and a half years, we should be seeing an R2 release of
Windows Vista Server.
Ok, so what is R2?
On the surface, R2 is a roll up of the original Windows
Server 2003 code, Service Pack 1, and the various feature packs that have been
released for Windows Server 2003. In fact, according to Microsoft, when Service
Pack 2 is eventually released for Windows Server 2003, the service pack will be
valid for both the original release of Windows Server 2003 and for R2.
If R2 is basically a rollup of Service Pack 1 and some
feature packs, you might be wondering why anyone would bother upgrading to R2?
Well, there are actually quite a few new features that we will see for the
first time in R2. A lot of these features will eventually make their way into
Windows Vista as well. According to Microsoft, if you believe that your
organization would benefit from some of these new features, then you should
upgrade to R2. If the new features don’t really do anything to help your
organization, then you are just as well off with Windows Server 2003. R2 is
nothing more than a supplemented version of Windows Server 2003 with Service
Pack 1 after all.
New Features in R2
R2 contains dozens of features, some major and some minor. For
the purposes of this article, I am going to talk primarily about the major
features and ignore most of the minor improvements. An example of a minor
feature is a revised Microsoft Management Console that eliminates the need to
Active Directory Federation Service
Probably the one component of R2 that has received the most
press is the Active Directory Federation Service. Quite frankly, Active
Directory Federation Service is a huge topic, and there is no way that I can possibly
do it justice within this article. What I can tell you though is that Active
Directory Federation Service extends the Active Directory to the Web.
We have all seen Web applications that are linked to a
backend SQL database or to some other secure backend resource. In the past, if
you wanted to make these types of resources available through a Web application
in a secure manner, you had to either create Active Directory accounts for
everyone who was going to be using the application, or you had to build some
kind of proprietary authentication mechanism into the application.
Either way, you had to manage accounts for everyone who was
going to use the resource. This is fine if the people who need access work for
your company. However, if you have suppliers or partner organizations that need
to provide access to a large number of their own employees, then management can
quickly become a nightmare. You will likely find yourself creating and managing
accounts for people who don’t even work for your company.
This is where the Active Directory Federation Service comes
in. The Active Directory Federation Service allows you to extend an external
trust to a Web application. This means that if you have a supplier who needs
access to your Web application, you can create a simple trust relationship with
your supplier and then shift the burden of managing the external accounts to
Improved interoperability with UNIX and Linux
If you have UNIX or Linux machines in your organization,
then you will probably really benefit from improvements in the way that Windows
is able to interact with UNIX and Linux networks. Specifically, there are three
new Services for UNIX components.
The first of these new components is called Subsystem for
Unix Based Applications, or SUA for short. This sounds like a mouthful, but SUA
is an extremely handy component. It allows you to compile UNIX / Linux
applications natively on a Windows Server without the need for an emulator!
Another long overdue component is the Microsoft Services for
Network File System (MSNFS). MSNFS allows UNIX / Linux clients to use NFS to
connect to shares on a Windows Server. Granted, UNIX / Linux users can already
do this through SAMBA, but the nice thing about MSNFS is that it is native to
Windows and it eliminates the need for SAMBA.
The third component is Identity Management for UNIX (IDMU).
IDMU allows an R2 based domain controller to spoof a UNIX Network Information
Service (NIS) server. This allows a Windows domain controller to authenticate
UNIX / LINUX clients.
When Microsoft released Windows 2000 Server, they introduced
quotas for the first time. Unfortunately, quotas could only be applied at the
volume level though and Windows 2000 relied solely on file ownership for quota
calculation. Needless to say, quotas had a lot of shortcomings in Windows 2000
Server, but it was a step in the right direction. The problem is that when
Microsoft released Windows Server 2003, they really didn’t do much to improve
upon the existing quota functionality.
All that has changed in R2. In R2, the quota management system
gets a major overhaul. In R2, quotas can be applied at the folder level, not
just at the volume level. Furthermore, you can do things like apply a quota
across a set of folders. You can even structure the quota so that Windows does
not allow a folder to grow beyond a certain size, regardless of who owns the
files within the folder.
Another new feature is the AutoQuota function. AutoQuota is
primarily intended for the user’s home folders. The idea is that you can set an
automatic quota at the top level folder, and the quota will then apply to each
individual user’s folder. You can even set threshold values at which the size
of a user’s folder will trigger a nasty E-mail warning message or an
Although not technically quota related, Microsoft provides
us with yet another way to keep hard disks from filling up in R2. You can now
restrict folder content by file type. For example, imagine that in the past you
have had problems with users storing their collection of MP3 files on your servers.
In R2, you can actually configure Windows so that MP3 files are forbidden in
certain folders. The only problem is that the technology is based solely on
file extension, and it won’t stop a savvy user from renaming the file
extension. However, if a user goes through the trouble of renaming a file
extension, then the user has taken premeditated steps to circumvent a corporate
policy, and you have a good chance of being able to take action against that
user if that’s the course of action that you want to take.
As if all of these improvements in quota management (and
file system management in general) aren’t enough, R2 features a really nice
collection of reports. You can generate reports showing file sizes, file
owners, most frequently used files, least frequently used files, duplicate
files, and just about anything else that you can imagine.
SAN and NAS
SAN and NAS technologies weren’t nearly as common when
Windows Server 2003 was initially released as they are today. In an effort to
prevent Windows Server from becoming dated, Microsoft has built some additional
SAN and NAS capabilities into R2.
Assuming that your vendor supports it (most should
eventually), you will be able to add R2 to any NAS Server that’s running
Windows Storage Server 2003. By doing so, you can extend R2’s quota management
features to your NAS devices.
Microsoft has also implemented SAN management into R2.
Assuming that your SAN solution supports the Windows Virtual Disk Service, you
will be able to use a built in snap-in for Microsoft Management Console to
manage a SAN. You will be able to use this snap-in to get a full view of your
storage system. Additionally, you can assign and unassign, create, and extend
logical unit numbers as needed.
Distributed File System
Windows has supported Distributed File Systems for many
years now. The original idea behind a distributed file system was that you
could group multiple network shares beneath a single share point so that you
can make it easier for users to locate network resources. DFS also supports
data replication, and is useful for implementing fault tolerance and load
In my opinion, DFS is one of the best features in Windows
Server 2003. I personally use DFS religiously. As great as the existing DFS
service is, Microsoft has made it even better in R2.
The first thing that Microsoft did to improve DFS is to
completely revise the Distributed File System management console. The old
console worked flawlessly, but it could be a little confusing for newbies, and
it didn’t scale very well to enterprise class DFS trees. The new Distributed
File System management console is designed to be easier to use and more
The new console is nice, but it’s minor in the scope of
other improvements that have been made to DFS. One of the best improvements has
to do with efficiency. As I mentioned before, a DFS tree can contain links to
shares on many different servers. Furthermore, when you create a DFS replica,
you can have replicas of your data spread across even more servers.
The way that DFS currently works is that when a user
accesses a DFS virtual root, they are taken to a pre-assigned replica in a
round robin fashion. In R2 this changes though. Now, when a user accesses a DFS
virtual root, Windows looks at the user’s Active Directory site, and routes the
user to a DFS replica that is in the user’s current site if possible. The
previous version of DFS did not take site information into account.
There have also been huge improvements in the way that DFS
replication works. Previously, DFS relied on the NT File Replication Service
(NTFRS). Unfortunately, NTFRS wasn’t really practical in large organizations
though. It tends to have trouble keeping pace when large files or large numbers
of files are replicated. If replication falls too far behind, NTFRS has been
known to fail catastrophically, forcing replicas to be completely rebuilt.
In R2, the DFS file replication engine has been completely
redesigned. It now handles large files and large numbers of files with no
problems. Although I have not been able to confirm it with Microsoft, I have
heard that the new file replication engine is designed so that when a file is
modified, only the bytes that have been modified are replicated rather than DFS
having to replicate the entire file. This goes a long way toward improving DFS’s
Currently, R2 is still in the Release Candidate stages of
testing. Once R2 is released however, anyone who buys a copy of Windows Server
2003 will automatically get R2. If you are a Microsoft Premier or a Software
Assurance Customer, then you should automatically receive R2.
For those who purchased Windows Server 2003 through standard
retail sources or through a volume license agreement, there is going to be an
upgrade charge for R2. At the present time I do not have pricing information
though. What I can tell you is that you won’t have to buy any additional client
access licenses nor will you have to upgrade your existing client access
licenses when you upgrade to R2.