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.

Enable password-less sign-in with security keys

This week is all about enabling password-less sign-in with security keys on Windows 10. I know that a lot has been written about that subject already, but it’s that big that it still deserves a spot on my blog. Especially the Microsoft Intune configuration belongs on my blog. In this post I’ll show the required configurations that should be performed, by an administrator and the the user, to enable the user to use a security key as a sign-in method. My user will use a Yubikey 5 NFC security key. I’ll start this post with the authentication method policy that should be configured in Azure AD, followed by the steps for a user to register a security key. I’ll end this post by showing the different methods to configure security keys a sign-in method on Windows 10, by using Microsoft Intune, and the end-user experience.

Keep in mind that the best experience, for password-less sign-in with security keys, is on Windows 10 version 1903 or higher. This is caused by the fact that the PassportForWork CSP setting is introduced in Windows 10 version 1903.

Configure the authentication method

The first step in enabling password-less sign-in with security keys, is configuring the authentication method. Within Azure AD there is the Authentication method policy available, which is currently still in preview, that can be used to enable password-less authentication for users. Either all users, or a specific group of users. Within that policy it’s currently possible to enable FIDO2 security keys and Microsoft Authentication as password-less authentication options. The following three steps walk through the process of enabling FIDO2 security keys as a password-less authentication option for all users.

  1. Open the Azure portal and navigate to Azure Active Directory Authentication methods > Authentication method policy (preview) to open the Authentication methods – Authentication method policy (preview) blade
  2. On the Authentication methods – Authentication method policy (preview) blade, select FIDO2 Security Key to open the FIDO2 Security Key settings blade
  3. On the FIDO2 Security Key settings blade, provide the following information and click Save
  • ENABLE: Select Yes
  • TARGET: Select All users (use Select users to only enable for specific users)
  • Allow self-service set-up: Select Yes
  • Enforce attestation: Select Yes
The key restriction policy settings are not working yet and should be left default for now.

Register security key as sign-in method

The second step is that the user must register a security key that can be used as sign-in method. That does require that the user already registered an Azure MFA method. If not, the user should first register an Azure MFA method. After registering an Azure MFA method, the following nine steps will walk the user through the process of adding an USB security key.

  1. Open the My Profile and navigate to Security info to open the Security info section
  2. On the Security info section, click Add method to open a dialog box
  3. On the Add method page, select Security key and click Add
  4. On the Security key page, select USB device and click Next
  5. A browser session will open to register the security key
  6. Insert the security key, touch it, provide a PIN and click Next
  7. Touch the security key another time and click Allow
  8. Provide a name for the security key and click Next
  9. On the Your all set page, click Done

After registering a security key as a sign-in method, the user can already use the security key as a sign-in method for browser sessions.

Configure security keys as a sign-in option

The third and last step is to configure security keys as a sign-in option on Windows devices. Within Microsoft Intune there are multiple methods for enabling security keys as a sign-in option on Windows 10 devices. It’s also good to keep in mind that, even though password-less sign-in is supported starting with Windows 10, version 1809, the following configuration options are all for Windows 10, version 1903 or later. The reason for that is actually quite simple, as the required setting (UseSecurityKeyForSignin) is introduced in the PassportForWork CSP with Windows 10, version 1903.

Using Windows enrollment (Windows Hello for Business) settings

The first configuration option is by using the Windows Hello for Business settings that are available within the Windows enrollment settings. Those settings actually enable the administrator to configure the use of security keys for sign-in independent of actually configuring Windows Hello for Business. The biggest challenge with this approach is that it can’t be slowly implemented, as it’s all or nothing. The following two steps walk through this configuration.

  1. Open the Azure portal and navigate to Microsoft Intune Device enrollmentWindows enrollment > Windows Hello for Business to open the Windows Hello for Business blade
  2. On the Windows Hello for Business blade, select Enabled with Use security keys for sign-in and click Save

This setting requires Windows 10, version 1903, or later, and is not dependent on configuring Windows Hello for Business.

Using Device configuration (Identity protection) settings

The second configuration option is by using the Identity protection device configuration profile. The Identity protection device configuration profile, provides the same configuration options as the Windows Hello for Business settings. The biggest difference is that the Identity protection device configuration profile can be implemented by using groups, which allows a phased implementation (and differentiation). The following four steps walk through this configuration.

  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: Identity protection
  • Settings: See step 4
  1. On the Windows Hello for Business blade, select Enable with Use security keys for sign-in and click OK;

