Easily track Windows 10 Intune MDM policy information on the Endpoint – Support Help #1

Hi and welcome to today’s post titled “Easily track Windows 10 Intune MDM policy information on the Endpoint – Support Help #1“

This is a continuation from my previous post titled Windows 10 MDM Log Checklist – Ultimate Help Guide for ITPro #1 where I have shown the different methods available for collecting MDM logs from an Intune managed Windows 10 endpoint.

Today we will try and go a level higher. This post is all about how as an IT Pro, you can get the information you require while troubleshooting an issue related to a config policy with an Intune managed Windows 10 endpoint from the Windows Registry and Events.

So let’s jump straight into the content.

Getting Started

When a device is enrolled in Intune, as part of the Device preparation phase of ESP, the 4th task is actually when Intune bootstraps the OMADM client of the device and sets itself up as a Provider for Enterprise Management.

Event 16 DeviceManagement-Enterprise-Diagnostics-Provider
MDM Enroll: OMA-DM client configuration succeeds.
 
Event 58 DeviceManagement-Enterprise-Diagnostics-Provider
MDM Enroll: Provisioning succeeded.

Bootstrapping the DM client of the device by Intune is a way of Intune telling the device

I am your Management Server and you would be talking to me only to check and get enterprise policies.

If you have PS scripts, win32 apps, or Remediation Scripts deployed, then the IME agent (an MSI app) also gets installed at this time, sets itself up as another Provider, takes its time to initialize the agent, and get the sidecar apps and policies from the service which it needs to track in the next stages of ESP.

Keeping aside Intune Sidecar, the communication between Intune (MS DM Server) and the Windows 10 endpoint (DM Client of the device) is in the form of SyncML commands. The DM Client post receiving the SyncML instruction (DM message) from Intune, parses the instruction to know which Configuration Service Provider to invoke to get the command/instruction executed.

While the particular CSP invoked by the DM client processes the settings to be implemented, those are first saved to the below reg_path under the Category area to which the settings belong.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers\{Provider GUID}\default\Device

All the config policies coming down from Intune get tagged to the Provider GUID which corresponds to the Intune Enrollment ID on the endpoint.

Once the CSP succeeds in implementing the settings, those get reflected the reg_path under the Category area to which the settings belong to.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device

Provider GUID is unique for each device of the same tenant. But as you can see, there will be several GUIDS under HKLM\Software\Microsoft\PolicyManager\Providers, so how you can easily determine which one corresponds to Intune?

Finding the Provider GUID

The easy way, go to the location C:\ProgramData\Microsoft\DMClient and note the folder name <GUID> you will find it there.

Or you can also open Task Scheduler and navigate to Microsoft > Windows > EnterpriseMgmt and note the <GUID>

This GUID is the current valid Enrollment ID that you need to look for in the registry under reg_path HKLM\Software\Microsoft\PolicyManager\Providers which would correspond to Intune.

You can also confirm the Provider GUID for the current Intune enrollment from the registry itself, by checking the reg_path as shown below.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked\<GUID>

Or, from the below reg_paths as well

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\<GUID>
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\Logger\<GUID>
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\Sessions\<GUID>

All these points to the current Intune Enrollment ID which will be the Provider GUID which corresponds to Intune under reg_path

HKEY_Local_Machine\Software\Microsoft\PolicyManager\Providers

Now that you know all the ways how you can figure out the current Enrollment ID or Provider GUID which corresponds to Intune, let’s continue with how you can get the information of config policies being enforced by Intune using the Windows Events and Registry.

Retrieve Windows 10 Intune MDM policy details from Registry and Events

Example 1

Consider I have a policy configured to block Automatic Device Encryption which is a Windows 10 Device restrictions policy assigned and deployed.

This is how Intune sends the instruction to the endpoint which is received by the DM client.

