Windows Group Policy: Deploying Group Policy

• Keeping Group Policy Up to Date

• Applying and Linking Group Policy Objects

• Using Default Policies

• Using Policy Preferences and Settings

Group Policy provides a convenient and effective way to manage both preferences and settings for computers and users. With Group Policy, you can manage preferences and settings for thousands of users or computers in the same way that you manage preferences and settings for one computer or user—and without ever leaving your desk. To do this, you use one of several management tools to change a preference or setting to the value you want, and this change is applied throughout the network to the subset of computers and users you target.

Previously, making many of the administrative changes that Group Policy enables was possible only by hacking the Windows registry, and each change had to be made individually on each target computer. With Group Policy, you can simply enable or disable a policy to tweak a registry value or other preference or setting, and the change will apply automatically the next time Group Policy is refreshed. Because changes can be modeled through the Group Policy Management Console before the modifications are applied, you can be certain of the effect of each desired change. Prior to deploying a change, you can save the state of Group Policy. If something goes wrong, you can restore Group Policy to its original state. When you restore the state of Group Policy, you can be certain that all changes are undone the next time Group Policy is refreshed.

Before you deploy Group Policy for the first time or make changes to existing policy, you should ensure you have a thorough understanding of:

• How Group Policy has changed with the introduction of each new version of the Windows operating system.

• How you can update Group Policy to include the preferences and settings available in a new Windows operating system.

• How Group Policy is applied to a local computer as well as throughout an Active Directory environment.

• How default policy sets are used and when default policy applies.

• When to use policy preferences and when to use policy settings.

I discuss each of these subjects in this chapter.

Keeping Group Policy Up to Date

Group policies were introduced with Windows 2000 and apply only to systems running workstation and server versions of Windows 2000 and later. This means Group Policy applies only to systems running Windows 2000, Windows XP Professional, Windows Vista, Windows Server 2003, Windows Server 2008, and later versions of Windows. Each new version of the Windows operating system has brought with it changes to the way Group Policy works, and I’ll explore important changes in this section.

Core Process Changes

Unlike Windows 2000, Windows XP Professional, and Windows Server 2003, Windows Vista and Windows Server 2008 use the Group Policy Client service to isolate Group Policy notification and processing from the Windows logon process. Separating Group Policy from the Windows logon process reduces the resources used for background processing of policy while increasing overall performance and allowing delivery and application of new Group Policy files as part of the update process without requiring a restart.

Windows Vista and Windows Server 2008 don’t use the trace logging functionality in Userenv.dll and don’t write to the Application log. Instead, they write Group Policy event messages to the System log. Additionally, the Group Policy operational log replaces Group Policy trace logging events that previously were logged to %SystemRoot%\Debug\Usermode\Userenv.log. Thus, when you are troubleshooting Group Policy issues, you’ll use the detailed event messages in the operational log rather than the Userenv log. In Event Viewer, you can access the operational log under Applications And Services Logs\Microsoft\Windows\GroupPolicy.

Windows Server 2008 uses Network Location Awareness instead of ICMP protocol (ping). With Network Location Awareness, a computer is aware of the type of network to which it is currently connected and can also be responsive to changes in the system status or network configuration. By using Network Location Awareness, the Group Policy client can determine the computer state, the network state, and the available network bandwidth. This change also allows Group Policy to be refreshed over Virtual Private Network (VPN) connections.

Policy Changes

Each new version of the Windows operating system introduces policy changes. Sometimes these changes have made older policies obsolete on newer versions of Windows. In this case the policy works only on specific versions of the Windows operating system, such as only on Windows XP Professional and Windows Server 2003. Generally speaking, however, most policies are forward compatible. This means that policies introduced in Windows 2000 can, in most cases, be used on Windows 2000, Windows XP Professional, Windows Server 2003, Windows Vista, and Windows Server 2008. It also means that Windows XP Professional policies usually aren’t applicable to Windows 2000 and that policies introduced in Windows Vista aren’t applicable to Windows 2000 or Windows XP Professional.

If a policy isn’t applicable to a particular version of the Windows operating system, you can’t apply it to computers running those versions of the Windows operating system. You will know if a policy is supported on a particular version of Windows because this is stated explicitly whenever you are working with a preference or setting.

Like Group Policy, the Group Policy Management Console (GPMC) has changed with new versions of Windows. GPMC version 1.0 worked with Windows XP and Windows Server 2003. The original Windows Vista release included GPMC version 1.5. When you install Service Pack 1 (SP1) on Windows Vista, GPMC version 1.5 is uninstalled. When you install the Remote Server Administration Tools (as discussed in Chapter 1) and select GPMC as a tool you want to use, you install GPMC version 2.0. GPMC version 2.0 is also the version included with the original release of Windows Server 2008.

