This week a blog post about the capabilities to block apps from starting and to allow apps to install on Samsung KNOX devices. I thought it would be good to mention these capabilities, as many are only familiar with the capability to work with compliant or noncompliant apps on Android. That capability can only be used for reporting functionalities. These capabilities are specifically for Samsung KNOX devices and can truly, and literally, block apps from starting. During this post I’ll go through the high-level steps to configure a blocked app and the end-user experience for both capabilities.
Information
Let’s start with some information about what can be achieved by using the block apps from starting and the allow apps to install capabilities. When using the block apps from starting capability, a list must be created of apps that are blocked from running on the device. Apps in this list are blocked from being run, even if they were already installed when the policy was applied. This list doesn’t prevent users from installing the apps. When using the the allow apps to install capability, a list must be created of apps that users of the device are allowed to install from the Google Play store. Only the apps in this list can be installed. No other apps can be installed from the store. This list doesn’t prevent users from starting the apps.
Configuration
Now let’s have a look at the high-level steps for these configuration. However, before I’m going to look at these steps, it’s good to mention that the configurations can be achieved by using OMA-URI settings. The following OMA-URI settings are available for these configurations:
- To create a block apps from starting list, use the following OMA-URI: ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/PreventStartPackages
- To create an allow apps to install list, use the following OMA-URI: ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/AllowInstallPackages
To find the value for these OMA-URI settings, the Google Play Store can be used. The app identifier that is used within the store, is what is needed to add a value to the block or allow lists. For example, when I’m looking at the OWA for Android app, in the store, the bold section, in the following URL, represents the required value: https://play.google.com/store/apps/details?id=com.microsoft.exchange.mowa&hl=en.
Now let’s have a look at how these two come together in the configurations for Microsoft Intune hybrid and Microsoft Intune standalone.
Note: When the block or allow lists must contain multiple apps, one of the following four characters ; : , | can be used as a delimiter.
End-user experience
Let’s end this blog post by having a look at the end-user experience. Below, on the left, is the end-user experience when the end-user starts an app that is blocked from starting. It’s indeed correct that it doesn’t show a screenshot. Reason behind that is because it actually lacks a real end-user experience. When the end-user tries to start a blocked app, the app won’t start and the end-user won’t get any notifications. Below, on the right, is the end-user experience when the end-user tries to install an app that is not allowed to install. The end-user will receive an error message accompanied by the message “Security policy prevents installation of this application”, which is a clear end-user experience.
Block app from starting | Allow app to install |
The app won’t start and the end-user won’t get a notification about what’s happening. |
More information
Fore more information about blocking and allowing apps on Android devices, please refer to:
- Use custom policies to allow and block apps for Samsung KNOX Standard devices: https://docs.microsoft.com/en-us/intune/deploy-use/custom-policy-to-allow-and-block-samsung-knox-apps
- Android and Samsung KNOX Standard policy settings in Microsoft Intune: https://docs.microsoft.com/en-us/intune/deploy-use/android-policy-settings-in-microsoft-intune
- Create configuration items for Android and Samsung KNOX Standard devices managed without the System Center Configuration Manager client: https://docs.microsoft.com/en-us/sccm/compliance/deploy-use/create-configuration-items-for-android-and-samsung-knox-devices-managed-without-the-client
Discover more from All about Microsoft Intune
Subscribe to get the latest posts sent to your email.
Hi. In InTune I’ve configured Device Configuration policies with OMA-URI settings to block apps from starting. It works for normal devices but not for “Android for Work” devices. Is this intentional due to containerization or a bug perhaps?
Hi Matthew,
Not sure, the docs only mention Android Samsung KNOX and nothing about Android for Work. Just to be sure you could check with Intune support. If you do, please don’t hesitate to share the answer.
Regards,
Peter
Great article Peter, is this (still) only an option for Samsung KNOX devices rather than any Android Enterprise device?
Hi Stuart,
To my knowledge, yes.
Regards,
Peter
Hi Peter,
Do you happen to know how to remove this setting (./Vendor/MSFT/PolicyManager/My/ApplicationManagement/AllowInstallPackages) from Android devices?
Whe accidently deployed this from intune to all out Android devices and not just to the test group :/
Hi Morten,
To be honest, I haven’t tested that without unenrollment of the device. I would think that removing the deployment would be sufficient, or deploying an empty list.
Regards,
Peter
Intune in Azure has now implemented the feature without the OMA URI custom setting.
In Device Configuration you’ll find it under Allow or Block apps category.
Funny thing is, it does not work quite as intended. It gives us 3 ways of identifying the application:
Package Name
URL (play store)
Managed App
I can’t find any information on what kind of information we’re suppose to input in the “Package name” field but i tried to put “com.sec.android.gallery3d” as a test to block Samsung Gallery App and nothing happen.
But when I put an URL of Google Maps, it does work.
Thank you, Jonathan! Yes, (almost) everything we can initially do via OMA-URIs will eventually come to the nice GUI options. As this is relatively new in the Intune Azure portal, it could take a moment before the docs are updated.