In-Depth

Group Policy Strategy and Tactics

Group policy is constantly evolving and has new functionality within Windows Server 2003. Here’s some basic training on what it can do.

• By Jeremy Moskowitz
• March 01, 2004

Any great general will tell you that there’s no specific recipe for success in battle. But you can stick to a few key rules that could help you win the day. Sometimes just going into the office can feel like a day on the battlefield; so, with that in mind, let’s take some tried-and-true battle principles, and see if we can relate these principles to something practical in our daily Active Directory and group policy administration duties.

Principle 1: Get to “Higher Ground”
Getting to higher ground in a land skirmish lets you survey all the territory you want to conquer at once. Then you can work toward a specific battle plan and hit your targets. A parallel idea can be found inside the free, downloadable tool called the Group Policy Management Console (GPMC). (For background on the GPMC, see “Lighten up the Group Policy Load” by Zubair Alexander, online at http://mcpmag.com/Features/
article.asp?EditorialsID=376).

The GPMC gets you to higher ground by providing a “bird’s-eye-view” of all the sites, domains and Organizational Units (OUs) you want to survey, as well as all the Group Policy Objects (GPOs) associated with any particular domain, as seen in Figure 1.

Figure 1. The Group Policy Management Console offers a high-level overview of your group policy structure. (Click image to view larger version.)

This gives you an amazing one-stop-shop way to see the relationship between any specific GPO and the locations where it’s linked, or vice-versa—that is, the relationship of what locations are linked to what GPOs. In Figure 1, we can see both cases—in the same view! By clicking on the GPO named “Deploy Office XP to Computers,” the Links heading in the Scope tab in the right pane shows that this GPO is linked to the Sales Office OU (as well as the Temporary Office Help OU). Additionally, clicking on the Sales Office OU shows the inverse; that is, which GPOs are currently linked to it. In this case, just the “Deploy Office XP to Computers” GPO is linked to it. This “two-way” view is the first big power the GPMC provides.

Remember that the GPMC is free and can manage any AD domain, either Windows 2000 Server or Windows Server 2003. All that’s required is a single Windows XP Professional machine (or Windows 2003 Server machine) to load the bits of the GPMC, and you’re off and running with all this new power. Oh, and it doesn’t matter if you have NT 4.0 BDCs in your Mixed mode AD—you can still use the GPMC.

Principle 2: Delegate Wisely
A general doesn’t dare do all the work personally: There’s too much to go around. Peeling potatoes and digging foxholes is fun—for about 10 minutes. Thereafter, you’ll want someone else to share in the day-to-day dirty work. To that end, don’t work harder; work smarter. To do that, delegate authority within the group policy management ranks. There are multiple tasks you can delegate—so many, in fact, we can only review several of the most commonly desired delegated tasks here.

The “old-school” method of group policy management utilized AD Users and Computers, using the Delegation of Control Wizard to delegate certain group policy management tasks. But the GPMC has its own way of performing the same function. Simply click on the OU over which you want to grant someone permission and select the Delegation tab, as seen in Figure 2. When you do, you’ll expose the Permission drop-down and select one of three tasks to delegate: Link GPOs, Perform Group Policy Modeling analyses, or Read Group Policy Results data. You’ll then be able to select Add and choose the user to whom you want to grant the Permission.

Figure 2. Delegating group policy management is easier with the latest version of GPMC. (Click image to view larger version.)

You can also assign someone the rights to create new GPOs in the domain. You can do this in one of several ways.

The “old-school” way of doing this was placing someone’s user account in the Group Policy Creator Owners security group, or, if the domain was in Native mode, you could put a group that person was in inside the Group Policy Creator Owners group. However, this approach had several drawbacks. First, if the domain wasn’t in Native mode, you couldn’t nest another Global Group inside the Group Policy Creator Owners security group; you had to specifically plunk in each specific user account. Next, the Group Policy Creator Owners actually has more rights over sensitive AD locations than it needs. This could be a potential security risk in the wrong hands.

The second way to delegate GPO-creation rights is through the GPMC, which has a new way to add anyone to create GPOs in the domain of your choice, even administrators in other domains. Simply click on the Group Policy Objects node, then click the Delegation tab. Click Add and plug in any user you want to grant access to to create GPOs in this domain.

