Mastering RSoP

I spend a fair bit of time helping folks figure out problems with Group Policy. In the 8+ years I’ve been doing this, by far the biggest improvement in Group Policy management has been the introduction of the Resultant Set of Policies (RSoP) capability in Windows Server 2003 and Windows XP to help us figure out what the effective policy is on our desktops and servers. Understanding what RSoP is and knowing how to read an RSoP for a user or computer will help you ensure Group Policy is healthy and happy in your environment. And, while RSoP won’t help solve every Group Policy problem that arises, an RSoP can point the way toward how to further investigate.

What Is RSoP?
The first thing to understand about the RSoP feature in Windows is that it’s technology that Microsoft built into the Windows Management Instrumentation (WMI) infrastructure beginning with Windows XP. RSoP doesn’t support Windows 2000 because Win2K’s WMI infrastructure and Group Policy engine don’t include the necessary components to collect RSoP information. The Windows 2000 Resource Kit does ship with a command-line utility called gpresult .exe that provides some of the information that RSoP delivers, but this first-try Gpresult doesn’t paint as complete a picture of policy processing as the later RSoP.

When XP and later versions of Windows were introduced, Microsoft provided two main tools for accessing the WMI-based RSoP infrastructure. The Microsoft Management Console (MMC) Group Policy Management Console (GPMC) snap-in provides a graphical UI for accessing RSoP data, and the command line–based Gpresult is built into the OS. Don’t confuse the RSoP-enabled version of Gpresult with the earlier Win2K Resource Kit version. Because the two tools use completely different mechanisms, they can return different information, with the RSoP-enabled version being the more accurate of the two.

So what exactly is RSoP? Well, essentially it’s a mechanism to determine, for a given computer or user in Active Directory (AD), what that computer or user’s effective Group Policy settings are. A user or computer can process many Group Policy Objects (GPOs) in a typical AD environment—with GPOs having possibly conflicting settings. GPOs are processed in a certain order that affects which policy settings will actually apply to a given user or computer, and GPOs can be filtered by using security groups and WMI filters. Given all these factors, you can see how knowing what the effective policy settings are for a given user or computer can be hard, especially in larger organizations. RSoP cuts through the confusion and tells you what’s happening with your Group Policy settings.

RSoP Planning vs. Logging
The RSoP capability in Windows Server 2008, Windows Vista, Windows Server 2003, and XP comes in two flavors. The first, and by far the most common, is known as RSoP or Group Policy Results Logging. (Group Policy Results is the more common name for RSoP.) Group Policy Results Logging, as the name implies, lets you see what policies were applied to a given Windows computer or user. It answers the question, “What policy settings were processed by a given computer or user during the last policy processing cycle?” Logging relies on the Group Policy engine and each Client Side Extension (CSE) that processes the various policy settings to report to WMI on what it did when Group Policy was processed. When you run a GPMC Group Policy Results Logging report, which Figure 1 shows, or use Gpresult from your XP or Vista machine, you’re essentially connecting to the machine you select—local or remote—and gathering the WMI logging data into a report.

The second RSoP flavor, RSoP Planning (also known as Group Policy Modeling in GPMC), answers the question, “What policy should apply to a given computer or user during a future policy processing cycle?” As the name implies, RSoP Planning lets you perform a “what-if” calculation on the policy that a given computer or user will receive. It goes one step better and lets you play with changes that might occur to users or computers to see what effect the changes will have on the users’ or computers’ effective policy.

For example, you can virtually move the user or computer into a new organizational unit (OU) or new security group to see how that will impact its effective policy. You can also simulate how policy would be affected if a slow network link were detected or if loopback policy were in place. All of these “modifications” that you can perform during the modeling phase will affect what policy settings a computer or user receives, and the Group Policy Modeling feature in GPMC lets you simulate these changes easily.

Unlike Group Policy Results, Group Policy Modeling doesn’t require you to query a particular target computer to figure out what will happen. However, it does require access to a Server 2003 or Server 2008 domain controller (DC) to work. In fact, if you have only Win2K DCs in your AD domain, you won’t even see the Group Policy Modeling node when you start up GPMC because the modeling feature uses a service called the Resultant Set of Policy Provider that runs only on the newer DCs. Without this service, modeling won’t run.

Using and Deciphering RSoP Logging
Now that you know what RSoP is, let’s look at how you can use it to get more insight into your Group Policy settings. I find the version of Group Policy Results Logging that’s available in GPMC easier to use than the command-line Gpresult utility, so let’s start with the graphical version.

A note before we dive into the details: If you’re working in a mixed environment of Server 2008, Vista, Server 2003, and/or XP, the rule of thumb is to run Group Policy Results on a machine that has the same or a more recent OS version than the machine whose results you’re testing. So, if you’re running Group Policy Results against a Vista machine, run it from a Vista machine, not an XP machine. You’ll get more complete results this way.

The other thing to be aware of at this point is that the computer for which you’re collecting Group Policy Results must be accessible on the network from your management station. That means it must be up and running and must not have a firewall blocking access to the ports and protocols required by Group Policy Results. Because Group Policy Results uses remote WMI calls to get access to this information, you typically need to ensure that the remote system allows the DCOM protocol. This protocol uses TCP port 135 for initial setup and random ports greater than 1024 for ongoing communication. If the target machine uses Windows Firewall, the easiest way to ensure that the necessary ports are unblocked is to use the built-in Remote Administration Exception provided in Group Policy. You can find this exception on XP and Server 2003 in GPMC under Computer Configuration\Administrative Templates Network\Network Connections\Windows Firewall\Standard (or Domain) Profile\Windows Firewall: Allow Remote Administration Exception and on Vista and Server 2008 under Computer Configuration\Windows Settings\Security Settings Windows Firewall with Advanced Security Inbound Rules, under the Predefined Rules selection.

Continue on Page 2

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.