Deep dive configuring Windows 10 ADMX-backed policies

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.


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
Group Policy English name
Set client connection encryption level
Group Policy English category path
Windows Components\Remote Desktop Services
Group Policy name
Group Policy ADMX file name


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.

1 Open the Group Policy Management Editor and navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security;
2 Right-click the setting Set client connection encryption level and select Edit;

GPO_SetClientConnectionEncryptionLevel_1In the Set client connection encryption level dialog  box, it’s possible to enable and disable the setting. After enabling the setting it shows an advanced setting to configure, the Encryption Level. In this example I want to enable the setting. That means that I need to use <enabled/> as value for my OMA-URI setting. However, as the advanced setting needs an additional data element, I also need to find the appropriate data for that element.

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.

1 Open TerminalServer.admx and navigate to the TS_ENCRYPTION_POLICY policy setting;

TerminalServerADMXThe <elements> section contains the configurable data elements and its possible values. As shown on the right, the configurable data element is named TS_ENCRYPTION_LEVEL and the configurable values are:

3 Open TerminalServer.adml and navigate to the TS_ENCRYPTION_POLICY string;

TerminalServerADMLThe ADML contains the readable string of the display names mentioned in the ADMX. Around the TS_ENCRYPTION_POLICY string I can see the following display names for the previously mentioned values:


GPO_SetClientConnectionEncryptionLevel_2Back to the Set client connection encryption dialog box, I can now translate the available configuration options to values for my OMA-URI setting. When I compare the TerminalServer.admx (and TerminalServer.adml) with the available configuration options, I can translate them like this:

  • Client Compatible = 2;
  • High Level = 3;
  • Low Level = 1.
6 Putting the advanced setting and its available configurations together, gives me the following data element for configuring the Encryption Level to Low Level: <data id=”TS_ENCRYPTION_LEVEL” value=”1″/>;

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″/>.


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.

TerminalServerADMX_Reg TerminalServer_Reg

41 thoughts on “Deep dive configuring Windows 10 ADMX-backed policies”

  1. 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.

  2. 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.

  3. 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: 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?

  4. 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!

  5. 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:

    Thank you!!

  6. 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"/]

  7. 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 [ ] )



    [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

  8. Hi Peter, I am trying to use the Config/Printers/PointAndPrintRestrictions based on the printing.admx like this:

    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,


      • 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,


  9. 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

  10. 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

    Many thanks!

  11. I’ve been reading up various pages from 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

  12. 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


    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.

  13. 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

  14. 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.

  15. hello,
    just watch copy pastes of those speech marks ” ” “, if they lean left or right then you’ll get errors.

  16. 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?



Leave a Reply to RKast Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.