How Windows 2000 Manages Group Policy Templates

Microsoft Windows 2000 manages Group Policy Template (GPT) updates inside the SYSVOL folder through structured file storage, numerical version tracking, and multi-master replication via the File Replication Service (FRS). This article explains how changes made in administrative tools are written to the SYSVOL directory structure, synchronized with Active Directory, and ultimately detected and applied by client endpoints across the domain.

Storage Structure of the GPT

In Windows 2000, every Group Policy Object (GPO) consists of two distinct halves: the Group Policy Container (GPC) stored in Active Directory, and the Group Policy Template (GPT) stored in the file system. The GPT resides within the shared SYSVOL folder on domain controllers, located at:

%SystemRoot%\SYSVOL\sysvol\<domain-name>\Policies\<GPO-GUID>\

Inside this folder, the GPT contains specific subdirectories and configuration files:

  • Machine: Stores computer-specific settings, startup/shutdown scripts, and Registry.pol.
  • User: Stores user-specific settings, logon/logoff scripts, and Registry.pol.
  • GPT.INI: The core configuration file located at the root of the GPO's GUID folder that tracks the template's synchronization state and version number.

The Update and Versioning Process

When an administrator modifies a policy using the Group Policy snap-in in the Microsoft Management Console (MMC), the console connects by default to the domain controller holding the Primary Domain Controller (PDC) Emulator FSMO role.

Once an administrator commits a change, the tool updates the relevant files within the Machine or User subdirectories and increments the version counter inside GPT.INI. The Version entry in GPT.INI is a 32-bit integer that stores two distinct 16-bit values:

  • The lower 16 bits represent the User configuration version.
  • The upper 16 bits represent the Machine (Computer) configuration version.

Simultaneously, the administrative tool increments the corresponding versionNumber attribute of the GPC object in Active Directory. Keeping these two numbers identical is required for Windows 2000 to consider the policy consistent.

Replication Through File Replication Service (FRS)

Because SYSVOL is a distributed file system shared by all domain controllers, changes made on the PDC Emulator must propagate throughout the domain. Windows 2000 relies on the File Replication Service (FRS) to detect file-system changes within the SYSVOL tree.

When the GPT files and GPT.INI are updated, the local NTFS Change Journal logs the alterations. FRS reads these journal entries, stages the modified files, and uses remote procedure calls (RPC) to transfer the changes to partner domain controllers according to the Active Directory replication topology. Because Active Directory replication and FRS operate on separate schedules and mechanisms, a temporary delay—known as replication latency—can occur where the GPC in Active Directory and the GPT in SYSVOL have mismatched version numbers until both replication cycles complete.

Client Detection and Policy Application

Windows 2000 client computers evaluate Group Policy during system startup, user logon, and during periodic background refreshes (occurring every 90 minutes by default, with a randomized 30-minute offset).

During processing, the client performs the following steps:

  1. Queries Active Directory to find the applicable GPOs and their current GPC version numbers.
  2. Accesses the SYSVOL share on its assigned domain controller and reads GPT.INI to retrieve the GPT version number.
  3. Compares the version numbers against its locally cached history in the client registry.
  4. If the GPC and GPT version numbers match each other and are higher than the local cached version, the client downloads the updated templates, executes scripts, and parses the Registry.pol files to apply the new settings. If the GPC and GPT versions do not match, the client skips processing for that cycle to prevent applying partially replicated, corrupted policies.