Manage Group Policy with ADMX

Good is never good enough.  Ok, so you found a way to install that application across 2000 workstations in the blink of an eye.  Good!  Think you can go home now?  Think again.  There is one crucial setting on that application for which the default simply won’t do for 50-100% of your users.  Now that you can install it, you have to be able to customize it.  Or maybe there is a widget already installed on the computers that needs to be adjusted, or there is some aspect of the user environment that needs to be controlled.  Being able to fine-tune the user experience is the next level of network administration.

If you installed the application with an MSI, you can fire up ORCA and you may just be able to find a property somewhere in the file that will enable you to toggle the setting.  Sometimes.  This frequently works for things like forcing the application to install for All Users, disabling the creation of shortcuts, or surpressing the EULA.  But there are a lot of settings you won’t find.  In those cases, you will probably want to edit the registry.  Are you going to do that manually on 2000 machines?  Worse yet, what if it is a per-user setting?  Are you going to follow your users around and edit the registry on any computer they log into?

Fortunately, you are a network god!  You could solve this problem with a batch or vbs script that runs at computer startup or login.  However, Microsoft has provided an even more elegant solution for changing the way that Windows and installed applications function:  ADMX files.

ADMX files allow you to extend the functionality of Group Policy and control settings that Microsoft didn’t build in, generally because your environment is non-standard.  You have a widget that not everyone has, and so Group Policy has no provision for controlling that widget’s settings.

Take Adobe Acrobat X as an example.  As discussed in another post, Adobe has included some nice customization options, but they do not include the ability to disable Protected Mode.  If you need to do so, you are going to have to resort to modifying the registry.  This is a perfect use for ADMX.  If you are already using Group Policy to deploy the application, you can even use the same Group Policy to change the Protected Mode per-user setting, making the entire installation process nice and tidy.

First, lets take a look at the files involved:


<?xml version=”1.0″ encoding=”utf-8″?>
<!– Created by Jay P Morgan – Morgan IT –>
<policyDefinitions xmlns:xsd=”
  revision=”1.0″ schemaVersion=”1.0″
    <target prefix=”mit” namespace=”mit.Policies.custom” />
  <resources minRequiredRevision=”1.0″ />
    <category name=”MIT”
              explainText=”$(string.MIT_Help)” />


<?xml version=”1.0″ encoding=”utf-8″?>
<!– Created by Jay P Morgan – Morgan IT –>
<policyDefinitions xmlns:xsd=”” xmlns:xsi=”” revision=”0.9″ schemaVersion=”1.0″ xmlns=”“>
    <target prefix=”Reader_DisableProtected” namespace=”Adobe.Policies.Reader_DisableProtected” />
    <using prefix=”mit” namespace=”mit.Policies.custom” />
  <resources minRequiredRevision=”1.0″ fallbackCulture=”uz-UZ-Cyrl”/>
      <definition name=”SUPPORTED_ProductOnly” displayName=”$(string.SUPPORTED_ProductOnly)”/>
    <category name=”ADOBEREADERX” displayName=”$(string.ADOBEREADERX)” explainText=”$(string.ADOBEREADERXHELP)”> 
       <!– Adobe Reader X category –>
       <parentCategory ref=”mit:MIT” />
       <seeAlso> policy </seeAlso>
       <keywords> custom </keywords>
    <policy name=”ADOBEREADERX_NoParamPolicy” displayName=”$(string.ADOBEREADERX_NoParamPolicy)” explainText=”$(string.ADOBEREADERX_NoParamPolicy_Help)” key=”Software\Adobe\Acrobat Reader\10.0\Privileged” valueName=”bProtectedMode”>
      <parentCategory ref=”ADOBEREADERX” />
      <supportedOn ref=”SUPPORTED_ProductOnly” />
        <decimal value=”1″ />
        <decimal value=”0″ />


