How Administrative Templates Extension Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Administrative Templates are the primary means of configuring the client computer’s registry settings through Group Policy. Organizations benefit the most by using Administrative Templates policy settings in a Windows Server 2003 environment with Active Directory installed and Windows XP client computers.

In this section

• Administrative Templates Extension Architecture

• Administrative Templates Extension Physical Structure

• Administrative Templates Extension Processes and Interactions

• Network Ports Used by Administrative Templates Extension

• Related Information

Administrative Templates Extension Architecture

The following diagram shows how components interact in implementing Administrative Templates policy settings.

Administrative Templates Extension Architecture

Components and protocols significant to Administrative Templates Extension are included in the following table.

Administrative Templates Components

Administrative Templates Extension Physical Structure

The following figure shows the files used by the Administrative Templates Extension.

Descriptions of these files are included in the following table.

Physical Structure Components

Administrative Templates Extension Processes and Interactions

The Administrative Templates CSE is invoked by the Group Policy engine with a list of GPOs to be applied. Each GPO contains a Registry.pol file. In order to modify settings in the registry, the Administrative Templates CSE parses the ntuser.pol files to remove previously set registry settings, returning the registry settings to a “default” state. The Administrative Templates Extension then retrieves the Registry.pol files from each GPO in the list and applies the Registry.pol changes to the local registry in order of precedence for the GPOs. Data is also written to WMI by the Administrative Templates Extension for RSoP to retrieve later. As the Registry.pol files are processed, the ntuser.pol file is created to centrally manage the registry keys that have been set. Events are written to the event log during this process. If debugging is enabled, data is written to the userenv.log as well.

Unlike other CSEs, the Administrative Templates CSE is coded within the Group Policy engine as a piece of userenv.dll. As a result, the extension is always called whenever Group Policy is processed. In addition, the Administrative Templates CSE is always called first by the Group Policy engine, in advance of any other CSEs that might be processed. Administrative Templates CSE will run only if there are any changes in any the GPOs that the Administrative Templates CSE has enabled.

True Policies and Preferences

The Administrative Templates CSE has control over a part of the registry for both user and computer registry hives and treats these specially. These parts are for the computer and user hives respectively:

• HKEY_LOCAL_MACHINE\SOFTWARE\policies (preferred location)

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies

• HKEY_CURRENT_USER\SOFTWARE\policies (preferred location)

• HKEY_ CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\policies

These trees cannot be modified by a non-administrator. Because all keys and values beneath these paths are erased before applying the resultant registry policy settings, the registry policies applied in these subtrees will only persist as long as a valid Group Policy setting exists. Policy settings that are stored in these specific locations of the registry are known as true policies.

All the policy settings in the standard Administrative Template files that shipped with Windows 2000 Server and Windows Server 2003 use true policies. This prevents the behavior that was often present in Windows NT 4.0, whereby System Policies resulted in persistent settings in the user and computer registry. The policy remained in effect until the value was reversed, either by a counteracting policy or by editing the registry. These settings are stored outside the approved registry locations listed and are known as preferences.

Although Group Policy settings take priority over preferences, they do not overwrite or touch the registry key used by the preference. If both a policy and preference are present, the preference will be successfully restored if the policy is removed or disabled. Preference settings persist in the registry until they are reversed by a counteracting policy setting or by editing the registry.

The configuration of the wallpaper on the Windows desktop illustrates an example of simultaneous policy and preference settings. In the Windows shell, it is possible for a user to configure their desktop wallpaper using the Display icon in Control Panel. An administrator can also configure desktop wallpaper using a default policy setting called Active Desktop Wallpaper, which can be found under User Configuration\Administrative Templates\Desktop\Active Desktop node in Local Group Policy Editor or GPMC.

The following table lists the resultant behavior for Group Policy settings and preferences.

Results of Group Policy Settings and Preferences

