56,000 Seat Production Exchange 2007 Deployment Microsoft licensing keeps Windows out of virtual appliances
Oct 18

Is Microsoft Exchange 2007 Supported on VMware?

Microsoft, SupportPost by Mike DiPetrilloAdd comments

The short answer is yes. I get the question a lot from customers so I thought a short blog post with the details would be in order.

An update on the Exchange support issue – it’s supported as of September 1, 2008 under SVVP.

Here’s the main page explaining what you get with SVVP. http://windowsservercatalog.com/svvp.aspx?svvppage=svvpsupport.htm

You can see from that page a list to the supported applications: http://support.microsoft.com/kb/957006/.

From there you will see the following for Exchange:

Microsoft Exchange Server
Microsoft Exchange Server 2007 Service Pack 1 and later versions are supported. For more information about the support for Exchange Server 2007, visit the following Microsoft Web site:
http://go.microsoft.com/fwlink/?LinkId=124624

Click on that link and you get a list of requirements for supporting in production:

Support Policy and Recommendations for Exchange Server 2007
Microsoft supports Exchange Server 2007 in production on hardware virtualization software only when all the following conditions are true:

  • The hardware virtualization software is Windows Server 2008 with Hyper-V technology, Microsoft Hyper-V Server, or any third-party hypervisor that has been validated under the Windows Server Virtualization Validation Program.
  • The Exchange Server guest virtual machine:
  • Is running Microsoft Exchange Server 2007 with Service Pack 1 (SP1) or later.
  • Is deployed on the Windows Server 2008 operating system.
  • Does not have the Unified Messaging server role installed. All Exchange 2007 server roles, except for the Unified Messaging role, are supported in a virtualization environment.
  • The storage used by the Exchange Server guest machine can be virtual storage of a fixed size (for example, fixed virtual hard drives (VHDs) in a Hyper-V environment), SCSI pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that is configured at the host level and dedicated to one guest machine.
    Note:

  • In a Hyper-V environment, each fixed VHD must be less than 2,040 gigabytes (GB). For supported third-party hypervisors, check with the manufacturer to see if any disk size limitations exist.
  • Virtual disks that dynamically expand are not supported by Exchange.
  • Virtual disks that use differencing or delta mechanisms (such as Hyper-V’s differencing VHDs or snapshots) are not supported.
  • No other server-based applications, other than management software (for example, antivirus software, backup software, virtual machine management software, etc.) can be deployed on the physical root machine. The root machine should be dedicated to running guest virtual machines.
  • Microsoft does not support combining Exchange clustering solutions (namely, cluster continuous replication (CCR) and single copy clusters (SCC)) with hypervisor-based availability or migration solutions (for example, Hyper-V’s quick migration). Both CCR and SCC are supported in hardware virtualization environments provided that the virtualization environment does not employ clustered virtualization servers.
  • Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it is running. This feature enables you to take multiple snapshots of a virtual machine and then revert the virtual machine to any of the previous states by applying a snapshot to the virtual machine. However, virtual machine snapshots are not application-aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange Server. As a result, making virtual machine snapshots of an Exchange guest virtual machine is not supported.
  • Many hardware virtualization products allow you to specify the number of virtual processors that should be allocated to each guest virtual machine. The virtual processors located in the guest virtual machine share a fixed number of logical processors in the physical system. Exchange supports a virtual processor-to-logical processor ratio no greater than 2:1. For example, a dual processor system using quad core processors contains a total of 8 logical processors in the host system. On a system with this configuration, do not allocate more than a total of 16 virtual processors to all guest virtual machines combined.

And lastly here’s the page where VMware is listed as supported in SVVP:

http://windowsservercatalog.com/item.aspx?idItem=3989e3af-30c0-dee8-8078-960c2ec0e1a6&bCatID=1521

So there’s the documentation you can follow to find that the Exchange deployment that I posted earlier and the case study that Gabe is talking about here is in fact supported. I hope this helps!

