Both the Active Directory and Windows in general offer a huge degree of flexibility. Group policies can be created that apply to anything from a single workstation to an entire organizational unit. Although it’s really nice to have a security model that can be custom tailored to meet your exact security needs, there is a definite downside to the way that Windows security works; it can be really complicated. A single group policy can apply to users or to computers, and can potentially contain contradictory settings. Furthermore, multiple group policies can be combined in a hierarchical fashion with higher level settings potentially canceling out some of the settings that were assigned by lower level policies. Throw in filters such as No Override and Block Policy Inheritance, and you can start to see how quickly things can become confusing. Fortunately, there is a way to tell exactly what the outcome of all of those policy elements is. You can run a Resultant Set of Policy (RSOP) query. In this article, I will show you how.
The Resultant Set of Policy Wizard
There are two primary situations in which you might want to run a RSOP query. One of those situations is the one that I discussed earlier, in which you need to determine what policy elements actually apply to a particular user. When you use the RSOP Wizard to determine which policy elements apply to a user, you will run the wizard in logging mode.
The other primary situation that the RSOP wizard comes in handy for is for testing a new policy prior to deploying it. For example, suppose that you were thinking about changing the minimum password length for users and you planned on making the change at the domain level. You could use the RSOP Wizard to figure out if the change that you want to make would have the desired effect, or if it would be canceled out by another, higher priority policy.
Of course changing the minimum password length doesn’t usually have catastrophic consequences, but there are plenty of group policy settings that could really cause problems if they were applied incorrectly. That’s the beauty of the RSOP wizard. When you run the RSOP Wizard in planning mode, you can test the effect of a policy without actually having to apply the policy. Even if you aren’t planning on making any big policy changes, you could use planning mode to determine the effects of moving a user to another location, or other similar scenarios.
Launching the Resultant Set of Policy Wizard
The RSOP Wizard could be considered to be a bit illusive since it’s not a part of the normal Group Policy Console. To launch the RSOP Wizard, enter the MMC command at the Run prompt. This will cause Windows to load an empty Microsoft Management Console. Next, select the Add / Remove Snap-in command from the console’s File menu. This will cause Windows to display the Add / Remove Snap-In properties sheet. Now, click the Add button found on the properties sheet’s Standalone tab and you will see a list of all of the available snap-ins. Select the Resultant Set of Policy option from the list and click the Add button, followed by the Close and OK buttons.
The Resultant Set of Policy snap-in should now be loaded in the console. To launch the wizard, right click on the Resultant Set of Policy container and select the Generate RSOP Data command from the resulting shortcut menu.
Logging Mode
Now that you know how to launch the wizard, let’s take a look at how you would use the wizard in logging mode. When the wizard starts, click Next to bypass the wizard’s Welcome screen. You will now be given a choice of running the wizard in logging mode or planning mode. Select the Logging Mode option and click Next. You will now see the screen shown in Figure A.
Figure A: You must choose the computer that the user will be using
As I mentioned earlier, group policies are applied at the user level and at the computer level. Therefore, if you want to find out which policy elements apply to a user, you need to know which computer the user is using. Of course in real life, you would probably be testing the effect of a policy on a group of users, and you would choose one of the user’s computers at random, assuming that the same computer level policy applied to all computers. If you would rather ignore computer level policies, this screen contains a check box that you can use to force the RSOP wizard to examine only user level policies.
Click Next, and you will see the screen shown in Figure B. This screen works very similarly to the screen shown in Figure A, except that you are specifying a user rather than a computer. You can test the user that is currently logged in, a user of your choice, or you can choose to examine only computer level policies.
Figure B: Select the user account that you want to examine
Click Next and you will see a screen asking you to confirm your selections. Click Next one more time, and the wizard will begin the analysis. Click Finish when the analysis completes, and you will see the results, as shown in Figure C. As you can see in the figure, the results are displayed within a group policy console. You can browse the console and look at the results of any policy setting that you choose.
Figure C: The results of the analysis are presented within a group policy console
Planning Mode
To run the RSOP Wizard in planning mode, launch the wizard in exactly the same way as you did before. When the wizard starts, click Next to bypass the wizard’s Welcome screen and then select the Planning Mode option and click Next again. When you do, you will see a screen similar to the one that’s shown in Figure D.
Figure D: Specify the computer and user information for the test
As you can see in the figure, you must specify a computer and a user for the tests to be run against. As an alternative to specifying a specific computer or a specific user, you can specify an Active Directory container instead. This screen also contains a check box that you can use to skip to the last page of the wizard without collecting additional data, but for the purposes of this article, I won’t use that option.
Click Next, and you will see the screen that’s shown in Figure E. This screen allows you to tell the wizard if you have a slow network link or if the test will occur across a site. You can also specify that loopback processing should be used if you so desire.
Figure E: Tell the wizard if slow network connections are in use or if you will be crossing a site
The next screen that you will see lists the location of the user and the computer container. The reason why the wizard shows you this screen is because you can make modifications that allow you to simulate the effect of moving the user to a different container or of using a different computer location. Make any necessary changes and click Next.
The following screen asks which security groups the user is a member of. Keep in mind that you shouldn’t specify which groups the user belongs to now, but rather which groups the user will belong to after you do whatever it is that you plan on doing. Click Next, and you will see an almost identical screen that asks which groups the computer is a member of. Unless you are making a drastic change to the computer’s domain membership, you should go with the defaults on the screen.
Click Next and you will see a screen asking which WMI filters should be applied. In most cases, there probably won’t be any WMI filters, so you usually don’t have to worry too much about this screen. Click Next and you will see a similar screen asking about WMI filters that should be applied to the computer. Again, you probably won’t have to worry about this screen, so just click Next.
At this point you will see a summary screen of all of the information that you have entered. Click Next and the wizard will process your proposed changes. When the changes have been processed, click Finish and you will see the outcome of the proposed policy changes displayed in a group policy console similar to the one shown in Figure C.
Conclusion
As you can see, the Resultant Set of Policy wizard can be a valuable tool whether you need to diagnose a policy that isn’t behaving as expected, or you need to plan for a policy change.