There’s another Group Policy task you can delegate. You can give some lowly private—er, user—the ability to manage the properties of a single GPO. Simply click on any particular GPO, click the Delegation tab and click Add to specify a user. Once you do, you’ll be able to set the permissions a particular user can perform upon a specific GPO with one of three possible choices:

Read. Allows the user you specified to dive in and see what stuff is set within the GPO.

Edit settings. Allows the specified user to see what stuff is set within the GPO and also to change that stuff.

Edit settings, delete, modify security. Continues the trend, but also gives the ability to grant other users the ability to perform the tasks in this dialog.

Principle 3: Have a Central Command Post
Any grizzled general won’t admit it to your face, but there’s something comforting about the central command post. At the central command post, a general knows he or she has the full complement of weaponry at command, not just whatever’s available at the battle site. The same holds true for group policy: Having a central command post ensures that the full complement of policy settings is always available for you to deploy.

You will notice different options when editing a GPO while using Windows 2000 versus Windows 2003. First, you can see that the very group policy node structure is different when editing GPOs on Win2K (Figure 3) and Windows 2003 machines (Figure 4). For instance, both GPO editors allow you to drill down to Computer Configuration | Administrative Templates | System. However, underneath System, the Win2K version of the editor shows Logon, Disk Quotas, DNS Client, Group Policy and Windows File Protection. However, the System node as seen in the Windows 2003 editor shows many more nodes, including Remote Assistance, System Restore and Remote Procedure Call, to name a few. Moreover, within a node—the Logon node, for example—you can see different policy settings. In this particular case, it certainly looks like the Win2K version of the Logon node has more policy settings. However, when viewed from Windows 2003, these policy settings are simply found elsewhere.

Figure 3. The Logon node while using Windows 2000 Server to edit GPOs. (Click image to view larger version.)

 

Figure 4. The Logon node while using Windows Server 2003 or Windows XP to edit GPOs. (Click image to view larger version.)

Additionally, you can see the Windows 2003 version of the GPO editor has two other essential benefits. First, all the policy settings that can apply to Win2K, Windows 2003 and XP appear. Indeed, about 200 more policy settings are available—and placed more logically within respective nodes. In Figure 4 for instance, the “Always use classic logon” policy setting, which applies only to XP or Windows 2003 machines, is simply not found should you choose to create a new GPO while using the GPO editor on your Win2K DC.

To ensure you’ve got the latest battalion of policy settings, my advice is to set up a central command post to manage your group policy infrastructure. Specifically, this is properly called a “Management Workstation.” Doing so will give you a “one-stop-shop” that contains all the latest policy settings. These policy settings are generated from the built-in Administration (ADM) template files located in the %systemroot%\inf folder and copied up to the server whenever a new GPO is created or modified.

I’d recommend creating an XP machine with the latest service pack, Adminpak.msi tools (the link is in Knowledge Base 304718) and the GPMC (downloadable at www.microsoft.com/grouppolicy), and use that to manage your group policy environment. Then, whenever Microsoft updates the ADM files (either in an XP or Windows 2003 service pack), you can simply plop the ADM files into the %systemroot%\inf directory of your management workstation. You’ll know you have the latest, up-to-date policy settings at your disposal. Indeed, if you leverage custom ADM templates, such as those available within the Office Resource Kits, you should also plop them into the %systemroot%\inf folder of your Management Workstation in order to use them properly.

Once you do this, you’ll have your XP command post—er, management workstation—armed with the latest policy settings to deploy on your network. However, like any general, you’ll need discipline and consistency for this to work effectively. If you choose to revert back to the old ways of doing things and create new GPOs by using Win2K systems, you won’t have all the policy settings at your command to control Win2K, XP or Windows 2003 systems.

An Army of One
Sure, going into the office and working with group policy isn’t nearly as dangerous as donning a flak jacket and leading troops into battle. However, both jobs do incur a bit of planning, and one false step could set you back. The three principles I’ve outlined here should help you gain better control over your environment and live another day to tell about it.