No TweetBacks yet. (Be the first to Tweet this post)
VN:F [1.7.8_1020]
Rating: 0.0/5 (0 votes cast)
VN:F [1.7.8_1020]
Rating: +1 (from 1 vote)

  • David
    In my research I've also got the following to add;

    1) SVVP currently only certifies up to 16GB RAM, so that means you are "limited" to 16GB for support. (does that means you can run 32GB and change back to 16GB when you call for support?)

    2) VMware don't seems to differentiate CCR from MSCS (even though it's using majority node set with no quorum). So when you check the SAN HCL, you'll notive that most arrays aren't supporting MSCS (and by association, CCR). EMC is the notable exception.

    So ignoring 2), yes, it's supported :)

    Of course, there still the "fall-back" positions we put forward to clients;

    a) Have a Platespin V2P one time use licence in your back pocket in case MS support ask for it to be reproduced physically

    b) Most of our customers have Premier MS support anyway, which entitles them to best effort support anyway (correct me if I am wrong).

    Does anyone have any real-world experiences where they were denied support due to breaching any of the above rules?

    Dave
  • David, here's my comments for you.

    "1) SVVP currently only certifies up to 16GB RAM, so that means you are "limited" to 16GB for support. (does that means you can run 32GB and change back to 16GB when you call for support?)"

    Anything is possible. I'm not advocating it but I know of a lot of customers that simply don't tell Microsoft they're running virtual. Again, with SVVP I really don't see the need to do this since VMware is supported in production running the vast majority of Microsoft applications. No need to lie.

    "2) VMware don't seems to differentiate CCR from MSCS (even though it's using majority node set with no quorum). So when you check the SAN HCL, you'll notive that most arrays aren't supporting MSCS (and by association, CCR). EMC is the notable exception."

    The independent SAN vendors do their own certifications for the arrays. The HCL gets updated all the time. MSCS is supported by VMware (and Microsoft) in the guest. CCR for Exchange is called out by Microsoft as a no-no. Most customers are finding that they prefer to just use HA built into VMware for the failover or Site Recovery Manager (SRM) for DR. If they're using other virtualization solutions then there are 3rd party products that do similar things (except for the SRM part).

    "Of course, there still the "fall-back" positions we put forward to clients;

    a) Have a Platespin V2P one time use licence in your back pocket in case MS support ask for it to be reproduced physically

    b) Most of our customers have Premier MS support anyway, which entitles them to best effort support anyway (correct me if I am wrong)."

    This is the great thing about SVVP - you don't need to have Premier level support anymore. Anyone that's deploying on a SVVP certified platform, Premier-level or not, gets support. What's even better is replication on physical only occurs if MS and VMware jointly can't figure out what's going on. Even before SVVP I've only seen 2 customers replicate back to physical to get the issue resolved. It's very rare that MS doesn't know what the issue is to start with.

    I'll let others reading comment on their real-world customer experience on getting denied support or not.
  • Thanks.
  • Luke Denham
    Interesting conflict here -

    MS state that Exchange 2007 is only supported on VMware (or any other virtualisation platform) if it is running SP1 and on Windows 2008.

    VMware does NOT support Windows 2008 clustering in production in ESX 3.5 U3.

    This seems to limit the options for Exchange 2007 deployment to a standalone server, SCR and LCR only. However, I am interested in implementing Exchange CCR for resilience. Since CCR doesn't utilise shared storage it is a different type of cluster to the traditional failover MSCS and perhaps less complicated and presumably the issue VMware has is with the storage side. All the replication occurs at the Exchange level rather than storage. I assume that the level of testing VMware would have needed to complete to validate W2K8 MSCS was prohibitive - a case of vendor not supporting the configuration and hopefully not that it won't work.
  • Rob Glanzman
    Win2K8 clustering requires SCSI-3 reservations. VmWare ESX 3.5 only supports pass-through SCSI-2. Hence, why it's not supported.
blog comments powered by Disqus