How to check GPO -> Registry mapping, and what to do if OMA-URIs aren’t enough?


The answer is pretty straightforward. Use PowerShell.

There are some nuances that have to be taken into account though.
First – to ‘mimic’ configuring the setting you would normally do with a specific OMA-URI you need to find its path, expected value, and its data type in the registry.
Second – you need to remember that the tattooing mechanism doesn’t work in this case.

Oliver Kieselbach did a very good job explaining it here: Changed Intune Policy Processing Behavior on Windows 10 – Modern IT – Cloud – Workplace (
In a nutshell – after configuring a setting via either of the available ways in Configuration profiles, this setting, once unassigned should become not configured. This is not the case with PowerShell – once you create a registry key and value, you then manually (probably with another script) have to reset this setting.

Now, why would you even do that? For the majority of the time it’s the fact that there might be a setting that would be configurable if it was a standard GPO management, but unfortunately has not yet been made available in MDM.
Another use case might be that you know a correct OMA-URI, but are unsure about the value, that this setting should be configured with. So, you configure it via GPO, find it in the registry, check the value and then configure the OMA-URI.

How to find a corresponding registry entry to a GPO setting?

Firstly I’d check Group Policy Administrative Templates ( – pretty much everyone knows about this website 🙂 If it’s not there, then…

Download Process Monitor, an app available as part of Sysinternals: Process Monitor – Windows Sysinternals | Microsoft Docs
Open it, select and hit CTRL+L on your keyboard. Add three rows with the information below:

  • Process Name is mmc.exe
  • Process Name is services.exe
  • Operation is RegSetValue
  • Operation is RegCreateKey

Open gpedit.msc (the Local Group Policy Editor), clear display with CTRL+X and find the setting you wish to configure.
Note: Try to keep the display clean just before configuring the policy.

I’ve selected a Devices: Allowed to format and eject removable media as I’ve had some troubles with it while configuring the CIS Benchmark. I knew that it’s available in CSPs, but couldn’t figure the correct value.

Before configuration
After configuration

Now, you can either right-click the entry where the RegSetValue operation was made, click Jump to and you’ll be able to see the data type and value, or you can simply check the Detail column.
In this instance, you can find, that the Administrators and Interactive Users have a value of 2, and surprisingly it’s not an integer like you would probably think but a string.

Visible data type, value and registry path

Having this knowledge is enough to create a PowerShell script that will deploy this setting for us. Although in this instance, this setting is available with CSP (Policy CSP – LocalPoliciesSecurityOptions – Windows Client Management | Microsoft Docs), it makes a good example anyway, because it’s not available in, nor the expected value has been mentioned in the documentation.

To conclude: I find this a really good way to troubleshoot, to find settings that are not that easily available and it allows me to dig a bit deeper and that I really do enjoy 🙂 Moreover, it makes the phrase “no, it’s not possible” a bit obsolete.


Leave a Reply

Your email address will not be published. Required fields are marked *