Our Own Group Policy Examples

Note

While you're plunking around inside the Group Policy Object Editor, you'll see lots of policy settings that are geared toward Windows 2000, Windows XP, and/ or Windows 2003. Some are geared only for Windows XP, and others are geared only for Windows 2003. If you happen to apply a policy to a system that isn't listed, the policy is simply ignored. For instance, policy settings described as working for Windows XP will not typically work on Windows 2000 machines.

Now that you've got a grip on honing your view within the GPMC, let's take it for a quick spin around the block with some examples!

For this series of examples, we're going after the users who keep fiddling with their display applets in Windows XP (and Windows 2000). In the Display Properties dialog box (right-click the Desktop and choose Properties from the shortcut menu) are several tabs, including Screensaver, Appearance, and Settings, as shown in Figure 1.10.

Figure 1.10: In Windows XP, all the tabs in the Display Properties dialog box are available by default.

For our first use of Group Policy, we're going to produce four "edicts." (For dramatic effect, you should stand on your desk and loudly proclaim these edicts with a thick British accent ):

At the site level, there will be no more Screen Saver tabs.
At the domain level, there will be no more Desktop tabs.
At the Human Resources Users OU level, there will be no more Settings tabs. And, while we're at it, let's bring back those Screen Saver tabs!
At the Human Resources Computers OU, we'll prohibit the use of the Task Scheduler.

Tip	Following along with these concrete examples will reinforce the concepts presented earlier. Additionally, they are used throughout the remainder of this chapter and the book.

Understanding GPMC's Link Warning

As you work through the examples, you'll do a lot of clicking around. When you click a GPO link the first time, you'll get this message:

This message is trying to convey an important sentiment. That is, multiple levels in Active Directory may be linked back and using the exact same GPO. The idea is that multiple levels of Active Directory could be using the exact same Group Policy Object contained inside the Group Policy Objects container but just linked back to it.

What if you modify the policy settings by right-clicking a policy link and choosing Edit from the shortcut menu? All instances in Active Directory that link to that GPO embrace the new settings. If this is a fear, you might want to create another GPO and then link it to the level in Active Directory you want. More properties are affected by this warning, and we'll explore them in Chapter 3.

If you've squelched this message by selecting "Do not show this message again", you can get it back. In the GPMC in the menus , choose View ˜ Options and select the General tab and select "Show Confirmation Dialog To Distinguish Between GPOs And GPO Links" and click OK.

Applying Group Policy Object to the Site Level

The least- often-used level of Group Policy application is at the site. This is because it's got the broadest stroke but the bluntest application. Additionally, since Active Directory states that only members of the Enterprise Administrators (EAs) can modify sites and site links, it's equally true that only EAs (by default) can add and manipulate GPOs at the site level.

Note	When a tree or a forest contains more than one domain, only the EAs and the Domain Administrators (DAs) of the root domain can create and modify sites and site links. When multiple domains exist, DAs in domains other than the root domain cannot create sites or site links (or site-level GPOs).

However, site GPOs might come in handy on an occasion or two. For instance, you might want to set up site-level GPO definitions for network-specific settings, such as Internet Explorer proxy settings or IP security policy for sensitive locations. Setting up site-based settings is useful if you have one building (set up explicitly as an Active Directory site) that has a particular or unique network configuration. You might choose to modify the Internet Explorer proxy settings if this building have a unique proxy server. Or in the case of IP security, perhaps this facility has particularly sensitive information, such as confidential records or payroll information.

Therefore, if you're not an EA (or a DA of the root domain), it's likely you'll never get to practice this exercise outside the test lab. In this example, we'll work with a basic example to get the feel of the Group Policy Object Editor.

Warning

Implementing GPOs linked to sites can have a substantial impact on your logon times and WAN (Wide Area Network) traffic if not performed correctly. For more information, see Chapter 3.

We already stood on our desks and loudly declared that there will be no Screen Saver tabs at our one default site. The good news is that we've already done two- thirds of what we need to do to make that site accept our will: we exposed the sites we want to manage, and we created the "Hide Screen Saver Tab" GPO in the Group Policy Objects container.

Now, all we need do is to tether the GPO we created to the site with a GPO link.

To remove the Screen Saver tab using the Group Policy Object Editor at the site Level, follow these steps:

Inside the GPMC snap in, drill down by clicking the Group Policy Management folder, the Forest folder, and the Sites folder.
Find the site to which you want to deliver the policy. If you have only one site, it is likely called Default-First-Site-Name.
Right-click the site, and choose "Link an Existing GPO", as shown in Figure 1.14.
Now you can select the "Hide Screen Saver Tab" GPO from a list of GPOs in the Group Policy Objects container in the domain.