When you start using GPMC 2.0 or later in your domain environment, you should stop using previous versions of GPMC because GPMC 2.0 and later have been updated to work with new features and file formats that can only be managed using GPMC 2.0 or later. Because of this, you can only manage Windows Vista and Windows Server 2008 policies from computers running Windows Vista, Windows Server 2008, or later versions.

On a computer running Windows Vista, Windows Server 2008, or later versions, you’ll automatically see the new features and policies as well as standard features and policies when you use GPMC 2.0 or later to work with Group Policy. However, the new features and policies aren’t automatically added to Group Policy objects (GPOs). Don’t worry—there’s an easy way to fix this, and afterward you’ll be able to work with new features and policies as appropriate throughout your domain.

To push new features and policies into the domain, you need to update the appropriate GPOs. Once you make the update, compatible clients are able to take advantage of the enhanced policy set, and incompatible clients simply ignore the settings they don’t support.

You update a GPO for new features and policies by following these steps:

1. Log on to a computer running Windows Vista or a later release of Windows using an account with domain administrator privileges.

2. Open the Group Policy Management Console (GPMC) by clicking Start, pointing to Administrator Tools, and then selecting Group Policy Management.

3. In the GPMC, you’ll see a Forest node representing the current forest to which you are connected (see Figure 2-1). When you expand the Forest node, you’ll then see the Domains and Sites nodes. Use these nodes to work your way to the Group Policy object (GPO) you want to work with.

   

   Figure 2-1. Group Policy Management Console connects to the local forest by default.

4. When you find the GPO you want to work with, right-click it and then select edit to open the Group Policy Management Editor, as shown in Figure 2-2.

   

   Figure 2-2. Editing a GPO in Group Policy Management Editor.

5. In the Group Policy Management Editor, click the Computer Configuration node and then click the User Configuration node. When you select these nodes, the current administrative templates are read in and applied to the GPO you’ve selected. After Group Policy is refreshed, you can modify policy settings as necessary, and the changes will be updated as appropriate in the selected site, domain, or organizational unit.

6. Repeat this procedure to update the GPOs for other sites, domains, or organizational units.

Normally, nothing else about how Group Policy is used would change when you make this update. However, computers running Windows Vista and later support a new file format called ADMX. ADMX uses XML to format policies and changes the way data is stored in the SYSVOL.

SYSVOL Changes

With the original file format used with policies, called ADM, policy definition files are stored in the GPO to which they relate. As a result, each GPO stores copies of all applicable policy definition files and can grow to be multiple megabytes in size. In contrast, with the ADMX format, policy definition files are not stored with the GPOs with which they are associated by default. Instead, the policy definition files can be stored centrally on a domain controller and only the applicable settings are stored within each GPO. As a result, GPOs that use ADMX are substantially smaller than their counterparts that use ADM. For example, while a GPO that uses ADM may be 4 megabytes (MB) in size, a GPO that uses ADMX may be only 4 kilobytes (KB) in size.

The ADMX file format is entirely different from the ADM format previously used. ADMX files are divided into language-neutral files ending with the .admx file extension and language-specific files ending with the .adml extension. The language-neutral files ensure that a GPO has identical core policies. The language-specific files allow policies to be viewed and edited in multiple languages. Because the language-neutral files store the core settings, policies can be edited in any language for which a computer is configured, thus allowing one user to view and edit policies in English and another to view and edit policies in Spanish, for example. The mechanism that determines the language used is the language pack installed on the computer.

Language-neutral ADMX files are installed on computers running Windows Vista and Windows Server 2008 in the %SystemRoot%\PolicyDefinitions folder. Language-specific ADMX files are installed on computers running Windows Vista and Windows Server 2008 in the %SystemRoot%\PolicyDefinitions\LanguageCulture folder. Each subfolder is named after the appropriate International Standards Organization (ISO) language/culture name, such as en-US for U.S. English.

Only policy editors that are compatible with the ADMX file format can read the policies that have been updated to use ADMX. When you start a compatible policy editor, it automatically reads in the ADMX files from the policy definitions folders. Because of this, you can copy ADMX files that you want to use to the appropriate policy definitions folder to make them available when you are editing GPOs. If the policy editor is running when you copy the file or files, you must restart the policy editor to force it to read in the file or files.

In domains, ADMX files can be stored in a central store rather than in the Policy-Definitions folder on each computer you use for GPO editing. Using a central store makes management of ADMX files easier and more efficient by allowing administrators to manage GPOs from any compliant computer on the network, simplifying version management of policy files and making it easier to add new policy files.

