Windows Group Policy: Deploying Group Policy

  • 2/11/2009
Contents

Applying and Linking Group Policy Objects

You store Group Policy preferences and settings in Group Policy objects (GPOs). While I’ll cover the nitty-gritty details in later chapters, I’ll examine the basic concepts related to Group Policy application (initial processing) and refresh (subsequent processing) in this section.

Policy Sets Within GPOs

Within Group Policy, two distinct sets of policies are defined:

  • Computer policies. These apply to computers and are stored under Computer Configuration in a Group Policy object.

  • User policies. These apply to users and are stored under User Configuration in a Group Policy object.

Both Computer Configuration and User Configuration have Policies and Preferences nodes. You use:

  • Computer Configuration\Policies to configure policy settings targeted to specific computers.

  • Computer Configuration\Preferences to configure policy preferences targeted to specific computers.

  • User Configuration\Policies to configure policy settings targeted to specific users.

  • User Configuration\Preferences to configure policy preferences targeted to specific users.

Initial processing of the related policies is triggered by two unique events:

  • Processing of computer policies is triggered when a computer is started. When a computer is started and the network connection is initialized, computer policies are applied.

  • Processing of user policies is triggered when a user logs on to a computer. When a user logs on to a computer, user policies are applied.

Once applied, policies are automatically refreshed to keep settings current and to reflect any changes that might have been made. By default, Group Policy on domain controllers is refreshed every 5 minutes. For workstations and other types of servers, Group Policy is refreshed every 90 to 120 minutes by default. In addition, most security settings are refreshed every 16 hours regardless of whether any policy settings have changed in the intervening time. Other factors can affect Group Policy refreshes, including how slow-link detection is defined (per the Group Policy Slow Link Detection Policy under Computer Configuration\Policies\Administrative Templates\System\Group Policy) and policy processing settings for policies under Computer Configuration\Policies\Administrative Templates\System\Group Policy. As discussed in “Determining Policy Settings and Last Refresh” in Chapter 7, you can check the last refresh of Group Policy using the Group Policy Management Console.

GPO Types

As discussed in Chapter 1, there are two types of policy objects: Active Directory–based Group Policy objects (GPOs) and Local Group Policy objects (LGPOs).

Active Directory supports three levels of Group Policy objects:

  • Site GPOs. Group Policy objects applied at the site level to a particular Active Directory site.

  • Domain GPOs. Group Policy objects applied at the domain level to a particular Active Directory domain.

  • Organizational Unit (OU) GPOs. Group Policy objects applied at the OU level to a particular Active Directory OU.

Through inheritance, a GPO applied to a parent container is inherited by a child container. This means that a policy preference or setting applied to a parent object is passed down to a child object. For example, if you apply a policy setting in a domain, the setting is inherited by organizational units within the domain. In this case, the GPO for the domain is the parent object and the GPOs for the organizational units are the child objects.

In an Active Directory environment, the basic order of inheritance goes from the site level to the domain level to the organizational unit level. This means that the Group Policy preferences and settings for a site are passed down to the domains within that site, and the preferences and settings for a domain are passed down to the organizational units within that domain.

TIP

As you might expect, you can override inheritance. To do this, you specifically assign a policy preference or setting for a child container that contradicts the policy preference or setting for the parent. As long as overriding the policy is allowed (that is, overriding isn’t blocked), the child’s policy preference or setting will be applied appropriately. To learn more about overriding and blocking GPOs, see the section “Managing Group Policy Inheritance” in Chapter 7.

While computers running versions of Windows prior to Windows 2000 have only one LGPO, Windows Vista, Windows Server 2008, and later versions allow the use of multiple LGPOs on a single computer (as long as the computer is not a domain controller). On compliant computers, there are three layers of LGPOs:

  • Local Group Policy object. The Local Group Policy object is at the top of the policy hierarchy for the local computer. The LGPO is the only local computer policy object that allows both computer configuration and user configuration settings to be applied to all users of the computer.

  • Administrators Local Group Policy object / Non-administrators Local Group Policy object. Whether the Administrators Local Group Policy object or the Non-Administrators Local Group Policy object applies depends on the account being used. If the account is a member of the local computer’s Administrator’s group, the Administrators Group Policy object is applied. Otherwise, the Non-Administrators Group Policy object is applied. This object contains only user configuration settings.

  • User-specific Local Group Policy object. A user-specific Local Group Policy object applies only to an individual user or to members of a particular group. This object contains only user configuration settings.

These layers of LGPOs are processed in the following order: Local Group Policy object, Administrators or Non-Administrators Local Group Policy object, and then user-specific Local Group Policy object.

Real World

