Getting Started with Group Policy

In this book, you'll learn about the 13 major categories of Group Policy:

Administrative Templates (Registry Settings)
Security Settings (in the Windows Settings folder)
Scripts (under Windows Settings)
Remote Installation Services ( User node only under Windows Settings)
Software Installation (Application Management)
Folder Redirection
Disk Quotas
Encrypted Data Recovery Agents (EFS Recovery Policy)
Internet Explorer Maintenance
IP Security Policies
Software Restriction Policies (available for Windows XP and Windows 2003 only)
Quality of Service (QoS) Policies (available for Windows XP and Windows 2003 only)
Wireless 802.11 Policies (available for Windows XP and Windows 2003 only)

For a quick reference of where to locate them in this book, just flip to the inside back cover. However, in this first section, you'll learn how to gain access to the interface, which will let you start configuring these categories.

Group Policy is a twofold idea. First, without an Active Directory, there's one and only one Group Policy available, and that lives on the local Windows XP or Windows 2000 workstation. Officially, this is called a Local Policy , but it still resides under the umbrella of the concept of Group Policy. Later, once Active Directory is available, the nonlocal (or, as they're sometimes called, Domain-Based or Active Directory-Based ) Group Policy Objects come into play, as you'll see later. Let's get started and explore both options.

Understanding Local Group Policy

Before we officially dive in to what is specifically contained inside this magic of Group Policy or how Group Policy is applied when Active Directory is involved, you might be curious to see exactly what your interaction with the Local Group Policy might look like.

You can begin to edit Group Policy in multiple ways. One way is to load the MMC (Microsoft Management Console) snap-in by hand. You can do so logged on to any workstation or member server (but not a Domain Controller) as a local administrator.

Warning

For the examples in this book, we'll do most of the workstation work on one workstation, XPProl, and most of the Active Directory and server work on one Windows 2003 Domain Controller, WINDC01, in a domain called Corp.com. Feel free to follow along if you like. Because Group Policy can be so all-encompassing, it is highly recommended that you try these examples in a test lab environment first, before making these changes for real in your production environment. The ideal configuration for this book is that XPPro1 has XP/SP2, and WINDC01 has Windows 2003/SP1.

To load the Group Policy Object Editor by hand, follow these steps:

Choose Start ˜ Run to open the Run dialog box, and in the Open box, type MMC . A "naked" MMC appears.
From the File menu, choose Add/Remove Snap-in to open the Add/Remove Snap-in dialog box.
Click Add.
Locate and select the Group Policy Object Editor Snap-in and click Add.
At the "Select Group Policy Object" screen, keep the default "Local Computer Policy" and click Finish.
At the Add Standalone Snap-in dialog box, click Close.
At the Add/Remove Snap-in dialog box, click OK.

You should see something similar to Figure 1.1.

Figure 1.1: Edit a Windows XP Local Group Policy by drilling down into the User Configuration settings.

You are now exploring the Local Group Policy of this Windows XP workstation. Local Group Policy is unique to each specific machine. To see how a Local Group Policy applies, drill down through the User Configuration folder ˜ Administrative Templates folder ˜ System ˜ Ctrl+Alt+Del Options and select Remove Lock Computer as seen in Figure 1.1. Once selected, click Enabled and select OK.

When you do, within a few seconds, you should see that if you were to press Ctrl+Alt+Del, then the "Lock Computer" option should be unavailable.

To revert the change, simply re-select Remove Lock Computer and select Not Configured. This reverts the change back to the way the operating system works by default.

Note	You can think of Local Group Policy as a way to perform decentralized administration. A bit later, when we explore Group Policy with Active Directory, we'll saunter into centralized administration.

Local Group Policy affects everyone who logs on to this machineincluding normal users and administrators. Be careful when making settings here; you can temporarily lock yourself out of some useful functions. For instance, frequently administrators want to remove Run from the Start menu. Then, the first time they themselves want to go to a command prompt, they can't choose Start ˜ Run. It's just gone!

Tip	To fix, you have to click the MMC.exe icon in Explorer (or via command line) and manually load the Group Policy Snap-in.

