Running Exchange 2013 on Amazon Web Services

There's lots of interest around cloud application platforms like Azure and Amazon Web Services (AWS). Microsoft won't provide support if you run Exchange 2010 or Exchange 2013 on a cloud platform, but that doesn't stop people doing the heavy lifting to figure out the technical complexities that exist in making applications like Exchange work well on these platforms. I recently spent some time playing with a test drive of Exchange 2013 running on AWS. Everything worked quite well. A pointer to the future?

I’ve covered the topic of using Amazon Web Services (AWS) to host Exchange when I speculated on when cloud application platforms might become commonplace for applications such as Exchange. Today, Amazon offers an Exchange 2010 hosted service based on AWS (a guide is available from Amazon) and I speculate that work is ongoing inside Microsoft to figure out how to best support Exchange on the Azure platform. It’s been proven that it is possible to run Exchange 2013 on Azure, but there’s a world of difference between being able to install and run software and being able to provide a guaranteed level of support.

For now, the Microsoft position is that they do not support Exchange when deployed on a cloud application platform. This position was well enunciated by Jeff Mealiffe at the recent Exchange Connections conference. It means that if you encounter a problem when running Exchange on EWS or Azure, you won’t get support unless you can replicate the problem on a supported platform (physical or virtual server). In fact, the position is the same as in the early days of virtualization when VMware proved that Exchange 2003 worked well on their platform but Microsoft would not support virtual servers until they had to on their own hypervisor.

Recently I took a look at a test drive of Exchange 2013 on AWS offered by a company called Apparatus. The offer was simple. Sign up and Apparatus will build out a sample Exchange 2013 environment that you can then use for four hours. It sounded like a reasonable thing to check out, so I signed up and hit the button to build the lab.

The lab was ready 25 minutes later. I received an email giving me connection details and I used RDP to connect to the test drive environment composed of two Exchange 2013 CU2 servers (standard edition) configured in a Database Availability Group (DAG). The lab comes complete with a handbook to coach you through the steps of connecting to the servers, using the Exchange Administration Center, and connecting to Exchange with various clients. All pretty simple stuff so far before the lab moved onto details of how to test Exchange high availability by stopping all the services on one of the DAG nodes to observe how the databases failed over to the other. Again, not too hard.

Everything worked as expected with the exception of outbound messages, which stubbornly refused to be delivered to either my Office 365 tenant domain or Gmail. However, inbound mail worked smoothly. I’m sure that some minor glitch occurred in the background to stop outbound mail flow as the lab guide sets the expectation that bidirectional email is supported.

The configuration is limited through some customization of RBAC roles so that you cannot access all features. A quick check with EMS revealed that 174 cmdlets were available to the Administrator account against the normal 965 that would be available if the account was not restricted. This is similar to what happens with Exchange Online in Office 365 where RBAC is used to remove access to the cmdlets used to manage features like high availability for on-premises servers. So you can’t create a new DAG, for instance, nor can you play around with roles and permissions. I was able to create a new database (DB3 in the screen shot).

The Apparatus people are careful to point out that the configuration they provide is not representative of a production environment. Instead, it’s intended to demonstrate that complex applications like Exchange 2013 can run on a cloud application platform. I’m sure that a lot of work was necessary behind the scenes to make AWS work with Exchange 2013, but that’s always the case when new computing paradigms hove into view.

The point that I took from the test drive is that cloud application platforms are maturing quickly and that the time when we will be able to use AWS and Azure to host Exchange 2013 and future version in a supported manner is approaching quickly, perhaps faster than first anticipated. 2014 might be the year when things really happen in this space. In the meantime, maybe you’d like to check things out and take a test drive to kick the proverbial tires of the AWS platform.

Happy Holidays!

Follow Tony @12Knocksinna

Discuss this Blog Entry 2

on Dec 24, 2013

Tony
You said "Apparatus did build out a sample Exchange 2013 environment on AWS".
It would great if in the future we the Engineers/Admins could build Exchange 2013 environment on AWS or Azure & then manage/control it too.

on Dec 28, 2013

AWS provides pre-configured virtual machines... and it is great thing to build Exchange 2013 environment on AWS that you said in this post...
thanks for sharing this information with us!!!
Ref: web hosting india

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×