You are not authorized to post comments.

Windows Tip: Troubleshooting group policy in Windows Vista

ITworld.com |  Operating Systems Add a new comment

Send your Windows question to Mitch today! | See other Windows tips


Group Policy is a key technology for managing computers on Windows-based networks where Active Directory is deployed. But Group Policy has been considerably enhanced in Windows Vista, and also in the soon-to-come Windows Server Code-Name "Longhorn." And of course, changes mean more learning for those who are going to administer these platforms, so this tip deals with one of these changes, namely how to troubleshooting Group Policy processing in Windows Vista.

In previous versions of Microsoft Windows, an important tool for troubleshooting Group Policy processing is the userenv.log file. This verbose log, which is generated by Userenv.dll (part of the core Group Policy engine) can be used by administrators to determine what is happening in the background when a user logs on to his or her computer and Group Policy is applied. If you search the Knowledge Base on Microsoft TechNet you can find lots of information on how to enable Userenv.dll logging and interpret the resulting logs. In Windows Vista however, Userenv.dll can no longer be configured to generate a userenv.log. How can you troubleshooting Group Policy processing issues then on this new platform?

The simple answer is, by using Event Viewer! In Windows Vista, Group Policy events are logged in two channels:

* Group Policy Operational Log. The events logged here are verbose Group Policy processing events that are similar to those that could formerly be found in userenv.log.

* System Log. Events with source "Group Policy" logged here are more general events concerning the success or failure of Group Policy processing.

That's not all though. There's yet another way in Windows Vista that you can troubleshoot Group Policy issues, and this is to enable debug logging for the Group Policy Object Editor (Gpedit.msc). When you enable debug logging, Gpedit.msc generates a GpEdit.log that can be used for resolving issues involving malformed ADMX files. To enable Gpedit.msc debug logging, create the following REG_DWORD registry value:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPEditDebugLevel

You should normally set this value to 0x10002 for troubleshooting purposes, and the result will be a GpEdit.log located in the %SystemRoot%\debug\usermode folder on the local machine.

You'll find lots of information in the upcoming Windows Vista Resource Kit concerning how Group Policy has changed in Windows Vista, and if you haven't pre-ordered this terrific book yet, you should do so today. I know, that's another shameless plug for a book that I was involved in, but hey, we geeks gotta eat!

ITworld LIVE

Operating SystemsWhite Papers & Webcasts

White Paper

A Comparison of PowerVM and VMware vSphere (4.1 & 5.0) Virtualization Performance

This technical white paper presents benchmark results showing greater VM consolidation ratios than demonstrated in previous benchmarks and demonstrating the extent of the performance lead that PowerVM virtualization technologies deliver over x86-based add-on virtualization products.

White Paper

Consolidating Lotus Domino x86 Workloads on IBM Power Systems

Read the white paper to learn how moving up to Lotus Domino 8.5 and consolidating with IBM Power Servers can help you boost performance results and ROI.

White Paper

Task, workflow & issue management for teams. Try free!

Need a flexible system for managing team tasks, issue tracking, and automating and managing workflow processes? Comindware® Tracker helps you do it all.

Webcast On Demand

Best Practices in Monitoring VMware

The benefits of virtualization are unassailable: increased agility, scale, and cost savings to name a few. However, so too are the monitoring challenges posed by these environments-including complexities, lack of visibility and control, and inefficiency.

Sponsor: Nimsoft

White Paper

How Nimsoft Service Desk Speeds Deployment and Time to Value

For years, many support teams have been hamstrung by their traditional service desk platforms, which require complex, time-consuming coding for virtually every aspect of customization. This complexity makes it costly and difficult for support organizations to adapt-and places an increasingly substantial burden on the agility and efficiency of the business as a whole.

See more White Papers | Webcasts

Ask a question

Ask a Question