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

With Ignite wrapping up a month ago, Microsoft released some information on the Future of Exchange not only concerning a new version but also with tieing it more to the cloud. Previously Microsoft revealed that Azure can be utilized for you File Share Witness (FSW) for Exchange and now you can now install Exchange in the cloud. Yes…. you can have your Exchange organization hosted in the Azure cloud. For those of you who think this is a good thing, there are caveats which we will discuss in this article. For those who are critical of this move, there are benefits to using this model which may or may not be obvious.

I will quickly cover your options in Azure for these scenarios:

  • File Share Witness
  • Hybrid Server
  • Stretching your DAG into the Cloud
  • Moving Exchange completely into Azure


Microsoft and Supportability

When Microsoft came up with this idea, they came up with a list of requirements to ensure that the configuration would be supportable. They also came up with a list of Azure/Exchange scenarios:

  • Dev / Test Environments
  • File Share Witness
  • Production – using Azure Premium Store

AzurePremium
The irony with Azure Premium Storage is that in the Preferred Architecture for Exchange, according to Microsoft’s own words, JBOD is the recommended configuration using 7200RPM SATA drives. With the Exchange IaaS offering requiring Azure Premium Storage, the drive requirements are vastly different ….

Azure – File Share Witness

This option was opened up in January of 2015. According to the support page in TechNet – HERE – Azure was to be used as a third datacenter for your Exchange deployment. For Example, if your Exchange Organization consists of two internal datacenters used to host Exchange 2013 CAS/MBX servers you can utilize Azure for a third site to put your FSW in case of an entire site failover. This configuration would require a multi-site VPN.

FSW-Azure1


One caveat to a Multi-Site VPN requires a manual change to the network configuration files and cannot be done in the Management Portal.

So why put a FSW in the cloud? Why not host this on a local server or in an additional site. Your decision comes down to a few factors:

  • Uptime requirements – having a FSW in an additional site can provide for additional reliability for your DAG in case of large failures –> All servers in a site or a complete site failure due to a major power outage or catastrophe
  • Site availability – do you have an additional
  • Cost – Do you have budget for this configuration? What will the ROI be in case of failure?
  • Management – if your company already has VMs in Azure then your administrative load should not increase if the server is on site or in Azure. If you do not have any existing VMs, then the decision might be affected by having an additional piece to manage.

Azure – Hybrid Server Placement

Since Exchange 2013 can be placed in Azure, that means you can also deploy a Hybrid server in the cloud as well. If you are using a version of Exchange prior to Exchange 2013, this could either be a beachhead for your Exchange 2013 environment in Azure or simply your connection to your Office 365 tenant for a full move of your mailboxes to the cloud.

One consideration for placing a Hybrid server in Azure is what to do with your ADFS servers? These can be placed on Azure VM’s as well. Would it be worth it to move a chunk of your configuration, including servers that all talk to each other, into Azure? If so, make sure to do some research on ADFS in Azure and read helpful articles like this one with tips and tricks to making this process go smoother.

Hybrid

Azure – Second or Third Exchange Site

Let’s say you don’t have a DR site as of yet. No second physical location, no datacenter to host a second copy or third copy of your databases. Exchange IaaS gives you the options to spin up some VMs in Azure to handle this particular function. Like all Exchange deployments costs, VM sizing and network considerations should be taken into account before setting this up in production. Microsoft also recommends that ExpressRoute be used to make this connection for Exchange.

SecondSiteASecondSite2

















Microsoft gives the following reasons for utilizing ExpressRoute as it will provide the following features:

  • Private connection to Azure
  • Increased sped and reliability
  • Lower latencies
  • Higher security
  • Cost benefits

Pricing can be found here and it ranges from $436/mo. for 10Mbps to $11,700/mo. for 1 Gbps [includes premium Add-On]. The FAQ on Express Route can be found here as well.

Azure – Total Exchange Replacement

If your were looking to virtualize your Exchange environment, move your expensive Exchange servers and storage into a hosted environment or looking for greater reliability than what your current hardware/virtual solution can provide, then Exchange IaaS might be the way to go. Make sure you understand the costs and requirements of such a move. Express Route may be needed, Azure Premium Store is required and so on. The move might be more of a solution if you already have an existing Azure infrastructure. This infrastructure will make the transition much easier that a move to a bare environment.

MoveAll

Don’t forget that while your VMs are in Azure, which is essentially a third party datacenter, this is not a hosted solution where someone else has been contracted to maintain your servers. You are still responsible for software updates / upgrades such as Exchange and the Operating System. Do not forget the max server specs of ~ 20 cores and ~ 96 GB of RAM when sizing your Exchange VMs for Azure. You will also need to assign static IP addresses just like on-premises servers. Multiple sites can be configured and is a recommended configuration per the Microsoft Exchange Preferred Architecture. Other recommendations include setting up a new ‘region’ for your FSW, using IP-less DAGs and minimalizing the number of DAGs that are placed in Azure (in other words, use larger/fewer DAGs rather than smaller/more DAGs).

Backups will always be an issue in Azure. Follow the Preferred Architecture recommendations to facilitate recoverability.

Final Thoughts

At this point I would be hesitant to recommend the above options for any client. My biggest concern is cost and not reliability. Microsoft has spent plenty on their infrastructure to make sure it is fast and reliable. Their servers and storage appear to be top-notch. If I were asked about this as an options, my first question would be, do you have any additional sites or hosting datacenters in which to place your Exchange infrastructure. If they do not, the next question would be, what about going to Office 365, if you are considering this route seriously? If that is not an option, then I might recommend Exchange in Azure. I Would have to make sure that they understood the caveats about Azure Premium Storage, the use of Express Route and finally any other pieces they may need to configure on their side to get their Exchange infrastructure in Azure.

As Microsoft stated clearly, this is not Exchange in the Cloud, it is not Office 365, this is essentially a hosted solution for Exchange. It may not be cost-effective, depending on your environment. It may not even make sense. However, the option is now out there for those who want to give it a go.

As a pure test environment, I can think of cheaper ways to go either through hosting or cheaper local hardware. If you have a virtual environment with existing capacity then this should be your first choice. If you cannot get budget for more hardware/storage, then maybe this is a viable testing option.

In the end, it is up to you. If you have an Azure infrastructure in place, then this might be a great addition. For those looking to dip their toes into Azure, this may not be the best first choice.

Further Reading

Azure Load Balancer Overview
Azure Load Balancing

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s