New Section – Recommended Exchange Reference Material
We all have books, whitepapers and documentation that we often end up referring to from time to time, whether it’s a refresher on a topic you’re a little rusty on or just to double check a few facts. For my benefit, and hopefully yours, here’s my handy list of Exchange reference material…
Recommended Exchange Reference Material
New Release – Exchange 2010 Virtual Load Balancer
An extra added cost to Exchange 2010 deployments is often a hardware load balancer, or even virtual load balancer appliances. These start at over £1000 for some of the cheaper ones and can cost tens of thousands, however there’s open source software out there that can do the same thing, just as well.
I’ve wrapped up some of this software together and built a web-based management interface, the end result being a free, easy to setup and use Virtual Load Balancer appliance that runs in both VMware vSphere and Hyper-V environments.
This is version 0.1 – the very first version, so I don’t recommend it in your production environment just yet; the base Load Balancer, HAProxy, should be rock-solid but overall it just needs a few more features, feedback and bug reports on the management interface.
Read more and download from the Exchange 2010 HAProxy Virtual Load Balancer page…
If you’re thinking of virtualising Exchange 2010 on VMware, you might want to consider your options…
Update: VMware have since changed their licencing slightly in response to customer outrage (in fact, this post was intented to help that along). vRAM allowances have been increased, but the fact still remains - Virtualizing Exchange on VMware can cost thanks to these changes.
It’s not often I commentate on news, let along licensing changes - but upcoming changes to the licensing model for VMware will have significant implications for organisations looking to virtualise Exchange on the vSphere platform.
Yesterday, with the announcement of the latest incarnation of their virtualisation platform, VMware have introduced a new licensing model that makes major changes to the costs involved with virtualising memory intensive servers.
VMware’s upcoming changes still split features into different editions, and still license customers on a per-CPU basis, but in addition to this, vSphere is now licenced on the memory allocated to virtual machines, known as vRAM.
What is vRAM?
With vRAM each CPU licence comes with an allocation of memory that is assigned to a number of pools and shared amongst the virtual infrastructure. For each edition of ESX, you get the following vRAM amounts included:
- Standard Edition – 24GB per CPU licence
- Enterprise Edition – 32GB per CPU licence
- Enterprise Plus Edition – 48GB per CPU licence
If you need more vRAM, you need to buy more CPU licences for the same edition used on your hosts, and pools of vRAM cannot be shared among editions. So if you’ve got excess Standard Edition vRAM, you can’t offer it to your Enterprise Plus hosts and vice-versa. And just to be clear – this isn’t utilised RAM, it’s allocated RAM. You’re charged for it whether or not particular virtual machines need to use it it’s full allocation right now.
How does this affect virtual Exchange 2010?
Although many VMware employees and bloggers are talking about about how they don’t think people are right-sizing VMs (making sure VMs don’t have more memory than they really need), their thinking ultimately seems to be really be about how you should be sizing for the vSphere licencing, not the application. Exchange performance, especially for the mailbox role benefits from large memory allocations and these are easy to calculate using the Exchange team’s tools and guidance on TechNet. For many installations this may result in a number of Client Access Servers with 8GB RAM, Hub Transport with 4GB, Mailbox servers with upward of 32GB RAM and 16GB RAM for Unified Messaging servers.
These high RAM allocations mattered little, because memory is relatively cheap, especially in a high-density virtual environment. No longer so – as RAM will be need to be purchased a second time in a VMware environment, there is a direct cost associated with each virtual Exchange instance you deploy in addition to your hardware, and possibly in addition to existing VMware licensing:
| Exchange Role and RAM | vSphere Standard Cost | vSphere Enterprise Cost | vSphere Enterprise+ Cost |
| Client Access Server, 8GB RAM | $331.66 | $718.75 | $582.50 |
| Hub Transport Server, 4GB RAM | $165.83 | $359.38 | $291.25 |
| Mailbox Server, 48GB RAM | $1990 | $4312.50 | $3495 |
| Unified Messaging Server, 16GB RAM | $683.33 | $1437.50 | $1165 |
If you’re wondering where these RAM sizes come from – they are Exchange best practises and the sizing quotes come directly from VMware’s own sample guidance - VMware Exchange 2010 on VMware - Best Practices Guide with the exception of the Unified Messaging role RAM size which comes from Microsoft Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper-V. The pricing comes from VMware’s vSphere 5.0 Licensing, Pricing and Packaging document.
For each of the above VMs, don’t forget you’ll need to multiply these by the number of Exchange VMs you need; so VMware’s example of a clustered environment (in the above whitepaper, page 61) with a couple of UM VMs on Enterprise Edition (320GB RAM allocated in total), this would come in at $28,750 in VMware licensing alone – a minimum increase of $5,750 against 8 CPUs worth of Enterprise Licensing and the full amount if you need to go out and buy the whole 10 CPUs worth of licencing to cover your existing environment
Of course there is an argument that if you’ve already licensed vSphere, you’ll probably be OK - you might have tons of vRAM spare! Maybe, but maybe not according to VMware. As VMware’s own John Troyer says in this VMware forum thread, “we expect almost everybody to come out a little ahead (i.e., some excess vRAM capacity) just from their regular SnS upgrade from vSphere 4”.
So even VMware expect that as you embark on your next project, such as virtualising Exchange, your existing VMware licensing probably won’t cover the kind of requirements outlined above you’ll need to buy a fair bit of additional VMware licensing, even if you current physical infrastructure has enough capacity.
What’s the alternative?
As a VMware advocate who’s been virtualising mission-critical applications on ESX since version 2.1, in 2004, it pains me to say this – but in my opinion, Hyper-V is suddenly looking even more attractive. If you’re got vSphere, you have probably already invested a lot of money in your environment and the maintenance costs were the biggest expense – not enough to dump the investment in money, time and sheer energy to go to another product.
But, things change – if you’ve been in IT longer than 10 years then you’ll remember what happened to Novell in similar circumstances. You already have to licence Windows on your virtual infrastructure, so you have already paid for Hyper-V, and the time and costs to deploy SCVMM may be significantly less than the costs associated with VMware’s new licensing model. If you’re looking for a good pilot project for Hyper-V to prove it is good enough for your needs, Exchange 2010 may well be that project.
Unified Messaging now supported in a virtual machine with Exchange Server 2010 SP1
The Unified Messaging role is a fantastic component of Exchange if you’ve got an on-premises phone system and currently have to run a separate voicemail system. The UM feature can not only replace your existing voicemail system, but it can also transcribe the messages into text for you, has great Outlook integration and provides voice access to mail, calendars and your phone directory.
However, it did have a downside. If you’ve considered virtualizing Microsoft Exchange roles in the past and use the Unified Messaging features, you’ve probably seen the following statement direct from the System Requirements document on TechNet:
All Exchange 2010 server roles, except for the Unified Messaging server role, are supported in a virtualization environment. This is due to the real-time response requirements associated with voice communications with the Unified Messaging server role.
So, while Lync is supported in a virtual environment it may have been a disappointment to find that you can’t virtualise a role that, on the face of it, would seem an ideal candidate for virtualization – the Unified Messaging server. Although it can be processor intensive, it’s not especially I/O intensive, nor does it require tons of storage and it can be scaled by the addition of further UM servers, load balanced by your PBX.
Therefore it comes as little surprise to read in the latest Exchange 2010 whitepaper, released just in time for TechEd 2011, “Best Practices for Virtualizing Exchange Server 2010 with Windows Server® 2008 R2 Hyper V“, that the Unified Messaging role is now supported in a Virtual Environment:
Microsoft Exchange Server 2010 SP1 supports virtualization of the Unified Messaging role when it is installed on the 64-bit edition of Windows Server 2008 R2.
Unified Messaging must be the only Exchange role in the virtual machine. Other Exchange roles (Client Access, Edge Transport, Hub Transport, Mailbox) are not supported on the same virtual machine as Unified Messaging.
The virtualized machine configuration running Unified Messaging must have at least 4 CPU cores, and at least 16 GB of memory.
Whilst these are pretty high requirements for a single VM, they certainly aren’t unfeasible, and I certainly don’t think they should be a deterrent to virtualizing the role. Typical hosts for virtualization can typically see 12x3Ghz cores and 196GB of RAM for well under £10K per host.
The only caveat worth bearing in mind is that the document is specifically aimed at Hyper-V; the support statement above just says “virtualization” and of course the associated TechNet article hasn’t been updated either – so it’s certainly worth waiting to see the extra details in TechNet 2011’s session EXL306 and watching the main TechNet Article to see if it’s updated.
Update 16th May – The updated guidance does indeed apply to VMware environments too, as per the Exchange Team Blog:
* The Unified Messaging server role is supported in a virtualized environment.
*Combining Exchange 2010 high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers, is now supported.Due to improvements we made in Exchange Server 2010 SP1, along with more comprehensive testing of Exchange 2010 in a virtualized environment, we are happy to provide this additional deployment flexibility to our customers. The updated support guidance applies to any hardware virtualization vendor participating in the Windows Server Virtualization Validation Program (SVVP).
BTW– thanks to Tim Harrington for making me aware of this document; I wasn’t expecting the UM news to be made public until next week, so it was a nice surprise!
And if you are interested in Virtualizing Exchange, check out Henrik Walther’s and Michel De Rooij’s blogs for some more more details about support for Live Migration/VMotion and host-based HA support.
Finally, if you’ve got any thoughts, let me know in the comments. If you’ve already been virtualizing the UM role regardless of the support (!) how’s it been? Any problems? If you are virtualizing Exchange Server 2010 at the moment, but still don’t plan on virtualizing the UM role, why not?


