Windows 10 MDM Bridge WMI Provider: Settings template

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

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

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

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

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

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

More information

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

Quick tip: Easy method for constructing settings of ingested ADMX-files

This week a quick extra blog post, just before the start of my vacation, about an easy method for construction settings of ingested ADMX-files. A few years ago I did a post about a deep dive for ingesting third-party ADMX-files and until today I still receive questions on that post that are related to constructing settings of ingested ADMX-files. Even though the described method is still available, there is an easier method for constructing the settings of ingested ADMX-files. A method that is less sensitive to errors. The following four steps walk through that easy method by again using chrome.admx as an example.

  1. The first step is ingesting the ADMX-file. That can be achieved by following the same steps as provided in my earlier post. After creating the required configuration that contains the content of the ADMX-file, assign the profile to a group with a test device and let Microsoft Intune do its magic.
  1. While Microsoft Intune is performing its magic on the test device, it’s time to start with the second step. The second step is looking up the setting and the available values in the ADMX-file. Just like my earlier post – to keep it simple – I’m looking at the SitePerProcess setting (see Figure 1). Now instead of going through the ADMX-file to construct a difficult OMA-URI, it’s time to have a look at the test device once Microsoft Intune performed its magic.
  1. After Microsoft Intune performed its magic, it’s time to start with the third step. The third step is looking up the setting of the ingested ADMX-file in the registry of the test device. Simply navigate to HKLM\SOFTWARE\Microsoft\PolicyManager\ADMXDefault and locate the just ingested ADMX-file. To make life a little bit easier, knowing to parent category can help. Otherwise, just find and locate the SitePerProcess setting. Once the setting is located, the required part of the OMA-URI is available without doing any really difficult steps (see Figure 2).
  1. The fourth and last step is putting the information together. The OMA-URI of a device-based ingested ADMX-file always starts with ./Device/Vendor/MSFT/Policy/Config. That combined with the information found in the registry of the test device makes ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/SitePerProcess.

I know I should have posted these steps earlier, but I still hope that it will still help administrators around the globe with constructing their OMA-URIs for settings of ingested ADMX-files. For as long as it’s still required.

Configuring the usage of Bluetooth encryption via Windows 10 MDM

This week a short blog post about configuring Bluetooth on Windows 10 devices that are managed via Microsoft Intune. More specifically, about configuring the Bluetooth encryption strength that is required for pairing Bluetooth devices. Last year there was a vulnerability regarding the Bluetooth encryption key negotiation that was addressed with an update to Windows and a specific configuration that should be performed to required a specific encryption strength. By default Windows allows all Bluetooth traffic, but with this vulnerability in mind some organizations might want to enforce a minimal encryption key size to be required for Bluetooth traffic. Even if that means that some Bluetooth devices won’t work, or stop working. In this post I’ll start with showing how to configure the Bluetooth encryption key size and I’ll end by showing the applied configuration.

Overview of the Bluetooth configuration options

Let’s start with an overview of the Bluetooth configuration options. Windows 10 already provides multiple configurations options regarding Bluetooth, via the Bluetooth policies in the Policy CSP. Most of these policies are already available via a Device restriction policy in the Cellular and connectivity section. That section contains nearly all available policies, with the exception of the latest policy, the ability to configure the encryption key size. That policy is recently introduced with Windows 10, version 2004, and will probably eventually also end-up in the UI.

That doesn’t mean that we can’t configure the Bluetooth encryption key size at this moment. Like with any available setting within the Policy CSP, it’s always possible to configure it by using a custom configuration profile. The only required information is the policy node and the available configuration values. Below is an overview of the required policy node within the Bluetooth section of the Policy CSP and the available configuration values.

PolicyDescription
SetMinimumEncryptionKeySizeThis policy setting helps with preventing weaker devices cryptographically being used in high security environments, as there are multiple levels of encryption strength when pairing Bluetooth devices. The default configuration is 0 and allows all Bluetooth traffic. Number 1 can be used to always enforce Bluetooth encryption and ignoring the precise encryption key size. Any number from 2 through 16 can be used to always enforce Bluetooth encryption and in that case that number also represents the bytes used in the encryption process.

Configuration of the Bluetooth encryption key size

After being familiar with the available policy settings and the possible values, it’s time to take a look at the steps for configuring the Bluetooth encryption key size policy setting. The nine steps below walk through the configuration of a new custom device configuration profile that includes the required OMA-URI and its value. The wizard style of configuring makes sure that the device configuration profile will be assigned to the selected users and/or devices.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Windows > Configuration profiles to open the Windows | Configuration profiles blade
  2. On the Windows | Configuration profiles blade, click Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create to open the Custom wizard
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the custom device configuration profile
  • Description: (Optional) Provide a valid description for the custom device configuration profile
  1. On the Configuration settings page, click Add to open the Add Row page. On the Add Row page, provide the following information and click Add (and click Next back on the Configuration settings page)
  • Name: Provide a valid name for the OMA-URI setting
  • Description: (Optional) Provide a valid description for the OMA-URI setting
  • OMA-URI: ./Vendor/MSFT/Policy/Config/Bluetooth/SetMinimumEncryptionKeySize
  • Data type: Select Integer
  • Value: 7
  1. On the Scope tags page, configure the applicable scopes and click Next
  2. On the Assignments page, configure the assignment and click Next
  3. On the Applicability rules page, configure the applicability rules (think about the existence of this setting for only the BusinessEnterprise and Education edition and the existence of this setting for only the 2004 version and later) and click Next
  4. On the Review + create page, verify the configuration and click Create

Result of the Bluetooth encryption configuration

Let’s end this post by showing the result of the Bluetooth encryption configuration. This time I’ll do that by simply looking at the Event Viewer and the MDM Diagnostic Report and relating the information seen at both locations. In both overviews the following corresponding information is seen of the successfully applied configuration.

  1. Policy setting: SetMinimumEncryptionKeySize
  2. Policy area: Bluetooth
  3. Policy value: 7
  4. Policy scope: Device
  5. Policy ID: 5C71E17A-2715-47C6-B338-4EE-07C445339

