Virtualization… it seems like everyone is moving to virtualize as much as they can. Whether they do it on-premises, or in the cloud, reducing physical machine counts in favour of increasing virtual machine counts is a trend that continues to grow. When you consider how many Exchange servers a company needs to have, and how critical it is for them to be highly available and fault tolerant, virtualizing them just makes sense. In this three-part series, we want to look at best practices for virtualizing Microsoft Exchange. We covered VMware here and Hyper-V here pointing out where support differs. We didn’t compare or try to convince you which platform is better. We’re also keeping away from discussing the merits of physical versus virtual.
This series makes three presumptions:
- You are going to virtualize your Microsoft Exchange server(s)
- You already have a virtualization platform in place
- You just want to know what you should watch out for, or anything you want to be sure you do, to have the best experience doing this.
If you’re good with that approach, this is part three – Exchange on IaaS. We’re not going to spend too much time on the difference between Azure and AWS or Google Cloud Platform, but we will make sure you know what’s what. In addition, we are not going to repeat the content from parts one and two, as we want to make sure you read those too. Check them out for specifics on CPU, RAM, and storage related to what is provisioned.
This shouldn’t come as a surprise to many, but let’s get it out of the way up front. If you want to be in a supported configuration so you can leverage Microsoft’s Premier Support, you need to be on Azure. Hey, it wasn’t until earlier this year that the Exchange team would even support you on Azure, so we may see more coming for competing platforms in the future. Until then, if you’re running Exchange in AWS and call Premier for help, it will be best effort only.
There’s a pretty big reason for that. AWS uses a proprietary hypervisor which is unsupported. Will it work? Probably. Do you want to risk it? That’s your call to make. If you are running Exchange in AWS and something goes wrong, Microsoft may still be able to help you, but they may also require that you reproduce the issue on a supported platform or limit their efforts to commercially reasonable. This means that if you are willing to pay they are willing to help, but there may come a time when they say you’re wasting your money and should move to physical hardware or Azure to repro the issue before continuing to burn money (your money)!
You will need to be really careful with your outbound mail, since any IaaS platform is going to have IP space all over the place, and not every receiving system is going to be thrilled about allowing incoming mail from what they may consider the Internet equivalent of the wild, wild, West.
In Azure, Microsoft will support Exchange for non-production use, such as in development, lab, QA, or other testing. They will also support running the cluster witness in Azure for stretched DAGs, and for production use if storage requirements are met. If you’re less about Premier supportability and more about your choice of IaaS, it is reasonable to assume that you can do much the same things in AWS or Google, as long as you mind the storage needs. More on that below.
This one is easy. Today, support for Exchange running in IaaS (Azure) is limited to Exchange 2013 only. It will almost certainly include Exchange 2016 at GA, but until then, it’s 2013 or nothing.
Here’s the bottom line on what you want to do with resource allocation to Exchange on IaaS.
Exchange needs AD, period. You are going to have to extend your Active Directory to your IaaS platform so that local Global Catalog services are available in the same location. You will also want to make sure those are tied together, which in Azure is called an Availability Group, so that if there is a site failover, Exchange and the DCs all stick together.
One reason that IaaS may not be the best choice for Exchange is because of disk I/O. Most IaaS providers offered tiered storage, and that includes Azure. Even though Microsoft does now support Exchange running in Azure, they will only support it for production mailbox hosting if you are using Azure Premium Storage. Both databases and log files must be stored in Premium Storage, and since those need the most disk I/O that’s not really surprising, is it?
Remember too that to be in a supportable configuration, Exchange must have unfettered access to all other Exchange servers and all domain controllers in your environment. If you’re extending your datacenter footprint to an IaaS provider, you need to treat that like another datacenter on your WAN, and ensure no firewalls are blocking any traffic. Sure, you are going to scoff at that and put up firewalls anyway, because that’s how you do it, but consider this. Microsoft publishes a LOT of TechNet and KB articles. Very few are about things that are explicitly NOT supported. Putting firewalls between Exchange and anything else on the intranet is one of those things, because it causes so many problems.
If you really want to run your own Exchange servers, and do it in an IaaS platform, you certainly can. Azure offers options that will keep you fully supported, but AWS and Google Cloud Platform are contenders too if supportability is secondary. However, consider why you want to put Exchange in IaaS, and then consider if maybe hosted Exchange or Office 365 might not be the better, and more cost effective option for you. IaaS is great, but if the thought is to reduce your overall servers, Exchange is maybe not the best workload for that. If the thought is to get out of the business of running Exchange, Office 365 may be the best way to get you there!
We hope this series has been helpful for you. If there’s any questions it left unanswered, leave a comment below and let us know. Also, if there is something else about Exchange you’d like us to cover, a comment here is a great way to get our attention. We’re here for you, so let us know what you would like to read.