A Blog About Exchange & Office 365

Menu

Exchange in The Cloud, No Not that Cloud! (Part 2)

In Part 1 of this series I covered the various options that Microsoft supports for Exchange in Azure. This second and final part will cover load balancing, transport for Exchange in Azure, networking options, backups and other options beyond Azure and some miscellaneous notes on Exchange in Azure.

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].

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.