Android Enterprise and Microsoft Intune

This week is all about the device management jungle of Android Enterprise. I should have discussed this subject a long time ago, but better late than never. Especially when I’m still seeing many question marks when discussing Android Enterprise. With the release of Android 10.0 coming to the different existing Android devices now, the purpose of this post is to create an overview of the different enterprise deployment scenarios of Android Enterprise, including the Microsoft Intune specific additions, and the different related enrollment methods. Everything focussed on providing a good starting point for managing Android devices. The main trigger is the nearing end of Android device administrator with the release of Android 10.0. Earlier I provided the steps for simplifying the migration of Android device administrator to Android Enterprise work profile management with Microsoft Intune, but that was a specific scenario for migrating away of Android device administrator. That doesn’t answer the question if Android Enterprise work profile management is the best deployment solution for your organization.

With this post I hope to provide a better overview of the different deployment scenarios, the requirements and the enrollment methods. All to make a good start with Android Enterprise. Before I’ll dive into Android Enterprise, I’ll start with a little bit of history about Android device administrator. After going through the Android Enterprise deployment scenarios and enrollment methods, I’ll end with a short note about the (crazy) future. I won’t compare or discuss the different configuration options for the different deployment scenarios, as I think that a deployment scenario should be chosen based on the use case first and not directly based on the available configuration options.

A little bit of history

Let’s start with a little trip down memory lane. A long time ago, with Android 2.2, Google introduced the Device Administration API. That API provided device administration features at a device level and allowed organizations to create security-aware apps with elevated administrative permissions on the device. It would enable organizations to perform some basic actions on the device to manage basic components, like email configurations (including remote wipe) and password policies. However, it also introduced many big challenges. One of those challenges was the limited number of configuration options, without a third-party solution like Samsung Knox, and another one of those challenges was the inconsistent level of control across different manufacturers. The more Android device administrator was used, the bigger the scream became for something new.

And something new came. Starting with Android 5.0 and later, Google started with the introduction of Android Enterprise by introducing the managed device (device owner) and work profile (profile owner) modes to provide enhanced privacy, security, and management capabilities. These modes support the different Android Enterprise deployment scenarios (more about those scenarios later) and can be managed by using the Android Management API. That API can be used to configure different enhanced policy settings for the managed devices and the companion app (Android Device Policy) automatically enforces those policy settings on the device. Microsoft Intune has chosen to rely on the API for managing most of the deployment scenarios.

Now only turning off the old management method is left. Starting with Android 9.0, Google has started with decreasing device administrator support in new Android releases, by starting with deprecating specific settings. These settings are mainly related to the camera and password configurations, and these settings are completely removed starting with Android 10.0. That will prevent organizations from being able to adequately manage Android devices by using Android device administrator. A big trigger to move away from Android device administrator. The advise – when using only Microsoft Intune – is to move to Android Enterprise modes and deployment scenarios with the introduction of Android 10.0. Even better, don’t wait until the introduction of Android 10.0 (but that advise might be a bit late now).

Android Enterprise deployment scenarios

The biggest challenge of the Android Enterprise device management jungle is the number of deployment scenarios. When looking specifically at the combination with Microsoft Intune, there is even an additional deployment scenario on top of the standard Android Enterprise deployment scenarios. Below in Figure 1 is an overview of the currently available Android Enterprise deployment scenarios with Microsoft Intune (picture is taken from the slide deck of session BRK3082 at Microsoft Ignite 2019).

Now let’s have a closer look at these different deployment scenarios and the supportability of Microsoft Intune. I’ll do that by zooming in on the different deployment scenarios as shown in Figure 1.

Android APP managed – Android app protection policies (APP) managed app is the least intrusive method for allowing access to company data on personal devices and still making sure that the data remains safe. Also, this method is not Android Enterprise specific. In this scenario, the app is managed with protection policies that will make sure that the company data remains within the app and these protection policies are only applied once the user signs in with a work account. Also, the protection policies are only applied to the work account and the user is still able to use the same app with a personal account. If needed, the IT administrator can remove company data from within the managed app.

AE Work Profile – Android Enterprise work profile is supported with Android 5.0 and later in Microsoft Intune and is focused on providing access to company data on personal devices by using a profile owner mode. In this scenario, the user enrolls the device and after enrollment a separate work profile is created on the device. This separate profile creates the separation between company data and personal data and can be easily identified by the user. The apps that are part of the work profile are marked with a briefcase icon and the company data is protected and contained within the work profile. If needed, the IT administrator can remove the work profile from the device.

AE Dedicated – Android Enterprise dedicated devices – previously known as corporate-owned, single-use (COSU) devices – are supported with Android 6.0 and later in Microsoft Intune and is focused on providing single purpose company-owned devices by using a device owner mode. This is often used for kiosk-style devices (example: devices used for inventory management in a supermarket). In this scenario, these devices are enrolled and locked down to a limited set of apps and web links, all related to the single purpose of the device. These devices are not associated with any specific user and are also not intended for user specific applications (example: email app). If needed, the IT administrator can remove any (company) data of the device.

