A Windows client computer that is joined to a domain might not receive all Group Policy settings configured at an Active Directory domain. As a result, some endpoints might not apply the missing Group Policy Object settings, but Winlogon can help diagnose and fix the problem.
For example, an Active Directory administrator may have configured wallpaper and wireless settings in a Group Policy Object (GPO) to be applied to a set of Windows machines. You notice that the clients are receiving the wallpaper settings perfectly, but they fail to apply the wireless policy settings configured through "Wireless Network (IEEE 802.11) Policies" node in GPO. The desktop administrator must then find the common cause of missing Group Policy settings.
Two types of components are implemented in GPO architecture: server-side components and client-side components. Server-side components include the Group Policy Editor, which an Active Directory admin can use to configure GPO settings. The client-side component is implemented on Windows clients to process GPO settings. The client-side component is also known as the client-side extension (CSE).
The Winlogon component, running as a process on Windows computers, handles the processing of GPO settings. The Winlogon process calls CSEs to process GPO settings at computer startup, user logon and at the Group Policy refresh interval. CSE is implemented as a Dynamic Link Library (DLL), and each CSE can determine not to perform GPO processing at any of these points.
How does Winlogon know which CSE is responsible for processing GPO settings?
The Windows registry is a big repository for storing information. Most applications and operating system components use the registry database to store information, which Windows components use to take necessary actions.
For example, when a Windows computer starts, it checks the location of the paging file in the Registry database to be initialized during startup. Similarly, the Winlogon process uses the registry to determine the location of a CSE before it instructs CSE DLL to start processing the Group Policy settings.
Each CSE is registered with the Winlogon OS at the following registry key location: HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\
Winlogon\GPExtensions. Each CSE is identified by a key named after the global unique identifier (GUID) of the extension.
As shown in the screenshot above, the "Wireless Group Policy" settings of a GPO are processed by the "wlgpclnt.dll" DLL, which has a well-known GUID assigned to it. Some common CSEs and GUIDs are shown below with their DLL names:
|Client-side extension GUID
A CSE DLL for the corresponding GPO node must exist on client computers before the policy settings can be processed and applied. For example, if the CSE DLL "Dskquota.dll" is not present or is corrupted, then GPO settings related to the Disk Quotas will not be applied or processed.
Windows XP has fewer CSEs than Windows 7 and Windows 8. For example, Windows XP computers do not know how to process settings related to Drive Mappings because there is no CSE on Windows XP computers to process settings from "Drive Maps" node in GPO.
If you need Windows XP computers to process settings from "Drive Maps" and other Preference Settings, you must download and install CSEs for them.
Use of CSEs during computer startup
As stated earlier, Winlogon process triggers CSEs to process policy settings from a GPO node. The following events take place when a computer starts:
1. A Windows client computer, which is joined to an Active Directory domain, starts.
2. The client authenticates with Active Directory domain controller.
3. The Winlogon process invokes itself and starts processing the policy settings from each node of the GPO.
4. The Winlogon process needs to know the CSE which is responsible for processing the settings from a GPO node. It determines the location of the CSE DLL at the HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion
\Winlogon\GPExtensions registry location. Winlogon identifies the CSE by its well-known GUID.
5. Winlogon instructs corresponding CSEs to process the GPO settings. For example, for "Administrative Templates" GPO node, the "userenv.dll" CSE is called to process and apply settings from "Administrative Templates" node in GPO. Similarly, "Dskquota.dll" CSE is called to process "Disk Quota" policy settings from GPO node.
More about Windows Group Policy settings
Using Group Policy Objects and checking refresh status
Group Policy settings differ among Windows versions
What are Group Policy Preferences?
How to apply a GPO at the organizational unit level
Note: Here the GPO processing is handled by the individual CSE. The Winlogon's task is just to instruct CSEs to take necessary actions for GPO processing.
6. CSE generates an Event ID 4016, which indicates that the CSE processing has started.
7. Once the processing is completed, an Event ID 5016 is logged in the Application Log, indicating that the CSE has successfully processed the GPO settings.
8. In case of any errors during CSE processing, the Event ID 6016 or 7016 will be logged in the Application Event Log to indicate a problem with the CSE processing. The CSE processing could result in a warning or error if the following conditions are true:
- The CSE or well-known GUID is missing at the above registry location.
- Winlogon can find the GUID but cannot get the location of the CSE DLL.
- Winlogon does not have permission to access the above registry key.
- The CSE DLL is missing or corrupted.
- There is no corresponding CSE available to process GPO settings.
The Winlogon process uses the registry database to determine the location of a CSE to process the settings from a GPO node. As you can see, if there is no corresponding CSE available to process the GPO settings, or if the CSE DLL is corrupted, the policy settings from a GPO node will not apply. That's why some GPO settings might be missing on Windows clients.
About the author:
Nirmal Sharma is a MCSEx3, MCITP and was awarded Microsoft MVP award in Directory Services. He specializes in Directory Services, Microsoft Clustering, Hyper-V, SQL and Exchange and has been involved in Microsoft technologies since 1994. Sharma can be reached at [email protected].