|
Executive Summary: Group Policy has become more important in Windows Vista and Windows Server 2008--but also more complex. The more you learn about the changes to Group Policy, the better you'll be able to control it. Changes you'll learn more about include those made to Group Policy Client Services, slow link detection, and the ability to create three new types of Group Policy Objects (GPOs). |
Now that Windows Vista has shipped and Windows Server 2008 is nearing release, it’s a good time to look more closely at some of the Group Policy enhancements these new versions of the OS introduce. Group Policy has taken on an important role as the key configuration management mechanism within Windows. That’s a good thing. It’s challenging though, because more enhancements mean more options, more options mean more choices, and more choices mean more complexity. The good news is that the enhancements Microsoft is making in Group Policy Management Console (GPMC) for Server 2008 will mitigate some of these complexities.
Group Policy Client Service
There are significant changes to some of the unseen aspects of Group Policy. Most importantly, the Group Policy engine has been moved out of the system Winlogon process, where it has run ever since Windows 2000, and into its own Group Policy Client service. The Group Policy Client service is a nonrestartable service in Vista and Server 2008 that runs the Group Policy processing engine. It runs outside of Winlogon and provides an isolated environment for Group Policy client-side extensions (CSEs) to run in. In fact, it even provides isolation between Microsoft CSEs and third-party ones, so if a third-party CSE crashes, Microsoft’s CSEs will not be affected during Group Policy processing. Feature
Slow Link Detection
The slow link detection process in Group Policy has also changed. If you’re familiar with slow link detection in previous versions of Windows, you know that, at the beginning of each Group Policy processing cycle, a client uses Internet Control Message Protocol (ICMP) to ping its Active Directory (AD) domain controller (DC) to determine its availability and compute the speed of the link between the client and DC. If this process fails for any reason (e.g., if ICMP is blocked or restricted by the network or if the DC is unavailable over ICMP), then Group Policy processing fails. Additionally, the calculation used for slow link detection was relatively crude and often resulted in a slow link being detected for no good reason.
In an effort to improve this process, Group Policy now leverages the new version of the Network Location Awareness (NLA) service provider that ships with Vista and Server 2008. NLA checks whether the DC is available and, if it is, determines the speed of the network link between client and DC. It uses robust protocols, such as remote procedure call (RPC), instead of the relatively simple and often-blocked ICMP. This results in better slow link detection and the ability to quickly determine whether a DC is available. As it turns out, whether or not a DC is available constitutes a very important factor in the next new feature I’ll talk about, namely the NLA-based refresh of Group Policy.
NLA Background
Refresh
In addition to using NLA to improve slow link detection, the Group Policy engine relies on NLA to improve the background Group Policy update process. In Windows versions up to and including Vista and Server 2008, a background refresh occurs every 90 minutes on workstations and member servers. Plus, there’s an additional refresh of up to 30 minutes in a randomized value that ensures all systems don’t refresh at once. Say a laptop’s background refresh occurred while a user was travelling home with it on the train. Because the DC wasn’t available, the refresh would simply fail. Ten minutes later, when the user is home and has plugged into the corporate VPN, the DC is available, but depending upon when the last refresh occurred, it may be many minutes before the next Group Policy update via background refresh.
NLA provides a new kind of background refresh for Group Policy in Vista and Server 2008. If a system running one of these new versions of the Windows OS attempts to refresh Group Policy in the background and fails because the DC isn’t available, then the next time the DC becomes available, the client triggers a background Group Policy refresh as soon as NLA detects the DC. The NLA refresh appears in the new Vista Group Policy Operational log, as shown in Figure 1.
The NLA refresh can be useful when you’re trying to push out a new policy to affect some behavior on your client machines and you don’t want your users to wait for more than an hour after they get back on the network to receive the change. However, it’s important to note that this feature works only if the previous background refresh attempt failed.
Multiple Local GPOs
How many times have you wished you could set a local GPO on your Windows XP systems that wouldn’t affect administrators logging onto those systems or that applied only to a specific user on the local system? Multiple local GPOs in Vista and Server 2008 are the answer you’ve been waiting for. As the name implies, multiple local GPOs provide a way of having more than one local GPO on a given Windows system. Systems prior to Vista store the local GPO in the file system under C:\windows system32\grouppolicy. On Vista and Server 2008 systems, the default local GPO still exists in that location, but you can also create three new types of local GPOs:
- A non-administrator local GPO lets you define user-specific policy settings that apply only to any non-administrative user (such as a user who’s not a member of the local Administrators group) logging onto the computer.
- An administrator local GPO lets you define user-specific policy settings that apply only to any member of the local Administrators group logging onto the computer.
- A user local GPO lets you define user-specific policy settings that apply only to a particular local user account defined on the workstation or member server. This policy doesn't apply to domain accounts.
These new local GPOs are stored in folders based on the SID of the group or user to whom they apply, under C:\windows\system32\group policy users. In Windows OSs before Vista, Group Policy processing has an order of precedence that starts with the local GPO, then sitelinked GPOs, then domain-linked GPOs, and finally organizational unit (OU)-linked GPOs. When a user logs on, Windows applies the User Configuration portion of Group Policy. The order of precedence with multiple local GPOs on Vista and Server 2008 is
- Default local GPO
- Non-administrator or administrator local GPO (if any)
- User local GPO (if any)
- Domain-based GPOs (site, domain, and OU-linked)
How do you get to those multiple local GPOs on your Vista or Server 2008 system? Here are the steps you need to take to be able to edit the other local GPOs:
- From the Start menu, choose Run, then type mmc to launch a blank Microsoft Management Console (MMC). (Because running MMC requires elevated privileges, when User Account Control—UAC—is enabled, you’ll be prompted for credentials.)
- In MMC, choose File, Add/ Remove Snap-in and scroll down to Group Policy.
- Select Add to add that snap-in to the console, and browse to the GPO you want to edit. The default is Local Computer, which refers to the default local GPO. However, at this point, click the Browse button to see other options.
-
In the Browse for a Group Policy Object dialog box, select the Users tab. You’ll see something similar to Figure 2. At this point, you can choose a specific local user, the general administrator, or the non-administrator and click OK to load the associated local GPO into the MMC Group Policy editor (GPE) snap-in for editing.
Figure 2 is a snapshot of my system; it lists several local users, plus Administrator, Administrators, and Non-Administrators. None of these local GPOs yet exists. But if I use the above instructions to add one of them to GPE and make modifications to it, it will exist within the local file system in the C:\windows\system32 GroupPolicyUsers folder.
ADMX Templates
You might have heard that the format for Administrative Templates, or ADM files, has changed in Vista and Server 2008. ADM files create the policy options you see under the Administrative Templates nodes in GPE. ADMX files in Vista perform the same role, but you won’t be able to work with them the same way. For example, if you created custom ADM files with Notepad or your favorite text editor, you’ll find it difficult to do the same thing with the new ADMX files. That’s because Microsoft has adopted a new XML data format for ADMX files, and their partners, ADML files. (Each ADMX file puts language-dependent string references in an ADML file for that specific language.)
Continued on Page 2
It’s easiest to explain the new ADMX by looking at it side-by-side with the old ADM. Table 1 compares the two technologies.
As you can see in Table 1, there are plenty of differences between ADM and ADMX. A major difference is storage—having a central store for ADMX files versus storing the same ADM files in every GPO on every DC (the socalled “SYSVOL bloat” problem). The central store (aka central or domain-wide repository) is simply a folder called PolicyDefinitions that you create manually in the \\
I’ve created a free utility at www.gpoguy.com/cssu.htm that you can use to automate the central store creation and population process. Once the central store is created and populated, both GPE and GPMC, running from Vista or Server 2008, will recognize its existence and reference ADMX files from that location instead of locally.
Another advantage to the new ADMX format, that I alluded to earlier, is the separation of the language-specific strings in new ADML files from the portion of the template that defines the policy settings. This lets you use one set of ADMX files for each supported language, and the ADML file for your local language is used whenever you launch GPE. So, instead of having to maintain multiple, language-specific ADM files as in the past, this new format lets you easily support editing of Administrative Template policy in multiple languages.
You can convert your custom ADM files to ADMX files by using a free ADM to ADMX converter that Microsoft provides. This tool, called the ADMX Migrator, also makes creating ADMX files from scratch a cinch. For download information, see “ADMX Migrator” in the Learning Path.
Interoperability
Before I look at problems arising in the mixed environment of Vista with ADMX, and Windows XP or Windows Server 2003 with ADM, I want to emphasize that these are problems for administrators. For GPO application on clients (of whatever type), the ADM or ADMX templates aren’t relevant. The templates are used only for the administrative view of the GPOs and are for administrative tasks, such as working with specific settings. The actual settings applied via GPO are still stored in registry. pol and related files, which didn’t change in Vista and Server 2008. This means that a GPO created and managed via either Vista or Server 2008 is perfectly compatible with downlevel clients for settings they support.
Administrators need to know that XP, Server 2003, and Win2K can’t “see” ADMX files. Thus, if you create a GPO and set some Vista-specific Administrative Template policies from GPE running on Vista, then try to edit that GPO from GPE running on XP, you won’t see the Vista-specific settings because they’re in Vista ADMX files that the XP machine can’t read. A further complication is that XP and Vista don’t store their template files the same way.
Let’s take the following mixed-environment scenario. Suppose you create a new GPO on your Vista workstation. Let’s also suppose that you’ve created the central store, so all GPOs managed from Vista are referencing the ADMX files from that central location. (Remember, Vista no longer stores template files in the SYSVOL portion of each GPO.) Now you edit that new Vista GPO on your XP machine. XP looks in the SYSVOL portion of that GPO and notices that there aren’t any ADMs there, so it copies its own ADMs into SYSVOL and pollutes your brand new Vista GPO.
How can this tragic scene be avoided? I count at least three ways. First, after you introduce Vista into your environment; you can make a plan to edit GPOs only from Vista systems. This guarantees that all GPOs from that time forward will see all settings. Second, you can keep your environments separate. If you have some XP and some Vista systems, manage the GPOs that apply to XP from XP systems and the ones that apply to Vista from Vista systems. However, if you absolutely, positively must manage your Vista GPOs from downlevel systems, consider the third option, which is to enable the following policy on users who edit GPOs from XP, Win2K, and Server 2003 systems. This policy will prevent the downlevel platforms from automatically updating the SYSVOL portion of your clean Vista GPOs with ADM files every time you edit them: User Configuration\Administrative Templates System\Group Policy\Turn off automatic update of ADM files
Better Logging
A big challenge of Group Policy troubleshooting in XP and Server 2003 environments is getting useful information out of the logs generated during a Group Policy processing cycle. It’s especially true if you try to make sense of the userenv.log file, located in %WINDIR% Debug\Usermode, a cryptic text log used by both user profiles and Group Policy to log the details of their activities. The good news is that Microsoft moved away from the userenv.log file in Vista and Server 2008. GPO processing now runs outside of Winlogon and leverages its own service. So instead of the userenv.log file, detailed trace information about Group Policy processing is found in the Group Policy Operational log. This log, shown in Figure 3, contains step-by-step detail of Group Policy processing on a given system.
You can locate the Group Policy Operational log in the new Event Viewer by expanding the Applications and Services Logs node and then clicking Microsoft, Windows, GroupPolicy, Operational. Note that the new eventing system (codenamed Crimson) in Vista and Server 2008 allows you to do interesting things such as forward specific events to a central collection point (called subscribing to events) or create filtered views of specific events. In addition to the Event Viewer, Microsoft has provided a free command-line tool called GPLogView that lets you output Group Policy Operational log events to text or HTML files. For download information, see “Group Policy Log View” in the Learning Path. If you like writing code, you can download the source code for GPLogView and contribute changes and enhancements to it at www.codeplex.com/gplogview.
New Policy Areas
In addition to all the core changes to Group Policy in Vista and Server 2008, Microsoft has added some new configuration capabilities. I don’t have room to discuss them all here, so I’ll just highlight some of the more interesting ones.
Deployed printers. In a move that’s similar to providing the printer deployment capability in Server 2003 R2, Microsoft has finally made deployed printers full citizens in the Group Policy world. Vista and Server 2008 systems can process either per-computer or per-user deployed printer definitions to allow you to map printers for computers and users within Group Policy. (Note that this capability can also be leveraged by XP or Server 2003 systems, but the mechanism to trigger evaluation of the printer policies via startup/logon script is different.) This capability requires an AD schema update if you’re not running the R2 (or later) version of the AD schema. The LDAP Data Interchange Format (LDIF) schema files that support this feature (and others) can be found on the Vista CD-ROM in the sources\adprep folder. If you’re running the Server 2008 AD schema, then these additions are already included. Deployed Printers are located within the Group Policy namespace under Computer (or User) Configuration\Windows Settings Deployed Printers.
Power management. Vista and Server 2008 finally let you control power management features via Group Policy. These include choosing the default power plan for a system and configuring every aspect of when a system sleeps, hibernates, or shuts down. You can find most of the power configuration options at Computer Configuration\Administrative Templates\System\Power Management, but you can also set a per-user option to require a password when a system comes out of hibernation or standby by setting the policy at User Configuration\Administrative Templates System\Power Management.
Continued on Page 3
New security policies. Vista and Server 2008 adds quite a few new security policy capabilities to the mix. Several are highlighted here:
• Wired and Wireless Policy—New for Vista and Server 2008 is the support for setting wired network security policy. Wired policy applies to Ethernet network links and lets you enforce 802.1x usage on those links for machines on your network. Wireless policy updates the policy supported in XP and provides new support for enhanced encryption schemes, such as Wi-Fi Protected Access 2 (WPA2), as well as the ability to explicitly deny or allow access to certain Service Set Identifiers (SSIDs). (Note that some of these capabilities are available only to Vista and Server 2008 systems.) Find the Wired and Wireless Policy in Group Policy under Computer Configuration\Windows Settings\Security Settings.
• Windows Firewall with Advanced Security— This new area within Group Policy is actually a redesign of two previously supported policy areas—IPsec and Windows Firewall. The new UI makes it simpler for you to define Windows Firewall exceptions as well as implement IPsec filtering on your network. Older IPsec and Windows Firewall policy settings are still available for backward compatibility, but you should use this new Group Policy area to control network security on your Vista and Server 2008 devices. Find this capability in Group Policy under Computer Configuration\Windows Settings\Security Settings.
• Network Access Protection (NAP)—This policy area supports the new NAP features in Server 2008 and lets you use Group Policy to configure client NAP behavior on your network. Find this capability in Group Policy under Computer Configuration Windows Settings\Security Settings.
Device restrictions. Device restriction support, and the ability to manage it via Group Policy, is probably one of the more compelling features for deploying Vista. The Device Restrictions policy in GPE lets you control access to any number of removable storage devices. Not only can you control which devices can be used, but you can also specify whether a user can read or write from a removable device. Figure 4 shows the options that are available for this policy area. You can set this policy either per-computer or per-user and you can find it under Computer (or User) Configuration\Admin istrative Templates\System Removable Storage Access.
GPMC Changes in Server 2008
There are a number of new GPMC changes coming in Server 2008. You’ll be able to search through Administrative Template settings within GPOs for, among other criteria, all enabled or disabled policies with a certain keyword in the policy, for Explain Text, for the Supported OS tag, or for whether the policy is managed or is a “preference.” You can also use search filters to filter the view of settings that appear in GPE.
The ability to create per-GPO and per-setting comments is also new. Those comments are stored with the GPO and provide a way for you to let others know what a particular GPO or setting is used for.
Now you’ll have the ability to provide new Starter GPOs. Starter GPOs are really collections of Administrative Template settings that you can apply to live GPOs. Starter GPOs let you create, for example, a group of Administrative Template settings for desktop lockdown that you can re-use whenever you create a new desktop lockdown GPO. Note that Starter GPOs support only Administrative Template policy but provide a quasi-offline capability for defining GPO settings that aren’t immediately live. You can also include Starter GPOs in Resultant Set of Policy (RSoP) modeling calculations so that you can see the impact that applying a Starter GPO to an existing live GPO has on your users and computers.
Microsoft added a very important set of new policy capabilities called Group Policy preferences in time for the release of Server 2008. Group Policy preferences is the name given to the former DesktopStandard PolicyMaker Standard Edition and PolicyMaker Share Manager products that Microsoft acquired in 2006. These new Group Policy extensions supply the missing link for providing coverage of almost every desktop and server configuration scenario imaginable. Group Policy preferences supports clients from XP forward and adds new Group Policy features such as support for mapped drives (without having to write scripts), distribution of shortcuts, power management, device restrictions, and local user and group management, to name just a few.
Time to Upgrade?
Overall, Vista and Server 2008 add some truly compelling features to the manageability and capability of Group Policy as the configuration management technology for Windows. Finally, you can map printers, manage power settings, and control removable storage access natively in Windows. These are all features that used to require third-party products to manage. The catch, of course, is that you need to upgrade your clients to Vista to take advantage of some of these desktop features. Even so, Group Policy still doesn’t provide all of the features you need. For example, you still need to purchase a product like Microsoft’s Advanced Group Policy Management in order to get change management for your Group Policy environment, and Group Policy still has no built-in enterprise reporting capability.
That said, if you are looking for justification to upgrade, the cost savings and risk mitigation that the many new features provide might be enough. In any case, these new features show that Microsoft is committed to making Group Policy an important part of your Windows management toolset.