As we stated in the Introduction, most of the settings we'll explore in this book are available to workstations or servers that aren't joined to an Active Directory domain. However, the Folder Redirection settings (discussed in Chapter 9), the Software Distribution settings (discussed in Chapter 10), and Remote Installation Services (discussed in Chapter 11) are not available to Stand-alone machines without Active Directory present.

Tip

You can also start the Local Group Policy Object Editor by choosing Start ˜ Run to open the Run dialog box and then typing gpedit.msc in the Open box. You can point toward other computers by using the syntax gpedit.msc /gpcomputer: " targetmachine" or gpedit.msc /gpcomputer: "targetmachine.domain.com" ; the machine name must be in quotes.

You can think of Local Group Policy as way to perform desktop management in a decentralized way. That is, you're still running around, more or less, from machine to machine where you want to set the Local Group Policy.

The other strategy is a centralized approach. Centralized Group Policy administration works only in conjunction with Active Directory.

We'll return to other ways to fire up the Group Policy Object Editorso stay tuned .

Note	Local Group Policy is stored in the c:\windows\system32\grouppo1icy directory. The structure found here mirrors what you'll see later in Chapter 4 when we inspect the ins and outs of how Group Policy applies from Active Directory.

Group Policy Entities and Policy Settings

Every Group Policy contains two halves: a User half and a Computer half. This goes for the Local Group Policy that we just saw and for Group Policy objects that are created when we use Active Directory, as you'll see later in this chapter. These two halves are properly called nodes, though sometimes they're just referred to as either the user half and the computer half or the user branch and the computer branch. A sample Group Policy Object Editor screen with both the Computer Configuration and User Configuration nodes can be seen in Figure 1.1.

The first level under both the User and the Computer nodes contains Software Settings, Windows Settings, and Administrative Templates. If we dive down into the Administrative Templates of the Computer node, underneath we discover additional levels of Windows Components, System, Network, and Printers. Likewise, if we dive down into the Administrative Templates of the User node, we see some of the same folders plus some additional ones, such as Shared Folders, Desktop, and Start Menu And Taskbar.

In both the User and Computer half, you'll see that policy settings are hierarchical, like a directory structure. Similar policy settings are grouped together for easy location. That's the idea anyway; though, admittedly, sometimes locating the specific policy you want can prove to be a challenge.

When manipulating policy settings, you can choose to set either Computer policy settings or User policy settings (or both!). We'll see examples of this shortly. (See the section "Using the Only Show Configured Policy Settings Option" in Chapter 3 for tricks on how to minimize the effort of finding the policy setting you want.)

Note	Most policy settings are not found in both nodes. However, there area fewthat overlap. In that case, if the computer policy setting is different from the user policy setting, the computer policy setting overrides the user policy setting.

Active Directory-Based Group Policy

To use Group Policy in a meaningful way, you need an Active Directory environment. An Active Directory environment needn't be anything particularly fancy; indeed, it could consist of a single Windows 2000 or Windows 2003 Domain Controller and perhaps just one Windows 2000 or Windows XP workstation joined to the domain.

But Active Directory can also grow extensively from that original solitary server. You can think of an Active Directory network as having four constituent and distinct levels:

The local computer
The site
The domain
The organizational unit (OU)

The rules of Active Directory state that every server and workstation must be a member of one (and only one) domain and be located in one (and only one) site.

In Windows NT, additional domains were often created to partition administrative responsibility or to rein in needless chatter between Domain Controllers. With Active Directory, administrative responsibility can be delegated using OUs.

Additionally, the problem with needless domain bandwidth chatter has been brought under control with the addition of Active Directory sites, which are concentrations of IP (Internet Protocol) subnets with fast connectivity. There is no longer any need to correlate domains with network bandwidththat's what sites are for!

Group Policy and Active Directory

When Group Policy is created at the local level, everyone who uses that machine is affected by those wishes. But once you step up and use Active Directory, you can have nearly limitless Group Policy Objects (GPOs)with the ability to selectively decide which Users and which Computers will get which wishes (try saying that five times quickly). The GPO is the vessel that stores these wishes for delivery.

Note	Actually, you can have only 999 GPOs applied to a user or a computer.

When we create a GPO that can be used in Active Directory, we actually create some brand-new entries within Active Directory, and we automatically create some brand-new files on our Domain Controllers, both of which are known as GPOs.

