Logo
CAR REVIEW
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
PREGNANCY
 
 
Windows Server

Windows Server 2012 Group Policies and Policy Management - Group Policy Processing: How Does It Work?

7/5/2013 5:09:18 PM

1. Group Policy Overview

The Microsoft Group Policy infrastructure is a complex system that leverages several features and services included in the Windows server and client OSs and the IP networks that these systems reside on.

At its simplest, a group policy is a set of definitions created by administrators to centrally configure and deploy computer and user settings. Group policy contains an extensive set of options right out of the box and can be extended even further through third-party software vendors and through custom development of policy settings by advanced Group Policy administrators. As an example of Group Policy at work, a policy can be created to automatically install a network printer on all machines located in a particular office. Another group policy could define firewall profile definitions that are less restrictive on the corporate network and very secure when a mobile workstation connects to a public wireless network.

Group policy was introduced with Windows 2000 Active Directory. Before Windows 2000, the building blocks of Group Policy were simply known as system policies and had some effective uses, but were still pretty limited. The Windows 2000 version of Group Policy proved to be very useful for security configurations and basic user settings but lacked many features, and when it came to mobile devices, it did not work very well. Microsoft Windows Server 2003 and Windows XP improved on the Windows 2000 Group Policy infrastructure by adding some new network detection features and more computer and user configuration options, including printer deployment. It was not until Windows Vista and Server 2008 were released that a major Group Policy overhaul had taken place.

Starting with Windows Vista and Server 2008, Microsoft now defined two different types of group policies: local and domain-based group policies. The local group policies with Windows Vista and Windows Server 2008 were basically mirrors of the settings available for both computers and users in domain-based group policies. This feature alone extended the application of Group Policy outside of Active Directory environments, making this tool valuable to organizations that use Windows workstations in workgroup configurations or in networks that do not necessarily rely on Microsoft Active Directory as the backbone for network authentication and other services.

Another major change to Group Policy was the introduction of Group Policy Preferences (GPP). GPP includes both computer and user-based preferences, and although these are configured with group policies, by their namesake, they implement the preferred configuration settings, and most can be changed by the user after policy application. GPP included much of the missing functionality that Group Policy administrators had to customize themselves within customized computer startup or user logon scripts to deploy customized desktop profile configurations, Registry settings, and much more. GPP really changed the Group Policy administrative landscape as it moved a lot of advanced customizations away from the cryptic scripts to GUI-based administration that all administrators can review and tune.

Many of the new Group Policy features of the Windows Vista and Windows Server 2008 infrastructure have been further improved and extended to provide more out-of-the-box functionality. Group policy is split into four main sections: computer policies, computer preferences, user policies, and user preferences. As a way to understand this quickly, consider the policy sections as enforced and the preference sections as initial configurations that can be changed as desired.

2. Group Policy Processing: How Does It Work?

The first thing an administrator needs to understand about Group Policy is that policies are processed and applied by computers and users. Policy processing occurs during certain events like computer startup and user logon but also at periodic intervals. When policy processing occurs, many factors are taken into account to determine whether a policy will be applied. One determining factor is whether the policy has been previously applied and, if so, whether it has been changed since the last application. This and many other factors are used to check each possible policy before it is applied to the computer/user.

Computer GPO Processing

Computers process group policies during startup, shutdown, and periodic refresh intervals. By default, the refresh interval is every 90 minutes on servers and workstations, with an offset of 0 to 30 minutes. On domain controllers, group policies are refreshed every 5 minutes. The offset ensures that domain-joined computers do not all refresh or process group policies simultaneously and potentially negatively impact the operation of the domain controllers and the computers themselves. When a domain-joined computer starts up, if the computer can successfully locate and communicate with an authenticating domain controller, Group Policy Object (GPO) processing occurs. During GPO processing, the system checks each linked or inherited GPO to verify whether the policy has changed since the last processing cycle, and then runs any startup scripts and checks for any other requirement to reapply the policy. During the shutdown and refresh interval, the GPOs are processed again to check for any updates or changes since the last application cycle.

Computer GPO processing is determined by GPO links, security filtering, and Windows Management Instrumentation (WMI) filters.

User GPO Processing

GPO processing for users is similar to GPO processing for computers. The main difference is that GPO processing for users occurs at user logon, logoff, and periodically. The default refresh interval for user GPO processing is 90 minutes plus a 0- to 30-minute offset. User GPO processing is determined by GPO links and security filtering.

Network Location Awareness

Network Location Awareness (NLA) is a service built in to Windows that is used to determine when the computer has connectivity to the Active Directory infrastructure. The Group Policy infrastructure uses NLA to determine whether to attempt to download and apply GPOs. This Group Policy functionality is also used with a connectivity check known as slow-link detection.

In earlier versions, Group Policy processing used slow-link detection to determine whether the network was reliable enough to process and apply policies. Slow-link detection relied on the Internet Control Message Protocol (ICMP) or ping to test for network connectivity and was not very reliable. Because of this specification, group policy processing on mobile and remote client workstations was very unreliable. When a mobile client workstation connected to the corporate network through a virtual private network (VPN) connection or after waking from hibernation or sleep mode, the change in network connectivity usually passed by unnoticed, and GPOs were not applied or refreshed. In these cases, the only way to get these clients to apply their GPOs was to have them manually run a Group Policy update from the command line or have these machines reboot while connected to the corporate network via wired Ethernet connections.

Group policy processing from Windows Vista and later, including Windows 8 and Windows Server 2012, now use the rebuilt NLA service to detect network changes. The new NLA service is much better at detecting changes to network connections, and when a connection is established, NLA checks for domain controller connectivity. If a domain controller can be contacted, the NLA service notifies the computer Group Policy service, which, in turn, triggers Group Policy processing for both computer-based and user-based Group Policy settings. The NLA service is not dependent on ICMP or ping, which on its own makes it more reliable. The NLA service should run on most networks without any special configuration on the network devices or network firewalls, even if ICMP communication is disabled or blocked by the firewall.

Group Policy Client-Side Extensions

Group policies are divided into policies and preferences, but even further within the policy different portions or sections of Group Policy will determine how, when, or if that particular section of a group policy will be processed. Group policy processing on the client side is managed by the Group Policy client-side extensions (CSEs). The CSEs are dynamic link library (DLL) files that are installed on the local client server or workstation OSs. When group policies are processed, it is actually the CSEs that apply the settings on the client. There are both policy and preference CSEs on the client system, and each CSE has its own default processing behavior, as discussed in the next section.

Tuning Group Policy Processing with GPO Settings

Within the Windows OS, there is a default behavior with regard to how Group Policy processing functions. Under these default behaviors, some parts of the group policy run only at computer startup and user logon, whereas some sections are processed during the background refresh interval. In addition, policies that have been processed earlier and have not changed since the last application of the group policy may or may not be processed again. Furthermore, if a computer startup or logon process has occurred off-network, Group Policy processing occurs when the domain network is detected. This is by design, to enhance both Group Policy processing and performance. For example, if all group policies were processed in full at every processing instance, the domain controllers and client system performance or user experience would likely suffer: Users might experience longer logon and logoff intervals, and computers across the organization might experience slower startups/shutdowns and might periodically just slow down. This is why, by default, group policies that have already been applied and have not changed are not processed during the background refresh interval.

Administrators and organizations might want to change the default behavior of Group Policy processing to streamline group policy performance and the user experience, or they might want to tighten security and ensure that all policy settings remain enforced by forcing group policies to reapply every policy processing cycle. To more fully understand the default processing behavior of computer and user Group Policy processing, review the settings within a domain group policy located at Computer Configuration and User Configuration node at Policies\Administrative Templates\System\Group Policy. Within the sections, you can review several Group Policy processing settings. The explanations for each describe their default behavior and provide different options for each setting that is enabled, as shown in Figure 1 for the Computer Configuration Drive Maps preference extension policy processing setting.

Image

Figure 1. Group policy drive maps preference policy setting.

Other -----------------
- BizTalk Server 2010 : Installation of WCF SAP Adapter (part 4) - IDOC Deep Dive, Building a BizTalk application — Sending IDOC
- BizTalk Server 2010 : Installation of WCF SAP Adapter (part 3) - IDOC schema generation
- BizTalk Server 2010 : Installation of WCF SAP Adapter (part 2) - WCF-SAP Adapter vs WCF Customer Adapter with SAP binding
- BizTalk Server 2010 : Installation of WCF SAP Adapter (part 1) - SAP Prerequisite DLLs
- Exchange Server 2007 : Leveraging the Capabilities of the Outlook Web Access Client - Getting to Know the Look and Feel of OWA 2007
- Exchange Server 2007 : Leveraging the Capabilities of the Outlook Web Access Client - Logging On to OWA 2007
- Exchange Server 2007 : Leveraging the Capabilities of the Outlook Web Access Client - What’s New in OWA 2007?
- SQL Server 2012 : Data Architecture (part 2) - Smart Database Design
- SQL Server 2012 : Data Architecture (part 1) - Information Architecture Principle, Database Objectives
- Microsoft Dynamic AX 2009 : .NET Business Connector - Usage Scenarios for .NET Business Connector
- Microsoft Dynamic AX 2009 : .NET Business Connector - Inside .NET Business Connector
- Microsoft Dynamic AX 2009 : .NET Business Connector - Introduction
- Windows Server 2012 : Installing and Managing Hyper-V in Full or Server Core Mode - Installing Windows Server 2012 and Microsoft Hyper-V Server 2012
- Windows Server 2012 : Installing and Managing Hyper-V in Full or Server Core Mode - Enabling the Hyper-V role
- Windows Server 2012 : Installing and Managing Hyper-V in Full or Server Core Mode - Verifying Hyper-V requirements
- Windows Server 2012 Requirements and Installation : Customizing the Interface with Features on Demand
- Windows Server 2012 Requirements and Installation : Deploying Minimal Server Interface
- Windows Server 2012 Requirements and Installation : Switching Between Install Modes
- Windows Server 2012 Requirements and Installation : Installing Server 2012 (part 2) - Server with a GUI Install
- Windows Server 2012 Requirements and Installation : Installing Server 2012 (part 1) - Server Core Install
 
 
Most view of day
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2007 : Exploring DSAccess, DSProxy, and the Categorizer
- Customizing Dynamics AX 2009 : Number Sequence Customization
- Windows Server 2012 : Full Windows experience (part 2) - Configuring User Profile Disks
- Windows Phone 8 : Configuring Basic Device Settings - Accessing the Device Settings Screen - Changing the Device Theme
- Microsoft Dynamic GP 2010 : Purchase Order Processing
- Microsoft Dynamics GP 2010 : Preventing Errors in Dynamics GP - Preventing account selection errors with Chart Segment names
- Microsoft Visio 2010 : Modifying a Graphic (part 4) - Cropping a Graphic
- Integrating SharePoint 2013 with the Office Applications (part 10) - Microsoft Outlook - Lists and Libraries
- Microsoft Project 2010 : Fine-Tuning Task Details (part 2) - Setting Task Constraints
- Managing Windows Licensing and Activation : Managing Volume License Activation (part 3) - Managing licensing and activation, Implementing KMS activation
Top 10
- Windows Phone 8 : Scheduled Tasks - Scheduled Task API Limitations
- Windows Phone 8 : Scheduled Tasks - Updating Tiles Using a Scheduled Task Agent
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 5) - Editing an Existing To-Do Item
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 4) - Creating the To-Do Item Shell Tile, Saving a To-Do Item
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 3) - Debugging Scheduled Tasks
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 2) - TodoService, TodoItemViewModel
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 1) - TodoItem,TodoDataContext
- Windows Phone 8 : Scheduled Tasks - Using Scheduled Tasks
- Windows Phone 8 : Scheduled Tasks - Background Agent Types
- Windows Phone 8 : Windows Phone Toolkit Animated Page Transitions - Reusing the Transition Attached Properties
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro