How Windows 98 Enforced System Policy Restrictions

In Microsoft Windows 98, system administrators managed user environments and enforced restrictions using the System Policy Editor (POLEDIT.EXE). This article explains how the tool operated, how policy files were generated and deployed across local or networked environments, and how the underlying Windows Registry was modified to limit user capabilities, such as hiding desktop elements, disabling the MS-DOS prompt, and restricting access to administrative settings.

The Role of the System Policy Editor

The System Policy Editor (POLEDIT.EXE) was an administrative utility included on the Windows 98 installation media. Unlike modern Group Policy infrastructure in Windows NT-based systems, Windows 98 relied on policy templates (.ADM files) that defined configurable registry entries. Administrators used this interface to toggle restrictions on a per-user, per-group, or per-computer basis.

The editor utilized three-state checkboxes for configuration:

  • Checked: Explicitly enforces the restriction by writing a specific value to the registry.
  • Unchecked: Explicitly removes the restriction by deleting the value or setting it to zero.
  • Grayed Out: Leaves the existing registry setting untouched, preserving the client's current state.

The CONFIG.POL File and Registry Merging

Windows 98 did not run an active background service to enforce system policies. Instead, policies were applied through direct modifications to the Windows Registry (USER.DAT and SYSTEM.DAT) during the logon process.

  1. Policy File Generation: Administrators created and configured rules in the editor, saving the output as a central binary file named CONFIG.POL.
  2. Network Distribution: In a networked environment (using Microsoft Windows NT Server or Novell NetWare), CONFIG.POL was stored in a standardized shared directory—typically the NETLOGON share on an NT domain controller.
  3. Logon Execution: When a user authenticated over the network via the "Client for Microsoft Networks," the Windows 98 logon process automatically checked the authenticating server for the presence of CONFIG.POL.
  4. Registry Overwrite: If found, the operating system downloaded the file and merged its settings into the local registry before launching the Windows Explorer shell (EXPLORER.EXE).

User-specific settings overwritten keys located in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies, while computer-specific settings altered HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies.

Local Enforcement and Standalone Systems

For standalone computers without a network domain, administrators could enforce policies locally:

  • Direct Registry Mode: Running POLEDIT.EXE directly on the target PC allowed an administrator to select "Open Registry," adjust policies, and save changes straight into the local registry.
  • Manual Path Configuration: Administrators could configure the local registry's UpdateMode under System\CurrentControlSet\Control\Update to load a local CONFIG.POL file stored on the local hard drive rather than querying a network share.

Common Policy Restrictions

Policy enforcement in Windows 98 worked largely through shell-level cooperations. When the Explorer shell loaded, it checked specific subkeys within the Policies registry hierarchy. Common restrictions included:

  • Explorer Policies (Policies\Explorer):
    • NoRun: Removed the Run command from the Start menu.
    • NoFind: Removed the Find/Search tool.
    • NoDrives: Hid specific drive letters in "My Computer" and Windows Explorer.
    • NoClose: Prevented the user from shutting down or restarting the computer.
  • System Policies (Policies\System):
    • DisableRegistryTools: Blocked users from launching REGEDIT.EXE to revert policy changes.
    • NoDispCPL: Prevented opening the Display Control Panel.
  • WinOldApp Policies (Policies\WinOldApp):
    • Disabled: Prevented the execution of MS-DOS prompts and 16-bit DOS-based applications, preventing users from bypassing the Windows GUI.

Structural Limitations of Enforcement

Because Windows 98 lacked the native Access Control Lists (ACLs) and protected subsystem architecture of Windows NT, policy enforcement was primarily client-side and shell-based. If a user booted the system into Safe Mode, started from a DOS boot diskette, or pressed "Cancel" at the standard network logon dialog (unless the MustBeValidated registry setting was enabled), the system would bypass the policy download and launch the shell without downloading CONFIG.POL. Despite these architectural limitations, System Policy Editor served as the primary administrative tool for standardizing the Windows 98 user experience across corporate environments.