Microsoft's follow-up to Windows Server 2003, cunningly titled Windows Server 2003 R2 (for "release 2"), will ship sometime in the coming months. Oddly enough, the product is right on schedule. The question is, does anyone care? I've seen precious little customer excitement around R2, despite the fact that it will completely replace Windows 2003 in the channel and offers several interesting new features.
Part of the problem, I suppose, is education. Microsoft hasn't done a good job of promoting R2, although I think I know why. This week, I examine a few R2 details you likely don't know about, both good and bad. If you're looking for more comprehensive R2 information, I'm preparing a lengthy review for the SuperSite for Windows. I'll give you a heads-up when that review is ready.
Part of R2's problem is that Microsoft has significantly scaled back the product since first planning it. Two major features have been removed from R2 and pushed back to the Longhorn Server feature set--and these features would have been the biggest reasons to upgrade. The first is a major revision to Windows 2003 Terminal Services, code-named Bear Paw, which would have provided remote application publishing without the need for complete remote OS environments. The second is Network Access Protection (NAP), which would have (finally) given Windows Server administrators a simple and practical way to implement network quarantine functionality. I wrote about these missing features--and the general R2 feature set--back in May 2005 (See the URL below).
Really Understanding R2
Microsoft likes to condense its product messages into easily digestible chunks of three bullet points or "pillars." For R2, these pillars are ill-named and inadequate at quickly describing the many new features the product actually provides. Microsoft calls them "branch management," "identity and access management," and "storage management." Excited yet?
The problem is that R2 actually contains a wide range of new features, many of which don't fit neatly into these simple categories. The branch-management features, for example, are really about overcoming the bandwidth limitations of dealing with managing remote servers. These features aren't just for branch offices--they're appropriate in any situation in which a server is located on the other side of a balky WAN link or in an office that has minimal or nonexistent IT support.
Also filed under this category is R2's support for Base Management Controller (BMC), an out-of-band server technology that lets administrators remotely access crucial server information, whether the machine is on or off. Servers with BMC support include a small dedicated processor that provides remote access to information you usually need to be on-site to get, including server temperature and fan speeds, and it also provides ways to remotely reboot and restart stalled servers. The ability to do this saves time and money and lets you avoid those awful long-distance calls in which an administrator tries to walk an onsite employee through various processes.
Finally, Microsoft used to sell a product called Windows Services for UNIX (SFU), which was built on the Interix code base and provided administrators with a way to run UNIX applications on Windows servers. Now, Windows SFU is provided to Windows Server licensees for free, and starting with R2, we'll see the company's new strategy for providing UNIX compatibility in Windows Server. In R2, you get something called the Subsystem for Unix Applications, which is essentially the runtime part of Windows SFU. However, you don't get most of the tools. Going forward, the runtime (which includes Network Information Service--NIS, password synchronization, and NFS administration capabilities) will be available only with future Windows Server versions. The tools, however, will always be made available as free downloads from the Microsoft Web site.
Consequently, any unique UNIX features in R2 won't be made available to users of previous Windows Server versions. Key among these unique features is the compatibility with Request for Comments (RFC) 2307, which describes a standardized method for implementing directory storage. RFC 2307 is a big deal in the UNIX world, and if your shop implements both Active Directory (AD) and UNIX-based directories, only R2 will provide the interoperability you need on the Windows side.
There's so much more, but I'm out of space and would like to tell you about some important Itanium news. So next week, I'll continue this exploration of little-known R2 facts and features.
Microsoft Defangs Longhorn Server for Itanium
In a move that will disappoint Itanium fans and customers, and likely push another nail into the Itanium's metaphorical coffin, Microsoft announced last week that it's seriously scaling back its support for Intel's most scalable processor. Although Microsoft still plans to ship a version of Longhorn Server for the Itanium in 2007, that version won't include all the features and functionality of the mainstream x86 and x64 versions of Longhorn Server. Instead, the Itanium version will be tuned specifically for database workloads and custom and line of business (LOB) applications.
Take a second to fully understand the ramifications of that decision. Despite recent signs of an Itanium resurgence, Microsoft has decided that servers based on this microprocessor will be relegated to niche workloads and will therefore never reach a mass market. Intel is a big enough partner that Microsoft can't simply cancel Itanium product development--yet. But the software giant is clearly sending a message. Although Itanium is the only platform on which some of the most scalable and demanding workloads will run in the near future, the Itanium, effectively, has no long-term future, according to Microsoft. My guess is that future Windows Server versions, starting with Blackcomb in 2011, won't support Itanium at all. By that time, servers based on the x64 will likely have surpassed Itanium from a performance and scalability perspective.
Microsoft Ships R2 Public Beta: Should You Bother?