Android Enterprise and Microsoft Intune: And the previously missing use case

This week is all about an addition to my previous post about the device management jungle of Android Enterprise. In that post I already did a brief look at the future and what Android 11 would bring to the table. At that time Microsoft Intune did not yet support a deployment scenario to address the Corporate-Owned, Personally Enabled (COPE) use case. The good news is: that has changed! Microsoft Intune now contains the deployment scenario Corporate-Owned Work Profile, which is currently still in preview, and that deployment scenario can address the COPE use case.

With this blog I want to provide a refreshed overview of the different deployment scenarios and the use cases that are addressed. However, the main focus of this post is the new Corporate-Owned Work Profile deployment scenario. I’ll start this post with the refreshed overview of the different Android Enterprise deployment scenarios in Microsoft Intune, followed with a summery of the main characteristics of the different deployment scenarios. I’ll end this post by focusing on the implementation of the new Corporate-Owned Work Profile deployment scenario.

Updated overview of the Android Enterprise deployment scenarios

Let’s start with a brief overview of the different Android Enterprise deployment scenarios that are available within Microsoft Intune. I’ve discussed these deployment scenarios before, but I thought it would be good to provide another quick overview to clearly differentiate between the deployment scenario and the use case and to address the main characteristics of the different deployment scenarios. Below in Figure 1 is an overview of the different deployment scenarios. As it’s mainly focused on the Android Enterprise capabilities, I’ve skipped the MAM-only scenario. For a first filtering the deployment scenarios are sorted based on the owner of the device and based on the type of workers for the device.

The next step in providing a clearer overview is the table below. That table describes the main characteristics of the different deployment scenarios. It shows important characteristics like the main use cases of a deployment scenario, if personal use is possible, if the privacy can be guaranteed, the management reach and more familiar characteristics.

Deployment scenarioUse casePersonal usePrivacy guaranteedEnrollment methodManagement reachReset requiredUser affinity
Work ProfileBring Your Own Device (BYOD)YesYesCompany Portal appProfile ownerNoYes
Corporate-Owned Work ProfileCorporate-Owned, Personally Enabled (COPE)YesYesNear Field Communication, Token entry, QR code scanning, or Zero touchProfile owner with device-level settingsYesYes
Fully ManagedCorporate-Owned, Business Only (COBO)YesNoNear Field Communication, Token entry, QR code scanning, or Zero touchDevice ownerYesYes
DedicatedCorporate-Owned, Single Use (COSU)NoNoNear Field Communication, Token entry, QR code scanning, or Zero touchDevice ownerYesNo

As a little bit of context with this table, the different collumns are used to provide the following information:

  • Deployment scenario – This column describes the name of the deployment scenario (or some times referred to as management scenario) in Microsoft Intune
  • Use case – This column describes the often used name of the most common use case
  • Personal use – This column describes if the deployment scenario can facilitate personal use (which can be as simple as the option for enabling a personal account for the Google Play store)
  • Privacy guaranteed – This column describes if the deployment scenario can guarantee the privacy of the user (which actually can only be the case when using a work profile)
  • Enrollment method – This column describes the different enrollment methods that are available for the deployment scenario
  • Management reach – This column describes the management reach of the deployment scenario on the device
  • Reset required – This column describes if the deployment scenario requires a reset of the device
  • User affinity – This column describes if the the deployment scenario facilitates user affinity

Android Enterprise Corporate-Owned Work Profile

Now let’s have a look at the previously missing use case, which was the actual trigger of this post, the COPE use case. That use case can now be addressed with the introduction of the Corporate-Owned Work Profile deployment scenario. A long time the public feeling was that Microsoft was missing a use case in Microsoft Intune. Even though the feeling was fair and actually not just a feeling but a simple fact, there was also a fair reason why the deployment scenario for that use case was not available. Microsoft was relying on the Android Management API (AMAPI) and support for the required deployment scenario was not available. That’s changing now.

However, before looking at that deployment scenario in a bit more detail, let’s start with stating that the previous deployment scenario in Android Enterprise, to address the COPE use case, often named Work Profile on Fully Managed Device (WPoFMD), is not going to happen in Microsoft Intune. The support that’s provided via Microsoft Intune by leveraging AMAPI, is focused on the changes coming with Android 11. With Android 11, Google wants to focus more on the privacy of the user. To achieve that, Google wants to further separate the work profile and the personal profile. With the previous implementation there would be two separate Device Policy Controller (DPC) instances running on the device. An instance running as device owner in the personal profile of the user and an instance running as profile owner in the work profile of the user. As you can imagine, that theoretically provides an organization with a lot of control over the personal profile of the user. Besides the level of control, the organization could also potentially see information from the personal profile of the user, like the installed apps. That will also be one of the biggest changes in the new implementation. There will no longer be a work profile on a fully managed device. Instead, the new Corporate-Owned Work Profile deployment scenario will be similar to a normal work profile, but on steroids. Starting with Android 11, there will be a single DPC instance running as profile owner on the corporate owned device of the user. That instance also has the capabilities to do a few device settings. However, there will be no insights in for example the installed apps, or data, in the personal profile on the device. There will be strict separation between the apps and data in the personal profile and the work profile. Similar to the work profile deployment on personal devices. The main difference between the two are the steroids of the DPC instance. On a personal device, the DPC instance is running as profile owner and only has permissions within the work profile. On a corporate device, the DPC instance is also running as profile owner, it has permissions within the work profile and it can manage a few device settings that also affect the personal profile.

When looking from a Microsoft Intune perspective, the nice thing is that the user will have the same usage experience on devices with Android 8 and later, and that the administrators will also have the same management experience for devices with Android 8 and later. That’s achieved by using AMAPI. That will make sure that with a single configuration performed by the administrator, the correct configuration will be applied to the Android device of the user. No matter the specific Android version. As long as it’s Android 8 or later.

More information

For more information regarding Android Enterprise and Android 11, refer to the following articles:

Windows 10 MDM Bridge WMI Provider: Settings template

This week my post is a few days later, as my post is an extension of my session at the Workplace Ninja Virtual Summit 2020. At the virtual summit I did a session about Getting to know the Windows 10 MDM WMI Bridge provider and during my session I shared how to easily work with the Windows 10 MDM Bridge WMI provider. Similar to using Microsoft Intune to address the different CSPs, we can also use PowerShell via the WMI bridge.

The main thing that I’ve showed at the end of that session was a setting template, basically a PowerShell-function, that can be used to set, adjust and remove nearly all settings via the MDM WMI Bridge provider. That PowerShell-script is available below and I’ve completely documented the use, parameters and what it exactly does.

function Update-PolicySetting {
<#
.SYNOPSIS
A simple function to update policy settings by using MDM WMI Bridge
.DESCRIPTION
This function provides the capability to adjust policy settings by using the MDM WMI Bridge.
It supports the capabilities to create, update and remove an instance
.PARAMETER className
This parameter is required for the name of the WMI class
.PARAMETER parentID
This parameter is required for the name of the parent node of the OMA-URI
.PARAMETER instanceID
This parameter is required for the name of the WMI instance, which is the node of the OMA-URI
.PARAMETER configureProperty
This parameter is required when configuring a setting and is the name of the property
.PARAMETER valueProperty
This parameter is required when configuring a setting and is the value of the property
.PARAMETER removeInstance
This switch is used to indicate that the specified variables are used for deleting the WMI instance
.EXAMPLE
Update-PolicySetting -className 'MDM_Policy_Config01_Start02' -parentID './Vendor/MSFT/Policy/Config' -instanceID 'Start' -configureProperty 'HideAppList' -valueProperty 1
This example will run the function and configure a the property to hide the app list in Start
.EXAMPLE
Update-PolicySetting -className 'MDM_Policy_Config01_Start02' -parentID './Vendor/MSFT/Policy/Config' -instanceID 'Start' -removeInstance
This example will run the function and remove the instance of Start
.NOTES
Author: Peter van der Woude
Contact: pvanderwoude@hotmail.com
#>
param (
[Parameter(Mandatory=$true)]$className,
[Parameter(Mandatory=$true)]$parentID,
[Parameter(Mandatory=$true)]$instanceID,
[Parameter(Mandatory=$false)]$configureProperty,
[Parameter(Mandatory=$false)]$valueProperty,
[Parameter(Mandatory=$false)][Switch]$removeInstance
)
try {
#Get a specific instance
$instanceObject = Get-CimInstance -Namespace 'root\cimv2\mdm\dmmap' -ClassName $className -Filter "ParentID='$parentID' and InstanceID='$instanceID'" -ErrorAction Stop
}
catch {
Write-Host $_ | Out-String
}
#Verify the action
if ($removeInstance -eq $false) {
#Verify if the additional required parameters are provided
if ($PSBoundParameters.ContainsKey('configureProperty') -and ($PSBoundParameters.ContainsKey('valueProperty'))) {
#Verify if the instance already exists
if ($null -eq $instanceObject) {
try {
#Create a new instance
New-CimInstance -Namespace 'root\cimv2\mdm\dmmap' -ClassName $className -Property @{ InstanceID=$instanceID; ParentID=$parentID; $configureProperty=$valueProperty } -ErrorAction Stop
Write-Output "Successfully created the instance of '$instanceID'"
}
catch {
Write-Host $_ | Out-String
}
}
else {
try {
#Adjust a specific property
$instanceObject.$configureProperty = $valueProperty
#Modify an existing instance
Set-CimInstance -CimInstance $instanceObject -ErrorAction Stop
Write-Output "Successfully adjusted the instance of '$instanceID'"
}
catch {
Write-Host $_ | Out-String
}
}
}
else {
Write-Output ">> Make sure to provide a value for configureProperty and valueProperty when creating or adjusting an instance <<"
}
}
elseif ($removeInstance -eq $true) {
#Verify if the instance already exists
if ($null -ne $instanceObject) {
try {
#Remove a specific instance
Remove-CimInstance -InputObject $instanceObject -ErrorAction Stop
Write-Output "Successfully removed the instance of '$instanceID'"
}
catch {
Write-Host $_ | Out-String
}
}
else {
Write-Output "No instance available of '$instanceID'"
}
}
}