More information

For more information about the different configuration options for Bluetooth, refer to the Bluetooth policies in the Policy CSP documentation.

Prevent non-administrator users from installing Windows app packages via Windows 10 MDM

This week a short new blog post about a new introduced Windows 10 MDM policy setting, in Windows 10, version 2004, to address new default behavior. That policy setting is related to the installation of Windows app packages. More specifically, that policy setting can be used to prevent non-administrator users from initiating the installation of (signed) Windows app packages. Starting with Windows 10, version 2004, every user – administrator and non-administrator – can initiate the installation of (signed) Windows app packages. On previous versions of Windows 10 that would require the administrator to at least enable the ability to sideload apps (part of the developer settings), for users to be able to initiate the installation of (signed) Windows app packages. This policy setting can be used to return to a situation similar to before, as it enables the administrator to prevent users from initiating the installation of (signed) Windows app packages. That can be the preferred situation for specific groups of users. In this post I’ll quickly go through the setting and requirements, followed by the configuration steps. I’ll end this post by having a look at the end-user experience.

Overview

Let’s start with a quick overview of this specific policy setting. This is an ADMX-backed setting that is available via the AppxPackageManager.admx and this policy setting is used to manage the ability of users to initiate the installation of (signed) Windows app packages. The friendly name of this policy setting is Prevent non-admin users from installing packaged Windows apps and this policy setting is only available in the Windows 10 Business, Enterprise and Education editions.

The policy setting is available in the ApplicationManagement area in the Policy CSP. That’s not a new area, but starting with Windows 10, version 2004, it contains this specific new policy setting. In the table below is an overview of the policy setting and keep in mind that the complete node of this policy setting starts with ./Vendor/MSFT/Policy/Config/ApplicationManagement/.

PolicyDescription
BlockNonAdminUserInstallThis policy setting manages the ability of non-administrator users to install (signed) Windows app packages. When enabled (value: 1), non-administrator users will be unable to initiate the installation of (signed) Windows app packages. Administrator users will still be able to initiate the installation of (signed) Windows app packages in Administrator-context. When disabled (value: 0), or not configured, all users will be able to initiate the installation of (signed) Windows app packages.

Note: This policy does not configure the ability of users to install Windows app packages via the Microsoft Store.

Configuration

When knowing the available policy setting and the possible values, it’s time to take a look at the steps for configuring that specific policy. The nine steps below walk through the configuration of a new custom configuration profile that includes the required OMA-URI and its value. The wizard style of configuring makes sure that the configuration profile will be assigned to the selected users and/or devices.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Windows > Configuration profiles to open the Windows | Configuration profiles blade
  2. On the Windows | Configuration profiles blade, click Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create to open the Custom wizard
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Basics page, provide the following information (the Platform and Profile type are greyed out and configured based on the provided information on the previous page) and click Next
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Configuration settings page, click Add to open the Add Row page. On the Add Row page, provide the following information and click Add (and click Next back on the Configuration settings page)
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Vendor/MSFT/Policy/Config/ApplicationManagement/BlockNonAdminUserInstall
  • Data type: Select Integer
  • Value: 1
  1. On the Scope tags page, configure the applicable scopes and click Next
  2. On the Assignments page, configure the assignment and click Next
  3. On the Applicability rules page, configure the applicability rules (think about the existence of this setting for only the Business, Enterprise and Education edition and the existence of this setting for only the 2004 version and later) and click Next
  4. On the Review + create page, verify the configuration and click Create

Note: At some point in time this configuration will probably become available in the Microsoft Endpoint Manager admin center portal without the requirement of creating a custom device configuration profile with a custom OMA-URI.

End-user experience

Let’s end this post by having a look at the end-user experience. The basic end-user experience when using this policy setting, is the same for every user. When initiating the installation of a (signed) Windows app package by simply double-clicking the file, every user – non-administrator and administrator – will receive the same experience. For an administrator to still be able to install a (signed) Windows app package, the installation should be initiated in an administrator-context (for example: using PowerShell that was started by using Run as Administrator).

To show the end-user experience, I’ve used two different Windows app packages. Below on the left is an example of a trusted app in MSIX-format and below on the right is an example of an offline trusted Microsoft Store app in APPX-format. Both examples simply used to show the behavior of the policy setting. MSIX Hero is actually a really nice and simple tool for managing and troubleshooting MSIX packages and Word Mobile is just a simple APPX package.

Reminder: This policy does not configure the ability of users to install Windows app packages via the Microsoft Store.

More information

For more information about the policy setting to prevent non-administrator from initiating the installation of Windows app packages, refer to the ApplicationManagement policies in the Policy CSP documentation.

Managing local administrators via Windows 10 MDM

This week is all about managing local administrators via Windows 10 MDM by using restricted groups. There has been many requests for a post like this after I wrote this post about creating local user accounts. And I have to admit that this post has been on my backlog for a long time. Better late than never, I think. Also, I’m definitely not the first to write about this subject, but I do think that I have some new insights that can be really helpfull. In this post I’ll start with an overview of the options for configuring local administrators on Azure AD joined (and Microsoft Inune managed) devices and reasons for using restricted groups, followed by the steps for configuring restricted groups. I’ll end this post by looking at the end-user experience.

Overview

When discussing the local administrators on Azure AD joined devices, it’s often about the Global administrator role and the Device administrator role. These roles are by default local administrator on Azure AD joined devices. Users can be added to the Global administrator role like any other administrator role. Adding users to the Device administrator role, however, is a different configuration. Users can be added by configuring additional local administrators on Azure AD joined devices. These two roles have one thing in common and that is that those roles apply to all Azure AD joined devices. No exceptions. However, there might be scenarios in which it’s required to limit the local administrators on a device, or scenarios in which it’s required to differentiate the additional local administrators for different groups of devices.

