Steve Goodman's Exchange Blog
14May/119

Unified Messaging now supported in a virtual machine with Exchange Server 2010 SP1

imageThe 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?

4Jan/110

2010 roundup and first anniversary of this blog…

So, 2011 is finally upon us and the new year also marks a couple special occasions for me. Firstly, I'm 30 in less than two weeks time (!) and secondly, it's a whole year since I started my blog…

For many years this site was really just about Car PCs. As that technology became standard in most cars, and the time I had spare for expensive hobbies diminished after the birth of my daughter I needed to find another outlet for my creative juices. I've always been into technology communities - in the past I've organised UK Car PC meets, been a forum mod on a number of Car computing websites and even been in a few UK computing magazines - again for the Car PC stuff.

However in recent years I've spent a lot more time and effort working with enterprise computing technology and taken a special interest in Messaging, VMware, storage and more lately Unified Communications. Therefore, it was a natural step to take more of an active interest, firstly helping people out on forums and of course by blogging.

With so many other Exchange related blogs around, I wanted to be different to a lot of the other blogs and make sure I don't just focus on the latest news; instead I wanted to try and offer something unique or provide the first insight into new features. As an Exchange TAP member the latter was thankfully easy (once features were out of NDA!) and I hope I've done a fairly good job of finding a unique angle or solving a problem you didn't know you had.

A few stats..

I won't bore you with a ton of graphics, so instead here's a few stats on my first year blogging…

And these are just on the blog itself - since I started tracking visits back in 2005 (the site was running for years before that), I've had over 680,000 views from nearly every country on the planet with only a couple of countries in central Africa and North Korea as exceptions.

The Year Ahead

It looks like 2011 is going to a be a busy year for Exchange-heads and UC-fans alike. Lync is certainly going to be making a big push into the Enterprise - it's a fantastic product and I can see it's going to be very popular. Exchange 2010 is no longer the new kid on the block and now it's past SP1 there's going to be a lot more enterprises moving to it from 2003 and 2007; and finally Office 365 is just around the corner. These are all areas I've got more work planned myself and I've got a list as long as my arm of blog posts that will hopefully be very useful.

So, you can expect to see a lot more blog posts from me in the year ahead. I've sat for far too long on a few topics I had planned so stay tuned for a few things that you haven't seen anywhere else yet, complex topics demystified and if all goes to plan I've got some stuff up my sleeve you can't get without spending a fair bit of money. Smile

Happy new year!

Steve

9Nov/101

VMware release Exchange 2010 "Best Practices Guide" [Updated]

imageI recently read via Virtualization.info that VMware have released their "Best Practices Guide" for Exchange 2010. It transpires this was actually released a couple of months ago, however it's the first time I've seen it and I certainly think if you run VMware vSphere and plan on running Exchange 2010 it's worth a read.

VMware say in the best practices guide that "Exchange Server 2010 is proving to be an even better candidate for virtualization than its predecessors.", "The Exchange 2010 Mailbox Server role is lightweight, fast, and ready for virtualization." and "performance for a virtualized Exchange server is comparable to a non-virtualized server running on the same hardware".

So from VMware, it's no surprise to hear that Exchange is a perfect workload to virtualize on their platform. If you're currently running vSphere, and considering virtualizing Exchange 2010, VMware will definitely support this on their ESX platform. However, there are a few caveats…

If you're currently running an Enterprise vSphere deployment, shared storage will most likely be your number one platform for all your VMs running in your virtual environment. Without it, the key VMware features like vMotion, DRS and VMware HA don't work and you're left with your eggs in a number of delicate baskets. So it won't be shock that VMware say "It is preferable to deploy virtual machine files on shared storage ".. "This is considered a best practice for mission-critical Exchange deployments, which are often installed on third-party, shared-storage management solutions.". While I agree with the first part of that, I certainly don't agree that it's still best practice to use shared storage for Exchange - for starters Exchange 2010 no longer supports single copy clusters and CR based clusters such as DAG and CCR really excel when using DAS. Understandably, for VMware this is the main issue. vSphere in the Enterprise == Shared Storage, so to maintain this model they need to recommend shared storage for any application running atop the platform.

So, you've really got to use shared storage for Exchange on vSphere.. But that's OK, isn't it? NFS is getting wider acceptance for running VMs on and of course iSCSI is a great middle ground between F/C and NFS for using traditional storage protocols at a decent price… Well, iSCSI is supported for standalone Mailbox servers, but "For Mailbox servers that belong to a Database Availability Group, only Fibre Channel is currently supported".

According to VMware, though, only supporting DAG on F/C may not be a major problem, though. Instead of using DAG to have multiple database copies, VMware say "The building block approach is a recommended best practice for creating a standalone Exchange Mailbox Servers running on vSphere using pre-sized virtual machine configurations. Exchange servers that have been divided into virtual machine building blocks (as opposed to larger, monolithic Exchange servers) can simplify server sizing during the initial deployment and create a highly scalable solution using virtual machines with predictable performance patterns.". So if you don't mind only having one database copy (or copying it at the array level), the the combination of iSCSI+VMware+Exchange 2010 may be for you.

It's fair to say although there are a few disappointments in the document - like the focus on shared storage, gentle push to avoid DAG and the use of F/C disks in RAID 10s instead of large, dense SATA disks, it's still a worthwhile read (so long as you follow Microsoft's own best practices) and will help with small and large Exchange deployments on vSphere alike.

Download Exchange 2010 on VMWare - Best Practices Guide

Update 1: Microsoft have recently posted (a few hours after this post, taking into account the time difference) a response to the Best Practices guide:  Answering Exchange Virtualization Questions and Addressing Misleading VMware Guidance

Update 2: VMware have responded to Microsoft's above post, addressing why VMware HA is a great compliment for DAGs: Virtualizing Exchange on VMware Provides More Recovery and Availability Options

16Feb/100

Most useful VMware vSphere storage posts of the last year

I’m on training this week with my team, on the vSphere Fast Track 4.0 course as a pre-requisite for the VCP 4 exam (I missed the upgrade window… !) and conversations with the trainer led me to dig out a number of posts I’ve found very useful since vSphere’s release:

From the Official VMware Performance Blog - Performance Study of VMware vStorage Thin Provisioningstraight from the horses mouth a good doc on comparing thin vs thick vs eagerzero. Spoiler - Eagerzero wins!

Chad Sakac, VP of the VMware Tech Alliance at EMC is someone who has a lot of good contacts and seems to be able to get the best information on a subject concatenated into a single (albeit long post). Some interesting posts of his are Where should you thin provision and the Multivendor iSCSI post (which is by EMC, VMWare, HP, Netapp and Dell; there are NFS and VI3 ones also).

There’s also a couple of Thin Provisioning posts I’d found interesting over a VCritical - Responsible Thin Provisioning in VMware vSphere and The Last Resort - PowerShell Prevents Datastore Emergencies. Though to be honest, I don’t see why one would need to worry about this at the Datastore level if they don’t overallocate at the vSphere layer and instead manage at the SAN instead.