In case you missed it, the deadline for getting off of Exchange 2007 is rapidly approaching, assuming you like to be in a supportable state, get security updates, and all of that. And since even Exchange 2010 is getting a bit long in the tooth, there’s probably a number of you out there considering Exchange 2016, and wondering about virtualization. In this post we will look at virtualizing Exchange 2016, including requirements and recommended settings to get the most out of this approach.

Virtualization is continuing to grow in popularity, with physical hosts and IaaS both being valid options. Whether using local hardware or VMs in the cloud, you will want to ensure that you pay close attention to the requirements for Exchange. We all know Exchange can be a bit of a resource hog, and VM technologies try to be fair and share with all of their guests, which may not always work as well when it comes to Exchange.

Host requirements

This may surprise you. Microsoft supports Exchange on more than just Hyper-V. Now, no, they don’t support VMware or Citrix, but if you are running Exchange servers on Windows hosts that are guest VMs in one of the competition’s virtualization platforms, you’re not cut off from support. Of course, what is and is not supported is not 100% clear. See the Windows Server Catalog at for details on the specific platforms and to see whether the Windows OS you want to use is supported on the hypervisor you are using. Then of course, you need to make sure the host has sufficient resources for both the guest operating system and Exchange, on top of its own needs.

If you are going to use Azure IaaS for your Exchange environment, keep in mind that all storage volumes must be created on Azure Premium Storage. You can only use the lower-tier storage for the operating system. This of course implies that the VM storage on-premises must be fairly beefy to support Exchange’s needs. Also, Azure VMs cannot send outbound SMTP mail directly. You’ll either need to use an on-prem relay, a third-party relay like SendGrid, or Exchange Online Protection.

Guest Operating System

At this time, only Windows Server 2012 and Windows Server 2012 R2 can be used as the guest operating system.


All Exchange 2016 roles are supported. There’s no need to stand up a physical server for any part of your Exchange 2016 org.


The host machines will need sufficient storage for their own operating system, the virtual disks configured for the guest server, memory files equal to the size of the memory allocated to the Exchange VMs, and additional storage for temporary files, log files, etc.

The Exchange storage requirements are more specific. While both fixed and dynamic disks are supported, they must use block-level storage. NAS storage is only supported in specific scenarios using SMB 3.0 and fixed disks. Because of the intense disk I/O that Exchange can create, storage for Exchange should be on separate spindles from the storage for both the host and guest operating system disks.


All memory allocated to Exchange VMs should be fixed. Dynamic RAM allocations and oversubscribing RAM are both unsupported.

Snapshots/Saved state

The use of snapshots is not supported, nor is booting up a guest VM from a standby image or saved state. You should only ever cold boot Exchange VMs, and shut them down completely before shutting down the host.


Microsoft recommends that you use only a 1:1 virtual processor-to-physical core ratio for best results. However, they will support you as long as the ratio is no greater than 2:1. However, don’t short-change your host operating system, as it must handle the hypervisor, virtual network, disk I/O, and likely management agents.

Host-based failovers and migrations

HA/FT schemes like vMotion and Live Migration are supported. Failovers that boot up machines from a cold boot state are also supported, but as mentioned above, saved states are not. So if HA/FT is a requirement (which of course it is!) then make sure you invest in sufficient hardware to support vMotion or Live Migrations. Don’t take periodic snapshots and plan on using them for a failover.

There is an article on the Microsoft website called  Exchange 2016 dev/test environment in Azure at which walks you through a basic Exchange 2016 build. Note of course the requirement to deploy a domain controller. That’s not just for the benefit of your lab. Exchange 2016 has just as high a dependency on Active Directory as previous versions, so if an IaaS build is in your future, you will need to ensure AD servers are also there.

If you are considering virtualizing Exchange using either VMware or Hyper-V you can have a look at our in-depth series:

Best practices for virtualizing Exchange – Part 1: VMware

Best practices for virtualizing Exchange – part two: Hyper-V