In-Depth

Policy Management Made Easy

Figuring out what group policies apply to an object on your Windows 2000 network can be a painstaking process; but Windows .NET’s Resultant Set of Policies feature promises simplification.

• By Chris Wolf
• 01/01/2003

WHEN MICROSOFT FIRST cooked up the idea of Group Policy Objects (GPOs) within the Windows 2000 Active Directory hierarchy, it was thought that network management of user and computer settings would be streamlined and much easier than the good ole Windows NT System Policies. While Group Policy Objects were definitely easier to set up and deploy, management was another issue.

The problem with managing group policies occurs mainly in enterprise-level environments. If you set up site-, domain- and organizational unit (OU)-level policies, you’d have to calculate the end result of the policy deployment manually. The most accurate way of determining the resultant policy settings for a particular user would be to:

1. Print a screenshot of the local computer policy settings for a particular machine.
2. Print a screenshot of the site Group Policy settings for the computer.
3. Print a screenhot of the domain Group Policy settings for the user and computer.
4. Print a screenhot of the OU Group Policy settings for the user and computer.
5. Compare the screenshots from each policy to arrive at a final determination of the resultant policy.

This is no easy task. To determine a resultant policy with Win2K, you need to remember L-S-D-OU (Local, Site, Domain, OU), which is the order in which policies are applied, and then compare screen captures of each set of policies to determine the end result of the policy deployment. Unfortunately, this approach doesn’t even account for the possibility of the Block Policy Inheritance or No Override Group Policy property settings. When dealing with site, OU and child OU policies, policy management basically boiled down to making an educated guess on the end result. Win2K had no built-in tool to tell you the effect that your policy configuration would have on an individual user or computer.

As Jeremy Moskowitz pointed out in his October 2001 article, “Troubleshoot Group Policy,” Microsoft realized the need for a good GPO troubleshooting tool and worked with FullArmor to produce FAZAM 2000 RFV (Reduced Functionality Version). This tool, included with the Win2K Server Resource Kit, can be downloaded for free at www.microsoft.com/windows2000/
techinfo/reskit/tools/existing/fazam2000-o.asp.

FAZAM RFV does several things: It gives you a way to analyze effective group policy settings for any user or computer object in your forest and lets you analyze applied GPO settings.

That’s all good, but now with Windows .NET Server 2003, Microsoft has extended that functionality manyfold with its Resultant Set of Policies (RSoP) feature. RSoP does everything the Win2K version did but goes much further in its ability to help administrartors detangle group policy.

With .NET RSoP (I tested the RC1 version), you can simulate GPO settings such as loopback, site location, and slow link detection, all of which is discussed later. FAZAM 2000 RFV is handy for instant analysis and troubleshooting, but the .NET implementation can also perform the instant analysis while at the same time offering simulation possibilities that alleviate many of the headaches in GPO planning. When deploying policies, you’ll never have to begin a sentence with, “It should…” Now, you can confidently say, “It will…”

If you’ve already worked with FAZAM, you’ll find the functionality of .NET RSoP familiar. With RSoP, you can:

• Determine the resultant Group Policy settings for AD objects such as users, computers and OUs.
• Simulate a Group Policy implementation.
• View the precedence of policies applied and the winning policy for a particular setting, such as password age.

Great. So How Do I Use It?
RSoP can run in two modes: logging mode and planning mode. Use logging mode when you need to determine the actual resultant GPO settings for a user or computer object. Planning mode is more flexible, letting you simulate “what if” scenarios based on AD data. For example, with logging mode, you can view the resultant policy settings for a single user or computer object in the forest. With planning mode, you can create an OU and child OUs, set up default policies for each OU, then use RSoP to determine the resultant policy for one of the child OUs. Put another way, logging mode gives you policy settings that you have, while planning mode allows you to see the policy settings that you would have based on the conditions you specify.

