Ok, let’s get started. Suppose you want
to verify that a certain workstation has
retrieved some policy settings. Start GPMC,
right-click the Group Policy Results node,
then select the Group Policy Results Wizard
option. The first wizard screen lets you
select a remote or local computer to connect
to. If you’re interested only in per-user
settings, you can also select a check box to
exclude any per-computer settings in the
report that will be generated.
After selecting the computer you want to
target, the next wizard screen lets you select
a user who has logged onto that computer,
if you want to return per-user Group Policy
settings in addition to computer settings.
The Group Policy Results wizard UI will
show you only those users who have logged
onto the remote system and generated
RSoP data. If you don’t see a user in the
list, he or she likely hasn’t logged onto that
system. After you select the user, the Group
Policy Results wizard collects the WMI data
from the selected computer and displays it
in the GPMC’s right-hand results pane, as
shown in Figure 1.
Interpreting the Results
Once you’ve run the Group Policy Results
wizard and the results are displayed, you
can dive in and interpret those results. In
the right-hand results pane are three tabs:
Summary, Settings, and Policy Events. Table
1 describes the purpose of each.
The Summary tab is probably the most
interesting in terms of finding out what’s
going on with Group Policy on the remote
system, so let’s examine it in detail. Figure
2 shows an expanded Summary
tab with all its sections.
Assuming you selected to show both
per-computer and per-user Group Policy
settings, the summary will be broken into
two sections: Computer Configuration
Summary and User Configuration Summary.
In each of these sections are five
subsections that provide details about what
policies were processed. The most interesting
subsections are Group Policy Objects
and Component Status.
The Group Policy Objects subsection
is further divided into Applied GPOs and Denied GPOs. Applied GPOs lists the GPOs
that were processed by the computer or
user, to which AD container those GPOs
were linked, and what their AD and SYSVOL
version numbers were. This information
is important because it lets you verify that
a particular GPO that you think should be
processed by the computer or user really
is being processed. The version numbers
are important because they should always
be the same for a given GPO. If the AD and
SYSVOL version numbers are different from
each other, the GPO being processed could
be out of sync on the DC that the computer
is using to process policy, which could indicate
a replication problem (or simply that
you initiated Group Policy Results processing
without leaving enough time for GPO
changes to replicate to the DC).
The Denied GPOs section is equally
interesting because it tells you exactly why a
GPO wasn’t processed, even though it might
be linked to a container in AD that includes
the computer or user. The most common
reasons for GPOs being denied—or, more
correctly, not processed—include security
group filters or WMI filters that prevent
them from being processed, a link being
disabled, or the GPO being empty (i.e.,
containing no settings). The Denied GPOs
section can provide good information about
how you’re applying your policies and
might indicate places where you can get rid
of “dead” GPOs that computers or users are
trying to process but can’t.
The Component Status section of the
results is the really interesting part! It’s the
portion of the report that tells you whether
Group Policy processing actually worked for
the computer or user in question. This section
of the report is broken down into each
part of the Group Policy processing cycle.
The component named Group Policy Infrastructure
represents what’s called the core phase of Group Policy processing. During
this phase, the computer or user account
reads the list of GPOs it must process, finds
out which ones it has access to, and creates
the list of CSEs that must process the policy
settings in those GPOs. If this part of the
processing cycle fails, then the rest of the
cycle will fail.
The subsequent components listed are
the various CSEs that ran for the computer
or user during the last processing cycle.
These include the different policy areas
such as Registry, Security, and Software
Installation. The report shows whether each
item succeeded or failed and, if it failed, will
often show the related error information.
In Figure 2, the Software Installation item
is Pending. The software installation CSE
requires a foreground processing event (i.e.,
a system reboot or user logon) to actually
run, so while the component hasn’t failed,
it hasn’t yet run. The Component Status section
is also marked with a visual cue—a red
X in the case of a failed event or a yellow ! in
the case of a warning such as the pending
state of software installation.
The Settings tab of the Group Policy
Results report, shown in Web Figure 1,
gives you a breakdown of the actual policy
settings that were applied to the computer or
user and the name of the GPOs that delivered
those settings. The report in Web Figure 1 shows the details of some Administrative
Template Windows Firewall settings that
were processed by the client. For Administrative
Templates, the report actually includes
the Explain text that goes along with the policy
to remind you what the policy is for. Note
also that, on Vista and Server 2008 systems,
the report lets you know that Administrative
Template policy descriptions were retrieved
from the central store, which is the serverbased
file-system location where ADMX and
ADML files can be kept.
When you select the Policy Events tab
of the Group Policy Results report, you see
a list of Group Policy–related events that
occurred on the remote system. These look
and feel like Windows Event Viewer events
because that’s where they come from. In
many cases, the events that are the most
interesting are the error or warning events,
but frankly, I haven’t found much of use in
this information, due to the sheer volume
of events and the lack of detail about them.
However, it’s worth looking at this view if
you’re having problems because some useful
information could turn up.
If you want to save the information from
the Summary or Settings tabs, right-click
over the area of either tab and select Save
Report to send the report to an HTML or
XML file. The XML file format is useful only if you plan to repurpose the raw
data somewhere else.
You can view a five-minute
screencast that shows how to run
the Group Policy Results wizard
and view the output. Click one of the Group Policy Results Screencast links at the top of the page.
Under the Covers
GPMC and Gpresult hide the complexity
of how RSoP data is collected
in WMI, but if you’re familiar with
WMI and know how to query its
contents, you can get directly at the
WMI data that underlies those nice
RSoP reports. RSoP data is held in a
special namespace within WMI specifically
for that purpose. Whereas
you might be familiar with querying
information in the root\CIMv2
namespace, RSoP data is held in
root\RSOP. The data is broken down
into a number of different classes,
each representing different policy
areas (e.g., registry, folder redirection,
security). Figure 3 shows a view
into this namespace through a WMI
browser tool called WMIX, which
you can download at www.pjtec.com/WMIX.
What you see here is a number of
containers in the RSOP namespace.
The containers that start with NS followed
by a bunch of alphanumeric
characters are called RSoP Sessions.
They represent me running RSoP
reports remotely against this system,
called XP3. In Figure 3, I’ve drilled
down into one of these sessions and
you can see a number of WMI classes
representing the various policy areas
that you’d typically look at in an RSoP
report. If I viewed the instances on
these classes, I would see the raw
Group Policy settings data that the
GPMC report returned.
RSoP data provides a powerful mechanism
for discovering how Group Policy is
working on your remote Windows systems.
Using GPMC or Gpresult, you can both
model what should happen with Group
Policy for a given user or computer, as
well as what did happen. And not only do
you get to see the actual settings that were processed, but you can also see whether
any errors occurred during processing that
might have prevented settings from being
delivered. This important tool goes a long
way toward guaranteeing that Group Policy
is doing what it’s supposed to do—keeping
your systems secure and locked down.
End of Article
