A couple of weeks ago, I did a my blog post about configuring a Windows 10 ADMX-backed policy. That time I used a relatively easy setting to configure and I briefly mentioned how to configure a more advanced setting. That raised some questions, which triggered me to do a deep dive in configuring those more advanced settings. In this blog post I’ll show, in a step-by-step overview, how to construct the OMA-URI setting and value for a more advanced setting.
Setting
I’ll use the ClientConnectionEncryptionLevel setting as an example again. A big difference with the previous time is that the docs are greatly improved. By default, the docs now already provide information about the corresponding Group Policy setting and the location of the Group Policy setting. The docs already provide the following information about the settings.
MDM CSP setting path/ name RemoteDesktopServices\ClientConnectionEncryptionLevel |
Group Policy English name Set client connection encryption level |
Group Policy English category path Windows Components\Remote Desktop Services |
Group Policy name TS_ENCRYPTION_POLICY |
Group Policy ADMX file name terminalserver.admx |
Value
The default information in the docs make it relatively easy to find the required setting and it’s basic values. Now let’s go through the steps to find all the required information for more advanced settings. A more advanced setting, to me, is a setting that must be enabled and requires additional data.
Step 1: Enable the setting
Let’s start with the first step, which is enabling the setting. The following steps will go through the steps to find the Group Policy setting and enabling it.
Step 2: Configure the setting
The next step is the advanced configuration of the Group Policy setting. The following steps will go through finding the available values and how those values can be used in a OMA-URI setting.
Step 3: Complete setting
Now I can put step 1 and step 2 together and enable the setting and configure the required additional configuration. When I want to enable Set client connection encryption level and set the Encryption Level to Low Level, I can use the following value for the OMA-URI setting: <enabled/><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>.
Result
Let’s have a look at the result, when I’m configuring the following OMA-URI setting:
- OMA-URI: ./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/ClientConnectionEncryptionLevel
- Date type: String
- Value: <enabled/><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>
As I’m basically configuring Group Policy settings, the best place to look for a successful configuration is the registry. Below on the left is another look at the TerminalServer.admx in which I show the registry key that will be configured. On the right I show the configured registry key and it’s value.
Thanks, very interesting article. Is it possible to configure any ADMX policies this way?
And does the below Microsoft comment mean that we can configure also ADMX policies that are not by default available in Windows 10 by first using /ADMXInstall policy CSP to ingest it?
“An ADMX file can either be shipped with Windows (located at %SystemRoot%\policydefinitions) or it can be ingested to a device through the Policy CSP URI (./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall)”
At this moment not all the standard ADMX policies are available for configuration via MDM.
I haven’t tested third-party ADMX templates, yet, but you should be able to do some configurations with that.
Thanks for this detailed blog post on this ‘obscure” configuration item in Intune. Many information is lacking on technet on this. One question I have is I see you use ‘./Device/Vendor/MSFT/Policy’ I assume the ./Device/ is for computer policy and if we want to apply a CSP to users we need ./User/ this is not documented anywhere unfortunately.
Often that’s an correct assumption. However, not every setting is available for configuration for users and devices. In general that’s good documented.
Awesome post, thank you. I’ve been playing around with this and if wondered if you or anyone else have tried to set a setting back to “Not Configured” ? According to: https://docs.microsoft.com/en-us/windows/client-management/mdm/understanding-admx-backed-policies the payload should be “(None)”. To test this I’ve tried to just remove from the compliance rule in the CI, I’ve also tried to just disable the configuration baseline and manually sync – but it doesn’t seem to revert it back (so that the setting is not grayed out). I’ve been testing this with the “AllowUsersToConnectRemotely” setting for the time being, any ideas?
I would say, setting the value to *blank* should be similar to (None).
A lot of what’s discussed is the “Policy CSP,” but is it also true that other CSPs are now exposed by the same method? For example, Personalization, Storage, WiFi, and so on via their own CSPs? In those cases would we use a different OMA-URI path, such as “./Vendor/MSFT/WiFi/” (substituting WiFi for Policy)?
Thank you!
Some are and some can be used just like the Policy CSP. I’ve got some examples, like using the Personalization CSP on my blog.
Would you please be able to do an article on third-party ADMX so that we can get a good understanding of how to ingest ADMX templates for other apps and centrally manage things such as browser configurations?
This has suddenly become super-relevant with the Meltdown and Spectre vulnerabilities just disclosed; for example: https://support.google.com/chrome/a/answer/7581529
Thank you!!
Thank you for the suggestion, Jim! I’ll put the idea on my list (no promises if and when it will happen).
Peter,
Is the below oma-uri correct ?
In the Intune portal i see ‘pending’ status for a lot of devices for some weeks now.
Autoplay/TurnOffAutoPlay
https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-autoplay#autoplay-turnoffautoplay
OMA-URI
./Device/Vendor/MSFT/Policy/Config/Autoplay/TurnOffAutoPlay
DATA TYPE
String
VALUE
Hi RKast,
It looks OK, just wondering what value you are using as it’s missing from your post.
Regards, Peter
Hi Peter,
Your blog comment section screws up the comment 🙁
Hopefully changing the < brackets to [ bracket will work.
the VALUE i used is:
[enabled/][data id="Autorun_Box" value="255"/]
Hi RKast,
Yes, that looks correct!
Regards, Peter
Hi Peter,
I was testing this with an example policy in the TerminalServer.admx file.
I want to set the policy “Specify SHA1 thumbprints of certificates representing trusted .rdp publishers”
Can you please check if both OMA-URI are correct ? (fyi i changed brackets to [ ] )
./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/RDS/Policy/TerminalServer
./user/Vendor/MSFT/Policy/Config/RDS~Policy~TS_GP_NODE~TS_CLIENT/TS_CLIENT_TRUSTED_CERTIFICATE_THUMBPRINTS_2
[enabled/]
[data id=”TRUSTED_CERTIFICATE_THUMBPRINTS” value=”00 11 22 33 44 55 66 77″/]
PS. i know ingesting policies are not allowed to write to locations software\policies\windows nt where the above policy writes but i want to know how derive such policy
Hi RKast,
Yes, that seems to be correct.
Regards, Peter
Hi Peter, I am trying to use the Config/Printers/PointAndPrintRestrictions based on the printing.admx like this: https://i.imgur.com/TOVWwvB.png
But this fails as event viewer tells me:
MDM ConfigurationManager: Command failure status. Configuration Source ID: (2C23D2DE-9919-48BF-96FC-5ECA51157EC7), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (Policy), Command Type: (Add: from Replace or Add), CSP URI: (./Device/Vendor/MSFT/Policy/Config/Printers/PointAndPrintRestrictions), Result: (Catastrophic failure).
MDM PolicyManager: Set policy string, Policy: (PointAndPrintRestrictions), Area: (Printers), EnrollmentID requesting set: (2C23D2DE-9919-48BF-96FC-5ECA51157EC7), Current User: (Device), String: (), Enrollment Type: (0x6), Scope: (0x0), Result:(0x8000FFFF) Catastrophic failure.
Do you have an idea on why this is failing?
Best regards,
Coert
Hi Coert,
I had a quick look at the config and it looks OK. Do you see any other failures in the event viewer related to printers (in the application log)?
Regards, Peter
Hi Peter, thanks for checking.
I contacted technical support and they found the error. Even though you don’t use the option, it is required to set [data id=”PointAndPrint_TrustedForest_Chk” value=”false” /] as well. Also changed [data id=”PointAndPrint_TrustedServers_Chk” value=”1 /] to [data id=”PointAndPrint_TrustedServers_Chk” value=”true” /] as the ADMX uses [enabledValue]s. It’s now working.
Best regards,
Coert
Little note, changed “1” to “True” because of [trueValue], not [enabledValue] as mentioned before
Thank you for the update, Coert!
Refer to the security baseline policy available and apply it to a users group. OMA-URI is the thing of the past to a large extent.
Hi Guarav,
Keep in mind that 1) this post is over two years old and yes a lot has changed in that time and 2) this post is used to provide an example of how ADMX-backed policies work and not to configure a specific settings.
Regards, Peter
What is not clear to me, do i need to include the ADMX file in the settings?
I ask, because this policy never deploys, just stays in pending state:
OMA-URI ./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/AllowUsersToConnectRemotely
Data Type STRING
Value
Many thanks!
Hi Jimmy,
No you don’t need to include the ADMX for ADMX-backed policies. What is the value that you’re using?
Regards, Peter
I’ve been reading up various pages from docs.microsoft.com to understand ADMX-backed policies (I still don’t know what “backed” means here. It is just meaning ADMX-based ?) and how they correspond to OMA-URIs when trying to establish configuration profiles from Intune MDM.
For the life of me I’ve yet to find any document that mentions how to _map_ OMA-URIs to the actual ADMX registry key paths. They may look similar to human eyes, but how does the OS know this? How do I see custom 3rd-backup ADMX declarations and determine the correct LocURI (that’s the OMA-URI, yes?) to target? They never appear to be the same.
Like how does ./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/ClientConnectionEncryptionLevel actually find its way to HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\MinEncryptionLevel ? This might seemed assured for pre-established OS components policies, but for 3rd-party programs and settings, it looks like a big guessing game.
Hi Aaron,
ADMX-backed policies are OMA-URIs that use actual ADMX policies to perform the configuration. That also means that the actual registry path and configuration in the ADMX is used to perform the configuration. The same applies for third-party ADMX policies. After ingesting the ADMX, the settings can be used for the configuration (see for an example this post).
Regards, Peter
When I inspect the TerminalServer.admx and TerminalServer.adml files, what I traced through out of them are that TS_ENCRYPTION_POLICY\TS_ENCRYPTION_LEVEL – with a Registry key value at HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\MinEncryptionLevel – has _only_ a _Group Policy administrative template path_ of
windows:WindowsComponents\TS_GP_NODE\TS_TERMINAL_SERVER\TS_SECURITY\TS_ENCRYPTION_POLICY
which translates to
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security\Set client connection encryption level
That is fine when I’m just using GP editor to edit my local configuration. But, I don’t see any space-less “RemoteDesktopServices” or “ClientConnectionEncryptionLevel” pathing from the OMA URI declared anywhere in those files; thus the mapping procedure is lost to me.
Ok on reviewing the documentation again, it appears the “magic mapping” happens because Windows has an _internal manifest_ (compiled during build time) letting it know which OMA URI represents which relevant Registry key path. But those are for well-known Windows components. 3rd-party ADMX ingestions for custom software aren’t explained how to map their OMA URIs.
Hi Aaron,
That is correct. Regarding the mapping of the third-party ADMX settings, please have a look at my other post that I mentioned. In that post I explain how to create a OMA-URI that maps to a specific settings in the ADMX file.
Regards, Peter
Yea the differences for OMA URIs between Windows components AT versus custom 3rd-party ATs was very confusing and pulled the rug under my feet; I was wasting so much reading and comparing various 1st-party and 3rd-party .admx and .adml files trying to figure out how the mapping happens. Even the official docs have inconsistent formatting with regular slash / and black-slash \ segmentation.
https://docs.microsoft.com/en-us/windows/client-management/mdm/understanding-admx-backed-policies
Hi Aaron,
Yes, it can be challenging to work with administrative templates. Did you now manage to get it all to work?
Regards, Peter
Yes once I was able to differentiate between 1st-party and 3rd-party formats, I was able to apply the custom configuration profiles. Thanks.
Great! Glad you figured out the differences and how to work with the different formats.
Regards, Peter
hello,
just watch copy pastes of those speech marks ” ” “, if they lean left or right then you’ll get errors.
That’s correct, James!
oops – of course, right after posting a question here, I found the problem after saving the text string as an .xml file and trying to use that. Intune quickly found the quotes that were malformed from copying and pasting the string above. Once I fixed the quotes and re-entered the string, this particular policy showed successful in Intune. Still need to validate that encryption is actually being enforced.
That is good to hear Dan!
Hi, coincidentally, I am trying to enable exactly the encryption policy you are demonstrating with but it is failing remediation in Intune.
./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/AllowUsersToConnectRemotely with as the string data seems to work but
./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/ClientConnectionEncryptionLevel with
does not. I’m getting -2016281112 (Remediation failed) 0x87d1fde8
any ideas what might be happening here or where to look?
thanks,
Dan