Because RSoP is built into .NET, you can find hooks to run it nearly anywhere. For example, you can right-click an OU in the AD Users and Computers Microsoft Management Console, select All Tasks, and then execute RSoP (Planning), or right-click a user object, select All Tasks, and then choose RSoP (Planning) or RSoP (Logging). You’ll also see shortcuts to launch RSoP in AD Sites and Services and in AD Domains and Trusts. It’s everywhere!

The easiest way to analyze policy settings by using RSoP in logging mode is to launch RSoP.msc from the Run dialog box. For Planning mode, I like creating an empty MMC and adding the RSoP snap-in. This is done by launching the MMC from the Run dialog box by typing “MMC” and pressing Enter. From the MMC, snap-ins can be added by pressing Ctrl-M, clicking Add, and then selecting the appropriate snap-ins.

FAZAM 2000: Much More Than Policy Analysis If you’re in the market for a serious GPO management tool, FAZAM 2000 is the clear choice and well worth the $9 per user price. In addition to determining the RSoP for a particular AD object, FAZAM also offers the following features: Back up and restore GPOs without having to back up the entire System State. Quickly migrate GPOs from one domain or forest to another. Create detailed reports on GPO settings and distribution throughout the AD forest. Remotely manage and view GPO events for all computers in the forest. Including an RSoP tool with .NET Server was an important and necessary step by Microsoft. The free RSoP tool is sure to bring a smile to your face when analyzing the effect of your Group Policy deployment strategy, but if you’re looking for long-term policy management, FAZAM is clearly the tool of choice. .NET RSoP does help you in planning policy implementation and troubleshooting user and computer policy settings, but doesn’t offer the enterprise-scale tools included with FAZAM. Group pPolicy is at the heart of any AD infrastructure. Buying .NET Server without buying FAZAM is like buying a car without air conditioning. Sure, you can roll down the windows and drive real fast, but are you really cool? Let’s face it: Unless you live in Alaska, it’s not much fun driving in the summer without air conditioning. Likewise, Group Policy management without FAZAM is not the same, no matter where you live. FAZAM 2000; $9/user plus 18% annual support; FullArmor Corp., 617-457-8100 www.fullarmor.com/solutions/group —Chris Wolf

RSoP in Action
Because planning mode is the most powerful and offers more configuration options, that’s where we’ll focus. With the RSoP snap-in loaded into the console, begin by right-clicking the snap-in and selecting Generate RSoP Data. This action launches the Resultant Set of Policy Wizard that lets you specify exactly what you’d like to analyze.

In Figure 1, I chose to analyze user and computer objects in the New York OU, which is a child of the Sales OU in the Msft.com domain. After selecting the objects to analyze, you’ll select advanced options. This is where the simulation comes into play. As shown in Figure 2, the wizard lets you simulate slow bandwidth conditions, loopback processing mode and site location.

Figure 1. The RSoP Wizard lets you select AD objects to analyze.

 

Figure 2. RSoP planning mode allows you simulate factors such as slow networks.

Sometimes you may not want to push all Group Policy settings over a network connection, especially if a user’s connecting via a dial-up modem. For example, you wouldn’t want to use a policy to force the installation of Office XP to all users over the network, including dial-up users. With slow link detection enabled (User or Computer Configuration | Administrative Templates | System | Group Policy | Group Policy Slow Link Detection), only the Administrative template (Registry settings) and Security settings portions of the GPO are applied. The remaining policy settings aren’t applied—that includes software distribution and folder redirection. The default value of “slow” is listed as 500Kbps but can be changed when you enable slow link detection.

Loopback Processing
Now to loopback processing, which is configured in the computer portion of any GPO under “Computer Configuration | Administrative Templates | System | Group Policy | User Group Policy Loopback Processing Mode.” Suppose you have a user in one OU logging onto a computer in another OU. Whose GPOs get applied to the system? To begin, remember that each GPO has a computer and user portion. Computer policies are applied once the computer boots up, and user policies at logon. With the default policy settings, you’ll get the site policy from where you log on and the user portion of your GPOs that apply to where your user object is located in AD. By default, the user gets the user settings in his or her GPO and not the computer object’s GPO. This can be changed by enabling loopback settings in the computer portion of the computer’s GPO. With loopback, you can configure loopback merge or loopback replace. Briefly, when loopback replace is used, the user settings in the computer’s GPO will override the user settings in the user’s GPO. With loopback merge, the user settings in both the user’s GPO and computer’s GPO are merged, with like settings in the computer’s GPO overriding those in the user’s GPO. Still confused? Consider the example shown in Figure 3.

