Group PolicyConcepts | Windows Server 2003 in a Nutshell

Group PolicyConcepts

Group Policy lets you centrally define various user and computer settings for WS2003, W2K, and XP computers on your network. These settings are then periodically refreshed to ensure their effect is maintained when changes occur in the objects to which they apply. The advantages of using Group Policy on your network include the ability to:

Centralize all policy settings for your enterprise at the domain or site level to enforce uniformity across administrative and physical locations. Group Policy is defined in Active Directory, the central repository of computer and network configuration information in WS2003.
Manage different sets of users and computers by applying different policies to different sites, domains, and OUs in Active Directory. Administrators can also reduce their own workload by delegating management over different portions of the Active Directory hierarchy to trusted users and groups.
Manage users' desktop environments on their client computers to make users more productive and to reduce time spent troubleshooting configuration problems. This includes the ability to lock down users' machines to prevent them from making changes to their working environment and the ability to make users' data folders be accessible from any computer on the network.
Manage the installation, update, repair, and removal of software on users' client computers. This can be used for applications, service packs , operating-system updates, and fixes and can ensure that the same applications are available to users regardless of the computer to which they log on.
Manage the security of computers and users in your domain by creating and managing account policies, audit policies, EFS recovery settings, and other security features.

Group Policy Objects

Group Policy settings are contained within a Group Policy Object (GPO). There are two different ways of looking at a GPO: logical and physical.

Logical Structure

There are two main types of settings within a GPO:

Computer configuration: These settings are applied to any computer affected by the GPO.
User configuration: These settings are applied to any user affected by the GPO.

For more information on the different categories of Group Policy settings available under user and computer configuration, see Group Policy Settings later in this section.

Physical Structure

The information specified in a GPO is actually stored in two separate, physical locations on domain controllers:

Group Policy Container

This is a container within Active Directory where the attributes and version information of GPOs are stored. The Group Policy Container is used for two purposes:

Domain controllers use it to determine whether they have the most recent version of GPOs. For example, if you update a GPO on one domain controller and other domain controllers check the Group Policy Container during Active Directory replication and discover that the version they have is an old one, they then replicate the new GPO to themselves .

Client computers use it to locate the Group Policy Template (GPT) associated with each GPO that is being applied to them.

The Group Policy container can be displayed in the Active Directory Users and Computers console by first using View Advanced Features to display the hidden containers in Active Directory. Then expand the System Policies container, which contains the different Group Policy Containers associated with each GPO. Each Group Policy Container is named using the globally unique identifier (GUID) of its associated GPO. You can view this information for interest's sake, but there is nothing for you to administer here.

Group Policy Template (GPT): This is a hierarchy of folders in the SYSVOL share, which is located on domain controllers. Each GPO has an associated GPT folder hierarchy in the SYSVOL share, which is also named using the GUID of the GPO. This GPT contains the administrative templates, security settings, scripts, software installation settings, and folder redirection settings associated with the GPO. In order to obtain these settings when a GPO is being applied, the client computer connects with the SYSVOL share on a domain controller and downloads the settings.

Group Policy Settings

There are several different categories of Group Policy settings:

Administrative templates

Folder redirection

Scripts

Security settings

Software installation

Internet Explorer maintenance

Let's examine these different categories.

Administrative Templates

These settings are used primarily to manage user environments. Administrative templates enable administrators to control the appearance and functionality of user work environments (desktops) and can be used to lock down user and computer settings to prevent desktops from being altered . This is important because ordinary users sometimes try to reconfigure their desktop settings themselves, resulting in extra support calls to the IT department and wasted time and money. Specifically, administrative template settings can be used to:

Prevent users from accessing certain operating-system functions such as the Control Panel or customization options for Internet Explorer
Enforce a standard desktop and Start menu across an enterprise or department
Prepopulate users' desktops with shortcuts to shared folders and network connections they will need
Enable users to access their personal desktop settings from any computer on the network

Of the eight groups of administrative template settings, some are under User Configuration in a GPO, some under Computer Configuration, and some under both, as Table 4-21 shows. If a conflicting administrative template setting is found in both the User and Computer Configuration in a GPO, the Computer setting usually overrides the User setting even if these settings are from different GPOs, and the one with the Computer setting was applied first.

Table 4-21. Categories of administrative template settings

Type	Description	Configuration
Control Panel	Lets you hide all or part of the Control Panel and restrict access to Add/Remove Programs, Display, Printers, and Regional Options	User
Desktop	Lets you control the appearance of the user desktop, enable or disable Active Desktop, and limit user ability to query Active Directory	User
Network	Lets you configure and manage aspects of offline files, network connections, DNS clients , and SNMP	User and Computer
Printers	Lets you control web-based printing, the automatic publishing of printers in Active Directory, and other aspects of network printing	Computer
Shared folders	Lets you allow shared folders and DFS roots to be published (new to WS2003)	User
Start menu & taskbar	Lets you control the appearance and functionality of the Start menu and taskbar	User
System	Lets you control logon and logoff functionality, set disk quotas, specify a primary DNS suffix, control how Group Policy is applied, disable registry-editing tools, disable Autoplay, configure user profiles, configure power management, enable Remote Assistance, configure the Windows Time Service, and more	User and Computer
Windows components	Lets you control the functionally of Internet Explorer, NetMeeting, Task Scheduler, Windows Installer, Windows Explorer, Terminal Services, Messenger, Windows Update, and more	User and Computer

Administrative templates are implemented as settings that modify the registry on users' machines. These settings are stored in two files, both called Registry.pol , which are located within two folders in the GPT of the GPO in the SYSVOL share of domain controllers in the domain. Specifically, the paths to these two files within the SYSVOL share are:

sysvol\<domain>\Policies\<GUID_for_GPO>\MACHINE\ Registry.pol
sysvol\<domain>\Policies\<GUID_for_GPO>\USER\ Registry.pol

When administrative template settings are applied to a client computer (when the GPO is applied), these settings are written to the client computer in two registry locations:

User configuration templates settings modify the HKEY_CURRENT_USER (HKCU) hive.
Computer configuration template settings modify the HKEY_LOCAL_MACHINE (HKLM) hive.

These settings are saved to two special sections of these hives:

\Software\Policies
\Software\Microsoft\Windows\CurrentVersion\Policies

By saving GPO administrative template settings to these special areas of the registry, the original (default) registry settings are unchanged so that when the GPO settings are removed (for example, by unlinking the GPO from the OU containing the User or computer object), the default registry settings take effect. This allows you to free up desktops that had previously been locked down by Group Policy.

If a resultant GPO setting stored in the registry areas described previously conflicts with the default registry setting for that same operating-system function, the GPO setting wins, of course ( otherwise , Group Policy could never be applied!). If a resultant GPO setting is Not Configured, the default registry setting applies for that function.

Folder Redirection

A useful feature of Group Policy in WS2003 is folder redirection, which allows My Documents , Start menu , Desktop , and Application Data folders for each user to be centrally located on a network share instead of on each user's local machine. These folders are normally part of a user's profile and are stored locally in the C:\Documents and Settings\<username> folder on the client computer that the user uses.

The advantages to redirecting folders include:

It makes users' work easier to back up since datafiles are stored in a central location on a network file server.
The data in these folders can be accessed easily by users no matter which computers they use to log on to the network.

Folder redirection is an alternative to implementing roaming users on your network and has several advantages over implementing roaming users:

My Documents and other special folders are normally part of a user's roaming profile, and when a roaming user logs on to a computer, his entire roaming profile (including My Documents and its contents) is copied to the local computer. This is done to create a local profile on the machine and can use up a lot of disk space on client computers if users have many files in My Documents and if many users share a single machine. In addition, the bigger the contents of My Documents , the longer it takes for a roaming user to log on to the network. If users make changes to their datafiles during a session and then log off, the changes are copied to the server and slow down the logoff process as well.
By contrast, files stored in redirected folders aren't copied to the local computer when a user logs on, with the result that logon and logoff traffic is minimized. Network traffic is generated only when a user tries to access a file in a redirected My Documents folder.

You can choose to redirect all four folders for each user to the same share or to separate shares, and you can redirect some of the folders and not the rest if you choose. Here are some specific reasons why you might want to redirect each folder:

Application Data: This folder contains user-specific data for applications such as Internet Explorer and should be redirected if users need to access these applications from any client computer.
Desktop: This folder contains the shortcuts and files on the user's desktop and should be redirected if you want users to have standardized desktops.
My Documents: This folder contains the work files for the user and is the default location for commands such as Open and Save in WS2003-compliant applications. You should redirect this folder if you want users to be able to access their work files from any computer on the network and to centralize user work files for backup purposes.
Start menu: This folder contains the user's Start menu shortcuts and folders and should be redirected if you want users to have a standardized Start menu. (Redirect all users to the same share and assign them NTFS Read permission so they can't alter their common Start menu.)

Scripts

These are settings that let you automate how scripts (batch files, Windows Scripting Host scripts, or even executable program files) are run on client computers. Four types of scripts can be configured to run automatically using Group Policy:

Startup scripts: These run synchronously (one after another, not concurrently) when a client computer is booted up.
Logon scripts: These run asynchronously (you can run multiple logon scripts concurrently) when users log on.
Logoff scripts: These run asynchronously when users log off.
Shutdown scripts: These run synchronously when the system is shut down normally.

Security Settings

These settings can be used to secure various aspects of WS2003 computers on your network. Security policies may be configured at the site, domain, or OU level, but most commonly at the domain level. Security settings are found in a GPO in Computer Configuration Windows Settings Security Settings. If you have Certificate Services installed, then User Configuration Windows Settings Security Settings is used also for these services.

Eleven groups of security settings are available, all of them under User Configuration, with two of them (public key policies and software restriction policies) also under Computer Configuration:

Account policies: These include password, account lockout, and Kerberos policies that control the security of the logon process. Password policies include the minimum length, age, history, and complexity of user passwords. Note that changing a password setting by using Group Policy has no effect on current user passwords until users try to change their passwords, so it's a good idea to ensure that users regularly change their passwords if you implement password policies on your network. Account lockout settings determine how long and after how many attempts users are locked out when they fail to enter their correct password. Once a lockout policy is configured, it is applied immediately for all users. Kerberos policies are used to configure aspects of Kerberos authentication for cross-domain authentication. Account policy settings (password and account lockout) apply to all users and work only for a GPO linked to a domain, not to a site or OU. You can configure account policy settings on a GPO linked to a site or OU, but these settings are ignored. Furthermore, account policy settings configured for a domain can't be blocked by GPOs linked to OUs. You can, however, link one GPO to multiple domains to enforce account policy settings across a domain tree or forest. See Group PolicyTasks later in this chapter for more information about linking and blocking GPOs.
Local policies: These include audit policies, user rights, and miscellaneous security settings that affect individual computers instead of the domain.
Event log: These settings allow you to configure the size and behavior of the system, security, and application logs.
Restricted group: These settings control the membership of specified groups using security policies.
System services: These settings can be used to configure the startup and security settings of WS2003 services running on all computers in a domain or OU.
Registry: These settings allow you to configure permissions on subtrees of registry keys on all computers in a domain or OU.
Filesystem: These settings allow you to set consistent NTFS permissions on selected files or folders on all computers in a domain or OU.
Wireless network (802.11) policies: These run the Wireless Policy Wizard to create policies for wireless networks. This feature is new to WS2003.
Public key policies: These settings allow you to configure trusted certificate authorities and encrypted data recovery agents .
Software restriction policies: Create software restriction policies to identify which software is allowed to run on your computer. This feature is new to WS2003 and helps you protect your computer against untrusted code.
IP Security policies on Active Directory: These settings let you configure IPSec settings on all computers in a domain or OU.

Security settings are covered in more detail under Security Policies later in this section.

Software Installation

Group Policy can also be used in conjunction with Active Directory and Windows Installer to enable administrators to remotely install, upgrade, maintain, and remove software applications on client computers from a central location. Windows Installer consists of two components:

Windows Installer service: A client-side service on WS2003 computers that allows the installation and configuration of software to be fully automated. The service can install applications either from a CD-ROM or network share (distribution point) directly, or it can be done using Group Policy.
Windows Installer package: The packaged application to be installed or upgraded. It consists of a Windows Installer file (an .msi file), external source files, package summary information, and a reference to the location of the distribution point where the files reside.

Windows Installer has several benefits over traditional Setup programs for installing applications:

It automatically fixes an application when one or more of its critical files become corrupt or missing.
It cleanly removes all files and registry settings when an application is uninstalled .
It allows software installation, upgrade, maintenance, and removal processes to be fully automated using Group Policy.

You can deploy software in two ways using Software Installation and Maintenance:

Assigning software

Assigning software causes the software to be installed automatically when users require it. Software can be assigned either to:

Users: This option places shortcuts on the desktop and Start menu of any computer that the user logs on to. When the user double-clicks on the desktop shortcut, selects the Start menu option, or even double-clicks on a file that has the specified file association, the application automatically installs on the computer to which the user is logged on. The advantage of assigning software is that the software is available on an as-needed basis and doesn't fill up the hard drives of client computers unnecessarily.
Computers: This option causes the software to be installed automatically when the designated computers are booted up. When users log on to their machines, the software is already deployed and available.

