What Is Core Group Policy?

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

In this section

• Change and Configuration Management

• Core Group Policy Infrastructure

• Core Group Policy Scenarios

• Core Group Policy Dependencies

• Related Information

Group Policy is an infrastructure used to deliver and apply one or more desired configurations or policy settings to a set of targeted users and computers within an Active Directory environment. This infrastructure consists of a Group Policy engine and multiple client-side extensions (CSEs) responsible for writing specific policy settings on target client computers.

Group Policy settings are contained in Group Policy objects (GPOs), which live in the domain and can be linked to the following Active Directory containers: sites, domains, or organizational units (OUs). The settings within GPOs are then evaluated by the affected targets, using the hierarchical nature of Active Directory. Consequently, Group Policy is one of the top reasons to deploy Active Directory.

Group Policy is one of a group of management technologies, collectively known as IntelliMirror, that provides users with consistent access to their applications, application settings, roaming user profiles, and user data, from any managed computer — even when they are disconnected from the network. IntelliMirror is implemented through a set of Windows features, including Active Directory, Group Policy, Group Policy-based Software Installation, Windows Installer, Folder Redirection, Offline Folders, and Roaming User Profiles.

Core Group Policy or the Group Policy engine is the framework that handles common functionalities across Administrative Template settings and other client-side extensions. The following figure shows how the Group Policy engine interacts with other components as part of processing policy settings. You use Group Policy Management Console (GPMC) to create, view, and manage GPOs and use Group Policy Object Editor to set and configure the policy settings in GPOs.

Group Policy Components

Change and Configuration Management

Administrators face increasingly complex challenges in managing their IT infrastructures. You must deliver and maintain customized desktop configurations for many types of workers, including mobile users, information workers, or others assigned to strictly defined tasks, such as data entry. Changes to standard operating system images might be required on an ongoing basis. Security settings and updates must be delivered efficiently to all the computers and devices in the organization. New users need to be productive quickly without costly training. In the event of a computer failure or disaster, service must be restored with a minimum of data loss and interruption.

Specifically, an IT department must respond to various factors that require change in an IT environment including:

• New operating systems and applications.

• Updates to operating systems and applications.

• New hardware.

• New business requirements that require configuration changes.

• Security influences that require configuration changes.

• New users.

Managing this change can be viewed as a continuous cycle, in which new business requirements demand changes that must first be tested before they can be deployed as a standard configuration. This cycle is shown in the following figure.

Change and Configuration Management Process

These roles, known collectively as Change and Configuration Management, enable administrators to implement change quickly and affect large numbers of users and computers at the lowest possible cost. You can use Group Policy to maintain standard operating environments for specific groups of users, such as developers or information workers. As software changes and policies change over time, Group Policy can be used to update the already-deployed standard operating environment until the image can be updated. Group Policy can also enforce rules, if necessary, by restricting the programs that can be run on company computers. For example, it can prevent access to games or other programs unrelated to the workplace.

Group Policy is a key enabling technology that allows you to implement Change and Configuration Management along with other technologies in IntelliMirror. For example, you can deploy new operating systems with Remote Installation Services or other imaging technology. You can deliver updates to computers throughout the network using Software Update Services (SUS). Although you can deploy software using Group Policy, larger organizations might want to use Microsoft Systems Management Server (SMS) to take advantage of the scalability that SMS provides.

In summary, Group Policy is the delivery mechanism that allows you to implement change and configuration for users and computers on the object level in Active Directory. Because you can target Group Policy settings to individual objects throughout the Active Directory hierarchy, Group Policy is the central enabling technology that allows organizations to effectively use Active Directory as a management tool. In addition, the Group Policy Management Console simplifies implementation and management of Group Policy.

Core Group Policy Infrastructure

Group policy is an infrastructure with pluggable extensions. Extensions that exist on client computers include Administrative Templates (also known as registry-based policy), Security Settings, Software Installation, Folder Redirection, Scripts, and Wireless Network Policies.

The policy settings exist in a GPO. A GPO is a virtual object that lives in the domain; part of the GPO is located in Active Directory and is called the Group Policy container. The other part of a GPO is located in the Sysvol and is called the Group Policy template. When policy settings need to be applied, the framework calls each extension and the extension then applies the necessary settings.

Each Group Policy extension has two extensions — a client extension that is called by the Group Policy engine to apply policy, and a server-side extension that plugs into Group Policy Object Editor to define and set the policy settings that need to be applied to client computers.

Although you can configure Local Group Policy objects (Local GPOs) on individual computers, the full power of Group Policy can only be realized in a Windows 2000 or Windows Server 2003-based network with Active Directory installed. In addition, some features and policy settings require client computers running Windows XP.

Group Policy and Active Directory

Active Directory organizes objects by sites, domains, and OUs. Domains and OUs are organized hierarchically, making the containers and the objects within them easy to manage. The settings defined in a GPO can only be applied when the GPO is linked to one or more of these containers.

By linking GPOs to sites, domains, and OUs, you can implement Group Policy settings for as broad or as narrow a portion of the organization as you want. GPO links affect users and computers in the following ways:

• A GPO linked to a site applies to all users and computers in the site.

• A GPO linked to a domain applies directly to all users and computers in the domain and by inheritance to all users and computers in child OUs. Note that policy is not inherited across domains.

• A GPO linked to an OU applies directly to all users and computers in the OU and by inheritance to all users and computers in child OUs.

When a GPO is created, it is stored in the domain. When the GPO is linked to an Active Directory container, such as an OU, the link is a component of that container, not a component of the GPO.

An example of how GPOs can be linked to sites, domains, and OUs is shown in the following figure.

Sample Active Directory Organizational Structure

In this configuration, the Servers OUs have the following GPOs applied: A1, A2, A3, A4, A6. The Marketing OUs have the following GPOs applied: A1, A2, A3, A5.

Loopback processing with merge or replace

Loopback is an advanced Group Policy setting that is useful on computers in certain closely managed environments, such as servers, kiosks, laboratories, classrooms, and reception areas. Setting loopback causes the User Configuration settings in GPOs that apply to the computer to be applied to every user logging on to that computer, instead of, or in addition to, the User Configuration settings of the user. This allows you to ensure that a consistent set of policies is applied to any user logging on to a particular computer, regardless of their location in Active Directory. Loopback is controlled by the setting, User Group Policy loopback processing mode, which is located in Computer Configuration\Administrative Templates\System\Group Policy. Loopback only works when both the user account and the computer account are in a Windows 2000 or later domain. Loopback does not work for computers joined to a workgroup. Loopback is not enabled if the computer or user is not in an Active Directory domain.

Filtering the Scope of the Group Policy Object

Group Policy is a powerful tool for managing the Windows Server 2003 environment. The value of Group Policy can only be realized through properly applying the GPOs to the Active Directory containers you want to manage. Determining which users and computers will receive the settings in a GPO is referred to as “scoping the GPO.” Scoping a GPO is based on three factors:

• The site(s), domain(s), or organization unit(s) where the GPO is linked.

• The security filtering on the GPO.

• The WMI filter on the GPO.

You can use the site, domain, and OU links from a GPO as the primary targeting principle for defining which computers and users should receive a GPO. You can then use security filtering and WMI filtering to further reduce the set of computers and users to which the GPO will apply.

Scoping or targeting of a GPO allows you to apply or deny an entire GPO; you cannot choose to filter settings within a GPO.

Group Policy Inheritance

In addition to the ability to filter the scope of GPOs, you can change the way GPOs are applied by managing Group Policy inheritance. In most environments, the actual settings for a given user and computer are the result of the combination of GPOs that are applied at a site, domain, or OU. When multiple GPOs apply to these users and computers, the settings in the GPOs are aggregated. The settings deployed by GPOs linked to higher containers (parent containers) in Active Directory are inherited by default to child containers and combine with any settings deployed in GPOs linked to child containers. If multiple GPOs attempt to set a setting to conflicting values, the GPO with the highest precedence sets the setting. GPO processing is based on a “last writer wins” model, and GPOs that are processed later have precedence over GPOs that are processed earlier.

Viewing and Reporting of Policy Settings

In order to properly implement, troubleshoot, and plan Group Policy, administrators need to be able to quickly view the settings in a GPO. When multiple GPOs apply to a given user or computer, they can contain conflicting policy settings. For most policy settings, the final value of the policy setting is set only by the highest precedent GPO that contains that setting. Resultant Set of Policy (RSoP) helps you understand and identify the final set of policy that is applied as well as settings that did not apply as a result of policy inheritance.

Specifically, Resultant Set of Policy helps you determine:

• The final value of the setting that is applied as a result of all the GPOs.

• The final GPO that set the value of this setting (also known as the winning GPO).

• Precedence details that show any other GPOs that attempted to set this setting and the value that each GPO attempted to set for that policy setting.

Group Policy Management Console, available as a separate download from the Microsoft Web site, addresses some common reporting requirements including the ability to document all the settings in a GPO to a file for printing or viewing. Users can either print the reports, or save them to a file as either HTML or XML.

Delegating Administration of Group Policy

Organizations need to be able to delegate administration of Group Policy to other administrators who can take responsibility for a given OU, domain, or other container. Active Directory is designed to allow you to delegate control of portions of the directory service in managing aspects of Group Policy. The following areas can be delegated:

• GPO delegation. This includes permission to create GPOs in a domain or permission to edit an existing GPO. Note that having permission to edit a GPO does not include any delegated rights on the GPO links.

• Link delegation. This includes permission to add, delete, or change links to GPOs. Note that having link delegation does not include any delegated rights on the GPO itself.

• RSOP delegation. This includes permission to run RSoP (in either planning or logging mode) on objects under a container.

• WMI filter delegation. This includes permission to create WMI filters or permission to edit an existing filter.

In GPMC, delegation is simplified because it manages the various Access Control Entries (ACEs) required for a task as a single bundle of permissions for the task. You can also use the Access Control List (ACL) editor to view or manage these permissions manually.

The underlying mechanism for achieving delegation is the application of the appropriate DACLs to GPOs and other objects in Active Directory. This mechanism is identical to using security groups to filter the application of GPOs to various users. You can also specify Group Policy to control who can use MMC snap-ins. For example, you can use Group Policy to manage the rights to create, configure, and use MMC consoles, and to control access to individual snap-ins.

Core Group Policy Scenarios

The Group Policy engine is designed to apply policy configurations to individual computers and users through Group Policy objects. Settings within a GPO are configured by individual client-side extensions and are applied to individual computers and users by the client-side extension. This section summarizes the core scenarios for the Group Policy engine.

• Scheduling of Group Policy application. Group Policy starts each time the computer starts or a user logs in, a process called foreground policy application. Group Policy is also applied in the background at regular refresh intervals. In addition, it can be forced to apply through command line tools such as Gpupdate.

• Obtaining GPOs from the relevant configuration locations. The Group Policy engine obtains GPOs from the appropriate site, domain, and OU containers, known collectively as Scope of Management (SOM).

• Handling special cases affecting all CSEs. The Group Policy engine implements additional changes specified by the administrator such as changing the link order in which GPOs should be applied. In addition, the Group Policy engine handles any loopback processing that has been set by an administrator. Loopback processing, typically used for public workstations or kiosks, specifies that the user settings defined in the computer’s GPOs replace or are merged with the user settings normally applied to the user.

• Filtering and ordering of GPOs. The Group Policy engine checks for any conditions set by the administrator to filter GPOs or specify the order in which GPOs should be applied.

• Configuring CSEs. CSEs can be configured to run only in some conditions, as specified in the registry.

• Maintaining version numbers and histories for all CSEs. A history list is maintained for each CSE in the Registry, showing when the CSE last applied policy. A status is also maintained to figure out whether the client-side extension applied policy successfully last time the policy was applied by the CSE.

• Calling into the CSE. When the Group Policy engine has determined that a particular CSE needs to be executed, it loads the dynamic link library (DLL) associated with the CSE and loads up the entry point.

• Notifying various components of any changes made by Group Policy. After all the extensions have been called, the Group Policy engine updates the registry information to specify what the next policy foreground application should be, as well as schedule the next background refresh time.

• Processing RSoP data. The Group Policy engine periodically refreshes the RSoP data, ensuring that actual policy application is updated and stored in the WMI namespace on each computer.

Group Policy Dependencies

Group Policy has several key dependencies. Domain-based Group Policy requires an Active Directory environment with DNS properly configured.

Active Directory

Active Directory is the Windows 2000 Server and Windows Server 2003 directory service that stores information about all objects on the computer network and makes this information easy for administrators and users to find and apply. With Active Directory, users can gain access to resources anywhere on the network with a single logon. Similarly, administrators have a single point of administration for all objects on the network, which can be viewed in a hierarchical structure. In a network environment, Group Policy depends on Active Directory as the targeting framework that allows you to link GPOs to specific Active Directory containers such as sites, domains, or OUs.

In a stand-alone environment without Active Directory, you can use Local Group Policy objects to configure settings on individual computers.

Domain Name System (DNS)

DNS is a hierarchical, distributed database that contains mappings of DNS domain names to various types of data, such as IP addresses. DNS enables the location of computers and services by user-friendly names, and it also enables the discovery of other information stored in the database.

Group Policy application requires clients to access specified servers, including domain controllers and other servers such as share points and install points. Group Policy management also requires access to domain controllers. DNS is used to locate and identify these servers. In Windows 2000 Server and later Active Directory requires DNS support. If the network is functioning, but clients or consoles such as the Group Policy Object Editor or GPMC are unable to locate the servers, there might be a problem with your network's DNS system.

Replication

Group Policy depends on other technologies in order to properly replicate between domain controllers in a network environment. A GPO is a virtual object stored in both Active Directory and the Sysvol of a domain controller. Property settings, stored in the Group Policy container, are replicated through Active Directory replication. Replication automatically copies the changes that originate on a writable directory partition replica to all other domain controllers that hold the same directory partition replica. More specifically, a destination domain controller pulls these changes from the source domain controller. Data settings, stored in the Sysvol as the Group Policy template, are replicated through the File Replication Service (FRS), which provides multi-master file replication for designated directory trees between designated servers running Windows Server 2003. The Group Policy container stores GPO properties, including information about version, GPO status, and a list of components that have settings in the GPO. The Group Policy template is a directory structure within the file system that stores Administrative Template-based policy settings, security settings, script files, and information regarding applications that are available for software installation. The Group Policy template is located in Sysvol in the \Policies sub-directory for its domain. GPOs are identified by their globally unique identifiers (GUIDs) and stored at the domain level. The settings from a GPO are only applied when the Group Policy container and Group Policy template are synchronized.

DFS publishing

The Sysvol folder is shared on each domain controller and is accessible through the UNC path \\dcname.domainname\sysvol.

The Sysvol is also published as a domain-based Distributed File System (DFS) share. This allows clients to access the Sysvol by using the generic path \\domainname\sysvol. A request for a DFS referral for \\domainname\sysvol will always return a replica in the same Active Directory site as the client if one is available. This is the mechanism that the Group Policy client-side extensions use to retrieve a local copy of the Group Policy template information.

Related Information

The following contains additional information that is relevant to this section.

Group Policy Settings Reference for Windows Server 2003