Intune Basics Part 6: Modern Device Management with Android Enterprise - Configuring Corporate-Owned Work Profile Devices

Welcome to part 6 of this series of posts which are intended on getting you started with managing Android devices using the Android Enterprise capabilities within Microsoft Intune.

Part 1 can be found here and covers setting up the various Android Enterprise enrolment methods

Part 2 can be found here and covers the configuration of Azure AD groups

Part 3 can be found here and covers the configuration of Personally-owned Work Profile devices

Part 4 can be found here and covers the configuration of Dedicated devices

Part 5 can be found here and covers the configuration of Fully Managed devices

This series will get you up and running as quickly as possible, therefore if you require further detail and explanation on Android Enterprise please refer to my previous post here which I am ensuring is kept up to date as newer functionality is supported within Intune.

Well, its admittedly been a while however this post will be picking up again the series to discuss this latest Android Enterprise enrolment type, which was announced as generally available as of the 2106 Intune service release.

Some Background Info

Many of you no doubt will have already tested this, or even deployed into production as it has been available in public preview since being first announced on 17th July 2020 and is typically the most sought after enrolment type due to its flexibility. It is commonly referred to as "COPE" within the mobility community, describing its intended use case (Corporate Owned, Personally Enabled). 

Its definitely worth mentioning at this stage that the implementation of COPE on some other MDM platforms for certain versions of Android, may be different to that of COPE within Intune. You should take this into consideration in migration scenarios as there will be differences in what is visible on the device to Intune than in these scenarios to the respective MDM solutions. This newer iteration is privacy friendly by design, as stated by Google and was mandated as of Android 11. Note that does not mean Android 11 is specifically required to support COPE on devices in Intune, as the functionality was back ported to be supported from Android 8 and newer, this support statement clearly defined in the documentation.

So what does this look like then both to the end user and from an Admin perspective? Well end user wise, almost identical to that of a Personally-Owned Work Profile (COPE) device, in fact it is designed to provide the user with access to an area for their own personal apps and data. From an Admin perspective, along with the previously mentioned point with COPE on other MDM platforms, it is also important to know that there is no way to retire just the Work Profile in this scenario, only a full wipe. Bear that in mind when allowing your users to access personal apps and data on company owned devices.

Finally I would also add that in my experience, the time it takes to enrol the device in comparison to all of the other Android Enterprise methods is quite a bit longer. Bear that in mind when expecting your users to set up their devices themselves and spec your hardware generously.

Configuration

Let's take a look at a Device Restrictions profile which would probably be your first port of call when configuring a COPE device

Navigate in the Endpoint Manager admin center to Devices > Android > Configuration profiles select Create profile

Select Android Enterprise for the platform and then Device restrictions within the heading Fully Managed, Dedicated and Corporate-Owned Work Profile

Enter a name for the profile and then select Next. You will now be presented with all of the available configuration options

As you are probably aware by now, there is a standardised layout which is prevalent for most configuration profiles across all platforms. Settings are grouped by applicability to the different enrolment types that are available

It is important to remember this to save both bloating you profile with unnecessary settings, but also you can create some unintended behaviour. If you really want to confuse yourself, like I did within Device experience set the Enrolment profile type to Fully Managed. The device will indeed be enrolled as COPE but the profile will give it the characteristics of a Fully Managed device.
So essentially, do not set the below, leave it as Not configured

I also just wanted to point out some more settings, firstly if you need to enable USB debugging, perhaps for screen sharing your device, then you will need to within the General section set Debugging features to Allow

Also note that there are two different places to block Screen capture and the Camera which can be done for apps within the Work Profile only

Also within the personal profile (remainder of the device) this restriction can be applied

Enrolment

As a reminder, back in part 1 of this serious we configured the various enrolment methods including this one, so lets have a look at what an enrolment looks like. Note that this is being tested on a Samsung Galaxy A12 with Android 11 as the Operating System

Tap anywhere in the blank space multiple times, note that this is on a device that is either brand new or has been factory reset

Select a Language then Next

Scan the QR code version of the associated COPE Enrolment token