<Add>
      <CmdID>9</CmdID>
      <Item>
        <Target>
          <LocURI> ./Device/Vendor/MSFT/Policy/Config/Security/PreventAutomaticDeviceEncryptionForAzureADJoinedDevices</LocURI>
        </Target>
        <Meta>
          <A:Format>int</A:Format>
          <A:Type>text/plain</A:Type>
        </Meta>
        <Data>1</Data>
      </Item>
</Add>

The above can be seen via the SyncML Viewer tool made by Oliver Kieselbach.

From this we can see, post parsing the command, the DM Client will invoke Policy CSP which would then be responsible for implementing the settings.

DM Client knows which CSP to invoke to get the instruction executed by reading the <LocURI></LocURI> section of the message.

This is how it reflects in the Windows 10 Event Viewer

Source: DeviceManagement-Enterprise-Diagnostics-Provider events

As explained above, the policy information will first be saved to reg_path under the category node that the feature settings belong to.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers\{Provider GUID}\default\Device

Once the CSP succeeds in implementing the policy settings, the same gets mirrored to the reg_path

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device

I noticed that registry shows the Provider source for the settings on a Windows 10 2004 system however I have not seen it with versions 1909 and earlier.

If the CSP encountered an error in implementing the policy settings, you would have an error event for the policy.

Similarly, you can track any policy that you are pushing from Intune as shown above.

Example 2

I have configured and deployed a normal device restrictions profile to manage Windows Spotlight settings. The policy is received by the device and can be confirmed from the registry which shows the settings being applied.

And then finally here

But this policy actually reported in a Failed state in Intune.

So what went wrong here?

Checking in the Windows Events, we see the below error events for the corresponding policy.

Event 404 DeviceManagement-Enterprise-Diagnostics-Provider events
 
MDM ConfigurationManager: Command failure status. Configuration Source ID: (C29B03B7-BA09-488C-AC62-9528A4E7E221), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (Policy), Command Type: (Add: from Replace or Add), CSP URI: (./User/Vendor/MSFT/Policy/Config/Experience/AllowWindowsSpotlight), Result: (Unknown Win32 Error code: 0x82b00006).
 
Event 809 DeviceManagement-Enterprise-Diagnostics-Provider events
 
MDM PolicyManager: Set policy int, Policy: (AllowWindowsSpotlight), Area: (Experience), EnrollmentID requesting set: (C29B03B7-BA09-488C-AC62-9528A4E7E221), Current User: (S-1-12-1-3546063745-1309206162-2641703837-3589660599), Int: (0x0), Enrollment Type: (0x6), Scope: (0x1), Result:(0x82B00006) Unknown Win32 Error code: 0x82b00006.
 
Event 827 DeviceManagement-Enterprise-Diagnostics-Provider events
 
MDM PolicyManager: Policy is rejected by licensing, Policy: (AllowWindowsSpotlight), Area: (Experience), Result:(0x82B00006) Unknown Win32 Error code: 0x82b00006.

The first two error events did not help in getting to know the reason for failure, but the 3rd event (827) did tell us why the policy failed. The policy is rejected by licensing.

Here licensing is referring to the Windows 10 SKU. The test device was running Windows 10 Pro, whereas enterprise management of Windows Spotlight settings is supported for Windows 10 Enterprise and Education SKU only.

A good reason why we should first check the applicability of a particular feature or settings to the platform we are trying to implement the same.

This is just an example of how you can track data for troubleshooting Intune MDM issues with Windows 10.

As an Intune Admin or an IT Pro, you should always be looking at reg_path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager for the MDM policy information as pushed down by Intune.

The End

You can understand that it is really not possible to cover information related to each and every specific policy deployment from Intune individually.

But I hope, by reading this, you as an IT Pro will have a better understanding of how to approach troubleshooting policy deployment failures with your Intune managed Windows 10 endpoints.

That was all for today.

You might also find the below articles of interest.

1. Intune Policy Processing on Windows 10 explained
2. Troubleshoot policies in Microsoft Intune
3. How to Troubleshoot Windows 10 Intune MDM Issues