<?xml version=”1.0″ encoding=”utf-8″?>
<!– Created by Jay P Morgan – Morgan IT –>
<policyDefinitionResources xmlns:xsd=”
   revision=”1.0″ schemaVersion=”1.0″>
  <displayName>BGISD base file</displayName>
  <description>This file contains the Morgan IT parent category.
      <string id=”MIT”>MIT Custom</string>
      <string id=”MIT_Help”>Contains Morgan IT custom configuration settings.</string>


<?xml version=”1.0″ encoding=”utf-8″?>
<!– Created by Jay P Morgan – Morgan IT –>
<policyDefinitionResources xmlns:xsd=”” xmlns:xsi=”” revision=”1.0″ schemaVersion=”1.0″ xmlns=”“>
  <displayName>Disable Adobe Reader X Protected Mode</displayName>
  <description>enter description here</description>
      <string id=”ADOBEREADERX”>Adobe Reader X</string>
      <string id=”ADOBEREADERX_NoParamPolicy”>Protected Mode</string>
      <string id=”ADOBEREADERX_NoParamPolicy_Help”>This Group Policy Setting will enable/disable Protected Mode.If you enable this setting, the bProtectedMode value will be set to 1. If you disable this setting, the bProtectedMode will be set to 0.

 Unverified –> If you do not configure this setting, the value will be deleted, if currently set to a value, enabling Protected Mode (the default setting).</string>
      <string id=”ADOBEREADERXHELP”>Adobe Reader X

This will be displayed as both a machine and user policy setting.</string>
      <string id=”SUPPORTED_ProductOnly”>Adobe Reader X</string>

The .admx files get placed on the Domain Controller or in the C:\Windows\PolicyDefinitions folder of the machine(s) from which the group policy will be edited.  The .adml files go in C:\Windows\PolicyDefinitions\en-US (for English-language installations) or the apropriate sub-folder for your language.

First off, while both files are needed, the real work is done in the ADMX files.  The ADML files are only there for display purposes.  For each variable or string in the ADMX file, there is a related definition in the ADML, stating what that string should display in the console.  For instance, for the category name ( line 15 ) ADOBEREADERX in AdobeReaderX.admx, the ADML file states ( line 8 ) that this string should display “Adobe Reader X” in our language.

In truth, this could be done with only two files; one .admx and one .adml.  However, we have followed the Microsoft best-practice of creating a root, or base admx file – MIT.*.  All future admx files we create will reference this base, and thus will appear under our MIT node in the Group Policy Editor.  So, in reality, all MIT.admx and MIT.adml do is create a node under which we can put all of our actual custom settings, such as those referenced in the AdobeReaderX files.  You can see where we created this connection in line 9 of the AdobeReaderX.admx file, with the “using” statement.

The rest is pretty straightforward, at least to get down the basics.  These files are completely functional as is, so as a test, you could place them in the appropriate locations on the hard drive, and fire up the Group Policy Management Console, to see the setting in action!

Here is what it should look like:

~ by Jay P Morgan on February 9, 2011.

One Response to “Manage Group Policy with ADMX”

  1. […] One thing that was missing, however, from an otherwise nice and quite comprehensive customization tool is the ability to disable the new Reader security feature called “Protected Mode”.  Now, I’m all for improved security, and Adobe ( almost synonymous with PDF) has recently gotten beaten on for at least one serious vulnerability. Unfortunately there happens to be a long list of circumstances in which Protected Mode will prevent the user from opening perfectly good documents,  and we fall into one of these circumstances. I suspect it is due to folder redirection, and if you likewise use folder redirection, you probably do as well.  So, I had to find a way to disable it lest every one of our users be confronted with an ugly error message the first time they try to launch the application.  I found the solution buried in the last note on the app kb page on; may God bless the creators and contributors of that site.  A simple registry edit (local computer didn’t work for me as the post suggests, so I went with current user) solved the problem.  Simply add: HKCUSoftwareAdobeAcrobat Reader10.0PrivilegedbProtectedMode with a dword value of zero.  Of course, doing that with a script can be so ugly, so, since the application is being deployed with group policy, an admx entry seemed like just the fix. Sounds like a topic for another post! […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s