AE Fully managed – Android Enterprise fully managed devices – previously known as corporate-owned, business-only devices (COBO) devices – are supported with Android 6.0 and later in Microsoft Intune and is focussed on providing company-owned devices, used by a single user exclusively for work, by using a device owner mode. In this scenario, these devices are enrolled and fully managed by the IT organization. To give the user a personal touch, the IT administrator can allow the user to add a personal account for the installation of apps from the Google Play store. However, the device will remain fully managed and there will be no differentiation between company data and personal data. If needed, the IT administrator can remove all (company) data of the device.

AE Fully managed with work profile – Android Enterprise fully managed devices with work profile – previously known as corporate-owned, personally-enabled (COPE) devices – are not yet available with Microsoft Intune, but are eventually focussed on providing company-owned devices used for work and personal purposes, by using a combination of device owner mode and profile owner mode. In this scenario, the IT organization still manages the entire device, but can differentiate between the strength of the configuration depending on the type of profile (example: a stronger configuration set to the work profile and a lightweight configuration set to the personal profile). That should provide the user with a personal space on the device and that should provide the IT administrator with enough capabilities to protect the company data.

For the management of the company-owned devices, Microsoft Intune relies on the Android Management API and Android Device Policy. That enables Microsoft to be able to quickly introduce new features, when introduced in the API. However, that also creates a dependency on Google to introduce new features via the API. A negative example of that dependency is the time it took before the Android Enterprise fully managed devices with work profile deployment scenario became available via the API. At this moment the Android Enterprise fully managed devices with work profile deployment scenario is not yet available with Microsoft Intune.

Android Enterprise enrollment methods

Once familiar with the Android Enterprise deployment scenarios, it’s good to get familiar with the Android Enterprise enrollment methods. That will enable the IT administrator to get an Android device in the correct mode (device owner, or profile owner) and the correct deployment scenario. The table below provides and overview of the available enrollment methods for the different deployment scenarios. It also provides some details about a few important properties of the deployment scenarios (based on the information about the deployment scenarios). Those properties are: is a reset required to get started with a deployment scenario and is a user affinity applicable with a deployment scenario.

As the Android Enterprise fully managed devices with work profile deployment scenario is not yet available with Microsoft Intune, the information regarding that deployment scenario is an educated guess, based on the other deployment scenarios. That’s why the information is in grey, as it’s still work in progress. The only thing that I’m sure of is that it would require a new enrollment. There will be no migration path from an Android Enterprise fully managed device to an Android Enterprise fully managed device with work profile. That will require a new enrollment. Keep that in mind with determining an eventual deployment and management strategy.

Deployment scenarioEnrollment methodsReset requiredUser affinity
Android app protection policies managed appManaged appNoNot applicable
Android Enterprise work profile deviceCompany Portal appNoYes
Android Enterprise dedicated deviceNear Field Communication, Token entry, QR code scanning, or Zero touchYesNo
Android Enterprise fully managed deviceNear Field Communication, Token entry, QR code scanning, or Zero touchYesYes
Android Enterprise fully managed device with work profileNear Field Communication, Token entry, QR code scanning, or Zero touchYesYes

Now let’s have a closer look at the different enrollment methods and the supportability within Microsoft Intune. I’ll do that by zooming in on the different enrollment methods as mentioned in the table above.

Managed app – Managed app enrollment is not specific to Android Enterprise and is supported with any platform version that is supported by the specific managed app. With this enrollment method, the user downloads and installs an app that is protected with app protection policies – when using a work account – and adds a work account to that app. After signing in it triggers the app protection policies for the work account. Also, keep in mind that the user would need to have the Company Portal app installed as a broker app.

Company Portal app – Company Portal app enrollment is supported with Android 5.0 and later in Microsoft Intune for Android Enterprise deployment scenarios. With this enrollment method, the user downloads and installs the Company Portal app and signs in with a work account. After signing in the user triggers the enrollment process in the Company Portal app.

Near Field Communication – Near Field Communication (NFC) enrollment is supported with Android 6.0 and later in Microsoft Intune and can make the enrollment of a device as simple as tapping the device on a specially formatted NFC tag. With this enrollment method, once the device is reset, or just out-of-the-box, and arrives on the initial Welcome screen, the administrator, or user, can simply tap the device on the NFC tag. That tap will automatically start the enrollment process.

Token entry – Token entry enrollment is supported with Android 6.0 and later In Microsoft Intune and enables the enrollment of a device by specifying a specific (enrollment) token. With this enrollment method, once the device is reset, or just out-of-the-box, the administrator, or user, walks through the standard setup wizard and once arrived at the Google sign-in screen provides the afw#setup code to trigger the Android Device Policy. That will enable the token entry to actually start the enrollment process.

