Microsoft’s embrace of simplicity in all things to do with Exchange 2013 and an increasing focus on utilizing low-cost hardware might have the unexpected side-effect of turning customers away from virtualization. If so, it will reverse a trend that had gathered pace ever since Microsoft first saw the light of the virtual day after Hyper-V appeared. It’s true that their policy toward virtual servers had moderated through the support of the combination of Exchange 2003 SP2 and Microsoft Virtual Server 2005 R2 in 2006, but full liberation of hypervisors had to wait until Exchange 2007 SP1 on Windows 2008 (using 64-bit servers, of course).
Over the six years or thereabouts since, virtual Exchange servers have become pretty popular on both VMware and Hyper-V and, to the credit of the Exchange development group, they have made Exchange a well-behaved citizen on virtual platforms. Sure, Exchange 2013 likes to be allocated static resources and doesn’t agree with dynamic memory and the like, it only supports movement between hosts using features like Hyper-V Live Migration, NFS storage remains unsupported, and snapshots (especially of running DAG member servers) are right out, but the list of cautions and restrictions published by Microsoft for virtual Exchange 2013 servers is pretty pragmatic and easily understood.
All of this seems reasonable for those contemplating using virtual servers as the basis for their deployment. Until, that is, you consider three pieces of information. First, there’s Microsoft’s Preferred Architecture for Exchange 2013, which states:
“In the PA, all servers are physical, multi-role servers. Physical hardware is deployed rather than virtualized hardware for two reasons:
The servers are scaled to utilize eighty percent of resources during the worst-failure mode.
Virtualization adds an additional layer of management and complexity, which introduces additional recovery modes that do not add value, as Exchange provides equivalent functionality out of the box.”
Fair enough. Microsoft selects physical hardware for a particular reason, something that is understandable when you consider that a lot of their operational experience with Exchange is gained from Exchange Online, where virtual servers are not used and the degree of automation and standardization that is practised is at a level that the average deployment would use.
Then we consider the points made by Jeff Mealiffe at his excellent “Exchange 2013 Virtualization Best Practices” MEC session. If you wandered into the room and had never contemplated the virtualization of Exchange before, you would probably have been left with an impression that this is not something that intelligent administrators do (at least, not for the servers where the mailboxes of their friends are located). Lots of restrictions, an emphasis on the complexity that the hypervisor brings to the operational environment, and a warning that you should only virtualize if you’re going to get something out of the exercise. In other words, don’t embrace virtualization unless it saves you money or delivers some other measurable advantage.
I thought the session was terrific as it was packed with information and contained some very well-founded points. There was enough there for anyone to be encouraged to think through their options so that a decision to virtualize was taken for the right reasons. You can listen to Jeff’s talk (use the link above) to make your own mind up. I’ve always preferred physical mailbox servers (I can live with virtual CAS or edge transport servers), so there’s a fair chance that I might be biased on this point.
But the third factor that no one really seems to talk about is the cost of the virtual platform. Exchange 2013 is a bit of a resource hog (no surprise there), so some pretty well-configured servers are required for the virtual hosts. Now factor in the need for several virtual hosts to ensure that your highly available mailbox servers are not rendered useless when an entire DAG is taken offline through the failure of one host. To avoid putting your eggs in one proverbial virtual basket, you need to distribute the virtual Exchange servers across multiple hosts, all of which are replete with CPU, disk, and memory. Add in the costs of the hypervisor, including training and support and perhaps some third-party software to handle backups and other mundane tasks, and you might be looking at additional cost mounting to tens of thousands of dollars. At least, that’s what I am being told by people who know a lot more about this topic than I do.
Another influence to factor in is the movement to the cloud. It seems logical that many of the companies that might have virtualized Exchange in the past to make better use of available resources will end up using Office 365. If you only have two or three hundred mailboxes in the company, Office 365 is probably the best choice for you.
If you put Microsoft’s architectural preference for physical servers together with their warnings of the complexities that a hypervisor brings and the additional cost incurred for virtualization, you have a combination that screams “don’t do this.” At least, don’t do virtualization unless you know what you’re doing, you have a good reason for virtualizing Exchange, your operational situation is mature enough to cope with the additional complexity, and you know how to harness the business and technical benefits that virtualization can bring.
Follow Tony @12Knocksinna
