The Basics of Group Policies
Published Mar 15 2019 05:16 PM 14.3K Views
First published on TECHNET on Jun 05, 2007

The Performance team handles Group Policies for several different components - most notably Printing, Internet Explorer and Terminal Server.  In most environments, the Active Directory administrator handles the design, implementation and maintenance all of the group policies - even if another group is responsible for the technologies affected by the policies.  When an issue arises with one of these technologies, often it is the administrator for that system who is trying to troubleshoot the problem - who may not know much about the policies in place.  So today we're going to go over some basic Group Policy concepts.

The primary purpose of Group Policy is to apply policy settings to computers and users in an Active Directory domain to enable IT administrators to automate one-to-many management of users and computers.  This simplifies administrative tasks and reduces IT costs.  Administrators can efficiently implement security settings, enforce IT policies, and distribute software consistently across a given site, domain, or range of organizational units.

The Group Policy engine is the infrastructure that processes Group Policy components including server-side snap-in extensions and client-side extensions.  It is a framework that handles client-side extension (CSE) processing and interacts with other elements of Group Policy.  The Group Policy engine is contained within userenv.dll which runs inside winlogon.exe.  So let's take a quick look at the Group Policy architecture:

When a client logs in to the Active Directory, it processes the appropriate group policies based on its membership within the domain, within a specific group, or within an organizational unit.  For example, if your machine is a member of an AD domain, then there will be a set of domain-wide policies that are applied to the machine when it is booted up.  There may also be policies applied based on where the machine is located geographically, or based on which business unit the machine belongs to.  The same principle applies to users.

The Group Policy Objects themselves are located on the SYSVOL share of the domain controllers within the AD.  Once the policies are brought down to the client, the individual client-side extensions (CSE) will apply the policies to the appropriate areas.

Client-Side Extensions (or CSE's) are called by the Winlogon process at computer startup, user logon and at the Group Policy refresh interval.  Each CSE is registered with Winlogon in the registry.  This registration information includes a DLL and a DLL entry point (function call) by which the CSE processing can be initiated.  The Winlogon process uses these to trigger Group Policy processing.  Each extension can opt not to perform processing at any of these points (for example, avoid processing during background refresh).

Each CSE is registered with Winlogon in the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions .  Each extension is identified by a key named after the GUID of the extension.  Some common extensions and GUID's are shown below:

GUID Extension Name
35378EAC-683F-11D2-A89A-00C04FBBCFA2 Administrative Templates
3610EDA5-77EF-11D2-8DC5-00C04FA31A66 Disk Quotas
B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A EFS Recovery
25537BA6-77A8-11D2-9B6C-0000F8080861 Folder Redirection
A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B Internet Explorer Maintenance
E437BC1C-AA7D-11D2-A382-00C04F991E27 IP Security
426031c0-0b47-4852-b0ca-ac3d37bfcb39 QOS Packet Scheduler
42B5FAAE-6536-11D2-AE5A-0000F87571E3 Scripts
827D319E-6EAC-11D2-A4EA-00C04F79F83A Security
C6DC5466-785A-11D2-84D0-00C04FB169F7 Software Installation

The diagram below shows the Group Policy Client-side extension components.

When a policy is created, the policy will be given a unique GUID.  A folder with this GUID will be created on the domain controller in the SYSVOL folder and then replicated to the other domain controllers.  The Group Policy template folder contains the following subfolders:

  • ADM:  Contains all of the .adm files for the GPO
  • Machine: Includes a Registry.pol file that contains the registry settings to be applied to computers (HKEY_LOCAL_MACHINE)
  • User: Includes a Registry.pol file that contains the registry settings to be applied to users (HKEY_CURRENT_USERS)

The User and Machine folders are created at install time, and the other folders are created as needed when the policy is set.  Each time GPOs are processed, a record of all of the GPOs applied to the user or computer is written to the registry.

  • GPOs applied to the local computer are stored in the following registry path:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
  • GPOs applied to the currently logged on user are stored in the following registry path:
    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History

OK - so now that you know a little bit about the behind the scenes workings of Group Policies, let's quickly cover some basic GPO tools.  The three main tools to become familiar with are gpresult , the userenv.log and Resultant Set of Policies Snap-in (rsop.msc) . GPResult is a command-line utility that can be run with several different switches to determine what policies are applying (or might apply) to a particular user on the machine on which it is executed.  The Userenv.log file is a diagnostic log to record detailed information about processing of the Group Policy engine.  The logging is enabled via the registry in the following key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon .  The specific value to set is UserenvDebugLevel .  This value is a DWORD value that should be set to 0x10002 to enable verbose logging to a log file.  The log file is written to the %Systemroot%\Debug\UserMode\Userenv.log file.

And that brings us to the Resultant Set of Policies Snap-in (rsop.msc) .  All Group Policy processing information is collected and stored in a Common Information Model Object Management (CIMOM) database on the local computer.  This information, such as the list, content, and logging of processing details for each GPO, can then be accessed by tools using Windows Management Instrumentation (WMI).  The Resultant Set of Policies Snap-in leverages WMI to list the GPO details.  RSOP functionality is only available on Windows XP / Windows Server 2003 and later Operating Systems

And that wraps up our overview of Group Policies.  In future posts, we will be looking at GPO's as they pertain to Internet Explorer, Terminal Services and other technologies supported by the Performance team.  Until next time ...

Additional Resources:

- CC Hameed

Version history
Last update:
‎Mar 15 2019 05:16 PM
Updated by: