Group Policy Terminology and Concepts

What is Group Policy

Group Policy is an Active Directory feature that provides the means for you to effectively and efficiently manage large numbers of computers. You can manage both user and computer configuration settings centrally, from one position of administration. You can define group policies as being a collection of user and computer configuration settings which you can link to the following components:

• Computers

• Sites

• Domains

• Organizational Units (OUs)

Once linked, Group Policy defines the manner in which the operating system, network resources, and applications and programs operate for users within the organization. In other words, group policies define the behaviour of the desktops of users.

You can use Group Policy for the following administrative operations:

• Through group policies, you can define and configure scripts that run at:

  • Computer startup

  • Computer shutdown

  • User logon

  • User logoff

• To change Registry settings

• To deploy and manage programs and applications

• To establish domain password and account policies

• To redirect system folders

• To enforce software distribution and installation

You can define policies that behave differently for a computer, and a user:

• You can define group policies that affect a computer, irrespective of the particular user logging on to the computer. For instance, you can through a policy, configure the proxy server settings for a computer.

• You can define group policies that affect a user, irrespective of the computer which the user utilizes to log on to the system. For instance, you can use group policies to specify the applications or programs which are available to the user, and the programs which should exist on the user's desktop.

  Group Policy settings can therefore apply to the following types of Active Directory objects:

• User objects

• Computer objects

Because users and computers in Active Directory can be located in groups, and categorized in Organizational Units (OUs), using group policies can simplify the management of thousands of computers.

You can also define policies that affects resources connected to a particular computer (local policy), or you can define policies that affect the Active Directory directory (non-local policies).

You need to be familiar with, and understand the concepts that affect Group Policy operations, the different components of Group Policy, and the terminology used with Group Policy in order to implement it within your organization. The remainder of this Article focuses on this.

Understanding Group Policy Objects (GPOs)

A group policy object (GPO) is an Active Directory object which contains one or more Group Policy settings which affect the configuration settings for users or computers. A GPO acts as a container for the settings configured in Group Policy files. The Active Directory components that can be linked to a GPO are computers, sites, domains, organizational units (OUs). By linking a GPO to sites, domains, and OU actually applies the GPO settings to any user or computer objects within that particular container.

As already mentioned, a GPO can be thought of as being a container that contains Group Policy settings. The GPO identifies the following components of Group Policy:

• Group Policy Template (GPT): A GPT contains a set of instructions which implements a group of policies. GPTs are located in policy folders, and stored in the SYSVOL of domain controllers.

• Group Policy Container (GPC): This is an Active Directory object that contains the names of the Group Policy Templates (GPTs) connected to a specific GPO.

An important Group Policy concept is that Group Policy settings are hierarchical. What this means is that it can be lined and applied at different levels, as illustrated below:

• Sites: You can define GPOs, and link it to an entire site in Active Directory. The GPOs would then apply to each domain and server that belongs to the particular site. If the site contains multiple domains, the GPOs are applied to all the domains within the site.

• Domains: When you define GPOs, and link it to a particular domain in Active Directory, it is applied to all Computer objects and User objects that belong to, or are stored within that particular domain.

• Organizational Units (OUs): As is the case with the other two levels at which you can link and apply GPOs, you can define and link GPOs to a specific OU in Active Directory. The GPOs are then applied to all Active Directory objects stored within the particular OU.

When determining the manner in which Group Policy settings are hierarchically applied, remember the following: All computers and users located beneath the container that the GPO is linked to, is automatically within the scope of the particular GPO. They will therefore be affected by each and every Group Policy setting specified in the GPO.

This makes it possible for a user or computer to fall within the scope of numerous GPOs linked to a site, domains, and OUs. The concept, Resultant Set of Policies (RSoP), refers to the total impact of the policies in the GPOs on the user or computer.

GPOs can be grouped into the categories listed below. The category into which a GPO falls is determined by the location at which the Group Policy settings originated.

