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.

Configure time zones via Windows 10 MDM

This week a blog post about a nice newly introduced policy setting in Windows 10, version 1903. That setting is available in the TimeLanguageSettings area, and can be used to set the time zone of the device. The TimeLanguageSettings area already existed before Windows 10, version 1903, but previously only contained a single setting for Windows 10 Mobile. Now it also contains a very useful setting related to non-Mobile versions of Windows 10. That setting will give some more control on the default time zone configuration of a device. In this post I’ll briefly go through the setting, followed by the configuration and the end-user experience.

Settings

Let’s start by having a look at the setting. The TimeLanguageSettings area is not a new node within the Policy CSP, but starting with Windows 10, version 1903, it does contain a nice new policy setting.  Below is an overview of that policy setting. Keep in mind that the complete node of this policy setting starts with ./Device/Vendor/MSFT/Policy/Config/TimeLanguageSettings/.

Policy Description

ConfigureTimeZone

Value: <time zone ID>

This policy can be used to specify the time zone that should be applied to the device.

Note: The time zone ID can be retrieved by using tzutil.exe. Simply use tzutil.exe /g on a device that already has the correct time zone configured.

Configuration

Now let’s continue by having a look at the configuration steps for the time zone. In other words, create a device configuration profile with the previously mentioned custom policy setting. I will use my own time zone as an example. The following three steps walk through the creation of that device configuration profile. After that simply assign the created profile to a user or device group.

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;
3a

TZC-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Time zone configuration
  • Description: (Optional)  
  • Platform: Select Windows 10 and later
  • Profile type: Select Custom
  • Settings: See step 3b
3b

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: Set time zone
  • Description: (Optional)
  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/TimeLanguageSettings/ConfigureTimeZone
  • Data type: Select String;
  • Value: W. Europe Standard Time

TZC-AddRow

Note: At some point in time this configuration will probably become available in the Azure portal without the requirement of creating a custom OMA-URI.

End-user experience

Let’s end this post by looking at the end-user experience. Below is an example of a Windows 10 device running version 1903. In that example it shows the configuration of the time zone that should be configured. In my testing the end-user would still be able to adjust the time zone afterwards.

TZC-EndUserExperience01

As the end-user was still able to adjust the configuration afterwards, I wanted to be sure that the configuration was actually applied. To do that I also looked at the MDM Diagnostics Report. That report, which is shown below, clearly shows that the policy setting is configured,

TZC-EndUserExperience02

Besides that report, the Event Viewer will also provide the information about the time zone change.

  • The Admin log in Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Proivder shows event id 814 with the message MDM PolicyManager: Set policy string, Policy: (ConfigureTimeZone), Area: (TimeLanguageSettings), EnrollmentID requesting merge: (A77EC83D-AFD9-4949-AE0C-69CD6784C83F), Current User: (Device), String: (W. Europe Standard Time), Enrollment Type: (0x6), Scope: (0x0).
  • The System log shows event id 22 with the message The time zone bias has changed to -120 from 420 followed by event id 1 with the message The system time has changed to ‎2019‎-‎07‎-‎11T06:26:15.574273500Z from ‎2019‎-‎07‎-‎11T06:26:15.574273500Z. Change Reason: System time adjusted to the new time zone.

More information

For more information about the available time zone settings in the Policy CSP, please refer to the documentation about Policy CSP – TimeLanguageSettings.

Working with Win32 app dependencies

After a couple of weeks with distractions, this week I’m stepping away from conditional access. This week is all about Win32 app management capabilities. More specifically, about Win32 app dependencies. About half a year ago, when Win32 app management capabilities were introduced, I did my first post about those capabilities. That post is still being read really good, so I thought this would be a good time for a nice addition to that post. In this post I’ll start with a shorting introduction about Win32 app dependencies, followed by the configuration steps for Win32 apps and specifically for Win32 app dependencies. I’ll end this post by showing the experience for the end-user and the administrator.

Introduction

Let’s start with a short introduction about reason for using Win32 apps and more specifically about using the Win32 app dependencies. Slowly there are coming more and more reason to look at Win32 apps as a serious alternative to using single-file MSI via MDM. An important reason for that is that Windows 10, version 1709 and later, will download Win32 app content by using delivery optimization. Other reasons are the Win32 app configuration options for requirements and detection rules. That will make the Win32 app really flexible. To make the Win32 app even more flexible, and even more comparable to the ConfigMgr app model, it’s now also possible to configure dependencies between Win32 apps.

Scenario

Before looking at the actual configuration steps, let’s first describe the example scenario that I’ll use to show the Win32 app dependencies feature. As an example scenario, I’m using PolicyPak. I won’t go into details about the functionalities of PolicyPak, that information can be found here. The reason that I’m using it as an example scenario, is simply because the installation contains three steps: install the license file, install the client-side extension and install any setting file. All of these are available as MSI and the mentioned order (see also the picture below) provides the best result. In other words, ideal for showing the Win32 app dependencies feature.

PolicyPak-dependency-overview

Note: In my testing, PolicyPak will work just perfectly fine if you don’t take into account dependencies, but this is an ideal scenario to ensure that all policies delivered from PolicyPak always get applied the first time

Configuration

Now let’s start with the configuration steps. I’ll do that by first quickly showing the steps to wrap a Win32 app and the steps to configure a Win32 app. For more details about that, please refer to my previous post about Win32 apps. After that, I’ll show the detailed steps for configuring Win32 app dependencies.

Prepare Win32 app

The first step is to quickly go through the steps to prepare the Win32 apps by using the Microsoft Intune Win32 App Packaging Tool. Wrap the Win32 apps. The packaging tool wraps the application installation files into the .intunewin format. Also, the packaging tool detects the parameters required by Intune to determine the application installation state.  The following five steps walk through wrapping the different PolicyPak MSIs.

1 Download the Microsoft Intune Win32 App Packaging Tool. In my example to C:\Temp;
2 Create a folder per PolicyPak MSI. In my example C:\Temp\[PolicyPakMSI];
3 Open a Command Prompt as Administrator and navigate to the location of IntuneWinAppUtil.exe. In my example that means cd \Temp;
4 Run IntuneWinAppUtil.exe and provide the following information, when requested

  • Please specify the source folder: C:\Temp\[PolicyPakMSI];
  • Please specify the setup file: [PolicyPakMSI].msi;
  • Please specify the output folder: C:\Temp
5 Once the wrapping is done. The message Done!!! will be shown. In my example a file named [PolicyPakMSI].intunewin will be created in C:\Temp.

Note: The mentioned steps should be performed per PolicyPak MSI.

Configure Win32 app

The next step is to quickly look at the configuration steps, within Microsoft Intune, to configure the Win32 apps. The following 17 steps walk through all the steps to configure the Win32 apps, by using the .intunewin files.

1 Open the Azure portal and navigate to Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, click Add to open the Add app blade;
3 On the Add app blade, select Windows app (Win32) – preview to show the configuration options and select App package file to open the App package file blade.
4 On the App package file blade, select the created [PolicyPakMSI].intunewin as App package file and click OK to return to the Add app blade;
5 Back on the Add app blade, select App information to open the App information blade;
6 On the App information blade, provide at least the following information and click OK to return to the Add app blade;

  • Name: [PolicyPakMSI] is pre-provisioned as name of the app;
  • Description: Provide a description of the app;
  • Publisher: Provide the publisher of the app;

Note: The remaining information regarding the Information URL, the Privacy URL, the Developer, the Owner, the Notes and the Logo is optional.

7 Back on the Add app blade, select Program to open the Program blade;
8 On the Program blade, verify the Install command and the Uninstall command and click OK to return to the Add app blade;
9 Back on the Add app blade, select Requirements to open the Requirements blade;
10 On the Requirements blade, provide at least the following information and click OK to return to the Add app blade;

  • Operating system architecture: Select the applicable platforms;
  • Minimum operating system: Select a minimum operating system version;