It is common practice to offer both a preference and a policy setting for most applications. The application reads the registry keys and uses them accordingly. Registry-based data is appropriate for many types of policy settings and is also the least complex way to create custom policy settings. In addition, Registry-based policy managed through administrative template files automatically supports Resultant Set of Policy (RSoP) capabilities.

Registry.pol Files

Registry.pol files are formed by the following process:

• When you start Local Group Policy Editor or GPMC, a temporary registry tree is created that consists of two nodes: USER and MACHINE.

• As you navigate the Administrative Templates node of the Local Group Policy Editor or GPMC, .adm file nodes are displayed. The .adm files within Local Group Policy Editor or GPMC nodes are loaded dynamically when a particular node is selected, and the .adm file is then cached.

• When a policy is selected in the details pane (the right side of the Local Group Policy Editor or GPMC), the temporary registry is queried to determine whether the selected policy already has registry values assigned to it; if it does, those values are displayed in the Policy dialog box. If the selected policy does not have a registry value assigned to it, the default value from the .adm file or from the associated MMC snap-in extension is used.

• After you modify a policy, the registry values that you specify are written to the appropriate portion of the temporary registry (either MACHINE or USER).

• When you close Local Group Policy Editor or GPMC, the temporary registry hives are exported to the Registry.pol files in the appropriate folders of the Group Policy template: GPT\Machine and GPT\User.

• The next time you start Local Group Policy Editor or GPMC for the same Group Policy object for which you have previously set Group Policy settings, the registry information from the corresponding Registry.pol files is imported into the temporary registry tree. Therefore, when you view the policy settings, they reflect the current state.

Registry.pol in the Local GPO

During processing, the local Registry.pol files in the Machine and User directories of the Local GPO are read. There is a Registry.pol file in both the Machine and User directories of the Local GPO directory structure for machine- and user-based policies respectively. The Local GPO is distinct from domain policy in that it updates the Registry.pol file as each policy setting is set and refreshes policy settings on the computer at the time each policy setting is configured.

.Adm Files

Administrative Template files describe where Registry-based policy settings are stored in the registry, by associating a description and explain text with a registry key and value. Local Group Policy Editor or GPMC displays only the descriptive text and provides various dialog boxes that you can use to modify the setting. A section of the user’s hive is mapped to the registry policy setting. .Adm files, unlike Registry.pol files, do not affect the actual policy processing by the Administrative Templates CSE. .Adm files only affect the display of the policy settings in the Local Group Policy Editor or GPMC snap-in. If an .adm file is removed, the settings corresponding to the .adm file will not appear in Local Group Policy Editor or GPMC. However, the policy settings that are configured from the .adm file will remain in the Registry.pol file and continue to apply to the appropriate target client or user.

Each administrative workstation that is used to run Local Group Policy Editor or GPMC stores .adm files in the Windows\Inf folder. When GPOs are created and first edited, the .adm files from this folder are copied to the \adm subfolder in the Group Policy template (GPT).

By default, when GPOs are edited, Local Group Policy Editor or GPMC compares the time stamps of the .adm files in the workstation’s Windows\Inf folder with those that are stored in the GPT \adm folder. If the workstation’s files are newer, Local Group Policy Editor or GPMC copies these files to the GPT \adm folder, overwriting any existing files of the same name. This comparison occurs when the Administrative Templates node (computer or user configuration) is selected in Local Group Policy Editor or GPMC, regardless of whether you actually edit the GPO. The .adm files stored in the Group Policy template can be updated by viewing a GPO in Local Group Policy Editor or GPMC. The process is simplified for local GPOs where all adm files are stored locally in a single adm folder.

Because of the importance of time stamps on .adm file management, the editing of system-supplied .adm files is not recommended. If a new policy setting is required, Microsoft recommends that you create a custom .adm file. This prevents the replacement of system-supplied .adm files when service packs are released.

Using the latest .adm files

As a general rule, each operating system or service pack release includes a superset of the .adm files provided by earlier releases, including policy settings that are specific to operating systems that are different to those of the new release. For example, the .adm files that are provided with Windows Server 2003 include all policy settings for all operating systems, including those that are only relevant to Windows 2000 or Windows XP Professional. This means that only viewing a GPO from a computer with the new release of an operating system or service pack effectively upgrades the .adm files.

How .adm files are handled by Local Group Policy Editor or GPMC

By default Local Group Policy Editor or GPMC attempts to read .adm files from the GPO (from the Sysvol on the domain controller). Alternatively, the .adm file can be read from the local workstation computer. This behavior can be controlled by a policy setting.

By default, if the version of the .adm file found on the local computer is newer (based on the time stamp of the file) than the version on the Sysvol, the local version is copied to the Sysvol and is then used to display the settings. This behavior can be controlled by a policy setting.

If the GPO contains registry settings for which there is no corresponding .adm file, these settings cannot be seen in Local Group Policy Editor or GPMC. However, the policy settings are still active and will be applied to users or computers targeted by the GPO.

How .adm files are handled by Group Policy Management Console

GPMC uses .adm files to display the friendly names of policy settings when generating HTML reports for GPOs, Group Policy Modeling, and Group Policy Results.

By default, GPMC uses the local .adm file, regardless of time stamp. If the file is not found, GPMC will look in the GPO’s directory on Sysvol.

You can specify an alternate path for where to find .adm files. If specified, this takes precedence over the previous locations. GPMC never copies the .adm file to the Sysvol.

Extensions that use Administrative Templates

There are additional extensions that are located within the Administrative Templates for Computer Configuration in the Local Group Policy Editor or GPMC. These are:

• Disk Quotas

• QoS Packet Scheduler.

Disk Quotas

Disk Quotas are used to manage NTFS file system disk space. Administrators use the Disk Quotas Extension to configure Group Policy for Disk Quotas on target computers. The Disk Quotas Extension includes a server-side extension and a client-side extension.

Administrators manage Disk Quotas policy settings under the following node in the Local Group Policy Editor or GPMC: Computer Configuration\Administrative Templates\System\Disk Quotas. The Disk Quotas node is the user interface for the server-side component of the Disk Quotas extension. There is no user interface for the client-side component, although you can view changes made by the CSE on the Quota Property tab for NTFS volumes. The Group Policy engine, using the Disk Quotas client-side extension component, applies settings to the target computer.

The Disk Quotas CSE is registered with Winlogon in the registry at the following path: {HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions\{3610eda5-77ef-11d2-8dc5-00c04fa31a66}

QoS Packet Scheduler

QoS Packet Scheduler Extension is an extension to Local Group Policy Editor or GPMC. Administrators use QoS Packet Scheduler Extension to set QoS Packet Scheduler Group Policy.

QoS Packet Scheduler Extension is included in the same binary (gptext.dll) as the Scripts, IP Security, and Wireless Group Policy extensions. Administrators manage QoS Packet Scheduler policy settings under the following node in the Local Group Policy Editor or GPMC: Computer Configuration\Administrative Templates\Network\QoS Packet Scheduler.

The QoS Packet Scheduler CSE is registered with Winlogon in the registry at the following path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ GPExtensions\{426031c0-0b47-4852-b0ca-ac3d37bfcb39}

Network Ports Used by Administrative Templates Extension

Administrative Templates CSE communicates with Active Directory using LDAP to complete the following tasks:

• GPO list retrieval.

• Group Policy container retrieval.

It uses SMB to complete the following tasks:

• Request DFS referral for \\domainname\sysvol.

• SysvolDFS replica location \\dcname.domainname\sysvol.

• Open and read GPT.INI.

• Return GPT.INI.

• Open and read GPT settings files.

• Return GPT file.

Port Assignments for Group Policy Administrative Templates

Related Information

The following contains additional information that is relevant to this section.

• “Group Policy Settings Reference” in the Tools and Settings Collection