New features are more evolutionary than revolutionary
With the release of Windows Server 2008 came Group Policy preferences, a set of more than 20 Group Policy extensions that expanded the range of configurable settings within a Group Policy object (GPO). Following that game-changing release, you might expect new Group Policy features of a similar nature in Windows Server 2008 R2 and Windows 7. Unfortunately, most of what you’ll see, and what I discuss in this article, are incremental improvements rather than game changers.
That being said, Microsoft did manage to incorporate one major change in Server 2008 R2 and Windows 7 by taking the first tentative steps toward automating Group Policy management using PowerShell. The rest of what you’ll find new in the latest Windows release is mostly updates to existing policy areas, some additional Windows components under Group Policy management, and some improvements to Group Policy preferences. Let’s look at the changes in depth.
Administrative Template Changes
The major news in Administrative Templates, or registry policy, occurred when Windows Vista shipped. With Vista, Microsoft introduced a new ADMX format and the Central Store. The ADMX format provided better multilanguage support; the Central Store took old ADM files out of the SYSVOL part of every GPO. With Server 2008 R2 and Windows 7, the greatest change in this area is the addition of yet more Administrative Template settings (more than 300). These settings cover a bevy of new Server 2008 R2 and Windows 7 features (e.g., policies to control new UI elements specific to each platform—see Figure 1). You'll find a full list of Administrative Template and Security policy settings in Excel format in Microsoft’s “Group Policy Settings Reference for Windows and Windows Server” (www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=18c90c80-8b0a-4906-a4f5-ff24cc2030fb).
One of the more subtle changes to Administrative Templates is a modified ADMX schema that now supports two new registry value types: REG_MULTI_SZ and REG_QWORD. Previously, you couldn't use Administrative Templates to modify these two value types. Your choices were to deliver these kinds of values via registry scripts, or to use the Group Policy preferences’ registry extension to get these value types on client machines. Now these types are supported in the ADMX syntax, and you can create custom ADMX templates that support these new types.
Another subtle Administrative Templates change is a UI improvement. In Server 2008 and Vista, Microsoft introduced the concept of Comments to Administrative Template settings. If you chose to, you could add comments to each policy setting. These comments, and the improved Explain text that provided help for each setting, were displayed as three separate tabs within Group Policy Editor’s (GPE’s) UI. You had to flip between each tab to use them. In Server 2008 R2 and Windows 7, all three elements are presented on a single pane that you can easily see and edit, as Figure 2 shows.
PowerShell Support
The major change in this release of Windows that I alluded to earlier is added support for PowerShell within the Group Policy universe. Microsoft added support for running PowerShell scripts within per-machine or per-user scripts policy and provided a set of 25 PowerShell cmdlets for PowerShell 2.0 that support many of the operations you can perform within Group Policy Management Console (GPMC). Let’s look first at the new scripts policy support.
When you create a new startup script or logon script in GPE, you'll see a new tab. As Figure 3 shows, you can now add PowerShell scripts to your scripts policy and control whether the scripts run before or after non-PowerShell scripts. But note that only Server 2008 R2 and Windows 7 Group Policy clients will run these new PowerShell-based script policies. They won’t work on earlier versions of Windows.
Perhaps the more interesting of the PowerShell enhancements is a set of cmdlets within a new PowerShell 2.0 module for Group Policy. These cmdlets encapsulate many of the functions found within the GPMC sample scripts that used to ship with that tool. From the PowerShell cmdlets, you can perform Group Policy–related administrative tasks such as creating new GPOs or deleting existing ones, linking GPOs to OUs or domains, and repermissioning GPOs. Figure 4 shows the full list of cmdlets exposed in the new module, called GroupPolicy, that ships with the Remote Server Administration Tools (RSAT) feature in Server 2008 R2 and Windows 7.
Note that to use the GroupPolicy module, you must be running PowerShell 2.0 on Server 2008 R2 or Windows 7. To provide this kind of GPMC PowerShell functionality on earlier versions of Windows, I've written a set of GPMC PowerShell 1.0 cmdlets that you can download for free at my website (www.sdmsoftware.com/freeware).
Let’s look at an example of the kind of power these new cmdlets provide. Suppose you want to create, permission, and link a GPO within a PowerShell script. The following one-line command does all that by leveraging three of the new cmdlets and the PowerShell pipeline:
new-gpo "Marketing IT GPO" | Set-GPPermissions -TargetName "Marketing Users" -TargetType Group -PermissionLevel GPOEdit | new-gplink -order 1 -Target "OU=Marketing, DC=cpandl,DC=com"
In this example, I’m using three cmdlets—New-GPO, Set-GPPermissions, and New-GPLink—to create the GPO called Marketing IT GPO, to modify the GPO’s permissions to grant the Marketing Users Active Directory (AD) security group rights to edit the GPO, and to link the GPO to the Marketing OU in my cpandl.com AD domain. All of this was done in one command using the PowerShell pipelining capability to pipe the output of one command to the next one. Using PowerShell and the GroupPolicy module makes it easy to perform complex Group Policy management tasks.
Modifying Registry Policy with PowerShell
GPMC functions aren’t all that Microsoft put into the GroupPolicy module. Also added is basic support for modifying a small subset of the settings within a GPO. Before I describe what Microsoft has done, let me provide a little background. Currently, you have two ways in Group Policy to push out registry values. The primary way to manage registry settings in Group Policy, which we’ve had forever, is through the use of Administrative Templates policy. Administrative Templates use ADM or ADMX template files to build the UI in GPE that describes which registry values can be managed via Group Policy, and they also provide the help text that describes what a policy setting does. When you set Administrative Template policies in GPE, the policy settings that you define are stored within the SYSVOL portion of the GPO in a file called registry.pol. This file holds the instructions for the registry values you want to deploy in the GPO.
The other method for managing registry values is Group Policy preferences registry extension. This method is more flexible than Administrative Templates policy, and it provides the more granular targeting features that come with Group Policy preferences. Both methods will let you manage registry changes centrally, and each method has its strengths.
What Microsoft provided in Server 2008 R2 and Windows 7 with respect to PowerShell support is the ability to modify GPO settings for both of these registry methods. In the first case, you now have the Get-GPRegistryValue, Set-GPRegistryValue, and Remove-GPRegistryValue cmdlets to retrieve and modify the underlying registry.pol file that is used by Administrative Templates policy to store its settings. The advantage of using these cmdlets to modify Administrative Templates policy is that you don’t need to create a custom ADM file to populate a particular registry value. Because these cmdlets don't rely on ADM or ADMX files, but instead let you push registry values into the underlying storage file, you can quickly push a new registry value into a GPO.
The downside is that this approach doesn't rely on ADM or ADMX files to define which registry values you're using; you have to know the underlying registry key and value you want to deploy. In addition, if you view a GPO that uses this method to configure a registry setting policy—and there is no underlying ADM or ADMX file representing that setting—the GPMC settings report will show it as Extra Registry Settings. If you bring up GPE, you won’t see the registry value that you've pushed into that registry.pol file. Obviously, going overboard with this approach can cause confusion. I don’t recommend relying on this approach for all your Administrative Template changes, but in a pinch it might come in handy.
The second PowerShell approach for registry policy involves the ability to read and modify settings in the Group Policy preferences Registry extension. Microsoft ships the Get-GPPrefRegistryValue, Set-GPPrefRegistryValue, and Remove-GPPrefRegistryValue cmdlets for this purpose. These three cmdlets let you manage new Group Policy preferences registry settings (note that you can't use these cmdlets to modify existing Group Policy preferences registry policy). As an example, let’s see how you can use these cmdlets to add a new registry value to a Group Policy preferences registry setting. The following example command populates the mouse beep value within a GPO called Test:
Set-GPPrefRegistryValue -Name Test -Context User -Action Create -Key "HKEY_CURRENT_USER\Control Panel\Mouse" -Valuename "Beep" -Value "Yes" -Type "String"
Note that in this command, you have to specify the registry key, valuename, value, and type to successfully populate the Group Policy preferences setting. What these cmdlets don’t provide is access to some of the more advanced features within Group Policy preferences, such as the items you see on the Common tab, and item-level targeting (the ability to granularly target preference settings). However, cmdlets are a good start toward providing Group Policy automation.
Starter GPOs—Does Anyone Care?
In Server 2008 and Vista, Microsoft introduced the notion of Starter GPOs—templates of GPOs that you could use to create real GPOs. The idea was sound, but the execution was lacking. The problem with Starter GPOs is that they support only Administrative Template policy settings, severely limiting the kinds of templates you can create. What Microsoft did in Server 2008 R2 and Windows 7 is only a small improvement over what was previously shipped. Basically, you now have the ability to prepopulate the Starter GPOs with the Windows Server 2008, Vista, and Windows XP SP2 security guideline settings that were previously provided via the so-called GPO Accelerators.
Of course, because Starter GPOs support only Administrative Templates settings, and not security settings (which are the main focus of the security guideline settings), these prepopulated Starter GPOs are relatively useless. But if you need to create templates of Administrative Templates settings that you can reuse to create real GPOs, then Starter GPOs are for you.
New Policy–Enabled Features
The last of the changes I'll cover are the new policies that have been added to support management of new features available in Server 2008 R2 and Windows 7. Most of the new policies relate to security settings, but a few minor updates have been made to Group Policy preferences as well. Let’s start with the new Group Policy preferences:
New Security Policies
The biggest new addition in the area of Group Policy–based security policy is the Application Control Policies, or AppLocker. These policies are found under \Computer Configuration\Windows Settings\Security Settings\Application Control Policies. Essentially, this is a significant upgrade to the old Software Restriction Policies (SRPs—which are still supported in Server 2008 R2 and Windows 7) that let you control which applications can execute on your Windows systems. Specifically, AppLocker lets you create application whitelists and blacklists to explicitly allow or deny a particular application or set of applications to execute based on a set of criteria you specify.
A major difference between what’s available in AppLocker and SRPs is that you now have more flexible rules for defining applications. As Figure 5 shows, for example, you can create rules by software publisher, application name, and version information held within the file.
You can also create rules for controlling script execution, which wasn’t explicitly supported in earlier Windows versions. Also, for each type of rule you create, you can enforce the rule or just work in audit mode. In audit mode, whenever a rule is hit by an application, the result is logged to the client rather than blocking or allowing that application. That way, you can run a rule in test mode before making it live, to ensure it doesn’t catch any unsuspecting applications. The only downside to AppLocker is that it works only on Server 2008 R2 and Windows 7 clients, so you can’t leverage it in earlier versions of Windows.
Advanced Audit Policy
Another security-related feature that you'll find in Server 2008 R2 and Windows 7 is a much more granular auditing infrastructure. If you look under \Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration, you'll see 10 different auditing categories that you can now tweak to control exactly which types of events generate security audits on Server 2008 R2 or Windows 7 systems. This new granularity, of course, is exposed only in these newest OS versions, but the fact that it's manageable via Group Policy is a good thing.
Network List Policies
The last new security policy I'll discuss gives you the ability to control network lists. By default, when Server 2008 R2, Windows 7, or Vista systems find new networks, whether public wireless networks or corporate LANs, a user is prompted to indicate the type of network it is (e.g., public, domain, home). But by using Network List Policies in Group Policy, you can now preconfigure how particular networks behave and which zone they should be shunted into when a user finds them.
You can also control the icons and the names of the networks that appear to the user. The only downside to using this policy area for preconfiguring wireless access points is that you need to know the name of the WAP ahead of time to configure all the various options. But this policy area is still a welcome addition for controlling users who frequently roam between networks.
Name Resolution Policy
The last new policy area, although not strictly a security policy (it’s found under \Computer Configuration\Windows Settings\Name Resolution Policy in GPE), lets you control DNS Security Extensions (DNSSEC) and Microsoft DirectAccess DNS configurations on a per-DNS domain name basis. For example, you can configure which features of DNSSEC are used for a given client talking to its DNS server, or which DNS and proxy servers a client connecting to your network via DirectAccess will use. Although not used by all shops, this feature is handy to have in Group Policy if you're rolling out DirectAccess to your mobile users.
Evolutionary, Not Revolutionary
The Group Policy improvements in Server 2008 R2 and Windows 7 are very much evolutionary rather than revolutionary. With the possible exception of adding some PowerShell automation support for Group Policy management, this is a very ho-hum release for Group Policy fans. Sadly, we'll have to wait a while longer to see the big architectural or functional improvements that users of this more than 10-year-old technology have been looking for.
But if you're planning to roll out Windows 7, there are enough new features to make your life easier when you’re configuring clients. I encourage anyone who hasn't started using PowerShell to dive in and check out what you can do with Group Policy and this new scripting technology.