11 Back on the Add app blade, select Detection rules to open the Detection rules blade;
12 On the Detection rules blade, select Manually configure detection rules and click Add to open the Detection rule blade.
13 On the Detection rule blade, select MSI as Rule type, verify the pre-provisioned MSI product code and click OK to return to the Detection rules blade;
14 Back on the Detection rules blade, click OK to return to the Add app blade;
15 Back on the Add app blade, select Return codes to open the Return codes blade;
16 On the Return codes blade, verify the preconfigured return codes and click OK to return to the Add app blade;
17 Back on the Add app blade, click Add to actually add app.

Note: The mentioned steps should be performed per PolicyPak .intunewin file.

Configure Win32 app dependency

Now the main configuration of this post, the configuration of the dependency between Win32 apps. The created Win32 apps need to be installed in the order as described (and shown) during the explanation of the scenario. The following six steps walk through the Win32 app dependency configuration. In my scenario, these steps need to be performed for he PolicyPak settings MSI, to create a dependency between the PolicyPak settings MSI and the PolicyPak client-side extensions MSI, and for the PolicyPak client-side extensions MSI, to create a dependency between the PolicyPak client-side extensions MSI and the PolicyPak license MSI. After configuring the Win32 app dependencues, make sure to assign the PolicyPak settings MSI to a user group.

1 Open the Azure portal and navigate to Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, select the just created [PolicyPakMSI] app to open the [PolicyPakMSI] app blade;
3 On the [PolicyPakMSI] app blade, select Dependencies to open the [PolicyPakMSI] app – Dependencies blade;
4 On the [PolicyPakMSI] app – Dependencies blade, click Add to open the Add dependency blade;
5 On the Add dependency blade, select the [PolicyPakMSI] app and click Select to return to the [PolicyPakMSI] app – Dependencies blade;
Win32App-AddDependency
6 Back on the [PolicyPakMSI] app – Dependencies blade, select Yes with AUTOMATICALLY INSTALL and click Save.
Win32App-AddDependency-Save

Note: Keep in mind that these steps need to be performed for both dependencies.

Experience

Now let’s end this post by looking at the end-user experience and the administrator experience.

End-user experience

The first experience to look at is the end-user experience. Below, from left to right, is the end-user experience. As I configured the dependencies to automatically install, the dependencies will install before the actual assigned PolicyPak settings MSI. First the end-user will receive the message that PolicyPak license MSI will install as a part of the PolicyPak settings MSI installation. After a successful installation, the end-user will receive the message that the PolicyPak client-side extensions MSI will install as part of the PolicyPak settings MSI installation. And once that installation is successful, the PolicyPak settings MSI will install.

PP-Example01 PP-Example02 PP-Example03

Administrator experience

Win32App-AdministratorExperienceThe second experience to look at is the administrator experience. That is not always the most exiting experience to look at, but in this case it does add something good and new to look at. For the administrator, Microsoft Intune provides the Dependency viewer. The Dependency viewer can be found by selecting an app and navigating to Monitor > Dependency viewer. The Dependency viewer shows the the dependencies of the selected app and the dependencies of the dependencies (all the way down). The Dependency viewer does not show the apps that depend on the app. So, to explain that with the example of this post, it would be like this:

  • PolicyPak settings MSI: The PolicyPak settings MSI would show that it has a dependency on the PolicyPak client-side extensions MSI and that the PolicyPak client-side extensions MSI has a dependency on the PolicyPak MDM license MSI (as shown on the right);
  • PolicyPak client-side extensions MSI: The PolicyPak client-side extensions MSI would show that it has a dependency on the PolicyPak MDM license MSI;
  • PolicyPak MDM license MSI: The PolicyPak MDM license MSI would show no dependencies.

More information

For more information regarding Win32 apps and Win32 app dependencies, please refer to the following article:

Always apply baseline to co-managed devices

Like the last couple of weeks, this week is also about co-management. This week is all about another nice detail that can be really useful, in specific use cases. That detail is the ability to always apply a configuration baseline to co-managed devices. Even when the Device configuration workload is switched from Configuration Manager to Microsoft Intune. That can be useful for configurations that are not available yet via Microsoft Intune, or for compliance checks that need to be performed and consolidated in one location. In this post I’ll provide a short introduction about the different configuration options, followed by the steps to configure a configuration baseline to co-managed devices when the workload is switched to Microsoft Intune. I’ll end this post with the end-results.