• Local GPOs: A local GPO is stored on a computer, whether it is a member server, or a workstation. Each computer running Windows Server 2003 has a local GPO. A local GPO applies only to the particular computer, and relates to activities on that particular computer. For computers that are part of Active Directory, the local GPO is lower-ranking than nonlocal GPOs. This basically means that in cases where the computer belongs to Active Directory, the local GPO settings can be overridden by nonlocal GPO settings. The local GPO is located in the Systemroot%System32GroupPolicy folder. Nodes that are located beneath Security Settings can be configured for local GPOs.

• Nonlocal GPOs: In addition to a computer running Windows Server 2003 having one local GPO, the computer can fall within the scope of numerous nonlocal GPOs. Nonlocal GPOs are also called Active Directory based GPOs. All nonlocal GPOs are defined in Active Directory and have to be linked to a site, domain or OU. Once linked, it is applied to User objects and Computer objects. Nonlocal GPOs therefore affect Active Directory objects, and are executed or carried out whenever the particular object is active. Nonlocal GPOs are located under %Systemroot%SysvolDomain NamePoliciesGPO GUIDAdm. The GPO GUID represents the Global Unique Identifier (GUID) of the GPO. Because nonlocal GPOs are created in Active Directory, are linked to sites, domains, or OUs; and are applied to User objects or Computer objects, a Windows 2000 or Windows Server 2003 domain controller has to be installed before you can use nonlocal GPOs. When the Active Directory directory service is installed, the following Nonlocal GPOs are automatically created:

  • Default Domain Policy: The Default Domain Policy is linked to the domain. This GPO impacts users and computers that are part of the domain using Group Policy inheritance.

  • Default Domain Controllers Policy: The Default Domain Controllers Policy is linked to the Domain Controllers OU. The GPO only impacts domain controllers.

You define one of the following policy types:

• User policies, which are applied when the user logs on. These policies determine the manner in which User objects operate within the network.

• Computer policies, which are applied to computers running in Active Directory. These policies determine the manner in which Computer objects operates within the network.

Group Policy settings in the GPO are regarded as being cumulative and hierarchical in nature. When a GPO is applied to a site, the GPO is applied to all computers within the site. This is because Active Directory directory information is replicated as follows:

• To all domain controllers in the site.

• To all domain controllers in sites where a site link has been created.

Where a domain level GPO, and OU level GPO applies to the same users, the settings of both GPOs are applied to the user. GPOs are by default cumulative and inherited. You can though configure the following options which either blocks inheritance or forces inheritance, at the different levels to which the GPO is linked:

• Force Policy Inheritance: This option is used to set inheritance properties on parent objects. Any child objects located beneath the parent object, automatically inherit Group Policy settings linked to the parent object.

• Block Policy Inheritance: This option can be used to explicitly define that the Group Policy settings of an object are not inherited from its associated parent object(s).

To configure and manage policy settings in GPOs, and link GPOs to computers, sites, domains and organizational units (OUs), Windows Server 2003 provides the following set of management tools:

• The Active Directory Users And Computers (ADUC) console

• The Group Policy Management console

• The Group Policy Object Editor

• The Resultant Set Of Policy snap-in

The Group Policy Object Editor is the tool used to manage and define the Group Policy settings in each GPO. You can use the Group Policy Object Editor to examine the Group Policy settings for a GPO.

You can use the steps below to open the Microsoft Management Console (MMC) for the local GPO.

1. Proceed to open the Microsoft Management Console.

2. On the Menu bar, click File and select Add/Remove Snap-In.

3. When the Add/Remove Snap-In dialog box opens, click the Add button on the Standalone tab.

4. On the Add Standalone Snap-In dialog box, select Group Policy Object Editor. Click Add.

5. On the Select Group Policy Object dialog box, in the Group Policy Object box, verify that Local Computer is listed.

6. Click Finish.

7. Click Close on the Add Standalone Snap-In dialog box.

8. Click OK on the Add/Remove Snap-In dialog box.

You can perform the following management tasks for GPOs:

• Create a GPO: You would use the Active Directory Sites And Services console to create a GPO and link it to a site. You would use the Active Directory Users And Computers console to create a GPO and link the GPO to a domain or OU. You can also use the Group Policy Management console to create GPOs and link them to sites, domains, or OUs.

