Windows Server 2008 R2 Unleashed (122 page)

Windows Update, while an OU representing a branch office in the domain can have a

GPO linked that enables the branch office desktop administrators security group to run

Windows Update.

ptg

GPO links inherited from parent containers are processed before GPO links at the

container itself, and the last applied policy setting value is the resulting value, if multiple

GPOs have the same configured setting with different values. This Group Policy inheri-

tance is also known as GPO precedence and is shown in Figure 19.6.

19

FIGURE 19.6

Examining Group Policy precedence.

598

CHAPTER 19

Windows Server 2008 R2 Group Policies and Policy Management

Group Policy Block Inheritance

Just as GPOs can be inherited, Active Directory also provides the option to block inheri-

tance, as shown in Figure 19.7, of all GPOs from parent containers. This is actually an

option applied to an Active Directory domain or organizational unit within the Group

Policy Management Console and not on a GPO. This option can be useful if the

container contains users and/or computer objects that are very security sensitive or busi-

ness critical. As an example of this option in use, an OU can be created to contain the

Remote Desktop Services host systems, which would not function correctly if domain-

level GPOs were applied. The OU can be configured to block inheritance to ensure that

only the policies linked to the particular OU were applied. If GPOs need to be applied to

this container, links would need to be created at that particular container level, or the

GPO link from the parent container would need to be enforced, which would override

the block inheritance setting.

ptg

FIGURE 19.7

Blocking GPO inheritance.

Group Policy Order of Processing

GPOs can be linked at many different levels and in many Active Directory infrastructures;

multiple GPOs are linked at the same OU or domain level. This is a very common practice

because this particular configuration follows a GPO best-practice recommendation,

included in a later section in this chapter, of creating separate GPOs for a particular set of

functions. As GPOs are processed one at a time, the GPO links are processed in a particular

order starting with GPOs inherited from parent containers followed by the order of poli-

cies that were linked to that container. The resulting impact of this processing order is

Elements of Group Policy

599

that when multiple GPOs contain the same configured setting, the last GPO applied

provides the resulting setting value. As an example of this, if two GPOs are linked at the

domain level, named GPO1 and GPO2, and GPO1 has a configured setting of “Remove

Task Manager” set to disabled and GPO2 has the same setting set to enabled, the end

result is enabled for that setting. To fully understand what the end resulting policy will be

in a container that has multiple GPOs linked and inherited, the Resultant Set of Policy

tool should be run in Planning mode from the Active Directory Users and Computers

console or Group Policy Modeling can be run from the GPMC console. Resultant Set of

Policies will provide a console showing the final applied policy settings. Group Policy

Modeling will go further and provide a report detailing which policies were applied, in

which order the policies were applied, and the resulting policy settings. The steps required

to run Group Policy Modeling are detailed in Chapter 27. One easy way to understand

this is to know that when looking at a particular Active Directory container in GPMC, the

group policy link order and the group policy precedence order are processed from the

highest number down. This means that the group policy that has a link order of 1 will

always be processed last by objects within that container.

GPO Filtering

Applying GPOs can be tricky and the design of the Active Directory forest, domains, sites,

and OU hierarchy play a major part in this. One of the most important considerations

ptg

when designing the Active Directory OU hierarchy within a domain is to understand how

the domain administrators plan to manage the domain computers and users with group

policies. Designing the Active Directory infrastructure is discussed in detail in Chapters 5

and 6, “Designing a Windows Server 2008 R2 Active Directory” and “Designing

Organizational Unit and Group Structure,” respectively.

In many cases, even with the most careful planning of the Active Directory infrastructure,

GPOs will be applied to computers and/or users that do not necessarily need the settings

contained within that GPO. To better target which computer and user objects a particular

GPO applies to, Microsoft has built in a few different mechanisms to help filter out or

include only the necessary objects to ensure that only the desired computers or users actu-

ally apply the policy. The mechanisms that control or filter how a policy will be applied

are as follows:

. GPO security filtering

19

. GPO WMI filtering

. GPO status for the Computer Configuration or User Configuration nodes

GPO Security Filtering

GPO security filtering is the “group” in Group Policy. Many administrators can get frus-

trated when having to explain the fact that Group Policy applies to computers and users

but not to groups. In fact, the GPO security filtering is where administrators can define

which users, computers, or members of security groups will actually apply the group policy.

By default, GPOs apply to the Authenticated Users security group, which includes all users

and computers in the domain. The scope of GPO application is then segmented based on

600

CHAPTER 19

Windows Server 2008 R2 Group Policies and Policy Management

the location of the Group Policy links. It can be segmented even further by removing the

Authenticated Users group from the GPO security filtering, as shown in Figure 19.8, and

replacing it with a custom security group.

ptg

FIGURE 19.8

Examining GPO security filtering.

When the security filtering of a GPO is configured to apply to a custom security group,

only the members of that group, whether users, other groups, or computer objects, will

actually apply that particular policy. Last but not least, it is most important to always keep

the group membership current; otherwise, the application of Group Policy might be

incomplete or incorrect.

GPO WMI Filtering

GPO WMI filtering is a Group Policy concept introduced in Windows XP and Windows

Server 2003. A WMI filter is a query that is processed by computer objects only and can be

used to include or exclude particular computer objects from applying a GPO that includes

the WMI filter. An example of a WMI filter could be a query that includes only computer

objects with an operating system version of “6.1*,” which includes all Windows 7 and

Windows Server 2008 R2 systems. Of course, it is important to state that WMI filters will

not be processed by legacy Windows 2000 or older systems. The security filtering must

also meet the criteria for the GPO to be processed. WMI filters work great when the Active

Elements of Group Policy

601

Directory hierarchy is relatively flat, but maintaining computer group membership can be

tedious. How to create WMI filters, including a few examples, is included in Chapter 27.

GPO Status

As mentioned previously in this chapter, GPOs are applied to computer and user objects.

Within a particular GPO, the settings available are segmented into two distinct nodes,

including the Computer Configuration node and the User Configuration node.

Configuring or changing the GPO status, shown in Figure 19.9, enables administrators to

change the GPO as follows:

. Enabled (Default)

. User Configuration Settings Disabled

. Computer Configuration Settings Disabled

. All Settings Disabled

This function of a GPO can be a very effective tool in troubleshooting GPOs as well as

optimizing GPO processing. As an example, if a GPO only contains configured settings in

the Computer Configuration node, if any user objects are located in containers linked to

that particular GPO, the GPO will still be processed by the user to check for any config-

ured settings. This simple check can add a few seconds to the entire GPO processing time

ptg

for that user, and if many GPOs are processed, it could increase the logon, logoff, or

refresh interval by minutes or more. As a troubleshooting tool, if a user or computer is

19

FIGURE 19.9

Examining GPO status.

602

CHAPTER 19

Windows Server 2008 R2 Group Policies and Policy Management

not receiving the desired end result of a set of applied policies, disabling a node or the

entire policy can aid an administrator in identifying the suspect GPO causing the unde-

sired result.

Group Policy Loopback Processing

Group Policy loopback processing, shown in Figure 19.10, allows for the processing of

both the Computer Configuration and User Configuration nodes within a policy even if

the user object is not in the same container as the computer that the group policy is

linked to. As an example, this function would be useful with a Remote Desktop Session

Host deployment where you want to apply computer configuration policies to configure

the Remote Desktop server settings but you also want to control the user settings of any

user who logs on to the server, regardless of where the actual user account is stored in