Installing applications by using Windows Package Manager

This week is all about installing applications via Microsoft Intune by using Windows Package Manager. A few years ago I wrote a post about something similar by using Chocolatey. That time the idea was to simply leverage the PowerShell script functionality that was just introduced. This time the idea is to leverage the Win32 app functionality together with the Windows Package Manager that is just introduced. Leveraging the Win32 app functionality provides me with a few advantages above simply leveraging the PowerShell script functionality. In my opinion the main advantages are the flexibility of the Win32 app model (think about requirements, detection rules, dependencies and notifications) and the ability to use Win32 apps during the Enrollment Status Page (ESP). Creating the Win32 app would cost a little bit more work, but comes with big rewards. In this post I’ll start with a short introduction about Windows Package Manager, followed by the actions and steps for creating a Win32 app that will use Windows Package Manager to install Microsoft PowerToys (as an example app). I’ll end this post by having a look at the end-user experience.

Introduction to Windows Package Manager

Let’s start with a short introduction to Windows Package Manager. Windows Package Manager is a package manager, like any other package manager. It basically provides an administrator (or actually any user with administrative rights) with a set of software tools that help with automating the process of getting apps on a device. The administrator (or user with administrative rights) can specify which apps should be installed, and the package manager does the work of finding the latest version (or a specifically specified version) and installing it on a device. That provides a streamlined experience for installing, updating and uninstalling apps. However, at this moment Windows Package Manager is in its early stages. That means that it doesn’t provide all the expected functionality yet. At the moment of writing this post, Windows Package Manager only provides installation functionality.

Using Windows Package Manager

Now let’s have a look at how we can use Windows Package Manager, in its current shape, in combination with Microsoft Intune. Similar to any other package manager, Windows Package Manager provides a nice repository with apps that can be deployed to devices in an automated way. My suggestion is to use three steps for installing apps by using Windows Package Manager with Microsoft Intune: 1) create a small PowerShell script that will trigger Windows Package Manager, 2) wrap the PowerShell script with the Win32 content prep tool and 3) create and assign the Win32 app in Microsoft Intune.

Prerequisites for using Windows Package Manager

Before looking at the actual configuration steps, let’s start by scoping this post a little bit. This post is focussed on using Windows Package Manager and is not focussed on installing Windows Package Manager. I do provide some guidelines of working with this. Especially as I’m using the Win32 app functionality, it provides all the room for adding functionalities and depending installations. For now it’s important to know how to install Windows Package Manager (winget) tool.

Besides that keep in mind that the Windows App Installer is installed per user, which means that the availability of the Windows Package Manager is also per user. That is important to know when installing apps by using Windows Package Manager, as it would require to run in the user context and it would require the user to have administrative permissions to install apps. Also, as mentioned earlier, at this moment creating an update or uninstall for an app requires creativity.

Creating a PowerShell script

Now let’s use Microsoft PowerToys as an example app for using Windows Package Manager. Also, I’m deliberately using a single app, as that provides me with more flexibility for installing other apps and more insights for reporting. The first step is creating a small PowerShell script that will simply use Windows Package Manager for installing Microsoft PowerToys. The following snippet will silently install Microsoft PowerToys, by looking at an exact match of the provided name, and log the installation details to the provided location.

winget install --exact --silent "Microsoft.PowerToys" --log "C:\Windows\Temp\Install-MicrosoftPowerToys.txt"

Note: It’s also possible to use abbreviations of the specified parameters, but I thought that using the full names would provide a more clear example. In this command -e can be used instead of –exact, -h can be used instead of –silent and -o can be used instead of –log.

Using the Win32 content prep tool

The second step is to use the Win32 content prep tool to convert the just created PowerShell script into the .intunewin format. That enables me to upload the .intunewin file into Microsoft Intune and to create a Win32 app of the installation of Microsoft PowerToys. The following three steps walk through the required steps for converting the PowerShell script into the .intunewin format. As the setup file I can simply refer to the PowerShell script.

  1. Download the Microsoft Win32 Content Prep Tool
  2. Create a folder that contains the just created PowerShell script (and potentially an uninstall script)
  3. Open the Windows Terminal by using Run as administrator and run the Microsoft Win32 Content Prep Tool by using a command similar to the following
.\IntuneWinAppUtil.exe -c C:\Temp\PowerToys -s Install-wingetPowerToys.ps1 -o C:\Temp -q

Note: In this command -c is used to specify the source folder, -s is used to specify the setup file, -o is used to specify the output folder and -q is used to run in quiet mode.

Creating and assigning the Win32 app

The third step is to add the .intunewin file of Microsoft PowerToys to Microsoft Intune as a Win32 app. The main reasons for using a Win32 app, are the power of the Win32 app model and the integration with the ESP. The Win32 app model can be used to detect the availability of Windows Package Manager (and eventually configure it as a dependency), or simply verify for the correct version of Windows 10 that contains Windows Package Manager by default. The following seven steps walk through the steps of creating and assigning the Win32 app in Microsoft Intune that will install Microsoft PowerToys by using Windows Package Manager.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps > All apps to open the Apps | All apps page
  2. On the Apps | All apps page, click Add to open the Select app type page
  3. On the Select app type page, select Other > Windows app (Win32) and click select to open the Add App wizard
  4. On the App information page, click Select app package file, select the just created .intunewin file, provide at least the following and click Next
  • Name: Provide a valid and unique name for the Microsoft PowerToys app
  • Description: Provide a description for the Microsoft PowerToys app
  • Publisher: Provide a publisher for the Microsoft PowerToys app
  1. On the Program page, provide at least the following information and click Next
  • Install command: Provide an install command similar to the following that will simply call the PowerShell script within the .intunewin file that will be used to install Microsoft PowerToys by using Windows Package Manager (winget) – PowerShell.exe -ExecutionPolicy Bypass -Command .\Install-wingetPowerToys.ps1
  • Uninstall command: Provide an uninstall command similar to the following that will be used to uninstall Microsoft PowerToys. Keep in mind that Windows Package Manager (winget) currently doesn’t support the uninstall of an app, which means that at this moment the uninstall would require some additional custom scripting (not the scope of this post) – PowerShell.exe -ExecutionPolicy Bypass -Command .\Uninstall-wingetPowerToys.ps1
  • Install behavior: Select User as the install behavior to make sure that the installation can actually use Windows Package Manager (winget) for installing Microsoft PowerToys. The App Installer app will make sure that winget is available on the device, but as it’s a Store app (or appxbundle) it will be installed for the user and not for the system.
  1. On the Requirements page, provide at least the following information and click Next
  • Operating system architecture: Select the applicable operating system architectures for the Microsoft PowerToys app
  • Minimum operating system: Select Windows 10 1803 as the operating system for the Microsoft PowerToys app (the minimum operating system for winget is not relevant in this case as it’s Windows 10 1709)
  • Configure additional requirement rules: (Optional) Configure a custom requirement that will detect a specific minimal Windows 10 version that includes Windows Package Manager
  1. On the Detection rules page, provide at least the following information and click Next
  • Rule format: Select Manually configure detection rules
  • Click Add to add a detection rule for the Microsoft PowerToys app that can be similar to the following configuration and click OK
  • Rule type: Select File
  • Path: Type C:\Program Files
  • File or folder: Type PowerToys
  • Detection method: Select File or folder exists
  • Associated with a 32-bit app on 64-bit clients: Select No
  1. On the Dependencies page, configure any required dependencies for the Microsoft PowerToys app or Windows Package Manager (winget), which can also be used to make sure that Windows Package Manager is always automatically installed as a dependency and click Next
  2. On the Scope tags page, configure any required scope tags for the Microsoft PowerToys app and click Next
  3. On the Assignments page, configure the applicable assignments for the Microsoft PowerToys app (make sure to show the default notifications to the end-user) and click Next
  4. On the Review + create page, review the configuration of the Microsoft PowerToys app and click Create

End-user experience

Let’s end this post by looking at the end-user experience (and mentioning the best places to look from an administrator perspective).

The best place to look at for the end-user experience is the action center in Windows. Action center contains all the different notifications, including those that are provided by the Microsoft Intune Management Extension. Those notifications are one of the reason why I like to use a Win32 app, as it provides a very plain and simple interaction with the end-user. As soon as the user receives the required assignment of Microsoft PowerToys, the user will be notified. After that the user will receive notifications when downloading and installing Microsoft PowerToys and when the installation is successfully performed. All of those notifications are shown on the right.

