In-Depth
Virtualizing Your Exchange Environment
The decision to virtualize Exchange can be a difficult one, but it can also pay off for some organizations. Here's what to consider when looking at running Exchange in a virtual environment.
To install Microsoft Exchange in a virtual environment, first you want to ... Wait a minute! You don't really want to read an article about how to install Exchange on a virtual server, do you? Really, the process of virtualizing Exchange is kind of boring when it comes right down to it. It's exactly the same process as installing it on a regular physical server, for the most part. And once it's installed and everything is up and running on a virtualized guest operating system, either on Microsoft Hyper-V or VMware ESX, there's not much more to the story. Of course, you must manage and maintain it just as you would a physical server, but all the really interesting stuff about virtualizing Exchange comes long before you double-click setup.exe.
Indeed, while actually installing Exchange in a virtual environment is nothing new, what is noteworthy is that until August 2008, Microsoft would not officially support such installations. This meant that running Exchange virtually was something often relegated to the realm of test labs and other non-production uses -- unless you were one of those renegade IT professionals who released it into production, anyway. There were IT pros who trusted their enterprise virtualization platform enough to boldly forge ahead and put virtualized Exchange into production, but they did so without Microsoft's blessing and risked being left out in the cold without support if issues did arise.
However, with the server virtualization game playing out at breakneck speed, Microsoft really had no choice but to start supporting Exchange on virtual installations, especially with all the work Redmond was putting into its own virtualization platform, Hyper-V. While Microsoft could have -- and should have -- made this move sooner, it's at least commendable that the company finally committed to it almost two years ago instead of doing something like holding out for the release of Hyper-V Server 2008 R2. The bottom line is that Exchange customers wanted support for virtual installations, and Microsoft responded by giving customers what they wanted. In other words: Better late than never.
In a perfect world, everyone would now be running Exchange in a virtual environment with no problems. E-mail would flow happily ever after, and this is where the story would end. But given the realities of how Exchange is deployed, this is where our story begins.
The Support Policy
What exactly does Microsoft currently support when it comes to virtualizing Exchange? While not quite as complex as Microsoft's licensing model, the support policy is very detailed and somewhat restrictive. As you read the policy, it becomes obvious that Microsoft approached this whole thing in a way that would allow the company to protect its own interests from a support perspective. However, Redmond's new support stance serves the best interests of its customers as well. How so? When the customer implements a virtualized Exchange environment by following the detailed guidelines and restrictions set forth in the policy, that customer is going to have the best-possible virtual experience. In that sense, it's no different than the requirement to follow Microsoft's recommendations when installing on physical servers in order to have the product work the way it should.
You can locate the policy itself in a TechNet article titled "Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments," online here. Just be prepared to set some time aside when you get ready to read it, as it's 11 pages long, printed. If you want to cheat just a bit, here are a few of the highlights you'll need to look out for:
- Exchange 2007 must be installed on Windows Server 2008 with Hyper-V or Microsoft Hyper-V Server 2008. Exchange 2010 can be installed on those versions or on R2 versions. Either Exchange version may be installed on a third-party hypervisor that has been validated under the Windows Server Virtualization Validation Program (SVVP) -- more on that to come.
- An Exchange 2007 guest must run SP1 or later and be deployed on Windows Server 2008. An Exchange 2010 guest must run on Windows Server 2008 SP2 or R2.
- Each Exchange server version and role must be sized to meet the general system requirements for that version, just as it would for an installation on a physical server.
- The Unified Messaging (UM) server role for either Exchange 2007 or 2010 is not supported in a virtualization environment. However, that doesn't mean it doesn't work. The reason for the lack of support is that the UM uses a third-party Real Time Collaboration stack, and the vendor who makes the stack doesn't support virtualization.
Microsoft resolved initial voice-quality problems with earlier builds of Hyper-V, though, and many shops are running UM in production without any issues. But until the vendor supports virtualization, the UM role won't be supported.
- For storage, you must use either fixed disks (under Hyper-V, the VHDs must be smaller than 2,040GB), SCSI pass-through (raw disks) or iSCSI storage. Virtual disks that use differencing or delta mechanisms are not supported.
- On the physical host server, you can only install management software, such as anti-virus, backup software, virtual machine (VM) management software and so on. You can't run any other applications, such as SQL Server, Active Directory or even Exchange.
- Microsoft doesn't support combining Exchange high-availability solutions -- cluster continuous replication (CCR) or single-copy cluster for 2007, or database availability groups for 2010 -- with hypervisor-based clustering or other high-availability or migration solutions.
- Creating VM snapshots of an Exchange guest VM from within the hypervisor application on the host is not supported.
- When specifying the number of virtual processors allocated to Exchange guest machines, the supported ratio of virtual processors to logical processors must not be greater than 2-to-1.
- Research, plan and test your virtualization solution. This isn't stated as a direct condition of the support policy, but it's the underlying suggested approach that runs throughout it.
This is a highly condensed and brief overview of the major support conditions. The policy itself goes into greater depth on these points and contains recommendations for many more elements, such as considerations for backup and restore, networking and so on.
The policy article referenced earlier also contains the requirements for virtualizing Exchange 2003. If you're wondering about converting your Exchange 5.5 or 2000 servers to VMs, there is, unfortunately, no support for any version of Exchange prior to Exchange 2003 in a virtualization environment.
As far as the official requirements for virtualizing Exchange 2010 are concerned, they're very similar to those for 2007. The complete virtualization requirements list can be found in the TechNet article "Exchange 2010 System Requirements," online here.
Which Roles Should I Virtualize?
Which Exchange server roles are the best candidates for Exchange virtualization? For many, the immediate candidates are the Client Access Server (CAS) and Hub Transport (HT) roles, which often can easily run on and benefit from virtualization. Be aware, though, that in Exchange 2010 the CAS role will demand more resources, so plan accordingly.
While Microsoft supports the Mailbox server role installed on a virtual server, there are many IT pros that cringe at the thought of setting up their systems that way. The critics feel that the Mailbox role is so CPU- and I/O-intensive that virtualizing it in production is a mistake, and performance will suffer. But there are many reasonable ways to look at this without writing off virtualization of your Mailbox role. It's true that you'll see a slight rise in your CPU utilization with virtualization, but many IT pros say that, unless you're already maxed out, you're looking at a 5 percent increase. As for the I/O issue, you can work around it by placing the virtualized drives on a SAN or, in smaller environments, by working with SCSI pass-through storage for the Mailbox database and transaction logs. Keep in mind, too, that you don't have to virtualize all of your production servers.
So, perhaps for higher availability, you wish to implement a CCR cluster. You can take a single server and virtualize the passive side, for instance. You can also use that same server to run a second CAS and/or HT server for higher availability of those roles. Really, there are scores of different design options that might pull virtualization into your environment judiciously if you're concerned about the performance hit -- especially on the Mailbox role.
Typically, however, if you meet Microsoft's support recommendations and size and test the solution appropriately, you can be sure that Exchange will perform just as it's supposed to. Your users will never know the difference. And in the end, isn't that peace of mind part of what virtualization is all about?
The Edge Transport (ET) role is supported for virtualization, although some may be concerned about an escape attack where a hacker goes through the VM and gets at the virtualized server itself. This is a possibility, but I can't find any examples of a successful escape attack. Moreover, the ET role sits on the perimeter, so the attack would only go so far even if it did succeed.
One final note: As previously mentioned in the support conditions, the UM server role is not supported by Microsoft on virtualization. Does this mean that if it's sized appropriately, it won't work? Of course not -- but keep in mind that you enter at your own risk if you choose to virtualize it.
Third-Party Support
When first published, Microsoft's new Exchange virtualization support policy met with initial criticism as being self-serving, because the company only directly supported its own virtualization technologies. VMware customers who rushed out to check the new policy could find no initial references to ESX.
Actually, Microsoft took the initiative to bring support to the table for customers of any virtualization vendor, provided that the vendor would work with Microsoft to validate its configurations. In order to do so, Microsoft launched the Windows SVVP. Full details of the program are available on the official SVVP page on the Microsoft Web site. Customers running Exchange on a third-party virtualization platform that has been validated under SVVP can receive full support from Microsoft. But what happens if you do have issues and Microsoft believes that the root of the problem is with the vendor's hypervisor software? As per the SVVP, Microsoft will actually work with the vendor through a support arrangement in order to assist in resolving the issue.
What has been the response to the Microsoft SVVP?
Currently, there are 11 vendors who have joined the SVVP, and eight of them so far have solutions and products that have been validated. These include Citrix Systems Inc., Hitachi Ltd., Novell and Red Hat Inc. -- just to name a few. And what about VMware? Yes, it's in there, too. As a matter of fact, VMware was able to announce on Sept. 3, 2008, that it was the very first vendor to have its hypervisor -- VMware ESX 3.5 update 2 -- validated by Microsoft under the program.
Licensing Compliance
Microsoft's move to support a virtualized Exchange installation is a definite indicator that many IT shops are choosing to go in that direction. And it's not just support for Exchange, either -- Microsoft's announcement last August stated that it had updated its technical support policy for 31 server applications to be supported on virtual platforms, including applications like SQL and SharePoint. The full list can be found here.
But Microsoft didn't stop with just a new support policy. In a move of true innovation, it also changed its licensing terms as of Sept. 1, 2008. The company now allows for moving 41 server applications running on virtual guest machines between physical host servers within a server farm as often as necessary without having to pay for additional licensing fees or worry about license reassignment.
What does this mean, and why should you care? Well, suppose you previously had two physical servers running a hypervisor and had a single Exchange virtual server configured on one of them. If you wanted to move the guest Exchange machine from running on one physical host over to the other, then you'd have had to reassign the license to that server, and you could only do so once within 90 days to be in licensing compliance. This often led to extra expense for many IT shops, because in order to remain compliant, they would've had to purchase an additional Exchange license for each physical server that the virtual server may have had to run on. In this example, that would've meant buying one additional license so that the virtual Exchange server could be moved back and forth between either of the two hosts as needed.
Bottom line: With the new licensing arrangement, you can take advantage of the dynamic nature of virtualization without incurring any extra licensing expense, because you can now count licenses by server farm instead of by individual servers.
Now that Microsoft officially supports Exchange in a virtual environment -- and on third-party hypervisors at that -- and all the licensing concerns have mostly been worked out, the technical question of, "can I virtualize Exchange?" has certainly been answered. This concludes our story, then, correct? Well, no, because for many IT shops there's still the philosophical question that remains: Should I virtualize Exchange?
Unfortunately, there's no single right or wrong answer to this question. Rather, it's wholly dependent on a multitude of factors that are going to differ greatly from one environment to another. It's not a decision to make lightly. Exchange is a core application for many businesses today, and users rely heavily on it. Therefore, if you're completely new to virtualization technology, then perhaps virtualizing your Exchange servers may not be what you want to start off with to get your feet wet. But for organizations that have successfully implemented one or more hypervisor platforms along with the appropriate storage solutions, there are compelling reasons to look at converting or migrating some -- or all -- of your organization to virtual Exchange.