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:
GPOs are not applied. GPOs cannot be accessed. GPO inheritance issues cause unexpected results. Folders are not redirected or are redirected to an unexpected location. Files and folders are not available offline. Files are not synchronized.
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:
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. |
|
