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:
Microsoft