When discussing MDM, we need to look back in time to understand its origin and some of its limitations. Back in June 2002, the non-profit organization Open Mobile Alliance (OMA) formed (for more information visit http://openmobilealliance.org/about-omawas). The OMA Device Management (OMA DM) specification was originally designed for the management of mobile devices like mobile phones, tablets, and PDAs (for more information visit http://openmobilealliance.org/about-oma/work-program/device-management). It was intended to provision and configure devices and enable software updates and fault management. There is a fixed set of OMA DM protocol commands all vendors support. Currently, Windows 10 1607 and higher supports MDM protocol version 6.0 (for more information visit https://msdn.microsoft.com/en-us/library/dn392112.aspx).

MDM configuration objects are stored in a so called OMA Uniform Resource Identifier (OMA URI) (for more information visit https://www.ietf.org/rfc/rfc3986.txt). You will need this OMA URI to add custom policies to your MDM solution if the setting is not available out-of-the-box. You can compare the use of such a custom URI as similar to writing your own custom ADMX templates. Like custom ADMX files need to write a supported registry key, the OMA URI needs to modify a supported resource identifier with a configuration service provider (CSP) capable of interpreting and applying the URI. Custom URIs can be added to Intune easily. Select Windows Custom Policy and fill out the Add or edit OMA-URI Setting box. Here is an example of the dialog box:

A list of all available CSPs in Windows 10 and their respective OMA URIs can be found at https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/configuration-service-provider-reference.

Every new release of Windows 10 brings new capabilities to MDM CSPs. An always updated TechNet article can be found at https://msdn.microsoft.com/en-us/windows/hardware/commercialize/customize/mdm/new-in-windows-mdm-enrollment-management#whatsnew10.

The following diagram shows as an example the BitLocker configuration service provider in tree format. As you can see from ./Device/Vendor/MSFT, it is a URI only applicable to Microsoft products:

When configuring this CSP, a Synchronization Markup Language (SyncML) XML is generated and transmitted. Here is a (partial) sample of such a SyncML BitLocker XML:

As OMA DMs and OMA URIs originate from mobile device management, the design of these URIs favor integer values for their settings, which is quite alright for the OS but a bit uncomfortable for human readability. Therefore you will need the corresponding CSP pages for translation very often. Here is an example of the possible BitLocker Encryption type values:

Another thing to note when displaying MDM settings on your client is that there is currently no comparable tool like GPRESULT.exe built in into Windows 10. You can get all applied settings by reading the registry but you will just see a long list of values and not the originator of the value. Use the following PowerShell command line for reading the registry:

get-item 'HKLM:\Software\Microsoft\PolicyManager\current\device\*'

A resultant set of policies, like a log file, can be exported in the system settings. Go to Settings | Accounts | Access work or school | Export your management log files:

Unfortunately, this file is in plain XML style, which is hard to read. So you will need a converter, which is currently not built-in into Windows 10. You can find such a Device Management Log XML to HTML Converter at https://gallery.technet.microsoft.com/scriptcenter/Device-Management-Log-XML-aa3bf9d4.

MDM policies are applied on a fixed schedule. When joining/enrolling a Windows PC to your MDM solution, it will check for new policies every 3 minutes for 30 minutes and then runs at its normal frequency of checking every eight hours (eight hours for Windows mobile and Windows 10 desktop, 24 hours for Windows RT).

Last but not least, there is some added complexity due to the several origins of MDM settings in Windows 10. Besides the built-in MDM client, which can be connected to for instance Intune, AirWatch, or MobileIron, MDM settings can be induced by Exchange ActiveSync settings, the built-in EAS client, and the built-in WMI bridge used by SCCM, or Windows PowerShell:

Depending on whether the MDM setting is a security setting or non-security, there are different override rules when applying them to a client. For security-related settings, the most restrictive setting will always win. For non-security settings, the base settings are Microsoft, OEM, or enterprise-created PPKG packages. They will be overridden by EAS and MDM clients, and at the topmost priority is GPO (if the setting is also configured by GPO). Without using XML log troubleshooting, MDM settings are very hard and time consuming.

On GitHub, you will also find a tool to convert existing GPOs to new MDM settings: https://github.com/WindowsDeviceManagement/MMAT.