Another option to manage local administrator on Microsoft Intune managed devices – which are often also Azure AD joined – is by using restricted groups. For this it’s possible to use the RestrictedGroups section in the Policy CSP. That contains a single node that can be used for adding local administrators (or for adjusting any other existing local group). When specifically looking at managing local administrators, make sure to keep the following in mind:

  • By using restricted groups, the provided local administrators will replace the existing local administrators.
  • By using restricted groups, which is a configuration node of the Policy CSP, the provided local administrators will be reapplied, within 8 hours, when changed by the user (behavior starting with Windows 10, version 1903).
  • The default local Administrator account must be part of the custom configuration, as it’s required for applying a custom configuration.
  • Every Azure AD joined device contains two SIDs (one representing the Global administrator role and one representing the Device administrator role) that are by default part of the local administrators.

Note: By default, on Azure AD joined devices, the user joining the device to Azure AD is also local administrator on the device.

Configuration

By knowing the available configuration options and the different configurations it’s time to look at the configuration steps. The five steps below walk through the configuration. Throughout those configuration steps, I’ll provide the required information regarding the OMA-URI and the XML-value that should be configured.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices > Windows > Configuration profiles to open the Windows | Configuration profiles blade
  2. On the Windows | Configuration profiles blade, click Create profile to open the Create a profile blade
  3. On the Create a profile blade, provide the following information and click Create to open the Create profile blade
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Create profile blade, select Settings to open the Custom OMA-URI Settings blade
  2. On the Custom OMA-URI Settings blade, click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade)
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership
  • Data type: Select String
  • Value: The value should be an XML. That XML should contain a groupmembership-element and that groupmembership-element should contain an accessgroup-element. That accessgroup-element contains the local group that should be adjusted and that accessgroup-element contains member-elements that contain the users that should be added to the local group. For an example see the XML below.

Note: The RestricedGroups section can be used to add members to any local group on a device.

<groupmembership>
	<accessgroup desc = "Administrators">
		<member name = "Administrator" />
		<member name = "AzureAD\pvanderwoude@petervanderwoude.nl" />
		<member name = "AzureAD\tvanderwoude@petervanderwoude.nl" />
		<member name = "S-1-12-1-2091167666-1329275207-1706997396-915002206" />
		<member name = "S-1-12-1-2447031348-1225114094-1633491097-1064162478" />
	</accessgroup>
</groupmembership>

End-user experience

Now let’s end by having a look at the end-user experience. The best place to look is in the Properties of the Administrators group. That group should reflect the provided configuration, as shown in Figure 4.

This configuration is the most common to be used when the primary user of the device is not a local administrator. A method to provide additional support to the end-user, without the requirement of adding that specific account as a local administrator on all devices.

It’s also good to keep in mind that starting with Windows 10, version 1903, the settings of the Policy CSP actually refresh. When, for whatever reason, the configuration of the local administrators was adjusted, the configuration will refresh within 8 hours. The next device check-in will take care of that.

Another place for verifying the configuration, would be to look at MDM Diagnostic Report. That report will show an overview of the RestrictedGroups setting configuration.

More information

For more information about managing local administrators, refer to the following articles:

.

Windows 10 MDM (PowerShell) scripting

A long, long time ago, I wrote about the MDM WMI Bridge provider. Nowadays I notice that the MDM WMI Bridge provider is still an unknown configuration layer for many IT admins. That’s why I’ve decided to do another post about the MDM WMI Bridge provider. A quick reminder: the MDM WMI Bridge provider is used to map the CSPs to WMI. This time my post is more focused on providing some examples and guidance. Besides that it’s also a nice addition on my latest posts about Windows 10 MDM configurations, policy refresh and troubleshooting. I’ll start this post by showing how to configure device settings and I’ll end this post by showing how to trigger device actions.

Keep in mind that this post is about configuring device settings. That means that every action requires to run in SYSTEM context. I advise to use PsExec for executing the scripts and tools mentioned in this post

Configuring device settings

The easiest starting point for everything related to WMI is Windows Management Instrumentation Tester (in short wbemtest). As an example I’ll take last weeks post to another level by also looking at the Reboot CSP for this post. The starting point for that is the MDM_Reboot_Schedule01 class.

Let’s start at the beginning. The root\cimv2\mdm\dmmap namespace, is the namespace that contains all the information regarding MDM in WMI. This is the MDM WMI Bridge provider. This namespace contains the WMI classes that map to CSP nodes. There are 3 methods available to get the available WMI classes:

  1. The docs about the MDM Bridge WMI provider
  2. Use wbemtest to connect to the namespace and click Enum Classes
  3. User PowerShell (Get-CIMClass) to enumerate the available classes

For this example I’ll use wbemtest to connect to the root\cimv2\mdm\dmmap namespace and to enumerate the available classes. This tool is an easy method for showing information via a UI. When knowing the exact class, it’s also possible to directly connect to that class by using Open Class instead of Enum Classes.

In this example, I know the class, which enables me to open the specific MDM_Reboot_Schedule01 class. Connecting to that class, provides me with the available properties (DailyRecurrent, InstanceID, ParentID, Single). These properties are well documented in the earlier mentioned article. In some scenarios, the classes and/or properties are not yet documented. In those scenarios wbemtest can be a very good starting point for getting the required information.

Now the available classes and properties are known, it’s time to have a look at the available options. As it’s basically standard WMI, at this point, there are also the standard WMI PowerShell scripting options available (Get, New, Remove and Modify). Below are some basic examples of using the CimCmdlets for WMI. Having mentioned that, I also deliberately left out some real New-CimInstance and Remove-CimInstance examples, as the example that I use for this post doesn’t support those actions. The MDM_Reboot_Schedule01 class already contains an instance and can’t contain multiple instances. Below are some generic example of using those cmdlets.

#Enumerate available instances
Get-CimInstance -Namespace $namespaceName -ClassName $className
#Create a new instance
New-CimInstance -Namespace $namespaceName -ClassName $className -Property @{}
#Get a specific instance 
$instanceObject = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID='$parentID' and InstanceID='$instanceID'"

#Remove a specific instance
Remove-CimInstance -CimInstance $instanceObject

