This week another blog post about Windows 10 and OMA-DM, but this week will be short and different. Starting this week I won’t be referring to OMA-DM anymore, instead I’ll be referring to Windows 10 MDM. The main reason for that is change is to align with Microsoft. Also, it simply makes more sense. OMA-DM is the standards based protocol on which the Windows 10 MDM protocol is based. In other words, Windows 10 MDM is not exactly the same as the OMA-DM standards. Technically speaking it’s not wrong to refer to OMA-DM, but it simply makes more sense to refer to Windows 10 MDM.
That being said, this blog post will be different for another reason. This week I’ll try to bring Windows 10 MDM closer to the regular methods, by simply pointing out the existence of the MDM Bridge WMI Provider. This post is all about creating awareness.
MDM Bridge WMI Provider
One of the most heard comments about Windows 10 MDM is related to the lack of knowing what’s happening. Well, I can’t really take that away, maybe the newly introduced logging in 1607 can, but I can show how to see the changes of the Windows 10 MDM configurations.
The MDM Bridge WMI Provider is the bridge to the Windows 10 MDM capabilities. An easy method to see what’s happening is using a WMI Explorer, or something simple as Windows Management Instrumentation Tester (wbemtest). Simply connecting to the root\cimv2\mdm\dmmap namespace is similar to connecting to the MDM Bridge WMI Provider. The classes in this namespace all translate to a configuration service provider (CSP) of Windows 10 MDM. This makes it fairly easy to see what’s happening to the configurations done via Windows 10 MDM.
Below is an example of the MDM_Policy_Result01_Experience02 class, in which the AllowManualMDMUnenrollment instance property was changed during the enrollment of the device. That class and instance property relates to the configuration OMA-URI of ./Vendor/MSFT/Policy/Config/Experience/AllowManualMDMUnenrollment.
Knowing this immediately opens up another world. This enables everyone to get information through the MDM Bridge WMI Provider by simply using PowerShell. Looking at the previous example, I can simply use the following PowerShell command, as there is only one instance, to get the information as shown in the table below.
Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" ` -ClassName "MDM_Policy_Result01_Experience02"
This also means that the MDM Bridge WMI Provider can be used to trigger configuration changes through Windows 10 MDM. For now, I’ll leave that up to everyone’s imagination.
There are a few important notes about the MDM Bridge WMI Provider that should be known and I’ll try to summarize them briefly:
- Administrative permissions are required to connect with the MDM Bridge WMI Provider. Without those permissions there will be an access denied error when connecting to the MDM Bridge WMI Provider;
- The local system context is required to view and adjust device settings. This can be achieved by using something like PsExec.exe;
- Be aware that there is a difference between user settings and device settings. Specific user settings won’t show when connected in the system context and specific device settings won’t show when connected in the user context;
- Be aware that my example mixed Config and Result properties and nodes. That’s related to the design of the Policy CSP. The Config section handles the configurations requests and the Result section provides a read-only path to the actual configuration.
Fore more information about Windows 10 MDM, the Windows 10 CSP and the MDM Bridge WMI Provider, please refer to:
- Mobile device management: https://msdn.microsoft.com/en-us/library/windows/hardware/dn914769(v=vs.85).aspx
- MDM Bridge WMI Provider: https://msdn.microsoft.com/en-us/library/windows/desktop/dn905224%28v=vs.85%29.aspx
- Configuration service provider reference: https://msdn.microsoft.com/en-us/library/windows/hardware/dn920025(v=vs.85).aspx
- Using PowerShell scripting with the WMI Bridge Provider: https://msdn.microsoft.com/en-us/library/windows/hardware/mt614877(v=vs.85).aspx