This setting requires Windows 10, version 1903, or later, and is not dependent on configuring Windows Hello for Business

Use Device configuration (Custom) settings

The third and last option is by using a Custom device configuration profile. That Custom device configuration profile, is actually identical to the Identity protection device configuration profile. The only difference is that it’s a OMA-URI configuration, so no simple UI switch. Even though it’s good to mention this option, to remember what the actual configuration is that’s done on the background. The following four steps walk through this configuration.

  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: Identity protection
  • 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: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
  • Data type: Select Integer;
  • Value: 1

This setting requires Windows 10, version 1903, or later, and is not dependent on configuring Windows Hello for Business

End-user experience

Let’s end this post by having a look at the end-user experience. Below on the first row it starts with a static example of the sign-in experience on Windows 10 and in a browser. The second row is an example of the password-less sign-in experience of an user on Windows 10, version 1903, using a Yubikey 5 NFC security key. I’m specifically showing the experience when using the Other user sign-in option, as it will show that the user doesn’t need to provide a username nor a password. The user only needs to have the security key and the related PIN.

More information

For more information about password-less sign-in on Windows 10, see this doc named Enable passwordless security key sign in for Azure AD (preview).

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.

Real-time application installation for devices

This week a new blog post again! During my vacation, I’ve been looking at some statistics of my blog and I noticed that my posts about app deployment related subjects are getting a lot of traction lately. That was a trigger for to make this post about a really nice application deployment feature that’s introduced in Configuration Manager, version 1906. That feature is to install applications for a device. The really nice part of this is that it uses the client notification channel to create a real-time application installation experience. In this post I’ll quickly go through the prerequisites, followed by the application deployment configuration. I’ll end this post by looking at the application installation trigger and the corresponding application requests.

Optional feature

Let’s start with the first prerequisites that should be in place to install applications for devices. That prerequisite is to enable the optional-release feature Approve application request for users and device. That can be achieved by simply following the next 2 steps:

  1. Open the Configuration Manager administration console and navigate to Administration > Overview > Updates and Servicing > Features
  2. Select Approve application request for users and device and click Turn on in the Home tab

Application deployment

The second prerequisite that should be in place is that the application should be deployed as available, with administrator approval, to a device collection. That can be achieved by following the next x steps for deploying an application: .

  1. Open the Configuration Manager administration console and navigate to Software Library > Overview > Application Management > Applications
  2. Select the an app and click Deploy in the Home tab to open the Deploy Software Wizard
  3. On the General page, browse to a device collection and click Next

This can be a generic collection, as the correct configuration will not result in a policy that is sent to the client.

  1. On the Content page, verify that the content is on a distribution point and click Next
  2. On the Deployment Settings page, select Install as Action, select Available as Purpose, select An administrator must approve a request for this application on the device and click Next

This is the most important configuration that should be configured in the deployment. This configuration will make sure that the application is available for installation on a device, without it being available for installation by the user.

  1. On the Scheduling page, click Next
  2. On the User Experience page, click Next
  3. On the Alerts page, click Next
  4. On the Summary page, click Next
  5. On the Completion page, click Close

Note: This feature can help with reducing the need for separate collections for every application.

Install application for device

Before looking at the actual actions, make sure that the required permissions are in place. The (administrative) user, performing the application installation trigger, needs at least the following permissions:

  • Application: Read, Approve
  • Collection: Read, Read Resource, Modify Resource, View Collected File

Now let’s have a look at the most interesting part, the actual application installation trigger. When using an administrative user account, with the required permissions, simply open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Devices. The administrative user can now right-click the device and click Install Application (see Figure 3).

That will provide the administrative user with an overview of the available apps for that specific device (see Figure 4). Selecting an application and clicking OK, will trigger the application installation by using the client notification channel.

Note: The application installation trigger and process can be monitored by following the logs related to client notification and application management.

Application requests

Let’s end this post by having a look at the application requests. Every triggered application installation will resolve into an approved application request that can be found in the Configuration Manager administration console by navigating to Software Library > Overview > Application Management > Application Requests (see Figure 5). It’s registered as an application request for all users on that specific device. An administrative user can also deny this request again, as shown in the same figure below. Doing this will trigger the uninstall of the application, when an uninstall command is defined in the configuration of application.

More information

For more information about installing applications for devices, please refer to the doc Install applications for a device.