In-Depth
Troubleshoot Group Policy
These tricks and tools will help you seek out and destroy problem policies.
Windows 2000's Group Policy is usually a pleasure. From on high, you
can dictate settings to tens, hundreds, even thousands of users and computers.
Want to specify Disk Quota settings to 100 servers? ZAP! Specify an Internet
Explorer proxy setting for 1,000 workstations? ZAAAP! Deploy software
to a gaggle of sales droids? ZZZZZAAAAAAAP! When Group Policy works, it
works great. When Group Policy doesn't workÑwell, that's what we're here
to discuss.
You'll know Group Policy isn't working because users will call you up.
Either they have "extra" settings they're not used to or, equally
common, they'll complain something they're familiar with is now suddenly
"gone." So, in general, when Group Policy isn't working it's
usually because it's either not applying or it's applying too much.
Check the Basics
Sometimes, it's the small, day-to-day things that will stop a Group Policy
from applying. Indeed, Group Policy is almost always working correctly!
And an understanding of the expected Group Policy behavior is a requirement
for our systems to run smoothly. You can often isolate problems by making
sure Group Policy isn't simply misconfigured.
- Is the policy disabled? This is a no-brainer. If the Group Policy
object is disabled, you'll simply not get your intended results. Note
that policies can be "half" disabled by disabling either the
User or Computer components of the Group Policy object.
- Are you sure about the inheritance? Remember that Group Policy flows
downward from Site, Domain, then to each nested Organizational Unit
(OU). Also remember that there's a local policy on the Win2K machine
that is always applied first. The last applied "conflicting"
Group Policy always "wins."
- Examine your "Block Inheritance" usage. When you Block
Inheritance at any level, you're squelching all policies set at a higher
level. You'll need to link manually to, or add in, all the policies
you want to affect your users.
- Examine your "No Override" usage. "No Override"
is the big boss. Once this is set on a Group Policy object, levels below
it "can't say no."
- Are your permissions set correctly? In order for Group Policy to
apply, users must have Read and Apply Group Policy rights. Without them,
Group Policy doesn't apply.
- Did something recently move? If you've just moved a computer or user
from one OU to another, it's quite possible that the last settings that
affected them are still in force. Either have the user in question log
off and back on or reboot the machine to download the latest settings.
Beyond the Basics
Built right into the core Win2K operating system are several freebies,
which you can use to help troubleshoot anomalies.
Quite possibly, the most overlooked and underutilized tool in Win2K is
the Event Viewer. The client's Event Viewer logs the successful applications
of Group Policy as well as the failures.
So, before beating your head too hard against the wall, look at the target
client's Application event log for relevant Group Policy records. In the
case of Figure 1, the client was pointing to an incorrect DNS server,
as detailed in Knowledge Base article Q261007, "Event ID 1000 Is
Logged in the Application Event Log."
It's one thing for the all the server pieces to be working perfectly,
but to have the result on the client be cockeyed. You can examine Group
Policy application on a client on a step-by-step level by turning on "verbose
logging."
 |
| Figure 1. The Event Viewer service is a terrific
place to start your Group Policy troubleshooting journey. (Click image
to view larger version.) |
When you enable verbose logging by editing the registry at the client,
you're telling the system to generate a file called userenv.log in the
\winnt\debug\ usermode directory. You can then examine the file to see
what the client system thinks is really happening.
You can enable verbose logging by logging onto the client system as the
Local Administrator. Then, using the registry editor, traverse to Hkey_Local_Machine
| Software | Microsoft | Windows NT | CurrentVersion | Winlogon. Add a
REG_DWORD value called "UserEnvDebugLevel" and give it a hex
value of 30002. You'll get an expanded Userenv.log file found in the \winnt\debug
usermode directory. It offers a detailed "client's-eye view"
of how things are applying.
On a "problem" machine, you might find text in the file such
as:
ProcessGPO: Searching
<>
{304A69F7-1386-4002-9705-3FB233EC0FF7},
CN=Policies,CN=System,DC=corp,DC=local>
ProcessGPO: User does not have
access to
the GPO and so will not be
applied.
In this snippet, the user was denied Read access to the Group Policy
object and, hence, couldn't apply it.
Free Tools at Your Service
The freebies within the operating system are a good place to start tracing
Group Policy application woes. However, to bump it up a notch, give these
free tools a try.
Gpresult
Gpresult is like a brother-in-lawÑsomewhat dependable
in a pinch, but not particularly useful unless
you prod a bit. You'll find it inside the Windows
2000 Server Resource Kit and online at www.microsoft.com/windows2000/techinfo/
reskit/tools/existing/gpresult-o.asp. Gpresult's
main goal is to tell you what results a particular
policy has on a given machine and user and what
the settings are. Gpresult must be run on the
client experiencing the problem.
Gpresult has three modesÑnormal, verbose and super-verboseÑand can expose
either the user settings; the computer settings; or, by default, both.
The tool is small enough to copy onto a floppy to shuttle over to the
client in question or it can be run over the network.
Listing 1 shows a snippet while trying to debug a user policy.
|
Listing 1. Sample
output from Gpresult, a utility that tells
you what results a policy has on a given
machine and user.
|
 |
You can glean all sorts of juicy tidbits from
Gpresult.
First, check to see which Group Policy objects are applied to both the
User and the Computer. If you're getting an unexpected setting at a client,
simply use the provided information along with the Group Policy Editor
tool to start tracking down the errant policy.
Next, if something isn't applying at all, check for the last time the
Group Policy was applied. In addition, Gpresult spells out the security
group membership. Perhaps your user is inside a group denied access to
Read or Apply the Group Policy you were expecting.
If you want to take Gpresult to the next level, use it with the /v switch
to see which registry settings are specifically being altered by the Group
Policy. If you're getting unexpected results, try hacking the registry
on a test machine to see if the test machine matches the "broken"
machine. Maybe the policy really is working as it should.
If you really want a screen-full, try running Gpresult with the /s switch,
which adds the binary data found in certificates and recovery agents.
REPLMON
REPLMON, available as part of the Support Tools on the Win2K Server CD,
may be one of the most useful free tools Microsoft ever created. For the
purposes of troubleshooting Group Policy, use it to make sure your Group
Policy objects are "complete." Group Policy object are made
up of two components: a Group Policy Container (GPC) and a Group Policy
Template (GPT). The former is an entry in the Active Directory database,
and the latter is a collection of files in the SYSVOL share on your domain
controllers. Each replicates separately and, sometimes, they don't always
replicate around to all domain controllers correctly.
First, load the support tools in the \SUPPORT\TOOLS directory of the
Win2K Server CD-ROM. Then start up REPLMON by clicking Start | Programs
| Windows 2000 Support Tools | Tools | Active Directory Replication Monitor.
Right-click over the "Monitored Servers" icon and click "Add
Monitored Server." Add one or all of your domain controllers.
Once the server is being monitored, right-click over it and select "Show
Group Policy Object Status." Once you do, you'll get a screen like
Figure 2.
 |
| Figure 2. REPLMON can show you when your GPOs
aren't being replicated correctly on the server. (Click image to view
larger version.) |
In Figure 2, you can see the Group Policy object named "Broken 2"
(at the bottom) has an X in the Sync Status column. With a little digging
I discovered this was because the GPT was damaged on the SYSVOL.
Finding an X in the Sync Status column might not be a real problem. This
is because the GPC and GPT are independently replicated. Perhaps the domain
controller you're inspecting simply hasn't yet received the latest updates.
Try inspecting another domain controller to see if another replica server
has received both the GPC and GPT.
FAZAM RFV
The Resource Kit has been re-released with a Supplement
1, which adds new tools to the original Resource
Kit's stable. It's available in bookstores, usually
for around $50 to $70 and contains one CD. Perhaps
the most useful new tool on that CD is called
FAZAM 2000 RFV or Reduced Functionality Version.
The RVF is licensed from FullArmor Corp. as a
way to assist in the troubleshooting of Group
Policy objects. It has its strong and weak points
(as we'll see shortly). But heck, it's freeÑand
you can't beat free. If you want to just get the
tool, you can download it from Microsoft's Web
site at www.microsoft.com/windows2000/techinfo/reskit/tools/existing/
fazam2000-o.asp.
FAZAM RFV has a function that lets you analyze the Resultant Set of Policies
or RSOP a client should experience. Simply select a User and Computer
to simulate what would happen if the two worked together. For instance,
in Figure 3, you could analyze what would happen if Frank Rizzo logged
on to W2kPro1. Or, you can select the "What If" button and see
what would happen if a certain user or computer was to move into an OU
of your choice. This feature can greatly assist in determining what'll
happen when users move before actually trying it out!
 |
| Figure 3. The FAZAM RSOP
tool lets you pick a user and computer to
simulate the result of a change. (Click image
to view larger version.) |
The FAZAM RFV presents a "Resultant Policy" tree. Unfortunately,
this is where the RVF version loses its usefulness. It thrusts you into
the Group Policy editor tool and forces you to surf around for a while
and collect all the settings. This can be particularly tedious and time-consuming.
Thankfully, the paid version of FAZAM 2000 does
a much better job with this feature. [For a
review of the full version, read the review by
Jeremy in the May 2001 issue.—Ed.]
Firepower
Troubleshooting Group Policy isn't easy. There
are a lot of little cogs that make up the giant
machine that is Win2K Group Policy. With a bit
of practice, you'll mesh with the tools and really
discover the source of your problems. Remember,
Group Policy usually works as it should, but if
it doesn't, it helps to have some troubleshooting
firepower on your side.
Portions of this article have been reprinted
from Windows 2000: Group Policy, Profiles,
and IntelliMirror by Jeremy Moskowitz, with
permission from Sybex.