QR code scanning – QR code scanning enrollment is supported with Android 7.0 and later in Microsoft Intune and enables the enrollment of a device by simply scanning a QR code. With this enrollment method, once the device is reset, or just out-of-the-box, and arrives on the initial Welcome screen, the administrator, or user, can multi-tap the screen to enable scanning of a QR code (on Android 7 and 8 that will first prompt for the installation of a QR code reader app). That QR code will automatically start the enrollment process.

Zero touch – Zero touch enrollment is supported with Android 8.0 and later In Microsoft Intune – only with participating manufacturers – and enables the enrollment of a device automatically. Similar to Apple Business Manager and Windows Autopilot. With this enrollment method, on first boot of the device, it will automatically check to see if an enterprise configuration is assigned. If so, the device initiates the provisioning method and downloads Android Device Policy. That download and installation will automatically start the enrollment process.

Note: Besides these standard Android Enterprise enrollment methods, there are also third-party additions (like Samsung Knox enrollment) that can benefit the enrollment process.

What the future brings

Let’s end with a look at the future and some advise. By now it should be obvious that platforms change. However, when looking at the first early signs of Android 11.0 – and specifically at what Android 11.0 brings to the Android Enterprise fully managed devices with work profile deployment scenario – organizations might wonder if change is always for the better. Just when the deployment scenarios of Android Enterprise get more and more traction, new changes are coming. Google recently announced that it will no longer support a work profile on fully managed devices with Android 11.0. Instead enhancements are made to the work profile, to provide a new enhanced work profile deployment scenario. And Android 11.0 will be a hard cut. Existing work profiles on fully managed devices will need to be migrated (to either a fully managed devices or to this new enhanced work profile) when upgrading to Android 11.0. The main driver for Google is the privacy of the user. Jayson Bayton wrote a great article around this subject. Also, when interested in anything around Android and Android Enterprise, I strongly advise to read more of his articles. It’s a great resource!

This change with Android 11.0 makes the future around the Android Enterprise fully managed devices with work profile deployment scenario, especially from a Microsoft Intune perspective, even more challenging. Even before that deployment scenario is available is available within Microsoft Intune. However, this shouldn’t be a reason for waiting even longer with the migration to Android Enterprise. Make sure to be familiar with the Android management requirements within your organization and built the solution and roadmap around those requirements. Often the lifecycle of the device is a good moment to look at a new method for managing the devices. Especially when looking at the supportability of new Android releases on existing devices. Don’t wait until the last moment and make a plan.

I would like to end by mentioning one last time that my advise is not to manage Android 10.0 with Android device administrator and only Microsoft Intune, as those devices will no longer be able to receive password requirements. To add-on to that, and to make my advise even stronger, make sure to be familiar with the upcoming restrictions to the Company Portal app on Android 10.0 devices managed via Android device administrator (see: Decreasing support for Android device administrator). Determine your own migration while you still can!

More information

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

Simplifying the migration of Android device administrator to Android Enterprise work profile management

This week is all about a recently introduced feature that will help organizations with their move away from Android device administrator managed devices to Android Enterprise work profile management. That is a very welcome feature as Google is decreasing device administrator support in new Android releases, which makes difficult for Microsoft Intune (and any other MDM-solution) to adequately manage Android device administrator managed devices starting with Android 10. The feature in Microsoft Intune that will help with moving away from Android device administrator managed devices is a compliance setting that will enable organizations to block devices in a structured manner and to provide a direct migration path to Android Enterprise work profile management.

In this post I’ll show how to create and configure a device compliancy policy that will slowly trigger end-users to start the migration to Android Enterprise work profile management, followed by the steps to block the enrollment of Android device administrator managed devices. Together that should help organizations to fully move away from Android device administrator managed devices. I’ll end this post by having a look at the end-user experience.

Configuring the device compliance policy

The first step is preparing a good migration experience, from Android device administrator managed devices to Android Enterprise work profile management, for the end-users. That can be achieved by creating a device compliance policy that eventually will block Android device administrator managed devices. To make sure that the end-user is not immediately being blocked from accessing company resources, I advise to use at least two levels of noncompliance. The first level would be that the end-user receives an email message with the advise to start the migration and the second level would be to actually block access to company resources. That can be after a longer period of noncompliance. The following seven steps walk through the steps for configuring a device compliance policy and provide some guidance for the different configurations. After the creation of the device compliance policy, assign the policy like any other policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices Android > Compliance policies to open the Android | Compliance policies blade
  2. On the Android | Compliance policies blade, click Create Policy to open the Create Policy blade
  3. On the Create Policy blade, provide the following information and click Create
  • Name: Provide a valid name for the device compliance policy
  • Description: (Optional) Provide a description for the device compliance policy
  • Platform: Select Android device administrator
  • Settings: See step 4 and 5
  • Locations: Leave default (for this post)
  • Actions for noncompliance: See step 6
  • Scope (Tags): Leave default (for this post)
  1. On the Android compliance policy blade, select Device Health to open the Device Health blade
  2. On the Device Health blade, select Block with Devices managed with device administrator and click OK to return to the Android compliance policy blade and click OK to return to the Create Policy blade
  3. On the Create Policy blade, select Actions for noncompliance to open the Actions blade
  4. On the Actions blade, add an action to first notify the user via email and make sure to adjust the default action to not mark a device as noncompliant immediately. That will provide the end-user with time to perform the migration before completely being blocked.

