If you would like to read the other parts in this article series please go to:
Introduction
Windows Vista includes some important changes from earlier Windows operating systems in regards to Group Policy (GP). This article introduces you to how troubleshooting is suddenly much easier by using the new Event Viewer, how the stability of policy application has improved by separating GP processing into its own service and why Network Location Awareness (NLA) is such a great thing.
Welcome to the constantly expanding Microsoft Group Policy universe.
Troubleshooting & monitoring
If you ever tried troubleshooting Group Policy processing on a Windows 2000, XP or 2003 computer you will probably say that you had some hard times finding the error messages, analyzing events etc. that eventually helped you figure out what was going on. The thing is, that with these operating systems, error messages could be found in the Event Viewer and a few different files – especially the file Userenv.log (placed in the %WINDIR%\Debug\Usermode directory), but this file holds information and logging from several different processes, like user profile load & unload etc. because we relied on the trace logging found in “userenv.dll”. See the Microsoft Technet articles “Troubleshooting Group Policy by Using Log Files” and “Interpreting Userenv log files” for detailed information. Let’s just say, things weren’t always easy for an administrator or Help Desk with all the cryptic error messages and the different places he/she had to look.
With Windows Vista the troubleshooting process is much easier! There are now only two logs for Group Policy on Windows Vista and both are accessed by using the new and improved Event Viewer (and logging API), codename ‘Crimson‘ (Figure 1)!
Figure 1
This new ‘interface’ for event management is a consolidated troubleshooting and reporting interface based on Microsoft Management Console (MMC) version 3. The logging is XML based, supports ‘Application Channels’, subscriptions – and you can now associate ‘Actions’/’Tasks’ to Events (send an email, execute a script etc.).
The Event Viewer can still be accessed though the “Control Panel\Administrative Tools”, by accessing “Computer Management” and by entering the command “EVENTVWR” into a Command Prompt or the “Run” dialog box.
If you right click an event (see Figure 1) and choose “Event Properties”, or just double click the event, the event is opened as shown in Figure 2. This looks a bit like earlier versions of Event Viewer, but notice the Details tab.
Figure 2
The Details tab contains all information about the event in the least detail. You have two different views of these details – Friendly View (Figure 3) and XML View (Figure 4). The latter shows the event as it really is – XML as everything else these days. So, why XML you might ask? Well, the simple answer is flexibility as you can import/export these events into any system or database without much trouble.
Figure 3
Figure 4
We now have two types of events: Admin and Operational events:
Admin events are regular events as we know them with a few changes. As you may remember, the Event Source of a GP application was the very general “Userenv” and these events were located in the Application Event Log. With Vista the Event Source is now “GroupPolicy“, it has moved to the System log and deals with GP only – making filtering a lot more accurate (you will have no mix of registry/profile unload and GP related events).
Speaking of filtering… Event filtering is also XML based and can be saved as Custom Views (see Figure 5).
Figure 5
Each event (Information, Warning or Error) should now contain a relevant link to Knowledgebase (KB) articles at Microsoft’s website – and as everything is written from scratch, the informational level should be better than before – only time will tell (this article is written based on Beta versions of Vista). The “GroupPolicy” events will mainly consist of basic event messages reporting successful or unsuccessful processing of GPs.
Operational events are found in Event Viewer under “Applications and Services Logs” > Microsoft > Windows > GroupPolicy – click the “Operation” log (see Figure 6).
Figure 6
The operational log provides improved event messages specific to GP processing, what Group Policy Objects (GPOs) where applied, which filters were used, periodic policy processing, loopback mode, how long did GP processing take to perform, other metrics etc.
It’s now much easier than with down-level Windows systems and you don’t have to open any text-logs in Notepad or whatever tool you may have used to diagnose GP processing issues. In other words, this is a very ‘admin-friendly’ replacement of the Userenv.log!
Stability
With Windows Vista we get improved stability and more reliable GP application and processing. The service is hardened by isolating 3rd party Client Side Extensions (CSE), requiring elevated privileges to stop the service (not even local administrators can stop the service by default) and the service restart configuration provides recovery on unexpected failures. All this will be 100% transparent to the user.
GP processing in Windows Vista now runs in shared service host (SVCHOST) and is not just part of the Winlogon process anymore – the new service is called “Group Policy Client” (or GPSVC). This dedicated service is now responsible for applying settings configured by administrators for the computer and users.
There are some additional benefits, Microsoft can deliver new GP files which can be updated without the need of a restart/log off and back on. Application of policy is more efficient because of reduction of resources used for background processing and performance increase because of reduction on memory usage.
Network Location Awareness
Network reliability was a huge issue with Windows 2000/XP/2003. Without a very stable network environment policy, processing started to perform somewhat badly. In scenarios with client VPN connections, change of network attachment or poor bandwidth/latency performance, things were not always pretty. You had to be lucky for policies to be applied correctly in these situations – same thing with laptops resuming from hibernate or standby state – very often a restart or log off was the only solution if policies were to be applied correctly.
Before Vista, policies were applied on clients only at machine startup (computer settings), at user logon (user settings) and every 90 minutes, plus up to 30 minutes offset, also known as the background refresh interval (which can be changed from the default value).
Another issue was the fact that Slow Link Detection (SLD) relied on the Internet Control Message Protocol (ICMP), so PING/ECHO requests were sent to determine the network state between client and Domain Controller (DC). When administrators turned off/filtered the ICMP protocol in routers or firewalls, often because of security concerns, policies were never applied because SLD determined the network was slower than 500Kbps (the default value).
The solution to all of these problems is Network Location Awareness (NLA) version 2.0. NLA is built in to the operating system and constantly monitors the network condition and introduces responsiveness to network changes and resource availability (subscribes to DC availability notification).
NLA is, among other things, aware of the presence of DCs, if the previous policy application cycle was skipped or failed, Vista will retry GP processing when a DC is available. The improved GP engine will even initiate a background refresh over a VPN connection, updating both the machine and user policy. So there’s no longer any need to reboot or log off and back on, before connecting to the corporate network over a VPN connection.
With the access to resource detection and event notification capabilities in the OS, such as recovery from Hibernation, moving in and out of Wireless networks, successfully exiting quarantine, docking of a laptop etc. we achieve a very accurate indicator to GP of when the network is ready and reliable.
NLA can also determine if the adapter is disabled or disconnected, enabling GP to shorten its wait time for scenarios in which the network is not available – this will help Windows Vista to boot/startup faster!
The use of NLA increases the level of security on the computers by more quickly and reliably applying GP changes, especially mobile users – which by the way is a heavily growing crowd – are now handled in a more safe and efficient manner.
There’s no reliance on the ICMP protocol with the new NLA bandwidth/connectivity determination, so there’s no doubt that NLA will improve policy application and processing. However, some additional configuration is required for Network Quarantine networks (NAC/NAQ).
What will the future bring?
Microsoft already provided some detail on what they expect to include in future operating systems and/or service packs (like Windows Vista Service Pack 1 and Windows Longhorn Server). One of the great things they will provide is the ability to put comments on GPO’s and GPO settings; this can be very helpful for documentation and change management.
Another great thing we will most likely get is search capabilities (specific keywords) and filtering options (like ‘managed’, ‘commented’, ‘configured’, ‘OS requirements’ etc.). So in some months or so we will be able to search within ADMX files loaded into the Group Policy Object Editor (GPOE). If you have ever tried finding a specific policy you will probably agree it could be difficult, with 800+ more policies in Vista/Longhorn (at this very early point before it is even launched) search capabilities will be vital in a short time.
“Guidance templates” will be supported by the Group Policy Management Console (GPMC). These templates will include recommended policy settings and values (known as ‘best practice’) and we can then create new GPO’s based on templates as well as customize our own templates.
It could be real nice with a stand-alone GUI tool for editing ADMX and ADML files (see article one). Microsoft have not promised such a tool yet, but if they don’t create it I’m pretty sure that others will. The XML format is a good standard, but to really enjoy its fruit and flexibility an “intelligent” (ADMX schema aware) editor would be real nice.
Conclusion
Windows Vista brings us some great new GP functionality and hopefully we will all experience the improvements on GP performance and reliability when Vista is deployed. So far it really looks like Microsoft did some thorough thinking and made GP processing even better than before.
In this part three (the last) of this article series, “Managing Windows Vista Group Policy”, basic troubleshooting, improved stability and Network Location Awareness was covered.
In part one of three articles we covered the difference between ADM and ADMX/ADML files and what the Central Store is all about.
In part two of this article series we covered having multiple local group policy objects.
Related Links
Windows Vista Group Policy chat (September 28, 2006) with Mark Williams, Judith Herman, David Power, Mike Stephens and Jeff Clark
Managing Group Policy with Windows Vista chat (June 1, 2006) with Judith Herman, Rahul Gupta, Mark Williams and Mark Lawrence
If you would like to read the other parts in this article series please go to:
