App Protection Policy is not applied

Not applicable

Hi everyone,


i have the following constellation:


1. One App Protection Policy named "iOS General"

2. One App Protection Policy named "iOS Outlook for managed devices"

3. One App Protection Policy named "iOS Outlook for unmanaged devices"



1. The following options are set for "iOS General:

Target to all app types -> yes

Targeted Apps -> all Apps in List except Outlook


2. The following options are set for "iOS Outlook for managed devices"

Target to all app types -> no -> Apps on Intune managed devices

Targeted Apps -> Outlook


3. The following options are set for "iOS Outlook for unmanaged devices"

Target to all app types -> no -> Apps on unmanaged devices

Targeted Apps -> Outlook


My expectations:

unmanaged Devices

  1. Policy "iOS General" is applied for all Apps, except from the Outlook App.
  2. The Outlook App applies the Policy "iOS Outlook for unmanaged devices"

managed Devices

  1. Policy "iOS General" is applied for all Apps, except from the Outlook App.
  2. The Outlook App applies the Policy "iOS Outlook for managed devices"


My problems:

1. unmanaged and managed devices are applying the "general" Policy. Very good.

2. When it comes to the distinction between managed device -> Outlook & unmanaged device -> outlook the App Protection Policies are not properly applied.

The policy "iOS Outlook for unmanaged devices" is applied every time. (Not as expected only on unmanaged devices!)


additional information:

I'm using a group with static user assignment. All my test-users are member of this group.

Every App Protection Policy is using this static group. (Policy -> Assignments -> Inlcude)



Thank you very much in advance.

Patrick :)

22 Replies

How is Outlook being distributed? Is it set as required or advertised from Company Portal? When you check device management in iOS Settings, is the app listed as managed?

Hi Patrick,


I just saw your post.  I have a similar issue with iOS app protection policy.  I have one set of policies for iOS devices and one for Android devices.  Policies work fine with Android when enrolling and unenrolling.  With iOS, the settings don't change once the device is managed.  I think the Outlook app is still registered as unmanaged thus it applied the unmanaged policy.  I have had a premier support ticket for about 3 weeks now.  I have been out of the country with limited access.  Sorry for the delay on this.  Anyway, the last status I got said that this is a bug.  There hasn't been a fixed issued as of last week.  Usually, I would say, submit a ticket since it could be something different for your environment, but you may need to wait it out a little longer.  Support hasn't given me any documentation or article on the issue.  In any case, as soon as I hear something, I will reply back.

Have a good one.




Hello eglockling,


in my understanding a "default" app protection policy should be applied to any app management state, isn't it?

(So even, when a user isn't using an intune managed device)

So my default profile is set to "target to all app types -> yes".

Microsoft explanation:

Use this option to target your policy to apps on devices of any management state.

During policy conflict resolution this setting will be superseded if a user has policy targeted for a specific management state.


Anyway, in my case i got the app via the "required" setting inside the app assignment.

When looking at "all devices -> my iphone -> managed Apps" i can see the Outlook app in there.

So it is a managed app in this case. (the same on a second test iphone)


Another question regarding the setting "target to all app types":

"this setting will be superseded if a user has policy targeted for a specific management state."

Would it be better to have the general policy holding all apps, including outlook?

And second: Have an App Policy for Outlook on managed devices with some other / divergent settings than the general policy?


So whenever there is a user with a device with one of these apps connecting with his corporate account, this app is going to apply the default / general policy PLUS when the device is managed in intune the policy "ios managed" is going to override the lax setting of the general policy.



Hello Marcelo,


With iOS, the settings don't change once the device is managed.  I think the Outlook app is still registered as unmanaged thus it applied the unmanaged policy.

So you think the app managemend state is meant in the setting "target to all app types -> no -> Apps on Intune managed devices?
When i'm reading the this in intune i think the device management state is meant, not the app management state.


Thank you very much. (Thanks to eglockling, too.) :)


Hi @Deleted @Marcelo Carvalho 


I had the same issue when I was initially setting up APP, iOS has an additional requirement in order to mark the application on the device as managed.

Link: target-app-protection-policies-based-on-device-management-state


You can validate the App Protection Status for each user/application under Client apps - App protection status




Hello @AndrewDawson,


thank you for participating.

I know already the App protection status page. What i like to use is the Troubleshooting Tool, where i can select a user and see exactly what Policy would be applied.


What I still don't understand:

"iOS has an additional requirement in order to mark the application on the device as managed."

