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