Once you’ve planned and deployed Group Policy and optimized its performance, things should work as expected if you’ve done your homework properly. But what if Group Policy doesn’t work as you expect it to? What if certain users or computers don’t receive the policy settings intended for them? Then you need to haul out your arsenal of Group Policy troubleshooting tools and try to find out what’s gone wrong. That’s what this article is about.
Start With The Basics
Before you start running various Group Policy troubleshooting tools and techniques however, take a moment to step back and ask some simple questions. This phase of the troubleshooting process is based on the motto that a minute of thinking is worth an hour of brute force effort. Below are some simple questions you should ask yourself before you dive into the troubleshooting process.
- Should the policy be applied to the affected users and computers? That’s a great question to begin with, isn’t it. Say a user comes to you and says he can’t install a certain application by invoking a shortcut on the Start menu. His neighboring workers can do this, but his machine must be broken because he doesn’t have the shortcut for that program. So he complains and you scratch your head wondering why the software installation policy that installs this program isn’t being applied to that user. But should it apply in the first place? What does the user mean by his “neighboring workers”? Maybe other employees on the same floor but belonging to a different department, and while users in that department need that particular program, the complaining user doesn’t and perhaps shouldn’t have access to the program. So actually Group Policy is working just fine in this situation—it’s the user that’s broken! Users are particularly envious of other users’ privileges, and this sort of thin happens a lot in some companies. The key troubleshooting question here is “Who should this policy apply to?
- What is common to the users or computers to whom the policy is not being applied? This question is applicable if several people or machines aren’t getting the policy they’re supposed to receive. Five people in the Marketing Department come to you and complain that they can’t access Control Panel anymore from the Start menu. What does this tell you? Check the GPO linked to the OU for Marketing users and see whether the policy “Prohibit access to the Control Panel” is Enabled (this policy is found under User Configuration\Administrative Templates\Control Panel). If this policy is Disabled or Not Configured, check GPOs linked to parent OUs to Marketing or linked to the domain and see whether security filtering is mistakenly configured so that users in the Marketing security group have this policy applied.
- When did users start complaining about the issue? Was it immediately after you made some change to your Group Policy settings, for example by creating and linking a new GPO to an OU? That should tell you something right away. Or did it happen when you made some administrative change to Active Directory, for example moving some computer accounts out of the default Computers container into an OU created specially for such accounts. In this case, the computer accounts were previously receiving their policy from domain-linked GPOs, but now any GPOs linked to the new OU will affect them as well. Or did the complaints start coming with no warning out of the blue and you’ve made no changes to any GPOs for several months? In that case something else is interfering with Group Policy processing for the affected users or computers, and you’ll need to use some of the tools described below to try and find the cause. Or maybe users haven’t been complaining to you at all.
- When did you actually configure the policy in question? In this situation what happened is that you configured a policy and then checked with the targeted users to see if the policy has been applied and it hasn’t. Well, don’t forget that Group Policy refreshes in the background only periodically, so maybe everything is fine and you just have to wait a while for Group Policy to refresh itself automatically. Or maybe the policy you configured is one that can’t be applied during background refresh and requires the user to log off and on again or to restart their machine. Examples of such policies include those for software installation, folder redirection, and scripts. In that case to ensure the new policy is processed you’ll have to wait until users log off at the end of the day, send them an email asking them to log off and then on again, or forcible reboot their machines remotely and face their wrath if they lose any of their work. Or maybe you configured a folder redirection policy and users rebooted their machines and the policy is still not applied. In that case asking the earlier question “What do they have in common” might reveal that the affected users all work at a remote site and receive their policy over a WAN connection from domain controllers at company headquarters. In that case, slow link processing for Group Policy may have come into effect, which can again prevent certain kinds of policy from being processed due to the bandwidth constraints of WAN links.
Bring On The Tools
Once you’ve asked these preliminary questions, which are essential to ask as they can often pinpoint the problem exactly but usually at least help to narrow the scope of what you need to investigate, it’s time to start testing things using tools ranging from ping to userenv logging. It’s difficult to cover such a broad topic in a short article, so I’ll just give you some tips to point you in the right direction:
- Check the network connection for the affected machine. Maybe it’s not just Group Policy processing that’s not working; maybe the affected user can’t even connect to the network because the network cable for her computer is unplugged! It’s amazing how something as simple like this can be the source of what seems at first to be a complex problem. For Group Policy is quite complicated in how it operates, and an understanding of how it works can help you pinpoint problems more easily. For a good explanation of how Group Policy works, see the new Group Policy Guide from Microsoft Press, which is part of the recently released Microsoft Windows Server 2003 Resource Kit. I worked as tech editor on this title, and its an excellent resource on all things Group Policy that Windows administrators should be sure to have on their bookshelf.
- Check if the affected machines can correctly perform DNS resolution. Probably half of all Group Policy processing issues are related to DNS problems such as corrupt resource records on DNS servers, misconfigured DHCP options on DHCP servers, users changing DNS settings on their machines, and so on. Remember that to process Group Policy a computer must first obtain a list of GPOs that apply to it. To do this, they need to query a domain controller. And to locate a domain controller, they need correct client DNS settings so they can obtain SRV records by querying the DNS server. So if DNS is broken then Group Policy is also. Tools for verifying and testing DNS include ipconfig, nslookup, netdiag, and Network Diagnostics in Help and Support.
- If you’re using the Group Policy Management Console (GPMC) to work with Group Policy, run the Group Policy Results wizard, specifying an affected user and computer on the wizard pages. This will query WMI on the affected machine and create an HTML report that displays which GPOs have been processed and which policy settings have been applied. You can save these reports and view them on any machine using Internet Explorer, and it’s a great way to troubleshoot Group Policy issues. An alternative to using the wizard is to run the command-line tool Gpresults.exe on the affected machine, see the article by Brien Posey on this topic right here on WindowsNetworking.com. In addition to generating RSoP reports, the GPMC can also help you troubleshoot Group Policy problems in other ways. For example, if you right-click on a GPO you can select Save Report to generate an HTML report showing all the configured settings in the GPO. This makes it simple to find out what effect a particular GPO actually has on the accounts in the container it’s linked to—a heck of a lot easier than opening the GPO in the Group Policy Object Editor and expanding all the nodes to see what policies are configured. Another benefit of the GPMC over the out of the box Group Policy tools included with Windows Server 2003 is that you can easily see what GPOs are linked where and which GPOs are disabled, which containers have inheritance blocking configured on them, which GPO links are enforced, and so on. Get the GPMC today from Microsoft’s website and use it for managing Group Policy on your network.
Conclusion
There’s lots more to troubleshooting Group Policy, but the above tips should get you started and should help you solve a good chunk of issues that may arise. More advanced users may want to enable verbose logging for Userenv.dll (the Group Policy engine) which is explained in article 221833 in the Microsoft Knowledge Base (the article explains how to enable verbose logging but doesn’t explain how to interpret such logs—see the Group Policy Guide from Microsoft Press for this). You can also use Event Viewer to check for Userenv events in the Application log, but we all know how cryptic Windows event log events can be (a good source of event log event information can be found at EventID.Net, a community-based project to compile detailed help information on cryptic events). And finally you can search or browse the Knowledge Base on TechNet and find obscure articles like this one that tell you Group Policy processing fails when the DFS client is disabled or when Read and Execute permission for the Everyone group is removed from the root of the system partition—just one of those obscure tidbits of information you may want to file away in your already overcrowded brain for some rainy day.
