As many of you know, Outlook for iOS supports a one-way contact export process whereby contacts from within Outlook can be exported into the native iOS Contacts app. This functionality enables Caller-ID, iMessage, and FaceTime integration for users’ Outlook contacts.
We recognize that there are limitations and/or concerns with our contact export process, such as:
The lack of a two-way synchronization mechanism means that users must remember to manage (create, edit, or delete) contacts from within Outlook and not the native iOS Contacts app. Contact changes within the native iOS Contacts app don’t get synchronized back to the appropriate Outlook account, which may lead to data loss when Outlook’s contact export process is triggered as the exported contacts get overwritten.
On enrolled devices, the exported Outlook contacts are considered unmanaged and are accessible to unmanaged, personal apps.
Unfortunately, these issues are not something that Outlook for iOS can solve as we’re completely dependent on the operating system to provide a supported mechanism for bi-directional synchronization and for delivering managed contacts. However, with the Managed Exchange ActiveSync Profile improvements introduced in iOS13/iPadOS, organizations now have an additional capability to configure how users can manage contacts on mobile devices.
On enrolled devices, users can leverage an Exchange ActiveSync profile that only synchronizes contacts. With this contact synchronization model in place, users no longer need to leverage Outlook for iOS’s contact export synchronization process. This approach results in two synchronization paths – Outlook leverages the native Microsoft sync technology for synchronizing data within Outlook, and ActiveSync is leveraged by iOS to synchronize the contacts.
Organizations can adopt this approach by deploying the following policies:
Deploy a managed Exchange ActiveSync (EAS) profile for contact synchronization.
Deploy an Outlook App Configuration Policy (ACP) that disables Save Contacts.
Note: Due to app configuration delivery timing, some users may experience duplicate contacts in the native iOS Contacts app. Once Outlook for iOS contact synchronization is disabled, the duplicates are removed.
This managed EAS profile forces OAuth as the authentication method, only allows Contacts synchronization, and prevents the user from changing what data types are synchronized.
Note: Changing an existing EAS profile with these new settings results in a new profile being pushed to the device. Users will be forced to enter their credentials and the profile changes won’t take effect until authentication is complete.
Note: A managed apps ACP requires the assigned users to have an App Protection Policy. For more information on recommended approaches to deploying Outlook general app configuration, see http://aka.ms/omappconfig.
With the above changes, Contacts for the user’s account synchronize into the native iOS Contacts app via the managed EAS profile. As these changes are driven by IT, end users do not need to take any action other than entering their credentials for the managed EAS profile.
What are the benefits of this approach?
The user can use the native iOS Contacts app for all contact management, if they desire. Contacts synchronize back into the user’s Exchange mailbox via the ActiveSync protocol and synchronize into Outlook for iOS over the Microsoft sync technology. Likewise, if the user performs any contact management within Outlook for iOS, those changes propagate to the native iOS Contacts app through ActiveSync synchronization.
From within the native iOS Contacts app, users can manually search the global address list.
Scenarios that can result in contact duplication are minimized (if not removed completely).
When coupled with other device enrollment restrictions, like Viewing corporate documents in unmanaged apps (allowOpenFromManagedToUnmanaged), the managed EAS profile’s contacts are inaccessible to unmanaged, personal apps.
What are the limitations and/or things to think through with this approach?
This approach requires iOS 13+ / iPadOS. Older iOS versions ignore the data type restriction and sync all data types.
Device enrollment is required. Many organizations use App Protection Policies and not full device or user enrollment on personally-owned devices.
Conditional access policy changes are required. The “Require approved client app” or “Require app protection policy” grant controls cannot be targeted against the iOS platform and Office 365 Exchange Online cloud app for modern authentication capable clients. Instead, the “Require device to be marked as compliant” grant control must be used.
IT organizations are not able to control which messaging apps are used. As the “Require app protection policy” or “Require approved client apps” grant controls are not applied to Exchange Online for iOS devices, any modern authentication capable messaging client will be able to connect (e.g., an Exchange Web Services or third-party ActiveSync client) and access messaging data on enrolled iOS devices.
Users may be able to access work or school content before an app protection policy is applied. As the “Require app protection policy” grant control cannot be used with Exchange Online and iOS devices, policy assurance for Outlook for iOS is not guaranteed. Also, messaging apps that do not support App Protection policies will be able to access messaging data on enrolled iOS devices.
Use of the “Require app protection policy” Azure Active Directory Conditional Access grant control to block Exchange ActiveSync and other modern authentication capable messaging protocol apps, by only allowing Outlook for iOS and Android.
Use of Intune App Protection Policies to protect school or work content within the apps and between accounts.
Use of Intune App Configuration Policies to enable Save Contacts and limit the exported contact data fields that are exported to the native iOS Contacts app.
With any solution you need to balance your security requirements with end user productivity. We recognize the need for this flexibility, so we hope you find the above scenario useful.
Ross Smith IV Principal Program Manager Customer Experience Engineering