Windows 10 MDM (PowerShell) scripting

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

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

Configuring device settings

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

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

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

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

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

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

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

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

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

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

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

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

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

Triggering device actions

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

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

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

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

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

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

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

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

More information

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

Scheduling a reboot via Windows 10 MDM

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

Available policy settings

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

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

Configuring the policy settings

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

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

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

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

Result on the device

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

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

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

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

More information

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

Windows 10 MDM troubleshooting

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

Introduction of the MDM Diagnostics Tool

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

Usage of the MDM Diagnostics Tool

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

MdmDiagnosticsTool.exe -out <output folder path>

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

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

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

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

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

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

Output of the MDM Diagnostics Tool

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

Output of usage option 1

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

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

Output of usage option 2 (Autopilot)

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

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

Output of usage option 2 (DeviceEnrollment)

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

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

Output of usage option 2 (DeviceProvisioning)

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

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

Output of usage option 2 (TPM)

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

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

More information

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

Triggering devices to upload (diagnostic) files to cloud storage

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

Available policy settings and configuration options

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

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

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

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

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

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

Constructing and configuring the policy setting

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

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

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

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

Administrator experience

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

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

More information

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

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.

Another new discovery method: Meet the Azure Active Directory Group Discovery!

This week is back to the world of Configuration Manager. With the release of Configuration Manager, version 1906, a lot of new features are introduced. Even a few very nice pre-release features. One of these pre-release features is the subject of this post, the Azure Active Directory Group Discovery. The Azure Active Directory Group Discovery can be used to discover user groups and members of those groups from Azure AD. In case there are users found in Azure AD user groups that haven’t been previously discovered, those users will be added as user resources in Configuration Manager. A user group resource record is created when the group is a security group. In this post I’ll briefly show the prerequisites, followed by the configuration steps. I’ll end this post by showing the administrator experience.

Prerequisites

Let’s start with the prerequisites that should be in place to configure the Azure Active Directory Group Discovery. The following 2 prerequisites should be configured.

1 Enable pre-release feature: The pre-release feature must be enabled. That can be achieved by simply doing the following: Open the Configuration Manager administration console and navigate to Administration > Overview > Updates and Servicing > Features. Select Azure Active Directory user group discovery and click Turn on in the Home tab;
CM-AADUGD-Prerelease
2 Enable cloud management: The cloud management Azure service must be added. That can be achieved by doing the following: Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services. Click Configure Azure Services in the Home tab and follow the documented instructions here;

Configuration

When the prerequisites are in place it’s time to look at the actual configuration steps. The following 7 steps walk through the required configuration steps for enabling Azure Active Directory Group Discovery.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services;
2 Select the Cloud Management Azure service and click Properties in the Home tab, to open the Cloud Management Properties dialog box;
CM-AADUGD-Properties
3

CM-AADUGD-CMPropertiesOn the Cloud Management Properties dialog box, select the Discovery tab, select Enable Azure Active Directory Group Discovery and click Settings to open the Azure AD Group Discovery Settings dialog box.

Note: The Settings button will be disabled when Enable Azure Active Directory Group Discovery is not selected.

4

CM-AADUGD-AADGDSOn the Azure AD Group Discovery Settings dialog box, select the Discovery Scopes tab and click Add to open the Select Azure Active Directory Objects dialog box.

Note: Once an Azure AD group is added, it will be shown in the overview of this dialog box.

5

CM-AADUGD-SAADOOn the Select Azure Active Directory Objects dialog box, (optionally add a name in the Name starts with text box) click Search to find the specific Azure AD group(s), select the Azure AD group and click OK.

Important: The search results will show cloud only Azure AD groups for both users and devices. Also, credentials will be requested when searching for Azure AD groups for the first time.

Note: Repeat this step for all applicable Azure AD groups.

6

CM-AADUGD-CMPropertiesPSBack on the Azure AD Group Discovery Settings dialog box, select the Poling Schedule tab. Use this tab to make adjustments to the discovery schedule.

Note: At this moment delta discovery is disabled.

7 Back on the Cloud Management Properties dialog box, click OK.

Note: Keep in mind that this is currently still a preview features.

Administrator experience

Now let’s end this post with the most interesting part, the administrator experience. From an administrative perspective, this configuration introduces at least the following new items.

1 Discovery method: One of the most interesting items is the new Azure Active Directory Group Discovery itself. After the configuration is finished the discovery method can be found by navigating to Administration > Overview > Cloud Services > Azure Services. Selecting the cloud management Azure service, and selecting the Azure Active Directory Group Discovery Agent Type, provides the option Run Full Discovery Now.
CM-AADUGD-Overview
2 Log file: One of the most important items is the log file SMS_AZUREAD_DISCOVERY_AGENT.log. This log files provides the information about the full and delta discoveries of the Azure Active Directory User Discovery and about the full discoveries of the Azure Active Directory Group Discovery (as shown below). The nice part is that the log file also provides information about the Microsoft Graph requests that it uses for the different discoveries.
CM-AADUGD-Log
3 CM-AADUGD-GroupPropCloud-only user groups: The most useful item is the availability of the cloud-only user groups in the on-premises environment. These user groups can be recognized by only having the Agent Name of SMS_AZUREAD_USER_GROUP_DISCOVERY_AGENT (as shown on the right). The availability of the cloud-only user groups in the Configuration Manager environment, and the availability of the new attributes for existing user groups, enables a whole lot of new scenarios. Most of these scenarios are related to co-managing Windows 10 devices with Configuration Manager and Microsoft Intune.
4 Group properties: The overall most interesting, most important and most useful item is the information in the database. The main user group tables and views now contain additional fields for cloud-related information. Some nice information can be found below, were I used a simple query to get some basic information about user groups. That information shows a few important differences with normal user groups. The group contains Azure AD information.
CM-AADUGD-SQL

More information

For more information about the Azure Active Directory Group Discovery, please refer to the Configure Azure Active Directory user group discovery section in the documentation about configuring discovery methods for Configuration Manager

Android Enterprise fully managed devices and the Google Play store

This week another post about an Android Enterprise configuration. Last week was related to company owned single-use (COSU) devices (also known as dedicated devices), while this week is related to company owned business only (COBO) devices (also known as fully managed devices). More specifically, about adding a personal touch to fully managed devices. Microsoft Intune doesn’t know the company owned personally enabled (COPE) devices, yet, but there is a feature within the fully managed devices configuration that can at least enable some more personal options to the user. That can be achieved with a simple configuration to allow access to all apps in the Google Play store. I’ll start this post with the configuration steps (and a little introduction) and I’ll end this post by having a look at the end-user experience.

Configuration

Let’s start with a quick introduction about the setting that should be configured and the impact of that setting. The setting Allow access to all apps in Google Play store must be set to Allow. Once it’s set to Allow, users get access to all apps in Google Play store. Apps can be sort of blocked by the administrator by assigning an uninstall of the apps to the user (or device). That will simply remove the app (over-and-over) again. When it’s set to Not configured, users are forced to only access the apps the administrator makes available (or required) via the Google Play store.

The following 3 steps walk through the process of creating a device restrictions policy that enables access to the Google Play store for users.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

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

  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Select Android Enterprise
  • Profile type: Select Device Owner > Device restrictions
  • Settings: See step 3b
3b On the Device restrictions blade, select Applications to open the Applications blade; and click OK to return to the Add configuration policy blade;
3c On the Applications blade, select Allow with Allow access to all apps in Google Play store and click OK and OK to return to the Create profile blade;
AEFMD-Applications

Note: This profile can be assigned to user and device groups.

End-user experience

Now let’s end this post by having a look at the end-user experience. Depending on the exact configuration the end-user can end up with one of the three scenarios as shown below.

  1. Below on the left is showing the Google Play store for the work account only, without access to all apps in the Google Play store.
  2. Below in the middle is showing the Google Play store for the work account only, with access to all apps in the Google Play store. Even though my store is in Dutch, the number of items in the menu, and the apps shown in the background, show the difference.
  3. Below on the right is showing the Google Play store for the work account when also a personal account is added (see the purple circle with a “P”). It provides the same options as shown in the middle, but also enables the user to switch between accounts.
Screenshot_20190729-172606_Google Play Store Screenshot_20190729-181300_Google Play Store Screenshot_20190724-210437_Google Play Store

The combination for the user to add a personal account to the device and being able to install apps via the Google Play store, will at least give the user some options to personalize the device.

More information

For more information about the device configuration options for Android Enterprise fully managed devices, please refer to the Device owner section in the documentation about Android Enterprise device settings to allow or restrict features using Intune.

Create a custom multi-app kiosk mode

This week is all about creating a custom multi-app kiosk mode for Android Enterprise dedicated devices. The Android Enterprise dedicated device settings also contains multi-app kiosk settings, but in some scenarios those settings can still be a little bit limiting. To create a multi-app kiosk mode, Microsoft Intune relies on the Managed Home Screen app. The fun part is that the Managed Home Screen app already contains a few more settings that are currently only available via app configuration policies. In this post I’ll start with a quick overview of the app configuration options that exist nowadays, followed by showing an app configuration example for the Managed Home Screen app to add a non-Managed Google Play Store app. Technically speaking I’ll add a single app, using the multi-app configuration option. Really adding multiple apps is more of the same. I’ll end this post by showing the end-user experience.

It’s important to keep in mind that the preferred and advised method to configure multi-app kiosk mode settings is still by using the dedicated device settings.

App configuration options

Let’s start this post by having a look at the app configuration options that are available nowadays. In the early days it was still required to manually configure configuration keys and values. These days Intune can prepopulate configuration keys that are available within the Android apps. Below is a quick overview of the 2 app configuration options that are available :

Configuration designer: The Configuration designer can be used to configure simple settings via the UI. It will automatically populate the available configuration keys within the app and allows the administrator to configure the simple configuration values. As long as the value type is not BundleArray
MSH-ConfigurationDesigner
JSON data: The JSON data can be used to configure all settings via a JSON template. The template will automatically populate the available configuration keys within the app and allows the administrator to configure all the configuration values.

MHS-JSONEditor

Configure the Managed Home Screen app

Now the app configuration options are clear. Let’s have a look at the app configuration of the Managed Home Screen app. As an example I want to use a setting that is only configurable via JSON data, as the value type is a BundleArray. That setting is to add (custom non-Managed Google Play Store) apps to the Managed Home Screen app. The following 3 steps walk through the process of creating an app configuration policy that enables the built-in Settings app to the multi-app kiosk mode.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > App configuration policies to open the Client apps – App configuration policies blade;
2 On the Client apps – App configuration policies blade, click Add to open the Add configuration policy blade;
3a

MHS-AddConfigPolicyOn the Add configuration policy blade, provide the following information and click Add;

  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Device enrollment type: Select Managed devices
  • Platform: Select Android
  • Associated app: See step 3b
  • Configuration settings: See step 3c
  • Permissions: See step 3d

Note: The main focus of this post is the configuration around the configuration settings (step 3c). That doesn’t mean that the permission configuration (step 3d) can’t be really useful when the app needs specific permissions. As it’s not the key part of this post, I won’t go into to much details for now.

3b

On the Associated app blade, select Managed Home Screen and click OK to return to the Add configuration policy blade;

Note: When the Managed Home Screen app is not available make sure that that the app is approved and synchronized with Intune.

3c

On the Configuration settings blade, select Enter JSON data with Configuration settings format. Now either click Download JSON template, for offline editing, or use the JSON editor to directly configured the required configuration keys. Before clicking on OK to return to the Add configuration policy blade, go through the following 3 steps (see also the screenshot below):

  1. Navigate to the applications configuration key to add the required apps for the custom multi-app kiosk mode. In my example, I add the Settings app (com.android.settings) to my multi-app kiosk mode. The valueString should be the app package name. To add another app simply copy the complete managedProperty and adjust the valueString.
  2. To be able to save the configuration, make sure to change all the values that need to be configured and still state something like STRING_VALUE. When a setting is not needed it can also be removed.
  3. The red areas on the scrollbar show the locations of values that must be adjusted or removed before the configuration can be saved.

Note: Make sure that the settings in the app configuration policy don’t overlap with settings in the dedicated device configuration.

MHS-JSONEditor-Config
3d On the Permissions blade, click Add to open the Add permissions blade. The Add permissions blade can be used select permissions that should be overridden. Select the required permissions and click OK to return to the Permissions blade and click OK to return to the Add configuration policy blade.

Note: At some point in time these configuration options will probably become available in the multi-app kiosk mode settings for dedicated devices.

End-user experience

Let’s end this post by having a look at the end-user experience. When the device is enrolled and the assigned apps are installed, the device will ask to select a home screen app (the message will actually show after the installation of the Managed Home Screen app). After selecting the Managed Home Screen app, the home screen will show as configured in the app configuration policy.

As shown on the right, I only get the Settings app (Instellingen is the Dutch version of Settings) as app on my home screen. That’s exactly what I wanted. Also, I configured a blue theme and I removed nearly all the other options from the end-user.

Note: The experience might be different from the configuration via the dedicated device settings. The main difference might be that in some cases the end-user might receive a message to configure a home screen app. So make sure to carefully test the end-user experience, to see if it matches the expectations.

Screenshot_20190721-195426

More information

For more information about configuring the Managed Home Screen app, please refer to the documentation about Configure the Microsoft Managed Home Screen app for Android Enterprise .