• Link GPOs to a site, domain or OU: You can view and manage GPO links on the Group Policy tab of the Properties dialog box of the particular site, domain, or OU. Computer policies affect computers in the particular site, domain, or OU to which the GPO is linked. User policies affect users in the particular site, domain, or OU to which the GPO is linked. You can also use the Group Policy Management console to manage GPO links.

• Edit existing GPOs: To edit existing GPOs, you have to actually open the Group Policy Object Editor with the existing GPO as the focal point. To do this:

  • For sites, use the Active Directory Sites And Services console, open the Properties of the particular site, click the Group Policy tab and then click the Edit.

  • For domains and OU, use the Active Directory Users and Computers console, open the Properties of the particular domain or OU, click the Group Policy tab and then click Edit.

  • If you are using the Group Policy Management console, right-click the existing GPO which you want to edit, and then select Edit on the shortcut menu.

Group Policy Settings

In Active Directory, Group Policy settings are held within a Group Policy object (GPO). A GPO has a globally unique identifier (GUID) attribute that identifies it within Active Directory. As mentioned previously, you can use the Group Policy Object Editor to examine the Group Policy settings for a GPO. The types of Group Policy settings that exist are categorized into user configuration settings and computer configuration settings. The computer configuration settings are stored in the Computer Configuration node and user configuration settings are stored in the User Configuration.

• Computer Configuration node: This node contains configuration settings which are applied to the computer when the operating system starts. The user logging on to the computer does not affect the execution of these group policies.

• User Configuration node: This node contains configuration settings which are applied when the user logs on to the computer. The computer being logged on to by the user does not affect the execution of these group policies.

Both the Computer Configuration and the User Configuration nodes contain the following nodes:

• Software Settings node, includes policy settings for installing, removing, or updating software on computers running in the network.

• Windows Settings node, includes policy settings for installing and connecting to the Windows operating system.

• Administrative Templates node, includes policy settings for the Registry.

Software Settings

By default, the Software Settings node under the Computer Configuration node and under the User Configuration node contains the Software Installation extension. This extension is for assisting with the configuration of software policy settings that define how software and applications are installed on computers. You can use software settings to deploy new applications to end users, and define a computer as the location for an application. Software settings defined under the User Configuration node can be used to make a specific application available to only a particular user, irrespective of the actual computer the user logs on to. Only the designated user would be able to view and execute the application. You can also use software policies to deploy new applications in the network, and make them accessible to users. You can control the default configuration for these applications as well.

Windows Settings

The Windows Settings node in the Computer Configuration node and in the User Configuration node contains the following:

• Scripts extension: You can define the following types of scripts:

  • In Computer Configuration: Startup and shutdown scripts execute when the computer starts, or shuts down

  • In User Configuration: Logon and logoff scripts execute when the user logs on or logs off the particular computer.

  When more than one script exists for a user or computer, logoff scripts are processed before shutdown scripts.

• Security Settings node: You can define the security levels assigned to a local GPO or nonlocal GPO.

The policy settings which you can define are determined by whether they are applied in the Computer Configuration node, or the User Configuration node.

• Account:

  • Location = Computer ConfigurationSecurity Settings node, includes policy settings for password settings and account lockout settings.

• Folder redirection:

  • Location = User ConfigurationSecurity Settings node, includes policy settings for redirecting particular user folders to other locations.

• Internet Explorer maintenance:

  • Location = User ConfigurationSecurity Settings node, includes connection settings user interface settings, and security zone settings; for changing the settings for Internet Explorer.

• Public Key policies:

  • Location = User Configuration Security Settings node, includes policy settings which are associated with the public key activities of users.

• Public Key policies:

  • Location = Computer ConfigurationSecurity Settings node, includes policy settings which are associated the public key activities of the system.

Administrative Templates

The policy settings that are contained in the Administrative Templates node of the Computer Configuration node and the User Configuration node are Registry based settings. Group Policy settings for user configuration are stored in the HKEY_CURRENT_USER (HKCU) registry key. Group Policy settings for computer configuration are stored in the HKEY_LOCAL_MACHINE (HKLM) registry key.

The Administrative templates node contains Group Policy settings for:

• Windows components, including Terminal Services, Windows Media Player, Internet Explorer, Windows update, and many more.

• User profiles

• Group policy

• Scripts

• Dial-up connections

• And many more different Group Policy settings for computer configuration and user configuration.

In fact, more than 500 Registry based Group Policy settings can be set under User Configuration. A few examples are Start Menu settings, Shared folder settings, Control Panel settings, and Desktop settings. The locations which contain a description on these Group Policy settings are listed below:

• The Administrative Templates Help feature is new in Windows Server 2003.

• Another new Windows Server 2003 feature, the Extended tab in the Group Policy Object Editor, offers information on each selected setting.

• The Explain tab in the Properties dialog box for the particular setting.

The Administrative templates node of both the User Configuration node and Computer Configuration node have the following nodes:

• Windows Components node: Includes Group Policy settings which can be used to manage Internet Explorer, Microsoft Windows Messenger, Terminal Services, Task Scheduler, and other Windows components.

• System node: Includes Group Policy settings for user profiles, Group Policy, scripts, and more Group Policy settings which are specific to either user configuration, or to computer configuration.

• Network node: Includes Group Policy settings for dial-up connections, and offline files, and other Group Policy settings which are specific to computer configuration.

Only the Administrative templates node located beneath the Computer Configuration node has a Printers node which contains Group Policy settings that can be set for printers. Only the Administrative templates node located beneath the User Configuration node has Start menu and task bar, desktop, Control Panel and shared folders nodes.

A Group Policy setting in the Administrative Templates node has one of the following states or settings:

• Not Configured

• Enabled

• Disabled

As previously mentioned, Group Policy settings for user configuration are stored in the HKEY_CURRENT_USER (HKCU) registry key, and Group Policy settings for computer configuration are stored in HKEY_LOCAL_MACHINE (HKLM) registry key. Each in turn stores Group Policy specific registry information in one of the following reserved trees:

• HKEY_CURRENT_USERSoftwarePolicies, for user policy settings.

• HKEY_LOCAL_MACHINESoftwarePolicies, for computer policy settings.

• HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionPolicies, for user settings.

• HKEY_LOCAL_MACHINESoftwareMicrosoft WindowsCurrentVersionPolicies; for computer settings.

What are Administrative Templates?

Administrative templates in Wndows 2000 and Windows Server 2003 are Unicode based text files that have a .adm file name extension. An administrative template can be defined as the text file which creates the user interface for the Group Policy settings which you can configure using the Group Policy Object Editor.

The three types of administrative templates which exist are:

• Default administrative templates: These are the administrative templates which are included in Windows Server 2003, and includes the following set of default administrative templates:

  • Conf.adm administrative template, includes NetMeeting settings for both Windows 2000 and Windows Server 2003 clients.

  • Inetres.adm administrative template, includes Internet Explorer settings for both Windows 2000, and Windows Server 2003 clients.

  • System.adm administrative template, includes system settings for Windows 2000 and Windows Server 2003 clients.

  • Wmplayer.adm administrative template, includes Windows Media Player settings for both Windows 2000 and Windows Server 2003 clients.

  • Wuau.adm administrative template, includes Windows Update settings for Windows 2000 and Windows Server 2003 clients.

• Vendor supplied administrative templates: These are administrative templates which are provided with software applications that can run on Windows Server 2003. These administrative templates usually need to be downloaded from a Web site, and then installed.

• Custom administrative templates: These types of administrative templates are usually created by application developers, using the .adm language, to exercise controller over user configuration and computer configuration.

Understanding the Group Policy Processing Sequence

The process listed below is executed when computer configuration settings and user configuration settings are applied at computer startup, and user log on.

1. When the network starts, the Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention Provider (MUP) are started.

2. Next, the list of GPOs is acquired for the computer.

3. The content of the GPO list is determined by whether the computer belongs to a Windows 2000 domain or Windows Server 2003 domain; and where in Active Directory the computer is actually located.

4. The computer configuration settings are processed first, and in this order:

   1. local GPO

   2. site GPOs

   3. domain GPOs

   4. OU GPOs

5. The startup scripts execute next, and in a particular sequence as well. This basically being that each script has to complete or alternatively timeout before the following script can be executed.

6. When the user finally logs on to the computer, and is authenticated, the user profile for the particular user is loaded. This is controlled by the Group Policy settings in use.

7. Next, the list of GPOs is acquired for the particular user logging on to the computer.

8. The content of the GPO list is determined by whether the user belongs to a Windows 2000 domain or Windows 2003 domain, whether loopback is enabled and the mode of this policy setting, where in Active Directory the user is actually located, and whether the list of GPOs that should be applied to the user has changed or not. The default configuration is that if the list has not since changed, no processing is performed. You can however change this.

9. The user configuration settings are processed next, and in this order:

   1. local GPO

   2. site GPOs

   3. domain GPOs

   4. OU GPOs

10. The logon scripts execute after this.

11. The user is displayed the user interface as defined by Group Policy.

Understanding the order in which Group Policy settings are processed

Nonlocal GPOs or Active Directory based GPOs are applied in a hierarchical manner. The end configuration of the user or compute is actually the result of the GPOs which are linked to a particular site, domain and OU.

Group policy settings are processed in the order specified below:

1. Local GPO: Recall from an earlier discussion, that each computer running Windows 2000 or Windows Server 2003 contains one GPO which is stored locally. Because the local GPO is applied first, it means that policies defined at the local computer have the least priority.

2. Site GPO: Site GPOs are GPOs which are linked to sites. The order of the different site GPOs are determined and defined by the Administrator.

3. Domain GPOs: Domain GPOs are applied next. These are GPOs which are linked to domains. Once again, when different domain GPOs are linked to the particular domain, their order is determined and defined by the Administrator. It is evident now that GPOs linked to a domain enjoy priority or precedence over site GPOs and local GPOs.

4. OU GPOs linked to the OU highest in the Active Directory hierarchy are applied before any other OUs.

5. OU GPOs linked to child OUs are applied next.

6. OU GPOs linked to the OU closest to the user or computer are then applied.

7. When the OU that contains the user or computer has a GPO linked to it; that GPO is applied last. You can see that OUs closest to, or which includes the user/computer have precedence over GPOs linked to OUs higher up the tree.

The order specified above is affected by the a few exceptions, which are noted below:

• If the computer is a member of a workgroup, only the local GPO is applied to the user or computer.

• When the No Override setting is enabled for a GPO which is linked to a site, domain or OU, no Group Policy settings contained in the particular GPO is overridden by other GPOs. Because of the hierarchical manner in which GPOs are applied, and there happens to be more than one GPO which has the No Override setting enabled, the GPO highest in the tree has precedence.

• Block Policy Inheritance can be explicitly specified for a site, domain or OU, and is not applied to any GPOs or GPO links. When enabled for a site, domain or OU; it prevents any Group Policy settings from passing down from higher up in the tree, to the particular site, domain or OU for which it is enabled. The only exception is that any GPO links which have the No Override settings enabled are not blocked, but are applied.

• The loopback setting: Loopback is a Group Policy setting which is useful for lab computers and terminal servers. Loopback enables you to configure alternatives to the default method of obtaining the list of GPOs for a user. You can configure the system to apply the User Configuration settings from GPOs which are linked to containers containing computer objects. The following states or settings can be enabled for Loopback:

  • Not Configured, Enabled, Disabled.

• Loopback can be enabled in the following modes:

  • Replace Mode: In this mode, the list of GPOs for a user is replaced by the GPO list acquired at computer startup.

  • Merge Mode: In this mode, the GPO list acquired when the computer started is added to the GPO list acquired at user log on. The GPO list acquired at computer startup is processed last.

Understanding Group Policy Inheritance

When discussing Group Policy, the concept of Inheritance signifies that Group Policy settings which affect user configuration and computer configuration are the resultant set of policies inherited from parent containers. Policies are usually passed down from a parent container to its associated child containers. The exception being that a Group Policy setting defined for a child OU overrides the same setting which it inherited from its parent OU.

A child OU does not inherit its parent OU policy settings in the following instances:

• When the policy settings of a parent OU are set to the Not Configured setting, no child OUs would inherit those settings. Policy settings that are Disabled are inherited as Disabled by child OUs.

• When a policy setting specified for a parent OU happens to be with the identical policy setting defined for the child OU, the child OU setting overrides the policy setting which it inherited from the parent OU.

• When the policy setting specified for a parent OU happens to be incompatible with the same policy configured for the child OU, the policy is not inherited by the child OU.

The ways in which Group Policy settings can be inherited are listed below:

• When the policy setting for a parent OU is set to Enabled or Disabled; and the child OU does not have the same policy setting configured, the child OUs inherits the policy setting of its parent OU.

• When a policy setting specified for a parent OU and a policy setting specified for a child OU are compatible, inheritance can take place. In this case, the child OU inherits the policy setting of the parent, and the policy setting configured for the child OU is applied as well.

Delegating Administrative Control of GPOs

Configuring the appropriate security settings on GPOs is important for the following reasons:

• When the security settings on the actual GPOs are not set correctly, both Administrators and users would be able to override them.

• When numerous Administrators create GPOs and edit existing GPOs, the management of GPOs can be intricate.

To simplify the management of Group Policy, you can delegate administrative control of the following administrative tasks:

• Creating GPOs: To delegate administrative control for creating GPOs, you have to include the specified user as a member of the Group Policy Creator Owners group. You would then delegate authority to the user to manage GPO linking to the site, domain or OU in which the user will be creating GPOs.

• Linking GPO: To delegate administrative control for linking GPOs, you need to specify the Manage Group Policy Links option which is made available through the Delegation Of Control Wizard for the particular domain or OU.

• Editing GPOs: To delegate administrative control for editing existing GPOs, you have to grant the Read and Write permission for the selected user.

Filtering Group Policies

As mentioned on numerous occasions throughout this Article, group policies are linked to sites, domains and OUs, and are then applied to user and computer objects, based on where they are located within Active Directory. Group policies are therefore never directly linked to security groups.

An option does though exist, whereby which you can apply a GPO to a designated security group(s) through a process known as filtering the GPO. When filtering the GPO, you can specify that it is only applicable when a user or computer is a member of the security group. You can define filtering as being the process by which certain security groups are either included or excluded from the Group Policy settings of the GPOs. This allows you to filter Group Policy to affect those computers and users which you set for being influenced by Group Policy. Because the Group Policy settings in a nonlocal or Active Directory based GPO is only relevant to users that have the Read (Allow) permission and Apply (Allow) permission for the GPO, you can set the necessary permissions for security groups to include only certain computers and users. When filtering Group Policy remember that the filter would only apply if the users in the security group are in the scope of the GPO.

Windows Management Instrumentation (WMI) is a management tool which Windows Server 2003 utilizes in a number of ways to monitor and manage network objects. WMI can be used to filter a GPO based on the results of a WQL query. This is a new Windows Server 2003 Group Policy feature. You cannot howeer filter individual elements of a GPO. You can also only choose one WMI filter for any specified GPO. When a WMI query is utilized to filter the scope of a GPO, the GPO is applied based on properties available in WMI that are located in the WMI query.

The WMI components are listed below:

• Managed Objects: The WMI technology gathers information from devices and applications such as hard drives, CPUs and network adapters.

• Common Information Model (CIM): WMI holds the information it gathered in the Common Information Model repository.

• Common Information Model Object Manager (CIMOM): The CIMOM processes this information, and interacts with any applications which need to have information stored in the CIM repository.

• WMI Query Language (WQL): The WMI query language (WQL) is used to compile WMI queries. The number of attributes which can be used in WMI queries are numerous.

• Event triggers: Group policies do not utilize WMI events

Resultant Set of Policies (RSoP)

Because, GPOs can be linked, blocked, filtered and its settings inherited; it can be quite a time consuming and complex task to determine which Group Policy settings are applied to a user or computer. Windows Server 2003 however includes the Resultant Set of Policy (RSoP) tool which simplifies group policy management. You can use the Resultant Set of Policy (RSoP) tool to determine what occurs with group policies when a particular user logs on to the computer.

Through RSoP, you can determine the following:

• Which GPOs are applied

• The level (site, domain, OU) at which they are applied

• Which GPOs are blocked

The tool can also be used to assist in the planning of a Group Policy implementation, and to troubleshoot Group Policy settings.