Note: The url https://portal.manage.microsoft.com/UpdateSettings.aspx can be used in the email message to launch the Company Portal app directly in the Update device settings page.

For automation purposes, automating the device compliance policy configuration can be achieved by using the deviceCompliancePolicies object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies

Configuring the device enrollment restrictions

The second step is making sure that new Android device administrator managed devices can no longer be enrolled into Microsoft Intune. That can be achieved by using device enrollment restrictions. The device enrollment restrictions can be used for blocking the enrollment of Android device administrator devices. The following five steps walk through the adjustment of the default enrollment restrictions. Something similar, and often more flexible, can be achieved by using custom enrollment restrictions.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Enroll devices > Enrollment restrictions to open the Enroll devices | Enrollment restrictions blade
  2. On the Enroll devices | Enrollment restrictions blade, select the Default device type restriction and navigate to Properties to open the All Users | Properties blade
  3. On the All Users | Properties blade, navigate to the Platform settings section and click Edit to open the Platform settings page on the Edit restriction blade
  4. On the Platform settings page, select Block with Android device administrator (see example below) and click Review + save to continue to the Review + save page
  5. On the Review + save page, click Save

For automation purposes, automating the device type restriction configuration can be achieved by using the deviceEnrollmentConfigurations object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/deviceEnrollmentConfigurations

End-user experience

Now let’s end this post by having a look at the end-user experience, which is the most important part of everything in this post. The end-user experience determines whether this migration process will be adopted by the end-user and whether this migration process is intuitive enough to walk the end-user through this migration process. My personal experience, after performing multiple of these migrations, is very positive. It catches problems and brings the end-user back to the progress in the Company Portal app. Even on an older device, which wasn’t encrypted, I eventually ended up in the Company Portal app.

Figure 4 to Figure 14 below, walk through the migration steps for the end-user when starting with an Android device administrator managed device and moving to Android Enterprise work profile management. Figure 5 is also the starting point when the end-user would click on the provided link in an email and Figure 15 provides an overview of the end result.

Note: In Figure 4 it already shows that the device status is “Not in Compliance“, while in fact the device can still be “In grace period“. Also, in Figure 5 the end-user will receive the message “Unable to resolve” when the enrollment of Android Enterprise (work profile) devices is restricted for the specific end-user.

More information

For more information about moving to Android Enterprise work profile management and enrollment restrictions, refer to the following docs:

Using bulk actions for renaming Windows devices

A few months ago, I did a blog post about the different ways of renaming Windows 10 devices. This week is a follow-up on that post, as it will also be about renaming Windows devices. This time it’s about using the recently introduced functionality to perform Bulk actions on devices. Those Bulk actions include the action to rename Windows 10 devices in bulk. That Bulk action is also available as a single action on a device and is currently not available for hybrid Azure Active Directory joined devices, nor available for co-managed devices. In this post I’ll show how to perform this action by using the Microsoft Endpoint Manager admin center, followed by using the Microsoft Graph Explorer. I’ll end this post by showing an example using PowerShell and the Microsoft Graph API.

Rename Windows devices using the Microsoft Endpoint Manager admin center

Now let’s start by having a look at using a Bulk action for renaming a Windows 10 device by using the Microsoft Endpoint Manager admin center. This method is – in my opinion – always the first step towards automating an action. The following 9 steps walk through the Bulk action for renaming Windows 10 devices. While performing these steps make sure to use Microsoft Edge and to turn on the Developer tools (Ctrl + Shift + I), as that will help with identifying the Graph request that should be used for automation purposes.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices All devices > Bulk Device Actions to open the Bulk device actions blade
  2. On the Basics page, provide the following information (see Figure 1) and click Next
  • OS: Select Windows
  • Device action: Select Rename
  • Enter new name: Provide a new naming conform the provided guidelines
  1. On the Devices page, click Select devices to include to select the devices to rename and click Next
  2. On the Review + create page, review the provided information and click Create

Verify request information using the Microsoft Graph Explorer

When following the Bulk action via the Network trace in the Developer tools, it shows the executeAction action that will perform the actual action. The most relevant parts of that action are shown below, as Figure 2 shows the request URL and Figure 3 shows the request payload. That combination is needed for automation purposes.

A closer look shows that the executeAction action is used as the request location to post the request.

https://graph.microsoft.com/beta/deviceManagement/managedDevices/executeAction

