11. 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 common practice because this
particular configuration follows a GPO best-practice recommendation.
Because 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 policies that
were linked to that container. The resulting impact of this processing
order is 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, you can run Group Policy Modeling from the Group Policy
Management Console. Group Policy Modeling provides a report detailing
which policies were applied, in which order the policies were applied,
and the resulting policy settings. One easy way to understand this is to know that when looking at a
particular Active Directory container in Group Policy Management
Console, the group policy link order and the GPP 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.
12. GPO Filtering
Applying GPOs can be tricky, and the design of
the Active Directory forest, domains, sites, and OU hierarchy plays a
major part in this. One of the most important considerations 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.
In many cases, even with the most careful
planning of the Active Directory infrastructure, GPOs will be applied to
computers/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 actually apply the
policy. The mechanisms that control or filter how a policy will be
applied are as follows:
• GPO links
• GPO security filtering
• GPO Windows Management Instrumentation (WMI) filtering
• GPO status for the Computer Configuration or User Configuration nodes
GPO Links
Group policy links are required to determine
which sites, domains, or organization units the policy will apply to.
When a new policy is created, before it can ever be used it must be
linked. Before it is linked, though, the security filtering, status, and
WMI filters should be configured to further segment policy application
to more specific computer and user objects within the linked container
hierarchy.
GPO Security Filtering
GPO security filtering is the group
in Group Policy. Many administrators can get frustrated 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 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 5, and replacing it with specific computer accounts, user accounts, or security groups.
Figure 5. Group Policy 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 or computer objects, 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 is a query that
includes only computer objects with an OS version of 6.2*, which
includes all Windows 8 and Windows Server 2012 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 Directory hierarchy is relatively
flat, but maintaining computer group membership can be tedious.
GPO Status
GPOs
are applied to computer and user objects. Within a particular GPO, the
settings available are segmented into two distinct nodes: the Computer
Configuration node and the User Configuration node.
Configuring or changing the GPO status, shown in Figure 6, enables administrators to change the GPO as follows:
• Enabled (Default)
• User Configuration Settings Disabled
• Computer Configuration Settings Disabled
• All Settings Disabled
Figure 6. Group Policy status
This function of a GPO can be a very effective
tool in troubleshooting GPOs as well as optimizing GPO processing. For
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 configured settings. This simple
check can add a few seconds to the entire GPO processing time 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 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 undesired
result.
13. Group Policy Loopback Processing
Group Policy loopback processing, shown in Figure 7,
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 server 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
Active Directory.
Figure 7. GROUP Policy loopback processing.
There are two different loopback
configurations: replace mode and merge mode. Merge mode applies the
user-based policies that would normally apply to the user account as
well as the user-based policies on the container that contains the
computer account the user is logging on to. Replace mode processes only
those user policies applied to the computer the user is logging on to.
14. Group Policy Slow-Link Detection and Network-Location Awareness
Group Policy uses several mechanisms to
determine whether a policy should be processed. One of the mechanisms
used by the Group Policy client computer is called slow-link detection.
By default, network tests are performed between the client computer and
the domain controller to determine the speed of the link between the
systems. If the speed is determined to be less than 500Kbps, the Group
Policy client does not process any policies. Slow-link detection default
settings, along with the ability to disable slow-link detection, is
configurable with each policy.
In earlier versions, Group Policy used
Internet Control Message Protocol (ICMP) or ping to detect slow links.
With Windows Vista, Windows Server 2008, and later OSs, Group Policy now
uses the Windows Network Location Awareness service to determine
network status. The slow-link detection settings are controlled within
the Policies\Administrative Templates\System\Group Policy sections of
the GPO. Starting with Windows Server 2012 policy templates,
administrators can also configure links detected at 3G connections to be
treated as slow links.