If an application that is deployed with assigning software becomes damaged, it is reinstalled automatically the next time the user logs on and activates a document associated with the application (Users option) or the next time the computer boots up (Computers option).

Publishing software: This option creates information in Active Directory telling client computers that the software is available from a network distribution point. When users open Add/Remove Programs in the Control Panel, the application appears as available for installation by the user. Alternatively, if users double-click on a file with the appropriate file association for the application, the client computer automatically contacts Active Directory, finds the published application, locates the distribution point, and begins the installation process.

Other options you can configure using Software Installation and Maintenance include:

Software modifications: Also called transform files, these . mst files can be used to deploy multiple configurations of an application for different groups in your enterprise.
Software categories: This lets you group published applications into different categories, making it easier for users to find and install them using Add/Remove Programs in the Control Panel.

Internet Explorer Maintenance

These settings are new in WS2003 and let you manage favorites, security zones, content rating, authenticode settings, proxy settings, and other aspects of Internet Explorer.

Using Group Policy

To implement Group Policy, you do two things:

Create a GPO

If there is an existing GPO that contains the settings you want to configure, you can modify that GPO instead of creating a new one. If you create a new GPO, then by default none of the settings in the GPO are configured.

Link the GPO

This associates the GPO with a container (site, domain, or OU) in Active Directory whose objects (users and computers) you want the GPO applied to. Once a GPO is linked to a container, the GPO settings will be applied to the users and computers in that container. Linking GPOs can be done in different ways:

You can link one GPO to multiple containers in Active Directory.
You can link multiple GPOs to a single container.

Once you have linked a GPO to a container in Active Directory, any users and computers in that container will have the GPO's settings applied to them (see When Group Policy Is Applied later in this section). Simply moving a user or computer object into the container automatically applies the GPO's settings to it.

How Group Policy Is Applied

You must understand the rules that control how GPOs are applied to users and computersotherwise, you may configure a GPO setting and never see it applied! Here are the key things to remember about how Group Policy is processed :

Order of application

GPOs are applied in a specific order:

