To maintain an effective Group Policy configuration, you must be able to troubleshoot Group Policy. Troubleshooting Group Policy involves using the Resultant Set Of Policy Wizard, the Gpresult.exe and Gpupdate.exe command-line tools, the Event Viewer, and log files to solve policy-related problems.
Troubleshooting Group Policy
As an administrator, you will likely have the task of finding solutions to problems with Group Policy. If problems occur, you might need to perform some tests to verify that your Group Policy configuration is working properly, such as the following:
Verify that GPOs apply to the appropriate users and computers.
Verify that folders configured for redirection are redirected to the appropriate location.
Verify that files and folders configured to be available offline are available when a computer is offline.
You will also need to be able to diagnose and solve problems, including:
Windows Server 2003 operating systems provide the following Group Policy troubleshooting tools to assist you in verifying your configuration and in diagnosing and solving problems:
Resultant Set Of Policy Wizard
Gpresult.exe
Gpupdate.exe
Event Viewer
Log files
Troubleshooting Group Policy with the Resultant Set Of Policy Wizard and Gpresult.exe
Recall that the Resultant Set Of Policy Wizard and the Gpresult.exe command-line tool are both used to generate RSoP queries and provide the RSoPs for users and computers you specify. In Windows Server 2003 operating systems, these tools can help you greatly reduce the amount of time you spend troubleshooting.
Troubleshooting Group Policy with Gpupdate.exe
Recall that the Gpupdate.exe tool, which is new in Windows Server 2003 (and also exists in Windows XP Professional), enables you to refresh policy immediately. Gpupdate replaces the Secedit/refreshpolicy command used for refreshing GPOs in Windows 2000.
Troubleshooting Group Policy with Event Viewer
By examining the application event log in Event Viewer, you can view Group Policy failure and warning messages, such as the one shown in Figure 1. The application event log contains basic predetermined Group Policy events and is used to track problems, not for Group Policy planning. Event log records with the source Userenv pertain to Group Policy events.
To avoid flooding the log, not all Group Policy failures and warnings are displayed in the event log. You can retrieve more detailed information about Group Policy processing by setting a switch in the registry to enable verbose logging for the event log.
Caution
This section contains information about editing the registry. Using the Registry Editor incorrectly can cause serious damage to your operating system. Use the Registry Editor at your own risk.
|
To enable verbose logging for the event log, complete the following steps:
1.
|
Log on as Administrator.
|
2.
|
Click Start, and then click Run.
|
3.
|
In the Run dialog box, in the Open box, type regedit and then click OK.
|
4.
|
In the Registry Editor console, open the HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/Current Version/ key, click Edit, select New, and then select Key on the toolbar.
|
5.
|
Type Diagnostics as the name of the new key. Right-click the new key, select New, and select DWORD Value on the toolbar.
|
6.
|
In the details pane, type RunDiagnosticLoggingGroupPolicy as the name of the new value. Right-click the new value, and select Modify.
|
7.
|
In the Edit DWORD Value dialog box, type 1 in the Value Data box. Ensure that the Hexadecimal option is selected. Click OK.
|
8.
|
Log off, and then log on again.
|
9.
|
Open the Application Log in Event Viewer, and view the enhanced Group Policy event logging.
|
Troubleshooting Group Policy with Log Files
You can generate a diagnostic log to record detailed information about Group Policy processing to a log file named Userenv.log in the hidden folder %systemroot%\Debug\Usermode. The generation of this diagnostic log is known as enabling verbose logging.
Caution
This section contains information about editing the registry. Using the Registry Editor incorrectly can cause serious damage to your operating system. Use the Registry Editor at your own risk.
|
To enable verbose logging to a log file, complete the following steps:
1.
|
Log on as Administrator.
|
2.
|
Click Start, and then click Run.
|
3.
|
In the Run dialog box, in the Open box, type regedit and then click OK.
|
4.
|
In the Registry Editor console, open the HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/Current Version/Winlogon key, click Edit, select New, and then select DWORD Value on the toolbar.
|
5.
|
In the details pane, type UserenvDebugLevel as the name of the new value. Right-click the new value, and select Modify.
|
6.
|
In the Edit DWORD Value dialog box, type 30002 in the Value Data box. Ensure that the Hexadecimal option is selected. Click OK.
|
7.
|
Log off, and then log on again.
|
8.
|
Open the %systemroot%\Debug\Usermode\Userenv.log file, and view the enhanced Group Policy event logging.
|
Note
To read or copy the logs on the target machine, you must have local Administrator rights.
|
The Userenv.log file, shown in Figure 2, provides details of errors and warnings in Group Policy processing on the computer on which it is set. Reading from left to right, this log shows a process code, the time it was processed (the date is not displayed), the process name, followed by a short statement of the error. The Userenv.log file has a maximum size of 1 megabyte (MB). At system startup, if the log file exceeds 1 MB, the contents are copied into a file named Userenv.bak and a new Userenv.log file is created.
Group Policy Troubleshooting Scenarios
Table 1 describes some troubleshooting scenarios related to the Group Policy Object Editor console.
Table 1. Group Policy Object Editor Console Troubleshooting Scenarios
| Problem: A user cannot open a GPO in the console even though he or she has Read access to it. |
|---|
| Cause | Solution |
| A user must have both Read permission and Write permission for the GPO to open it in the Group Policy Object Editor console. | Make the user a member of a security group with at least Read and Write, and preferably Full Control, permission for the GPO. For example, a domain administrator can manage nonlocal GPOs. An administrator for a computer can edit the local GPO on that computer. |
| Problem: When a user tries to edit a GPO, the Failed To Open The Group Policy Object message appears. |
| Cause | Solution |
| A networking problem, specifically a problem with the Domain Name System (DNS) configuration. | Make sure DNS is working properly. Refer to help for details. |
| Problem: When a user tries to edit a GPO, the Missing Active Directory Container message appears. |
| Cause | Solution |
| This is caused by Group Policy attempting to link a GPO to an OU that it cannot find. The OU might have been deleted, or it might have been created on another domain controller but not replicated to the domain controller that you are using. | Limit the number of administrators who can make structural changes to Active Directory, or who can edit a GPO at any one time. Allow changes to replicate before making changes that affect the same OU or GPO. |
| Problem: When a user tries to edit a GPO, the Snap-In Failed To Initialize message appears. |
| Cause | Solution |
| This error can occur if Group Policy cannot find the file Framedyn.dll. | If you use installation scripts, make sure that your scripts place the %systemroot%\System32\Wbem directory in the system path. By default, %systemroot%\System32\Wbem is in the system path already; therefore, you are not likely to encounter this issue if you do not use installation scripts. |
Table 2 describes some troubleshooting scenarios where Group Policy settings are not taking effect.
Table 2. Group Policy Settings Troubleshooting Scenarios
| Problem: Group Policy is not being applied to users and computers in a security group that contains those users and computers, even though a GPO is linked to an OU containing that security group. |
|---|
| Cause | Solution |
| This is correct behavior. Group Policy affects only users and computers contained in sites, domains, and OUs. GPOs are not applied to security groups. | Link GPOs to sites, domains, and OUs only. Keep in mind that the location of a security group in Active Directory is unrelated to whether Group Policy applies to the users and computers in that security group. |
| Problem: Group Policy is not affecting users and computers in a site, domain, or OU. |
| Cause | Solution |
| Group Policy settings can be prevented, intentionally or inadvertently, from taking effect on users and computers in several ways. A GPO can be disabled from affecting users, computers, or both. It also needs to be linked either directly to an OU containing the users and computers or to a parent domain or OU so that the Group Policy settings apply through inheritance. When multiple GPOs exist, they are applied in this order: local, site, domain, OU. By default, settings applied later have precedence. In addition, Group Policy can be blocked at the level of any OU or enforced through a setting of No Override applied to a particular GPO link. Finally, the user or computer must belong to one or more security groups with appropriate permissions set. | Make sure that the intended policy is not being blocked. Make sure no policy set at a higher level of Active Directory has been set to No Override. If Block Policy Inheritance and No Override are both used, keep in mind that No Override takes precedence. Verify that the user or computer is not a member of any security group for which the Apply Group Policy access control entry (ACE) is set to Deny. Verify that the user or computer is a member of at least one security group for which the Apply Group Policy permission is set to Allow. Verify that the user or computer is a member of at least one security group for which the Read permission is set to Allow. |
| Problem: Group Policy is not affecting users and computers in an Active Directory container. |
| Cause | Solution |
| GPOs cannot be linked to Active Directory containers other than sites, domains, and OUs. | Link a GPO to an object that is a parent to the Active Directory container. Then, by default, those settings are applied to the users and computers in the container through inheritance. |
| Problem: Local Group Policy is not taking effect on the computer. |
| Cause | Solution |
| Local policies are the weakest. Any nonlocal GPO can overwrite them. | Check to see what GPOs are being applied through Active Directory and whether those GPOs have settings that are in conflict with the local settings. |
|
No comments:
Post a Comment