Outlook for iOS & Android Is Dumping AWS and Heading for an All-Microsoft Infrastructure in Q3
By the time Microsoft Ignite happens in September 2016, the Outlook app for iOS and Android will have an all-Microsoft infrastructure. The Amazon-based cache is being replaced by a new architecture that will be shared by Exchange Online, Exchange on-premises and non-Microsoft email servers like Gmail. It’s a big change and it’s happening now.
When Microsoft bought Acompli in November 2014, I wrote that the deal had transformed their mobile email strategy because it allowed them to move away from some of the restrictions that exist in the Exchange ActiveSync (EAS) protocol. Acompli used EAS to access Exchange mailboxes, but only to fetch message data for interim processing on Amazon Web Services (AWS). Being able to process data retrieved from mailboxes allowed Acompli to create features such as the Focused Inbox that proved enormously popular with users. The downside is that potentially sensitive information contained in messages exists outside the control that companies can normally exert over Exchange and remains on an unknown site for up to 30 days.
Processing client data on AWS is acceptable when you’re a small startup. When Microsoft rebranded the Acompli apps and relaunched them as Outlook for iOS and Outlook for Android in January 2015, the internet had one of its frequent meltdowns about the security of the data accessed by the clients and how that data was stored on AWS. I concluded then that many commentators had overreacted.
To be fair to Microsoft, since the launch of the Outlook apps, they have done as much as they possibly could to address the concerns of corporate security departments about how the apps work. Apart from implementing support for Azure Active Directory Authentication (ADAL, an OAuth-based authentication mechanism) and multi-factor authentication, Microsoft has added a lot of new functionality to the Outlook apps including directory access, rights management, better support for mobile device management policies such as enforcement of PIN length, data encryption, and remote wipe, and integration with Skype for Business and OneDrive for Business.
Microsoft recently shared some information about the new architecture they are putting in place to support Outlook for iOS and Android. As described above, the need for change is pretty obvious. Let’s see what they have planned.
AWS is the sticking point for some customers
Even after addressing other security requirements, removing the cached client data from AWS proved to be the big sticking point that needed to be resolved before some IT departments would support the use of the Outlook apps. “Move it to Azure” was the constant refrain from those who thought they had an answer. On the surface, that’s true because moving all the data to a Microsoft infrastructure provides customers with “single throat to choke” when it comes to questions like compliance, auditing, and data management as laid out in the Office 365 Trust Center, including achieving certification against the requirements laid down in the Compliance Framework for Office 365.
Making a quick move to Azure is all very well, but the problems involved in transforming an architecture that has to function at the scale of Office 365 is a tad more complicated than simply moving data from one cloud service to another. Small items like data sovereignty (where data is stored) have to be taken into account, as must the distributed nature of Office 365, which currently operates over twelve datacenter regions distributed around the world.
Then there’s the need to construct an architecture that will work with the cloud and on-premises versions of Exchange as well as the other email servers that the Outlook apps support. Finally, the changeover must happen in an invisible manner to tenants because no one likes the flow of email to mobile devices to stop, even when massive infrastructural changes occur in the background.
Even after addressing all those issues, another big problem that the new architecture had to solve was to make sure that the Outlook apps could continue to expand their functionality and wouldn’t be limited to whatever features are supported by the Exchange ActiveSync (EAS) protocol. EAS is not going away any time soon as it remains the cornerstone of Microsoft’s ability to support access to Exchange mailboxes from mobile email clients created and maintained by major players such as Apple and the Android vendors. However, there’s a ton of functionality available in Exchange that is not exposed through EAS. Choosing to use EAS as the basis for connectivity would limit the Outlook apps and prevent them from being able to implement features such as access to shared mailboxes and calendars.
Outlook’s new mobile architecture
For the past couple of years, Microsoft has been developing a set of REST-based APIs to allow programmatic access to all manner of Office 365 data, including mailboxes. Mobile apps like Outlook Groups already use the REST-based APIs to access Exchange Online and the REST-based APIs are scheduled to be supported by Exchange on-premises servers too. Much development effort is going into those APIs to make sure that all of the scenarios considered by the Outlook team are available, so the decision was made to use the REST-based APIs to communicate with Exchange Online and other Office 365 components.
The next big issue that had to be solved was how to deal with the proprietary API calls used by the Outlook clients to communicate with the back end. One solution would be to rewrite everything to use the REST APIs, but that would mean that older versions of the Outlook apps could not use the new infrastructure. Instead, Microsoft has put in place a stateless protocol translator that runs on Azure. The role of the translator is to turn Outlook API calls into REST calls, including the translation of mailbox commands returned by servers to be consumed by clients. The translator is truly stateless and no mailbox data is cached on Azure; everything remains safe and secure in Exchange Online and TLS connections are used to secure all client connections.
Figure 1 illustrates the new infrastructure. It’s critical to understand that all of the intermediate processing that was once done on AWS to support functionality such as Outlook’s “Focused Inbox” is now done by Exchange Online. The user’s mailbox represents a single definitive source of information that can be drawn upon by any client, even if some of the data in the mailbox (like the MAPI flags used to mark items to show up in the Focused Inbox) won’t be exposed to clients that access the mailbox using other protocols. Because all information remains in mailboxes, the data is fully exposed for indexing and compliance purposes.
Figure 1: The Outlook app architecture for communicating with Office 365 (Image Credit: Microsoft)
One restriction that is introduced is that an Outlook client can only connect to a single Office 365 region at a time. This means that you can’t setup a client to connect to a mailbox belonging to an Office 365 tenant in the U.S. and another belonging to an Office 365 tenant in Europe.
Customers whose tenants belong to the German or U.S. government Office 365 regions will be unable to use the Outlook apps until Microsoft deploys the necessary infrastructure with a specific dependency being the availability of the Azure protocol translator in those regions.
Supporting Exchange on-premises
The new architecture is simple and elegant when it comes to Office 365, but Outlook mobile clients are also used with many on-premises mailboxes. The answer that Microsoft came up with reveals some out-of-the-box thinking that leverages the size and capabilities of the Office 365 infrastructure. In a nutshell, if your mailbox is on an on-premises Exchange server and you access it with one of the Outlook apps, Microsoft will automatically create a new mailbox-like data cache for you on an Exchange Online server in a special part of Office 365 that’s specifically there to support Outlook users.
Essentially, the Exchange Online data cache serves as a replacement for the temporary processing cache that previously existed on AWS and serves as a place where data can be processed for advanced features that might not be necessarily supported by a server. The data cache for a user is removed if an administrator deletes the account or wipes the mailbox.
Behind the scenes, the contents of on-premises mailboxes are synchronized with Exchange Online using EAS. Enough information is synchronized initially to make the mailbox usable for the Outlook app and eventually the complete contents of the mailbox will be synchronized. Exchange Online uses a form of “drizzle-mode” synchronization to fetch data similar to the way that the Outlook desktop client gradually makes offline replica copies of all folders in a mailbox. Figure 2 shows how the architecture expands to accommodate Exchange on-premises users. The only dependency that is introduced is that the Exchange server must support EAS 14.1, which was first shipped with Exchange 2010 SP1. You have to run Exchange 2010 SP3 or later to be supported by Microsoft.
Figure 2: The new connection between a device running the Outlook app and on-premises Exchange (Image Credit: Microsoft)
The new architecture allows individual devices running the Outlook apps to be identified individually rather than a catch-call EAS connection representing the AWS cache.
Dealing with non-Microsoft servers
The story doesn’t stop there. The Outlook apps for iOS & Android have a very loyal following of users whose mailboxes are on servers that don’t run any version of Exchange and the goal is to provide them with exactly the same app functionality that’s available to users whose mailboxes are on Exchange. The answer is to create an Exchange Online mailbox-like data cache for those users too – for people running Gmail, Yahoo, Outlook.com, or any other email server supported by Outlook. Because the new version of Outlook.com shares some of the same architecture as Exchange Online, its mailboxes are treated exactly the same way as those belonging to Exchange Online.
Once again, a synchronization process is used to fetch data from the user’s “home” mailbox to build out their data cache in Exchange Online. Different protocols are used (like IMAP4 for Gmail), but essentially the same process is followed to make sure that a complete copy of the user’s mailbox is available for processing on Exchange Online. The Outlook clients will interact with that copy of the mailbox. In fact, Google does much the same thing to support Exchange mailboxes for its Gmail client for Android, even if many users don’t realize that their mailbox data is extracted and stored elsewhere.
Unlike the previous architecture, where 30 days of mailbox data was held in the AWS cache, the new architecture aims to have complete copies of user mailboxes available for processing. In particular, this allows Outlook clients to issue search requests that can be handled by Exchange Online without any need to contact the user’s home mailbox.
Of course, synchronizing complete copies of millions of mailboxes won’t happen quickly. Large network pipes exist between Microsoft and other major provides such as Google and synchronization will proceed in the background with little or any impact on the user. The complete copy of their mailbox won’t be available immediately for access by Outlook, but who looks for year-old messages on a frequent basis anyway?
Companies that use on-premises Exchange servers probably don’t have the same kind of internet pipelines as Microsoft and Google have. Accordingly, it is possible that the switchover to the new architecture could cause some strain on internet connectivity as data is synchronized from user mailboxes to Exchange Online. This process will begin in the last quarter of 2016 and it’s something that on-premises administrators will have to keep an eye on to ensure that their internet links are not swamped, especially for users in remote offices.
The elegance and power of the new architecture
The desire to synchronize complete user mailboxes to Office 365 will certainly cause comment. But when you think about it, the solution is both elegant and powerful because it means that Microsoft has a single place to introduce new functionality that will then be available to everyone who uses the Outlook apps, no matter what email server their mailbox is hosted on. For this reason, I consider the new architecture to be both elegant and powerful, admitting of course that implementation of an architecture is often the place where perils lurk.
Microsoft says that they are preparing the new infrastructure with a goal to being able to switchover Office 365 users by the time the Ignite conference rolls around in late September 2016. Interestingly, Microsoft is also updating the REST-based API to support mobile device management policies to allow these policies to continue to work with the Outlook apps as they won’t use EAS any more. This step will allow Microsoft to migrate tenants who have deployed mobile device management policies, a process that will begin once the new API is put into production.
There’s nothing but good in this change. Moving to a completely Microsoft-controlled and managed environment will give customers more confidence in deploying the Outlook apps in tandem with Office 365, especially those outside the U.S. who have always had a problem with the notion of the cached data kept on U.S.-based servers. Using exactly the same architecture to serve users of both on-premises Exchange servers and non-Microsoft email servers is an excellent approach to what seemed to be a difficult problem. Let’s hope that it works well in practice.
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.