Win Server 2008 Directory Services, Group Policy Enhancements

by Marcin Policht

Windows Server 2008 brings a host of improvements to Active Directory Group Policies. This article introduces enhancements as well as other Active Directory-related implications.

Windows Server 2008
One of the most important advantages offered by Active Directory since its inception coinciding with the release of Windows 2000 Server platform (besides its obvious benefits as an identity management solution) has been centralized administration of virtually every major facet of Microsoft-based computing environment. Christened initially as IntelliMirror (and incorporated into Zero Administration initiative for Windows), the original collection of rather loosely coupled technologies has evolved throughout the years, yielding a cohesive and highly integrated framework.

However, despite a number of major new developments and drastic departures from some of its original concepts, the core of the management area still relies on Group Policies. Starting with this article of our series, we will introduce their enhancements incorporated into Windows Server 2008 (and corresponding Active Directory-related implications).

From the architectural standpoint, Group Policy constitutes a client-server methodology, which allows you to manage different aspects of software running on Windows operating system (with a broad impact on users' computing experience, via both user- and computer-specific settings). Scope of control ranges from a single, stand-alone computer (via its Local Group Policy Objects) to entire Active Directory forest (or even beyond it, considering that Windows Server 2008 gives you ability to apply Group Policy-driven configuration across trusted forests). It can be highly granular, especially when using Item Level Targeting available in Group Policy Preference Extensions. Desired settings, assigned via a Microsoft Management Console-based utility running on an administrative workstation (interacting with Group Policy Server-Side Extensions) are reflected in corresponding changes to Active Directory configuration (in the form of Group Policy Objects residing within Group Policy Container) and to content of directory structure under SYSVOL share hosted on each domain controller (referred to as Group Policy Template).

Read More About Windows Server 2008

These changes subsequently trigger appropriate actions on target computers, carried out by Group Policy Engine and utilizing software components (implemented as Dynamic Link Libraries) known as Client Side Extensions. You can identify CSEs present on a local computer by examining its HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogonGPExtensions registry key. In both Vista and Windows Server 2008, Group Policy Engine and CSEs no longer leverage Winlogon process (as was the case with their predecessors), but function using a dedicated service, called Group Policy Client Service (gpsvc), operating within boundaries of the generic host process Svchost. This approach offers stability, security, responsiveness, and performance improvements.

To recognize other advantages of Group Policies that are of relevance in a Windows Server 2008 environment (as well as Vista, where they were introduced), it is helpful to understand the methodology used to apply their settings to intended targets. Its rules take into consideration the type of a group policy target (user or computer), its current status, and the type of settings. More specifically, domain members process group policies during their startup and subsequently attempt their refresh every 90 minutes (with a random, positive, up to 30-minute offset). For domain controllers, the equivalent interval is set at 5 minutes. Application of user-specific settings follows similar pattern, although they are initiated by a user logon — as opposed to computer startup. Note that all these values can be adjusted via Group Policies.

In general, the determination whether a refresh is needed is made based on comparison between the version of group policy recorded on the client (in the HKLMSOFTWAREMicrosoftWindowsCurrentVersionGroup PolicyHistory registry key) and that present on a local domain controller hosting its Active Directory representation. There are, however, some exceptions to this rule. For example, security settings are always reapplied every 16 hours (with a 30 minute offset) to domain member computers and every 5 minutes to domain controllers.

In addition, since certain types of configuration options (such as folder redirection or software deployment) could potentially cause a variety of undesired side effects if deployed while a user is logged on, they are activated only during a computer startup or user logon. Note, however, that this is also dependent on whether Group Policy is processed synchronously, which happens as long as the Fast Logon Optimization is not in effect. Similarly, some settings, such as new disk quotas (existing ones remain valid since they are cached locally), folder redirection, scripts, software installation or deployed printer connections are not processed if the group policy engine detects limited network connectivity to a domain controller. By default, the threshold is set at 500 Kbps of effective bandwidth, although this value can be altered via Group Policies.

Unfortunately, since earlier versions of Windows based such detection on the outcome of a simple PING test, it frequently produced misleading results (frequently due to blocking of ICMP traffic somewhere along the network path). Windows Server 2008 (as well as Vista) employ for this purpose considerably more reliable Network Location Awareness mechanism, which is capable of evaluating connectivity to domain controllers based on a sampling of TCP traffic exchanged prior to initiation of Group Policy processing (performed by the Group Policy service), without relying on ICMP response. Furthermore, since Network Location Awareness is able not only to determine network throughput but also to detect changes in the connection state and availability of a domain controller, it facilitates dynamic adjustment of Group Policy refresh, triggering it during such events as recovery from hibernation or standby, newly enabled network adapter, or the start of a wireless or Virtual Private Network session.

Architectural and functional improvements of the Group Policy client-side components have also resulted in more effective troubleshooting techniques. In addition to the already familiar Resultant Set of Policies console and GPResult command line utility (displaying effective client settings derived from a combination of all Group Policy settings that apply to it), which are still available in Vista and Windows Server 2008, you can take advantage of enhanced Event Logs.

In earlier versions of Windows, in-depth analysis of Group Policy processing involved enabling verbose logging (via registry modifications) of the core client engine (implemented as Userenv Dynamic Link Library) and each Client Side Extensions. This resulted in multiple log files. In addition, Userenv was also responsible for a number of non-Group Policy related features, making the troubleshooting process even more cumbersome. Similarly, server side logging — recording events generated by the Group Policy Management Console and Group Policy Editor related actions — had its own group of files and corresponding registry entries that needed to be modified. You can find more detailed information regarding this functionality in the Microsoft Technet article Fixing Group Policy problems by using log files.

In Vista SP1 and Windows Server 2008, inconsistent Userenv and CSE-level logging has been replaced by a new centralized system, with all relevant actions recorded in the System Event Log and Group Policy Operational Log (located in the Application and Services LogsMicrosoftWindowsGroup Policy section of the Windows Event Viewer), with the source identified clearly as "Group Policy". In addition, the content of each log entry has been supplemented with improved description of the corresponding event as well as, in case of a problem (indicated by the Error or Warning level), with suggestions regarding the most likely causes and potential remediation or resolution methods.

XML-based nodes in each entry designate individual characteristics of each event, such as ActivityID (assigned to each instance of a Group Policy refresh), type of processing (background or foreground, synchronous or asynchronous) or the name of target security principal and participating Active Directory domain controller. This, in turn, facilitates filtering and creation of custom views. You can further simplify your log analysis by taking advantage of GPLogView utility (downloadable from the Microsoft Download Center), which gathers all relevant events from both System and Group Policy Operational Event Logs. A comprehensive collection of troubleshooting information is included in the article Troubleshooting Group Policy Using Event Logs posted on the Microsoft Technet site.

When discussing the client side of Group Policy functionality in Windows Server 2008, it is also important to mention an innovative approach to its local implementation. More specifically, Windows Server 2008 (just like Vista) offers three types of Local Group Policy Objects (present on both stand-alone and domain member servers — but not on domain controllers). These MLGPOs (Multiple Local GPOs) can be assigned to individual users or pre-defined generic user types, which constitutes a significant departure from the approach employed in earlier version of Windows. It is limited to a single instance of Local Group Policy and applicable to all users, regardless of their privileges. As a result, you can define different settings for administrators and non-privileged users, or even separate them further on per user basis. The MLGPOs can be grouped into three categories, listed below in the order in which they are processed:

  • Local Group Policy - consisting of a single Group Policy Object that applies to local computers as well as to all users who log on to it. In essence, this is equivalent to the functionality built into the operating system since the release of Windows 2000 platform.
  • Administrators and Non-Administrators Local Group Policy - comprised of two GPOs (containing only user configuration settings) with one of them applied to members of local Administrators group and the other to all remaining, non-privileged users.
  • User-Specific Local Group Policy - containing only user configuration settings and targeting individual, arbitrarily selected users (which implies is one GPO per user, whose environment you decide to configure in this manner). Note that it is not possible to use local groups for this purpose.

Configuration of Local Group Policy is handled in the traditional manner by launching Group Policy Object Editor (which can be accomplished simply by running GPEDIT.MSC from the elevated Command Prompt or Run text box). To create or edit other MLGPOs, you must launch a Microsoft Management Console (e.g., by executing MMC within the security context of a privileged account), add the Group Policy Object Editor from the list of available snap-ins, and set its focus on a target user or group by clicking on Browse... command button in the Select Group Policy Object dialog box. Once the Browse for a Group Policy Object window appears, switch to Users tab and choose an appropriate account. Note that this interface also allows you remove or disable any existing MLGPOs. After you have confirmed your choices, you will be presented with the standard Group Policy Object Editor interface from which you simply apply desired settings. Note that it is possible to disable MLGPOs by using Turn Off Local Group Policy Object Processing Group Policy setting residing in the Computer ConfigurationAdministrative TemplatesSystemGroup Policy node.

This concludes our coverage of the client-side Group Policy related enhancements available in Windows Server 2008. In our next article of this series, we will focus on the topics dealing with management of Active Directory-based Group Policies.

This article was originally published on Friday May 15th 2009
Mobile Site | Full Site