That basically means that it’s only possible to modify the available instance in the MDM_Reboot_Schedule01 class. That instance is Schedule. The Schedule instance can be adjusted by adding a value to the Single property and/ or the DailyRecurrent property. Those properties are used to actually create the specified schedule. Just like in the CSP configuration, the date and time value is ISO8601 and in UTC. The example below will get the Schedule instance in the root\cimv2\mdm\dmmap namespace, and will modify the Single property to configure a new single scheduled reboot.

#Declare variables
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_Reboot_Schedule01"
$parentID = "./Vendor/MSFT/Reboot"
$instanceID = "Schedule"
$singleSchedule = "2019-10-01T22:00:00Z"

#Get a specific instance
$instanceObject = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID='$parentID' and InstanceID='$instanceID'"

#Adjust a specific property
$instanceObject.Single = $singleSchedule

#Modify an existing instance
Set-CimInstance -CimInstance $instanceObject

Triggering device actions

Besides configuring settings via the MDM WMI Bridge provider, it’s also possible to trigger actions via the provider. When still looking at the Reboot CSP, that CSP also contains a node to execute RebootNow. RebootNow will trigger a reboot within 5 minutes. That action is available within the Intune console as a Restart action for a device. The nice thing is that this action can also be triggered via the MDM WMI Bridge provider.

Let’s skip the beginning about connecting to the WMI namespace and directly navigate to the required WMI class. The MDM_Reboot class. When connecting to the MDM_Reboot class, by using wbemtest, it’s immediately clear why wbemtest is such a nice and easy tool. After connecting to the class, wbemtest immediately provides an overview of the available methods. In this case the RebootNowMethod method.

Triggering the RebootNowMethod method, via PowerShell, will provide an alternative (and very creative) method for rebooting a device. This method is well documented in the earlier mentioned documentation. In some scenarios, the methods are not yet documented. In those scenarios wbemtest can be a very good starting point for getting the required information.

The RebootNowMethod method can be triggered by getting the available instance of the MDM_Reboot class. That instance is Reboot. That instance can be used to trigger the RebootNowMethod method. The example below will get the Reboot instance in the root\cimv2\mdm\dmmap namespace, and will trigger the RebootNowMethod method to trigger a reboot within five minutes.

#Declare variables
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_Reboot"
$parentID = "./Vendor/MSFT/Reboot"
$instanceID = "Reboot"
$methodName = "RebootNowMethod"

#Get a specific instance
$instanceObject = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID='$parentID' and InstanceID='$instanceID'"

#Trigger specific method
Invoke-CimMethod -InputObject $instanceObject -MethodName $methodName

Now let’s end this post by having a look at the effect of triggering the RebootNowMethod method. Below is an example of a simplified version (read: a one-liner) of the previous script. Just for demo purposes. After triggering that the RebootNowMethod method, the device will immediately provide a popup with a reboot notification.

More information

For more information about PowerShell and the MDM WMI Bridge provider, have a look at this article about Using PowerShell scripting with the WMI Bridge Provider.

Scheduling a reboot via Windows 10 MDM

This week is also about configuring Windows 10 devices. This week is all about scheduling a reboot on a Windows 10 device by using Microsoft Intune and Windows 10 MDM. That can be useful for scheduling reboots on for example shared devices. Simply making sure that even those type of devices get a reboot every now and then, or making sure that specific configurations or installations are getting fully applied. This can be achieved by using the Reboot CSP. In this post I’ll have a look at the available policy settings and the configuration of those policy settings. I’ll end this post by having a look at the results of the configuration.

Available policy settings

The Reboot CSP can be used to configure reboot settings. That CSP contains only a few policy settings and methods (nodes). The required policy setting for this post is available as a policy setting (node) in this CSP. The root node of the Reboot CSP is ./Vendor/MSFT/Reboot and the table below describes the nodes below.

PolicyDescription
RebootNowThis node can be used to execute a reboot of the device. It will trigger a reboot within 5 minutes to allow the user to wrap up any active work. This method is used when triggering a Restart via the Intune console.
Schedule/SingleThis node can be used to execute a reboot of the device at a scheduled date and time. Setting a null (empty) date will delete an existing schedule. The date and time value is ISO8601, and both, the date and time, are required.
Example: 2019-10-01T22:00:00Z
Schedule/DailyRecurrentThis node can be used to execute a reboot of the device, each day, at a scheduled time starting at the configured time and date. Setting a null (empty) date will delete an existing schedule. The date and time value is ISO8601, and both, the date and time, are required.
Example: 2019-10-02T21:00:00Z

Configuring the policy settings

Now let’s continue by looking at the actual configuration of the different configurable policy settings of the Reboot CSP. That means configuring a single reboot schedule and a daily recurrent reboot schedule. This can be achieved by using a custom device configuration profile. The following four steps walk through the configuration of the single reboot schedule, by using the information of above (including the example values).

The daily recurrent reboot schedule can be achieved by following the same steps and simply adjusting the OMA-URI and the Value. The screenshots below show both configurations. Also, by using two different Data type configurations. After creating the profile, it can be assigned like any other device configuration profile.

  1. Open the Azure portal and navigate to Microsoft Intune Device configuration Profiles to open the Devices configuration – Profiles blade
  2. On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade
  3. On the Create profile blade, provide the following information and click Create
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Windows 10 and later
  • Profile type: Custom
  • Settings: See step 4
  1. On the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade)
  • Name: Single reboot schedule
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Vendor/MSFT/Reboot/Schedule/Single
  • Data type: Select String
  • Value: 2019-10-01T22:00:00Z

Note: The same configuration can be achieved by using the Date and time data type and selecting the date and time in the UI (as shown below). Keep in mind that it will translate the selected date and time to the UTC time, which in my case is currently a 2 hour difference. To remove the schedule, use 0000-00-00T00:00:00Z as a value.

Result on the device

After assigning the created device configuration profile(s), it’s time to have a look at the results on a device. The Reboot CSP will create a scheduled task for the configured reboot schedules (as shown below). Those scheduled tasks are available at Microsoft > Windows > EnteriseMgmt > {EnrollmentID} > Reboot.

