Whether you’re faced with configuring 10 Windows servers and desktops or
10,000, you know that Group Policy offers valuable assistance to ensure
you complete the task in time for you to head home and have a life. But
you’ve probably also heard the horror stories of Group Policy’s complexity,
where a sys admin made changes without understanding their
consequences and paid the price in making life more difficult instead of
easier. For example, ever look to modify the “Logon Locally” user right
on a Group Policy Object (GPO) to remove unnecessary groups, only to
discover that you did it on a GPO that applies to everyone in the domain, and now no one can log
on? I can tell you that that has happened more than once.
Problems such as these are common. But you can ensure that Group Policy lives up to its
potential—just by making sure you nail down a few essential concepts: how GPOs are processed,
how permissions and filtering work, the difference between policies and preferences, and how to
use some basic troubleshooting steps.
Understanding Group Policy Processing
How the client processes GPOs is fundamental to ensuring that everything goes according to plan.
Let’s start by realizing that, despite the fact that the feature is named Group Policy, policies are processed
only by computers and users. So, when you link a Group Policy Object (GPO) to an Active
Directory (AD) object, the computer portion of that GPO is read only by computer objects in AD
and the user portion is read only by user objects. You can use security groups to filter which users
and computers are subject to a given GPO, but you can’t target GPOs at specific security groups.
Confused? Just think of it this way: Whenever you link a GPO to an object, domain, or organizational unit (OU) in AD, make sure that the user
or computer that you want the GPO to apply to
is beneath the linked container within the AD
tree. If it isn’t, then the user or computer won’t
see the GPO and can’t process it.
The process of linking a GPO is different
from the process of creating it. When you created
a GPO from the Microsoft Management
Console Active Directory Users and Computers
snap-in in Windows 2000, you linked the
GPO to the AD container you were focused on
in the same step. The ability to create a GPO
without linking it came with the advent of
Group Policy Management Console (GPMC).
With GPMC, you can create GPOs without
linking them, and then link them later.
You can also re-use a GPO by linking it to
multiple AD containers—for example, you
might link one desktop lockdown GPO to four
or five OUs. A big benefit of linking a GPO to
multiple containers is that any change you
later make to that GPO will affect the users
and computers in all the linked OUs. However,
because you can link GPOs to multiple
containers in AD, a given user or computer
might process multiple GPOs. To know which
policy applies in that case, you need to know
the answer to a couple of questions: How doesGroup Policy know which GPO to process first,
and which settings ultimately apply if the different
GPOs have different settings?
Group Policy processing follows a specific
order. The local GPO on a given computer is
processed first, followed by GPOs linked to
AD sites, then GPOs linked to an AD domain,
and finally those linked to OUs. Because OUlinked
GPOs are processed last, they “win”
the contest that determines which GPO’s
settings actually apply to the
computer or user. For example,
if a domain-linked GPO
removes the Run option from
the Windows Start menu and
an OU-linked GPO adds the
Run option back to the menu,
the OU-linked GPO will apply
because the user processes it
second, and the Run option
will appear in the user’s Start
menu.
Group Policy uses both
foreground and background
processing. For a computer,
foreground processing happens
when the computer initially
starts up, typically—but
not always—before the user sees a logon dialog.
For a user, foreground processing occurs
when the user logs on, typically—but again not
always—before the user sees his or her desktop.
Background processing takes place periodically
to refresh Group Policy. On domain
controllers (DCs), background processing for
computers and users occurs every five minutes.
On member servers and workstations,
it occurs by default every 90 to 120 minutes.
Although Group Policy is refreshed automatically
during background processing, not all
policy areas run during background processing.
For example, neither software installation
nor Folder Redirection policy runs in the background.
Group Policy Permissions
and Filtering
As I mentioned earlier, GPOs are processed
only by users and computers, but they can be
filtered by security groups that contain user
or computer accounts. By default, when you
create a GPO, the Authenticated Users group
receives Read and Apply permissions to that
GPO, which gives all users and all computers
the ability to see, and thus to process, the GPO.
But you might sometimes want only a subset
of users or computers in a given OU to process
a GPO. In that case, you can use security
groups to filter the GPO. That process is easily
done by using a must-have tool: Group Policy
Management Console (GPMC), which ships
with Windows Vista and can be downloaded
by searching in System Tools at www.microsoft
.com/downloads.
As Figure 1 shows, you can modify the
security filtering on a given GPO by simply
adding and removing groups from the Security
Filtering section in GPMC.
Let’s say, for example, that you have a GPO
linked to the Marketing OU, which contains 200
user accounts. You want to deliver some user
policy settings to a subset of those users—the
users who are also members of the Marketing
Special Projects group. Using GPMC, this task
is easy. Start GPMC by entering
gpmc.msc
in the Run dialog box on the Start menu.
Under the Group Policy Objects node in the
tree pane, select the GPO you want to filter.
Remove the Authenticated Users group from
the GPO because that group lets all users and
computers process that policy. To do so, highlight
that group in the Security Filtering dialog
box and press the Remove button. Then add
the Marketing Special Projects group to the
security filtering list by clicking the Add button
and entering or searching for the “Marketing
Special Projects” group in your AD domain.
GPMC takes care of granting the Read Group
Policy and Apply Group Policy permissions
on that GPO.
Previous
Register