From an administrator perspective, the log files would probably be more interesting. To follow the installation of Microsoft PowerToys, which is started via Windows Package Manager, the administrator can look at the location provided in the winget command (in my case: C:\Windows\Temp\Install-MicrosoftPowerToys.txt). To follow the process of the Win32 app, the administrator can look at the standard log file of the Microsoft Intune Management Extension (IntuneManagementExtension.log).

More information

For more information about the usage and the introduction of the Windows Package Manager and working Win32 apps in Microsoft Intune, refer to the following articles.

Quick tip: Allow access to unlicensed admins

This week a quick extra blog post about a small nice new feature that became available in Microsoft Intune. That feature is the setting to allow access to Microsoft Intune for unlicensed admins. That setting enables an organization to toggle a tenant-wide setting that removes the Intune license requirement for administrators when accessing the Microsoft Endpoint Manager admin console (and Microsoft Graph). Once toggled it can never be reinstated.

The following two steps walk through the process of allowing access to unlicensed admins

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Tenant administrationRoles > Administrator Licensing to open the Intune roles | Administrator Licensing page
  2. On the Intune roles | Administrator Licensing page, click Allow access to unlicensed admins
  3. On the Allow access to unlicensed admins verification window, click Yes

After following these steps all unlicensed administrators have access to Microsoft Intune. To revoke the access of an unlicensed administrator, simply remove their membership of any Intune role.

Configuring eSIM profiles on Windows devices

This week is all about configuring eSIM profiles on Windows 10 devices by using Microsoft Intune. An eSIM is an embedded digital version of a SIM card that enables the user to connect to the mobile network provider, without an actual physical SIM card. It can be programmed to the mobile network provider and data plan of choice. That can provide an Internet connection over a cellular data connection on an eSIM-capable device. Even though the eSIM functionality is available for most platforms, Microsoft Intune currently only supports the configuration of eSIM profiles on Windows 10 devices. In this post I’ll start with a short introduction, followed by the steps to import and assign eSIM profiles. I’ll end this post by having a look at the end-user experience.

Introduction to eSIM profiles

Windows 10 provides programmatical support for provisioning an eSIM profile on the device and Microsoft Intune enables organizations to use that functionality to automatically provision eSIM profiles on the device. Microsoft Intune provides organizations with the capability to import the activation codes that are provided by the mobile network operator. That can be used to configure the related cellular data plans on the eSIM module by deploying those activation codes to the Windows 10 devices. When Intune installs the activation code, the eSIM hardware module uses the data in the activation code to contact the mobile network provider. Once completed, the eSIM profile is downloaded to the device, and configured for cellular activation. To deploy eSIM profiles to the Windows 10 devices by using Microsoft Intune, the following are needed:

  • eSIM capable device – such as the Surface Pro X
  • Windows 10 version 1709 or later that is enrolled and managed by Microsoft Intune
  • Activation codes provided by the mobile operator (more about those later)

Deploying eSIM profiles on Windows devices

The deployment of eSIM profiles by using Microsoft Intune can be divided into three actions. The first action is creating the CSV-file, the second action is importing the CSV-file and the third action is assigning the eSIM profile.

Creating the CSV-file

Let’s start with the first action, which is creating the CSV-file. This is an important step, as the CSV-file as to contain specific information and the CSV-file is not the same on every line. When creating the CSV-file be sure to be familiar with the following

  • The activation codes in the CSV-file are used one time, but can be imported multiple times by using different CSV-files – Importing an activation code multiple times may cause problems when deploying the same activation code to multiple devices.
  • The CSV-file should be specific to a single mobile network operator and the activation codes should be specific to the same billing plan. 
  • The CSV-file can contain a maximum of 1000 activation codes that can be imported.
  • The name of the CSV-file should be unique – Importing a CSV-file with an existing name will cause problems.
  • The structure of the CSV-file must follow the format as described below. 
  1. The name of the CSV-file becomes the cellular Subscription pool name
  2. The first row of the CSV-file contains the URL of the mobile network operator eSIM activation service, also known as the Subscription Manager Data Preparation server (SM-DP+).
  3. The second and all later rows of the CSV-file contains the unique one-time use activation codes that include two values:
    1. First column contains the unique ICCID (the identifier of the SIM chip)
    2. Second column contains the Matching ID (the actual activation code)

Importing the CSV-file (adding the cellular subscription)

The second action is importing the created CSV-file, which will add cellular subscriptions to Microsoft Intune. This can be achieved by simply following the three steps below.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > eSIM cellular profiles to open the Devices | eSIM cellular profiles (Preview) page
  2. On the Devices | eSIM cellular profiles (Preview) page, click Add to open the Add cellular subscription blade
  3. On the Add cellular subscription blade, browse to the created CSV-file that contains the activation codes and click OK to add them.

Adding cellular subscriptions by using the Graph API can be achieved by using the embeddedSIMActivationCodePools object.

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

Assigning the eSIM cellular profile

The third action is assigning the eSIM cellular profile, which will deploy the eSIM profile to the devices. It’s important to know that this should always be a device group. An eSIM profile is only applicable to devices. Once the eSIM profile is assigned to a group of devices, Microsoft Intune randomly distributes the activation codes to members of the group. There isn’t any guarantee which device gets a specific activation code. Also, when a device has another assignments of different eSIM profile, the device will also add an eSIM profile of that assignment. That makes it possible to provision multiple eSIM profiles on a single device. Assigning the eSIM profile to a group of devices can be achieved by following the next three steps.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > eSIM cellular profiles to open the Devices | eSIM cellular profiles (Preview) page
  2. On the Devices | eSIM cellular profiles (Preview) page, and select the created cellular subscription followed by Assignments to open the {{CellularSubscriptionName}} | Assignments blade
  3. On the {{CellularSubscriptionName}} | Assignments blade, select the required device group and click Save to assign them

Note: Removing a device from the assignment, or deleting the eSIM cellular profile, will trigger Microsoft Intune to remove the eSIM profile from the device.

Assigning the cellular subscriptions by using the Graph API can be achieved by using the assignments object for a specific cellular subscriptions pool.

https://graph.microsoft.com/beta/deviceManagement/embeddedSIMActivationCodePools/{embeddedSIMActivationCodePoolId}/assignments

The eSIM profile experience

Let’s end this post by having a look at the experience for the end-user and the administrator. First the end-user experience. After the device checks-in, receives the eSIM profile and is successfully activated, the user receives the notification that a new eSIM profile is available (as shown in Figure 2). As mentioned in the notification, the user still needs to select the profile to use. To achieve that, the user can click in that notification on Settings > Manage eSIM profiles. That will bring the user to the place to manage the eSIM profiles (as shown in Figure 3). The user can select the applicable profile and click on Use. That will enable the user to actually use the eSIM profile.

The administrator experience is a little bit different from normal policy assignments. The best administrator experience is available by navigating to Devices > eSIM cellular profiles selecting a specific profile and selecting the Device status. That provides an overview as shown below (in Figure 4). The information of the different columns is explained below.

  • Device Name – The name of the assigned device
  • User – The name of the user whom enrolled device
  • ICCID – The unique code provided by the mobile network operator within the activation code installed on the device (this information is also part of the imported CSV-file)
  • Activation Status – The delivery and installation status of the activation code on the device by Microsoft Intune
  • Cellular status – The state provided by the mobile network operator
  • Last Check-In – Date the device last communicated with Intune

More information

For more information about configuring eSIM profiles on Windows devices, refer to this article about configuring eSIM cellular profiles in Intune (public preview).

Pushing notifications to users on iOS and Android devices

This week is all about the different options in Microsoft Intune to send push notifications to users on iOS (and iPadOS) and Android devices. The trigger of this post is the option to send push notifications as an action for noncompliance, which was introduced with the 2005 service release of Microsoft Intune. Besides that, it was already possible to send custom notifications to a single device, to the devices of a group of users, or as a bulk action to multiple devices. In this post I want to go through the different options for sending push notifications, followed by showing the end-user experience.

Send custom notifications