As I’ve configured a single reboot schedule and a daily recurrent reboot schedule, the screenshot below shows a task RebootCSP daily recurrent reboot and a task RebootCSP scheduled reboot. Those tasks are used for performing the actual reboots by using deviceenroller.exe -ForcedReboot.

After successfully rebooting multiple devices, I’ve noticed the following to keep in mind:

  • The Last Run Time of the scheduled tasks never updates after a reboot, as if the scheduled task is recreated with a new Next Run Time.
  • The result of the custom device configuration profile in Microsoft Intune still shows a Remediation failed error message, while the configuration is successful.

More information

For more information about the Reboot CSP, have a look at the documentation about the Reboot CSP.

Windows 10 MDM troubleshooting

This week another new blog post related to Windows 10 MDM. In the recent weeks I’ve discussed policy refresh, some configurations and now some troubleshooting. This post is also triggered by my previous as I used the MDM Diagnostics Tool (MdmDiagnosticsTool.exe) as an example. Based on that example I’ve received some requests for more information. There are more useful tools like dsregcmd, but this post will focus on the MDM Diagnostics Tool, as there’s not that much information available. In this post I’ll provide information about the usage and results of the MDM Diagnostics Tool as having the right information is really useful for troubleshooting Windows 10 MDM managed devices.

Introduction of the MDM Diagnostics Tool

The MDM Diagnostics Tool is a command line tool that can be used to gather information. Information related to specific MDM areas. Depending on the chosen MDM area, the MDM Diagnostics Tool will gather the related events, registry, logs and more, all consolidated into a single folder or single file. The MDM Diagnostics Tool is one of the best starting points for the IT admin, for a consolidated source for troubleshooting.

Usage of the MDM Diagnostics Tool

The MDM Diagnostics Tool can has four different usage options. The first usage option is the generic option to output MDM diagnostics info only, to a given folder.

MdmDiagnosticsTool.exe -out <output folder path>

The second usage option is to collect predefined area logs and to create a cab file with the results. The possible areas are available in the registry under: HKLM\SOFTWARE\Microsoft\MdmDiagnostics\Area. At this moment those areas are Autopilot, DeviceEnrollment, DeviceProvisioning and TPM (as shown below).

MdmDiagnosticsTool.exe -area <area name(s)> -cab <output cab file path>

The third usage option is to collect predefined area logs and to create a zip file with the results. The possible areas are the same as for the second usage option. Only the file type of the result is different.

MdmDiagnosticsTool.exe -area <area name(s)> -zip <output zip file path>

The fourth usage option is to collect information specified in a XML-file and to create a zip file with the results. I haven’t found out (and not really looked at) how to construct a working XML-file for that option. To use the MDM Diagnostics Tool in combination with Microsoft Intune, have a look at my previous post.

MdmDiagnosticsTool.exe -xml <xml file of information to gather> -zip <output zip file path> -server <MDM Server to alert>

Output of the MDM Diagnostics Tool

The output of the different usage options of the MDM Diagnostics Tool is also different. As usage option 2 and 3 contain the same information and I can’t really use option 4, let’s have a look at the output of option 1 and 2. Below is a quick overview of the output, followed by an explanation of the diagnostic data that is available in the output.

Output of usage option 1

The first usage option provides the generic MDM diagnostics that contains the following information:

  • DeviceManagement-Enterprise-Diagnostics-Provider.evtx – This event log contains the information (and errors) regarding the MDM sessions of the device. It also shows the MDM PolicyManager errors.
  • MDMDiagReport.html (and related xml) – This is the same report that can be generated by using the Settings panel and generating the Advanced Diagnostics Report. That report shows the applied configuration states of the devices, including Policy CSP settings, certificates, configuration sources, and resource information.
  • Microsoft-Windows-AAD.evtx – This event log contains information (and errors) related to Azure AD communications. From device registration until token requests.
  • Microsoft-Windows-Shell-Core.evtx – This event log contains a lot of information mainly related to logon tasks and runonce actions on the device.

Output of usage option 2 (Autopilot)

The second usage option, with the Autopilot area specified, provides generic MDM diagnostics and specific Autopilot related diagnostics that contains the following information:

  • AgentExecutor.log – This log file contains information about the PowerShell scripts that are executed by the Intune Management Extention.
  • AutopilotConciergeFile.json – This json file contains the language and keyboard configuration information during a self deployment.
  • AutopilotDDSZTDFile.json – This json file contains the configuration information during a regular deployment.
  • ClientHealth.log – This log file contains the health information of the Intune Management Extention.
  • DeviceHash_DESKTOP-U1JNF0E.csv – This csv file contains the device hash information of the device.
  • DiagnosticLogCSP_Collector_Autopilot.etl – This event trace log file contains trace information of the Autopilot process of the device.
  • DiagnosticLogCSP_Collector_DeviceEnrollment.etl – This event trace log file contains trace information of the device enrollment process of the device.
  • DiagnosticLogCSP_Collector_DeviceProvisioning.etl – This event trace log file contains trace information of the device provisioning process of the device.
  • IntuneManagementExtension.log – This log file contains information about the Win32 app deployments that are performed by the Intune Management Extension.
  • LicensingDiag.cab (and related LicensingDiag_Output.txt) – These files contain licensing and diagnostic information.
  • MDMDiagReport.html (and related xml) – This is the same report that can be generated by using the Settings panel and generating the Advanced Diagnostics Report. That report shows the applied configuration states of the devices, including Policy CSP settings, certificates, configuration sources, and resource information.
  • MdmDiagReport_RegistryDump.reg – This registry file contains exported registry information related to Autopilot, but also related to the provisioning of the device and the policy manager. Basically everything related to MDM management.
  • microsoft-windows-aad-operational.evtx – This event log contains operational information (and errors) related to Azure AD communications. From device registration until token requests.
  • microsoft-windows-appxdeploymentserver-operational.evtx – This event log contains operational information (and errors) related to packaging, deploying, or querying app packages.
  • microsoft-windows-assignedaccess-admin.evtx – This event log contains admin information (and errors) related to assigned access (kiosk mode).
  • microsoft-windows-assignedaccessbroker-admin.evtx – This event log contains admin information (and errors) related to the broker of assigned access (kiosk mode).
  • microsoft-windows-assignedaccessbroker-operational.evtx – This event log contains operational information (and errors) related to the broker of assigned access (kiosk mode).
  • microsoft-windows-assignedaccess-operational.evtx – This event log contains operational information (and errors) related to assigned access (kiosk mode).
  • microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx – This event log contains admin information (and errors) regarding the MDM sessions of the device.
  • microsoft-windows-devicemanagement-enterprise-diagnostics-provider-debug.evtx – This event log contains debug information (and errors) regarding the MDM sessions of the device.
  • microsoft-windows-devicemanagement-enterprise-diagnostics-provider-operational.evtx – This event log contains operational information (and errors) regarding the MDM sessions of the device.
  • microsoft-windows-moderndeployment-diagnostics-provider-autopilot.evtx – This event log contains the operational information (and errors) regarding the Autopilot profile settings and OOBE flow of the device.
  • microsoft-windows-moderndeployment-diagnostics-provider-managementservice.evtx – This event log contains the operational information (and errors) regarding the management service of the device.
  • microsoft-windows-provisioning-diagnostics-provider-admin.evtx – This event log contains the admin information (and errors) regarding adding packages to the device.
  • microsoft-windows-shell-core-operational.evtx – This event log contains a lot of information mainly related to logon tasks and runonce actions on the device.
  • microsoft-windows-user device registration-admin.evtx – This event log contains admin information (and errors) regarding the device registration (status).
  • setupact.log – This log file contains information about the errors that occur during the Windows installation process of the device.
  • TpmHliInfo_Output.txt – This file contains information about the support of TPM 2.0 for the TPM of the device.

Output of usage option 2 (DeviceEnrollment)

The second usage option, with the DeviceEnrollment area specified, provides generic MDM diagnostics and specific device enrollment related diagnostics that contains the following information:

  • DiagnosticLogCSP_Collector_DeviceEnrollment.etl – This event trace log file contains trace information of the device enrollment process of the device.
  • MDMDiagHtmlReport.html (and related xml) – This is the same report that can be generated by using the Settings panel and generating the Advanced Diagnostics Report. That report shows the applied configuration states of the devices, including Policy CSP settings, certificates, configuration sources, and resource information.
  • MdmDiagReport_RegistryDump.reg – This registry file contains exported registry information related to Autopilot, but also related to the provisioning of the device and the policy manager. Basically everything related to MDM management.
  • microsoft-windows-aad-operational.evtx – This event log contains operational information (and errors) related to Azure AD communications. From device registration until token requests.
  • microsoft-windows-appxdeploymentserver-operational.evtx – This event log contains operational information (and errors) related to packaging, deploying, or querying app packages.
  • microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx – This event log contains admin information (and errors) regarding the MDM sessions of the device.
  • microsoft-windows-devicemanagement-enterprise-diagnostics-provider-debug.evtx – This event log contains debug information (and errors) regarding the MDM sessions of the device.
  • microsoft-windows-devicemanagement-enterprise-diagnostics-provider-operational.evtx – This event log contains operational information (and errors) regarding the MDM sessions of the device.
  • microsoft-windows-moderndeployment-diagnostics-provider-managementservice.evtx – This event log contains the operational information (and errors) regarding the management service of the device.
  • microsoft-windows-provisioning-diagnostics-provider-admin.evtx – This event log contains the admin information (and errors) regarding adding packages to the device.

Output of usage option 2 (DeviceProvisioning)

The second usage option, with the DeviceProvisiong area specified, provides generic MDM diagnostics and specific device provisioning related diagnostics that contains the following information:

  • DiagnosticLogCSP_Collector_DeviceProvisioning.etl – This event trace log file contains trace information of the device provisioning process of the device.
  • MDMDiagHtmlReport.html (and related xml) – This is the same report that can be generated by using the Settings panel and generating the Advanced Diagnostics Report. That report shows the applied configuration states of the devices, including Policy CSP settings, certificates, configuration sources, and resource information.
  • MdmDiagReport_RegistryDump.reg – This registry file contains exported registry information related to Autopilot, but also related to the provisioning of the device and the policy manager. Basically everything related to MDM management.
  • microsoft-windows-aad-operational.evtx – This event log contains operational information (and errors) related to Azure AD communications. From device registration until token requests.
  • microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx – This event log contains admin information (and errors) regarding the MDM sessions of the device.
  • microsoft-windows-provisioning-diagnostics-provider-admin.evtx – This event log contains the admin information (and errors) regarding adding packages to the device.
  • microsoft-windows-shell-core-operational.evtx – This event log contains a lot of information mainly related to logon tasks and runonce actions on the device.

Output of usage option 2 (TPM)

The second usage option, with the TPM area specified, provides generic MDM diagnostics specific certificate and TPM related diagnostics that contains the following information:

  • CertReq_enrollaik_Output.txt – This file contains information about an attempt to enroll an AIK key for the device.
  • CertUtil_tpminfo_Output.txt – This file contains information about the TPM of the device.
  • MDMDiagHtmlReport.html (and related xml) – This is the same report that can be generated by using the Settings panel and generating the Advanced Diagnostics Report. That report shows the applied configuration states of the devices, including Policy CSP settings, certificates, configuration sources, and resource information.
  • MdmDiagReport_RegistryDump.reg – This registry file contains exported registry information related to Autopilot, but also related to the provisioning of the device and the policy manager. Basically everything related to MDM management.

More information

For more information related to troubleshooting Windows 10 MDM related issues, please refer to the following documentation:

Triggering devices to upload (diagnostic) files to cloud storage

This week is all about triggering Windows 10 devices to upload (diagnostic) files to cloud storage. That can be very useful for gathering information and diagnosing potential issues. Starting with Windows 10, version 1903, Microsoft added additional functionality to the DiagnosticLog CSP. The DiagnosticLog CSP is used for generating and collecting diagnostic information from the device and the additional functionality enables triggering devices to upload existing event logs, log files, and registry values to cloud storage. That actually opens the route to some really nice scenarios regarding the collection of information on MDM managed Windows 10 devices. I’ll start this post by providing some information about the required setting, followed by going through the steps of configuring that setting. I’ll end this post by showing the administrator experience.