Figure 3. To understand RSoP, let’s work with a sample single domain containing two sites and six OUs.

The illustration shows a domain dispersed over two sites, with OUs located in each site. Suppose your user object is in OU1B and you logged onto a computer in OU2A. At logon, the user portion of the following policies would be applied:

1. Local computer policy
2. NY site
3. MCPMag.com domain
4. OU1
5. OU1B

Site policies are always physical, whereas domain and OU policies are logical. That’s why you’ll get the NY site policy instead of the CA policy.

Now, let’s assume that loopback merge is configured in the same scenario. That means that at logon, the user portion of the following GPOs would be applied in the order listed:

1. Local computer policy
2. NY site
3. MCPMag.com domain
4. OU1
5. OU1B
6. OU2

Because the OU2 policy is applied last, its settings would have the potential to override earlier configurations in OU1 and OU1B policies.

Finally, let’s consider if loopback replace were configured instead. Now at logon, the user would have these policies applied:

1. Local computer policy
2. NY site
3. MCPMag.com domain
4. OU2

With loopback replace, only the user GPOs in the computer’s logical AD hierarchy are applied. This configuration is ideal in areas such as a public computer lab or kiosks where you want all users to have identical configurations.

Even with a thorough understanding of GPO loopback, manually predicting a resultant policy is no easy task. Before RSoP, you had to implement loopback in order to test it. There was no way to do a simulated loopback policy implementation unless it was performed in a lab. Now you can run the test on your production policies prior to seeing the result of using loopback merge or loopback replace.

Finally, you can also simulate resultant policy settings by site, allowing you to examine the effect of policies on a site-by-site basis. For example, you can check the policy settings if a user named Melissa was logged on in Los Angeles or in New York. This can be a valuable troubleshooting tool if, say, Melissa is experiencing problems in Los Angeles but not in New York. RSoP might make you the Sherlock Holmes of GPOs.

Back to Running RSoP
Once you’ve set the Advanced options for the policy analysis, the last steps in configuring the RSoP analysis are to select the user and computer objects the simulation should apply to and select which WMI filters—which allow you to filter the effective settings of a Group Policy Object—to apply to user and computer objects. You can simulate the inclusion of all WMI filters or only the ones you select for the analysis.

After successfully navigating the wizard, you can finally enjoy the fruits of your labor—the resultant policy. In my test, I configured identical policy settings in two policies, with the parent policy having the No Override option selected. The result of my analysis is shown in Figure 4.

Figure 4. RSoP analysis of display settings for the New York OU, the result of the sample analysis.

A nice feature of .NET RSoP is that for each applied setting, the analysis will display the policy that caused the setting. What it doesn’t show, however, is if resultant policy settings are due to one policy overriding another. To view all the policies involved in a particular resultant setting, you’ll need to double-click a single setting, such as “Prevent changing wallpaper properties,” and then click the Precedence tab.

Figure 5 shows the “Prevent changing wallpaper properties” resultant policy setting and the two policies that had the setting defined. As you can see, the Default Domain Policy is listed at the top and thus is the applied setting.

Figure 5. The GPO Precedence tab shows you which policy wins out.

Fine-Tuning
After reviewing the resultant policy based on the conditions you specify in the wizard, you can then run the analysis for different objects or rerun the analysis on the same objects after changing policy configuration in AD (if needed). To launch a new query and rerun the analysis for the same query, simply right-click the RSoP object in the MMC and select Change Query or Refresh Query. With RSoP, you can continue to analyze the policies for the same AD objects until the GPOs behave just as you’d originally planned.