Troubleshooting
Group Policy
Because Group Policy is complex, sometimes
it doesn’t work the way you expect. You might
have inadvertently misconfigured something,
or it might not work because something is simply
broken. Group Policy processing requires
several elements to work in harmony. Your AD
infrastructure must be healthy, your workstations
must be healthy, and the various settings
that you configure must be compatible with
the applications running on your desktops.
When any of that is out of whack, you might
see Group Policy processing failures.
When failure happens, how do you find out
what is amiss? The first step is to create a Resultant
Set of Policy (RSoP) report on the problem
computer. RSoP is gathered using the Group
Policy Results Wizard within GPMC. You can
also use the command-line utility gpresult.exe
that comes with Vista, Windows 2003, and XP,
to generate an RSoP report. The easiest thing
to do is to run the Group Policy Results wizard from GPMC. The wizard lets you pick a local
or remote computer to connect to, then pick
a user who has logged onto that computer.The wizard then connects to that remote computer
and gathers information about Group
Policy processing that occurred during the last
processing cycle. The most useful part of that
report is the Summary tab, which you can see
in Figure 4.
The summary tab shows you which GPOs
were applied to the computer and user, and
most importantly, which GPOs were denied
and why. In the Component Status section,
the report can give you information about
whether any specific portions of Group Policy
processing failed and why. The Group Policy
Infrastructure item you see in that section tells
you whether the basic setup of Group Policy
processing succeeded. If this step fails, then it
usually indicates some infrastructure problem
that’s preventing any Group Policy processing
from occurring. If the error occurs in one
of the so-called client-side extensions that
implement the various policy areas, then you
might be able to isolate the problem by using
the error messages provided. If you want to
see which individual policy settings are being
delivered to the computer or user, then you can view the Settings tab in the Group
Policy results report to see which
settings “won” and are being processed.
However note that just
because the RSoP report says the
setting has been applied doesn’t
actually guarantee that the setting
was successfully made. It’s best to
sometimes check the underlying
setting, be it a registry value or
security setting, to be sure.
You can also look in the
Application event log on a given
Windows system (note that Vista
puts Group Policy events into
the System event log and the
Group Policy Operations log) to
see additional errors related to
Group Policy processing.
With Knowledge
Comes Power
Group Policy is complex and
powerful. By understanding how
Group Policy is processed, you
can get a better handle on using
its power. Remember that Group
Policy is processed in order of local GPO, AD
site, domain, then OU (sometimes referred to
as LSDOU) and that typically, the “last writer
wins” when there are conflicting settings. Policies
and preferences can affect how policy stays
on your systems when the GPO is removed,
and making explicit choices about using each
is important. The registry policies delivered by
Microsoft in their standard ADM and ADMX
files don’t typically tattoo the registry, but any
custom ADMX files you use might. In addition,
other policy areas such as security do tattoo
your systems and must be explicitly “un-done”,
while some policy areas must be told to be
undone when they no longer apply. Finally,
if policy is still not doing what you expect, fall
back to the Group Policy Results wizard in
GPMC to tell you what’s actually going on with
your problem system and to point you toward
a solution.
End of Article