I thought the App Protection Policy is based on the DEVICE Management state, not if an app is in managed (installed through intune) or unmanaged (installed through regular appstore) mode.


Quote from you link:

Because Intune app protection policies target a user’s identity, the protection settings for a user can apply to both enrolled (MDM managed) and non-enrolled devices (no MDM).


You can have one protection policy for un-managed devices in which strict data loss prevention (DLP) controls are in place, and a separate protection policy for MDM managed devices, where the DLP controls may be a little more relaxed.

That's what i want to achive. I already have these different policies set up. (but not working for ios correctly , as you already know


More interesting is this quote:

For iOS, additional app configuration settings are required to target APP settings to apps on Intune enrolled devices:


This (additional app configuration settings are required to target APP settings to apps on Intune enrolled devices) seems to be our problem. iOS needs additional settings, so that the APP recognizes the devices management state correctly.


An advise from the next link is:

In Intune, the App Configuration policy has to be for enrollment type "Managed Devices". Addicionally, the App needs to be either installed from the Intune Company Portal if set as available or pushed as required to the device.

So thats what i don't think is logical:

iOS: The App itself must be managed to apply the correc policy (which should be used on DEVICE Management state. (not app management state))

Android: Everything is working as expected. A managed device is using the "APP for managed devices" both for a user driven app installation and for a intune driven installation of an app.


Now i'm going to read the docs and try to understand and implement the configuration correctly. (Wish me luck :D )

I will write down it here soon if anything happened. (expected or unexpected)



best response

Hi Patrik,


You will need to create an App Config policy for each application.

IntuneMAMUPN   String   {{UserPrincipalName}}




  • The AppConfig Outlook GUI creates this setting when you select "Allow only work or school accounts".
  • Not every Microsoft APP application accepts IntuneMAMUPN in appconfig.


As you said the App Protection Policy report will show pending/applied config on a device, you can also navigate to about:intunehelp on iOS managed browser and check the applied settings from the device directly.


I have also seen some recent issues with APP not applying correctly after changing profiles, I suspect I will just have to re-enrol the device.




I'm **bleep** confused right now. :D


1. I added an app configuration policy (as required).

Device Enrollment Type: Managed devices
Platform: iOS
Required App: Microsoft Outlook

Use configuration designer
Configuration Key: IntuneMAMUPN
Value Type: String
Configuration Value: {{UserPrincipalName}}


Result: When clicking on save, the ConfigKey disappears after reopen the config.

Solution: After entering the ConfigKey & Value i have to click in an empty row and then click on save.

I'm getting crazy....


Now my iOS device is correctly using the desired App Protection Policy. (iOS Policy for managed device, which allow the user to export contacts in the native contacts app.)



I didn't try out any app configuration policy before.

Now i'm using an policy as mentioned above: ("Outlook - iOS")

I set the required value IntuneMAMUPN, so that the APP is correctly beeing applied when device is managed.

Addiotionally i started using the "configure email account settings" just like you did in the provided screenshot.

I have a question about that: Why is it important to allow only work or school accounts inside the outlook App? (For this case)

I want my users to have the opportunity to use the outlook app also for their private accounts.

(To increase the acceptance of the app)


@Deleted I've encountered the same issue with regard to trying to save the IntuneMAMUPN value. I raised a service ticket related to that issue but, interestingly after a short while the Intune App Protections started to apply correctly (I saw the apps in question perform their 'restart' after prompting the user that they were being protected). Without having to do anything else, the App Protections are behaving properly now - applying to unmanaged devices correctly and a different less restrictive policy applying to managed devices. Two separate policies, one for unmanaged (applied only to unmanaged devices) and one for managed (applied only to managed devices). Due to a timings issue I ask Microsoft to close the ticket though before it had been investigated as I was spending too long with their engineers taking screen shots and trying to explain the issue - even directing them to the articles I'd used to perform the setup.


For me, at least, things seem to be working OK. I just needed to be patient. About 18 hours patient, before the settings took hold!

@Gary Cooper 

Reeeaaally strange.


Okay, adding the UPN is working now as I've described.

At this moment I'm testing with an iOS device.

- Which Policy is applied when unmanaged?

- Which Policy is applied when this is unmanaged device is going into management?

- Is the non-managed policiy re-applied, when leaving the management?


I'll write back in a few minutes (okay azure... perhabs in a few hours.) when testing is done.

Now it's working really good, everything as expected.


