Microsoft KB Archive/250842

= Troubleshooting Group Policy application problems =

Article ID: 250842

Article Last Modified on 2/28/2007

-

APPLIES TO


 * Microsoft Windows 2000 Server
 * Microsoft Windows 2000 Advanced Server
 * Microsoft Windows 2000 Professional Edition
 * Microsoft Windows 2000 Datacenter Server

-



This article was previously published under Q250842



SUMMARY
This article describes troubleshooting procedures for Group Policy processing on a Windows 2000 client computer. This might include incorrect or incomplete policy settings or the lack of policy application to the computer or user.

Before you use the steps in this article, you should be familiar with the information contained in the following Microsoft Knowledge Base articles:

216357 Identifying Group Policy client-side extensions

228460 Location of ADM (Administrative Template) files in Windows 2000

216358 Troubleshooting Group Policy client-side extension behavior



MORE INFORMATION
 Enable verbose debug logging on the Windows 2000 client computer using the instructions outlined in the following Microsoft Knowledge Base article:

221833 How to enable user environment debug logging in retail builds of Windows 2000

A log file (Userenv.log) is generated in the Winnt\Debug\UserMode folder and usually points to the root cause of a general failure to enumerate the list of Group Policy Objects (GPOs) that apply to the user. Minimal information about the status of each Group Policy extension (DLL that performs a specific type of policy application, such as Security, Folder Redirection, and so on) applying policy is also recorded in the Userenv.log file, but for verbose information about each extensions, there are other settings to enable logging specific to those components (described later in this article). Verify connectivity and DNS resolution. If connectivity to domain controllers is causing the problem, the debug log usually detects the problem and records specific locations in Active Directory and on network shares where Windows 2000 is attempting to gain access to data.

The Windows 2000 support utilities, Dcdiag.exe and Netdiag.exe, are used to test network connectivity and DNS resolution. Dcdiag.exe is used to test Domain Controllers, and Netdiag.exe is used to test workstations and servers. To run Dcdiag.exe, type dcdiag /v at a command prompt on a domain controller. To run Netdiag.exe, type netdiag /v at a command prompt on a workstation or member server.

For more information about Dcdiag.exe and Netdiag.exe, see the Windows 2000 support tools help, or click the article number below to view the article in the Microsoft Knowledge Base:

265706 DCDiag and NetDiag in Windows 2000 facilitate join and DC creation

 Verify that Group Policy should be applied to the client. Windows 2000 determines what type of policy to apply, whether it is down-level policy (Ntconfig.pol in Microsoft Windows NT 4.0) or Group Policy, based on the location of the computer and user account. Use Gpresult.exe from the Microsoft Windows 2000 Resource Kit. Pay particular attention to the order in which the GPOs are applied. If the same setting is specified in multiple GPOs, those applied later in the process (lower in the log files) are authoritative and override settings in GPOs higher in the list. Use Gpotool.exe to determine if there is an inconsistency between Active Directory and SYSVOL versions of the same GPO across peer domain controllers. This information can help you determine if replication latency is causing the Windows 2000 client to not receive the correct policy. If you think this is the case, use Replmon.exe and Repadmin.exe (both from the Windows 2000 Support Tools suite) to determine the replication partners for the domain controller that the client used as a source for the Group Policy and determine if replication is succeeding. Verify in the Userenv.log file that the Distinguished Name (DN) of the computer/user is being determined. If Windows 2000 does not determine the DN, it cannot properly parse Active Directory to determine which GPOs to apply to the user or computer. View the Userenv.log file. Entries for each GPO that is evaluated are recorded in this file. Determine if any GPOs are being skipped because the user does not have the proper permissions on the GPO (the user should have Read and Apply Group Policy permissions).</li>  Determine if loopback processing is in effect. This causes the user components of GPOs that apply to the computer to be applied to the user. To determine this, look for a line in the Userenv.log file that looks like the following example: <pre class="fixed_text">USERENV(e8.128) 15:46:17:234 ProcessGPOs: Calling GetGPOInfo for normal policy mode NOTE: In this example, normal policy processing rules apply. </li> If the client computer is running Terminal Services, certain types of policy (specifically application deployment) disable the assignment of applications.</li> If application deployment is not working, perform the following actions:

