It’s a good bet you’re familiar with group policy, which enables administrators to assert change control and set a broad range of settings for the operating system, desktop and working environment, network, and much more for servers and workstations. You might also know that group policy can be applied at different levels, which opens the possibility for a policy at one level to override the policy set at another level. So, determining the resultant set of policy (RSoP) can sometimes be difficult. At best, it can be confusing. To help administrators get a handle on group policy, Microsoft introduced the Resultant Set of Policy MMC snap-in. Here’s what the RSoP snap-in does and how you can use it to get a handle on your own policies.
How Group Policies are applied
Understanding how RSoP works requires that you first understand how group policy is applied and the factors that affect policy application. Group policy can be applied at the site, domain, domain controller, organizational unit (OU), and local levels. Whether a particular policy is effective depends on the level at which it is applied and whether the same policy is set differently at a level with higher precedence. Group policy is applied in the following order of precedence:
- OU policy
- Domain controller policy
- Domain policy
- Site policy
- Local policy
In addition, you can set the No Override attribute for a group policy object (GPO). When No Override is enabled, other GPOs that set corresponding policies cannot override the ones set in the protected GPO. For example, assume you set a policy at the OU level, which gets applied first, and set the policy differently in a GPO that is assigned at the domain level. At this point, the domain policy will overwrite the OU policy. However, you enable the No Override attribute for the OU-based GPO. Now, even though the domain GPO would be applied after the OU policy and therefore take precedence, the No Override attribute on the OU GPO prevents its settings from being overwritten.
One other factor that determines whether the settings in a given GPO become effective is the permissions set on the GPO. For example, if you remove the Read Or Apply Group Policy permissions for a given security group, the GPO’s policies will not be set for users in that target group.
What’s the RSoP snap-in?
The RSoP snap-in enables you to query current or planned policies and view the results of that query, which is the resultant set of policies, for a specified target user and computer. In addition to group policies, RSoP includes administratively assigned settings including those from administrative templates, folder redirection, Internet Explorer maintenance, security settings, scripts, and software installation policies. By including these objects, RSoP provides a complete view of the environment resulting from all of these settings.
The RSoP snap-in operates in one of two modes: Logging Mode or Planning Mode. In Logging Mode, the RSoP snap-in queries policies and displays the resulting policy set for a given user and computer. Logging Mode therefore enables you to review the policy settings that are applied for the target user/computer. Logging Mode can be a valuable and effective tool for troubleshooting policy application problems and determining how security groups affect policy settings.
Planning Mode enables you to explore different policy scenarios. In Planning Mode you specify several items of information about the desired target including container or user, computer, site, security group membership, and other factors to determine the resultant set of policy based on those selections. Planning Mode offers an excellent means for determining the results of planned policy deployment and testing the deployment before actually rolling it out.
The RSoP snap-in is available with Windows XP as well as Windows Server 2003. You don’t need to run the snap-in on a domain controller to gather information about a user or computer from the Active Directory in Planning Mode. Instead, you can run it from a Windows XP workstation.
Both RSoP modes are useful in different scenarios. I’ll explore both, beginning with Planning Mode. All examples assume you are running the RSoP snap-in on Windows Server 2003, but it’s very similar on Windows XP.
Using RSoP in Logging Mode
If you’ll be querying policies from a remote computer, you must first log on as a member of the Domain Admins or Enterprise Admins security groups, or you must have been delegated Generate Resultant Set of Policy (logging) rights. (I cover delegation later in this article.) For local querying and logging, any user can run a Logging Mode query on the local computer.
To begin using RSoP, you need to open the RSoP snap-in. Choose Start, Run, and enter MMC. When the MMC opens, choose File, Add/Remove Snap-In. On the Standalone tab, click Add to open the Add Standalone Snap-In dialog box. Scroll down, choose Resultant Set of Policy, click Add, and then click Close. Click OK on the Standalone tab to close it and return to the MMC.
The RSoP snap-in at first doesn’t look like much (Figure A) because you haven’t queried for any policies yet. To query policy, you need to run the Resultant Set of Policy Wizard. Right-click the Resultant Set of Policy branch in the left pane and choose Generate RSoP Data to start the wizard. Click Next to get past the obligatory splash screen and then choose Logging Mode. When you click Next, the wizard prompts you to select the computer to use as the target (Figure B). You can choose the local computer, specify the remote computer name, or click Browse to look for the computer in the Active Directory.
Figure A |
![]() |
The RSoP MMC starts off empty. |
Figure B |
![]() |
Select the computer to examine. |
The option at the bottom of the Computer Selection dialog box lets you exclude computer settings from the query. This is handy when you want to focus solely on user policies, such as when you suspect a user setting is causing the problem at hand. Using this option excludes half of the possibilities and simplifies the resulting policy set.
Next, the wizard prompts you to specify whether to use the current user (the one under which you are logged on) or to select a specific user (Figure C). What the user list displays in the wizard depends on how you are logged on. If you are logged on with a regular local account, you’ll see only that account. If you log on as the local administrator, you’ll see the local administrator account and all other local accounts that have been used to log on at least once (accounts that have never logged on do not appear). It’s necessary to log on with a domain user account prior to running RSoP if you want to view the policies for that domain account. Logging on with the domain administrator account lets you choose that domain administrator account or any local accounts that have been used previously to log on.
Figure C |
![]() |
Select what user to check policy on. |
You can also select an option here to exclude the user settings and only show the computer settings. Again, this option is handy when you want to focus solely on computer settings and simplify the resulting query. The Summary dialog box that appears when you click Next shows the settings you have selected.
After the wizard finishes the query, the RSoP snap-in will probably look a little more familiar to you (Figure D), particularly if you have worked with the Group Policy Editor. The left pane provides a hierarchical tree of settings. When you click a branch in the left pane, the policies under that branch appear in the right pane. The columns in the right pane are essentially the same as in the Group Policy Editor, but with the addition of a Source GPO column that indicates the source for the policy setting. You can double-click a policy to open a dialog box that shows more information about the policy, including its value (Figure E) and precedence (Figure F).
Figure D |
![]() |
Here’s a completed RSoP MMC.
Figure E |
![]() |
You can view the value of a policy. |
Figure F |
![]() |
You can also view the group policy precedence. |
At this point you can browse through the policies as needed. If you need to view policies for a different computer or user, you can either clear the current query and reissue it, or open another instance of the snap-in focused on the desired target. To clear the query and start a new one, right-click the upper-most branch of the policy target in the left pane and choose Change Query to start the Resultant Set of Policy Wizard. Follow the steps in the wizard to specify the information for the new query, just as you did for the old one.
Opening a new instance of the RSoP snap-in rather than clearing the existing query is useful when you need to compare settings between policy targets. Just add the snap-in as you did for the first one, then right-click the new instance in the left pane and choose Generate RSoP Data.
Using RSoP in Planning Mode
As I mentioned at the beginning of this article, Planning Mode enables you explore different policy scenarios. Essentially, Planning Mode lets you play “What if?” with policies and can be extremely useful for the following tasks:
- Simulating the effects of policy changes at various levels
- Viewing policies of new user accounts in the Active Directory
- Testing policy precedence when the computer and user are in different security groups or different OUs
- Determining the effects of moving a computer to a new location
- Simulating a slow network connection
- Simulating a policy loopback scenario
I’ll cover these in a moment. For now, let’s get into Planning Mode. Start by adding the RSoP snap-in to an MMC console. After you’ve added the snap-in, right-click the Resultant Set of Policy branch of the snap-in in the left pane and choose Generate RSoP Data to start the Resultant Set of Policy Wizard. In the wizard, choose Planning Mode when prompted to choose the mode and then click Next. The wizard displays the User And Computer Selection page shown in Figure G. Here you choose either a user or a container in the AD. You also specify the container for the computer or choose a specific computer.
Figure G |
![]() |
Choose the container here. |
On the Advanced Simulation Options page (Figure H) you can specify some additional options to test certain scenarios. For example, choose the Slow Network Connection option if you want to test the effect of a slow network connection on the application of group policy. Why do that? A slow network connection can affect policy application, causing some policies not to be applied. Choosing the option to simulate a slow network connection causes the RSoP console to slow the data transfer, enabling you to see the effects on the resultant set of policies.
Figure H |
![]() |
You can select additional options for the RSoP console. |
The Loopback Processing option lets you simulate the effect of configuring the User Group Policy Loopback Processing Mode policy for a GPO. Loopback provides a mechanism by which you can control the way group policies are applied. This policy offers two values when set to Enabled: Replace or Merge.
When Replace is selected, the group policy object list for the user is replaced entirely by the list already obtained for the computer at startup. When set to Merge, the group policy list is a concatenation of the computer list obtained at startup and the user list obtained after logon. Setting this option in the RSoP snap-in in Planning Mode has the same effect as setting the User Group Policy Loopback Processing Mode policy for the target GPO.
The Advanced Simulation Options page also allows you to choose a site for the scenario. Site selection here enables you to analyze the effect of settings based on startup or logon on a subnet other than the one from which you are running the query. In the Alternate Active Directory Paths page that follows in the wizard (Figure I), you specify the location in which the target policy is intended to be applied.
Figure I |
![]() |
Choose a site for your test scenario. |
In the next two pages of the wizard you have the capability to specify the security groups in which the user and the computer reside. Figure J shows the User Security Groups page (the Computer Security Groups page is similar). You can add and remove groups to simulate the effect of actually changing group membership for the target. However, you’re only changing the simulated group membership, not the actual group membership. In this way you can test the effects of membership changes before you actually make those changes.
Figure J |
![]() |
You can simulate the effects on different groups. |
The next two pages of the wizard prompt you to specify how WMI filters for the GPO are to be handled. WMI filters enable you to filter the application of group policy based on criteria such as hardware configuration. With these two pages you can specify that all WMI filters be applied or only apply selected filters for the user and/or computer. The final page of the wizard displays a summary of your selections and allows you to choose the domain controller on which to process the simulation.
As with Logging Mode, Planning Mode generates a policy set that you can navigate and view. Policies that have a setting other than Not Defined have a red circle and X icon. This helps you quickly identify policies that have been set.
Viewing error information
Unless you direct it not to do so, the RSoP snap-in collects extended error information as it performs the query. You can view this error information to determine if any problems occurred during the query. The availability of these error messages can help you not only identify problems with the RSoP snap-in, but also identify network or Active Directory problems that are causing policy application problems.
To view the error information, right-click the Computer Configuration or User Configuration branch after the query is complete and choose Properties. Click the Error Information tab, which lists each group policy component that RSoP used to generate the policy report. The list indicates the success or failure for each component. Click on a component to view specific error information for that component.
Delegating RSoP
As I hinted at earlier in this article, you can delegate permission to generate RSoP queries to help distribute administrative workload. A user who has been delegated the necessary permission can perform queries in either Logging Mode or Planning Mode (as you designate) without having to log on as or be a member of the Domain Admins or Enterprise Admins groups.
To delegate RSoP, open the Active Directory Users And Computers console. Right-click the OU and choose Delegate Control to start the Delegation Of Control Wizard. Click Next, add the user or group to which you want to delegate, and click Next. In the Tasks To Delegate page (Figure K), place a check beside Generate Resultant Set of Policy (Logging) and / or Generate Resultant Set of Policy (Planning) and then click Next. Click Finish to apply the delegation.
Figure K |
![]() |
Using the Delegation Of Control Wizard, you can allow other users to run the RSoP MMC. |