Group Policy
Inside ADM and ADMX Templates for Group Policy
Jeremy Moskowitz
At a Glance:
- Types of group policy templates
- Proper and improper Policies keys
- Viewing ADM templates
- Converting ADM to ADMX
ADM files. You either love 'em or you hate 'em. Or maybe both. That's because they're both necessary and confusing. And now there are ADMX files, a new format that can seemingly only add to the confusion. Well, it's time for me to shed some light on this cloudy subject.
Why Do We Need ADM Files?
Group Policy covers a wide range of areas. If you dive down into the Group Policy Object Editor (GPOE), you'll discover lots of different "stuff" you can do with Group Policy. For instance, you'll find Software Restriction Policy, Group Policy Software Installation, Folder Redirection, and, yes, the one we utilize most: Administrative Templates. The Administrative Templates node appears on both the User and Computer sides. As you'd expect, users can only embrace User-side policy settings and computers can only embrace Computer-side policy settings.
But where do all these magical settings within Administrative Templates come from? When new applications are "born," there are some settings you can potentially manipulate. That's where ADM files come into play. They describe the areas of the application that are ready to accept settings defined by an administrator. ADM files are limited right away, unfortunately, because they can only address Registry settings within an application. But an application might save its settings in other areas such as .ini files, .js files, .xml files, and databases.
In-the-Box ADM Files
So how do all those in-the-box policy settings for Computer Configuration | Administrative Templates and User Configuration | Administrative Templates get there in the first place? If you right-click the words "Administrative Templates" in the GPOE and select "Add/Remove Templates" on either the User or Computer side, you'll see the default templates that make up the standard configuration in Figure 1.
.gif)
Figure 1 Default Administrative Templates (Click the image for a larger view)
The breakdown of these files is:
- Conf.adm—NetMeeting® settings.
- Inetres.adm—Internet Explorer® settings, including connections, toolbars, and toolbar settings. These settings are equivalent to the options that are available when you click on the Internet Options menu inside Internet Explorer.
- System.adm—Operating system changes and settings. Most of the Computer and User Administrative Template settings are in this ADM template.
- Wmplayer.adm—Windows Media® Player 9 settings.
- Wuau.adm—Controls your clients' access to Windows® Update and/or Windows Server® Update Services servers.
Adding a New ADM Template File
This is an easy one. First, get the ADM template you want to use. You could use one that you've downloaded from
GPanswers.com (we have about a dozen interesting ones), or maybe you want to utilize the ADM files for Office 2003 or Office 2007 located on the Microsoft Web site.
Just right-click the words "Administrative Templates" and then click "Add," as shown in Figure 1, to add in the template. By default, Windows looks for templates in the \Windows\inf directory, but there's no reason you can't store them wherever you'd like. Here's something you may not be aware of: once the ADM template is added from the original storage point, that ADM template also gets added to the contents of the Group Policy Object (GPO) itself.
For instance, for this article I went to
GPanswers.com and downloaded nopassport.adm. I originally housed this template file in my c:\temp directory. This ADM template allows us to squelch the "Do you want to add your passport?" message that happens the first time a user logs into a machine running Windows XP.
I also downloaded the Office 2003 ADM templates and stored them in c:\temp. But they won't stay in that directory. In Figure 2, you can see that I've added nopassport.adm and Word11.adm. You can see these have been added to the list of default templates in the "Add/Remove Templates" window.
.gif)
Figure 2 Additional ADM files in the GPO (Click the image for a larger view)
Now, if you look inside the file-based portion of the GPO itself (specifically, in the \\domaincontroller\SYSVOL\domainname\Policies\GUID\ADM directory), you can see that the nopassport.adm and Word11.adm files are now part of the GPO, as shown in Figure 2.
Why are these templates added to the GPO? Because if you then try to edit this GPO on another management station, you'll be able to see the settings contained within the ADM files.
Why Can't I See What I Just Loaded?
Sometimes you can see your ADM file additions and sometimes you can't. And this is causing a lot of confusion for a lot of administrators. Indeed, this is a very common question on
GPanswers.com, so let's clear it up right now.
You should at least be able to see the results of adding the two templates (see Figure 3). Two new nodes will appear: Computer Configuration | Nuisances (because of nopassport.adm) and User Configuration | Microsoft Office Word 2003 (because of Word11.adm). If you dive down into the Microsoft® Word 2003 settings, you'll see quite a huge array of configurables, as indicated in Figure 3.
.gif)
Figure 3 Configurable group policy settings (Click the image for a larger view)
But why can't you see the settings in the new Nuisances node? To understand that, you first need to understand the idea of "proper" versus "improper" Policies keys that an ADM template might affect.
Proper vs. Improper Policies Keys
Microsoft documentation states that four Registry areas are considered to be the approved places to create policies out of Registry hacks:
- HKLM\Software\Policies (computer settings, the preferred location)
- HKLM\Software\Microsoft\Windows\CurrentVersion\Policies (computer settings, an alternative location)
- HKCU\Software\Policies (user settings, the preferred location)
- HKCU\Software\Microsoft\Windows\CurrentVersion\Policies (user settings, an alternative location)
The settings that are contained within the Word 2003 ADM file write to these proper locations, but the nopassport.adm file doesn't—nopassport.adm writes to HKLM\Software\Microsoft\MessengerService\PassportBalloon.
The GPOE puts up a little safety gate before it allows you to see these settings because the settings that don't write to these four proper Policies keys will tattoo the Registry. So, even if you whack the GPO, there's no way the setting will revert back. For example, let's say you added the nopassport.adm file and chose to squelch the "Do you want to add a passport?" pop-up balloon for every machine in your domain. Then, later, the boss said he really enjoyed getting that pop-up balloon. In that case, you've got a long road ahead of you because all computers now will embrace the setting—basically forever—until you expressly put that setting back. And, yes, it's possible to create a new, custom ADM just for this purpose, but, again, it could be a long road.
In contrast, regular policy settings have a default value. And if you whack the GPO, those settings will revert back to the default. For instance, if you choose to prohibit access to the Control Panel using the built-in ADM templates, then later change your mind, all you need to do is whack the GPO and access to the Control Panel comes back. This is true for just about every setting that ships with the default ADMs (there are some oddball exceptions).
Again, with the custom passport squelch ADM, the site where the policy setting is placed doesn't enable the Group Policy engine to revert it upon deletion. So Microsoft protects you by (initially) not showing these tattooing policy settings at all so you don't shoot yourself in the foot!
Seeing ADM Templates
So, seeing the ADM templates isn't all that hard. The editor, by default, doesn't show you the settings, but it's easy to fix that. Click on "Administrative Templates" (on either the User or Computer area), then select View | Filtering. Finally, uncheck (yes, uncheck) "Only show policy settings that can be fully managed" (which can be seen in Figure 4). When you do this, you'll see the policy setting "Passport Solicitation" show up under the Setting column, also seen in Figure 4.
.gif)
Figure 4 GPO filtering (Click the image for a larger view)
Windows XP vs. Windows Vista
in the Editor
Did you notice a subtle difference in the policy setting that just popped up? Look at the icons of the policy settings that ship with the ADM files out of the box in Figure 5. Now, look at the icon for a policy setting from an ADM template where the settings don't write to the proper Policies Registry keys, as shown in Figure 6.
.gif)
Figure 5 ADM files with icons (Click the image for a larger view)
.gif)
Figure 6 Icons for improper key usage (Click the image for a larger view)
This blue versus red icon differential helps you know which settings will tattoo and which won't. But again, it's all based upon where the setting actually performs its duty.
In Windows Vista®, by the way, the situation changes a bit when you use ADM files in your Windows Vista management station. ADM files show up in their own node called the "Classic Administrative Templates (ADM)" node, as seen in Figure 7. What were red-dot settings now show up as scroll icons with a down arrow (but while editing the setting itself, it has a little "No Enter" sign).
.gif)
Figure 7 Classic Administrative Templates node (Click the image for a larger view)
The settings that were blue-dot (those that write to the proper Policies keys) show up as little scroll icons, as seen in Figure 8.
.gif)
Figure 8 Scroll icons showing proper keys (Click the image for a larger view)
What's All the Hubbub about ADMX?
Windows Vista and Windows Server 2003 each ship with a new, built-in Group Policy Management Console (GPMC). And with that new GPMC comes a new ability to shake off the use of old ADM files to make room for newer ADMX files if you want to do that. Why would we want to shake off the ADM format?
Recall that the ADM file itself is placed up inside the Group Policy Template (GPT) part of the GPO (the part that lives in SYSVOL). When that happens, you burn about 4MB on every domain controller (DC) every time you create a GPO. Also recall that the ADM file itself is placed in the GPT of the GPO because it's necessary when you want to re-edit the GPO on another management station. Without that ADM file, you can't edit any custom settings contained within the GPO.
So, the ADMX format helps us break away from these issues. You no longer need to store anything inside the GPO directly, so you don't get what's known as "SYSVOL bloat"—that is, a fat SYSVOL that must store GPOs full of ADM files and has the burden of replicating them to every DC. To work around this, the new ADMX standard can take advantage of what's known as the "Central Store." The job of the Central Store is to have one location where you can place the new ADMX files so they don't need to get copied into each and every GPO. So, goodbye SYSVOL bloat. The other big deal about the Central Store is that if an ADMX file has an updated definition, then all Windows Vista management stations will immediately use that updated ADMX file.
If you want to learn about the format of ADMX files, specifically the creation and use of the Central Store in detail, I've got two resources for you. Darren Mar-Elia wrote an informative article on ADMX file format internals and a brief explanation of the Central Store in the February 2007 issue of Technet Magazine (
technetmagazine.com/issues/2007/02/Templates). I also have an entire downloadable chapter from my latest book, Group Policy: Management, Troubleshooting, and Security, available in the "Book Resources" section of
GPanswers.com.
As I explained, ADM templates are still supported when you use a Windows Vista management station, but ADM files are not supported within the Central Store. This can be a little confusing, so let's take a walk through an example.
Let's assume I just created a GPO from a Windows Vista management station and then tweaked some of the in-the-box settings (like Prohibiting Access to the Control Panel). Now, let's also assume I wanted to add a custom ADM template. After doing so, let's peek into the GPO's GPT and see what has happened to get some clarity.
To add the ADM template, you can repeat some steps I performed earlier. Just open up the GPOE, right-click "Administrative Templates," which is contained within both the Users or Computers node, and select "Add/Remove Template." You can see the added template in Figure 9.
.gif)
Figure 9 Viewing the added template (Click the image for a larger view)
In order to actually see the settings contained within this ADM template, you're going to need to do what we did earlier in Figure 4. That is, click on View | Filtering. Finally, uncheck "Only show policy settings that can be fully managed." Then, close the GPOE and return to the GPMC. Figure 10 shows the Details tab of the GPO I just created from my Windows Vista management station. (Note the catchy name of the GPO.) By looking in the Details tab, I can determine the GUID for the GPO, which will make it easier when I go sleuthing around in SYSVOL to find that particular GPO.
.gif)
Figure 10 Default Administrative Templates
Once I track down the GPT of the GPO (by using the GPO's GUID), I can crack open that GPO's ADM directory and see that there's exactly one ADM template here—the one that I manually imported, shown in Figure 11. This is because Windows Vista machines don't rely on ADMs anymore. Since they don't natively use them, they don't natively push anything up into the GPO itself. However, if you manually import an ADM (as we just did), it will continue to honor the ADM in the same fashion that previous versions of Windows did.
.gif)
Figure 11 Manually imported ADM file (Click the image for a larger view)
This is in contrast with, say, the GPO in Figure 12, which was created on a machine running Windows XP or Windows Server 2003. When GPOs are created using pre-Windows Vista management stations, the original ADM files are pushed up into the GPO, as I previously described. This GPO was created on a Windows XP management station. You can tell because it's jam-packed with ADM files that Windows Vista doesn't need or use.
.gif)
Figure 12 GPO created on Windows XP (Click the image for a larger view)
Converting ADM to ADMX Using the ADMX Migrator Tool
So Windows XP uses ADM files and Windows Vista uses ADMX files, although Windows Vista will continue to support ADM files if that's what we have available. However, we cannot stick an ADM file into the Central Store and expect our Windows Vista management stations to be able to make use of the file.
In order to utilize the settings contained within the ADM in the Central Store, you would need to convert the ADM file to ADMX, or re-create the ADM files as ADMX files by hand. Luckily, there's a single download that performs both of these functions. The ADMX Migrator tool (which is really composed of both an ADM-to-ADMX converter tool and an ADMX creation tool) can be downloaded at
go.microsoft.com/fwlink/?LinkId=103774.
You can install the ADMX Migrator Tool MSI file on Windows Server 2003, Windows XP, or Windows Vista. Once installed, the applications can be found in the C:\Program Files\FullArmor\ADMX Migrator directory. The command-line application I'll be running is called faAdmxConv.exe. But since the directory isn't in the path, you would need
to be in that directory in order to run the application. Therefore, when I'm using the tool, I opt to add this directory to my Windows path. The article at
www.computerhope.com/issues/ch000549.htm explains how to set the path in Windows.
I usually create a temp directory such as C:\ADMtemp and copy my source ADM files into it. There are a lot of possible parameters for faAdmxConv.exe, but the simplest way to convert an ADM file is to specify the name of the ADM file and the output directory. If you've already gone ahead and put the source ADM file in ADMtemp and added faAdmxConv.exe to the path, you can just run "faAdmxConv nopassport.adm ." (with the dot at the end to signify the current directory as output). If you don't specify the dot (for this directory) or another explicit path, the output goes to the temp directory within your account's profile. In Figure 13, you can see three commands:
.gif)
Figure 13 ADMX Migrator tool (Click the image for a larger view)
- A "dir" command to see the ADM file
- The "faAdmxConv" command with the name of the ADM and the . (dot) to represent the current directory
- A "dir" to see the outputted files: nopassport.admx and nopassport.adml
Before you go plunking the resulting files directly into your Central Store, you might want to test this on a machine that is running offline. After you take the machine offline, copy the ADMX file to the C:\Windows\PolicyDefinitions directory and the ADML file to the language-specific directory. In the U.S., that directory is C:\Windows\PolicyDefinitions\en-us. An example of the copy procedure can be seen in Figure 14.
.gif)
Figure 14 Copying ADMX files to the Central Store (Click the image for a larger view)
The ADM-to-ADMX converter tool was recently updated to version 1.2. This corrects a number of conversion bugs and adds useful warning messages during conversion time. If you've tried the ADM-to-ADMX converter tool in the past, but gave up due to error messages you couldn't correct for, I would encourage you to try it again with the 1.2 version now available for download.
Finally, the converted ADM file is now really two files: an ADMX (language-neutral) file and an ADML (language-specific) file. At this point, you can put the resulting files inside the Central Store or test them on a local machine. However, once again, in order to actually see the policy settings contained within this ADMX template, you're still going to need to do what we did back in Figure 4. That is, you'll still need to click on View | Filtering, then uncheck "Only show policy settings that can be fully managed." That's because the settings contained within this ADMX file do not write to one of the proper Policies keys I discussed previously.
Cleaning Up Shop
The ideal state is clearly to use only ADMX files and to utilize the Central Store. But in order to do that you need to convert all of your current ADM files to ADMX, convert all management stations to Windows Vista (or Windows Server 2008), and make a commitment to stop editing GPOs on pre-Windows Vista machines.
If you've completed these three steps, you have more or less banished ADM files from your world. At this point, the ADM files within your GPOs are just taking up space within your DC's SYSVOL. Once you're achieved ADMX nirvana, you could, if you wanted, simply delete the ADMs contained within the GPO's GPT within SYSVOL. That's right: like your body's appendix, they're vestigial. They did serve a purpose at one point, but no more. You can either do this manually or with a script. But before you do this, note that it would be a serious mistake if these steps haven't been completed. So be sure to do this only if you're sure you can leave ADM files behind.
For additional information on ADM, ADMX, and ADML files, see the Managing Group Policy ADMX Files Step-by-Step Guide at
go.microsoft.com/fwlink/?LinkId=105019 and the ADMX Technology Review at
go.microsoft.com/fwlink/?LinkId=105032. Also, be sure to sign up for the GPanswers.com newsletter, at
GPanswers.com/newsletter, and intermediary notices via blog at
GPanswers.com/blog.
.