When computers are being used in a stand-alone configuration rather than a domain configuration, you may find that multiple LGPOs are useful because you no longer have to explicitly disable or remove settings that interfere with your ability to manage a computer before performing administrator tasks. Instead, you can implement one local policy object for administrators and another local policy object for nonadministrators. In a domain configuration, however, you might not want to use multiple LGPOs. In domains, most computers and users already have multiple Group Policy objects applied to them—adding multiple LGPOs to this already varied mix can make managing Group Policy confusing. Therefore, you might want to disable processing of LGPOs, and you can do this through Group Policy. To disable processing of Local Group Policy objects on computers running Windows Vista or later, you must enable the Turn Off Local Group Policy Objects Processing setting in an Active Directory–based Group Policy object that the computer processes. When you are editing a GPO in the Group Policy Management Editor, this setting is located under Computer Configuration\Policies. Expand Administrative Templates\System\Group Policy, and then double-click the Turn Off Local Group Policy Objects Processing entry.

Putting this all together when both Active Directory and local policies are in place, policies are applied in the following order:

  1. Local GPOs

  2. Site GPOs

  3. Domain GPOs

  4. Organizational unit GPOs

  5. Child organizational unit GPOs

Because the available preferences and settings are the same for all policy objects, a preference or setting in one policy object can possibly conflict with a preference or setting in another policy object. Compliant operating systems resolve conflicts by overwriting any previous preference or setting with the last read and most current preference or setting. Therefore, the final preference or setting written is the one that Windows uses. For example, by default, organizational unit policies have precedence over domain policies. As you might expect, there are exceptions to the precedence rule. These exceptions are discussed in the section “Managing Group Policy Inheritance” in Chapter 7.

GPO Links

In Active Directory, each site, domain, or OU can have one or more GPOs associated with it. The association between a GPO and a site, domain, or OU is referred to as a link. For example, if a GPO is associated with a domain, the GPO is said to be linked to that domain.

GPOs are stored in a container called Group Policy Objects. This container is replicated to all domain controllers in a domain, so by default all GPOs are also replicated to all domain controllers in a domain. The link (association) between a domain, site, or OU is what makes a GPO active and applicable to that domain, site, or OU.

Linking can be applied in two ways:

  • You can link a GPO to a specific site, domain, or OU. For example, if a GPO is linked to a domain, the GPO applies to users and computers in that domain. The main reason for linking a GPO to a specific site, domain, or OU is to keep with the normal rules of inheritance.

  • You can link a GPO to multiple levels in Active Directory. For example, a single GPO could be linked to a site, a domain, and multiple OUs. In this case, the GPO applies to each of these levels within Active Directory. The main reason for linking a GPO to multiple levels within Active Directory is to create direct associations between a GPO and multiple sites, domains, and OUs irrespective of how inheritance would normally apply.

You can also unlink a GPO from a site, domain, or OU. This removes the direct association between the GPO and the level within Active Directory from which you’ve removed the link. For example, if a GPO is linked to a site called First Seattle Site and also to the cpandl.com domain, you can remove the link from the cpandl.com domain, removing the association between the GPO and the domain. The GPO is then linked only to the site. If you later remove the link between the site and the GPO, the GPO is completely unlinked. A GPO that has been unlinked from all levels within Active Directory still exists within the Group Policy Objects container, but it is inactive.

Connecting to and Working with GPOs

When you use the GPMC to work with GPOs, by default the corresponding changes are made on the domain controller that is acting as the PDC emulator. In this way, the PDC emulator is the central point of contact for GPO creation, modification, and deletion. Active Directory manages policy in this way to ensure that changes to the GPO structure can be implemented only on a single authoritative domain controller and that only one administrator at a time is granted access to a particular GPO. Because the PDC emulator role is specified at the domain level, there is only one PDC emulator in a domain, and therefore only one place where policy settings are changed by default. If the PDC emulator is unavailable when you are trying to work with policy settings, you get a prompt that enables you to work with policy settings on the domain controller to which you are connected or on any available domain controller.

Any user who is a member of the Domain Admins or Enterprise Admins group can view and work with Active Directory–based Group Policy. Unlike local Group Policy, GPO creation and linking are separate operations with Active Directory–based Group Policy. First you create a GPO and define a group of policy settings to achieve desired results. Then you apply your GPO and make it “live” by linking it to the container or containers within Active Directory where it will be applied.

Although creating and linking GPOs are two distinct operations, the GPMC does allow you to create GPOs and simultaneously link them to a domain or OU within the directory. This means you have two options for creating and linking GPOs. You can:

  • Create a GPO and then later link it to a domain or OU within the directory.

  • Create a GPO and simultaneously link it to a domain or OU within the directory.

To link a GPO to a site, the GPO must already exist.

The link is what tells Active Directory to apply the preferences and settings specified in the GPO. For example, you can create a GPO called Main Cpandl.com Domain Policy and then link it to the Domain container for cpandl.com. According to the default (standard) inheritance and policy processing rules, once you link a GPO to a container, the related policy preferences and settings are applied to that container, and lower-level containers within the directory can also inherit the preferences settings. This means a linked GPO can affect every user and computer throughout the enterprise—or some subset of users and computers throughout the enterprise.

Save to your account

This chapter is from the book