Windows Insider

Vista's ADMX Marks the Spot

Getting to know XML.

• By Greg Shields
• 02/01/2007

With the release of Windows Vista, Microsoft's language change for Group Policy template authoring has caused some serious confusion among Windows administrators. Although the changeover to XML has been slowly taking over things like Security Configuration Wizard customizations and the new Office 2007 file format, administrators are still struggling with XML's more complicated syntax. Let's drill down into what's necessary to get you started customizing Group Policy in Windows Vista.

Shopping the Central Store
Although one of the major reasons for the switch to XML was to add support for multiple-languages, the reality is that most Windows networks host a single language. That being said, for most of us Vista Group Policy's major enhancement is the incorporation of a centralized location for storing template files called the Central Store.

In the old format each of the default ADM templates was stored, along with any customized templates, in every Group Policy Object folder in the SYSVOL. This decentralization required a minimum of 4MB per GPO. As policies got added over time, this became a major contributor to SYSVOL bloat. Creating lots of GPOs in a domain with latent WAN links also meant a major headache for SYSVOL replication.

With the new format, all Group Policies are now stored just one time in the Central Store, eliminating duplication and reducing the size of the SYSVOL.

Creating your Central Store is a manual process. As a Domain Administrator, log onto a Domain Controller and create a new SYSVOL folder named C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions. You'll also need to create a subfolder for language-specific files. For the English language, this subfolder's name should be \EN-US.

Then, from any Vista workstation navigate to the C:\Windows\PolicyDefinitions folder and upload its contents to your newly created SYSVOL location. Templates are now broken into two halves: an ADMX file containing the configuration components and an ADML file containing the associated descriptive text. Once the templates are uploaded into the SYSVOL and replicated, they're available for use within the Group Policy Object Editor.

eXtra Methods to Learn
If you open any of the new template files, you'll immediately notice that they're quite a bit meatier than those in the ADM format. Like HTML, the XML language requires tags surrounding each element, which has the tendency to add lots of extra text.

Let's look at a very simple example of the differences between the old ADM format and what that custom configuration would look like as an ADMX file. The text below describes a custom ADM template file intended to eliminate Acrobat Reader's splash screen at launch.

CLASS USER
CATEGORY "Adobe Acrobat Reader 7.0"
POLICY "Disable splash screen"
KEYNAME "Software\Adobe\Acrobat Reader\7.0\Originals"
EXPLAIN "Set this value to disable the splash screen"
VALUENAME "bDisplayedSplash"
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END POLICY
END CATEGORY

After converting it, the associated ADMX file looks like this. Note the items in bold, which illustrate the actual registry configuration components of the file. The rest is all wrapper code and pointers to the ADML file:

<policyDefinitions revision="1.0" schemaVersion="1.0">
<policyNamespaces>
<target prefix="fullarmor" namespace="FullArmor.Policies.48AFD0DF_651D_40CB_B850_149CD7 C843C8" />
<using prefix="windows" namespace="Microsoft.Policies.Windows" />
</policyNamespaces>
<supersededAdm fileName="Acrobat 7.0.adm" />
<resources minRequiredRevision ="1.0" />
<categories>
<category name="AdobeAcrobatReader70" displayName="$(string.AdobeAcrobatReader70)" />
</categories>
<policies>
<policy name="Disablesplashscreen" class="User" displayName="$(string.Disablesplashscreen)" explainText="$(string.Disablesplashscreen_Help)" key="Software\Adobe\Acrobat Reader\7.0\Originals"
valueName="bDisplayedSplash">
<parentCategory ref="AdobeAcrobatReader70" />
<supportedOn ref="windows:SUPPORTED_WindowsVista" />
<enabledValue>
<decimal value="1" />
</enabledValue>
<disabledValue>
<decimal value="0" />
</disabledValue>
</policy>
</policies>
</policyDefinitions>

Combining XML's syntactic excessiveness with the typical Windows administrator's distaste for programming means most admins will likely need a GUI tool to help build customized templates. A few have already been released by Microsoft that render XML in a more visually friendly way.

The first tool is XML Notepad 2007, which you can download from Microsoft's Web site. This tool creates a tree view for any XML file that looks a lot like Windows Explorer. Navigating to an element is done by clicking in the left pane, while adding one is done from the right.

XML Notepad 2007 is handy for generic XML authoring, but it doesn't provide any assistance with the specific schema for authoring ADMX files. To remedy this, Microsoft has licensed and made freely available a tool from FullArmor Corp. called ADMX Migrator. Like XML Notepad, this tool generates a tree view for rendering graphically the contents of the ADMX file, but is specifically coded for rendering ADMX files.

ADMX Migrator can ingest an old-style ADM file and convert it to an ADMX file while allowing the administrator to create additional categories and configurations. One function not handled natively by the tool is multiple-language localization. By default, ADMX Migrator creates all ADML files in U.S. English only. Remember, too, that XML files can be cantankerous beasts. All tags must be properly configured according to the ADMX schema definition. In addition, XML is natively case-sensitive, which can add a whole new suite of coding nightmares if you're generating templates by hand.

If your head is still swimming in this sea of XML elements and ADMX schemas, take heart. For most administrators, this changeover to the ADMX format will not substantially change your experience.