Two topics deserve some discussion following the release of the Outlook Web App (OWA) for iOS apps. First, why are the apps only usable against Office 365 domains? Second, what aspects of the mobile device management capability built into Exchange do these apps leverage?
The news that you could only use the OWA for iOS apps against an Office 365 tenant domain came as an unpleasant surprise to some. In fact, your tenant domain needs to be running the latest version of Exchange 2013, so if you haven’t yet been upgraded to the Wave 15 applications you’re as plumb out of luck as those running on-premises Exchange.
But that’s not strictly true because OWA for iOS does connect to on-premises Exchange 2013. Several people have proven that this is possible using Exchange 2013 RTM CU2. However, Microsoft does not support this configuration and, strictly speaking, on-premises customers will have to wait until Exchange 2013 RTM CU3 before they have a chance of support.
And don’t even think about OWA for iOS if you run Exchange 2007 or Exchange 2010. The simple fact is that Microsoft is highly unlikely to retrofit these versions of Exchange with all of the updates necessary to support OWA for iOS. All of this means that the OWA for iOS apps become another entry on the list of reasons to support a migration to Exchange 2013 (or Office 365), which is probably what Microsoft wants. After all, if you support a large community of iOS users, doesn’t it seem like a good idea to provide them with the best possible client experience?
Moving on to mobile device management, the concentration up to now has been on Exchange ActiveSync (EAS), so the question really is what EAS management components do the OWA for iOS apps leverage.
The ability to allow, block, or quarantine (ABQ) mobile devices is important in terms of managing connectivity to Exchange. EAS includes some nice ABQ capabilities in terms of organizational policies and mobile device access rules, but my testing reveals that the OWA for iOS apps ignore ABQ restrictions. In fact, the only element of the EAS infrastructure that the OWA for iOS apps appear to respect is the wipe remote device capability. That’s an essential feature to have, but it’s disappointing that administrators cannot block iOS devices that connect using these apps.
To test the capability, I created a new mobile device access rule using the New-ActiveSyncDeviceAccessRule cmdlet. I elected to block devices running OWA for iOS by specifying the string “OWA for Devices on iPhone (DeviceType)”, which is specified by devices running these apps. You can discover this by running the Get-MobileDevice cmdlet (Exchange 2013 or Exchange Online) or Get-ActiveSyncDevice (Exchange 2007 or Exchange 2010). The switch in cmdlet name reflects a concentration on “mobile connectivity” rather than EAS going forward.
The ABQ rule I tried is something like this:
New-ActiveSyncDeviceAccessRule -QueryString "OWA for Devices on iPhone (DeviceType)" -Characteristics UserAgent -AccessLevel Block
Naively I thought that I had done all required to block OWA for iOS connections. And indeed, when I examined details of a device after setting the block, I found that its device access state was set to be “Quarantined”.
DeviceType : OWA for Devices on iPhone DeviceUserAgent : Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_3 like Mac OS X) AppleWeb DeviceModel : iPhone (iPhone4,1) FirstSyncTime : 16/07/2013 18:03:20 UserDisplayName : Tony Redmond DeviceAccessState : Quarantined DeviceAccessStateReason : Global
But the device continued to connect and mail stayed flowing. Cue consternation!
Some behind-the-scenes conversations then ensued and I discovered that Microsoft regards OWA for iOS as a “trusted application”. After all, Microsoft wrote these apps and therefore all is sweetness and light. On the other hand, that nasty code written by Apple or the Android people is absolutely open to control by ABQ access rules, as (curiously) is Windows Phone devices or the Windows 8 mail app, both of which are hard-core EAS applications. All of this goes to show that trust varies within Microsoft.
So, the upshot of all of this is that you cannot use ABQ rules to block OWA for iOS. If you want to block a user from connecting, you have to disable OWA access completely for their mailbox by running Set-CASMailbox–OWAforDevicesEnabled $False. OWAforDevicesEnabled is a new parameter that is also available in Exchange 2013 RTM CU2.
Life is never perfect and new applications that create new scenarios are never perfect when first introduced either. These aspects demonstrate that the iOS variant of OWA for Devices has created some new issues for Exchange administrators to think through. Just wait until OWA for Android appears!
Follow Tony @12Knocksinna