To create a central store for ADMX files, you must access a domain controller using an account that is a member of the Domain Admins group and then create a folder called PolicyDefinitions within the SYSVOL. This folder is where you’ll place the language-neutral ADMX files. You’ll also need to create subfolders within the PolicyDefinitions folder for each language that is supported in your ADMX files. These subfolders will store the language-specific resource files, which have the extension .adml. After you create the required folders, you need to copy the language-neutral ADMX definition files and the language-specific ADMX resource files to the appropriate folders in the central store.

Because the default location for the SYSVOL is %SystemRoot%\Sysvol, you would do the following to create and establish the central store in the default SYSVOL location:

1. Access a domain controller running Windows Server 2008 in the target domain using an account that is a member of Domain Admins, and then create a PolicyDefinitions folder under %SystemRoot%\Sysvol\DomainName\Policies, where DomainName is the name of the domain in which the domain controller is located and for which you want to establish a central store. Within the PolicyDefinitions folder, create subfolders for each language that is supported in your ADMX files.

   Real World

   As discussed in “Replication Changes” later in the chapter, domain controllers can replicate the SYSVOL using either File replication Service (FRS) replication or Distributed File System (DFS) replication. The default SYSVOL location is %SystemRoot%\Sysvol when domain controllers replicate the SYSVOL using FRS replication. When domain controllers replicate the SYSVOL using DFS replication, the default SYSVOL location is %SystemRoot%\Sysvol_dfsr. If your domain controllers use DFS replication, you create the PolicyDefinitions folder under %SystemRoot%\Sysvol_dfsr\DomainName\Policies and copy files to this location.

2. Copy all the ADMX and ADML files from their original location on a target computer to the appropriate SYSVOL folders.

   Windows Vista SP1 and Windows Server 2008 have 146 default ADMX files. Each ADMX file has an associated ADML file located under one or more language-specific folders, such as en-US for U.S. English. These files are stored by default under %SystemRoot%\PolicyDefinitions and %System-Root%\PolicyDefinitions\LanguageCulture, respectively. If you’ve created custom ADMX files, these files are stored on the workstation on which they were created. If you are using an operating system later than Windows Vista SP1 or Windows Server 2008 RTM, there may be additional ADMX files that are available only on computers with this operating system and service pack combination installed.

If you want to create a central store for all languages supported by the computer on which you are currently logged on, you could copy all the required policy files from your computer to a target domain controller in a single step. Simply run the following commands at an elevated, administrator command prompt:

xcopy /s /y %SystemRoot%\PolicyDefinitions \\DC\Sysvol\DomainName\policiesPolicyDefinitions\

where DC is the host name of the target domain controller, and DomainName is the fully qualified DNS name of the domain in which the domain controller is located. In the following example, you copy the ADMX and ADML files from your computer to CorpServer56 in the Cpandl.com domain:

xcopy /s /y %SystemRoot%\PolicyDefinitions \\CorpServer56\Sysvol\cpandl.compolicies\PolicyDefinitions\

Two helpful environment variables when you are working with policy files are %UserDNSDomain% and %LogonServer%. %UserDNSDomain% represents the current log on domain, and %LogonServer% represents the domain controller that authenticated you during logon. Therefore, you could also copy all required policy files by entering the following command at an elevated, administrator command prompt:

xcopy /s /y %SystemRoot%\PolicyDefinitions \\%LogonServer%\Sysvol%UserDNSDomain%\policies\PolicyDefinitions\

As a recommended best practice, you should create the central store on the domain controller that holds the PDC (primary domain controller) Emulator role in the target domain. Why? By default, the PDC emulator is the domain controller that Group Policy relies on when you access GPOs for editing. Therefore, when you create the central store on the PDC emulator, you ensure that anyone who edits Group Policy objects sees the central store immediately rather than having to wait for SYSVOL replication. As part of normal SYSVOL replication, the PDC emulator will then replicate the central store to other domain controllers in the domain.

You can determine which domain controller in your logon domain has the PDC Emulator role by entering the following command at a command prompt:

dsquery server –o rdn –hasfsmo pdc

The resulting output is the host name of the PDC emulator in your logon domain. If you want the name for the PDC emulator in another domain, you must use the –Domain parameter. Consider the following example:

dsquery server –o rdn -hasfsmo pdc -domain tech.cpandl.com

Here you obtain the host name for the PDC emulator in the tech.cpandl.com domain. If there are multiple domains in the forest, you might also want a list of all the domain controllers that have the PDC emulator role on a per-domain basis. To do this, use the -Forest parameter, such as:

dsquery server -hasfsmo pdc –forest

For more information on why Group Policy relies on the PDC emulator by default, see “Connecting to and Working with GPOs” later in this chapter.

