Отличная статья Джереми Московица о Group Policy в Windows 7 и Windows Server 2008 на родном всем компьютерщикам английском языке.
What’s New in Group Policy for Windows 7 and Windows Server 2008 R2
Jeremy Moskowitz
At a Glance:
- Updated RSAT filters
- Automated GPO handling with Windows PowerShell
- Tabless interface for ADM and ADMX
- Built-in Starter GPOs and new policy settings
Contents
Updated Group Policy Core Features
Beyond the Core Features
Learn More
I get e-mail almost every day from people asking me, "What's coming for Group Policy in the new version of Windows?" In this question, I can feel an eagerness to know what the new features and changes will mean for IT professionals.
I know that change can sometimes be stressful, but I can say confidently that the news is all good: Some powerful, neat Group Policy changes are included in Windows 7 and Windows Server 2008 R2, but nothing too radical or different. IT professionals will benefit from some updates, some new features and some user interface tweaks, for example, but without the headaches associated with steep learning curves.
The Group Policy changes can be divided into two broad categories. First are the items the Group Policy team delivers: core functionality, including the Group Policy engine and new and updated features in the Group Policy editing system (Group Policy Management Console, or GPMC, and Group Policy Management Editor, or GPME). Second are items that other teams provide to manage their components using Group Policy: updated policy settings and feature controls inside GPME that we all use to manage the new and updated functions on our target machines. In this article, I cover both kinds of changes.
Updated Group Policy Core Features
For Windows 7 and Windows Server 2008 R2, the Group Policy team has come through with a smorgasbord of features and updates. Here's the nonscientific breakdown of what is delivered in the most recent update of Windows: one big fix, one big update, one big new feature, one big user interface change and one big in-the-box addition.
The Big Fix: Updated Filters
The updated filters in the updated GPMC (available for Windows 7 and Windows Server 2008 R2) are welcome changes. The fixes squash a bug that's been around since Windows Vista shipped. In Figure 1, you can see one of my favorite features that's been available since the updated GPMC, contained within the Remote Server Administration Toolkit (RSAT): the Filter Options dialog box.
Figure 1 Filter Options dialog box. (Click the image for a larger view)
RSAT's job is simple: to let you use a Vista (or later) machine to control various aspects of your network from the machine you use and to provide the tools you need to do so, including the updated GPMC. This updated GPMC has some neat features; one of them is the ability to use filters to define the criteria you want to use to find just the Administrative Templates Group Policy settings you want. The problem was that when Vista and its corresponding RSAT came out, the filters didn't work, a bug that plagued many administrators.
Let me explain the bug in a little more detail. Figure 1 shows the Enable Requirements Filters section of the Filters dialog box. The goal of this section is simple: to help you figure out which Administrative Templates policy settings are valid for specific operating systems.
One mode within Enable Requirements Filters is "Include settings that match all of the selected platforms." The other is "Include settings that match any of the selected platforms. At first glance, the two modes seem very similar. But the difference between "all" and "any" is substantial. Here is what each mode is supposed to do once you select it and specify some criteria:
- "Include settings that match all of the selected platforms" should show policy settings that are valid only on the types of machines specified. So if you select Windows XP Service Pack (SP) 2 and Vista, the result should be policy settings that work only on Windows XP SP2 and Vista.
- "Include settings that match any of the selected platforms" should show settings that apply to any of the selected operating systems. So if you select both Windows XP SP2 and Vista, all settings that apply to Windows XP SP2 and all settings that apply to Vista should be displayed.
These filters are both as useful as they sound. The only problem is that with the Vista and Windows Server 2008 version of RSAT, neither of them worked properly. If you selected "Include settings that match all of the selected platforms," the result was often a mere fraction of valid settings that were actually applicable to target machines. And if you selected "Include settings that match any of the selected platforms," no results were ever displayed.
According to my friends in the Group Policy team, this fix should be part of the final downloadable version of RSAT for Windows 7 and the in-the-box RSAT for Windows Server 2008 R2.
The Big Update: Deploying Windows PowerShell Scripts to Target Machines
Unless you're living under a rock, you know that Windows PowerShell is gaining popularity with system administrators. But one issue has blocked some administrators from adopting PowerShell. There hasn't been a simple way for them to leverage their newfound PowerShell muscle over an area in which they need the most control: user and computer scripts.
The RSAT in Windows 7 and Windows Server 2008 R2 allows administrators to specify PowerShell scripts as either logon or logoff scripts (for the user) and startup or shutdown scripts (for the computer). Figure 2 shows the Startup Properties dialog box in the GPME, in which the administrator can specify the order in which PowerShell scripts run and also which type of scripts should run first: PowerShell scripts or the non-PowerShell scripts (which are not shown but are located within the Scripts tab in the Startup Properties dialog box).
Figure 2 Windows PowerShell Scripts tab in the Startup Properties dialog box. (Click the image for a larger view)
To use this feature, you need to create or edit your Group Policy Objects (GPOs) from a Windows 7 or Windows Server 2008 R2 machine with the corresponding RSAT tools (which contain an updated GPMC to support this new functionality). In addition, the target machine must be Windows 7 or Windows Server 2008 R2 for the PowerShell scripts to run. Older machines (even with PowerShell loaded) are not valid targets and do not run PowerShell logon, logoff, startup or shutdown scripts. Some third-party solutions that can deploy PowerShell scripts to non-Windows 7 machines are available if you need this capability.
The Big Feature: Manipulating Registry Settings with PowerShell Cmdlets
Lots of system administrators like to automate their world. This a good thing. Indeed, you can think of leveraging Group Policy in your environment as the mass automation of your client machines (so you don't have to run around and push buttons). To take your administration to the next level, you might want to automate the handling of your GPOs themselves.
Some administrators have leveraged the existing Group Policy GPMC sample scripts to automate key Group Policy tasks.
Windows 7 and Windows Server 2008 R2 allow you to use PowerShell to perform many of these functions. What was possible in the GPMC sample scripts is now possible using PowerShell: creating, linking, renaming, backing up, copying and deleting GPOs as well as much more.
The ability to configure the contents of a GPO using a scriptable method, however, is totally new and now available only when you use PowerShell as your scripting method. Before you get too excited, I should mention that not all 39 areas of Group Policy are scriptable. Indeed, only two are: Registry Policy and Registry Preference. Even so, it's a terrific start.
In Figure 3, you can see how I'm using the built-in PowerShell in Windows 7 to first install the Group Policy-specific cmdlets using the cmdlet import-module grouppolicy and then create a new GPO with the new-gpo cmdlet.
Figure 3 Creating a new GPO using Group Policy cmdlets built into Windows 7. (Click the image for a larger view)
The Group Policy team's blog has an array of items regarding Windows PowerShell integration. You can view all of them at one glance by checking out the the Group Policy Team Blog.
The Big User Interface Change: Updated ADM and ADMX User Interface
One of the most striking Group Policy changes is in the Administrative Templates section of the GPME.
A new "tabless" interface, shown in Figure 4, puts all the content you need for creating new or manipulating existing policy settings in a one-stop-shop page.
Figure 4 Windows Firewall: Allow ICMP Exceptions dialog box. (Click the image for a larger view)
Administrators can now configure a policy setting as Not Configured, Enabled or Disabled, make comments about a policy setting, see the Supported On information, view the Help (Explaintext), and manipulate any configurable settings within Options.
The goal of this change is to make the policy-setting experience more intuitive, integrate help and take away all the tabs so administrators don't have to click from place to place anymore.
The Big In-the-Box Addition: Built-in Starter GPOs
The ability to create and use Starter GPOs first became available in the Vista version of the GPMC. The idea behind a Starter GPO is that an administrator can create a starting point for other administrators to use when creating their GPOs. The fundamental architecture and functionality hasn't changed much in this new update, but one new distinction is notable.
Specifically, when you use a Windows 7 or Windows Server 2008 R2 machine to create the Starter GPO's container, the container is automatically populated with some built-in Starter GPOs. These Starter GPOs follow Microsoft best practices and map to the Windows Server 2008 Security Guide. For example, one of these built-in Starter GPOs is for an average Enterprise Client (EC) and another, with a more locked-down approach, is called Specialized Security Limited Functionality (SSLF).
Windows 7 and Windows Server 2008 R2 include Starter GPOs for both the user and computer sides. These Microsoft-created Starter GPOs are also available (in slightly older form) for Vista and Windows XP SP2.
Beyond the Core Features
Now let's talk about some of the areas of additional control you get when you're working with Windows 7 or Windows Server 2008 R2 as a client. And when I say "client" here, I mean "the computer receiving Group Policy directives" (even if it's a Windows Server 2008 R2 machine).
One great addition is about 300 new policy settings, of which 90 or so are meant just for Internet Explorer 8 (which is available for Vista and Windows XP machines). Other changes include new and updated settings management for BitLocker, BitLocker To Go, an updated taskbar, Remote Desktop Services (which used to be called Terminal Services), BranchCache, Windows Remote Management (WinRM) and heaps of other controls. I won't be able to explore all the new controls in this article, but I will give you an up close and personal look at some of my favorites.
Updated Group Policy Preferences for Power Options
One of the key reasons IT geeks fall in love with Group Policy is the amount of control it allows them to exert on desktops. When the main focus of Group Policy is settings delivery, however, these control-freak IT geeks can sometimes have difficulty explaining to managers why Group Policy has value in raw "dollars and sense." In one area of Group Policy, though, real cost savings can be promised (if utilized properly): power settings.
By properly configuring the power settings of desktops and laptops, IT administrators can usually save their companies thousands of dollars annually. Group Policy makes such configuring easy.
Figure 5 shows the power options available in the Windows 7 (and Windows Server 2008 R2) GPMC.
Figure 5 New Power Plan (Windows Vista and later) Properties dialog box. (Click the image for a larger view)
Look closely at the title of the dialog box in Figure 5. You'll notice that it says New Power Plan (Vista and later) Properties. That is to say, these settings are valid for both Vista and Windows 7. Here's the caveat: Windows 7 and Windows Server 2008 R2 client machines will know what to do with these directives right away; Vista will not. Vista will simply ignore the directives (even though the feature is clearly labeled as Windows Vista and later). That's because Vista needs a soon-to-be-released update to the client-side extensions of its underlying Group Policy Preferences. Once available and applied, Vista machines will embrace these newly available directives.
Updated Group Policy Preferences for Scheduled Tasks
Similar to the updated Power Plan settings just mentioned is additional task-scheduling functionality within the GPMC in Windows 7 and Windows Server 2008 R2. Figure 6 shows the new options for scheduling tasks: Scheduled Task (Windows Vista and later) and Immediate Task (Windows Vista and later).
Figure 6 New GPMC task-scheduling options in Windows 7. (Click the image for a larger view)
Like the Power Plan settings, Windows 7 computers are ready to use these settings. Vista machines will need to wait for an update that will allow them to utilize these settings.
Updated Software Restriction Policies: AppLocker
The under-the-hood name for AppLocker is Software Restriction Policies version 2, or SRPv2. In the Group Policy interface (and in the documentation), however, you'll see this new feature called simply AppLocker.
Briefly, the goal of AppLocker is to help modern IT organizations dictate which software should and shouldn't run on their Windows 7 (and later) machines. The original Software Restriction Policies (SRP) did a decent job, but AppLocker takes software restrictions to the next level. One key new AppLocker ability is to allow or restrict software based on the software's publisher. To take advantage of this new feature, the software you want to allow or restrict must be digitally signed (for more information on AppLocker, see Greg Shields' Geek of All Trades column, "AppLocker: IT's First Panacea?").
Then, using the Create Executable Rules Dialog Box, you set up rules for various publishers. For example, you can create a rule specifying that it's OK to run Adobe Reader as long as the version is 9.0 or higher. You can move up the vertical slider to specify that all versions, filenames, and/or products or publishers can be valid on target systems. Or you can be specific with the Use custom values check box.
Learn More
As you can see, Windows 7 and Windows Server 2008 R2 bring a lot of enhancements to Group Policy. From the 300 new policy settings, to the two updated Group Policy Preferences, to the integration of Windows PowerShell—there's a lot to love. To learn more about Group Policy in Windows 7 and Windows Server 2008 R2, you can check out the Group Policy team blog, as well as my blog and training resources at GPanswers.com.
Jeremy Moskowitz is a Group Policy MVP. He runs GPanswers.com, a community forum for Group Policy, and trains hundreds of administrators each year in his Group Policy Master Classes. Jeremy is also founder of PolicyPak Software (PolicyPak.com), which makes an innovative add-on to control third-party applications using Group Policy.