Local: Group Policies applied to the local machine are processed first.
Site: The GPO linked to the site in which the user or computer resides is applied next, if in fact there is a GPO linked to the site. (By default, sites don't have a GPO linked to them.)
Domain: The GPO linked to the domain in which the user or computer resides is applied next. This may be the Default Domain Policy or some custom GPO you have created.
OU: The GPO linked to the OU in which the user or computer resides is then applied, if there is a GPO linked to the OU.

Conflicting settings

All GPO settings in all GPOs are applied in order to produce the resultant Group Policy settings for a user or computer object in Active Directory. The exception is if two or more GPOs are in the chain conflict on one or more settings. If conflicts arise, the settings from the last GPO in the conflict are applied. For example, if a GPO linked to the domain hides the Control Panel for all users in the domain, but the Vancouver OU has a GPO linked to it that displays (unhides) the Control Panel, then users logging on in Vancouver (i.e., user objects in the Vancouver OU) will see the Control Panel in their Start menu.

The exception is that if a User setting and a Computer setting conflict, the Computer setting is usually the winner regardless of the order in which the GPOs are applied.

Multiple GPOs

A site, domain, or OU may have multiple GPOs linked to it. If this is the case, these GPOs are applied in the order in which they are listed in the Group Policy Object Links list on the Group Policy tab of the properties sheet for that container.

Inheritance

GPO settings are inherited from site to domain to OU. Child containers inherit the settings of parent containers and can have Group Policy applied to them even if no GPO is explicitly linked to them. For example, if the Canada OU contains the Vancouver OU and a GPO is linked to Canada, user and computer objects in Vancouver will have the GPO settings applied to them as well.

If a GPO is linked to an OU and a parent OU higher up in the Active Directory hierarchy, the GPO inherited from the parent will be applied first, after which the explicitly linked GPO will be applied.

Blocking

You can explicitly prevent Group Policy settings from being inherited from a parent container (OU, domain, or site) using blocking. Blocking is limited by two factors:

If a parent container has a forced GPO linked to it, blocking on the child doesn't stop GPO inheritance from the parent.
Otherwise, if you enable blocking on a container, it blocks all settings from all GPOs higher up in the Active Directory hierarchy.

Forcing

You can force GPO inheritance on objects in child containers, regardless of whether the inherited settings conflict with those from processed GPOseven when blocking is configured on child containers.

Filtering

You can filter GPO settings to prevent inheritance by specific users, computers, and security groups in the container. This is done by suitably configuring Group Policy permissions on the container.

When Group Policy Is Applied

When a computer starts, Group Policy settings (if any GPOs are linked to the site, domain, or OU in which the associated computer object resides in Active Directory) are applied as follows :

Computer settings are processed.
Startup scripts (if any) are processed.

When a user logs on to a computer, Group Policy settings (if any GPOs are linked to the site, domain, or OU in which the associated user object resides in Active Directory) are applied as follows:

User settings are processed.
Logon scripts (if any) are processed.

Logon scripts assigned in a GPO are executed before scripts specified in the user's profile.

Once a computer for which Group Policy is assigned is running (whether a user is logged on or not), the Group Policy settings on the computer are refreshed at regular intervals, as follows:

Domain controllers refresh every five minutes. This ensures that domain-controller security settings are always fresh.
Client computers refresh every 90 minutes, plus a random offset of up to 30 minutes. This ensures that client-computer lockdown settings are maintained.

Software-installation and folder-redirection policies are processed only during startup and logon and aren't refreshed periodically as other policies are.

Planning Group Policy

Group Policy can be used to configure and manage computer and user environments to any degree desired. A large enterprise might want to use Group Policy to manage network security, enforce desktop standards, configure offline folders, deploy software, and perform and manage other administrative functions. The site, domain, and OU structure of an organization must be structured carefully in order to optimize the use of Group Policy.

You need to be aware of certain considerations when using Group Policy at each of the site, domain, and OU levels in Active Directory:

Site level

A GPO linked to a site is applied to all computers and users that are physically located at that site but doesn't affect mobile users from that site that travel to a different site in your organization. If a site spans multiple domains, the site GPO affects all the domains in the site.

A typical use of a site GPO is to prevent software installation from occurring beyond site boundaries since sites are often connected by slow WAN links.

Do not use a site GPO if your organization has only one site and one domain. Use a domain GPO instead.

Domain level

A GPO linked to a domain is applied to all computers and users in the domain. A GPO in a parent domain doesn't affect a GPO in a child domain of the parent. A domain GPO can be configured only by a domain administrator; it can't be delegated to someone not in that group.

A typical use of a domain GPO is to specify security settings for the domain (password and account lockout policies).

You can link a GPO to more than one domain, but this is not recommended since it increases interdomain network traffic. Instead, create a separate GPO for each domain.

OU level

A GPO linked to an OU is applied to all computers and users in the OU. Group Policy settings are inherited from a parent OU by its child OUs. Administrators can reduce their workload by delegating management of OU GPOs to trusted users in the enterprise (see Delegation earlier in this chapter).

Some typical uses for OU GPOs include:

Managing user rights, auditing, event log settings, and local security settings on OUs containing domain controllers and member servers
Managing software deployment and local security settings on OUs containing workstations
Managing desktop lockdown, folder redirection, and EFS policy on OUs containing users

Security Policies

We mentioned the security settings portion of Group Policy earlier, but this needs a bit more explanation. There are three different types of security policies:

Domain Security Policy: This is actually a system policy (not a GPO) that can be configured on WS2003 computers that aren't domain controllers.
Domain Security Policy: This is the Security Settings portion of the Default Domain Policy GPO, which is linked to the domain container in Active Directory Users and Computers.
Domain Controller Security Policy: This is the Security Settings portion of the Default Domain Controller Policy GPO, which is linked to the Domain Controllers OU within a domain container in Active Directory Users and Computers.

Let's look at each of these policies in more detail.

Local Security Policy

Local Security Policy displays the security settings for the local machine. In a domain-based scenario, these settings are determined by Group Policydon't edit these settings directly or they will be overwritten the next time Group Policy refreshes. On standalone servers in a workgroup, however, you can edit these settings to configure the following aspects of WS2003 security:

Account policies: This includes password and account lockout policies. For example, you can specify a minimum password length or have the lockout counter reset itself after a specified number of minutes.
Local policies: This includes audit policies, the rights assigned to different users and groups, and various other local security settings.
Public key policies: This contains a certificate declaring that the Administrator is an EFS recovery agent.
IP Security policies: This includes settings to configure IPSec for secure communications across a virtual private network (VPN).

Domain Security Policy and Domain Controller Security Policy

The Domain Security Policy and the Doman Controller Security Policy shortcuts in Administrative Tools open the Default Domain Security GPO for the domain in an MMC console window with the Group Policy snap-in installed. The entire GPO is not displayed, however. Only the policy subtree Computer Configuration Windows Settings Security Settings is displayed and available, providing a quick way to configure security settings for domains using Group Policy.