That request requires a request body to supply a JSON representation of the different properties. A closer look at that JSON payload shows the properties action, actionName, deviceIds, deviceName, platform, realAction and restartNow. The good thing is that these properties are pretty self explanatory, especially in combination with the action that was performed to retrieve this information. It’s good to specifically point out that the deviceIds property is an array that can currently contain up to a 100 devices and that the deviceName property should contain the naming format for the different applicable devices.

{
	action: "setDeviceName",
	actionName: "setDeviceName",
	deviceIds: ["d8cd02c1-9443-4ad0-8681-937c2e6d7607"],
	deviceName: "CLDCLN%RAND:2%",
	platform: "windows",
	realAction: "setDeviceName",
	restartNow: false
}

The next step toward automating this Bulk action is by trying the correct request URL and request payload via the Microsoft Graph Explorer, as that’s an easy method to try Graph API requests. Simply sign-in, change the action to POST, add the request URL, add the request payload (as shown in Figure 4) and click Run Query.

Note: The application requires the scope DeviceManagementManagedDevices.PrivilegedOperations.All.

Running the query will return a bulkManagedDeviceActionResult result type. That result type provides a JSON representation of the status properties. Those status properties include successfulDeviceIds, failedDeviceIds, notFoundDeviceIds and notSupportedDeviceIds. The good thing is that these properties are also pretty self explanatory. A simple method to verify this behavior is by throwing in some random deviceIds. Those deviceIds should end up as part of the notFoundDeviceIds.

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#microsoft.graph.bulkManagedDeviceActionResult",
    "successfulDeviceIds": [
        "d8cd02c1-9443-4ad0-8681-937c2e6d7607"
    ],
    "failedDeviceIds": [],
    "notFoundDeviceIds": [],
    "notSupportedDeviceIds": []
}

Rename Windows devices using PowerShell and the Microsoft Graph API

After verifying the request URL and the request payload, the last step toward automating this Bulk action is putting it all together in a PowerShell script. I’m going to provide a really simple example that would still require administrator interaction, but does show how it can be achieved. That example is shown below and basically performs the following actions:

  • Install the PowerShell SDK for Microsoft Intune Graph API (if it’s not installed).
  • Connect with the Graph API, which will prompt the administrator for credentials.
  • Set the required variables for the request URL and the request payload.
  • Invoke the Graph API request with the configured variables.
#Install PowerShell SDK for Microsoft Intune Graph API
If ((Get-Module Microsoft.Graph.Intune) -eq $null) {
    Install-Module -Name Microsoft.Graph.Intune
}

#Connect to Microsoft Graph
$ConnectGraph = Connect-MSGraph

#Set the request URL
$URL = "https://graph.microsoft.com/beta/deviceManagement/managedDevices/executeAction"

#Set the JSON payload
$JSONPayload = @"
{
	action: "setDeviceName",
	actionName: "setDeviceName",
	deviceIds: ["d8cd02c1-9443-4ad0-8681-937c2e6d7607"],
	deviceName: "CLDCLN%RAND:2%",
	platform: "windows",
	realAction: "setDeviceName",
	restartNow: false
}
"@

#Invoke the Microsoft Graph request
Try {        
    Invoke-MSGraphRequest -HttpMethod POST -Url $URL -Content $JSONPayload -Verbose -ErrorAction Stop
}
Catch {
    Write-Output "Failed to rename the Windows devices"
} 

When the PowerShell script was successfully executed it will also return the bulkManagedDeviceActionResult result type, as shown in Figure 5. Simple improvements to this PowerShell script would be to remove the administrator interaction, add the deviceIds to a variable and query for the required devices.

More information

For more information about renaming Windows devices and , refer to the following articles:

Using policy sets to group objects

This week is all about Policy sets in Microsoft Intune. Policy sets are introduced a few months ago and enable administrators to group management objects that need to be identified and assigned as a single object. That can help with simplifying the administration of the environment. A Policy sets can be a group of almost all different object that are available within Microsoft Intune. That includes objects for different platforms within the same Policy sets. This enables an administrator to use Policy sets for a lot of different use case, from creating a standard for a specific user type to creating a standard set of apps for all users. In this post I’ll walk through the configuration steps and through the different steps I’ll describe the available options and challenges. I’ll end this post with some notes about the assignment of a Policy set.

Creating policy sets

