Step 2: Troubleshoot core-processing problems by checking infrastructure.
Let's say that the Group Policy Results Wizard revealed that core processing failed (i.e., the Group Policy Infrastructure component status was Failed). Such a failure usually points to an infrastructure problem related to either the client or the domain controller (DC) from which the policy information is being read. Note that "client," in this context, could be either a server or a workstation. Several technologies can cause core-processing problems. Start by doing the following checks:
- Is the TCP/IP NetBIOS helper service running on the client machine? This service is required for successful Group Policy processing. To check this service, either type
net start
at a command prompt to get a list of all running services or go into the Administrative Tools program group on the Start menu and select the Microsoft Management Console (MMC) Services snap-in to verify that the service is started.
- Is DNS configured correctly on the client to ensure that the system can properly resolve DCs?
- Is ICMP enabled on your network? The client and the DC must be able to use ICMP for slow-link detection before Group Policy processing can occur. If ICMP isn't enabled, all Group Policy processing will fail.
- Can the client access the copy of the GPO that's stored in Sysvol on the DC that the client's communicating with? If not, Group Policy processing will fail. You can use gpotool.exe—one of the Microsoft Windows 2000 Resource Kit tools—to query all DCs in a domain and determine whether a Sysvol replica related to Group Policy storage is out of sync. A Sysvol replica that's out of sync usually indicates an FRS replication problem. The Microsoft article "How To Troubleshoot the File Replication Service in Windows Server 2003" (http://support.microsoft.com/kb/327341/en-us) is a good starting point for troubleshooting FRS problems on Windows 2003. The Ultrasound FRS monitoring and troubleshooting tool (available at http://www.microsoft.com/downloads/details.aspx?FamilyID=61acb9b9-c354-4f98a82324cc0da73b50&DisplayLang=en) can also help identify and correct FRS replication problems.
You can also get clues to core-processing problems by checking the client computer's Application event log for events that have an event source of Userenv. Such events typically relate to core processing and sometimes can contain information about specific errors that occurred during processing. In that case, you might want to use the gpolog.adm template to enable verbose Application event logging.
Step 3: Use the Application event log to troubleshoot client-side extension problems.
If the Group Policy Results Wizard reveals that the problem is specific to a particular client-side extension, focus your efforts on determining why that extension failed. Start by looking for related errors in the Application event log. You'll typically see one of the following event sources listed for a particular client-side–extension problem:
- Folder Redirection (for Folder Redirection policy)
- Userinit (for Scripts policy)
- Scecli (for Security Settings policy)
- Application Management (for Software Installation policy)
- Userenv (for the Administrative Template policy and for core processing)
In addition to using the Application event log, you might need to drill down further to find problems specific to client-side extensions.
Step 4: Enable logging specific to core or client-side extension processing.
If the information in the Application event log isn't detailed enough, you might need to drill further into a core processing or client-side–extension problem. The gpolog.adm template I mentioned earlier exposes a variety-of logs. A good log to start with is the Userenv log (written to %windir%\debug\ usermode), which captures detailed step-by-step information of both core and client-side extension processing as well as user profile activity. This file is updated with every Group Policy processing cycle, and you can use it to walk through the processing actions of each client-side extension. You can see whether a client-side extension actually ran, and if not, why it didn't. For example, the log file might show that the client-side extension didn't run because the GPOs it was processing hadn't changed since the last cycle.
Finally, you can enable verbose logs to help you troubleshoot certain client-side extensions. For example, you can enable a verbose log for the Software Installation extension to determine why a package was incorrectly installed—whether because of a problem with the client-side extension or a problem with the package itself. If the problem is related to the package, then you can enable verbose Windows Installer logging within an administrative template policy (Computer Configuration\Administrative Templates\Windows Components\Windows Installer\Logging) to further attack the problem.
Be Methodical
Group Policy troubleshooting requires a methodical, step-by-step approach that first narrows the problem and then seeks out the solution. The tools and suggestions I've discussed will help keep your troubleshooting time to a minimum and the solution close at hand.
|
SOLUTIONS SNAPSHOT
PROBLEM: Group Policy processing is failing.
SOLUTION: Enable Group Policy logging and start troubleshooting.
WHAT YOU NEED: GPMC for Windows 2003 or XP; optionally, the gpolog.adm tool to enable Group Policy logs
DIFFICULTY: 3 out of 5 |
|
SOLUTION STEPS:
- Review the most recent processing cycle using the GPMC Group Policy Results Wizard.
- If it's a core-processing problem, check related infrastructure pieces.
- If it's a client-side–extension problem, enable the Application event log and look for errors.
- Drill further into logs specific to core processing and/or client-side–extension processing.
|
End of Article
