Stay with Exchange ActiveSync or Embrace Outlook Mobile?

Choosing Between Native Email Clients and Outlook

With the October 1 deadline approaching for the launch of the last phase of the great basic authentication turn-off project, Microsoft is cranking out tweets to remind tenant administrators of steps they should consider taking to prepare for the transition. One tweet that seized my attention was the recommendation to use Outlook mobile (Figure 1).

It’s not as if Microsoft has ignored other email clients in the drive to disable basic authentication for email connection protocols. A joint project with Apple arranged for the automatic upgrade of email profiles on millions of iOS and iPadOS devices to use modern authentication. Apple “native” email clients have used Exchange ActiveSync (EAS) to connect to Exchange servers for 15 years or thereabouts and the iPhone is a very popular device with Exchange Online users. Working out a joint approach to help Apple devices move to modern authentication reflected a pragmatic realization that Microsoft could not move forward with their plans if millions of corporate iOS users were left with non-functional email clients.

If you reflect on how things have transpired during Microsoft’s campaign to remove basic authentication, the nagging doubt might emerge that EAS clients might be exposed to other issues in the future. That, and a growing functionality gap that I’ll explore in this article might be enough to force organizations to move away from EAS clients to embrace Outlook.

Two Categories of Mobile Devices for Exchange

Mobile devices connected to Exchange Online mailbox split into two camps: those that use Outlook mobile and those that use Exchange ActiveSync (EAS). That wasn’t always the case. Pre iPhone, the Blackberry was the mobility king. Microsoft didn’t particularly like the dominance that Blackberry enjoyed for Exchange mobility. They, therefore, delivered the Exchange ActiveSync protocol in Exchange 2003 Service Pack 1 to connect mobile devices to Exchange Server.

Exchange ActiveSync

In those days, mobile network costs to transmit data were much more expensive than they are today and the networks and devices were less capable of handling large quantities of data. EAS operates on the basis of long-standing HTTPS transactions optimized for high-latency, low-bandwidth connections. The client takes out subscriptions for server folders like the Inbox and Calendar. When changes occur in these folders, Exchange lets the client know that it needs to process transactions such as downloading new messages or updating a calendar event.

Paul Robichaux once described EAS as working like Reese’s Peanut Butter Cup. I never really understood this analogy, but the YouTube video survives to this day and it’s a reasonable explanation of how EAS connects mobile devices to Exchange.

EAS worked well in the days before copious network availability and it continues to work efficiently and effectively today. EAS clients support modern authentication too, so there’s no more danger that their usage will expose accounts to compromise than Outlook mobile does.

Around 2006, Microsoft began to sell EAS licenses to mobile device vendors with the intention of making the protocol the lingua franca for Exchange mobile connectivity. Microsoft was very successful and major vendors like Samsung and Sony duly signed up, followed by Apple after the launch of the iPhone in 2007.

Today, EAS maintains its position as the go-to protocol for mobile devices that want to connect to Exchange (server and online). The alternatives are POP3 and IMAP4, both antique and largely obsolete protocols. Although mobile clients based on these protocols exist, they are uncommon. In the enterprise, it’s either Outlook mobile or devices running EAS. Most native mail clients available for mobile devices from hardware vendors use EAS.

Outlook and Acompli

Before Microsoft acquired Acompli in December 2014, the mobile client strategy for Exchange Online was messy (to be polite). At the MEC 2014 event in Austin, Microsoft discussed the wonders of OWA for Devices, a plan to leverage the browsers built into mobile operating systems by wrapping them around OWA to deliver a mobile client. On the surface, the idea seemed reasonable. As Microsoft delivered features for OWA, the features would appear in OWA for Devices on mobile devices and the world would be a better place.

The idea seemed good until Acompli came along and people realized what a real mobile client could deliver. Outlook mobile was born with iOS and Android clients and OWA for Devices headed to the software scrapyard.

The new Outlook mobile didn’t use EAS. It had its own way of processing mobile data and making it available to clients. This approach allowed Acompli to create the focused Inbox, a feature that’s now available in all Outlook clients. Microsoft faced challenges to make Outlook mobile an acceptable client for enterprise use… In its early days, the client used data held in AWS, essentially copies of mailbox data formatted for use by Outlook mobile. This situation persisted until mid-2016 before Microsoft could transition the data to Azure. Since then, Microsoft has refined the synchronization technology to make sure that the data fetched from Exchange mailboxes is optimized and capable of supporting advanced features such as sensitivity labels.

Functionality Drives Choice

Available functionality is the basic yardstick for choosing between EAS and Outlook. EAS is now an old protocol that Microsoft maintains but does not actively develop to keep pace with the evolution of server features. Reflecting its age, EAS does what you’d expect a mobile email client would do in 2010. It can synchronize with an Exchange mailbox to download and send emails, interact with the calendar, create tasks, and use contacts.

Outlook mobile delivers the same functionality and more. For example, EAS clients don’t support access to shared mailboxes or group mailboxes (Outlook groups), nor does EAS support delegate access to mailboxes. In the past, some complained that Outlook mobile restricted their ability to connect to mailboxes in multiple Microsoft 365 tenants. That isn’t the case today.

The same functionality gap exists with encrypted email. Mobile email clients usually don’t have problems with industry-standard encryption like S/MIME, but in a Microsoft 365 environment, there’s increasing use of sensitivity labels to protect access to email and document content. Sensitivity labels use rights management to understand who’s allowed to interact with items, and Outlook mobile supports this capability. However “unenlightened” clients like the iOS mail app can’t read protected messages until the server decrypts the messages for them. To make this happen, a tenant runs the Set-ActiveSyncOrganizationSettings cmdlet to update the AllowRMSSupportForUnenlightenedApps setting to True:

Set-ActiveSyncOrganizationSettings –AllowRMSSupportForUnenlightenedApps $True

Server-side decryption works for messages originating from the same Microsoft 365 tenant. However, protected messages from another domain won’t be decrypted. The downside of server-side decryption is that you end up with unprotected messages on mobile devices, which is probably not what you want. After all, there’s a reason why someone protected a message in the first place.

The Device Management Question

Exchange Server’s mobile device management capabilities complete with PowerShell cmdlets transitioned to the cloud. Much the same set of features is available in Exchange Online today. Policy-driven control over what devices can connect to Exchange is effective, and it doesn’t require additional licenses. If you just want to control mobile email clients, Exchange’s mobile device management will do the job, including exerting some control over Outlook clients. Figure 2 shows how easy it is to configure a device access rule to block Outlook mobile.

Synchronization attempts by Outlook mobile after the device rule is an effective fail. Outlook mobile notifies the user that their account “has been blocked on this device by your administrator” and Exchange sends them an email to say that the device is temporarily quarantined. Of course, the user can’t read the message because they can’t synchronize, but they’ll see it the next time they get to another client.

Not much has changed in EAS management since Paul Cunningham wrote about it in 2017. That’s because Microsoft maintains but does not enhance EAS management. Instead, their eyes are fixed on MDM solutions like Intune that offer organizations more control over devices and apps. In other words, MDM covers much more than email clients, which is why Microsoft 365 mobile device management is all about Intune. At least, it is from a Microsoft perspective. Other MDM solutions are available from ISVs that deserve your consideration.

Two variants of Microsoft 365 MDM exist. This page describes the licensing requirements and the functionality differences. In a nutshell, you have:

• Basic MDM is included in some Microsoft 365 plans and the Office 365 enterprise plans.
• MDM (Intune) requires another license such as Enterprise Mobility and Security E3. Intune includes Mobile application management (MAM), which you might need to manage BYOD devices.                                                                                       

Given the need to take a more holistic approach to device management than simply focusing on email, it’s a sad but inevitable fact that the mobile device management facilities included in Exchange Online are the bare minimum.

The Big Problem for EAS

The problem that’s evident here is that technology developments are outpacing the ability of the EAS protocol to make features available to the developers of email clients. Two critical issues are at play. First, the EAS protocol doesn’t support these scenarios, but even if Microsoft extended EAS to add support for other types of mailboxes and for delegate access, you wouldn’t be able to use the functionality unless the developers of native mail apps updated their GUI to expose new features.

No guarantee exists that the developer of any EAS-based client would use any new feature Microsoft includes in the EAS protocol, and each vendor could implement features differently. Every email client needs to cover the basics of sending and receiving email, but asking their developers to create and maintain a new interface for a specific Exchange feature is a different matter.

Personal Choice and Inertia

Facilitating user choice is often an influence when an organization defines its mobile device strategy. If that’s the case, then you’re going to have to cope with a variety of devices and EAS is a great choice as a common protocol for mobile email. But if you want to do more with mobile device management and invest in an MDM solution, then the better choice might be to standardize Outlook mobile for email. I’ve used the client ever since Microsoft bought Acompli. The native clients now seem remarkably unsophisticated when I test them and I see no reason to move back. Now that I’ve made my choice, what will yours be?