How Windows 2000 Processes ADM Files in Group Policy

This article provides an overview of how Microsoft Windows 2000 uses Administrative Template (.adm) files to configure and enforce system settings through Group Policy. It explains the end-to-end lifecycle of these files, detailing how the Group Policy snap-in parses templates to generate the administrative interface, how settings are compiled into policy files within the SYSVOL share, and how client machines ultimately apply those registry modifications.

Template Storage and SYSVOL Replication

In Windows 2000, Administrative Templates are plain-text markup files that define which registry keys and values can be modified through the Group Policy interface. When an administrator creates or edits a Group Policy Object (GPO) using the Group Policy Microsoft Management Console (MMC) snap-in, the system automatically copies the default .adm files (such as system.adm, inetres.adm, and conf.adm) from the local %SystemRoot%\Inf directory directly into that specific GPO’s folder structure within SYSVOL.

Specifically, these files are placed in:
\\<Domain>\SYSVOL\<Domain>\Policies\<GPO-GUID>\Adm\

Because Windows 2000 stores a full set of .adm files inside every single GPO, each policy object consumes approximately 4 megabytes of disk space in SYSVOL. These files are replicated across all domain controllers in the domain via the File Replication Service (FRS).

Parsing and Interface Generation

The .adm file does not apply policies directly to client machines; it acts solely as a blueprint for the administrative interface. When an administrator opens a GPO in the Group Policy Editor, the console reads and parses the syntax contained in the .adm files residing in that GPO's Adm directory.

The editor interprets specific hierarchical tags:

  • CLASS: Directs the setting to either MACHINE (Computer Configuration) or USER (User Configuration).
  • CATEGORY: Defines the organizational folder tree displayed in the MMC.
  • POLICY: Defines the individual configurable setting.
  • KEYNAME and VALUENAME: Specify the target registry paths and values to be modified on the endpoint.
  • PART: Defines the UI control type used for user input (such as checkboxes, text boxes, or dropdown lists).

Once parsed, the Group Policy Editor presents these directives as human-readable policy nodes under the "Administrative Templates" folders.

Creation of the Registry.pol File

When an administrator changes a setting from "Not Configured" to "Enabled" or "Disabled," the Group Policy Editor does not update the .adm file. Instead, it writes the corresponding registry keys, value names, data types, and values into a binary file named registry.pol.

This file is saved within the GPO’s SYSVOL directory:

  • Computer settings are written to <GPO-GUID>\Machine\registry.pol.
  • User settings are written to <GPO-GUID>\User\registry.pol.

Once registry.pol is saved, the role of the .adm file in the configuration pipeline is complete.

Client-Side Processing

Windows 2000 client computers never read, parse, or download .adm files during policy refresh. Instead, policy enforcement on the client proceeds through the following steps:

  1. Discovery and Evaluation: During startup (for computer policies) or user logon (for user policies), as well as during periodic background refreshes (every 90 minutes by default), the client queries Active Directory to determine which GPOs apply to it based on site, domain, and organizational unit (OU) membership.
  2. Retrieval: The client connects to the SYSVOL share of a domain controller and downloads the relevant registry.pol file.
  3. Registry Application: The Windows 2000 Registry Client-Side Extension (CSE)—implemented in userenv.dll—reads the binary entries within registry.pol and writes them directly to the local system registry under HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER.

Managed Policies vs. Tattooing

Windows 2000 distinguishes how policies behave based on the registry path defined in the .adm template:

  • True Policies: Settings targeted at the dedicated policy subkeys (\Software\Policies and \Software\Microsoft\Windows\CurrentVersion\Policies) are strictly managed. If the GPO is later unlinked or deleted, the Registry CSE automatically removes the values, reverting the system to its prior state.
  • Preferences (Registry Tattooing): If a custom .adm file targets registry locations outside the standard policy subkeys, the settings are written permanently to the client's registry. If the GPO is removed, the values persist until manually deleted or overwritten by another policy.