You can think of Active Directory as having three major levels:

Site
Domain
OU

Additionally, since OUs can be nested within each other, Active Directory has a nearly limitless capacity for where we can tuck stuff away.

In fact, it's best to think of this design as a three- tier hierarchy: site, domain, and each nested OU. When wishes, er, policy settings, are set at a higher level in Active Directory, they automatically flow down throughout the remaining levels.

So, to be precise:

If a GPO is set at the site level, the policy settings contained within affect those accounts within the geography of the site. Sure, their user accounts will be in a domain (and/or possibly in an OU), but the account is affected only by the policy settings here because the account is in a specific site.
If a GPO is set at the domain level, it affects those folks within the domain and all OUs and all other OUs beneath it.
If a GPO is set at the OU level, it affects those folks within the OU and all other OUs beneath it (usually just called child OUs).

By default, when a policy is set at one level, the levels below inherit the settings from the levels above it. You can have "cumulative" wishes that keep piling on.

You might wonder what happens if two policy settings conflict. Perhaps one policy is set at the domain level, and another policy is set at the OU level, which reverses the edict in the domain. The result is simple: Policy settings further down the food chain take precedence. For instance, if a policy setting conflicts at the domain and OU levels, the OU level "wins." Likewise, domain-level settings override any policy settings that conflict with previously set site-specific policy settings. Take a look at the folling graphic to get a graphical view of the order of precedence.

However, one giant caveat should be mentioned at this point. If the Local Group Policy has been set on a specific workstation, everyone logging on to that workstation is affected by that policy setting. Then, the policy settings within Active Directory (the site, domain, and OU) apply. So, sometimes people refer to the four levels of Group Policy: local workstation, site, domain, and OU. Nonetheless, GPOs set within Active Directory always "trump" the Local Group Policy should there be any conflict.

If this behavior is undesired for lower levels, all the settings from higher levels can be blocked with a "Block Inheritance" attribute. Additionally, if a higher-level administrator wants to guarantee that a setting is inherited down the food chain, they can apply the "Enforced" attribute via the GPMC attribute (or "No Override" attribute in the old-school parlance) (Chapter 3 explores both Block Inheritance and Enforced attributes in detail.)

Note	Don't sweat it if your head is spinning a little bit now from the Group Policy application theory. I'll go through specific hands-on examples to illustrate each of these behaviors so that you understand exactly how this works.

Linking Group Policy Objects

Another technical concept that needs a bit of description here is the "linking" of GPOs. When a GPO is created at the site, domain, or OU level, via the GUI (which we'll do in a moment), the system automatically associates that GPO with the level in which it was created. That association is called linking.

Linking is an important concept for several reasons. First, it's generally a good idea to understand what's going on under the hood. However, more practically, the new Group Policy Management Console, or GPMC, as we'll explore in just a bit, displays GPOs from their linked perspective.

You can think of all the GPOs you create in Active Directory as children within a big swimming pool. Each child has a tether attached around their waist, and an adult guardian is holding the other end of the rope. Indeed, there could be multiple tethers around a child's waist, with multiple adults tethered to one child. A sad state indeed would be a child who has no tether but is just swimming around in the pool unsecured. The "swimming pool" in this analogy is a specific Active Directory container named Policies (which we'll examine closely in Chapter 4). All GPOs are born and "live" in that specific domain. Indeed, they're replicated to all Domain Controllers. The adult guardian in this analogy represents a level in Active Directoryany site, domain, or OU.

In our swimming pool example, multiple adults can be tethered to a specific child. With Active Directory, multiple levels can be linked to a specific GPO. Thus, any level in Active Directory can leverage multiple GPOs, which are standing by in the domain ready to be used.

Remember, though, unless a GPO is specifically linked to a site, a domain, or an OU, it does not take effect. It's just floating around in the swimming pool of the domain waiting for someone to make use of it.

I'll keep reiterating and refining the concept of linking throughout these first four chapters. And, in Chapter 3, I'll discuss why you might want to "unlink" a policy.

This concept of linking to GPOs created in Active Directory can be a bit confusing. It will become clearer a bit later as we explore the processes of creating new GPOs and linking to existing ones. Stay tuned. It's right around the corner.