An example to use this function to hide the app list in Start can be found below.

Update-PolicySetting -className 'MDM_Policy_Config01_Start02' -parentID './Vendor/MSFT/Policy/Config' -instanceID 'Start' -configureProperty 'HideAppList' -valueProperty 1 

As mentioned during my session, the required parameters can be found mainly by looking at WMI by using the WMI Explorer. The name of the instance is the node of the OMA-URI that contains the required configuration. In this case Start. When you can’t find the required information, you can always refer to the documentation that’s shared below.

More information

During my sessions I’ve showed many reference to post that describe the subjects that I covered. For future reference those posts are summarized below.

Getting started with Endpoint Data Loss Prevention

Completely fresh after my vacation I thought it would be awesome to have a look at Endpoint Data Loss Prevention (DLP), which was announced during Microsoft Inspire. Endpoint DLP extends the activity monitoring and protection capabilities of DLP to sensitive content on Windows 10 devices. The best part of it is that the actual functionality is built-in to Windows 10 (and the Edge Chromium browser). No additional agent is required, just the onboarding of the device. In this post I want to start with a short introduction about Endpoint DLP, followed by the actions to onboard devices and to configure DLP policies and settings. I want to end this post by having a quick look at the end-user experience.

Introduction to Endpoint DLP

Let’s start with a quick introduction about Endpoint DLP. Endpoint DLP is an extension on the activity monitoring and protection capabilities that are provided by DLP, for sensitive content that is used on Windows 10 devices. That can be content that is directly edited in SharePoint Online, or OneDrive, but also content that is only locally available on the Windows 10 devices. So no dependency on the location of the data, but only on the data itself (and of course the device that it’s used on). Really awesome!

At this moment Endpoint DLP enables organizations to audit and manage activities of users on sensitive items. Activities like created, renamed, printed and more. For a complete list, refer to the documentation. Besides that, Endpoint DLP monitors the activity based on MIME type, which means that an extension change doesn’t stop content from be monitored. At this moment the list of supported file extensions is documented here.

To enable Endpoint DLP, make sure that the following is in place:

  1. The user must have a Microsoft 365 E5/A5 subscription or Microsoft 365 E5/A5 compliance or information protection and governance add-on
  2. The device must be running Windows 10 build 1809 or later
  3. The device must be Azure Active Directory (AAD) joined, or Hybrid Azure AD joined
  4. The Chromium Edge browser must be used on the device for the cloud activity actions

Onboard devices into device management

The first action that should be performed is onboarding the devices into device management. After onboarding the devices, the activities of those devices can be reviewed in features like activity explorer, or can be monitored by compliance solutions such as insider risk management and data loss prevention (DLP). To enable the onboarding, simply follow the next three steps.

  1. Open the Microsoft 365 compliance portal and navigate to Settings > Device onboarding (preview) > Devices and click on Turn on device onboarding
  1. On the Turn on device onboarding dialog box, review the message about devices already onboarded via Microsoft Defender ATP and click OK
  1. On the Device monitoring is being turned on dialog box, review the message and click OK

