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.
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.