New features for GPOs and GPMC
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.
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 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.
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
1. Default local GPO
2. Non-administrator or administrator local GPO (if any)
3. User local GPO (if any)
4. 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:
1. 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.)
2. In MMC, choose File, Add/ Remove Snap-in and scroll down to Group Policy.
3. 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.
4. 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.
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.
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
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.
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.
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.
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.