Now let’s have a closer looking at Policy sets by walking through the configuration. The following 9 steps walk through the creation of a Policy set and the different options.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices Policy sets to open the Policy sets blade
  2. On the Policy sets blade, select Policy sets and click Create to open the Create a policy set wizard
  3. On the Basics page, provide the following information (see Figure 1) and click Next: Application management
  • Policy set name: Provide a valid name for the Policy set
  • Description: (Optional) Provide a description of the Policy set
  1. On the Application management page, provide the following information (see Figure 2) and click Next: Device management
  • Apps: Click Select apps to add apps to the Policy set. That can be an iOS/iPadOS store app, an iOS/iPadOS line-of-business app, a Managed iOS/iPadOS line-of-business app, an Android store app, an Android line-of-business app, a Managed Android line-of-business app, an Office 365 ProPlus Suite (Windows 10), a Web link, a Built-in iOS/iPadOS app, or a Built-in Android app. That also means that a Windows app (Win32) is currently not supported. After adding an app to the Policy set, the assignment type can also be configured.
  • App configuration policies: Click Select app configuration policies to add app configuration policies to the Policy set.
  • App protection policies: Click Select app protection policies to add app protection policies to the Policy set. That can be an APP targeted at managed Windows devices, an APP targeted at managed iOS/iPadOSOS devices, an APP targeted at managed Android devices, an APP targeted at unmanaged iOS/iPadOSOS devices, or an APP targeted at unmanaged Android devices. That also means that APP targeted at unmanaged Windows devices are not supported.
  1. On the Device management page, provide the following information (see Figure 3) and click Next: Device enrollment
  • Device configuration policies: Click Select device configuration policies to add device configuration policies to the Policy set.
  • Device compliance policies: Click Select device compliance policies to add device compliance policies to the Policy set. Only the Android Enterprise device owner type policies are not available.
  1. On the Device enrollment page, provide the following information (see Figure 4) and click Next: Scope tags
  • Device type restrictions: Click Select device type restrictions to add custom device type restrictions to the Policy set.
  • Windows autopilot deployment profiles: Click Select Windows autopilot deployment profiles to add Windows autopilot deployment profiles to the Policy set.
  • Enrollment status pages: Click Select enrollment status page profiles to add custom enrollment status page profiles to the Policy set.
  1. On the Scope tags page, provide the following information (see Figure 5) and click Next: Assignments
  • Scope tags: Click Select scope tags to add custom scope tags to the Policy set.
  1. On the Assignments page, provide the following information (see Figure 6) and click Next: Review + create
  • Included groups: Click Select groups to include to include groups to the assignment of the Policy set.
  • Excluded groups: Click Select groups to exclude to exclude groups from the assignment of the Policy set
  1. On the Review + create page, verify the following information and click Create

After going through the configuration of a Policy set it’s good to note that security baselines are not part of a Policy set configuration. The guided scenario Try out a cloud-managed PC also creates a policy set to group the different objects that are created during the guided scenario and that are supported as being a part of the guided scenario. That scenario also creates a security baseline assignment that is not part of the created Policy set. Guided scenarios are available on the Home page of the Microsoft Endpoint Manager admin center.

For automation purposes, it might be better to know how to automate the device type restriction configuration. That can be achieved by using the policySet object in the Graph API.

https://graph.microsoft.com/beta/deviceAppManagement/policySets

Assignment notes

Let’s end this post with some notes about the assignment of a Policy set. The following should be kept in mind when creating the assignment for the Policy set.

  • The different non-Windows app protection policies (APP) do not support an assignment via a Policy set. In that case the group will be added as a direct assignment. Those assignments will not be deleted when the assignment of the Policy set is removed.
  • The different APPs do not support an assignment to All users or All devices
  • A Windows autopilot deployment profile does not support an assignment to All users
  • An Enrollment status page profile does not support the assignment of virtual groups (All users, All devices or All user & All devices)
  • An Device type restriction profile does not support the assignment of virtual groups (All users, All devices or All user & All devices)

When the assignment of the Policy set is created it will show as a specific assignment with the different objects that are part of the Policy set (as shown in Figure 8).

More information

For more information about using policy sets for managing groups of objects in Microsoft Intune, refer to the documentation about Use policy sets to group collections of management objects.

Enabling the ConfigMgr administration service through the cloud management gateway

This week is all about the administration service in Configuration Manager. More specifically, about enabling the Configuration Manager administration service via the cloud management gateway (CMG) to make it available over the Internet. The administration service provides API interoperability access to WMI over HTTPS via the SMS Provider. This REST API can be used in place of a custom web service to access information of the Configuration Manager site. Some really good information and starting points about this subject can be found at this blog post by Adam Gross. In this post I’ll skip the basics and specifically look at making the administration service available over the Internet. I want to provide in my own style what the configuration requirements are and why they are needed. I’ll start this post by showing the required configurations in Configuration Manager and in Azure AD and I’ll end this post by retrieving the most common parameters for scripting.

Before starting with the actual configurations, I want to post a little thank you message: Thank you Sandy for answering my (dumb) questions while I should simply read better.

Configuring the SMS Provider properties

The administration service is available with the installation of the SMS Provider. Every site system with an SMS Provider has the administration service. Before being able to enable the SMS Provider over the CMG, the following prerequisites should be in-place:

  • The server that hosts the SMS Provider role requires .NET 4.5.2 or later
  • Enable the SMS Provider to use a certificate, by either using Enhanced HTTP or by manually binding a PKI-based certificate on the server that hosts the SMS Provider role
  • A running CMG (as I’m not going through that installation)

