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!

Using ADMX ingestion to configure the Zoom desktop application with Intune

Due to recent events I am seeing that organisations are having to come up with solutions quickly in order to enable their workforce, most of which it is the first time they are working from home. After working for a customer recently who wishes to deploy the Zoom desktop client to their whole organisation, I had a conversation with them and it was apparent that actually they were not entirely sure how specifically they wanted Zoom configured on install. On browsing the documentation I soon realised that there were some Group Policy templates available so, thinking ahead I thought it would be a good idea to see if I could import these policies to support any additional configuration requirements post install if the customers requirements changed over time.

So for a bit of background on this, as of Windows 10 1703 functionality was made available within the Intune service (and obviously the Window OS) giving the ability to support ADMX backed policies. So essentially the ability to transmit Group Policy settings in a format that are understood by the MDM client using the Policy CSP. This being achieved by importing or "ingesting" ADMX files and then configuring specific settings in relation to the ingested content. There are some caveats and considerations which  I am going to explain in this post and I want to keep it as simple as possible. Over time support has been provided for ADMX settings with the Administrative Templates profile within the Intune portal and most recently announced - these settings are now presented in an interface very similar to the experience of the Group Policy Management Console;

So how do we approach this then? First of all download the ADMX files for the Windows Desktop client. There are two versions, ZoomMeetings_HKCU if you want to deploy the policies within the users scope and ZoomMeetings_HKLM for devices. I went with the latter and then opened up the file with an xml editor.

From this, as per the documentation I needed to confirm that the registry keys for these policies were not within the exclusions list (I assumed this would be fine however its always worth a check)

I also wanted to look at the policies available and take note of the values supported for each policy, to use when creating the custom configuration profile to deploy the required settings

So lets take two settings in this example, we wish to prevent the end user from logging in using either their Google or Facebook credentials. What we essentially need to do now is deploy the ADMX file with an OMA-URI setting in order for it to be ingested and then disable these two settings using additional OMA-URI's for each. In order to know what values to use for these OMA-URI's a good approach (thanks Per Larsen for your excellent presentation at WMUG back in August 2019) is to deploy the ingested ADMX to the device first so these values are available in the registry.

First of all login to the Endpoint Manager admin center (EMAC) and navigate to Devices > Windows > Configuration Profiles > Create profile

Select Windows 10 and later as the platform and Custom as the profile type, give the profile a suitable name. Just as a reminder this profile will eventually contain both the fully ingested ADMX file and in addition the two OMA-URI strings for our settings.

Select add and then fill in the appropriate values;

Name; Something descriptive

Description; Add if required

OMA-URI; Should be in the following format with the items in bold being custom providing they are unique on the device ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/CustomZoomADMX/Policy/CustomZoomADMX

Data type; String

Value; The pasted contents of the ADMX file

Assign this to a device and then once the MDM profile has reported back as successfully deployed in Intune open the registry and navigate to HKLM:\Software\Microsoft\PolicyManager\ADMXInstalled to verify that the policy exists, there is a status and policy count

Now navigate to HKLM:\Software\Microsoft\PolicyManager\ADMXDefault and referring back to the ADMX file the settings we required were within the zoomgeneral category

Now we can go back to the profile we created earlier to add two more OMA-URI's using the above values

To enable the disable Facebook login policy

./Device/Vendor/MSFT/Policy/Config/CustomZoomADMX~Policy~ZoomUsCommunication~zoomgeneral/DisableFacebookLogin_Policy

The same for the Google

./Device/Vendor/MSFT/Policy/Config/CustomZoomADMX~Policy~ZoomUsCommunication~zoomgeneral/DisableGoogleLogin_Policy

Remembering that the available values for these settings can be found in the original ADMX file so the are both string and set to <enabled/>

Remember to change the beginning of the OMA-URI's to ./User if using user based ADMX policies

Originally the experience when launching the Zoom app on the device displayed the following options

After carrying out a policy sync you can now see the settings have applied

I hope you have found this useful, thanks for reading!