Custom notifications can be used to push a notification to the users of managed iOS (including iPadOS) and Android devices. These notifications appear as push notifications from the Company Portal app (or Microsoft Intune app) on the device of the user, just as notifications from other apps. A custom notification message includes a title of 50 characters or fewer and a message body of 500 characters or fewer. Besides those message limitations, the following configurations should be in place for a device to be able to receive push notifications.

  • The device must be MDM enrolled.
  • The device must have the Company Portal app (or Microsoft Intune app).
  • The Company Portal app (or Microsoft Intune app) must be allowed to send push notifications.
  • An Android device depends on the Google Play Services.

Send custom notification to a single device

The method for sending a custom notification to a single device is by using device actions. To use device actions for sending a custom notification to a single device, simply follow the three steps below.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > All devices {{select Android or iOS device} to open the Overview page of the specific device
  2. On the Overview page, select the Send Custom Notification device action (when the option is not available, select the  option first from the upper right side of the page) to open the Send Custom Notification pane
  3. On the Send Custom Notification page, specify the following message details and select Send to send the notification to the device
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to a single device can be achieved by using the sendCustomNotificationToCompanyPortal object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/managedDevices('{IntuneDeviceId}')/sendCustomNotificationToCompanyPortal

Send custom notification to a group of devices

There are actual two methods for sending a custom notification to a group of devices. The first method for sending a custom notification to a group of devices is by using the tenant administration. That can be achieved by using the four steps below. The twist is that those steps will enable the administrator to send a notification to a group, which will only target the users of that group. The notification will then only go to all the iOS (and iPadOS) and Android devices that are enrolled by that user.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Teant administration Custom notifications to open the Tenant admin | Custom notifications blade
  2. On the Basics page, specify the following message details and select Next
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation
  1. On the Assignments page, select the group that should be used to send this notification to and click Next
  2. On the Review + Create page, review the information and click Create to send the notification

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to the devices of a group of users can be achieved by using the sendCustomNotificationToCompanyPortal object in the Graph API.

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

The second method for sending a custom notification to a group of devices is by using bulk actions. That can be achieved by using the four steps below. Those steps will enable the administrator to send a notification to multiple selected iOS (and iPadOS) and Android devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices All devicesBulk Device Actions to open the Bulk device actions blade
  2. On the Basics page, specify the following details and select Next
  • OS – Select the platform of the devices that should receive this notification (Android (device administrator), Android (Work Profile), or iOS/iPadOS)
  • Action – Send custom notification
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation
  1. On the Assignments page, select the devices to send this custom notification to and click Next
  2. On the Review + Create tab, review the information and click Create to send the notification

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to multiple selected devices can be achieved by using the executeAction object in the Graph API.

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

Send noncompliance notification

Noncompliance notifications can be used to push a notification to a device about the noncompliance state of the device. These notifications appear as push notifications from the Company Portal app on the device of the user, just as notifications from any other app. The notification is pushed to the device, the first time after the device is noncompliant and checks in with Microsoft Intune (depending on the configured schedule of the push notification). The message of the notification contains the details about the noncompliance and can’t be customized. Also, the notification is only pushed a single time. To push multiple notifications, simply add multiple actions. The four steps below show how to add a noncompliance action that will send a push notification to a compliance policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Endpoint security Device compliancePolicies to open the Compliance policies | Policies blade
  2. On the Compliance policies | Policies page, either create a new policy, or edit an existing policy (this example is of editing an existing policy)
  3. On the Actions for noncompliance page, select Send push notification as an additional action
  1. On the Review + save page, click Save

For automation purposes, automating updating a device compliance policy can be achieved by patching the specific deviceCompliancePolicies object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies/{policyId}

End-user experience

Let’s end this post by having a look at the end-user experience. The push notifications will show on the lock screen just as notifications from any other app. Below on the left (Figure 5) is showing an example of the lock screen that contains a custom notification and a noncompliance notification. Below in the middle (Figure 6) is showing an example of a custom notification when the Company Portal app was open. The user will go to the same page in the Company Portal app, when clicking on the custom notification on the lock screen. Below on the right (Figure 7) is showing an example of the page in the Company Portal app, when clicking the noncompliance notification. That will enable the user to immediately take action.

Note: The experience on Android devices is similar. However, keep in mind that on Android devices, other apps might have access to the data in push notifications.

More information

For more information about the different options to send push notifications to users on iOS and Android devices, refer to the following docs:

Simplifying management of the Google Chrome browser

This week is all about simplifying the management of the Google Chrome browser. I’ve done my fair share of posts about different methods for managing settings for the Google Chrome browser, by using Microsoft Intune, like for example by using ADMX-files or by using PowerShell, but it can be easier. It can also be achieved by using Chrome Browser Cloud Management. Chrome Browser Cloud Management is a cloud-based solution that enables the management of the Google Chrome browser across Windows, Mac and Linux devices. In this post I’ll start with a short introduction about Chrome Browser Cloud Management, followed by the steps to enrol Windows devices by using Microsoft Intune. I’ll end this post by looking at the end-user experience.

Note: Keep in mind that this post is only intended to provide a simple management solution for the Google Chrome browser. Please make your own consideration if this would be added value for your organization.

Introduction to Chrome Browser Cloud Management

Let’s start with a short introduction to Chrome Browser Cloud Management. Chrome Browser Cloud Management provides the IT administrator with a unified managed experience across Windows, Mac and Linux devices via a single cloud-based console. That removes the need to use different management tools for different platforms when managing Google Chrome across the organisation. Besides that, it can even provide benefits when managing a single platform. Even in combination with Microsoft Intune. At this moment, Microsoft Intune can provide some challenges with managing Google Chrome, as it would require the use of either PowerShell scripting or ADMX-files. Both, at this moment, time intensive activities. In that case, using Chrome Browser Cloud Management would add an additional management tool, but would save time in configurations.

Chrome Browser Cloud Management provides a method to enroll Google Chrome browsers by providing an enrollment token to the browser. On Windows devices that can be achieved by applying a simple registry key. Once the Google Chrome browsers are enrolled, the Chrome Browser Cloud Management enables the management over user settings and apps and extensions. Both contain some often used configurations. Below are a couple of examples of often used configurations. Figure 1 shows how to easily configure the Homepage and Page to load on startup setting and Figure 2 shows how to easily add the Windows 10 Accounts extension.

Enroll cloud-managed Google Chrome browsers

Now let’s continue by looking at enrolling Google Chrome browsers. Basically that requires two actions. The first actions is to generate the enrollment token and the second action is to enroll Google Chrome browsers by using the enrollment token.

Action 1: Generate enrollment token

The first action is to generate and enrollment token. That token will be used for enrolling the Google Chrome browsers. The following four steps walk through the process of generating that token.

  1. Open the Google Admin console and navigate to Devices > Chrome management > Managed browsers to open the Managed browsers page
  2. On Managed browsers page, on the right bottom of the screen click on the + button to open the Chrome Browser Cloud Management License Agreement dialog box
  3. On the Chrome Browser Cloud Management License Agreement dialog box, click I ACCEPT to generate an enrollment token and to open the Enrollment token dialog box
  4. On the Enrollment token dialog box, click the copy sign to copy the enrollment token and click DONE.

Note: I’m not downloading the registry file, as I think that it’s easier to deploy the enrollment token by using a PowerShell script.

Action 2: Enroll Google Chrome browsers on Windows devices

The second action is to enroll Google Chrome browsers on Windows devices by using the generated enrollment token. For that purpose I’ve created a small PowerShell script that will be deployed via Microsoft Intune. That means two steps. The first step is to create the PowerShell script and second step is distribute the PowerShell script via Microsoft Intune.

Let’s start with the first step. The following PowerShell script provides a simple example that will create the registry path and key if needed. Simply add the copied enrollment token as the value of the $KeyValue variable.

The second step is to distribute the PowerShell script by using Microsoft Intune. That will make sure that the enrollment token applied to the Windows devices, which will trigger the Google Chrome browser to enroll. The next seven steps walk through the deployment of the PowerShell script.

  1. Open Microsoft Endpoint Manager admin center portal and navigate to Devices > Windows > PowerShell scripts to open the Windows | PowerShell scripts blade
  2. On the Windows | PowerShell scripts blade, click Add to open the Add PowerShell script wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the PowerShell script
  • Description: (Optional) Provide a description for the PowerShell script
  1. On the Script settings page, provide the following configuration and click Next
  • Script location: Select the PowerShell script
  • Run the script using the logged on credentials: Select No to run the script in SYSTEM context
  • Enforce script signature check: Select No
  • Run script in 64-bit PowerShell Host: Select Yes
  1. On the Scope tags page, configure any additional scope tags for this PowerShell script and click Next
  2. On the Assignments page, configure the assignment of this PowerShell script and click Next
  3. On the Review + add page, review the settings and click Add

End-user experience

Let’s end this post by having a look at the end-user experience. Below I’ve provided a few examples of the experience for the end-user. Figure 5 provides an overview of the applied registry key and its value and Figure 6 provides an overview of the Google Chrome browser and the applied policies. The latter shows the managed state of the Google Chrome browser and the applied Chrome policies. With those Chrome policies it provides the source of the policy, which is Platform for the cloud management enrollment token configured via Microsoft Intune and Cloud for all policies configured via Chrome Browser Cloud Management, and the policy name and value. The shown Chrome policies – and their results – are the examples provided in the introduction.

Note: An administrator can also look at the enrolled browsers in the Google Admin console by navigating to Devices > Chrome management > Managed browsers.

More information

For more information about cloud-management of the Google Chrome browser, refer to the documentation about Cloud-managed Chrome Browser.

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:

Changing the primary user of Windows devices

This week is all about the primary user of a Windows device. More specifically about the recently introduced functionality to change or remove the primary user of a Windows device. The primary user is used within Microsoft Intune to map a licensed user to a device. Changing the primary user enables the administrator to switch the primary user of a device from one user to another user, or to switch a device without an assigned primary user (shared device) to a specific user. Besides that, removing the primary user enables the administrator to switch a device from a specific user to a shared device. In this post I’ll start with a short introduction about the primary user (and shared devices), followed by actually changing the primary user. The steps for changing the primary user manually and the places to look at in the Microsoft Graph API for automating the steps.

Introduction to the primary user

Before looking at the possibilities of changing or removing a primary user, it’s good to understand the usage and default configuration of the primary user of a Windows device. That’s why it’s good to start with a short introduction. The primary user is used within Microsoft Intune to map a licensed user to a device. That enables the user to see the device in the Company Portal app and the Company Portal website, and also enables the user to perform self-service actions on that device. Besides that, it helps the administrator when troubleshooting and supporting users.

When a device has no primary user assigned, the Company Portal app detects it as a shared device. Shared devices can be identified with a “shared” label appearing on the device tile in the Company Portal app. On a shared device, the Company Portal app can still be used to request and install available apps. However, self-service actions aren’t available. By removing the primary user of a device, the device is configured to operate in shared mode.

Microsoft Intune automatically adds the primary user to the Windows device during, or soon after, the enrollment of the device. The table below, based on the table in my post about Windows 10 enrollment methods, provides an overview of the user that is added as primary user to the device. When the user performs the enrollment, the primary user is added during enrollment, and when the device is automatically enrolled, the primary user is added during sign in.

Enrollment methodOwnershipPrimary user
Bring Your Own DevicePersonalUser that performs enrollment
Azure AD joinCorporateUser that performs enrollment
Windows AutopilotCorporateUser that performs enrollment
Device Enrollment ManagerCorporateNone
Provisioning packageCorporateNone
Co-managementCorporateFirst user that signs in
Group PolicyCorporateFirst user that signs in

Note: Keep in mind that Windows Autopilot contains multiple scenarios, including a scenario without user interaction. In that case no primary user is assigned.

Changing the primary user

Just before looking at the actual steps of changing the primary user of a Windows device, it’s good to go through a few notes about changing the primary user.

  1. Changing the primary user can take up to 10 minutes to be reflected.
  2. Changing the primary user is currently not possible on co-managed devices.
  3. Changing the primary user does not make any changes on the local device (the local group membership are not adjusted).
  4. Changing the primary user doesn’t change the “Enrolled by” user.
  5. Changing the primary user doesn’t affect the assigned user in Windows Autopilot.

Now let’s have a look at the steps for changing the primary user of a Windows device in the Microsoft Endpoint Manager admin center portal. After looking at the manual steps, I’ll also have a quick look at the Graph API for automating these steps. The steps for removing the primary user are similar and just one click away. When following the four steps below for changing the primary user of the Windows device, the steps for removing the primary user will also become clear (during step 2).

Note: To change the primary user of a Windows device, the administrators should be at least Intune Administrator, Help Desk Operator, School Administrator, or Endpoint Security Manager.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Windows devices > {DeviceName} > Properties to open the {DeviceName}|Properties blade
  2. On the {DeviceName}|Properties blade, select Change primary user to open the Select primary user blade
  1. On the Select primary user blade, select a user and click Select to return to the {DeviceName}|Properties blade
  2. On the {DeviceName}|Properties blade, click Save

For automation purposes, it might be better to know how to automate the primary user configuration. That can be achieved by using the managedDevices object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/managedDevices('{managedDeviceId}')/users/$ref

Below is an example of a JSON that should be used for adding a primary user. To create the relationship between the mangedDeviceId and the userId, the JSON contains OData data.

@odata.id: "https://graph.microsoft.com/beta/users/{userId}"

Keep in mind that at the moment of writing this article the required properties are only available in the BETA version of the API and production use is not supported.

More information

For more information about primary users of Windows devices, refer to the following articles:

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.

Block Android device enrollment for specific device manufacturer

This week is all about restricting the enrollment of Android devices. More specifically, about a very recently introduced feature which is the ability to block Android device enrollment based on the manufacturer of the device. That enables the organization to prevent Android devices of specific manufacturers from enrolling in Microsoft Intune. That can be useful when the organization has a specific policy for allowed device manufacturers. In this post I’ll walk through the configuration steps, followed with the end-user experience.

Starting with this post, I’ll provide both the configuration steps via the Microsoft Endpoint Manager admin center portal and the configuration location in the Graph API (including the related JSON-snippet) as part of the configuration steps.

Configuration steps

Now let’s start by having a look at the configuration steps. These configurations can be achieved by either creating custom device type restrictions or by editting the existing default device type restriction. In the following example I’ll walk through these steps by adjusting the default device type restrictions. The following steps show how to add a device manufacturer to a list of blocked manufacturers.

  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, provide the manufacturers to block in the Device manufacturer field (see example below) and click Review + save to continue to the Review + save page

Note: Use a comma-separated list when adding multiple manufacturers.

  1. On the Review + save page, click Save

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

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

However, keep in mind that the required properties are currently only available in the BETA version of the API. Below is an example snippet of a JSON that contains the Android Enterprise configuration with the blocked manufactures configuration, similar to the configuration via the UI.

"androidForWorkRestriction": {
    "platformBlocked": false,
    "personalDeviceEnrollmentBlocked": false,
    "osMinimumVersion": null,
    "osMaximumVersion": null,
    "blockedManufacturers": [
        "Samsung"
    ]
}

End-user experience

Now let’s end this post by having a look at the end-user experience. I’ll do that by showing the behavior on a personally-owned Android device that should enroll by using Android Enterprise work profiles to manage corporate data and apps. By default, enrollment of this type of personally-owned devices is enabled. That can be limited by using the enrollment restrictions, as shown in this post, or by simply blocking personally-owned devices.

In this scenario, I’m allowing the enrollment of personally-owned and company-owned Android devices, but I’m blocking any enrollment of Android devices from a specific device manufacturer.

When the end-user downloaded and installed the Company Portal app and started the enrollment process, at some point during the enrollment process the end-user will be blocked. While being blocked, the end-user will receive the message “Couldn’t add your device“. That message, of which an example is shown on the right, includes a clear explanation of why the device couldn’t be added. In my example the end-user is being told that the company needs the end-user to use an Android device manufacturer other then samsung.

Note: Keep in mind that the only reason that I’m using Samsung as an example in this post, is that I’ve got test Android devices of that device manufacturer. I don’t have any reasons that would actually require me to block the enrollment of Android devices from that device manufacturer.

More information

For more information about blocking Android device enrollment for specific device manufacturers, refer to the following docs: