Hi, and welcome to today’s post, “Easily Track Windows 10 Intune MDM Policy Information on the Endpoint – Support Help #1.”
This is a continuation of my previous post, Windows 10 MDM Log Checklist —Ultimate Help Guide for ITPro #1, in which I showed the different methods available for collecting MDM logs from an Intune-managed Windows 10 endpoint.
Today, we will try to 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.
Administrators can remotely configure settings, enforce security measures, and efficiently manage device applications by utilising MDM policies. The built-in support for Windows 10 and 11 MDM policies enables seamless integration with various MDM solutions, ensuring a robust and constructive management approach.
So, let’s jump straight into the content.
Index |
---|
Device Preparation |
Finding the Provider GUID |
Retrieve Windows 10 Intune MDM policy details from Registry and Events |
The End – Easily track Windows 10 Intune MDM policy information on the Endpoint |
- Microsoft Introduces New Windows Enrollment Attestation Feature in Intune
- Allow Upload Of User Activities Policy Using Intune
- Intune MDM Enrollment Error Code 80180005
- Fix MDM Authentication Error Code 80180002
Device Preparation
When a device is enrolled in Intune as part of the Device preparation phase of ESP, the fourth task is when Intune bootstraps the device’s OMADM client 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 for Intune to tell 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) is also installed at this time. It sets itself up as another Provider, takes its time to initialize the agent, and gets the sidecar apps and policies from the service that it needs to track in the next stages of ESP.
Keeping aside Intune Sidecar, SyncML commands communicate between Intune (MS DM Server) and the Windows 10 endpoint (DM Client of the device). After receiving the SyncML instruction (DM message) from Intune, the DM Client parses the instruction to know which Configuration Service Provider to invoke to execute the command/instruction.
While the particular CSP invoked by the DM client processes the settings to be implemented, those are first saved 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 corresponding to the Intune Enrollment ID on the Endpoint.
Once the CSP succeeds in implementing the settings, those get reflected in the reg_path under the Category Area to which the settings belong.
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 GUIDEs under HKLM\Software\Microsoft\PolicyManager\Providers, How
can you quickly determine which one corresponds to Intune?
Finding the Provider GUID
The easy way is to go to the location C:\ProgramData\Microsoft\DMClient and note the folder name <GUID>. You will find it there.
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>
Easily Troubleshoot Windows 10 Intune MDM Policies – Locating the current Enrollment ID – Way 3 using Registry. [NOTE: This is not the Intune Device ID)
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 that corresponds to Intune under reg_path
HKEY_Local_Machine\Software\Microsoft\PolicyManager\Providers
Now that you know how to figure out the current Enrollment ID or Provider GUID corresponding to Intune, let’s continue with how to get information about config policies being enforced by Intune using Windows Events and Registry.
Retrieve Windows 10 Intune MDM Policy Details from Registry and Events
Example 1
I have a policy configured to block Automatic Device Encryption, a Windows 10 Device restrictions policy that has been assigned and deployed.
This is how Intune sends the instructions to the Endpoint the DM client receives.
<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 execute the instruction by reading the message’s <LocURI></LocURI> section.
This is how it is reflected in the Windows 10 Event Viewer
Source: DeviceManagement-Enterprise-Diagnostics-Provider events
DeviceManagement-Enterprise-Diagnostics-Provider events should be your primary source to start digging for information related to MDM policy deployments and their outcomes.
As explained above, the policy information will first be saved to reg_path
, under the category node to which the feature settings belong.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers\{Provider GUID}\default\Device
HKLM\SOFTWARE\MICROSOFT\POLICYMANAGER\PROVIDER\{PROVIDER GUID\default\Device will be the place to look for in the Registry to check if Intune delivered the policy settings as-is configured.
Once the CSP succeeds in implementing the policy settings, the same gets mirrored in the reg_path
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device
HKLM\SOFTWARE\MICROSOFT\POLICYMANAGER\current\Device\ will be the place to look for in the Registry to check if the system succeeded in implementing the policy settings with the value as was configured.
I noticed that the 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 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 device has received the policy and can be verified in the Registry, which displays the applied settings.
HKLM\SOFTWARE\MICROSOFT\POLICYMANAGER\PROVIDER\{PROVIDER GUID\default\Device\ shows that Intune delivered the policy settings as-is configured.
And then, finally, here
HKLM\SOFTWARE\MICROSOFT\POLICYMANAGER\Current\Device\ shows that the system implemented the policy settings as-is configured.
However, this policy was reported as having failed in Intune.
The policy status is in error through policy settings implemented in the Registry.
So what went wrong here?
When checking the Windows Events, we see the error events below 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 us understand the reason for failure, but the third event (827) did tell us why the policy failed: licensing rejected it.
Here, licensing is referring to the Windows 10 SKU. The test device ran Windows 10 Pro, whereas enterprise management of Windows Spotlight settings is supported only for Windows 10 Enterprise and Education SKUs.
A good reason we should first check the applicability of a particular feature or settings to the platform we are trying to implement is 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. Intune pushed down the MDM policy information.
The End – Easily track Windows 10 Intune MDM policy information on the Endpoint
You can understand that it is impossible to cover information related to each specific policy deployment from Intune individually.
As an IT pro, I hope you will better understand how to troubleshoot policy deployment failures with your Intune-managed Windows 10 endpoints by reading this.
That was all for today.
You might also find the articles of interest below.
- Intune Policy Processing on Windows 10 Explained
- Troubleshoot policies in Microsoft Intune
- How to Troubleshoot Windows 10 Intune MDM Issues
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost five years of experience working with Microsft Intune. He is currently working as a senior consultant and architect at Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He was awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his blog site, MDM Tech Space, at https://joymalya.com
Hola!
Any clue on how to do it the other way around?
Have a DeviceLock Policy on the registry HKLM\SOFTWARE\MICROSOFT\POLICYMANAGER\PROVIDER\{PROVIDER GUID\default\Device\DeviceLock.
I would like to know which specific Configuration Policy is sending the policies reflected in that Reg Path.
Thanks for any feedback and/or comments.
I’m also looking to know which specific Configuration Policy is sending the policies reflected in that Reg Path. a
Me too please. Ex husband is stalking me and controlling my devices via MDM.
Is there a way to remove its privileges…for good? Please. I’ve had to reformat THREE times already. I do Not want to do it again.