Introduction

When looking at the evaluation of baselines, co-management provides the administrator with 3 different configuration options (of which the third options is the main subject of this post):

  1. Apply Configuration Baselines via Configuration Manager when the Device configuration workload is set to Configuration Manager:
  2. Apply Device configuration profiles via Microsoft Intune when the Device configuration workload is set to Microsoft Intune:
  3. Apply Configuration Baselines via Configuration Manager as an exception to Device configuration profiles via Microsoft Intune when the Device configuration workload is set to Microsoft Intune

Configuration

Let’s start by having a look at the configuration. I’ll do that by going through an example that will create a baseline to verify the update compliance of co-managed devices. That will provide an easy method to verify compliance and consolidate the results. Below are 4 steps that walk through the process.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Baselines;
2 On the Home tab, click Create Configuration Baseline to open the Create Configuration Baseline dialog box;
3a

AlwaysApply-Step01On the Create Configuration Baseline dialog box, provide the following information and click OK to create the configuration baseline.

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description; 
  • Configuration data: See step 3b;
  • Select Always apply this baseline even for co-managed clients;

Explanation: The check Always apply this baseline even for co-managed clients in the baseline will make sure that the baseline is always applicable to co-managed devices. Even when the Device configuration workload is set to Microsoft Intune.

3b

AlwaysApply-Step02On the Create Configuration Baseline dialog box, click Add > Software Update to open the Add Software Updates dialog box. On the Add Software Updates dialog box, find the required software update and click OK.

Explanation: This configuration will make sure that this baseline will verify the compliance of all co-managed devices for the latest cumulative update.

4

AlwaysApply-Step03Right-click the just created baseline and click Deploy to open the Deploy Configuration Baselines dialog box. Leave everything default, select the collection for this baseline deployment and click OK.

Explanation: This configuration will make sure that this baseline is deployed to the required collection and will make sure that this baseline is only used for compliance and not for remediation.

Note: The setting Always apply this baseline even for co-managed clients in the baseline, as mentioned in step 3a, can be used to make sure that the baseline is always applied on co-managed devices.

End-results

Now let’s continue by having a look at the results on a co-managed device. Below are two examples of one of a co-managed device. First an overview of the Configuration Manager Properties, followed by a look in the DCMAgent.log file. Both are client-side details, as the server-side will provide status information similar like for any other device.

1 AlwaysApply-ConfigMgrPropertiesThe first example that I would like to show, is the Configurations tab in the Configuration Manager Properties. The Configurations tab shows the deployed baseline, including the last evaluation time and the compliance state. Similar to the evaluation of a baseline when the Device configuration workload is still set to Configuration Manager;
2 The second example that I would like to show, is the DCMAgent.log file. That log file records high-level information about the evaluation, conflict reporting, and remediation of configuration items and applications. Specifically to this post, this log file provides information about the status of the Device configuration workload (first arrow below) and provides information about specifically enabled baselines (second arrow below);
AlwaysApply-DCMAgent

More information

For more information about co-managed devices and configuration baselines, please refer to this article about creating configuration baselines in System Center Configuration Manager.

Switching the Office Click-to-Run apps workload

This week is all about the Office Click-to-Run apps workload. More specifically, this week is all about what’s happening, from a Configuration Manager perspective, when switching the Office Click-to-Run apps workload to Microsoft Intune. Switching the Office Click-to-Run apps workload to Microsoft Intune will make sure that the Office Click-to-Run app will be installed via Microsoft Intune and no longer via Configuration Manager. In this post I’ll show how to switch the Office Click-to-Run apps workload to Microsoft Intune, followed by what is actually making sure that Configuration Manager will no longer install Office Click-to-Run apps. I’ll end this post with a summary.

Configuration

Let’s start with the easy part, in this case, the configuration. Assuming that co-management is already configured, the following 3 steps will walk through the process of switching the Office Click-to-Run apps workload to Microsoft Intune.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Co-management;
2 Select CoMgmtSettingsProd and click Properties in the Home tab, to open the Properties dialog box;
3