Figure 1.14: Once you have your first GPO designed, you can link it to your site.

Once you have chosen the GPO, it will be linked to the site. You can also view it in the "Linked Group Policy Objects" tab in the right pane.

Warning

Did you notice that there was no "Are You Sure You Really Want To Do This?" warning or anything similar? The GPMC trusts that you set up the GPO correctly. If you create GPOs with incorrect settings and/or link them to the wrong level in Active Directory, you can make boo-boos on a grand scale. Again this is why you want to try any setting you want to deploy in a test lab environment first.

Verifying Your Changes at the Site Level

Now, log onto any workstation or server that falls within the boundaries of the site to which you applied the site-wide GPO. You can choose any user you have definedeven the Administrator of the domain.

If you are logged onto a Windows XP Professional machine, you can open up the Display applet in Control Panel and note that the Screen Saver tab is missing, as shown in Figure 1.15 below.

Figure 1.15: The Screen Saver tab in Windows XP is missing because the site policy is affecting the user.

Note

Don't panic if you do not see the changes reflected the first time you log on. See the sections "Group Policy processing behavior" and "Forcing Background Processing" in Chapter 3 to find out how to encourage changes to occur. To see the Screen Saver tab disappear on Windows XP machines right now, log off and log back on. The policy should take effect.

This demonstration should prove how powerful Group Policy is, not only because everyone at the site is affected, but more specifically because administrators are not immune to Group Policy effects. Administrators are not immune because they are automatically members in the Authenticated Users security group. (You can modify this behavior with the techniques explored in Chapter 3.)

Applying Group Policy Objects to the Domain Level

At the domain level, we want an edict that says the Desktop tab should be removed from the Display Properties dialog box. Active Directory domains allow only members of the Domain Administrators group the ability to create Group Policy over the domain. Therefore, if you're not a DA (or a member of the EA group), it's likely that you'll never get to practice this exercise outside the test lab.

To apply the edict, follow these steps:

In the GPMC, drill down by clicking Group Policy Management ˜ Forest ˜ Corp.com.
Right-click the domain name to see the available options, as shown in Figure 1.16.

Figure 1.16: At the domain level, you can create the GPO in the Group Policy Objects container and then immediately link to the GPO from here.

Create and Link a GPO Here versus Link an Existing GPO

