More Powerful Group Policy in Windows Vista
At a Glance:
- The Group Policy infrastructure
- Improved network awareness
- Added Group Policy capabilities
Windows Vista delivers a substantial update to the Group Policy infrastructure. Yet as organizations around the world deploy Windows Vista, many administrators probably won't notice much of a difference in how they work because the numerous changes in Group Policy functions
all take place under the hood. What administrators will find, however, is that Windows Vista™ Group Policy is much more powerful than it was in previous versions.
Prior to Windows Vista, Group Policy processing occurred within a process called winlogon. Winlogon had a lot of responsibility, which included getting people logged on to their desktops, as well as servicing the various Group Policy chores. Group Policy is now its own Windows® service. What's more, it's hardened, which means that it cannot be stopped nor can an administrator take ownership of the permissions upon Group Policy in order to then turn it off. These changes enhance the overall reliability of the Group Policy engine.
This is just for starters. Let's take a more in-depth look at some of the major changes that have been made to the new Group Policy.
Improved Network Awareness
Before Windows Vista, the Group Policy engine would try to figure out if you were coming in over a slow link or a fast link. It would then use this knowledge to help craft which policy settings it would apply. Over a slow link, Group Policy wouldn't send the entirety of policy settings to your system, as this could take quite a bit of time to download. This assistance hasn't been removed from the new Group Policy. However, what has changed is how current network bandwidth is calculated.
This speed determination was done by sending Internet Control Message Protocol (ICMP) ping packets to Domain Controllers. This approach had many problems in real-world use. First, many administrators turn off ICMP on their routers. Second, if the connection was over high-latency links (like satellite), the calculations were unreliable. In these situations, the Group Policy engine had no guaranteed way to determine if the link was truly fast or not.
Additionally, the Group Policy engine had no idea if the machine was being restored from hibernation or standby mode. Nor did the Group Policy engine know if you suddenly dialed in after being off the network for six months. Using a machine that runs Windows XP or Windows 2000, a user could dial in, check e-mail, and disconnect—all without getting a Group Policy refresh. Most administrators would want to perform a Group Policy refresh, if needed, on a system being restored from hibernation or standby or a machine dialing in after a long absence.
The updated Windows Vista Group Policy is smart enough to know about network connectivity in real time. The main change is that the Group Policy engine now uses the Network Location Awareness 2.0 (NLA) handler in Windows Vista. The NLA service simply alerts the Group Policy engine whenever a Domain Controller is available. And, if so, a Group Policy refresh is performed if needed.
Multiple Local GPOs
In the days before Windows Vista, only one Local Group Policy Object (GPO) was supported. If you typed GPEDIT.MSC at a command prompt and made some changes to the settings, you affected every user and administrator who used that machine. This was often a problem if, say, you wanted to remove the Run command from the start menu for typical users, but leave it available for administrators.
The new Multiple Local GPO facility addresses this problem using GPO layers. This capability will probably be used mostly on systems that are not joined into an Active Directory domain. However, corporate users may find this feature useful as well.
The new Multiple Local GPO facility, which is based on layers, can get a bit complicated (see Figure 1). There's still a default local GPO, which applies to the local computer system context and affects all users on the system. This GPO defines both Computer Settings and User Settings.
Figure 1 Users' Total Local Group Policy
The second layer affects members of either the local system Administrators group or non-Administrators on the local system. By definition, a user account cannot be in both groups. The layer figures out whether the user is a local System Administrator or a regular user and then applies the appropriate GPO (either Administrators or non-Administrators). The third layer affects a specifically named local system user account.
So that's three potential local GPOs that can affect any particular user who sits down at the machine. For example, you can use the three layers to provide settings for everyone on a particular machine, more settings that affect only non-Administrators of the machine, and finally settings that affect just one single user of that machine.
Of course, if the system has been joined into an Active Directory® domain, the Active Directory Group Policy Objects take precedence over local policies. It should also be noted that Domain Administrators can choose to turn off all local GPO processing for Windows Vista.
Error Messages and Troubleshooting
Windows Vista has an entirely new Event Log system. The Group Policy engine leverages this new Windows Eventing 6.0 system (commonly known as the Event Log) and splits events into two particular logs. The familiar System log (which is now seen as an Administrative log) contains Group Policy problems. If an error with the Group Policy engine occurs, it should appear in the System log, listed as coming from the Group Policy Service (not the Userenv process).
A new Applications and Services log (which is an Operational log), is specifically for Group Policy, and stores operational events. This essentially replaces the cumbersome userenv.log troubleshooting file, as each step from the Group Policy engine is listed here for easy reading.
ADM and ADMX
Since the days of Windows NT® 4.o, ADM files have provided the underlying definitions templates for what's possible in Group Policy. Not everything in Group Policy is controlled by ADM files, but they are responsible for all the goodies located under User Configuration | Administrative Templates in addition to Computer Configuration | Administrative Templates.
Functionally, these ADM files have some flaws. In versions of Windows previous to Windows Vista, every time you create a new GPO you copy a slew of these ADM files into every GPO's folder (which lives in SYSVOL) to the tune of about 5MB per GPO. With lots of GPOs, there are lots of duplicated systems template files placed on SYSVOL, and this creates in turn lots of replication from each of these 5MB nuggets.
Additionally, ADM files aren't language-neutral. An ADM file is built in one language and everyone using that file has to make due with that language choice.
Group Policy in Windows Vista addresses these issues with the introduction of a new XML-based format for policy definition files called ADMX. The ADMX files themselves are language-neutral. However, they must be accompanied by a language-specific ADML file. You can easily add more languages by simply adding more ADML files to accompany an ADMX file.
The ADMX format supports a central store. This eliminates all the replication of duplicate information and it makes it easier to update an ADMX file. Suppose an ADMX file is updated, perhaps from a service pack—all you need to do is drop the updated file in the central store and you're done. All Group Policy administrators in the domain who are using Windows Vista workstations will have access to the updated ADMX file. Previously, you needed to ensure each administrator's machine had the correct copy of any updated ADM file, and that was a challenge at best.
A domain administrator needs to create the central store on SYSVOL manually, once for each Active Directory domain. Once the central store is created, all administrators using Windows Vista machines to create and manage GPOs will automatically use the central store. Note that this is a feature specific to Windows Vista and it's the Windows Vista machine joined to an Active Directory domain that checks for the presence of a central store. You don't have to wait for the next version of Windows Server® , code-named "Longhorn," nor do you have to convert you users' machines to Windows Vista. This occurs regardless of whether the domain is based on Windows Server Longhorn, Windows Server 2003, or even Windows 2000. In order to take advantage of the central store, you simply need to create the central store, and then use Windows Vista machines to create or manage GPOs.
As mentioned, ADMX and ADML files are based on XML. The primary benefit of XML is the use of an industry-standard language. It's worth pointing out, though, that there is no ADMX graphical editor (or any plans for Microsoft to release one). Nor is there an ADM to ADMX conversion tool for any custom ADM templates you might already have.
Windows Vista will ship with about 130 ADMX files which replace the 6 to 8 ADM files that shipped with previous versions of Windows. These files live in the \Windows\PolicyDefinitions directory, as shown in Figure 2. Note that the ADML files are stored in language-specific subdirectories, like the en-US directory for United States English.
Figure 2 ADMX Files in the \Windows\PolicyDefinitions Directory (Click the image for a larger view)
Group Policy Management Console
The Group Policy Management Console, or GPMC, was available as a download for Windows XP and Windows Server 2003. A scriptable Microsoft Management Console, GPMC offered a single administrative tool for managing Group Policy.
GPMC is now built right into Windows Vista. This means that whenever you're ready to create or edit GPOs, you'll have easy access to the best tool for the job. Just type GPMC.MSC at the Windows Vista Start | Search command prompt and you're ready to go.
New Stuff to Control
Windows Vista brings about 800 new policy settings to the table. These exist over multiple categories, many of which you already know and rely on. But Windows Vista also introduces some great new categories—ones that simply hadn't existed or lacked any Group Policy controls.
Enhanced areas in Group Policy include Wired and Wireless networking policy, Windows Firewall and IPsec, Print Management, Desktop Shell, Remote Assistance, and Tablet PC. Note that the updated Wired and Wireless policies may require a forest-wide schema update (for more information on this, see microsoft.com/technet/itsolutions/network/wifi/vista_ad_ext.mspx).
New areas in Windows Vista Group Policy include Removable Storage Device management, Power Management, User Account Control, Windows Error Reporting, Network Access Protection, and Windows Defender.
To control the areas that specifically affect Windows Vista machines, you must use a Windows Vista machine (or a Windows Server "Longhorn" machine) when you create or edit the GPOs. That's because the older operating systems will have no knowledge of these new settings that are specific to Windows Vista.
An exploration of any of these areas could fill an entire article, so there isn't space here to delve into each one. However, the Removable Storage Device management features and Power Management features (seen in Figure 3) are particularly noteworthy. These features, I suspect, will be huge boons for administrators everywhere. In short, these areas give decent granular control over which devices can be attached to Windows Vista and what kind of power settings laptops, desktops, and monitors will use to save companies money.
Figure 3 Enforce Power Management through Group Policy (Click the image for a larger view)
With the additional Power Management settings in Windows Vista, an administrator can elect to turn off or place an inactive video display monitor into a low-power "sleep" mode. Studies published on the Environmental Protection Agency's Energy Star Web site have shown that controlling monitor power use can result in savings of $10 to $30 USD per monitor annually. That savings can really add up when you've got hundreds or thousands of monitors in your company.
As for Removable Storage Management, consider this scenario: an administrator wants to allow students to use their USB flash drives to access term papers, homework, or other documents on any campus kiosk workstation. However, due to possible misuse, as well as potential security risks, the students should not have write access to the USB drives at the campus kiosk workstation—unless, of course, it is a school-approved USB drive. This type of device management granularity is possible using Windows Vista Group Policy settings.
As you can see, these improvements to Windows Vista management happen under the hood. Administrators will find that Windows Vista Group Policy provides powerful, flexible configuration management with a significant increase in configurable settings, and new resources to increase system security (and potentially reduce costs).
Jeremy Moskowitz, MCSE and MVP in Group Policy, runs GPanswers.com, a community forum on Group Policy. He also runs a two-day Group Policy intensive training course. His latest book is Group Policy, Profiles and IntelliMirror, Third Edition (Sybex, 2005). Contact Jeremy at www.GPanswers.com. Thanks to Mark Lawrence of the Group Policy Team at Microsoft for his assistance with this article.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited