Without-Enrollment and Outlook for iOS & Android General App Configuration
Published Jul 22 2019 09:00 AM 9,568 Views
Microsoft

In January and March, Outlook for iOS and Android launched support for delivering configuration settings when the app is deployed on enrolled devices.

 

With an Intune service update rolling out this week, administrators will be able to customize the default configuration for several in-app settings when Outlook for iOS and Android has an Intune App Protection Policy applied. That’s right, device enrollment is no longer a condition to manage the general app configuration of Outlook for iOS and Android!

 

In addition, with this update, administrators can also manage Outlook for iOS and Android’s data protection settings and contact field sync controls within an App Configuration Policy. Admins no longer need to manage these settings with configuration key pairs when using Intune.

 

Once the Intune rollout is complete, you can either create a new App Configuration Policy with a device enrollment type of “Managed Apps” or update an existing policy to leverage the new controls when the policy is targeted against Outlook for iOS and Android. For existing policies, the configuration keys are automatically consumed in the new policy experience. For more information on which settings are available and how to configure a policy, please see Deploying Outlook for iOS and Android app configuration settings. You can also review Add app configuration policies for managed apps without device enrollment for general steps on how to create a policy. 

 

In deployments where you have both enrolled devices and unenrolled devices, or perhaps only enrolled devices, you may be wondering what type of an App Configuration Policy you should now utilize for managing Outlook's general app configuration settings. If an App Protection Policy is targeted to the users, the recommendation is to deploy the general app configuration settings in a “Managed Apps” enrollment model. This ensures the policy is deployed to both enrolled devices and unenrolled devices. 

 

APP App Configv2.png

Figure 1: Managed apps App Configuration Policy for Outlook for iOS and Android from https://devicemanagement.microsoft.com. If you're in https://portal.azure.com, then you'll go to Intune -> Client apps -> App configuration policies and add a configuration policy. 

 

In order for the app to apply the policy settings, Outlook for iOS 3.32.0 and later must be installed. Outlook for Android 3.0.108 and later is required; however, that build will not be available to all users until the end of next week. 

 

We hope this functionality aids you in your deployments. If you have any questions, please let us know!

 

Ross Smith IV
Principal Program Manager
Customer Experience Engineering

3 Comments
Copper Contributor

Hello Ross,

What happens when your users have both enrolled and unenrolled devices (Same user having Outlook installed on both an enrolled Iphone and an unenrolled Ipad for example) ? Would it be possible to target different policies to the same user ? One policy for the enrolled device to allow Contact sync and another policy that blocks Contact Sync for the unmanaged device ?

 

A potential solution would be to be able to target the policies to devices and not just users or have an additional option to target only unmanaged devices.

Thank you

Koen

Microsoft

@Koen Van den Broeck - I think there are a few questions here, so let me see if I can parse them out correctly. :)

 

Question 1 - How can I allow contact sync on enrolled devices, but block it on unenrolled devices?

Assuming the enrollment provider is Intune, the best approach here is to use a set of App Protection Policies.

 

For enrolled devices, create an APP with app types targeted set to "Apps on Intune managed devices". In the APP data protection settings, set "sync app with native contacts app" to enable.

 

For unenrolled devices, create an APP with app types targeted set to "Apps on unmanaged devices". In the APP data protection settings, set "sync app with native contacts app" to disable.

 

This will allow users to setup contact sync on enrolled devices, while disabling the ability for users to setup contact sync on unenrolled devices. You can then use an ACP (either managed apps or managed devices) to set the default behavior of contact sync to be on. Note: the APP setting enables/disables the ability for Outlook to use contact sync, while the ACP setting only controls the default behavior of contact sync if Outlook is allowed to perform contact sync.

 

See https://docs.microsoft.com/intune/app-protection-policies#target-app-protection-policies-based-on-de... for more information.

 

Question 2: What happens if I have a managed devices ACP and managed apps ACP targeted to the same user (setting either has same or competing values)?

In this scenario, the managed apps ACP setting will take priority. 

Copper Contributor

Thank you Ross for clarifying :)

 

Regarding Question 1: When using the APP, you need to set "IntuneMAMUpn" (unless this requirement changed) and this is the source of a lot of issues ... Once you set this parameter there are issues with information flowing to other Apps or trying to add a personal account to Outlook.

 

In our case, we have an APP for unmanaged devices including all Office apps and we do not allow to copy data outside of the Office apps.

When a user on a managed device (having IntunMAMUpn set) opens a mail from Yammer with a link and clicks on it, Yammer App opens and a message is displayed "Action not allowed ..." Although there is no APP for managed devices, both Outlook and Yammer app are installed via Company Portal and IntuneMAMUpn is set on all Office apps.

When I recreate exactly the same ACP for Outlook without "InuneMAMUpn", it works perfectly on a managed device, however I cannot apply the APP to the unmanaged device for the same user. 

 

I was hoping to get rid of the IntuneMAMUpn and the requirement to install apps from the company portal (on managed devices) with these new improvements, but I guess it is for a next version.

 

Thank you,

Koen

Co-Authors
Version history
Last update:
‎Dec 19 2023 01:26 PM
Updated by: