Using Administrative Template Files with Registry- Based Group Policy
This white paper explains the concepts, architecture, and implementation details for registry-based
Group Policy in Microsoft® Windows® operating systems. It shows how to create custom
Administrative Template (.adm) files and includes a complete reference for the .adm language. In
addition, it includes information about changes in .adm files for Windows XP with Service Pack 2
(SP2).
Using Administrative Template Files with Registry-
Based Group Policy
Microsoft Corporation
Published: September 2004
Abstract
This white paper explains the concepts, architecture, and implementation details for registry-based
Group Policy in Microsoft® Windows® operating systems. It shows how to create custom
Administrative Template (.adm) files and includes a complete reference for the .adm language. In
addition, it includes information about changes in .adm files for Windows XP with Service Pack 2
(SP2).
The information contained in this document represents the current
view of Microsoft Corporation on the issues discussed as of the
date of publication. Because Microsoft must respond to changing
market conditions, it should not be interpreted to be a commitment
on the part of Microsoft, and Microsoft cannot guarantee the
accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT
MAKES NO WARRANTIES, EXPRESS, IMPLIED OR
STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of
the user. Without limiting the rights under copyright, no part of this
document may be reproduced, stored in or introduced into a
retrieval system, or transmitted in any form or by any means
(electronic, mechanical, photocopying, recording, or otherwise), or
for any purpose, without the express written permission of Microsoft
Corporation.
Microsoft may have patents, patent applications, trademarks,
copyrights, or other intellectual property rights covering subject
matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this
document does not give you any license to these patents,
trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations,
products, domain names, e-mail addresses, logos, people, places
and events depicted herein are fictitious, and no association with
any real company, organization, product, domain name, e-mail
address, logo, person, place or event is intended or should be
inferred.
© 2004 Microsoft Corp. All rights reserved.
Microsoft, Active Directory, Windows, Windows NT, and Windows
Server are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein
may be the trademarks of their respective owners.
Table of Contents
Table of Contents
........................................ 3
Introduction
................................................ 6
Overview of RegistryBased Policy and Administrative Template
Files
....................................................... 6
Default .adm Files
.................................... 7
When to Use RegistryBased Group Policy
................. 8
True Policies vs. Preferences
........................... 8
How to Use Policy Settings and Preferences
........... 9
Design Considerations for Creating Policy Settings
.......
10
When to Create Policy Settings
......................... 11
Controlling Feature Releases to Users
...............
11
Create Policy Settings to Reduce Need for Support
.
. 11
Control Data
......................................... 12
When Not to Create a Policy
............................ 12
User Interface Design
................................... 12
Policy Names
........................................ 13
Explain Text
......................................... 13
Best Practices for Developing RegistryBased Policy Settings
........................................................
15
Creating Custom .Adm Files
.............................. 16
How to Write a Simple .Adm File for Registrybased Group Policy
...........................................................
18
Testing Administrative Template Files
..................... 22
Creating an .Adm Test File
.............................. 23
Loading an .Adm File into the Group Policy Snapin
.
. 24
Maintaining and Managing .Adm Files
....................... 24
Importance of Timestamps for .Adm Files
................ 25
Duplicate CATEGORY Sections
.......................... 25
.Adm Files Used by the Group Policy Object Editor
......
26
.Adm Files Used by GPMC
................................. 26
Controlling .Adm File Replication
...................... 26
Turn Off Automatic Updates of .Adm Files
.............
26
Always Use Local .Adm Files for Group Policy Object Editor
.....................................................
27
Maintaining .Adm files on Administrative Workstations
27
Multilanguage Administration Issues
..................
28
Operating System and Service Pack Release Issues
.......
28
Keyboard Shortcuts for Administrative Templates Node
29
What’s New for Administrative Template Files in Windows
XP SP2
...........................................................
30
Changes to LISTBOX ADDITIVE
........................... 30
Managing Policy Settings on Earlier Operating Systems or
Service Packs
...........................................
31
“String Too Long…” Hotfix for Earlier Operating Systems and
Service Packs
........................................
32
Language Reference for Administrative Template Files
......
33
.Adm File Language Versions
............................ 33
Comments
................................................
34
Strings
.................................................
34
CLASS
...................................................
34
Syntax
...............................................
34
Example
..............................................
35
CATEGORY
................................................
35
Syntax
...............................................
35
Example
..............................................
36
Supported Tag
........................................
37
CATEGORY Keywords
....................................
37
POLICY
..................................................
38
Syntax
...............................................
38
POLICY Example
.......................................
39
POLICY Keywords
......................................
40
PART ....................................................
40
Syntax
...............................................
40
Using PART Types to Add Controls to the User Interface
42
CHECKBOX PART Type
...................................
42
TEXT PART Type
.......................................
44
EDITTEXT PART Type
...................................
45
NUMERIC PART Type
...................................
48
COMBOBOX PART Type
...................................
50
DROPDOWNLIST PART Type
...............................
51
LISTBOX PART Type
....................................
52
ACTIONLIST
..............................................
53
Additional Elements
.....................................
55
Introduction 5
.Adm File String/Tag Limits
............................ 59
Related Links
..............................................
60
Introduction 6
Introduction
Administrators can use Group Policy to deliver and apply one or more desired configurations or
policy settings to a set of targeted users and computers within an Active Directory® directory
service environment. The majority of available policy settings are provided through Administrative
Template files (.adm files) and are designed to modify specific keys in the registry. This is known
as registry-based policy. For many applications, the use of registry-based policy delivered by .adm
files is the simplest and best way to support centralized management of policy settings.
Intended for IT administrators and developers, this document describes how to implement registry-
based Group Policy by using .adm files.
For detailed instructions about enabling applications for Group Policy, see “Group Policy” in the
Microsoft Platform Software Development Kit at http://go.microsoft.com/fwlink/?LinkId=26258.
Overview of Registry
Based Policy and
Administrative Template
Files
By using registry-based policy, operating system components and applications can respond to
registry key settings that administrators can manage centrally with Group Policy. These policy
settings determine the behavior of the application for targeted computers or users. As long as a
component or application has been policy-enabled (that is, its behavior changes based on registry
values indicated in the .adm file), you can manage its features and settings through registry-based
policy.
.Adm files are UNICODE text files that Group Policy uses to describe where registry-based policy
settings are stored in the registry. All registry-based policy settings appear and are configured in
the Group Policy Object Editor under the Administrative Templates node. .Adm files do not apply
policy settings; they simply enable administrators to view the policy settings in the Group Policy
Object Editor. Administrators can then create Group Policy objects (GPOs) containing the policy
settings that they want to use. For example, you might have one GPO that contains various policy
settings for managing the Active Desktop feature.
With the release of Microsoft® Windows XP Service Pack 2 (SP2), IT administrators have more
than 1,300 Administrative Template policy settings available for their use. In addition,
administrators and developers can add their own custom settings.
Language Reference for Administrative Template Files 7
Registry-based Group Policy uses .adm files in the following manner:
• The Group Policy Object Editor reads the .adm files. By default, when an administrator opens
a GPO, a comparison is made between the timestamps of the .adm files stored in the GPO
being edited and those on the local computer. If the local .adm files have a more recent
timestamp then they are uploaded to the domain controller and replicated throughout the
domain.
• The Group Policy Object Editor console (gpedit.msc) displays the settings, and, depending on
the .adm file, the policy settings can be displayed in a localized language.
• The Group Policy Object Editor uses .adm files to configure user interface settings such as
dialog boxes, radio buttons, and drop-down lists, thereby enabling administrators to manage
these settings centrally.
• The Group Policy Management Console (GPMC) uses .adm files to display policy settings
when using Group Policy Results or Group Policy Modeling, also known as Resultant Set of
Policy (RSoP).
Note
Windows XP SP2 includes modifications to the LISTBOX
ADDITIVE behavior in .adm files (implemented by a new
version of gptext.dll, the .dll used by the Group
Policy Object Editor.) For details about these
changes, see the, “What’s New for .Adm Files in
Windows section later in this document
XP SP2”
For more information about the architecture of Administrative Templates, see Administrative
Templates Extension Technical Reference at http://go.microsoft.com/fwlink/?LinkId=35291.
Default .adm Files
The Group Policy Object Editor displays the policy settings within the .adm files that are included
with the operating system by default. These .adm files are:
• System.adm. Provides policy settings to configure the operating system. System.adm is
installed by default in Windows Server™ 2003, Windows XP, and Windows 2000 Server
operating systems.
• Inetres.adm. Provides policy settings to configure Internet Explorer. Inetres.adm is installed
by default in Windows Server 2003, Windows XP, and Windows 2000 Server operating
systems.
• Wuau.adm. Provides policy settings to configure Windows Update. Wuau.adm is installed by
default in Windows Server 2003, Windows XP Service Pack 1 (SP1), and Windows 2000
Server Service Pack 3 (SP3) operating systems.
8 Using Administrative Template Files with RegistryBased Group Policy
• Wmplayer.adm. Provides policy settings to configure Windows Media Player.
Wmplayer.adm is installed by default in Windows Server 2003 and Windows XP operating
systems. Wmplayer.adm is not available on 64-bit versions of the Windows Server 2003
operating system and Windows XP 64-Bit Edition.
• Conf.adm. Provides policy settings to configure NetMeeting. Conf.adm is installed by default
in Windows Server 2003, Windows XP, and Windows 2000 Server operating systems.
Conf.adm is not available on 64-bit versions of the Windows Server 2003 operating system
and Windows XP 64-Bit Edition.
Most Group Policy settings are contained in the System.adm file. The .adm files that ship with
Windows Server 2003, Windows XP Professional, and Windows 2000 Server operating systems
are located in the %windir%\inf\ folder. (for example, C:\Windows\inf). For more information
about .adm file maintenance, see the “Maintaining and Managing .Adm Files” in this document.
When to Use RegistryBased
Group Policy
In general, if a policy setting can be configured using a simple user interface, and any configuration
input can be stored in the registry as plain text, you should consider using registry-based policy.
Specifically, registry-based Group Policy is an appropriate solution for the following scenarios:
• Creating available and unavailable (on/off, or yes/no) functionality. You can use registry-
based policy as if it were a switch, to turn functionality on or off. For example, you can create
a policy setting to allow administrators to control whether a certain item is displayed on the
desktop.
• Defining a set of static modes. For example, you can set the language used on a computer.
You can set up a static list of the possible language selections, and when the policy setting is
enabled, the administrator can select a language from the pre-created list. This action is
typically shown in the user interface as a drop-down list.
• Creating a policy setting that requires simple input that can be stored in the registry as
plain text. For example, you can create a policy setting to define the screensaver or bitmap
that is displayed on the user’s desktop. With this policy setting enabled, Group Policy
administrators are provided with a text dialog box into which they can enter the name and path
of the bitmap file to be used. This information is then stored in the registry as plain text.
True Policies vs. Preferences
Group Policy settings that administrators can fully manage are known as “true policies.” In
contrast, settings that users configure or that reflect the default state of the operating system at
installation time are known as “preferences.” Both true policies and preferences contain
information that modifies the registry on users’ computers. True policy settings take precedence
over preference settings.
Language Reference for Administrative Template Files 9
Registry values for true policies are stored under the approved registry keys as listed in Table 1.
Users cannot change or disable these settings.
Table 1 Approved Registry Key Locations for Group Policy
Settings
For Computer Policy Settings: For User Policy Settings:
HKLM\Software\Policies (The HKCU\Software\Policies (The
preferred location) preferred location)
HKLM\Software\Microsoft\Window HKCU\Software\Microsoft\Windows
s\CurrentVersion\Policies \CurrentVersion\Policies
Preferences are set by the user or by the operating system at installation time. The registry values
that store preferences are located outside the approved Group Policy keys listed in Table 1. They
are located in other areas of the registry. Users can typically change their preferences at any time.
For example, users can decide to change the location of their local dictionary to a different
location, or set their wallpaper to a different bitmap. Most users are familiar with setting
preferences that are available to them through the operating system or application user interface.
It is possible for an administrator to write an .adm file that sets registry values outside of the
approved Group Policy registry trees included in Table 1. In this case, the administrator is only
ensuring that a given registry key or value is set in a particular way. With this approach, the
administrator configures preference settings, instead of true policy settings, and marks the registry
with these settings (that is, the settings persist in the registry even if the preference setting is
disabled or deleted).
If you configure preference settings by using a GPO in this manner, the GPOs that you create do
not have Access Control List (ACL) restrictions. As a result, users might be able to change these
values in the registry. When the GPO goes out of scope (that is, it is unlinked, disabled, or deleted),
these values are not removed from the registry. In contrast to this, true registry policy settings do
have ACL restrictions to prevent users from changing them, and the policy values are removed
when the GPO that set them goes out of scope. For this reason, true policies are considered to be
policy settings that can be fully managed. By default, the Group Policy Object Editor only shows
policy settings that can be fully managed. To view preferences in the Group Policy Object Editor,
you need to click the Administrative Templates node, click View, then click Filtering, and then
clear Only show policy settings that can be fully managed.
Although Group Policy settings take priority over preferences, they do not overwrite or modify the
registry keys used by the preferences. If a policy setting is deployed that conflicts with a
preference, the policy setting takes precedence over the preference setting. If a conflicting policy
setting is removed, the original user preference setting is restored.
How to Use Policy Settings and Preferences
Applications commonly include a user preference and a policy setting that perform similar or
related functions. For example, you might want to offer users the ability to configure part of a
component through a user preference setting, and also centrally control this setting by using a
registry-based policy setting.
10 Using Administrative Template Files with RegistryBased Group Policy
An example of where both a policy and preference can co-exist is the configuration of the
wallpaper on a Windows desktop. Users can set their desktop wallpaper to be displayed (or not
displayed) by using the Display icon in Control Panel. You can also use a policy setting to
configure desktop wallpaper. To specify the desktop wallpaper that displays on users’ desktops,
administrators can use the Active Desktop Wallpaper policy setting (found in the Group Policy
Object Editor, under the User Configuration\Administrative Templates\Desktop\Active
Desktop. As a result, the user can choose to display or not display the wallpaper, but the
administrator can choose which wallpaper is displayed when the display setting is ON.
Table 2 lists the resultant behavior for Group Policy settings and preferences.
Table 2 Results of Group Policy Settings and Preferences
Policy Preference Resultant
Scenario
Present Present Behavior
No policy or No No Default
preference behavior.
Preference Only No Yes Preference
configures
behavior.
Policy only Yes No Policy
configures
behavior.
Both policy and Yes Yes Policy
preference configures
behavior.
Preference is
ignored. In
all cases,
policy
overrides
preference.
Design Considerations
for Creating Policy
Settings
This section addresses essential issues for creating and configuring custom policy settings in .adm
files.
Use the following questions as a guide to help you design Group Policy settings.
• What is the default behavior (that is, when the policy is set to Not Configured)?
Language Reference for Administrative Template Files 11
• What is the behavior when the policy is Enabled, Disabled, or Not Configured? The
Enabled behavior should always be the opposite of the default behavior (that is, Not
Configured).
• Do administrators need to explicitly disable a feature?
• Do the proposed policy settings affect users or computers or both?
• What are some potential future ramifications of the new policy settings? When new products
are released, you must continue to maintain the previous .adm settings to manage computers
running legacy software. New products and settings must be able to co-exist with earlier
versions.
When to Create Policy Settings
An administrator should consider creating a policy setting for the following purposes:
• To help administrators manage and increase security of their desktop computers.
• To hide or disable a user interface that can lead users into a situation in which they must call
the helpdesk for support.
• To hide or disable new behavior that might confuse users. A policy setting created for this
purpose allows administrators to manage the introduction of new features until after user
training has taken place.
• To hide settings and options that might take up too much of users’ time.
Controlling Feature Releases to Users
An administrator can use .adm files to provide policy settings to manage new features of a new or
updated application. By creating a single GPO for all new features, or by creating a GPO for each
logical grouping of new features, an administrator can reduce the need for support and potential
user frustration. A GPO should also be considered for specific features that administrators need to
control after the new features have been enabled.
By enabling policy settings in this area, the administrator can control how and when users get new
product features. By grouping related features, the administrator can prevent users from using a
new feature set until they have been trained.
Create Policy Settings to Reduce Need for
Support
To reduce the need for support, administrators can start by determining the top issues that users
have and considering ways in which they can use policy settings to prevent support calls. For
example, you could use policy settings to control software settings in the following scenarios:
• When proper configuration settings require advanced knowledge of the application.
12 Using Administrative Template Files with RegistryBased Group Policy
• When there are complicated or advanced configuration settings that the typical user does not
need to use.
In these scenarios, it would be appropriate to use Group Policy to give an administrator the ability
to control access to the configuration settings.
Control Data
You can create policy settings to populate data for your application. Such data usually exists in
small sets in the form of numbers, text strings, and so on. For example, a phone dialer could use
policy settings to enable administrators to mandate that certain items exist in the phone directory.
When Not to Create a Policy
Although registry-based Group Policy provides an effective way of managing components and
applications, there are some circumstances where its use is not recommended. For example:
• Do not create a policy for all of your application settings because large applications typically
contain hundreds or even thousands of settings, and only a subset of these needs to be
managed through Group Policy. Be selective about the features you want to enable or disable.
Because Group Policy provides centralized management of the setting, you should evaluate
whether administrators would want this kind of management before adding the policy setting.
• Do not create a policy if you do not intend to provide support for the policy setting. Treat each
policy as a feature that needs to be tested, validated, and supported.
User Interface Design
Effective policy settings should be clearly written and displayed. You must also ensure that the
user interface is clear and easy to understand. For example, review these user interface design
options for disabling My Network Places:
• Create an error message. For example, the user clicks My Network Places and the following
error message appears: “This option has been disabled by your administrator.” In response, the
user calls the administrator or support desk to ask why this feature has been disabled.
• Disable the user interface. For example, a user interface feature in My Network Places is
disabled (grayed-out). This implies to the user that there is a way to enable the user interface.
In response, the user might spend a lot of time trying to get this feature to work. In the end, the
user might either give up in frustration or call the support desk.
• Hide the user interface feature. For example, a user interface feature in My Network Places
is hidden. In response, the user does not recognize that anything is missing or unavailable.
This is the preferred choice in this scenario.
• Do nothing. For example, when a user clicks My Network Places, and the screen does not
change (that is, nothing happens). In response, the user assumes that something is wrong and
calls the support desk.
Language Reference for Administrative Template Files 13
Policy Names
You set the name of the policy setting at the same time that you create it. The name of the policy
setting is displayed in the Group Policy Object Editor. Use the following guidelines for creating
policy names:
• Use a verb that reflects the effect of the policy setting. Examples of verbs commonly used in
policy setting names include: allow, permit, turn on, prohibit, hide, and prevent.
• Do not use the terms “enabled” or “disabled” in your policy setting names. Instead, consider
using the terms “turn on” and “turn off,” or “allow” and “prevent.”
• Avoid overly technical jargon that might not be understood by administrators who are not
experts in a particular component. Include technical details of the policy setting in the Explain
text.
• Use short, descriptive names that accurately reflect the function of the policy setting, for
example, Turn off Internet File Association service.
Note
Policy names are limited to 256 characters. However,
depending on the font used on the user’s workstation,
a smaller number of characters are displayed, and all
others truncated. On most systems, you can assume
that you have the ability to display policy names up
to 65 characters. (Using a Resolution of 1024 / 768
with small fonts installed).
When Group Policy names are translated into
additional languages, they typically require
additional characters. Therefore, if you are using
English to name a Group Policy, limit the name to 49
characters. This limitation allows your title to grow
by 33 percent during translation, without causing any
truncation issues.
Explain Text
Explain text provides information about the behavior of the policy setting, its interaction with other
policy settings, and can include any other information that you would like administrators to be
aware of. When an administrator selects a policy setting, and then clicks the Explain tab, the
Explain text appears in the policy setting’s Properties dialog box . Explain text is limited to a
maximum of 4096 characters, and Category Explain text is limited to a maximum of 256
characters.
Use the following guidelines when you create the Explain text:
Note
Do not try to supplement a Group Policy setting title
in the user interface with tip text that can be
displayed in the user interface. Include any tips for
using the policy setting in the Explain text.
14 Using Administrative Template Files with RegistryBased Group Policy
• Draft the Explain text soon after creating the specification document for the policy setting.
This serves as a high-level roadmap for developers, and assists testers in creating a test plan
for the policy.
• Make sure your documentation team is available to help create the Explain text.
• Target the Explain text to the Group Policy administrator, rather than the end user.
Use the following template for the Explain text, and make sure that you include the following
items:
• Write a one- or two-line description of the policy setting.
• Write a one- or two-line description of the feature that the policy setting affects.
• Use separate paragraphs within your Explain text for each policy setting state, as follows:
• If you enable this policy setting….
• If you disable this policy setting….
• If you do not configure this policy setting….
• Include tips for using the policy setting.
• Include notes or interactions that this policy has with other settings.
As a best practice, you should also provide information about the following:
• Items that are not covered by this policy setting.
• Any other policy settings that are required for your policy setting to function.
• Any other policy settings that are related to the same component that your policy setting
affects and which may have a higher or lower priority. For example, if you have a policy
setting to restrict access to the LAN settings for a computer. This policy setting takes priority
over more specific policy settings regarding the actual items you can configure within a LAN
connection.
• Any related policies that the administrator needs to be aware of.
The following Explain text is from the Active Desktop Wallpaper policy setting in the User
Configuration\Administrative Templates\Desktop\Active Desktop. This policy setting controls
the desktop background (wallpaper) that is displayed on users' desktops.
Specifies the desktop background ("wallpaper") displayed on all users' desktops.
This setting lets you specify the wallpaper on users' desktops and prevents users
from changing the image or its presentation. The wallpaper you specify can be
stored in a bitmap (*.bmp), JPEG (*.jpg), or HTML (*.htm, *.html) file.
To use this setting, type the fully qualified path and name of the file that
stores the wallpaper image. You can type a local path, such as
C:\Windows\web\wallpaper\home.jpg or a UNC path, such as \\Server\Share\Corp.jpg.
If the specified file is not available when the user logs on, no wallpaper is
displayed. Users cannot specify alternative wallpaper. You can also use this
Language Reference for Administrative Template Files 15
setting to specify that the wallpaper image be centered, tiled, or stretched.
Users cannot change this specification.
If you disable this setting or do not configure it, no wallpaper is displayed.
However, users can select the wallpaper of their choice.
Also, see the "Allow only bitmapped wallpaper" in the same location, and the
"Prevent changing wallpaper" setting in User Configuration\Administrative
Templates\Control Panel.
Note: You need to enable the Active Desktop to use this setting.
Note: This setting does not apply to Terminal Server sessions.
Best Practices for Developing
RegistryBased Policy
Settings
It is strongly recommended that you do not try to create a single policy setting to control all aspects
of your component. Group Policy is easier to implement and use if you have several smaller policy
settings. This approach gives you more flexibility in designing and modifying your policy settings.
All policy settings should have an associated behavior for each of the three possible states shown in
Table 3:
Table 3 Policy States and Associated Behaviors
Enabled Disabled Not Configured
Turns on the Turns off the Has no effect –
behavior indicated behavior indicated default behavior
by the policy name by the policy name
Consider the following guidelines when you design your policy settings:
• Policy settings are never removed from the .adm files supplied by Windows operating
systems. Even if subsequent versions of Windows no longer support the policy setting,
Microsoft will continue to include that policy setting in .adm files for all future Windows
operating systems that support Group Policy.
• Computer policy settings should override user policy settings.
16 Using Administrative Template Files with RegistryBased Group Policy
• The Enabled behavior should be the opposite of the default behavior. For example, if a feature
is on by default, the policy setting should be named using something like “Turn off
”, for example, Turn off reminder balloons. By default, reminder balloons are
displayed when the Offline Files feature is enabled; they are used to notify users when they
have lost the connection to a networked file and are working on a local copy of the file. If
Turn off reminder balloons is set to Enabled, the system hides the reminder balloons, and
prevents users from displaying them.
• Consider whether administrators need to explicitly disable a feature. You must understand the
differences between the Not Configured state (which implies that the administrator does not
care) and the Disabled state (which means that the administrator cares and wants to implement
a very specific behavior).
• Make sure that your documentation team is involved with creating the Explain text. Well-
written Explain text can help reduce support calls.
• Each component should expose a user interface that always reflects the policy setting that is
applied. For example, if a Group Policy setting removes the ability for the user to set a
preference for a component, the user interface should clearly indicate this and access to that
particular item in the component should be removed (for example, the item is disabled and
grayed-out, or it is not visible to users).
Creating Custom .Adm Files
You can create custom .adm files to extend the use of registry-based policy settings to new
applications and components. Creating and implementing custom .adm files involves the following
tasks:
• The application or component must be enabled to use Group Policy-enabled. Many off-the-
shelf applications for Windows are already Group Policy-enabled. For example, Microsoft
Office is developed to work with Group Policy settings, and applicable .adm files are included
in the Office Resource Kit. If a developer’s application is not already Group Policy-enabled,
the developer must write code that changes the application so that an administrator can apply
the application-specific Group Policy settings. For more information, see Microsoft Platform
Software Development Kit at http://go.microsoft.com/fwlink/?LinkId=20540.
• After the application or component is Group Policy-enabled, a developer or administrator must
write an .adm file that includes the appropriate settings for that application. Custom .adm files
are created as text files that describe policy settings. A framework language is provided for
.adm files, as described in “Language Reference for Administrative Template Files” later in
this document. When you create a new policy setting in a custom .adm file, it is more efficient
if you copy and modify existing policy settings that are similar to the ones that you want to
create, rather than write new policy settings from scratch. To use an existing .adm file as a
template for a custom .adm file, first copy the original .adm file into a new file with a different
file name, and then edit the new file. Similar policy settings can provide:
• A model to use as a basis for your Group Policy settings.
• Consistency with available policy settings.
Language Reference for Administrative Template Files 17
• Information about possible interactions between policies.
• Administrators use the Group Policy Management Console to view and manage GPOs and use
the Group Policy Object Editor to view the Administrative Templates node under Computer
Configuration or User Configuration.
Caution
Treat the .adm files that ship in the operating
system as readonly files. These files are often
updated when you install service packs or future
releases of the product. Policy settings should never
be removed from .adm files that are included in the
operating system by default.
Keep in mind that by itself, the .adm file does not actually apply Group Policy to the client
computer. You must have a corresponding component or application that responds to the registry
key that is affected by the policy setting.
The following code example illustrates a simple .adm file.
CLASS USER
CATEGORY !!DesktopLockDown
POLICY !!DisableTaskMgr
EXPLAIN !!DisableTaskMgr_Explain
VALUENAME "DisableTaskMgr"
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
KEYNAME "Software\Policies\System"
END POLICY
END CATEGORY
[strings]
DisableTaskMgr="Disable Task Manager"
DisableTaskMgr_Explain="Prevents users from starting Task Manager"
DesktopLockDown="Desktop Settings"
This sample code exists in the System.adm file. It allows you to configure a policy called Disable
Task Manager, which appears in the Group Policy Object Editor namespace in User
Configuration\Administrative Templates\Desktop Settings.
This policy setting defines the following behavior:
• If an administrator enables this policy setting, it creates a registry key called DisableTaskMgr
and set its value to 1. The VALUEON tag implements this behavior. In this case, users cannot
start Task Manager.
• If an administrator disables this policy setting, it creates a registry key called
DisableTaskMgr and set its value to 0. The VALUEOFF tag implements this behavior. In
this case, users can start Task Manager.
18 Using Administrative Template Files with RegistryBased Group Policy
• In both cases, the DisableTaskMgr registry key is created below
HKCU\Software\Policies\System in the registry. Note that the key is created under CLASS
USER and not under CLASS MACHINE because this is a user policy setting.
• If an administrator sets this policy setting to Not Configured, it deletes the registry key called
DisableTaskMgr. In this case, users can start Task Manager.
Table 4 lists where registry-based policy settings are stored in any of the four approved registry
locations for Group Policy.
Table 4 Approved Registry Key Locations for Group Policy
Settings
Computer Policy Settings User Policy Setting:
HKLM\Software\Policies (The HKCU\Software\Policies (The
preferred location) preferred location)
HKLM\Software\Microsoft\Window HKCU\Software\Microsoft\Windows
s\CurrentVersion\Policies \CurrentVersion\Policies
The registry keys are created when a GPO containing an enabled or disabled registry-based policy
setting is applied. If the GPO is later removed (for example, unlinked from an OU in which a user
resides), the registry keys associated with it are also removed. Security prohibits a standard user
from changing the registry keys. A local administrator can overwrite these registry keys, and thus
change or disable the behavior of the policy setting. For this reason, as a Group Policy
administrator, you might want to enable the Registry policy processing policy setting (located in
Computer Configuration\Administrative Templates\System\Group Policy)and select the
following option: Process even if the Group Policy objects have not changed.
Selecting this option updates and reapplies the policy settings even if you -- the Group Policy
administrator -- have not changed the policy settings. This provides an additional safeguard in the
event that local administrators try to change policy settings through the registry. Policy settings are
reapplied during the regular background refresh of Group Policy, which occurs by default every 90
minutes with a randomized delay of up to 30 minutes.
How to Write a Simple
.Adm File for Registry
based Group Policy
This section shows you how to create a simple .adm file for delivering registry-based Group Policy
settings. The code samples provided are parts of a single .adm file. Please refer to “Language
Reference for Administrative Template Files,” later in this document for full details about the .adm
language.
The sections of the sample .adm file illustrate how to set a registry value to:
Language Reference for Administrative Template Files 19
• Turn a feature on or off.
• Allow the selection of one or more values from a list.
• Display a list with add and remove buttons.
• Enter EDITTEXT and static text.
• Display a numeric list to the administrator.
• Display a numeric list to the administrator, using a spin control.
• Display an actionable list to an administrator.
To Set a Registry Value to Turn a Feature ON or OFF
This sample code displays a check box. The value is set in the registry with the REG_DWORD
type. By default, the check box is clear. If the check box is selected, it writes the value 1 to the
registry. If the check box is clear, it writes the value 0 to the registry.
CLASS USER
CATEGORY!!SampleCategory
KEYNAME "SOFTWARE\Policies\Microsoft\ADM_Samples"
POLICY!!Sample_ADM_FeatureOnOff
#if version >= 4
SUPPORTED!!SUPPORTED_WindowsXPSP1
#endif
EXPLAIN!!Sample_ADM_FeatureOnOff_Help
VALUENAME "ADM_Sample_FeatureOnOff"
VALUEON 1
VALUEOFF 0
END POLICY
END CATEGORY
To Set a Registry Value to Allow the Selection of One
or More Values from a List
You can use DROPDOWNLIST to display a combo box with a drop-down style list. You can pre-
populate the list of items that are displayed in the list and the corresponding registry value to be
written for each item in the list.
20 Using Administrative Template Files with RegistryBased Group Policy
POLICY!!Sample_ADM_DropDownList
#if version >= 4
SUPPORTED!!SUPPORTED_WindowsXPSP1
#endif
EXPLAIN!!Sample_ADM_DropDownList_Help
PART!!Sample_ADM_DropDownList DROPDOWNLIST REQUIRED
VALUENAME "Sample_ADM_DropDownList"
ITEMLIST
NAME !!Sample_ADM_DropDownList_Always VALUE NUMERIC 1 DEFAULT
NAME !!Sample_ADM_DropDownList_WorkStationOnly VALUE NUMERIC 2
NAME !!Sample_ADM_DropDownList_ServerOnly VALUE NUMERIC 3
END ITEMLIST
END PART
END POLICY
To Set a Registry Value to Display a List with Add and
Remove Buttons
You can use registry-based Group Policy to display a list box that contains Add and Remove
buttons.
By default, only one column appears in the list box, and for each entry, a value is created where the
name and value are the same. For example, a name entry in the list box creates a value called name
that contains data labeled name.
POLICY!!Sample_ADM_ListBox
#if version >= 4
SUPPORTED !!SUPPORTED_WindowsXPSP1
#endif
EXPLAIN!!Sample_ADM_ListBox_Help
PART!!Sample_ADM_DropDownList LISTBOX
KEYNAME "Sample_ADM_ListBox"
END PART
END POLICY
To Set a Registry Value for EDITTEXT and Static Text
This setting allows the user to type alphanumeric text in an edit field. The text is set in the registry
with the REG_SZ type.
The following code is an example of how you can use the EDITTEXT PART type.
POLICY!!Sample_ADM_EditText
#if version >= 4
SUPPORTED !!SUPPORTED_WindowsXPSP1
#endif
EXPLAIN!!Sample_ADM_EditText_Help
PART!!Sample_ADM_EditText EDITTEXT
VALUENAME "ADM_Sample_EditText"
END PART
