Tools and Techniques
If RSoP doesn't reveal which policy setting might be causing the problem, your next step is to narrow down the other possible sources. If you're not sure whether the problem is related to an Administrative Template policy or a security policy, you can try several things. Bearing in mind that Administrative Template policies provide only obfuscation and not security, the first hint as to where a problem is coming from is in the error messages it throws. For example, messages such as Access Denied or Permission Denied are clear indications of security rather than desktop lockdown issues, whereas error messages such as the one in Figure 1 are most probably Administrative Template—related.
If you get messages that aren't even this clear, you can use some tools to narrow down the problem. My favorite tool for tracking down possible Administrative Template—related problems is Sysinternals' free regmon.exe (http://www.sysinternals.com). Regmon lets you filter registry activity by registry key. By using Regmon during the operation that's causing problems to trace registry activity to one of the four policy-related subkeys mentioned earlier, you can often identify the policy that's causing the problem. Figure 4 illustrates how Regmon helped me track down a policy restriction that prevents Microsoft PowerPoint from running. Although this example is somewhat oversimplified (I'd have been able to see this policy using the RSoP tools without having to resort to Regmon), it gives you an idea of how you can use the tool to track down an Administrative Template policy when RSoP doesn't fill the bill.
If you suspect the problem might be related to a security policy, you need to try to identify and undo that policy. As I mentioned earlier, security policies essentially tattoo your systems if you remove the GPO without first removing the setting. Thus, to fix such a problem, you must explicitly reverse the specific security setting. If your organization's security requirements don't allow you to undo a security policy company-wide, you might instead want to isolate a few workstations to try and solve the problem. The best way to start from scratch in terms of security settings is to use the setup security.inf security template file to roll back Windows security to the default settings provided at setup. The setup security.inf file is located in %windir%\security\templates on all standard Windows systems. You can use the secedit.exe utility to apply this template, or you can import the template into the local GPO on a computer by opening GPE, right-clicking the Computer Configuration\WindowsSettings\Security Settings node, and choosing Import Policy.
After you've rolled back security to its setup state, you can retest the application to ensure that it's working, then reapply security policies, one setting at a time, until you identify the problematic setting. Obviously, this process can be extremely time consuming and should be considered only if you can't track down the problematic policy any other way. But as a last resort, using this approach on one or two test machines can help you locate the source of the problem you're experiencing.
As a general rule, when testing policy settings, try to change only one new setting at a time, then test that setting before you proceed to the next one. Although this approach slows policy deployment, it also makes troubleshooting policy settings much easier than if you were to make a large number of changes all at once.
Test, Test, Test
Group Policy provides many powerful capabilities. But if you don't thoroughly test GPOs before you implement them, they have the potential to interfere with your users' day-to-day functioning.
Always test your Group Policy settings before you implement them. If you run into problems, using the RSoP tools that Microsoft provides, as well as third-party tools such as SysInternal's Regmon utility, can make the process of tracking down those problems much less painful. And no matter what, be sure you have a good change process in place.
End of Article
