Windows Administration

Dig into New Group Policy Templates in Windows Vista

Darren Mar-Elia

At a Glance:

• Inside ADMX
• Editing ADMX files
• How ADM and ADMX files differ
• Creating a Central Store

Prior to Windows Vista, the registry values you could set within Group Policy were governed by ADM files, whose syntax was cryptic and proprietary. If you wanted to control additional registry values beyond the ones Microsoft shipped with the standard ADM files, you had to learn this

syntax and create a custom ADM file. In addition, these ADM files were stored with each Group Policy Object (GPO) in your Active Directory® environment, and each of these GPOs with the accompanying ADM files were replicated to all domain controllers in the domain.

With the release of Windows Vista™, Microsoft takes a major step in the area of Group Policy-based registry templates. Windows Vista introduces significant changes in both the format of the ADM file, now called ADMX, and the way in which these files are stored. In this article, I'll take a look inside the new ADMX format and discuss how these files are different from ADM. I'll also look at how storage of these files is handled in a Windows Vista environment.

ADMX Differences

The biggest difference between the new ADMX file format and the old ADM format that's been around since Windows NT® 4.0 is that ADMX has adopted the XML standard for describing registry policy settings. This is good for several reasons. The first is that there are many more tools for editing XML than for the ADM syntax. The second is that, because XML is schematized, it will eventually become easier to build tools that help you know the right tags to put in the right places to create a well-formed ADMX file. What schematized means is that, for a given application of XML such as the ADMX format, there's a documented schema that describes the elements and attributes that are possible, and how they are organized. We'll look at an example later in the article.

The other key difference between ADMX and ADM is the separation of the strings section of the main ADMX file into a language-specific ADML file. If you're familiar with ADM files, you know that at the end of every file there's a section delimited with a "[strings]" tag where you could assign values to strings of text you wanted to appear when using the Group Policy Editor and Administrative Templates. For example, the text you saw when you clicked on the Explain tab on a given policy was stored within that strings section. The problem with this is that the strings were stored within the ADM file, so if you wanted to use that ADM on a Windows® system running a different language, you had to create a new ADM file with a strings section for that language.

It got even more complicated if someone on, let's say, the French version of Windows, wanted to edit an existing GPO that had used English ADMs. The French admin would only see English in the Group Policy editor. Windows Vista gets around this problem by separating the [strings] section into an XML-based ADM Language (or ADML) file. The ADML file can be shipped in any supported language and can easily be changed to support any new language without having to touch the main ADMX file that stores the policies. More importantly, when that French admin edits a GPO from his Windows Vista workstation, the Group Policy Editor will detect that the French version of Windows is being used and will load the French ADML files for that GPO automatically.

You can see all of the ADMX and ADML files that come with your installation of Windows Vista by opening the folder at c:\windows\policydefinitions (see Figure 1).

Figure 1** ADMX Files in Windows Vista **(Click the image for a larger view)

Note that at the top of the file listing in Figure 1, there is a folder called en-us. This is the language-specific folder that contains the ADML files for the ADMX files you see in this PolicyDefinitions folder-in this case for US English. There is one ADML file for each ADMX. As of this writing, Windows Vista contains 132 ADMX/ADML files by default. This is another big difference between Windows Vista and prior versions: Windows XP-created GPOs typically held five ADM files, the largest being System.adm, which held policy items for most of the Windows components under policy control. In Windows Vista, Microsoft decided to break up the ADMX files by function-hence the much larger number of ADMX files. Each ADMX typically covers a single Windows component (such as Control Panel, DNS Client, Windows Explorer, and so on).

Inside the ADMX

That ADMXs are written in XML is a significant improvement, as I noted earlier. However, many administrators don't know how to write XML, let alone understand the schema used by ADMX for creating policy extensions. While a tutorial on custom ADMX creation is beyond the scope of this article, let's look at how ADMXs are formed.

You can open an ADMX or ADML file in any text editor, even Notepad, but unless your editor understands XML syntax, it may not be very meaningful. I use Visual Studio® because its IntelliSense® feature helps you complete particular elements. Figure 2 shows the first few lines from one of the ADMXs that ships with Windows Vista.

Figure 2 Some XML in an ADMX File

<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="https://www.w3.org/2001/XMLSchema" 
  xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="https://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>

This may look strange if you're not familiar with XML, but many of these XML elements can be found in any ADMX file. The policyNamespaces element, for example, uniquely identifies this ADMX file within the universe of all ADMX files.

If you created custom ADM files in prior versions of Windows, you know there was a set of tags, such as Category, Policy, ListBox and ActionList, you employed to define the policy settings that would appear in the Group Policy Editor. Many of these tags haven't changed, or have changed only slightly in the ADMX format, but they look much different because they're represented as XML. For example, I had written a custom ADM file that enabled various types of logging within Windows for Group Policy troubleshooting. A section of that custom ADM is shown in Figure 3. I ported this file to the new ADMX format, as shown in Figure 4.

Figure 4 The ADM File Converted to an ADMX File

<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>

Figure 3 A Custom ADM File

CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM

In many respects, this ADMX snippet is much simpler to understand than its ADM cousin, as it's more succinct. The policy element specifies what this policy is doing (Folder Redirection Logging). The attributes prefixed with $(string. are references to the corresponding ADML string element. The key and valuename attributes, obviously, specify which registry key and value this policy affects. The parentCategory element controls where this policy appears in the Group Policy Editor Administrative Template hierarchy. The supportedOn element indicates which operating system version respects this policy, and finally, the enabledvalue and disabledvalue elements specify what values are put into the registry when this policy is set to enabled and disabled.

This is a pretty simple on/off policy. As in ADM syntax, it is possible to create more complex UI elements within the Group Policy Editor. When you do that within ADMX, the syntax gets a bit more involved and includes a presentation attribute that references a portion of the ADML file where the UI element's text labels can be found. But beyond this, the ADMX syntax is really not much more complicated. One thing to keep in mind is that some of the tag names have changed between ADM and ADMX. So for example, in ADM parlance you had "edittext" and "listbox" tags. In ADMX, you find those tags referred to as "text" and "list" within the ADMX file. Those elements will have corresponding entries in the ADML file that specifies the text that appears alongside them.

As you may already know, an administrator can load a custom (legacy) ADM file into the Windows Vista Group Policy Object Editor. People often ask me whether Microsoft will provide a utility for converting custom ADM files to the ADMX syntax. In fact, Microsoft teamed with FullArmor Corp. to release a free tool called the ADMX Migrator. This tool does two things. First, it converts your old custom ADM files to the ADMX format (see Figure 5 for an example of using the tool to convert my custom gpolog.adm).

Figure 5** ADMX Migrator **(Click the image for a larger view)

The second thing it provides is an ADMX Editor that lets you create new ADMX files from scratch. You can download this tool at go.microsoft.com/fwlink/?LinkID=77409.

ADMX Storage

The other notable change I want to discuss is how ADMX and ADML files are stored for use. In versions of Windows prior to Windows Vista, when you edited a new GPO, the ADM files were automatically copied up from the local workstation where you performed your editing tasks to the SYSVOL portion of the GPO on a domain controller within your Active Directory domain. These ADMs were then subsequently replicated to every DC in a domain, for every GPO that was created. This wasted a lot of network bandwidth and disk storage, especially in large environments with dozens or hundreds of GPOs. Windows Vista turns this process on its head. By default, when you create an Active Directory-based GPO from a Windows Vista workstation, the Administrative Template policies that appear in the Group Policy Editor are loaded from the c:\windows\policydefinitions folder on the computer you're editing the GPO from.

The ADMX and ADML files are not copied up to SYSVOL-they are only referenced locally. This eliminates the storage and network burden that ADMs put on the Group Policy environment. But it gets even better. Windows Vista also supports a central store, a repository for Administrative Templates. This addresses how you effectively control the ADMX files used to edit GPOs, regardless of who is editing them. You do so by copying all of the official ADMX and ADML files (and any custom ones you create) up to a network location, and then all subsequent Group Policy editing from Windows Vista workstations references those network-based versions instead of each of their individual local ones. Setting up a central store is an easy, one-time-per-domain task. Just follow the steps in the "Creating a Central Store" sidebar.

Summary

The new ADMX format in Windows Vista is a clear improvement over the ADM files used with previous OS versions. The use of XML provides a cleaner framework for editing and searching these files. The moving of language-specific strings into separate files make multi-language Group Policy editing seamless, and the central store eliminates the need to store and update all of your GPOs with copies of ADM files. All this makes learning about ADMX a smart move.

Creating a Central Store

The creation of the central store is relatively straightforward. Follow these simple steps to create one in your Active Directory domain:

Step 1: Open Explorer and navigate to the SYSVOL share on the PDC-emulator DC in your environment (you can use any DC but the PDC role owner is usually where any Group Policy changes are focused).

Step 2: Drill into the Policies folder under SYSVOL and create a new folder called PolicyDefinitions.

Step 3: Copy the contents of the C:\windows\policydefinitions folder on your Windows Vista workstation to the new PolicyDefinitions folder, including the language-dependent ADML folder (for example, en-us on US English computers).

Once the ADMX and ADML files are copied to the Central Store folder, the Group Policy Object Editor on Windows Vista will start referencing the files there, and will ignore the ones stored locally!

Darren Mar-Elia is a Microsoft Group Policy MVP, creator of the popular Group Policy site—www.gpoguy.com and coauthor of Microsoft Windows Group Policy Guide (Microsoft Press, 2005). He is also CTO and founder of SDM Software, Inc. Reach him at Darren@gpoguy.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.