As Microsoft Exchange server is one of my area’s of expertise (or so they keep telling me :) )  I have had numerous discussions in the past whether you should virtualize Exchange or not. For ages Microsoft has claimed it cannot be done, performance would suffer severely, you would not receive support in a virtual environment etcetera.

To be honest, I didn’t really care about it. We’ve designed perfectly working Exchange organizations on VMware when MS was still refusing support. There are some rules you need to respect when you design your messaging environment, but generally it is no problem if you have the required resources available!

Now, a colleague of mine (Thanks Ruben!) pointed me at a specific page within the Microsoft Technet network which has recently been updated. And guess what, suddenly all roles in Exchange 2007 except the UM role are supported on a virtual platform. Now, they do speak of Hyper-V on this page only, but if you follow the link to “Validated Third Party Hypervisor“, you’ll see almost all VMware products are validated for Windows 2008 (and Exchange).

Now, what are the key things to look at when you design a virtual messaging infrastructure? Well, I always use the following list:

  1. How many users do I need to host tops? (try to anticipate on coming changes i.e. takeovers or resignations etc)
  2. How does the average user use the collaboration environment? (device them into 3 groups: light, medium, heavy)
  3. Do I have mobile users?
  4. Do I need clustering/High Availability within Exchange?
  5. How much storage will I need within approximately 2-3 years?
  6. And after all of the above questions are answered, how many IOPS does this environment require to perform within parameters?

Now, I will not give it all away (I have to keep my job too, you know ;) ) but there are some tips I’d like to give you all out there.

  • First of all, do not underestimate the amount of IOPS your messaging environment requires. Most VMs use a 80/20 ratio. 80% of the actions on storage are read actions, 20% of the actions are write actions. Exchange is not like that. The average usage of Exchange will be 45/55. This means that your storage will experience a different kind of load on the LUNs where the databases and log files are hosted. You have to take this into account when designing your storage requirements because hard disks read information faster than they write it.
  • Second, make sure that your networking infrastructure is in order. Your users, when using the full Outlook client, will experience delays and get error messages if the latency to your mailbox server is too high. On average, the latency should be about 20 milliseconds (you can check this by ctrl+rightclick on your Outlook icon in the Windows tray and choose “Server Connections”)
  • Third, do not forget your mobile users. Windows Mobile and Blackberry users claim extra performance because they are constantly connected to your collaboration infrastructure. Calculate at least 0.10 IOPS/mobile user on top of the normal mailbox usages.
  • Fourth, there are some places you can get help :) Microsoft itself offers you several design aids for your collaboration environment. There is the general mailbox storage design page @ Technet here.  Also, there is a great calculation sheet (excel format) made by the Exchange Design team which is a real help when designing your storage. It can be found here. There are loads of other useful documents at that site too.
  • Fifth, try to keep your design as straight forward as possible. Don’t go wandering off into clustering techniques if you do not really require them. Remember that up to 5000 users can be hosted on one virtual mailbox server without performance issues, IF you design it correctly. Also, Exchange 2010, which will be coming soon, promotes the simplicity in your collaboration design. Single server, single disk rather than complex cluster designs. Simple design makes simple administration and simple administration save money.
  • Sixth, never forget your backup design. You can use mailbox retention settings to enable your users to recover (accidentally) deleted items and might replace your brick level backup, but this does not replace a proper database backup. Snapshotting helps a lot too, but in most storage environments it comes with a performance penalty. Take this into account when you design your backup infrastructure.
  • Seventh, if you need to use clustering, consider your licensing. Clustering requires the enterprise edition of Exchange, but when you use several VMs to host your roles (and you probably will) you only need the enterprise version for the mailbox servers that you need to cluster. The other servers can use the standard edition! This might save you some money that you can later on spend on your storage ;)
  • Eighth, do not virtualize the UM role. This will have very strange effects. Voice messages what are played from within Outlook will sound odd or will not play at all. This also is valid for the Office Communication Server or OCS from Microsoft. Many companies are looking at this technique at the moment for presenting presence information and enabling Instant Messaging within the company. The current versions of OCS and the Exchange UM role are not suited for visualization.
  • Ninth and finally, use Exchange 2007 or 2010 when you virtualise your collaboration environment. Ofcourse you can use Exchange 2003 too, but it is far from optimized for virtualisation. Exchange 2007 uses far less IOPS than Exchange 2003. Exchange 2010 will probably use even less then Exchange 2007! And since performance and IOPS are your key values, this is good news for the future.

If you design carefully, Exchange can be extremely flexible (more flexible then it ever was) on your virtual environment, IF you keep the above facts and tips in mind. There still are other things to keep an eye out for, too. Mailbox and database recovery, for example, put a different load on your storage than normal usage does (the pagesize is much different). Also, the new version of Exchange, Exchange 2010, makes it even more appealing to virtualise. Remember that with a simple and straight forward design, you will benefit in the future. Unneeded complex designs might be a bigger challenge, but are hard to govern and maintain and will always hunt you in the end.

The bottomline and conclusion of this piece is: Virtualise Microsoft Exchange: Can you really? Yes you can! And if you ask me: yes, you should, too! :)

I hope this piece helps when you put Exchange on your VMware farm Virtual Infrastructure. Let me know if it does or doesn’t. I appreciate any comments :)