Load Balancers
As with any Exchange 2013 installation, planning for your load balancing needs should be done before deploying Exchange itself. Azure provides a couple of options for load balancing for Exchange Server in Azure. Of the preferable option would to either use the Network Level load balancing or using a third-party approved load balancer in Azure [Kemp has this capacity today].
Notes from Ignite 2015 on Load Balancers in Azure
- Azure Load Balancer sufficient for many scenarios
- Increase idle connection timeout to handle long duration connections from Exchange clients
Set-AzureLoadBalancedEndpoint –IdleTimeoutInMinutes 15 - Connection distribution is not round-robin or least connections – using hash distribution instead
- Health probe can either be http or ping probe
- Various 3rd party options available for additional functionality
Read up on the capabilities and setup options in the links at the bottom of the page. Then plan for your implementation in the cloud. If you have existing Load Balancers in Azure already, make sure they can handle the additional load and are configured per MS settings for Exchange.
Transport Considerations
If your Exchange servers are completely moved into Azure, then there are some considerations that Microsoft would like your to review:
- IaaS providers typically not worried about IP reputation, commonly used by spammers to send UCE
- Delivery failures common (connection filtering with 3rd party blocklists)
- Consider outbound relay service for SMTP to Internet
- EOP now properly handling certificate authority from Azure VMs, EOP standalone offers are a good solution
If your Exchange organization is simply split into Azure, then these Transport recommendation may not be of concern. Just be aware that you need to design your environment to make it as supportable as possible from Microsoft.
The gist of the recommendations are that now your Exchange servers are in the cloud and their IP addressing may not be under your control. This means that some providers will not allow your Exchange servers to send them due to SenderID, SPF, DMARC or PTR (reverse DNS) look up failures. EOP is one possible path for your mail flow, however, if you are not using EOP, ‘relaying’ or using a third-party provider for email transport outside of your environment is a supported path. This could cause your organization to incur additional costs. The majority of my clients, regardless of mail system, have some sort of hosted solution for this like Barracuda, Message Labs and Microsoft EOP for their messaging hygiene. Like all other caveats, you now have information that will hopefully make any transition plans easier and smoother to execute.
Backups
Backups in the cloud are still of concern. Yes Azure now has backups, but they are not nearly as robust as an on-premises solution. The same can be said of Exchange IaaS. If you are stretching your DAG, then backing up the local copy would overcome this limitation. Make sure to keep this in mind as you are designing your architecture / infrastructure for Exchange IaaS. Backups (and restores!) require an entire design meetings to make sure this element of your infrastructure is properly vetted out prior to going into production. Before I get berated for not mentioning that you can use DPM in Azure for workloads, I did check their latest news and I do not believe Exchange is yet covered. Here is the original announcement of using DPM to protect Azure Workloads.
Further Notes for Exchange Iaas
Active Directory Recommendations:
- Use Windows Server 2012 or later for rollback prevention via VM-GenerationID
- Each deployment region should be an AD site
- Plan for VPN connectivity to enable replication with on-premises AD (or use ExpressRoute)
- ADFS deployment works great, follow on-prem deployment guidance
- Use static IPs (important for DNS config)
- Use availability sets to improve overall availability
Network Recommendations
- Each region will need a virtual network defined
- Virtual network definitions include IP subnets, DNS servers
- Azure regional virtual networks are connected with site-to-site VPN
- On-premises networks connected via VPN or ExpressRoute
- Azure network configuration defined in XML, applied with PowerShell
- Set-AzureVNetConfig
- Plan load balancer configuration for client access
Other options
If you are like most of my clients, your second or third sites for Exchange Server are either at a real datacenter or in a different physical location that your company owns. Using a service like Azure should provide a similar experience. However, even Microsoft states that this configuration is not necessarily ideal. That using a different service or method to provide this level of redundancy might be better or cheaper somewhere else. Microsoft would rather you utilize the scale and services of Office 365 before venturing into Azure for Exchange / messaging solutions. Something to keep in mind.
Further Reading
Azure Load Balancer Overview
Azure Load Balancing
Azure Backups 1
Azure Backups 2
Azure Backups 3