O365W-ComanangementPropertiesOn the Properties dialog box, navigate to the Workloads tab. On the Workloads tab, move the slider with Office Click-to-Run apps to Intune.

Note: When there is a need to first test this configuration with a pilot group, simply move the slider with Office Click-to-Run apps to Pilot Intune. In that case make sure to configure a Pilot collection on the Staging tab of the Properties dialog box. 

Note: This configuration change will update the configuration baseline that is used to apply the co-management configuration to Configuration Manager clients. That baseline is shown on Configuration Manager clients as CoMgmtSettingsProd (and for pilot devices also CoMgmtSettingsPilot).

Effect of the configuration

Now let’s continue by looking at the effect of this configuration, from a Configuration Manager perspective. I’ll do that by showing the Global Condition that is used, I’ll do that by showing how that Global Condition is used and I’ll do that by showing what happens on the client device.

1 The first thing that I want to look at is the Global Condition that is used. Starting with Configuration Manager, version 1806, the Intune O365 ProPlus management condition is created as a Global Condition in Configuration Manager. That condition is used to make sure that the Configuration Manager client can no longer install the Office Click-to-Run app on co-managed devices, as the condition will be added as a requirement to the app. That is achieved by a VBScript, in the condition, that queries SELECT * FROM DeviceProperty WHERE DeviceIsO365IntuneManaged=TRUE in the root\ccm\cimodels namespace. Based on the results of the query, the VBScript will either return true or false. That return value will be used to evaluate the requirement of the app.
O365W-ConfigMgrConsole
2 O365W-AppRequirementThe second thing that I want to look at is the default configuration of the Office Click-to-Run app that is created when walking through the Microsoft Office 365 Client Installation Wizard. More specifically, the Requirements tab of the created Deployment Type. After a new Office Click-to-Run app is created, the Intune O365 ProPlus management condition is added as requirement to the Deployment Type. The value is configured to False, to make sure that the Office Click-to-Run app is not installed when the Office Click-to-Run apps workload is switched to Intune (or to Pilot Intune).
3 O365W-WbemTestThe third thing that I want to look at is the change on a co-managed device after the Office Click-to-Run apps workload is switched to Intune. Starting with Configuration Manager, version 1806, the Configuration Manager client has a new DeviceProperty named DeviceIsO365IntuneManaged in the root\ccm\cimodels namespace.Based on the configuration of the Office Click-to-Run apps workload, this property is configured to either TRUE or FALSE. That is done during the evaluation of the CoMgmtSettingsProd (and for pilot devices also CoMgmtSettingsPilot) baseline on Configuration Manager clients.

Note: Together these 3 things will make sure that the Configuration Manager client will no longer install any deployed Office Click-to-Run apps when the Office Click-to-Run apps workload is switched.

Summary

Let’s end this post with a summary of what is happening from a Configuration Manager perspective.

  • A relatively new Global Condition, named Intune O365 ProPlus management, is available in Configuration Manager;
  • The Intune O365 ProPlus management condition is used to verify if the co-managed device should use Configuration Manager or Intune for installing the Office Click-to-Run app;
  • The Intune O365 ProPlus management condition is added by default to to Office Click-to-Run apps created through the Microsoft Office 365 Client Installation Wizard;
  • A relatively new DeviceProperty, named DeviceIsO365IntuneManaged, is available in the Configuration Manager client configuration in WMI;
  • The DeviceIsO365IntuneManaged property is used to contain the status of the co-managed device, regarding whether Configuration Manager or Intune should be used to install the Office Click-to-Run app;
  • The DeviceIsO365IntuneManaged property is configured based on the status of the Office Click-to-Run apps workload in the co-management configuration;
  • The Office Click-to-Run app is deployed via Configuration Manager and the Configuration Manager client verifies the status of the DeviceIsO365IntuneManaged property by using the Intune O365 ProPlus management condition.

More information

For more information regarding the Office Click-to-Run apps workload, please refer to this article about Co-management workloads.

The different ways of enrolling devices in Windows Analytics

After a week of silence, due to the MVP Summit, this week another new blog post. This week is all about enrolling devices in to Windows Analytics. An updated version, with a slightly different angle, of a post of about two years ago. This time I’ll summarize the different methods to achieve the same goal and the changes since Windows 10, version 1803. I’ll start this post with an overview of the required settings, followed by an overview of the different configuration methods. I’ll end this post by going through my preferred method, for a cloud scenario, and the administrator experience.

Settings to configure

Now let’s start by looking at the settings that are required to enroll devices in to Windows Analytics. Those settings are the commercial ID, the telemetry level (and with that enabling Windows telemetry) and allowing the device name in the telemetry data (since Windows 10, version 1803). The following table describes the settings that are required, including a description, and starting point for my preferred method, for a cloud scenario, of configuring these settings.

Policy Description

AllowTelemetry

Values: 0 (Security), 1 (Basic), 2 (Enhanced), or 3 (Full)

This setting should be used to enable Windows telemetry. Windows Analytics requires a minimum Windows telemetry level of enhanced (optional together with the policy LimitEnhancedDiagnosticDataWindowsAnalytics to limit the telemetry data to the minimal required).

AllowDeviceNameInDiagnosticData

Values: 0 (Disabled) or 1 (Enabled)

This setting should be used to allow the device name in the Windows telemetry that is sent to Windows Analytics. That will enable that the different solutions within Windows Analytics can actually be used for really tracking update compliance.

CommercialID

Values: [YourCommercialID]

This setting should be used to specify the workspace id that should be used for Windows Analytics. The commercial ID can be found in the Settings of the different Windows Analytics solutions.

Note: The first two policies are available in the node ./Vendor/MSFT/Policy/Config/System and the third policy is available in the node ./Vendor/MSFT/DMClient/Provider/MS DM Server.

Configuration options

Let’s continue with looking at the different configuration methods. Every configuration option has pros and cons, which can differ per scenario.

1 WA-ConfigMgrWhen using Configuration Manager, the Configuration Manager client can be used to enroll a device in to Windows Analytics. This can be achieved by using the Windows Analytics section in the Client Settings. This configuration method can configure the commercial ID and the telemetry level. This can be a useful method in an on-premises, or a co-management scenario. Only allowing the device name in the telemetry data would require an additional configuration method.
2 WA-GPOWhen using Group Policy, Administrative Templates can be used to enroll a device in to Windows Analytics. This can be achieved by using the Data Collection and Preview Builds section in the Windows Components section of the Administrative Templates. This configuration method can configure the commercial ID, the telemetry level and the device name. This can be useful in any on-premises, or cloud scenario (by using a third-party tool like PolicyPak: MDM Edition). Only reporting on a setting-level will be limited in a cloud scenario.
3 When using Configuration Manager or Microsoft Intune, PowerShell scripts can be used to enroll a device in to Windows Analytics. This can be achieved by using the New-Item and the New-ItemProperty cmdlets to directly create the required registry keys. This configuration method can configure the commercial ID, the telemetry level and the device name. This can be useful in any on-premises, or cloud scenario. Only reporting on a setting-level will be limited.
4 WA-MDMWhen using Microsoft Intune, Windows 10 MDM can be used to enroll a device into Windows Analytics. This can be achieved by using custom OMA-URI settings. This configuration method can configure the commercial ID, the telemetry level and the device name. This can be useful in a co-management, or cloud scenario.

Preferred configuration option

Let’s continue by looking at my preferred configuration option, at least in a cloud scenario. Besides using Group Policy, this is the most reliable and complete option for configuring the required settings. It allows setting-level configuration and reporting. The following 3 steps walk through the required actions.

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;
3a

WA-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b;

Explanation: This configuration will make sure that a custom profile is created that can be used to add the required Windows Analytics settings.

3b

WA-AddRowOn 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 description;
  • OMA-URI: Specify a the required policy setting;
  • Data type: Select Integer;
  • Value: Specify the required value;

Note: Simply repeat this step for every policy setting that should be configured.

WA-MDM

Note: At some point in time this configuration will probably become available in the Azure portal without the requirement of creating a custom OMA-URI.

Administrator experience