Just to outline my tests:

  1. iPhone reset to factory defaults
  2. Outlook App installation
    1. I had to login by myself
    2. When logged in the message "your app is now protected" appears -> restart of the app
    3. User have to set a PIN
  3. OneDrive installation
    1. just for testing.
  4. Troubleshooting:
    1. App Protection Policy applied correctly:
      1. "Test - iOS unmanaged - Outlook"
        1. e.g. the user can't sync the contacts.
      2. "Test - iOS - General"
        1. Policy for all the other apps, independently of the management state.
  5. Enrollment in companyportal-App
    1. The user account was found, because it has previously used in outlook. (i think, thats why.)
    2. Device enrollment took place.
  6. Starting Outlook App again
  7. Troubleshooting
    1. App Protection Policy applied correctly:
      1. "Test - iOS managed- Outlook"
        1. e.g. the user is now able to sync the contacts.
      2. "Test - iOS - General"
        1. Policy for all the other apps, independently of the management state.


I'm really happy, that this is working now. :)

Thank you all.

Feel free to continue discussing. I will follow this thread, of course.



Hi @Deleted and @AndrewDawson ,


Sorry for the late response.  Ya, I forgot to mention about the app configuration profile for iOS apps.  I was waiting on Microsoft on something.  In my environment, for Outlook app, the configuration key is disappearing from the UI.  They said that should be fixed in 1903.  In any case, I still got issues, but Patrick is all set.  Have a good one.  Thanks Andrew for the info.  Patrick, thanks for sharing.





I had the same experience and pinned it down to the GUI already addressing this key in policy, since the policy already exists the key is removed and hidden from view.


Looking into the browser response when loading this config in chrome you see the Key already defined;


Note: this is the same config from my previous screenshot.




Ya, it should be fixed in 1903.  Here a couple of steps on how to review that info in Microsoft Graph.  Microsoft engineer showed me.


  1. Go to
  2. Sign In with Microsoft
  3. Sign in with your Global Admin account
  4. Click on Modify permissions
  5. Select all the options that include “DeviceManagement” prefix (already consented in mine). You will be prompted to reauthenticate afterwards
  6. Change to BETA
  7. Erase “me” from the URL and add “deviceAppManagement/mobileAppConfigurations”
  8. Click on “Run Query” and it will show all the app configuration policies below.
  9. You should be able to find it by DisplayName
  10. It will show the configuration keys that were created


This is how I found out I had 3 configuration keys and one of them was misspelled.  

@Marcelo Carvalho 

I now are experiencing the same problem.

The IntuneMAMUPN Value is disappearing.


I will open a Ticket at MS, too.


Edit: I just saw your second answer (Graph). This is really nice to know, thank you!

Result: All values are set, the GUI is just missing this.



Where did you see that in chrome?

When loading the page i can't see that.

Anyway, the "graph way" is really good for troubleshooting. 


Hi @Deleted,


The result will be the same as the Graph API call outlined by Marcelo.


Since the web interface effectively used the Graph API to make calls when load pages you can just monitor the browser network traffic.




Note: you will see a few connecting referring to the API as various resources will load long with the appconfig content (i.e. config assignment).


This is also a good method for understanding the Graph API and designing various automation processes.



I had expected the disappearing input was due to the fact that it already existed based on the GUI selection and should never exist twice due to potential conflicts in the configuration. i.e. server-side was removing once detected.


After some testing the additional config is accepted and saved, the config will not show as it is 'represented' by the GUI control above.  Important: Microsoft should validate the config on save and prevent duplicate entries from being committed rather than fix the UI to display the additional entries.





i opened a ticket and received a call from Microsoft:

The current status is, that the microsoft support does'nt know why this happens exactly.

What we have already found out is, that other values doesn't have any problems.

For example we've added another XML Value like "userid" as key, "String" as value type and {{userid}} as configuration value.

When saving this and reloading the page everything is fine.


At the moment i'm waiting for an answer of the next technician :D



I'm glad it's all working for you.  Sorry for throwing you off a little.  For me, there was an actual issue per the engineers at Microsoft.  They reproduced the issue multiple times.  They reported it working on Monday.  We still have issues with the UI, but that's getting fixed.  If you set it for other apps, the configuration key will be listed (it won't disappear).  Microsoft Graph seems like a quick way to get other info, too.  It's good stuff.  Have a good one.



Great...  Good luck!  Maybe I'll keep my ticket open until they fix that, too.