A little Introduction
Some organisations, would still prefer hosting their own Exchange server(s), rather than migrating to Office 365. And since the Cloud is the way to go for many organisations, deploying an Exchange server in the Cloud, be it Azure or AWS, could be challenging on so many levels. This includes latency, failovers, data disk corruption, replication and so forth.
If you’re unsure on how to start, unfortunately Azure does not provide a free test drive for Exchange server (as of this writing). Fortunately however, a free test drive of Exchange 2013 is available in AWS (excluded from the blog). Nevertheless, Microsoft does provide a guide for deploying a test/dev Exchange 2016 in Azure found here .
Also, this blog will not go into details on server (hardware) requirements and step-by-step Exchange Installation. This blog assumes you have knowledge of either Azure or AWS, and Microsoft Exchange.
Note that previously Exchange server was not supported in Azure, but this is no more as Microsoft now supports the platform if deployed in Azure.
Deployment of Exchange 2016 on Infrastructure-as-a-Service (IaaS) providers is supported if all supportability requirements are met. In the case of providers who are provisioning virtual machines, these requirements include ensuring that the hypervisor being used for Exchange virtual machines is fully supported, and that the infrastructure to be utilized by Exchange meets the performance requirements that were determined during the sizing process. Deployment on Microsoft Azure virtual machines is supported if all storage volumes used for Exchange databases and database transaction logs (including transport databases) are configured for Azure Premium Storage.
You can read more about it here and here .
Exchange in the Cloud
Assuming one Exchange Server 2013 will be deployed in Azure, the only supported way to send email to external domains from Azure compute resources is through an SMTP relay (otherwise known as an SMTP smart host). The Azure compute resource sends the email message to the SMTP relay, and then the SMTP relay provider delivers the message to the external domain. Microsoft Exchange Online Protection is one provider of a SMTP relay, but a number of third-party providers also offer this service.[1] Symantec Cloud is one service that provides SMTP relays, as detailed in the design below.
[1] https://blogs.msdn.microsoft.com/mast/2016/04/04/sending-e-mail-from-azure-compute-resource-to-external-domains/
As this blog is about Exchange in the Cloud (Azure), our focus will be on that. The above diagram takes into consideration a complete failover of the primary site. That is, the Azure Exchange server will be responsible for sending and receiving emails as well, should the primary site goes down.
Installing Exchange in the Cloud, be it Azure or AWS is fairly similar to that of on premise deployment. You can also successfully deploy DAG.
Exchange Deployment Consideration
There are many shapes of organisations, large organisations, mid-size organisations, enterprises, small organisations, start ups and so on. Why then should any of these organisations host an Exchange server in Azure? The short answer is that they shouldn’t.
In some rare scenarios, and temporary solution it might be advisable to host an Exchange server in Azure. These include if an organisation doesn’t have a secondary datacentre to host another platform for redundancy (or DAG in Exchange terms). In an other case if a company is planning to move to Office 365.
The only reasonable solution for hosting an Exchange server in Azure would be for setting up DAG, but this scenario applies on large organisations.
Exchange in Azure
The following considerations are required for an Exchange server deployment in Azure:
- Virtual Network
- Virtual machine (adhere to Exchange recommendation as per Microsoft’s best practice)
- Availability Set
- Public Load Balancer
- Network Security Group
- Smart host
And don’t forget about your witness server, depending on your environment.
The trickiest part in this deployment however lies within the load balancer, whether on premise or in Azure. You could use Azure Load Balancer for your Azure deployed Exchange server, or get KEMP LoadMaster found in the Azure Marketplace (my personal recommendation, although more costly), this would even allow you to also load balance between Azure and external network. While Azure Load Balancer can only load balance in the same VNet region.
There are many articles out there discussing topics on Exchange in Azure, however I would recommend checking Microsoft’s own Exchange on IaaS: Concerns, Tradeoffs, and Best Practices here .
Conclusion
Should an organisation really have Exchange on IaaS? It really depends on the company and requirements. The best solution however, is to have a hybrid deployment (Exchange/Office 365), or an ideal solution is to completely move to Office 365.
I hope you found this informative. Please add your comments below.
Thank you for reading.