Available policy settings and configuration options

Let’s start by having a look at the available policy settings. The required policy setting for this post is available as a policy setting in a new node of the DiagnosticLog CSP. The root node of the DiagnosticLog CSP is ./Vendor/MSFT/DiagnosticLog and the table below describes the relevant nodes below.

PolicyDescription
DiagnosticArchive This is the root node for the DiagnosticArchive functionality (only “Get” functionality).
DiagnosticArchive/ArchiveDefinitionThis policy setting can be used to set an XML snippet (as a string) describing what data to gather and where to upload it when done. That XML defines what the data that should be collected and that should be compressed into a zip file to be uploaded to Azure blob storage (“Add” and “Execute” functionality).
DiagnosticArchive/ArchiveResults This policy setting displays the results of the last archive run (only “Get” functionality).

The required policy setting for this post is the DiagnosticArchive/ArchiveDefinition node. That policy setting requires an XML formatted string as input. The format of the XML is shown below. The elements are all wrapped in the Collection element and it contains at least the an ID and SasUrl element. Those elements are required to make sure that the policy setting will be executed and that the collected data is sent to the correct location. The collected data will be uploaded in the format DiagLogs-{ComputerName}-YYYYMMDDTHHMMSSZ.zip. That format is not configurable.

<Collection>
     <ID>{id}</ID>
     <SasUrl>{web address}/{container}{key}</SasUrl>
     <RegistryKey>{registry key}</RegistryKey>
     <Command>{command}</Command>
     <FoldersFiles>{file or folder}</FoldersFiles>
     <Events>{event viewer}</Events>
</Collection>

The usage of the different elements in the XML formatted string is described in the table below.