Replication Changes

A key change between earlier implementations of Active Directory and implementations for Windows Server 2008 and later has to do with how policies and related data are replicated. The Active Directory system volume (SYSVOL) contains domain policy; scripts used for log on, log off, shutdown, and startup; other related files; and files stored within Active Directory. While I’ll provide an in-depth discussion of the SYSVOL in Chapter 7, let’s take a quick look at the way SYSVOL replication works.

The way domain controllers replicate the SYSVOL depends on the domain functional level. When a domain is running at Windows 2000 native or Windows Server 2003 functional level, domain controllers replicate the SYSVOL using File Replication Service (FRS). When a domain is running at Windows Server 2008 functional level, domain controllers replicate the SYSVOL using Distributed File System (DFS).

FRS and DFS are replication services that use the Active Directory replication topology to replicate files and folders in the SYSVOL shared folders on domain controllers. The way this works is that the replication service checks with the Knowledge Consistency Checker (KCC) running on each domain controller to determine the replication topology that has been generated for Active Directory replication. Then the replication service uses this replication topology to replicate SYSVOL files to other domain controllers in the domain.

The storage techniques and replication architectures for DFS and FRS are decidedly different. File Replication Service (Ntfrs.exe) stores FRS topology and schedule information in Active Directory and periodically polls Active Directory to retrieve updated information using Lightweight Directory Access Protocol (LDAP). Internally, FRS makes direct calls to the file system using standard input and output. When communicating with remote servers, FRS uses the remote procedure call (RPC) protocol.

FRS stores configuration data in the registry and also stores various types of data in the NTFS file system. For example, FRS stores transactions in the FRS Jet database (Ntfrs.jdb), events and error messages in the FRS Event log (NtFrs.evt), and debug logs in the debug log folder (%SystemRoot%\Debug). The contents of the Replica tree determines what FRS replicates. The Replica tree for Active Directory is the SYSVOL. The SYSVOL contains domain, staging, and SYSVOL folders.

NTFS uses the update sequence number (USN) journal to track information about added, deleted, and modified files. FRS in turn uses the USN journal to determine when changes are made to the contents of the Replica tree and then replicates those changes according to the schedule in Active Directory.

Distributed File Service (Dfssvc.exe) stores information about stand-alone namespaces in the registry and information about domain-based namespaces in Active Directory. The stand-alone DFS metadata contains information about the configuration of each stand-alone namespace and is maintained in the registry of the root server at HKLM\SOFTWARE\Microsoft\Dfs\Roots\Standalone. Domain-based root servers have a registry entry for each root under HKLM\SOFTWARE\Microsoft\Dfs\Roots\Domain, but these entries do not contain the domain-based DFS metadata.

When the DFS service starts on a domain controller using Active Directory with DFS, DFS checks this path for registry entries that correspond to domain-based roots. If these entries exist, the root server polls the PDC emulator master to obtain the DFS metadata for each domain-based namespace and stores the metadata in memory.

In Active Directory, the DFS object stores the DFS metadata for a domain-based namespace. The DFS object is created in Active Directory when you establish a domain at or promote a domain to the Windows Server 2008 domain functional level. Active Directory replicates the entire DFS object to all domain controllers in a domain.

DFS uses a client-server architecture. A domain controller hosting a DFS namespace has both the client and the server components, allowing the domain controller to perform local lookups in its own data store and remote lookups in data stores on other domain controllers. DFS uses the Common Internet File System (CIFS) for communication between DFS clients, root servers, and domain controllers. CIFS is an extension of the Server Message Block (SMB) file sharing protocol.

It is an easy choice whether to use FRS or DFS. FRS enables interoperability with Windows 2000 Server and Windows Server 2003 but does not support the latest replication enhancements. DFS offers incremental improvements in Active Directory performance and features but is only available when all domain controllers are running Windows Server 2008 and the domain is running in the Windows Server 2008 functional level.

DFS supports the latest replication enhancements, including replication of changes only within files, bandwidth throttling, and improved replication topology. When you make a change to a GPO and FRS is being used, FRS replicates the entire GPO. When you make a change to a GPO and DFS is being used, only the changes in GPOs are replicated, thereby eliminating the need to replicate an entire GPO after a change.

FRS uses an older, less efficient technology for replication, called Rsync. DFS uses Remote Differential Compression (RDC) instead of Rsync to provide replication that is up to 300 percent faster and compression that is 200 to 300 percent faster. With DFS, operational overhead for managing content and replication is also reduced by approximately 40 percent. Additionally, DFS supports automated recovery from database loss or corruption as well as replication scheduling. Together these features make DFS significantly more scalable than FRS.