Make no bones about it: Server 2008 R2 is really Windows Server 7

Make no bones about it: Server 2008 R2 is really Windows Server 7

Summary: Whether you call it Windows Server 2008 R2 or Windows Server 7, there's no doubt that this is a major Server product release for Microsoft.While the Windows 7 Release Candidate is getting all the attention this week, I thought I might bring some focus on the Client OS's bigger brother -- Windows Server 2008 R2 , which also reached its Release Candidate milestone today.


Windows Server 2008 R2 Desktop File Manager

Whether you call it Windows Server 2008 R2 or Windows Server 7, there's no doubt that this is a major Server product release for Microsoft.

While the Windows 7 Release Candidate is getting all the attention this week, I thought I might bring some focus on the Client OS's bigger brother -- Windows Server 2008 R2 , which also reached its Release Candidate milestone today. Despite the "2008 R2" moniker, make no bones about it -- the product is really Windows Server 7.

Click on the "Read the rest of this entry" link below for more.

I'm not sure why Microsoft decided to deviate from the "Windows 7" brand name for this particular release, as the previous Server "R2" product was more or less an integrated Service Pack refresh for Server 2003 with minor improvements. Windows Server 2008 R2 originally started life and was branded as Windows Server 7 in early betas, but the marketing team quickly put the kibosh on the "Server 7" moniker.

Also See: Windows Server 2008 R2 RC Gallery

My theory as to why they did this was to not scare off early adopter Enterprise customers who had already brought in Server 2008 with Hyper-V, in either a production or evaluation role, and were considering larger Server 2008 rollouts. By naming Server 7 "2008 R2" I guess some of the fear factor was removed and CIOs/CTOs of major IT shops could pretend they were bringing in a patch release like they did with 2003 R2 and not a major refresh. Honestly, I think this choice of branding does the product a huge disservice because so many new things have been added to this release, but go figure. It's semantics at this point.

Some of the major technology areas which received focus during Windows Server 2008 R2's Development.

Whatever this product release is called, it is a major, not a minor refresh. Both Server 2008 R2 and Windows 7 share the same core OS, so a lot of the improvements you've been hearing about with Windows 7 are in 2008 R2, whether it be UI changes or under the hood resource allocation and performance improvements.

It should be noted right off the bat that Server 2008 R2 has one major difference from its predecessor, in that the 32-bit version of Server is now extinct. That's right people, Server 2008 R2 is 64-bit only. That means it only runs on the latest Xeons and Opterons (and Itaniums, for those of you who care) and desktop chips with 64-bit architectures. In some sense, I can agree with this in that Microsoft finally wanted to leave that generation of equipment behind, but I think re-purposed 32-bit systems could have benefited greatly from the refresh. Instead, these boxes are likely to be used for Linux or Server 2003 or Server 2008 SP2. I have a somewhat selfish reason for wanting this because I have a bunch of 32-bit systems that I'd love to refresh with this software, including an older laptop.

