Overview of Registry-Based Policy and Administrative Template Files

Applies To: Windows Server 2003

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.

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).

For more information about the architecture of Administrative Templates, see Administrative Templates Extension Technical Reference at https://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.  

• 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 Registry-Based 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.

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

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.

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