Connect to Wi-Fi

Select Next

The enrolment process will start

Agree the terms

The Work Profile will start being created

Select Accept & continue

Sign in with credentials

Select Install

Select Next

Select Set up

Sign In

Enter the password again

Register

Done

Next

The end user can now enter their personal Google account details if they wish, facilitating access to personal apps and data within the personal profile of the device

Review the terms, scroll down and select an option

Review and set the date and time then select Next

Review the Google services, scroll down then select Accept

Select a security option

Select an option for Google Assistant

Review and remove any additional apps as desired, scroll down then select OK

Review and accept the terms as desired, select Next

Select an option

Further review recommended apps, select Install / Finish

The device is now enrolled. If you swipe up from the bottom you will see that the personal and work apps are separated, with the same experience as per on a Personally-owned Work Profile device

That's all for this post, many thanks for reading

Further exploration and analysis of OEMConfig

 In a previous post published almost 2 years ago (wow time flies!) I briefly covered what OEMConfig meant in terms of Android device management and figured that now would be a good time to explore this functionality again with you. 

The fact that OEMConfig is supported in Intune isn't indeed hot off the press news, however its still a fairly new initiative which I feel both customers and tech folk alike are pretty much in the dark about. I would suggest that this is probably due to the value offered differing between OEM's and often handsets.

So, what actually is it? OEMConfig is a way of delivering device configuration value for settings that are mostly not available within Intune. These configurations are delivered via an OEMConfig app, which essentially controls the execution of these settings rather the MDM agent. The app differs across OEM's and sometimes, such as for the example I will be discussing in this post, across models of handset. You should also be aware that some elements of these settings may require additional licensing from one of the supported OEM's, all of  which are documented here

The key benefit of OEMConfig is the fact that each time the OEM wishes to release additional functionality, there is little to no development time in order for this to be available on devices. So no delay in waiting for a dedicated profile to be made available in Intune! However, what I would add is that in order to take advantage of this functionality it may actually mean the handset needs to be upgraded, or indeed if the new feature may come under the context of a setting that needs additional licensing. Most of the time I would expect this to be a case of an update needs to be installed on the device.

In this example, I have a Nokia 5.3 handset which in this scenario, requires an OEMConfig app specific to the model;

So the requirement now is to deploy this app to the device. Within the Microsoft Endpoint Manager admin center navigate to Apps > Android then select Add then Managed Google Play app as the app type

Search for the previously mentioned OEMConfig app for Nokia 5.3 devices (noting again that for Nokia devices there are OEMConfig apps per model)

Select it then click Approve twice, then Done before finally Sync to ensure that the app appears as available

Once the app appears in the list, select it then properties. Select edit next to assignments then add the appropriate target group as a required assignment. Save any changes

Now the configuration needs to be defined and then assigned. Navigate to Devices > Android > Configuration Profiles select Create Profile. Choose Android Enterprise as the platform and then OEMConfig for profile.

Give the profile a suitable name and then click Select an OEMConfig app to ensure the correct app is associated with the profile. After selecting Next you will now see the settings that are available, which can be configured using the default configuration designer

In this example, we are going to enforce location services on the device, so next to Location select Configure then Enabled from the drop-down menu on the next screen

Select Next twice and then assign the profile to the appropriate target group. Next then Create completes the assignment of the configuration.

As you can see, initially location services were disabled on my test device

Now you can see they are enabled, in addition, the prompts for the OEMConfig app install and confirmation of the setting being enabled are also visible

I have to admit that initially, I thought there was significant value in the ability to be able to control this setting on these handsets. The problem is that in this specific scenario it does not prevent the end-user from altering the setting, which is also clearly stated on the app within the store

I also attempted to modify the setting and wait for / force a sync to see if it reverted again without any luck. I intend to explore this further and will update this post if I have any further information on why this is the case. 

That aside I believe this still demonstrates the possibilities with using this technology and it should be something you should consider as a contributing factor when selecting company-owned Android devices.

Many thanks for reading this post, if you have any questions please feel free to reach out to me!