Troubleshooting Group Policy

With a standard SBS setup, there will generally be few group policy issues to troubleshoot. Clients may encounter errors showing up in the event logs on servers and workstations indicating that there were problems applying group policy settings. These errors, usually UserEnv 1030 and 1058 errors, actually indicate a communications problem between the workstation and the server or a misconfiguration of network settings, not actually a problem with the group policies themselves.

Group policy issues often appear as anything but group policy problems. The issues that appear depend largely on the types of changes made in group policy. In most cases, when group policy is applied and not fully tested, a policy change will have an impact on another aspect of the network, and the only clue the system administrator has that group policy might be the culprit is that the problems started appearing around the time that a change was made in group policy.

Group Policy Testing Tools

This chapter has already covered the Group Policy Modeling and Group Policy Reporting Wizards, but they deserve mention yet again because of their importance in determining not only what should happen with group policy but also what actually does happen.

Other tools that are useful in troubleshooting group policy problems are the command-line tools gpresult and gpupdate.

Using Group Policy Modeling and Results

Both the Modeling and Results Wizards are good first-step tools to aid in troubleshooting. If you suspect problems with group policy try the following steps:

1.	Run a group policy Modeling report for a workstation or user experiencing a problem.
2.	Review the report and make sure that the policy settings you are expecting to be there are actually showing up in the model.
3.	Run a group policy results report against the same user and/or machine and compare the results to the modeling report. If the settings between the two reports do not match, drill down into where the differences appear and try to determine why the policy is not being applied in the same way.

Using gpresult and gpupdate

Another way to determine what policies have been applied on a workstation is through the gpresult command. This tool, which only runs in a command prompt, generates text data that matches the graphical output of the group policy results report. This tool is run directly on the workstation and can be used to collect results data when the Windows XP SP2 firewall blocks RPC requests from the server.

To get the most information out of gpresult, run gpresult /v at the command prompt and redirect the output to a text file. You can then review the command output by opening the file in Notepad or another text-editing tool.

As you can see from the listing, you get access to the same data present in the Group Policy Results report. Some administrators find this output more difficult to work with, but it can always be generated at the workstation, especially when the Group Policy Results Wizard cannot contact the workstation to collect the data remotely.

The gpupdate command replaces the secedit command from Windows 2000. The most common use of gpupdate in troubleshooting policy issues is to force policy to be reapplied on demand either at the server or a workstation. Normally, group policy is applied on a regularly scheduled basis at both the server and workstation level. When you are troubleshooting a group policy problem, you want to avoid any unnecessary delays when you can, and gpupdate can help cut down on those delays.

To force the server to immediately update changes made in GPOs across the entire network, run gpupdate /force from a command prompt on the server. This forces the server to process and apply all group policy objects defined in Active Directory. When workstations are connected correctly to the domain, this also triggers an update to occur on the workstations as well.

If needed, gpupdate /force can be run on a workstation to ensure that it has pulled the latest policies from the server and applied them locally.

Group Policy Disaster Recovery

Before making any changes to group policy, you should use the tools in the Group Policy Management Console to back up the GPO first. You can also back up the entire set of GPOs on the server through the tool as well. In the Group Policy Management Console, expand Forest, Domains, domainname, and right-click on the Group Policy Objects folder. One of the options in the pop-up menu is Back Up All. When you select this option, you can save all the GPO configurations to a single location on the server. This location should be a secure location so that normal users cannot access and/or modify the settings files. Alternatively, you can right-click on each individual GPO and select the Back Up option to save the settings for just that object. Ideally, you should do this immediately after setting up the server so that you have a set of default settings to recover should something happen to the group policy configuration.

The only other tool for performing a disaster recovery on group policy mishaps is the system state backup. Because the system state backup contains security and policy information as well as system files and configuration data, if group policy becomes corrupt to the point that the network is unusable, you could restore from a recent system state backup to recover the policy elements as a whole. Of course, for this to actually work, you must be collecting a system state backup as part of your regular backup regimen.

Best Practice: Do Not Use dcgpofix to Recover from Group Policy Problems

dcgpofix should only be used on an SBS server as an absolute last resort. This tool restores group policy on a server back to the point immediately before the server was promoted to Domain Controller status. In other words, all the customization of security and group policy performed by the SBS setup process is lost. Use this tool only when there is absolutely no other way to get control back on a server.

If you do have to run dcgpofix to regain access to a server, you need to restore a system state from backup to get the SBS customizations back on the system. If a system state backup is not available for restore, you can look at rerunning the SBS installation process. At a bare minimum, you need to re-create the SBS policies by hand to restore at least some of the security and configuration to the server. If you run dcgpofix to recover access to your server, do not assume that it is safe to let your server go back to its regular routine.