In the previous 3 postings, I've described a workflow that can take you from Group Policy problem to Group Policy resolution. But sometimes the 'standard' methods for solving Group Policy problems don't work. In this installment, I want to spend some time talking about the "out-of-the-box" thinking that is sometimes required to track down GP problems. The first place to start is to talk about some of the common problems I've seen with respect to GP.

Differentiating a Real Problem from a Real Mistake
Truth-be-told, at least half of the problems I see folks having with GP relate to a misconfiguration of a GPO, rather than a real problem with policy processing. So the first thing you need to do is perform a sanity check on whether you have linked your GPOs correctly, whether you don't have security filtering gumming up the works or whether you've done something like set Block Inheritance on an OU or Enforced on a GP link. The GPMC GP Results report can help show the way here by telling which GPOs are being applied and denied, and why. Make sure you pay close attention to that section of the report to ensure that you are really targeting a computer or user correctly. If you don't see the GPO you expect to see in that report, chances are, it is not linked or filtered correctly.

Another common thing I've seen is that an administrator has inadvertently turned on loopback processing on a set of computers, which can affect how user policy processing occurs. Look for this setting in the GP results report or use SDM Software' GP Health PowerShell cmdlet (www.sdmsoftware.com/group_policy_health) to quickly discover this kind of information across your remote systems.

Finally, if you are seeing those dreaded 1058 and 1030 errors in the application event log on your GP clients, start with the most obvious causes first. These errors indicate that the client is unable to read the gpt.ini file that is housed in each GPO in SYSVOL. So, make sure that SYSVOL is actually being shared out on all your DCs and that GP is in-sync across all your DCs. You can use the gpotool.exe utility that Microsoft provides in Windows to test GP up-to-dateness across all your DCs. Next, if you are seeing these errors for computer GP processing but not for user GP processing, that could indicate a problem with the network stack initializing in time for computer processing to succeed. Check out KB article http://support.microsoft.com/default.aspx?scid=kb;en-us;842804 for a registry tweak that might help here.

Group Policy troubleshooting is definitely an art. It requires being aware of all the different processes that must work in concert to complete a successful processing cycle. Its why I created the Troubleshooting Pak--to help expose as much of those moving parts as possible to give you the best chance to track down a problem. Hopefully this series of articles has given you additional insight into the Group Policy "engine" and how you can approach solving problems that arise in your environment!

Written by Guest Blogger Darren Mar-Elia. Darren is CTO & Founder of SDM Software (www.sdmsoftware.com), a Group Policy Solutions company. SDM Software develops and sells product to improvement the manageability and reliability of Windows systems that leverage Group Policy. The GPExpert™ Troubleshooting Pak (www.sdmsoftware.com/group_policy_troubleshoot) is an example of one of these products--a set of four utilities that help speed time-tor-resolution of Group Policy problems.