Windows Vista and Server 2008 Group Policy Enhancements

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
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.

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

   Previous  [1]  2  3  Next