Mastering RSoP

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 at wms18.streamhoster.com/pentonmedia/windows/winscreencasts/RSOPMarElia.wmv.

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

   Previous  1  [2]  Next