In my opinion, the Resultant Set Of Policy Wizard is one of the handiest tools built into Windows Server 2003. As you probably know, Microsoft created this tool in an effort to help administrators cope with the complexities of managing group policies. The hierarchical nature of group policies often causes unexpected results when all effective policies are applied. The Resultant Ste of Policies Wizard has traditionally been used to help administrators examine the effective policy and determine which group policy elements are causing any undesirable results that are discovered.
As you can imagine, the Resultant Set Of Policy Wizard is an invaluable tool for administrators that need to troubleshoot unexpected policy outcomes. However, the Resultant Set Of Policy Wizard is also an extremely powerful tool that can be used to help you anticipate the effects of network growth or reorganizations.
How can it work in planning?
To help you to understand how the Resultant Set Of Policy Wizard can be used as a planning tool, let's pretend that you work for a company that has two offices that are connected via a WAN link. The Active Directory is set up in a way in which there is a separate organizational unit for each of the two buildings. Security is applied through group policies to both the users and to the computers in each facility.
Now imagine that one of the departments in your company has a big project to come up and has to hire a hundred temps. The logistics of this project mandate that the temps be in the same building as the rest of the employees in the department that the temps will be working for. The only problem is that the building is already full and there isn't room for a hundred temps. The president of the company decides to temporarily move the finance department to the company's other building until the project is over to make space for the temporary employees.
Since the move is temporary, the employees in the Finance department will continue to use their existing user accounts and those accounts will continue to be associated with the same security groups as they are now. The potential problem is that the employees from the finance department will be using computers that are a part of the other building's organizational unit. Your job is to ensure that the employees from the finance department are able to continue to do their jobs and that there are no strange permission-related problems after the move.
This is where the Resultant Set Of Policy Wizard comes into play. The Resultant Set Of Policy Wizard is the perfect tool for situations like the one that I just described. The Resultant Set Of Policy Wizard has two different modes; logging mode and planning mode. Logging mode is the mode used most often. Its job is to help administrators figure out why group policies are not producing the expected permissions. Planning mode on the other hand allows you to simulate all kinds of strange and bizarre situations so that you can find out ahead of time how your existing group policy settings will apply to those situations.
The example that I gave earlier about the company shipping their employees off to a different building to make way for a bunch of temps probably sounded a bit far fetched. Actually, I used to work for a company that did things like that all the time. That isn't really the point though. The point is that I wanted to give you a really unusual situation so that you could see just how flexible and adaptable the Resultant Set Of Policy Wizard really is.
The Resultant Set Of Policy Wizard is perfect for testing group policy precedence and outcomes in situations in which the user and the computer are in different security groups, the user and computer are in different OUs, or the user and / or the computer are moved to a new location. In these types of situations, it is sometimes difficult to manually calculate the effect of the planned operation. However, the Resultant Set Of Policy Wizard can accurately report the results to you within minutes.
Using the Resultant Set Of Policy Wizard
Now that I have talked about some of the situations in which it would be useful to run the Resultant Set Of Policy Wizard, I want to walk you through a sample Resultant Set Of Policy based planning session. There is no way that I can possibly go over every option and every possible outcome within the confines of an article, but my goal is to demonstrate the flexibility of this tool in a way that will give you enough knowledge to be able to use the Resultant Set Of Policy Wizard within your own organization.
To access the Resultant Set Of Policy Wizard, enter the MMC command at the Run prompt. When you do, Windows will load an empty Microsoft Management Console. Next, select the Add / Remove Snap-in command from the console's File menu. Doing so will cause Windows to display the Add / Remove Snap-in properties sheet. Click the Add button found on the properties sheet's Standalone tab and Windows will display a list of the available snap-ins. Select the Resultant Set Of Policy option from the list of available snap-ins and click the Add button, followed by the Close and OK buttons. The Resultant Set Of Policy snap-in is now loaded and ready to use.
In the console's left column, right click on the Resultant Set Of Policy object and select the Generate RSoP Data command from the resulting shortcut menu. When you do, Windows will launch the Resultant Set Of Policy Wizard.
Click Next to bypass the wizard's Welcome screen and you will be asked whether you would like to use logging mode or planning mode, as shown in Figure A. As I explained earlier, logging mode if intended for diagnosing existing problems, so you will want to choose the Planning Mode option. Click Next to continue.
|Planning mode uses existing Active Directory information to determine how your group policies will respond to changes to your network.|
At this point, you will see the screen that's shown in Figure B. This is probably the most important screen in the entire wizard (at least for planning mode any way). As you can see in the figure, this screen allows you to skip to the wizard's final page. This means that every other screen in the wizard is optional, but this one is required.
|Enter the name of the user or user container and computer or computer container that you want to simulate.|
Before I show you what to do with this screen, I just want to point out that even though this screen might look a bit intimidating at first, you can not mess anything up by entering something wrong. After all, planning mode is nothing but a simulation. You are not actually configuring anything. You are simply asking the wizard what would happen if your network were configured in the manner specified.
With that said, let's take a look at the screen that's shown in Figure B. This screen is basically asking you for the name of a user and a computer. The idea here is that group policies are applied on both the user and the computer level. Therefore, the starting point for the simulation is that you have to enter which user and computer accounts you want to test.
Of course sometimes user and computer names aren't really appropriate for what you need to do. Let's go back to my earlier example in which the president of the company was shipping all of the employees in the Finance department off to another office on the other side of town. When I presented this situation, I mentioned that it was your job to determine whether or not there would be any weird permissions problems once the move was complete.
One way that you could make this determination would be to plug the user name for one of the employees in the Finance Department into the Resultant Set Of Policy Wizard. You could then enter the name of one of the computers in the other office and then find out what kind of permissions would apply as a result of the move.
In a situation like this though, using individual user names and computer names probably isn't the best course of action for a couple of reasons. For starters, you are moving an entire department, not one individual user. If you perform the test on one user account out of the entire department, then there is always the chance that this particular user might be a member of some security group that nobody else in the department is a member of, thus skewing the results. If this were a real life situation, it would probably be better to specify the name of the container that contains all of the user accounts for the users in the Finance department, rather than using individual user accounts. Of course you could always follow up by testing a few individual users to make sure that your results were consistent.
Just as you probably don't want to perform the tests solely on an individual user account if you are moving an entire department, you probably also don't want to base the test results on a single computer either. Most of the time, permissions applied to computers tend to be a lot more consistent than permissions applied at the user level. Even so, if you are relocating an entire department it would be best to specify the name of the container that contains the computers in the remote office, rather than the name of one individual computer.
I've found that a lot of new administrators are really intimidated by having to specify names in a way that the Active Directory can understand. I'll admit that Active Directory naming conventions can be a little tricky at times, but in this case, the naming really isn't bad. If you are specifying the name of an individual user or computer, you can simply enter then name in domain\name format. For example, to enter the name User1 in a domain named test, you would enter TEST\USER1.
If on the other hand, you want to specify a container rather than an individual user, you just need to know the name of the container, and the name of the domain that the container exists in. For example, user accounts are placed into the Users container by default. If you wanted to specify that you wanted the Resultant Set Of Policy Wizard to look at the Users container in the test.com domain, then you would enter CN=Users,DC=test,DC=com. The syntax is pretty easy, but if you are still having trouble, you can always click the Browse button and then select the desired container from a graphical representation of the Active Directory.
After specifying the user or user container and computer or computer container that you want to test, you have a couple of options. You can calculate the results now, or you can specify some more requirements for the test. In my earlier example regarding moving the Finance department to another building, I would simply enter the name of the container containing the finance department employee's user accounts and enter the name of the container containing the computers at the alternate facility. I would then select the Skip to the Final Page check box to see the results.
When you select the option to skip to the wizard's last screen and click Next, you will be taken to a screen that's similar to the one shown in Figure C. As you can see in the figure, this screen provides a summary of the choices that you have selected. You will notice in the figure that the user and computer containers are filled in, but there are also a bunch of references to things that I haven't talked about. Had we not skipped ahead in the wizard, there would have been screens asking you questions related to these options. After I show you what the results screen looks like, I will backtrack and talk about what some of these options are.
|Verify that the selected options are correct.|
At this point, make sure that the information presented on the summary screen is accurate for your simulation. Click the Next button and Windows will compile the resultant Set Of Policy based on the information that you have entered. Depending on the complexity of your simulation, the compilation can take a while. When the process completes though, click the Finish button and you will see a screen similar to the one that's shown in Figure D.
|This is what the results screen looks like.|
As you can see, the results screen is basically just a read only version of the Group Policy Editor. This allows you to browse through the group policy and see what the final outcome was for the various group policy settings. If you need to know where a particular setting came from, you can right click on it and select the Properties command from the resulting shortcut menu to gather more information. The resulting properties sheet contains a Precedence tab that shows where the group policy setting came from.
Other factors that may be simulated
When I showed you the summary screen, I mentioned that there were some elements that might have contained values had you filled in some of the information on the screens that we skipped. I wanted to take a moment and briefly explain what some of these options are:
- Slow Network Connection - Some administrators configure the group policy in such a way that it applies a different set of rules if the network connection speed is below a specified rate. The Resultant Set Of Policy Wizard allows you to simulate a slow network connection in case you have such policies in place.
- Loopback Processing - If you want to simulate loopback processing, the Resultant Set Of Policy Wizard supports using both merge and replace. Using the merge mode simulates appending the group policy object list obtained by the computer at startup to the group policy objects obtained for the user. If you use replace mode then the group policy objects obtained for the user will be replaced by the group policy objects obtained by the computer at startup.
- Site Name - Group policies can be applied at the site level. Therefore, the Resultant Set Of Policy Wizard allows you to simulate the use of a specific site.
- User and Computer Security Groups - The Resultant Set Of Policy Wizard allows you to specify security groups both for the user and for the computer. That way, you can predict the Resultant Set Of Policy when you are using security groups to filter group policy objects.
- WMI Filters - The Resultant Set Of Policy Wizard allows you to simulate the use of WMI filters both for the user and for the computer.