Let’s end this post by looking at the administrator experience. Of course I can simply show the configurations on the device, but I thought that showing a device including the device name in a solution would show the complete picture. It proofs that Windows telemetry is enabled, that it’s sending data to the correct workspace and that it’s sending the device name (even for devices with Windows 10, version 1803 and newer). See below for that example.

WA-Result

More information

For more information about Windows Analytics and Microsoft Intune, please refer to the following articles:

Configure storage sense via Windows 10 MDM

This blog post uses the Storage node of the Policy CSP, to configure Storage Sense on Windows 10 devices. Most of the policies in that area are added in Windows 10, version 1903, which is currently still in preview.

This week a short blog post about a few newly introduced policy settings in Windows 10, version 1903, which is currently still in preview. Those settings are related to Storage Sense and those settings are made available via a newly introduced ADMX-file. That ADMX-file is StorageSense.admx. Storage Sense can automatically clean some of the user’s files to free up disk space. In this post I’ll briefly go through the available settings, followed by the configuration and the end-user experience.

Settings

Let’s start by having a look at the available settings. The Storage area is not a new node within the Policy CSP, but starting with Windows 10, version 1903, it does contain multiple new policy settings. These policy settings are ADMX-backed policy settings, which are part of the new StorageSense.admx. Below is an overview of the available policy settings. Keep in mind that the complete node of these policy settings, starts with ./Device/Vendor/MSFT/Policy/Config/Storage/.

Policy Description

AllowStorageSenseGlobal

Values: 0 (Disabled) or 1 (Enabled)

This setting can be used to enable or disable Storage Sense and to make sure that the user cannot override that.

AllowStorageSenseTemporaryFilesCleanup

Values: 0 (Disabled) or 1 (Enabled)

This setting can be used to configure that when Storage Sense runs, it can delete the temporary files that are not in use.

ConfigStorageSenseCloudContentDehydrationThreshold

Values: 0-365 (Days)

This setting can be used to configure that when Storage Sense runs, it can dehydrate cloud-backed content that hasn’t been opened in a certain amount of days.

ConfigStorageSenseDownloadsCleanupThreshold

Values: 0-365 (Days)

This setting can be used to configure that when Storage Sense runs, it can delete files in the Downloads folder if they have been there for over a certain amount of days.

ConfigStorageSenseGlobalCadence

Values: 1 (Daily), 7 (Weekly), 30 (Monthly) or 0 (During low free disk space)

This setting can be used to configure Storage Sense to automatically clean some of the files to free up disk space.

ConfigStorageSenseRecycleBinCleanupThreshold

Values: 0-365 (Days)

This setting can be used to configure that when Storage Sense runs, it can delete files in the Recycle Bin if they have been there for over a certain amount of days.

Note: Even though these policy settings are ADMX-backed policy settings, I noticed that it wasn’t required to use specific configuration values. I could use simple integer values.

Configuration

Now let’s continue by having a look at the configuration options for Storage Sense. In other words, create a device configuration profile with the previously mentioned custom policy settings. The following three steps walk through the creation of that device configuration profile. After that simply assign the created profile to a user or device group.

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;
3a

MSIntune-DC-SS-01On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MSIntune-DC-SS-02On 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 description;
  • OMA-URI: Specify a the required policy setting;
  • Data type: Select Integer;
  • Value: Specify the required value.

Note: Simply repeat this step for every policy setting that should be configured.

MSIntune-DC-SS-03

Note: At some point in time this configuration will probably become available in the Azure portal without the requirement of creating a custom OMA-URI.

End-user experience

Let’s end this post by looking at the end-user experience. Below is an example of a Windows 10 device running the latest available Windows Insider Preview build. In that example it’s clearly shown that Storage Sense is enabled and managed by the organization.

StorageSenseEnabled01

More details about the Storage Sense configuration can be found when clicking on Configure Storage Sens or run it now. These configuration options are shown below, including the configuration that I’ve applied, which can’t be adjusted.

StorageSenseEnabled02

More information

For more information about the available storage sense settings in the Policy CSP, please refer to the documentation about Policy CSP – Storage.