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
- January 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:
- Print a screenshot of the local computer policy settings for a particular
- Print a screenshot of the site Group Policy settings for the computer.
- Print a screenhot of the domain Group Policy settings for the user
- Print a screenhot of the OU Group Policy settings for the user and
- 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/
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,
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
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.
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
- Back up and restore GPOs without having to back
up the entire System State.
- Quickly migrate GPOs from one domain or forest
- 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.,
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.
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:
- Local computer policy
- NY site
- MCPMag.com domain
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:
- Local computer policy
- NY site
- MCPMag.com domain
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:
- Local computer policy
- NY site
- MCPMag.com domain
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
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
|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
|Figure 5. The GPO Precedence tab shows you which
policy wins out.
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