When those prerequisites are in-place, the SMS Provider can be configured to allow CMG traffic for the administration service by following the next three steps.

  1. Open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Servers and Site System Roles
  2. Select the server that hosts the SMS Provider role, select the SMS Provider role and click Properties in the Site Role tab to open the Provider role properties dialog box
  3. On the Provider role properties dialog box, select Allow Configuration Manage cloud management gateway traffic for administration service and click OK

Register a new app with Azure AD

For accessing the administration service via the CMG, two apps must be created within Azure AD, 1) a Web app (also known as a Server app within Configuration Manager) that is used for making the administration service available and 2) a Native app (also known as a Client app within Configuration Manager) that is used for obtaining an access token for the user. That access token can be sent in a request to the Web app, which authorises the user and returns the administration service.

During the creation of the cloud services within Configuration Manager a Web app and a Native are already created. I need to (and can) access the administration service via that created Web app, but I don’t want to reuse the existing Native app as I need to make some adjustments and I don’t want to interfere with existing functionalities. The following steps walk through the registration and configuration of a new Native app with the required configurations to obtain and access token for the user and be able to sent that token in a request to the Web app.

  1. Open the Azure portal and navigate to Azure Active Directory  > App registrations to open the App registrations blade
  2. On the App registrations blade, click New registration to open the Register an application blade
  3. On the Register an application blade, provide the following information (as also shown below) and click Register
  • Name: Provide a valid name for the Web app (in this post: ConfigMgrAdminService)
  • Supported account types: Select Accounts in this organisational directory only ({yourTenant} only – Single tenant)
  • Redirect URI (optional): Select Public client/native (mobile & desktop) and provide https://login.microsoftonline.com/common/oauth2/nativeclient as Redirect URI

Note: The mentioned redirect URI, is the latest recommended value for desktop applications running on Windows (see also: https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-desktop-app-registration).

  1. After the registration of the app, navigate to Authentication to open the Authentication blade
  2. On the Authentication blade, navigate to the Default client type section and select Yes with Required for the use of the following flows where a redirect URI is not used (as shown below) and click Save
  1. Navigate to API permissions to open the API permissions blade
  2. On the API permissions blade, click Add a permission to open the Request API permissions blade
  3. On the Request API permissions blade, select APIs my organisation uses and select the Web app – the standard name of that app is ConfigMgrService (as shown below) – that was initially created during the setup of the cloud services to open the specific API permissions blade
  1. On the specific API permissions blade, select Delegated permissions, select user_impersonation and click Add permissions (as shown below) to return to the API permissions blade
  1. On the API permissions blade, select Grant admin consent for {yourTenant} (as shown below

Retrieve the parameters to start with PowerShell

After configuring the SMS Provider properties, registering and configuring the Native app, the administration service is available via the CMG. The next step is to actually externally connect with the administration service. However, this might be an open door, but before doing that it’s good to understand that the user that is authentication and connecting with the administration service must have sufficient permissions within Configuration Manager.

At this moment I won’t provide an example, that might be something for a future post, but for now I’ll refer to this great post by Zeng Yinghua (also known as Sandy) and this repository about the Microsoft Graph (as the idea for retrieving a token is the same). The main challenge in any of those scripts is getting the token. To successfully achieve that, the following information is often required.

  1. Application (client) ID of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 1).
  2. Tenant ID of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 2).
  3. Redirect URI of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 3) or copying the information that was provided in step 3 during the registration of Native app in Azure AD.
  1. Application ID URI of the Web app that is named by default ConfigMgrService. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrService > Overview (shown in the figure below with number 4)
  1. External URL of the administration service. That information can be the easiest retrieved in SQL by using the query below on the ConfigMgr database
select ExternalEndpointName, ExternalUrl from vProxy_Routings
where ExternalEndpointName = 'AdminService'

More information

For more information about Configuration Manager administration service, please refer to the documentation about the SMS Provider.

Device compliance based on custom configuration baselines

This week is all about the new feature to include a custom configuration baselines as part of a compliance policy assessment. That’s a new feature that is introduced in Configuration Manager, version 1910. That will also make this a followup on the post I did earlier this year about using the power of ConfigMgr together with Microsoft Intune to determine device compliance. This will be added functionality, as it’s now possible to make custom configuration baselines part of the device compliancy check. For both, Configuration Manager managed devices and co-managed devices. Even when the workload is switched to Microsoft Intune.

Introduction

This option that makes it possible to use a custom device configuration baseline part of a compliancy policy, opens up a whole new world of possibilities. Especially when knowing that this can also be used when co-managing devices. This enables organisations to create a custom device configuration baseline for specific business requirements that cannot be captured by using the default functionalities that are available for Configuration Manager and Microsoft Intune.

