Exchange is a lifeline of virtually every business in this world. It could feel like the end of the world when your email is slow. So when it’s time to upgrade your mail servers there’s always careful planning and lots to consider especially in a time when IT departments are tasked with providing cost savings. I often get asked how should I upgrade or should I go to the cloud and leave the work to Microsoft. What about virtualization and is it really supported architecture This post is to help you evaluate your options. It has some technical knowledge, opinions and some rants along with Star Trek references but most of all I hope it to be useful for you. So let’s begin looking at whether you should deploy Microsoft 365 Email or Virtualize Microsoft Exchange On-premises…
Deploy Microsoft 365 Email – Small Ship – Be Part of the Collective
If you are a company with 200 or less employees and you are considering upgrading your Exchange environment, do not upgrade, just be assimilated by the Microsoft 365 Borg. Go to the cloud! When I say cloud I mean Microsoft 365. Given the amount of training and knowledge needed to run an exchange environment for a small environment on-premises you are much better off letting somebody else do the hard work, ie Microsoft. Be part of the collective and your IT staff can focus on other matters.
M365 has many offerings with different price points that can meet your needs. Deploying Exchange on premise with all the bells and whistles is a lot of work and maintenance. The time needed to babysit Exchange is not worth it when you get everything in MIcrosoft 365 without all the hard work.
Resistance is not always futile
For medium and large enterprises, you have some options besides being assimilated by the Microsoft 365 Borg. If you choose not to be assimilated, I first recommend you read up on Microsoft’s Preferred Architecture (PA) written by Ross Smith IV on the Exchange Team’s blog. Some like to refer to this as the gospel blessed by the Exchange Gods and if you follow you do not need to make your daily sacrificial offerings as all will be well with your mail servers. For those of us that don’t drink the Kool-Aid refer to this as a reference guide with recommendations for the best performance if you meet the requirements with daily sacrificial offerings as optional.
The Preferred Architecture (PA)
[SPOILER ALERT if you have not read the PA]
I personally think the PA is cute. It’s 2016, we are in a virtualized world. Just like the Matrix. We now live in containers that are living in containers (Google Docker if you have no idea what my containers reference is) while Microsoft is preaching physical servers are better. Yes, boys and girls, Microsoft prefers you to run Exchange on physical servers with just a bunch of disks. Keep it simple for your servers, remove hypervisors and SANs, then use Exchange High Availability and only worry about activating databases in the event of a failure. Hmmm… Does this mean a cute Keanu Reeves is going to save me from the Matrix???
I do not completely disagree with the preferred architecture; in fact, I actually agree with the components of it, except for the requirement for physical hardware. In the real world, we all have different technical and business requirements. Such as when you are mandated to reduce hardware footprint in the datacenter without taking email to the cloud. Perhaps you just want to utilize your investment in your virtualization platform. In these cases, the PA may not be ideal and that is OK, even Microsoft says that’s ok (see screenshot). They may not like it but it is ok to not follow the gospel. It just means you deploy Exchange in other supported architecture designs.
Virtualization
Now back to options for deploying Exchange when you are not being assimilated by the Borg. You can either deploy Exchange following the PA and run physical servers or virtualize your exchange servers. Yes, my friends, virtualizing exchange on premise is fully supported BUT there is a caveat. If you are going to do it, do it the right way or you could have a big headache to deal with. Virtualizing Exchange servers is not like any average application. It has special needs and requirements, which when these are not met, it can bring havoc into your messaging environment. There is published guidance on virtualizing Exchange that can found on Technet. Follow it, share it with your virtualization admins, then practice it, and all will be good with the Exchange servers. You can also check out a blog post I wrote 3 years on Petri.com “Virtualizing Microsoft Exchange Tips and Tricks”. If you are short on time or just don’t feel like clicking on the links to read the other posts below is brief recap of what is key to look out for when virtualizing Exchange.
Tips for Virtualizing Exchange
- Read the fine print. Before you start spinning up VMs, take a glance at Microsoft’s support statement for Virtualizing Exchange servers. Doing a little research goes a long way to determine the right needs for your particular environment.
- Reserve CPU and Memory – Exchange does not like Hot Add or Dynamic memory and CPU reductions. These can have a negative effect on the performance of your Exchange servers. Slow performing Exchange server means unhappy users.
- Do NOT vMotion a running Mailbox server with active databases – Exchange does not like vMotion of active Mailbox servers. There is no reason to be using any time of vMotion or Live migration for Exchange if you are using a DAG. If you’re running a DAG you don’t need to migrate your vms because your passive databases on another VM would handle the high availability of the mailboxes. Just worry about activating databases.
- Disable DRS and Storage DRS – See recommendations for vMotion and Live migration.
- Know your underlying storage – quoting myself from Petri.com “Exchange does not support NFSfor Exchange data. Storage presented to an Exchange VM must be block level storage. NFS is a common protocol used in a lot of VMware environments; if you are in one of them, you will need to look at other protocols to present the storage to yours VMs. The ideal way of presenting storage to an Exchange VM is to use pass-through storage from the host to the VM. Software iSCSI inside the guest VM is also supported, but there are performance considerations you must account for.”
The 3rd non-option
So now we going to discuss my “favorite” option that I don’t consider really an option, which is running Exchange in the cloud from Infrastructure as a Service (IaaS) like Amazon. The official support statement for running Exchange in the cloud on IaaS like Amazon Web services is sort of cloudy. It is cloudy because technically virtualizing exchange which is supported as long as fully meet the technical specifications for running Exchange Non-Microsoft hardware virtualization software. Once you’ve read that feel free to browse the Server Virtualization Validation Program (SVVP) validated solutions. Long, complicated and time consuming to click and read huh? Imagine having to do that all the time to make sure your IaaS providers hypervisors are supported. This is on top of making sure they have configured the Hypervisors to the specific set of requirements you need such as reserved resources.
My take on running exchange on IaaS is that it’s not worth it when you can go straight to Office 365. If you want to virtualize Exchange for cost savings, then stay on premise. Staying on premise allows you more control of your hypervisor, it’s your hardware you can update it when you choose too and are not dictating by a hosting provider. Why deal with the headache of trying to figure out if your provider has met all the specifications?
Running Exchange in Microsoft Azure is supported, that’s obviously not a surprise to anybody. I don’t think I have to explain anything else there… But in my opinion running Exchange in Azure is just as pointless as Amazon Web Services because there’s Office 365.
There is a way out of every box, a solution to every puzzle; it’s just a matter of finding it.
So there you have it, your options for deploying Exchange. If you are thinking about running Exchange in the cloud on IaaS, then you may want to deploy Microsoft 365 Email. Just call up your Microsoft TAM and tell him/her you want to be assimilated to the Microsoft 365 Borg. For those that don’t want to assimilate or cannot for certain compliance reasons, you can go physical or virtualize. I recommend using the Exchange role calculator to determine what your hardware requirements will be. The calculator can give you an idea of your hardware/virtualization requirements will be for your environment. Compare the 2 scenarios and the costs associated along with your business requirements to determine what would be the right fit for you. Good Luck.