In the previous example we forced the site level to embrace our Hide Screen Savers Tab edict. First, we created the GPO in the Group Policy Objects folder, and then in another step we linked the GPO to the site level. However, at the domain level (and, as you're about to see, the OU level), we can take care of both steps at once via the Create And Link A GPO Here command.

This tells the GPMC to create a new GPO in the Group Policy Objects folder and then automatically link the new GPO back to this focused level of Active Directory. This is a time-saving step so we don't have to dive down into the Group Policy Objects folder first and then create the link back to the Active Directory level.

So why is this "Create and Link a GPO Here" option possible only at the domain and OU level, but not the site level? Because Group Policy Objects linked to sites can often cause excessive bandwidth troubles using the old-school way of doing things. With that in mind, the GPMC interface makes sure that when you work with GPOs that affect sites, you're consciously choosing from which domain the GPO is being linked.

I'll talk more about this concept and how it's rectified with the GPMC way of doing things at the top of Chapter 3.

Don't panic when you see all the possible options. We'll hit them all in due time; right now we're interested in the first two: "Create and Link a GPO Here" and "Link an Existing GPO."

Since you're focused at the domain level, you are prompted for the name of a new Group Policy Object when you right-click and choose to "Create and Link a GPO Here." For this one, type a descriptive name, such as "Hide Desktop Tab." Your new "Hide Desktop Tab" GPO is created in the Group Policy Objects container, and, automatically, a link is created at the domain level from the GPO to the domain.

Tip	You can be sure that the GPO was created by simply drilling down through Group Policy Management, Forest, Domains, Corp.com, and Group Policy Objects and looking for your new Hide Desktop Tab GPO.

Right-click either the link to "Hide Desktop Tab" (or the GPO itself) and choose Edit to open the Group Policy Object Editor. To hide the Desktop tab, drill down through User Configuration, Administrative Templates, Control Panel, and Display, and double-click Hide Desktop Tab. Change the setting from Not Configured to Enabled, and click OK. Close the Group Policy Object Editor to return to the GPMC.

Verifying Your Changes at the Domain Level

Now, log on as any user in the domain. You can log on to any computer in the domain or as any user you have definedeven the administrator of the domain. Open the Display Properties dialog box. You'll see that the Desktop tab is now also missing, as in Figure 1.17.

Figure 1.17: The Desktop tab is now also missing because the user is affected by the domain-level policy.

Once again, administrators are not immune to Group Policy effects. You can change this behavior as you'll see in Chapter 3.

Applying Group Policy Objects to the OU Level

OUs are wonderful tools for delegating away unpleasant administrative duties , such as password resets or modifying group memberships. But that's only half their purpose. The other half is to be able to apply Group Policy.

You'll likely find yourself making most of Group Policy additions and changes at the OU level, because that's where you have the most flexibility and the OU is the most-refined instrument to affect users. Once OU administrators become comfortable in their surroundings, they want to harness the power of Group Policy.

Preparing to Delegate Control

To create a GPO at the OU level, you must first create the OU and a plan to delegate. For the examples in this book, we'll create three OUs that look like this:

Human Resources
- Human Resources Users
- Human Resources Computers

Having separate OUs for your users and computers is a good ideafor both delegation of rights and also GPO design. Microsoft considers this a "best practice."

In the Human Resources Users OU in our Corp.com domain, we'll create and leverage an Active Directory security group to do our dirty work. We'll name this group HR-OU-Admins and put our first users inside the HR-OU-Admins inside group. We'll then delegate the appropriate rights necessary for them to use the power of GPOs.

To create the Human Resources Users OU, follow these steps:

Log on to the Domain Controller WINDC01 as Domain Administrator.
In Active Directory Users And Computers, right-click the domain name and choose New ˜ Organizational Unit, which will allow you to enter in a new OU name. Enter Human Resources as the name.
Inside the Human Resources OU, create two more OUs Human Resources Computers and Human Resources Users , as shown in Figure 1.18.

Figure 1.18: When you complete all these steps, your Human Resources OU should have Frank Rizzo and the HR-OU-Admins as well as the Human Resources Users OU and Human Resources Computers OU.

Tip	Alternatively, you can create the OU in the GPMC. Just right-click the domain and choose "New Organizational Unit" from the shortcut menu.

To create the HR-OU-Admins group, follow these steps:

In Active Directory Users And Computers, right-click the new Human Resources Users OU and choose New ˜ Group.
Create the new group HR-OU-Admins as a new Global Security group.

To create the first user to go inside HR-OU-Admins, follow these steps:

In Active Directory Users And Computers, right-click the Human Resources Users OU and choose New ˜ User.
Name the user Frank Rizzo, with an account name of frizzo , and click Next.
If you've established a Windows 2003 domain, you must now enter a complex password for a user.
Finish and close the wizard.

Easily Manage New Users and Computers

The Computers folder and Users folder in Active Directory Users and Computers are not OUs. They are generic containers. You'll notice that they are not present in the GPMC view of Active Directory. Because they are generic containers (and not OUs), you cannot link Group Policy Objects to them.

These folders have two purposes:

If an NT 4 domain is upgraded, the user and computer accounts will wind up in these folders. (Administrators are then supposed to move the accounts into OUs.)
It's the default location where older tools create new users and computers. These older tools are in the Windows NT 4 User Manager (which still works in a Windows 2000 or Windows 2003 domain). Additionally, command-line tools, such as the net user, net group, will add user accounts to this location. Similarly, the Computers folder is the default location for any new client workstation or server that joins the domain. Or, similarly, should you pre-create computer accounts using the net computer command.

If you execute one of these commands, the objects you create will wind up in eitherthe Users folder or the Computers folder. But really, you don't want your users or computers to be in these folders you want them in OUs. That's where the action is because you can apply Group Policy to OUs, not to these folders! Yeah, sure, these users and computers are affected by site and domain level GPOs. But really the action is at the OU level, and you want your computer and user objects to be placed in OUs as fast as possible not sitting around in these generic Computers and Users folders.

To that end, Windows 2003 domains (in full functional level) have two tools to redirect the default location of new users and computers to the OUs of your choice. For example, suppose you want all new computers to go to a NewComputers OU and all new users to go to a NewUsers OU. And you want to link several GPOs to the NewUsers and NewComputers OUs to ensure that new accounts immediately have some baseline level of security, restriction, or protection. Without a little magic, new user accounts created using older tools won't automatically be placed there.

In Windows 2003 Active Directory, Microsoft has provided REDIRUSR and REDIRCMP commands that takes a distinguished name, like:

 REDIRCMP ou=newcomputers,dc=corp,dc=com and/or REDIRUSR ou=newusers,dc=corp,dc=com

Now if you link GPOs to these OUs, your new accounts will get the Group Policy Objects dictating settings to them at an OU level. This will come in handy when users and computers aren't specifically created in their final destination OUs.

To learn more about these tools, see the Microsoft Knowledge Base article 324949.

To add Frank Rizzo to the HR-OU-Admins group, follow these steps:

Double-click the HR-OU-Admins group.
Click the Members tab.
Add Frank Rizzo.

When it's all complete, your OU structure with your first user and group should look like Figure 1.18.

Delegating Control for Group Policy Management

Now that you've created the Human Resources OU, which contains the Human Resources Users OU and the Human Resources Computers OU and the HR-OU-Admins security group, and put Frank inside the HR-OU-Admins group , you're ready to delegate control. You can delegate control to use Group Policy in two ways: using Active Directory Users And Computers, and using the GPMC.

Tip	For this first example, we'll kick it old school and use the Active Directory Users And Computers way. Then, in Chapter 2, I'll demonstrate how to delegate control using the GPMC.

To delegate control for Group Policy management, follow these steps:

In Active Directory Users And Computers, right-click the top-level Human Resources OU you created, and choose Delegate Control from the shortcut menu to start the "Delegation of Control Wizard."
Click Next to get past the Wizard introduction screen.
You'll be asked to select users and/or groups. Click Add, add the HR-OU-Admins group, and click Next to open the "Tasks to Delegate" screen, as shown in Figure 1.19.
Click "Manage Group Policy links", and then click Next.
At the wizard review screen, click Finish.

Figure 1.19: Select the "Manage Group Policy Links" task.

Tip

You might want to click some or all the other check boxes as well, but for this example, only "Manage Group Policy links" is required. Try to avoid selecting "Generate Resultant Set of Policy (Planning)" and "Generate Resultant Set of Policy (Logging)" at this time. You'll see where they come in handy in Chapter 3.

Note

The Manage Group Policy Links task assigns the user or group "Read" and "Write" access over the gPLi nk and gPOptions properties for that level. To see or modify these permissions by hand, open Active Directory Users And Computers, choose View ˜ Advanced Features, If later you want to remove a delegated permission, it's a little challenging. You can locate the permission that you set by right-clicking the delegated object (such as OU), then click on the Properties tab, click the Security tab, choose Advanced, and dig around until you come across the permission you want to remove. Finally, delete the corresponding access control entry (ACE).

Adding a User to the Server Operators Group

Under normal conditions, nobody but Domain Administrators, Enterprise Administrators, or Server Operators can walk up to Domain Controllers and log on. For testing purposes only, though, we're going to add our user, Frank, to the Server Operators group so he can easily work on our WINDC01 Domain Controller.

To add a user to the Server Operators group, follow these steps:

In Active Directory Users And Computers, double-click Frank Rizzo's account under the Human Resources Users OU.
Click the Member Of tab and click Add.
Select the Server Operators group and click OK.
Click OK to close the Properties dialog box for Frank Rizzo.

Normally, you wouldn't give your delegated OU administrators Server Operators access. You're doing it solely for the sake of this example to allow Frank to log on locally to your Domain Controllers.

Testing Your Delegation of Group Policy Management

Log off as Administrator on WINDC01 and log back on as Frank Rizzo. Now follow these steps to test your delegation:

Choose Start ˜ Programs ˜ Administrative Tools ˜ Group Policy Management to open the GPMC.

Note	If the Administrative Tools folder is not present, you'll need to choose Start ˜ Run to open the Run dialog box, and then type mmc in the Open box to load a "naked" MMC. Then load the Group Policy Management snap-in.

Drill down through Group Policy Management, Domains, Corp.com, and Group Policy Objects. If you right-click Group Policy Objects in an attempt to create a new GPO, you'll see the shortcut menu shown in Figure 1.20.

Figure 1.20: Frank cannot create new GPOs in the Group Policy Objects container.

As you can see, Frank is unable to create new GPOs in the swimming pool of the domain. Since Frank has been delegated some control over the Human Resources OU (which also contains the other OUs), let's see what he can do. If you right-click the Human Resources OU in the GPMC, you'll see the shortcut menu shown in Figure 1.21.

Figure 1.21: Frank's delegated rights allow him to link to existing GPOs, but not to create new GPOs.

Because Frank is unable to create GPOs in the swimming pool of the domain (the Group Policy Objects container), he is also unable by definition to create and link a GPO here. Although Frank (and more specifically, the HR-OU-Admins) has been delegated the ability to "Manage Group Policy links", he cannot create new GPOs. Frank (and the other potential HR-OU-Admins ) has only the ability to link an existing GPO.

Understanding Group Policy Object Linking Delegation

When we were logged on as the Domain Administrator, we could create GPOs in the Group Policy Objects container, and we could create and link a GPO here at the domain or OU levels. But Frank cannot.

Here's the idea about delegating the ability to link to GPOs: someone with a lot of brains in the organization does all the work in creating a well-thought-out and well- tested GPO. Maybe this GPO distributes software, maybe it sets up a secure workstation policy, or perhaps it runs a startup script. You get the idea.

Then, others in the organization, like Frank, are delegated just the ability to link to that GPO and use it at their level. This solves the problem of delegating perhaps too much control. Certainly some administrators are ready to create their own users and groups, but other administrators may not be quite ready to jump into the cold waters of Group Policy Object creation. Thus, you can design the GPOs for other administrators; they can just link to the ones you (or others) create.

When you (or someone with the right to link GPOs) selects "Link an Existing GPO", as seen in Figure 1.21, you can choose a GPO that's already been createdand hanging out in the domain swimming poolthe Group Policy Objects container.

In this example, the HR-OU-Admins members, such as Frank, can leverage any currently created GPO to affect the users and computers in their OUeven if they didn't create it themselves . In this example, Frank has linked to an existing GPO called "Word 2000 Settings". Turns out that some other administrator in the domain created this GPO, but Frank wants to use it. So, because Frank has "Manage Group Policy Links" rights on the Human Resources OU (and OUs underneath it), he is allowed to link to it.

But, as you can see in Figure 1.22, he cannot edit the GPOs. Under the hood, Active Directory doesn't permit Frank to edit GPOs he didn't create (and therefore doesn't own).

Figure 1.22: The GPMC will not allow you to edit an existing GPO if you do not own it (or do not have explicit permission to edit it).

Tip	In Chapter 2, I'll show you how to grant specific rights to allow more than just the original creator (and now owner) of the object to edit specific GPOs.

Giving the ability to just link to existing GPOs is a good idea in theory, but often OU administrators are simply given full authority to create their own GPOs (as you'll see later.) For this example, don't worry about linking to any GPOs. Simply cancel out of the Select GPO screen, close the GPMC, and log off from the server as Frank Rizzo.

Granting OU Admins Access to Create New Group Policy Objects

By using the Delegation of Control Wizard to delegate the Manage Group Policy Links attribute, you performed half of what is needed to grant the appropriate authority to Frank (and any additional future HR-OU-Admins) to create GPOs in the Group Policy Objects container and link them to the Human Resources OU, the Human Resources Users OU, or the Human Resources Computers OU. (Though we really don't want to link many GPOs directly to the Human Resources OU.)

You can grant the HR-OU-Admins the ability to create GPOs in the Group Policy Objects container in two ways. For now, I'll show you the old-school way; in Chapter 3, I'll show you the GPMC way.

One of Active Directory's built-in security groups, "Group Policy Creator Owners", holds the key to the other half of our puzzle. You'll need to add those users or groups whom you want to have the ability to create GPOs to a built-in group, cleverly named Group Policy Creator Owners. To do so, follow these steps:

Log back on as Domain Administrator.
Fire up Active Directory Users And Computers.

By default, the Group Policy Creator Owners group is located in the Users folder in the domain. Double-click the "Group Policy Creator Owners" group and add the HR-OU-Admins group and/or Frank Rizzo.

Tip

If you just created a new Windows 2003 domain or upgraded your domain from NT 4, you will not be able to add the HR-OU-Admins group until the domain mode has been switched to Windows 2000 Native or Windows 2003 Functional level. Switch the domain by using Active Directory Domains and Trusts. Switching the domain mode is a one-way operation, which shuts out older Domain Controllers. If you are not prepared to make the switch to Native mode, you'll only be able to add individual members, such as Frank Rizzo and not a group.

Log off as Domain Administrator from WINDC01.

Tip	In Chapter 2, you'll see an alternate way to allow users to create GPOs.

Creating and Linking Group Policy Objects at the OU Level

At the site level, we hide the Screen Saver tab in the Display Properties dialog box. At the domain level, we chose to hide the Desktop tab in the Display Properties dialog box. At the OU level, we have two jobs to do:

Hide the Settings tab in the Display Properties dialog box.
Restore the Screen Saver tab that was taken away at the site level.

To create a GPO at the OU level, follow these steps:

Log off as Administrator on WINDC01 and log back on as Frank Rizzo.

Choose Start ˜ Programs ˜ Administrative Tools ˜ Group Policy Management to open the GPMC.

Note	If the Administrative Tools are not present on the machine you are using, choose Start ˜ Run to open the Run dialog box, and in the Open box, type mmc to load a "naked" MMC. Then load the Group Policy Management snap-in.

Drill down until you reach the Human Resources Users OU, right-click it, and choose "Create and Link a GPO Here" from the shortcut menu to open the "New GPO" dialog box.
In the "New GPO" dialog box, type in the name of your new GPO, say "Hide Settings Tab/ Restore Screen Saver Tab." This will create a GPO in the Group Policy Objects container and link it to the Human Resources Users OU.
Right-click the Group Policy link and choose Edit from the shortcut menu to open the Group Policy Object Editor.
To hide the Settings tab, drill down through User Configuration ˜ Administrative Templates ˜ Control Panel ˜ Display and double-click the Hide Settings Tab policy setting. Change the setting from "Not Configured" to "Enabled", and click OK.
To restore the Screen Saver tab, double-click the Hide Screen Saver Tab policy setting. Change the setting from "Not Configured" to "Disabled", and click OK.
Close the Group Policy Object Editor to return to the GPMC.

Tip	By disabling the Hide Screen Saver Tab policy setting, you're reversing the Enable setting set at a higher level. See the sidebar "A Note about the Three Possible Settings: Not Configured, Enabled, and Disabled" later in this chapter.

Verifying Your Changes at the OU Level

On your test Windows XP machine in the domain, log back on as Frank. Right-click the Desktop and choose Display from the shortcut menu to open the Display Properties dialog box. Note that the Settings tab is missing, but that the Screen Saver tab is back, as shown in Figure 1.23.

Figure 1.23: The Settings tab is missing along with the Desktop tab, but the Screen Saver tab has returned.

This test proves, once again, that even OU administrators are not automatically immune from policy settings. Chapter 3 explains how to change this behavior.

Group Policy Strategy: Should I Create More or Fewer GPOs?

At times, you'll want to lock down additional functions for a collection of users or computers. For example, you might want to specify that no users in the Human Resources Users OU can use Control Panel.

At the Human Resources Users OU level, you've already set up a GPO that contained a policy setting to hide the Settings tab in the Display Properties dialog box. You now have a decision to make. You can create a new GPO that affects the Human Resources Users OU, give it a descriptive name, say "No One Can Use Control Panel", and then drill down through User Configuration ˜ Administrative Templates ˜ Windows Components ˜ Control Panel and enable the policy setting named Prohibit Access to Control Panel.

Or you could simply modify your existing GPO, named "Hide Settings Tab/Restore Screen Saver Tab" so that it contains additional policy settings. You can then rename your GPO to something that makes sense and encompasses the qualities of all the policy changes, say, "Our Human Resources Users ' Desktop Settings."

Here's the quandary : The former method (one policy setting per GPO) is certainly more descriptive and definitely easier to debug should things go awry. If you have only one policy set inside the GPO, you have a better handle on what each one is affecting. If something goes wrong, you can dive right into the GPO, track down the policy setting, and make the necessary changes, or disable the ornery GPO (as discussed later).

The second method (multiple policy settings per GPO) is teeny-weeny bit faster for your computers and users at boot or logon time, because each additional GPO takes some miniscule fraction of additional processing time. But if you stuff too many settings in an individual GPO, the time to debug should things go wrong goes up exponentially. Group Policy has so many nooks and crannies that can be difficult to debug.

So, in a nutshell , if you have multiple GPOs at a particular level, you can do the following:

Name each of them more descriptively.
Debug them easily if things go wrong.
Disable individually misbehaving GPOs.
Associate that GPO more easily to a WMI filter (explored in Chapter 10).
More easily delegate permissions to any specific GPO (explored in Chapter 3).

If you have fewer GPOs at a particular level, the following is the case:

Logging on is slightly faster for the user (but really only slightly).
Debugging is somewhat more difficult if things go wrong.
You can disable individually misbehaving GPOs or links to misbehaving GPOs. (But if they contain many settings, you might be disabling more than you desire .)

So, how do you form a GPO strategy? There is no right or wrong answer; you need to decide what's best for you. Several options, however, can help you decide.

One middle-of-the-road strategy is to start with multiple GPOs and one lone policy setting in each. Once you are comfortable that they are individually working as expected, you can create another new GPO that contains the sum of the settings from, in this example, Hide Settings Tab and Prohibit Access to Control Panel and then delete (or disable) the old individual GPO.

Another middle-of-the-road strategy is to have a single GPO that contains only the policy settings required to perform a complete "wish." This way, if the wish goes sour, you can easily address it or disable it (or whack it) as needed.

Here's yet another strategy. Some Microsoft documentation recommends that you create GPOs such that they affect only the User half or the Computer half. You can then disable the unused portion of the GPO (either the Computer half or the User half). This allows for policy settings affecting one node to be grouped together for ease of naming and debugging and allows for flexible troubleshooting. However, be careful here because after you disable half the GPO, there's no iconic notification, and, in my opinion, troubleshooting can become harder if not performed perfectly and consistently. In all, I'm not a huge fan of disabling "half" the GPO.

Creating a New Group Policy Object in an OU

For the sake of learning and working through the rest of the examples in this section, you'll create another GPO and link it to the Human Resources Computers OU. This GPO will remove the ability to create new scheduled tasks using the Task Scheduler for all the Windows 2000 and Windows XP machines in the Human Resources Computers OU.

Note	The same setting exists under the User node, but we'll experiment with the Computer node policy.

First, you'll need to create the new GPO and modify the settings. You'll then need to move some client machines into the Human Resources Computers OU in order to see your changes take effect.

To disable the ability to use the Task Scheduler for the Human Resources Computers OU, follow these steps:

If you're not already logged in as Frank Rizzo, the Human Resources OU administrator, do so now.
Choose Start ˜ Programs ˜ Administrative Tools ˜ Group Policy Management to start the GPMC.

Note
If the Administrative Tools are not present, choose Start ˜ Run to open the Run dialog box, and in the Open box, type mmc to load a "naked" MMC. Then load the GPMC.
Drill down until you reach the Human Resources Computers OU, right-click it, and choose "Create and Link a GPO Here" from the shortcut menu.
Name the GPO something descriptive, such as "Prohibit New Tasks in Task Scheduler."
Right-click the GPO, and choose Edit to open the Group Policy Object Editor.
We want to affect our Windows XP computers, so we need to use the Computers node. To disable the Task Scheduler, drill down through Computer Configuration ˜ Administrative Templates ˜ Windows Components ˜ Task Scheduler, and double-click Prohibit New Task Creation . Change the setting from Not Configured to Enabled, and click OK, as shown in Figure 1.24.
Close the Group Policy Object Editor to return the GPMC.

Figure 1.24: By enabling this policy setting, you're disabling the Task Scheduler.

Tip	Be aware of occasional strange Microsoft verbiage when you need to enable a policy to disable a setting. In Windows 2003, most policy settings have been renamed to Prohibit <whatever> to reflect the change from confusion to clarity.

Moving Computers into the Human Resources Computers OU

Since you just created a policy that will affect computers, you'll need to place a workstation or two inside the Human Resources Computers OU to see the results of your labor. You'll need to be logged on as Administrator to WINDC01 to do this.

Tip	Quite often computers and users are relegated to separate OUs. That way, certain GPOs can be applied to certain computers but not others. For instance, isolating laptops, desktops, and servers is a common practice.

In this example, we're going to use the Find command in Active Directory Users And Computers to find a workstation named XPProl and move it into the Human Resources Computers OU.

To find and move computers into a specific OU, follow these steps:

In Active Directory Users And Computers, right-click the domain, and choose Find from the shortcut menu, as shown in Figure 1.25, to open the Find Users, Contacts, and Groups dialog box.
From the Find drop-down menu, select Computers. In the Name field, type XPProl to find the computer account of the same name. Once you've found it, right-click the account and choose Move from the shortcut menu. Move the account to the Human Resources Computers OU.

Figure 1.25: Use the Find command to find computers in the domain so you can move them.

Repeat these steps for all other computers that you want to move to the Human Resources Computers OU.

Warning

After you move the computer accounts into the Human Resources Computers OU, reboot your client machines. As you'll see in Chapter 3, the computer does not recognize the change right away when computer accounts are moved between OUs.

As you can see in this example (and in the real world), a best practice is to separate users and computers into their own OUs and then link GPOs to those OUs. Indeed, underneath a parent OU structure, such as the Human Resources OU, you might have more OUs, (i.e., Human Resources Laptops OU, Human Resources Servers OU, etc.). This will give you the most flexibility in design between delegating control where it's needed and the balance of GPO design within OUs. Just remember that in order for GPOs to affect either a user or computer, that user or computer must be within the scope of the GPOsite, domain, or OU.

Verifying Your Cumulative Changes

At this point, you've set up three levels of Group Policy that accomplishes multiple actions:

At the site level, the "Hide Screen Saver Tab" GPO is in force for users.
At the domain level, the "Hide Desktop Tab" GPO is in force for users.
In the Human Resources Users OU, the "Hide Settings Tab / Restore Screen Saver Tab" GPO is in force for users.
In the Human Resources Computers OU the "Prohibit New Tasks in Task Scheduler" GPO is in force for computers.

At this point, take a minute to flip back to Figure 1.8 (the swimming pool graphic) to see where we're going here. To see the accumulation of your policy settings inside your GPOs, you'll need to log on as a user who is affected by the Human Resources Users OU and at a computer that is affected by the Human Resources Computers OU. Therefore, log on as Frank Rizzo on XPProl.

Right-click the Desktop and choose Display from the shortcut menu to open the Display Properties dialog box. Note that the Settings tab is still missing from the previous exercise (and the Screen Saver tab is restored). In Control Panel, select Classic View, and double-click Scheduled Tasks. Now missing is the ability to create new tasks. (Although you can choose File ˜ New ˜ Schedule Task, you won't to able to create a new task once this policy setting is in force.)

This test proves that even OU administrators are not automatically immune from GPOs and the policy settings within. Under the hood, they are in the Authenticated Users security group. See Chapter 3 for information on how to modify this behavior.

Note	Again, don't panic if you don't see the changes reflected right away. See Chapter 3, for more text on how to encourage changes to occur.

A Note about the Three Possible Settings: Not Configured, Enabled, and Disabled

As you saw in Figure 1.24 earlier in this chapter, nearly all policy settings can be set as Not Configured, Enabled, or Disabled. These three settings have very different consequences, so it's important to understand how each works.

Not Configured The best way to think about Not Configured is to imagine that it really says, "Don't do anything" or even "Pass through." Why is this? Because if a policy setting is set to Not Configured, then what it's being told to do is to look at a higher level and see if anything is set there. If there is nothing set at a higher level, then there's nothing to do the operating system simply does whatever its default is.

Enabled When a specific policy setting is enabled, the policy will take effect. In the case of the Hide Screen Saver Tab policy, the effect is obvious. However, lots of policy settings, once enabled, have myriad possibilities inside the specific policy setting! (For a gander at one such policy setting use the Group Policy Object Editor and drill down to User Configuration ˜ Administrative Templates ˜ Windows Components ˜ Internet Explorer ˜ Toolbars and select the policy setting named Configure Toolbar Buttons .) So, as we can see, enabled really means " Turn this policy setting on." It will then either do what it says, or there will be more options inside the policy setting that can be configured.

Disabled This setting leads a threefold life.

Disabled usually means that if the same policy setting is enabled at a higher level, reverse its operation. For example, we chose to enable the Hide Screen Saver Tab policy setting at the site level. If at a lower level (say, the domain or OU level), we chose to disable this policy setting, the Screen Saver tab will pop back at the level at which we disabled this policy.
Additionally, Disabled often forces the user to accept the administrator's will. That is, if a policy setting is disabled, some default behavior of the policy setting is enforced, and the user cannot change it. To see an example policy setting like this, use the Group Policy Object Editor and drill down through User Configuration ˜ Administrative Templates ˜ Control Panel and select the policy setting named Force Classic Control Panel Style. Once this policy setting is disabled, the policy forces Windows XP users to use the Control Panel in the new task-based style. The point here is that the Disabled setting is a bit tricky to work with. You'll want to be sure that when you disable a policy setting, you're doing precisely what you intend.
Disabled sometimes has a special and, typically, rare use. That is, something might already be hard-coded into the Registry to be "turned on" or work one way, and the only way to turn it off is to select Disabled. One such policy setting is the Shutdown Event Tracker. You disable the policy setting, which turns it off, because on Windows 2003 it's already hard-coded on. In Windows XP, it's already hard-coded off. Likewise, if you want to kill Windows XP/SP2's firewall, you need to set Windows Firewall: Protect All Network Connections to Disabled. (You can find that policy setting at Administrative Templates ˜ Network ˜ Network Connections ˜ Windows Firewall ˜ Domain Profile while editing GPOs on Windows XP/Service Pack 2 computers.)

So, think of Not Configured as having neither Allow nor Deny being set. Enabled will turn it on, and possibly have more functions. Disabled has multiple uses, and be sure to test, test, test to really make sure that once you've manipulated a policy setting, it's doing precisely what you had in mind.

Our Own Group Policy Examples