Server 2008 R2 also includes the Hyper-V Type 1 Hypervisor virtualization out of the box. In the general release of Server 2008, it was a beta, which was later patched with the final version. With Server 2008 R2, Hyper-V is now truly ready for prime time, with a number of major enhancements listed below (as well as a few that I'm not allowed to talk about yet):

NTFS File System Clustering for Hyper-V -- One of the biggest complaints about the initial Hyper-V was that it had no true fault tolerance like ESX 3.5 did, which features a clustered locking file system known as VMFS. With Server 2008 R2, NTFS file systems can now be clustered in the same fashion, using shared NTFS LUNs across a fiber-optic SAN using HBAs or iSCSI initiatiors. This allows the live migration to function in exactly the same way VMWare 3.5 does. From a fault tolerance perspective if a Hyper-V host goes down, another Hyper-V host can reboot the VM and bring it back up, just like VMWare 3.5. So far, this type of shared NTFS LUN clustering is specific to Hyper-V, but if you read the tea leaves, I expect this support to become available to other Microsoft technologies, such as SQL Server and Exchange.

Hot Add/Removal of VM Storage: LUNs and File Systems avaliable to Hyper-V can be removed and added to the system without rebooting the physical host.

VM Chimney/TCP Offload -- TCP/IP traffic can be offloaded from a VM to a physical NIC instead of a virtual network, for network intensive apps that use large data transfers and pre-posted buffers. This reduces the burden on the CPU, and is fully supported by Hyper-V's Live Migration. To use this feature, you need Chimney compatible hardware, which I believe is equivalent to Intel's VT-D extensions in the newest Xeon chips.

Virtual Machine Queuing (VMQ) -- Network Interfaces can now have direct memory access (DMA) into the allocated RAM of a Virtual Machine. This allows the virtual NIC on the VM to appear as multiple NICs on the physical host. The primary benefit of this function is that the virtual host no longer has device DMA data in its own buffer, which results in a shorter path length for I/O and greater network performance gain.

Physical Boot from VHD file -- While not specifically a Hyper-V feature, this allows a physical Windows 2008 R2 server to boot from a VHD file (Virtual Hard Disk format used by Hyper-V and Virtual PC) stored on a Windows Server's NTFS.

So far, given the limited time I've been able to explore the broad feature set of the Server 2008 R2 Release Candidate, I'm awfully impressed with what the product can do. Be sure to check out my screen shot gallery for some more in-depth drill down. I'm looking forward to really putting this release through its paces over the next several weeks, including 2008 R2's Active Directory and networking enhancements, so stay tuned for the follow-ups.

Have you had time to explore the Windows Server 2008 R2 RC yet? Talk Back and Let Me Know.

Reblog this post [with Zemanta]

Topics: Software, Hardware, Operating Systems, Servers, Windows


Jason Perlow, Sr. Technology Editor at ZDNet, is a technologist with over two decades of experience integrating large heterogeneous multi-vendor computing environments in Fortune 500 companies. Jason is currently a Partner Technology Strategist with Microsoft Corp. His expressed views do not necessarily represent those of his employer.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • 64-bit required for memory

    The 64-bit only limitation makes since because virtualization is memory constrained more than CPU. PAE works but there is a performance hit. I believe the trend in large enterprise environments is a minimal or embedded base OS (JeOS + hypervisor) on large multicore servers with tons of memory, running appliance like applications. Or, big apps like clustered databases. Where this may miss, or is overkill is in the SMB market where classic file and print servers still dominate. 2008 R2 is an enterprise release and will shoehorn for SMB or branch office servers. I have no doubt it is an improvement, but I'd liken it to IBM seeing mainframe revenue strong and missing the PC server revolution. I see a trend toward atom powered mini-server appliances serving up mini-clouds to nettops and netbooks in an SMB like setting.
  • WHAT!?!?

    Next you'll tell me Windows Server 2008 is really Vista with Service Pack 1!!!!
    • Actually

      It is. The original RTM build of Server 2008 is at the same core OS revision as Vista SP1.
      • Sorry

        Hehehe, I was being factious. I know Win2k8 is Vista SP1, I run it at work.
      • Didn't they make out it was a build from scratch at one point?

        I'm sure I remember seeing that somewhere.
    • Comment to "What"

      The comment about Windows Server 2008 R2 is Windows 7 is not as far off as you think. And yes, the foundation code for Server 2008 (or Longhorn when it was in development) is Vista based. I beta tested Longhorn. And believe or not, the developers released one or two beta versions and they forgot to take off "Windows Vista" of of the Longhorn boot up screen. I haven't played with WS2008 R2; however, I'm sure the tradition of building the server from the desktop OS codde is still utilized.

  • I have to admit

    Jason isn't exactly always kind to Windows. Given his overview I'm pretty excited about Server 2008 R2 now, at least even more than I was. It was looking more and more like a major upgrade but I haven't had a chance to download it yet. Now it's pretty high on my list of things to do. I'll probably wait until Saturday when the 7/R2 rush dies down.

    I am personally happy about them leaving 32-bit behind. It kills any remaining excuse software vendors of server-based apps have of not porting their apps to 64-bit. I just installed an EMR package for the doctor's office, a "new" app, that didn't support Vista or Server 2008 Terminal server, or even 2003 R2 64 bit. So their Terminal Server is limited to 4GB of memory, they wouldn't pay for Enterprise. How can a modern app not support these? Of course, the application didn't support resolution scaling, it was fixed at 640x480.

    Terrible developers still survive... Maybe forcing 64-bit will kill some of them off.
    • Just to be clear

      Even though Server 2008 R2 requires a 64-bit machine, Win32 is still very much alive. I don't expect Win32 to die for a LONG, LONG, LONG time.
      • Actually

        I am pretty sure (unless something changes) Windows 7 will be the last 32bit OS. Its becoming a moot point if you ask me. 64bit Windows runs 32bit apps and with the exeption of some poorly written apps all the 32bit apps run fine on 64bit Vista and I have been using 64bit Vista since 2007. Some 32bit apps took a patch or a little TLC to get working but the vast majority all work fine. There will always be some slow developers but I expect that to be minimal.
        • When I mean Win32

          I mean the programming APIs. Not the OS kernel or libraries being 64-bit or 32-bit. The 32-bit Windows APIs will be around for a long time.

          Not all applications NEED to be 32-bit either. It's not always a performance improvement, sometimes the increased binary size eating up more memory actually doesn't make up for the ability to address increased memory.

          I'm still not entirely sure why a Word Processor or a text editor needs to be 64-bit native. I can sort of see why a web browser might take advantage of it now, but the application for it just isn't there. Same thing with client-side JVMs.
    • Terrible developers still survive...

      Maybe the death of Windows will kill some of them off.
      • Perhaps you've been fortunate

        But there are terrible Linux developers as well. In fact I'd probably wager there are more of them. WIth a Windows dev there's a cost of admission, so to speak. At least if you're doing things properly. Linux there's no upfront costs for development softare and OS. Less to risk means more are likely to try, and fail, at it.
        • Actually it tends to be the other way around...

          ...because in the Linux world everyone sees your code, in the Windows world they only see the results or lack thereof.
      • Please don't feed the troll (nt)

    • You're [i]excited[/i] about a Server OS?

      You need to get out more...

      Perlow. You got [i]paid[/i] for that?! Shame on you.
      • Jealous are we? Typical freetard mentality...nt

  • Q: about SAN

    If a SAN LUN (with your VM on it) can only be assigned to 1 WWN on a (specific) host, how do you automatically allow for another host to "take over" and run that VM?
    Roger Ramjet
    • NTFS cluster locking

      It works the same way VMFS does on ESX. NTFS is a cluster locking file system with the latest release. So you can have several hosts talking to a clustered LUN simultaneously, but only one can "own" the vm disk file at any time.

      With live migration you are essentially paging the memory back to a different host, like when your laptop wakes up from resume mode. When that completes the other host owns the file. If in the case the host with the VM goes down, as it does with ESX 3.5, another host reboots it.

      The latest VMWare vSphere has the ability to "Shasdow Guest" VMs where VMs sre essentially RAIDed. Hyper-V can't do that yet.
  • 64-bit is no big deal. Naming it R2 is misleading.

    Virtually all CPU's from the last 3-4 years are 64-bit capable. And since you can run 32-bit apps on 64-bit Windows, this is no big deal.

    Well except with BES 4.x which won't even install on 2008 32 or 64-bit. Thank heavens BES 5 is coming soon. Our BES server is the only 2003 server in our Exchange forest.

    I feel going with the R2 monicker is a mistake though. The 2003 R2 "upgrade" was a harmless install that wasn't even worth it outside of a domain controller. Whereas 2008 R2 is a full OS version upgrade and I hate in-place upgrades of OS's which makes me almost want to wait for R2 before upgrading my domain.

    Calling it Windows 2008 R2 still doesn't take away that this is a major version upgrade not just a piddly version update like 2003 R2 was.