In-Depth

Troubleshoot Group Policy

These tricks and tools will help you seek out and destroy problem policies.

• By Jeremy Moskowitz
• October 01, 2001

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.