<ol style="list-style-type: lower-alpha;"> Enable Windows Installer logging using the instructions in the following Microsoft Knowledge Base article:

223300 How to enable Windows Installer logging in Windows 2000

</li> Enable Application Management Policy processing using the instructions in the following Microsoft Knowledge Base article:

246509 Troubleshooting program deployment by using verbose logging

</li></ol>

These logs may show clients that cannot locate the installation path specified for the program you want to install.</li> Not all types of policy are applied during a background refresh of Group Policy. To force the re-application of all types of policy, you must restart the computer or the user must log off and log on again, depending on whether machine policy or user policy is being applied, respectively.</li></ol>

If You Need to Call Microsoft Product Support Services
If you need to call Microsoft Product Support Services, it is important to provide the following information to the support professional:
 * The Userenv.log file from the Winnt\Debug\UserMode folder.
 * The "gpresult.exe /s" output redirected to a text file (run on the Windows 2000 client computer).
 * The "gpotool.exe /verbose" output redirected to a file (run on the Windows 2000 domain controller).
 * The "netdiag.exe /v /l" output, which results in a file named Netdiag.log (run on the Windows 2000 client computer).

If you know the type of policy or the specific GPO that is not being applied, the following additional information is also helpful (depending on the type of policy):

If Security Policy Does Not Work
Determine the GUID of the GPO that is not working, using the steps in the following Microsoft Knowledge Base article:

216359 How to identify Group Policy objects in the Active Directory and SYSVOL

Remember that for most security settings, the highest priority settings reign and are not cumulative. Locate the Gpttmpl.inf file found in the corresponding SYSVOL folder under Machine\Microsoft\Windows NT\SecEdit. This is the file that has the security settings applied by Group Policy for a given GPO.

If Registry/Software Policy Does Not Work
<ol> Determine the GUID of the GPO that is not working, using the steps outlined in the following Microsoft Knowledge Base article:

216359 How to Identify Group Policy Objects in the Active Directory and SYSVOL

</li> Locate the Registry.pol file in the Machine or User folder in the corresponding GPO folder in SYSVOL.</li></ol>

If Application Management Policy Does Not Work
<ol> Enable Windows Installer logging using the instructions in the following Microsoft Knowledge Base article:

223300 How to enable Windows Installer logging in Windows 2000

</li> Enable Application Management Policy processing, using the instructions in the following Microsoft Knowledge Base article:

246509 Troubleshooting program deployment by using verbose logging

NOTE: Review the Application Management Policy engine log files first to determine if the programs you want installed are being determined and handed off to Windows Installer. The Installer log files contain a history of the installation procedures that took place during the installation of the program.</li></ol>

If Logon/Logoff/Startup/Shutdown Script Policy Does Not Work
Using Gpresult output, determine which GPOs had scripts configured to run and determine the GUID of each GPO using the steps in the following Microsoft Knowledge Base article:

216359 How to identify Group Policy objects in the Active Directory and SYSVOL

Locate the Scripts folder for each GPO in SYSVOL and verify that the scripts that are configured to run have been replicated to the domain controller used as the source for policy.

If Folder Redirection Policy Does Not Work
Using Gpresult output, determine which GPOs (if any) had Folder Redirection policy. If a policy is in place that should be affecting the user but the folders are not being redirected, it is possible a GPO was not applied because the user did not have the proper permissions on the GPO.

If the GPO is disabled or deleted but folder redirection is still in effect after a policy refresh, perform the following steps (if the GPO is still available):
 * 1) Open the GPO.
 * 2) Right-click the folder that was redirected, and then click Properties.
 * 3) On the Settings tab, identify whether or not the Return the redirected folder to its previous setting option is selected.

Additional query words: fail fails failure failing downlevel

Keywords: kbenv kbinfo KB250842

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.