After successfully performing the previous steps, the devices that are already onboarded via Microsoft Defender ATP will start appearing in the devices list. When not already using Microsoft Defender ATP, devices can be onboarded by using the same process as for onboarding devices for Microsoft Defender ATP. When using Microsoft Intune that means following the next 10 steps.

  1. In the Microsoft 365 compliance portal, navigate to Settings > Device onboarding (preview) > Onboarding
  2. Select with Mobile Device Management / Microsoft Intune as the Deployment method and click Download package to download the onboarding package
  3. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices  > Configuration profiles > Create a profile to open the Create a profile blade
  4. On the Create a profile blade, provide the following information and click Create to open the Microsoft Defender ATP (Windows 10 Desktop) wizard
  • Platform: Windows 10 and later
  • Profile: Microsoft Defender ATP (Windows 10 Desktop)
  1. On the Basics page, provide a valid name for the profile and click Next
  2. On the Configuration settings page, provide the following information and click Next
  • Microsoft Defender ATP client configuration package type: Select Onboard and add the downloaded package of Step 2 (this is not necessary when a Microsoft Defender ATP connection is established with Microsoft Intune)
  • Sample sharing for all files: Not applicable
  • Expedite telemetry reporting frequency: Not applicable
  1. On the Scope tags page, click Next
  2. On the Assignments page, assign the onboarding configuration to the required group and click Next
  3. On the Applicability Rules page, click Next
  4. On the Review + create page, click Create to create the profile

Configure Endpoint DLP settings

Once the devices are onboarded, the next step is to have a look at the Endpoint DLP settings. These settings apply to all new and existing DLP policies that protect content on Windows devices and these settings are divided into the following three categories.

  • File path exclusions – This category can be used to configure file path exclusion to make sure that files in the specified locations won’t be monitored by the DLP policies.
  • Unallowed apps – This category can be used to configure specific apps that are prevented from accessing files that are protected by the DLP policies.
  • Browser and domain restrictions to sensitive data – This category is divided into the following two subcategories.
    • Unallowed browsers – This subcategory can be used to configure specific browsers that will be blocked from accessing files that are protected by DLP policies. The end-user will be prompted to use Edge Chromium.
    • Service domains – This subcategory can be used to configure specific service domains – from Edge Chromium – that are either allowed or blocked from uploading files that are protected by DLP policies.

To optionally configure these settings simply open the Microsoft 365 compliance portal and navigate to Policies > Data loss prevention > Endpoint DLP settings (preview).

Configure Endpoint DLP policy

Once the generic Endpoint DLP settings are configured, the next step is to have a look at configuring an Endpoint DLP policy. That’s actually just configuring a normal DLP policy with a new endpoint specific section. Let’s walk through those configurations by configuring a DLP policy that is based on the defaults of the GDPR template. To achieve that, simply follow the 11 steps below.

  1. Open the Microsoft 365 compliance portal and navigate to Policies > Data loss prevention > Policies and click Create policy (preview) to open the Create policy wizard
  2. On the Choose the information to protect page, select the General Data Protection Regulation (GDPR) template and click Next
  3. On the Name your DLP policy page, verify the information – if needed adjust the name – and click Next
  4. On the Locations to apply the policy page, make sure to at least select Devices (preview), make sure to include a (test) user and/or group and click Next
  1. On the Define policy settings page, select Review and customize default settings from the template and click Next
  2. On the Info to protect page, verify the default configuration and click Next
  3. On the Protection actions page, verify the default configuration and click Next
  4. On the Customize access and override settings page, perform the following actions and click Next
  • Verify the default configuration of the Restrict access or encrypt the content in Microsoft 365 locations section
  • Enable the configuration of the Audit or restrict activities on Windows devices section and configure the different activities to Audit, Block or Block with override
  1. On the Test or turn on the policy page, configure to test or to turn on or off the policy and click Next
  2. On the Review your settings page, verify the configuration and click Submit
  3. On the New policy created message page, select Done to close the wizard

End-user experience

Now let’s end this post by having a look at the end-user experience. Based on the usage of the GDPR template, I can show some nice examples of the user experience when working with personal information (like drivers license numbers). To show some examples of the behavior I’ve created a document, named Document5.docx, and that document contains a drivers license number. When I now want to copy content from that document, I receive a notification as shown below in Figure 6 and when I now want to print that document, I receive a notification as shown in Figure 7. Both notifications show the override option for the end-user, via the Allow button, as configured in the DLP policy (see Figure 5).

More information

For more information about Microsoft Endpoint DLP, refer to the documentation that starts here with Learn about Microsoft 365 Endpoint data loss prevention (preview).