ElementDescription
IDThe ID element is used to specify a unique GUID value that defines the run of the DiagnosticLog CSP. The ID can be generated by using the New-Guid cmdlet. A new ID is required to trigger a new collection.
Example value: 91d667ae-18d3-46c6-ae43-0bb6d6ac25f4
SasUrl The SasUrl element is used to specify the storage location for the collected data. The SasUrl can be copied from Blob service SAS URL of the storage container, with the addition of the storage container name (make sure to escape special characters).
Example value: <![CDATA[https://{storageaccount}.blob.core.windows.net/{storagecontainer}?sv=2018-03-28&ss=b&srt=o&sp=c&se=2019-10-30T04:19:14Z&st=2019-09-17T19:19:14Z&spr=https&sig=qpVr6NFegQfjIWYV4uwsAqbT1FtgzCtz8P%2Bbrhl6%2FQM%3D]]>
RegistrykeyThe Registrykey element (there can be multiple) can be used to specify a registry key that should be exported and collected.
Example value: HKLM\Software\Policies\Microsoft
FoldersFilesThe FoldersFiles element (there can be multiple) can be used to specify a file or folder that should exported and collected.
Example value: C:\Windows\Temp\MDM*.*
Command The Command element (there can be multiple) can be used to specify a command that should be executed.
Example value: %windir%\system32\mdmdiagnosticstool.exe -out C:\Windows\Temp\MDM\
Events The Events element (there can be multiple) can be used to specify an Event Log that should exported and collected (specify the name of the log).
Example value: Microsoft-Windows-User Device Registration/Admin

Constructing and configuring the policy setting

Now let’s continue by constructing the XML formatted string and by having a look at the configuration. The first step is constructing the XML format string that will be used during the configuration. The main use case of this post is gathering troubleshooting information. For that reason the XML formatted string is constructed with information to gather the policy registry key, to run the MDM diagnostics tool, to gather the result of the MDM diagnostic tool and to gather additional event logs. A nice combination to show all the different options. The example constructed for this post is provided below. It contains the earlier mentioned example values. The only elements that should still be added are the ID and the SasUrl. Those elements are environment specific.

<Collection>
    <ID>{GUID}</ID>
    <SasUrl><![CDATA[{web address}/{container}{key}]]></SasUrl>
    <RegistryKey>HKLM\Software\Policies\Microsoft</RegistryKey>
    <Command>%windir%\system32\mdmdiagnosticstool.exe -out C:\Windows\Temp\MDM\</Command>
    <FoldersFiles>C:\Windows\Temp\MDM\*.*</FoldersFiles>
    <Events>Microsoft-Windows-User Device Registration/Admin</Events>
</Collection>

After constructing the XML it’s time for the actual configuration of the policy setting. The following four steps walk through the actual configuration steps of a custom device configuration profile. That device configuration profile can be used to configure the ArchiveDefinition policy setting. After creating the device configuration profile, simply assign the profile like any other device configuration profile.

  1. Open the Azure portal and navigate to Microsoft Intune Device configuration Profiles to open the Devices configuration – Profiles blade
  2. On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade
  3. On the Create profile blade, provide the following information and click Create
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Windows 10 and later
  • Profile type: Custom
  • Settings: See step 4
  1. On the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade)
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Vendor/MSFT/DiagnosticLog/DiagnosticArchive/ArchiveDefinition
  • Data type: Select String
  • Value: {XML}

Administrator experience

Let’s end this post by having a look at the administrator experience. Below on the first row on the left is an example of the collected data in the storage account. It provides an overview of the devices that collected and uploaded the requested data. All conform the mentioned naming standard. Below on the first row on the right is an example of the same data, but downloaded and extracted. The XML provides an overview of the results of the different actions to gather data. The folders contain the data of the different actions. The number of folders matches the number of actions in the provided XML. The lines even match (line 1 is folder 1, etc.).

Below on the second row is an example of how the information is logged in the registry. The MdmDiagnostics key contains a value that contains the results of the latest run, the Results value, and a value that contains the initial XML, the XML value. That key also contains a key per diagnostics collection run. The ID of the latest run is registered in the earlier mentioned values.

More information

For more information about triggering devices to upload files to cloud storage, see the DiagnosticLog CSP for triggering devices to upload files to cloud section in the DiagnosticLog CSP documentation.

Windows 10 MDM policy refresh

This week is all about the Windows 10 MDM policy refresh. More specifically, the policy refresh behavior starting with Windows 10, version 1903. Starting with Windows 10, version 1903, the policy refresh got a lot more interesting. Before Windows 10, version 1903, the policy refresh would simply tattoo the settings once during the device checking. Starting with Windows 10, version 1903, the settings that are implemented by the Policy CSP are actually refreshed during the device check-in. Not just tattooed once, but actually re-applied when for example adjusted by the user. Also, similar to that, those settings are also removed when no longer assigned. In this post I’ll have a look at the triggers for a device check-in, the different device check-in actions and the difference in behavior of the device check-ins (focused on the Policy CSP).

Triggers for device check-ins

Let’s start by looking at the multiple triggers for the device check-in. I would like to differentiate between the following three different type of device check-in triggers:

  • A notification – The check-in can be triggered by a notification from Microsoft Intune.
  • A scheduled check-in – The check-in can be triggered by a scheduled task.
  • A manual check-in – The check-in can be triggered manually by the user.

Notifications that trigger device check-ins

The challenge with notifications that trigger a device check-in is that it’s not an exact science and that we’re mainly bound to the docs about the process. When looking at the notifications that trigger device check-ins there are basically different actions, performed by the administrator, that can trigger a notification. The triggered notification will notify the device to check-in with Microsoft Intune. Actions that trigger a notification are for example when a policy, a profile, or an app is assigned (or unassigned), updated, or deleted.

The device will check-in with Microsoft Intune when the device receives a notification to check-in. The challenge is that it’s up to the device to actually check-in. A different priority, so to say, is for targeting a device or user with an action, like a lock, a passcode reset, an app, a profile or a policy assignment. With those actions Microsoft Intune immediately notifies the device to check in to receive these updates.

There are also changes that don’t cause a notification to the devices. For example revising the contact information in the Company Portal app don’t cause an immediate notification to be send to the device.

This device check-in will refresh the already applied Policy CSP settings and will also remove unassigned Policy CSP settings.

Scheduled device check-ins

The scheduled device check-ins are more clear. In that case we’re not mainly stuck to the docs, as the configuration is available in the Task Manager. After the device is enrolled in Microsoft Intune, three scheduled tasks will be enabled and run on different schedules. Let’s have a close look at those scheduled tasks.

Frequency of scheduled device check-ins

Once a Windows 10 device is enrolled in Microsoft Intune, three different scheduled tasks will be used to trigger the compliance and configuration check-ins. Those scheduled tasks can be found in the Task Scheduler at Microsoft > Windows > EnterpriseMgmt > {tenantId}.

Table 1 provides an overview of the different check-in schedules that belong to the different scheduled tasks. The first scheduled task repeats every 3 minutes for the first 15 minutes after the enrollment. The second scheduled task starts 15 minutes after the enrollment and repeats every 15 minutes for 2 hours and the third scheduled task starts 2 hours and 15 minutes after the enrollment and repeats every 8 hours indefinitely.

Table 1: Check-in frequency
Schedule Frequency
Schedule #1 created by the enrollment clientAfter triggered, repeat every 3 minutes for a duration of 15 minutes
Schedule #2 created by the enrollment clientAfter triggered, repeat every 15 minutes for a duration of 2 hours
Schedule #3 created by the enrollment clientAfter triggered, repeat every 8 hours indefinitely

Note: The behavior for devices without user affinity is different, as it’s up to the device to check-in.

Action during scheduled device check-ins

During the device check-in the deviceenroller.exe will be started as a program. The different scheduled tasks, used for triggering the compliance and configuration check-ins, use slightly different parameters.

Table 2 provides an overview of the different check-in actions. The deviceenroller.exe program itself is still a little bit of a mystery, as it’s being user for enrolling devices en also for check-ins. Both by using different parameter. Sadly not all parameters speak for itself, which makes it a little guesswork to fully understand.

This device check-in action will also refresh the already applied Policy CSP settings.

Table 2: Check-in action
Schedule Action
Schedule #1 created by the enrollment client%windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c
Schedule #2 created by the enrollment client%windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c
Schedule #3 created by the enrollment client%windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c /b

Note: The documented actions can also be used to “manually” trigger a device check-in.

Manual device check-ins

The manual device check-ins are also in the gray area. It’s clear that the manual device check-in can be triggered by using the Settings panel. Navigate to Accounts > Access work or school and click Sync. Another option is by using the Company Portal app. Navigate to Settings and click Sync.

During the device check-in the omadmclient.exe will perform actions to sync the policies.

This device check-in will not refresh the already applied Policy CSP settings.

Recognize different device check-ins

I noticed that the easiest method to fully recognize the difference in device check-ins, is by using the Event Viewer. When opening the Event Viewer, simply navigate to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider and look at for Event ID 208. The difference will be in the origin of the started session, as shown in the following list:

  • A notification – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x7), Initiator: (0x0), Mode: (0x2), SessionID: (0x7C), Authentication Type: (0x3).
  • A scheduled check-in – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x3), Initiator: (0x0), Mode: (0x2), SessionID: (0x75), Authentication Type: (0x3).
  • A manual check-in (by using Settings panel) – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x5), Initiator: (0x0), Mode: (0x2), SessionID: (0x76), Authentication Type: (0x3).
  • A manual check-in (by using Company Portal app) – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0xD), Initiator: (0x0), Mode: (0x2), SessionID: (0x77), Authentication Type: (0x3).

Example Windows 10 MDM policy refresh

Now let’s end this post by having a look at an example of the Windows 10 MDM policy refresh. Below on the right I’ve adjusted the telemetry setting of the device and below on the left I’m manually running the device check-in action of the scheduled task (yes, I’ve tested it multiple times). It end’s by refreshing the telemetry value immediately after the check-in.

More information

For more information about installing applications for devices, please refer to the doc about Common questions, issues, and resolutions with device policies and profiles in Microsoft Intune.