This provides a lot of flexibility for devices that are either managed by Configuration Manager, or that are co-managed by using a combination Configuration Manager and Microsoft Intune. In the latter scenario, that even still provides that flexibility when the compliance policies workload is switched to Microsoft Intune. In that case Microsoft Intune can be configured to take the ConfigMgr compliance assessment result as part of the overall compliance status. The info gets sent to Azure AD and can be used for conditional access. In this post I’ll show how to correctly configure the device compliance policy, the configuration baseline and (optionally) the Configuration Manager compliance.

Before starting with the different configurations it’s good to keep in mind that if the compliance policy evaluates a new baseline that has never been evaluated on the client before, it may report non-compliance at first. This occurs if the baseline evaluation is still running when the compliance is evaluated.

Configure device compliance policy

The first configuration that should be in place is the device compliance policy. The device compliance policy is used to determine the compliance status of the device. Within the device compliance policy, a new rule is available that will enable the evaluation of configuration baselines as part of the compliance of the device. The following steps walk through the creation of a new device compliance policy including the required rule. The device compliance policy can be deployed like any other device compliance policy.

  1. Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies
  2. Click Create Compliance Policy to open the Create Compliance Policy Wizard
  3. On the General page, provide the following information and click Next
  • Name: Provide a valid name for the compliance baseline
  • Description: (Optional) Provide a description for the compliance baseline
  • Select Compliance rules for devices managed with Configuration Manager client
  1. On the Supported Platforms page, select Windows 10 and click Next
  1. On the Rules page, perform the following actions and click Next
  • Click New to open the Add Rule dialog box
  • On the Add Rule dialog box, select Include configured baselines in compliance policy assessment and click OK
  1. On the Summary page, click Next
  2. On the Completion page, click Close

Configure configuration baseline policy

The second configuration that should be in place is the configuration baseline policy. The configuration baseline policy is used to configure, or verify, specific configuration on a device. Within a configuration a new settings is available that will make the evaluation of the configuration baseline a part of the compliance evaluation. The following steps will walk through the process of creating a new configuration baseline including the new setting. In my example I’m adding a configuration item that will verify if the local administrators comply the the organisation defaults. The configuration baseline can be deployed like any other configuration baseline.

  1. Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines
  2. Click Create Configuration Baseline to open the Create Configuration Baseline dialog box
  1. On the Create Configuration Baseline dialog box, provide the following and click OK
  • Name: Provide a valid name for the configuration baseline
  • Description: (Optional) Provide a description for the configuration baseline
  • Configuration data: Select the required configuration items that should be part of this configuration baseline
  • Select Always apply the baseline even for co-managed devices
  • Select Evaluate the baseline as part of compliance policy assessment

The combination of these settings will make sure that the configuration baseline is applied to co-managed devices and that the configuration baseline will be evaluated as part of the compliance. Keep in mind that any baseline with the second option selected, that is deployed to the user, or to the user’s device, is evaluated for compliance.

(Optional) Configure Configuration Manager Compliance

An optional configuration is to configure Microsoft Intune to also look at information of Configuration Manager for determining the compliance. In my scenario that is a required configuration as I’m using it in combination with co-managed devices. Within a compliance policy a setting is available that will require compliance from Configuration Manager. The following steps walk through the configuration of that setting in a device compliance policy. Nothing more, nothing less. The device compliance policy can be assigned like any other device compliance policy.

  1. Open the Microsoft 365 Device Management portal and navigate to Devices Windows > Compliance policies to open the Windows – Compliance policies blade
  2. On the Windows – Compliance policies blade, click Create Policy to open the Create Policy blade
  3. On the Create Policy blade, provide the following information and click Create
  • Name: Provide a valid name for the compliance policy
  • Description: (Optional) Provide a description for the compliance policy
  • Platform: Select Windows 10 and later
  • Settings: See step 4 and 5
  • Actions for noncompliance: Leave default (for this post)
  • Scope (Tags): Leave default (for this post)
  1. On the Windows 10 compliance policy blade, select Configuration Manager Compliance to open the Configuration Manager Compliance blade
  2. On the Configuration Manager Compliance blade, select Require with Require device compliance from System Center Configuration Manager and click OK to return to the Windows 10 compliance policy blade and click OK

Experience

Now let’s end this post by having a look at the end-user experience. In my scenario I’ve created a custom configuration baseline that will verify the number of local administrators on the device. When it’s above a specific number of local administrators, the device is considered not compliant as the device might be compromised. In that case the end-user will receive a message in the Company Portal app as shown below. It explains the end-user that the security settings should be updated and to look for more information in Software Center.

When looking at Software Center it actually provides exactly the same message to the end-user. It provides the end-user with the message that the security settings should be updated. For more information the end-user should contact the support department. So make sure that the requirements are clear to the end-user.

More information

For more information see the Include custom configuration baselines as part of compliance policy assessment section of the Create configuration baselines doc.