Android Policy Planning

What

Android Policies provide a method of configuration.

Key aspects:

• Policies may contain multiple types of settings
• Multiple Policies may be pushed to devices

Example Policy, allowing Developer Settings, including setting Debug:

Possibly, one of the most important consideration:

Where multiple Profiles are assigned which contain the same Payload type (but differing settings), what could the possible expectation of experience be on the end device with these overlapping Policy Settings, noting that Apps potentially have their own settings also?

How

Firstly, overlapping Policies should be avoided, to ensure experience is by design, not luck.

Next, as mentioned above, Policies can contain many configurations, but should they?  Consider:

• Having an experience that is undesired from the Policy
• Needing to remove and reinstall a Policy

Undesired Experience:

More items in the Policy makes it harder to identify anything occurring that is undesired.

Removing the undesired experience temporarily, whilst identifying, may involve removing the entire Policy, which could easily be undesirable in its own right.  By creating multiple Policies with different settings, instead of one massive Policy containing everything, makes identifying and resolving unexpected experiences, much easier with less impact.

Remove/Reinstall

Perhaps something doesn’t appear to be working as intended.  To confirm the Policy, it may be desirable to remove that Policy, but what if other items in the Policy should not be removed, e.g. Certificates.  Separating settings based upon functionality should help alleviate this potential problem.

Overlapping Policies

What is an overlapping Policy.  This is when two or more Policies are trying to manage the same thing, but with different settings.  This shouldn’t be confused with multiple allowed Policies.

Greater detail on this can be found in our KB:

https://kb.filewave.com/books/android/page/android-emm-policies-and-permissions

In essence, overlapping Policies should be avoided.  An experience may appear correct, due to an overlap.  If one of the Polices were removed, the experience may unexpectedly alter if there was no awareness of this.

A Policy to provide certificates is an example of a potential multiple allowed Policy.  One Policy provides one certificate and another Policy provides a different certificate.

Planning

The above comes down to planning.

Policies could contain multiple settings based upon functionality.

Consider the impact if there was a requirement to remove and subsequently reinstate a Policy, for whatever reason.

Also give thought to how devices will be purchased and enrolled depending upon what needs to be managed.  Enrolment types can also impact items managed.

Will the choice made, incur additional concerns over security, if desired management cannot be achieved?