realtimepublishers.

com

tm

The Definitive Guide To

tm

Windows 2000
Group Policy

Darren Mar-Elia

Table of Contents
Chapter 1: Introducing Group Policy .............................................................................................. 1
Overview of Group Policy .............................................................................................................. 1
Processing GPOs ............................................................................................................................. 2
Server-Side Processing........................................................................................................ 2
Using LSDOU Ordering.......................................................................................... 3
Client-Side Processing ........................................................................................................ 5
Viewing and Editing GPOs ............................................................................................................. 6
Capabilities of GPOs..................................................................................................................... 12
Software Settings | Software Installation .......................................................................... 13
Assignment vs. Publishing .................................................................................... 14
Windows Settings | Security Settings................................................................................ 16
Account Policies................................................................................................................ 17
Local Policies .................................................................................................................... 18
Audit Policy........................................................................................................... 18
User Rights Assignment........................................................................................ 19
Security Options.................................................................................................... 20
Event Log .......................................................................................................................... 20
Restricted Groups.............................................................................................................. 21
System Services................................................................................................................. 22
Registry ............................................................................................................................. 23
File System........................................................................................................................ 24
Public Key Policies (Machine and User) .......................................................................... 25
Windows Settings | Scripts (Startup/Shutdown) ............................................................... 26
Windows Settings | Scripts (Logon/Logoff) ..................................................................... 26
Windows Settings | Internet Explorer Maintenance.......................................................... 27
Browser User Interface.......................................................................................... 27
Connection ............................................................................................................ 27
URLs ..................................................................................................................... 28
Security.................................................................................................................. 28
Programs................................................................................................................ 28
Windows Settings | Folder Redirection............................................................................. 29
Windows Settings | Remote Installation Services............................................................. 30
Administrative Templates ................................................................................................. 31

Table of Contents
Summary ....................................................................................................................................... 33
Chapter 2: Group Policy Structure and Processing....................................................................... 34
Structure of the GPO ..................................................................................................................... 34
The GPC............................................................................................................................ 35
Finding GPO Friendly Names from Their GUIDs................................................ 37
The GPT ............................................................................................................................ 39
Storing Group Policy Settings....................................................................................................... 41
Storing GPC Information .................................................................................................. 42
The Class Store Container..................................................................................... 43
Storing GPT Information .................................................................................................. 47
Applications Folder ............................................................................................... 48
Documents and Settings Folder............................................................................. 48
Microsoft Folder.................................................................................................... 49
Scripts Folder ........................................................................................................ 50
Registry.pol ........................................................................................................... 51
GPO Versioning ................................................................................................................ 51
Group Policy Processing ................................................................................................... 54
Bringing It All Together........................................................................................ 55
Summary ....................................................................................................................................... 55
Chapter 3: Creating Group Policies Step by Step ......................................................................... 56
Creating AD-Based GPOs............................................................................................................. 56
Editing GPOs................................................................................................................................. 58
Setting GPO Options......................................................................................................... 60
No Override........................................................................................................... 61
Disabled................................................................................................................. 62
Blocking Policy Inheritance .............................................................................................. 63
Setting GPO Properties ..................................................................................................... 65
General .................................................................................................................. 66
Links...................................................................................................................... 66
Security.................................................................................................................. 67
Controlling GPO Precedence ............................................................................................ 67
Adding New GPO Links ................................................................................................... 69
Deleting GPOs................................................................................................................... 70

ii

Table of Contents
Setting Domain Controller Options............................................................................................... 71
Using Security Groups to Filter the Processing of GPOs ............................................................. 72
Changing the Default Processing ...................................................................................... 73
Using the Deny ACE......................................................................................................... 74
Treading Carefully ............................................................................................................ 75
Using GPO Functionality .............................................................................................................. 76
Administrative Template Policy........................................................................................ 76
Software Installation ......................................................................................................... 82
Folder Redirection............................................................................................................. 88
Setting Up Advanced Folder Redirection ............................................................. 88
Security Settings................................................................................................................ 91
About Security Templates..................................................................................... 91
Creating Security Templates ................................................................................. 92
Importing Security Templates into a GPO............................................................ 93
Summary ....................................................................................................................................... 93
Chapter 4: Designing and Implementing Group Policy in the Enterprise..................................... 95
Integrating Group Policy Design in Your AD Infrastructure........................................................ 95
Managing the Complexity of GPOs .............................................................................................. 96
Designing the Implementation ...................................................................................................... 97
Scenario AOne AD Domain.......................................................................................... 98
Two Implementation Options.............................................................................. 101
Scenario BMultiple AD Domains ............................................................................... 103
Two Implementation Options.............................................................................. 105
Handling Delegation Requirements .................................................................... 108
Multi-domain Considerations.......................................................................................... 109
Site-Linked GPOs ........................................................................................................... 109
Adopting GPO Naming Conventions.............................................................................. 111
Maintaining Change Control........................................................................................... 113
Tying It All Together ...................................................................................................... 114
Considering Technical Issues...................................................................................................... 115
Asynchronous, Slow Network, and Periodic Background GPO Processing................... 115
Controlling Their Effects .................................................................................... 116
GPO Loopback Processing.............................................................................................. 119

iii

Table of Contents
Summary ..................................................................................................................................... 119
Chapter 5: Working around Group Policy Limitations............................................................... 120
Controlling GPO Delegation....................................................................................................... 120
Default Rights ................................................................................................................. 121
How GPO Delegation Works.......................................................................................... 123
Delegating Creation, Editing, and Deletion GPOs.............................................. 123
Linking GPOs...................................................................................................... 128
Putting GPO Delegation into Practice............................................................................. 133
Making Changes to the Policies Folder............................................................... 134
Modifying Permissions on Existing GPOs.......................................................... 138
Linking GPOs to a Site Object............................................................................ 138
Using Security-Group Filtering on GPOs ................................................................................... 139
Security-Group Filtering for Applications ...................................................................... 140
Using Loopback Processing ........................................................................................................ 144
Summary ..................................................................................................................................... 148
Chapter 6: Troubleshooting and Managing Group Policy .......................................................... 149
Examining Common GPO Problems .......................................................................................... 149
Using GPO Troubleshooting Tools............................................................................................. 155
Group Policy Result Tool (gpresult.exe)......................................................................... 155
Group Policy Object Verification Tool (gpotool.exe) .................................................... 157
Network Connectivity Tester (netdiag.exe) .................................................................... 159
Software Installation Diagnostics (addiag.exe)............................................................... 162
FAZAM 2000.................................................................................................................. 163
Enabling GPO Logging............................................................................................................... 164
The Application Event Log ............................................................................................. 165
Usermode Logs ............................................................................................................... 167
The userenv.log File............................................................................................ 168
Other Log Files.................................................................................................... 169
Windows Installer Logging............................................................................................. 170
Managing GPOs .......................................................................................................................... 171
RSoP................................................................................................................................ 172
Backing Up and Restoring GPOs.................................................................................... 173
The Role of the Local GPO............................................................................................. 174

iv

Table of Contents
Summary ..................................................................................................................................... 176
List of Acronyms and Abbreviations .......................................................................................... 177

Copyright Statement
2001 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that have
been created, developed, or commissioned by, and published with the permission of,
Realtimepublishers.com, Inc. (the Materials) and this site and any such Materials are protected
by international copyright and trademark laws.
THE MATERIALS ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. The Materials are subject to change without notice and do not represent a
commitment on the part of Realtimepublishers.com, Inc or its web site sponsors. In no event
shall Realtimepublishers.com, Inc. or its web site sponsors be held liable for technical or editorial
errors or omissions contained in the Materials, including without limitation, for any direct, indirect,
incidental, special, exemplary or consequential damages whatsoever resulting from the use of
any information contained in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not be
copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, in
whole or in part, except that one copy may be downloaded for your personal, non-commercial use
on a single computer. In connection with such use, you may not modify or obscure any copyright
or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of third
parties. You are not permitted to use these trademarks, services marks or logos without prior
written consent of such third parties.
If you have any questions about these terms, or if you would like information about licensing
materials from Realtimepublishers.com, please contact us via e-mail at
info@realtimepublishers.com

vi

Chapter 1

Chapter 1: Introducing Group Policy

As far back as 1996, top developers and architects from Microsofts NT engineering team
traveled around to the companys large enterprise customers, asking what improvements the
customers wanted most from the next version of NT. At that time, NT 4.0 was out, and Microsoft
was planning the next major release. One common theme that was delivered loud and clear from
customers was the need to reduce the cost of managing and maintaining NT desktops and servers
in large enterprise environments.
The whole topic of total cost of ownership (TCO)presented most vocally by the Gartner Group
in its discussions of the cost of maintaining desktops in a corporate environmenttook on new
significance during that time. Even to this day, TCO plays a major part in how organizations
look at the return on their Windows infrastructure investment. Until NT 4.0, Microsoft had spent
less time worrying about TCO and more time adding features and increasing the stability and
reliability of its fledgling operating system (OS).
With the upcoming Windows 2000 (Win2K, originally called NT 5.0), Microsoft focused
squarely on the TCO challenge. In NT 4.0 (and Windows 95), Microsoft introduced System
Policy, a mechanism for using the registry to lock down portions of a users desktop to prevent
him or her from futzing with the configuration. It was believed that enough futzing would
break something on the desktop, thus generating a costly call to the Help desk. In the final
analysis, futzing may turn out to be an overrated issue, but it nonetheless helped to increase the
awareness of TCO in the enterprise.
System Policy was mildly effective, but it didnt completely address most enterprise TCO issues.
For example, it hardly addressed software distribution, configuration management, or security
configuration. So Microsoft got to work developing Group Policy Objects (GPOs) in Win2K as
the successor to System Policy. You can think of GPOs as System Policy on steroids.
In this chapter, Ill introduce the capabilities of GPOs and take a detailed look at the features
they provide, out-of-the-box. I say out-of-the-box because, in addition to delivering more
functionality with the GPO infrastructure than System Policy, Microsoft also made the GPO
technology extensible so that third parties could add management capabilities for their
applications and services.
This chapter is written for readers who are already familiar with the concepts of Active Directory (AD)
and Microsoft Management Console (MMC). If you need a refresher, check out
http://www.realtimepublishers.com for references to other free eBooks about AD, including The
Definitive Guide to Windows 2000 Administration, by Sean Daily and Darren Mar-Elia, and The
Definitive Guide to Active Directory Troubleshooting by Sean Daily.

Overview of Group Policy

Group Policy is implemented on Win2K only. NT 4.0 doesnt support storing or processing
GPOs. However, Win2K devices can process the old-style NT 4.0 System Policy (for example,
ntconfig.pol) files when a user logs on to an NT 4.0 domain from a Win2K workstation or server.
Group Policy can be defined on a local Win2K device or in an AD infrastructure. A local GPO
exists on every Win2K workstation and server installation by default.

Chapter 1

The local GPO is stored by default in the folder %Systemroot%\System32\Grouppolicy.

The local GPO is a stand-alone object in that you must manage it individually against each
Win2K device using the MMC Group Policy snap-in. Also, some of the capabilities that GPOs
provide in an ADbased domain environment arent available on local GPOs. (Examples are
software deployment and Folder Redirection, described later in this chapter in the Windows
Settings | Folder Redirection section.) For these and other reasons, GPOs only begin to fulfill
their full promise when youve deployed an AD infrastructure and have begun to migrate all
your workstations and servers to Win2K. Before talking about how GPOs leverage AD, and AD
domain controllers, its important to understand how GPOs are processed.

Processing GPOs
In NT 4.0, when a user logged on to an NT 4.0 domain from an NT 4.0 device, the Winlogon
process running on the workstation or server executed a System Policy file stored on the
authenticating NT 4.0 domain controller in the NETLOGON share (or elsewhere, as specified by
the administrator). NT 4.0 System Policy let administrators distribute changes to registry keys
per-user changes were stored in HKEY_CURRENT_USER keys, per-machine changes in
HKEY_LOCAL_MACHINE keys. These registry changes were executed according to the
instructions of the System Policy file when the user logged on. Both per-user and per-machine
changes happened at once.
Server-Side Processing
GPOs maintain a few similarities with System Policy processing. Only user objects and
computer objects in an AD domain can process GPOs. However, unlike NT 4.0 System Policy
where only one policy file could be processed by a user per domainmultiple GPOs can be
linked to AD container objects at various levels in the AD hierarchy, providing support for
processing many GPOs for a given user and computer.
In addition to storing links in AD, GPOs leverage file storage on AD domain controllers like NT
4.0 System Policy leveraged the NETLOGON share on NT 4.0 domain controllers. GPOs are
stored in the SYSVOL share on domain controllers in an AD domain.
GPOs are made up of the Group Policy Template (GPT) and the Group Policy Container (GPC).
The GPT stores the files that are stored by GPOs in SYSVOL. These files make up the guts of
the GPO. (A portion of the GPO is stored in AD.)
The GPC is created for each GPO you define. The GPC is a class of AD object that represents a
GPO in the AD and keeps some additional information related to the software deployment
features of GPOs.
Sites, domains, and organizational unites (OUs) link to GPOs using an AD attribute on these
container objects that refers to the linked GPO by its globally unique ID (GUID). More details of
what is actually stored in the GPT and GPC, as well as how they relate to GPO functionality, are
discussed in detail in Chapter 2 of this book.

Chapter 1

Container objects are AD objects that can contain other AD objects. For example, an AD domain is a
container object that can contain OUs, users, and so on. An OU is a container object that can contain
other OUs, users, groups, and so on. Finally, an AD site is a container object that can contain subnet
objects.

Unlike NT 4.0s System Policy, which was processed when the user logged on, GPO-based
policy directed at computers is processed by those computers that are members of an AD domain
when they first start up and establish communication with the domain controller. This computerspecific policy processing happens independently of any user-based policy processing. Then,
when a user defined in the AD logs on to an AD domain from a Win2K workstation (or server),
any user-specific GPO policy is processed at that time.
This split between computer and user processing implies that there are two parts to a GPO, and
that is indeed the case. As youll see further on in this chapter, GPOs are organized in the Group
Policy MMC snap-in into Computer Configuration and User Configuration sections. The section
to which a policy is defined determines whether the computer or the user will process it. (In other
words, computers process the Computer Configuration section, and users process the User
Configuration section.)
Using LSDOU Ordering
In addition to delineating computer and user policies in a GPO, users and computers process
GPOs using the following order of precedence:
1. Local GPO
2. AD site-based GPO(s)
3. AD domain-based GPO(s)
4. AD OU-based GPO(s)

You often see this order represented by the acronym LSDOU (Local, Site, Domain, OU). This
acronym means that computers and users process GPOs using LSDOU based on where those
user and computer objects reside in AD. LSDOU specifies an order of precedence in processing
GPOs: local GPOs are processed first, followed by site, domain, and OU-based GPOs. The
effective policy that a user or computer receives is often referred to as Resultant Set of Policy
(RSoP).
To further illustrate LSDOU, Figure 1.1 shows an example of an AD domain with several GPOs
defined.

Chapter 1

Figure 1.1: Processing GPOs using LSDOU ordering.

A lot of Figure 1.1 describes how GPOs are processed in an AD domain environment. First, note
that the name of this particular AD domain is mydomain.tld. This domain contains an OU called
Finance and a child OU of Finance called AcctsRecv. In AcctsRecv, there is a Win2K
workstation object and a user object. The workstation object is on a subnet defined in the New
York Site.
AD sites arent associated with a particular domain. Instead, they create logical boundaries of
physical Internet Protocol (IP) network subnets that can encompass devices from multiple domains.
Thus, a site-based GPO can be processed by users and computers in multiple AD domains.

In Figure 1.1, six GPOs are defined:

The local GPO on the workstation

One on the New York Site

Two on the Finance OU

Two at the domain level

When the workstation starts up or the user logs on to the domain, those six GPOs are processed
in the order shown in the text to the right of the drawing, reflecting the LSDOU ordering. There
are a few things to note about this figure. First, in the case of the GPOs linked to the Finance
OU, even though the workstation and user are defined in the AcctsRecv OU, they still process
the GPOs linked to the parent OUFinancethanks to AD inheritance.

Chapter 1
Also, two GPOs are defined at each of the OU and domain levels. As youll see in Chapter 4,
there is no problem linking multiple GPOs to a given container, but you must define an order of
precedence for processing so that one GPO processes before the other. In this figure, the second
GPO in the list is processed first, followed by the first one in the list for each container.
Finally, the names I chose for the GPOs are meant to help an administrator understand the
purpose of each GPO. Ill talk more about naming conventions for GPOs in Chapter 4, but when
you define your GPOs, its definitely a good idea to descriptively and consistently name them.
Client-Side Processing
In addition to knowing about the order of GPO processing, its important to understand the
mechanism on Win2K devices by which GPOs are processed. While in an AD infrastructure, the
guts of a GPO are stored in the GPT (in SYSVOL) and the GPC (in AD), its the client (the
Win2K server or workstation) that actually processes the GPO. The client uses a series of clientside extensions (CSEs)Windows dynamic-link libraries (DLLs)that are knowledgeable about
the stuff stored on the server side of the GPO (the GPT and GPC).
As in NT 4.0, Winlogon calls these CSEs to process machine- and user-specific GPO settings.
Each major default capability in the Win2K GPO has a corresponding CSE that ships with
Win2K. The extensible model that GPOs provide lets independent software vendors (ISVs) write
their own CSEs to support custom GPO capabilities. You can think of the CSE as providing the
real policy functionality in the GPO, while the GPT and GPC are the storage mechanism for
whatever data that policy functionality requires.
For the list of CSEs registered on a given Win2K device, check the registry key HKEYLOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\Gpextensions. Figure 1.2 shows a typical CSE registration.

Figure 1.2: Viewing a CSE registration in the registry.

In Figure 1.2, the Folder Redirection capability is provided by a CSE DLL called fdeploy.dll.
5

Chapter 1

See Chapter 2 for more details about the role of CSEs in Group Policy processing.

Viewing and Editing GPOs

Before I discuss in detail the capabilities of a GPO, its a good idea to review how to view and
edit them. The basic tool for managing GPOs is the MMC Group Policy snap-in. This snap-in is
installed as part of every Win2K installation.
Microsoft has also pre-created an MMC console tool so that you can edit local GPOs on Win2K
workstations and servers. This console tool is called gpedit.msc. Choose Start, Run, then type
gpedit.exe

to launch MMC with the Group Policy snap-in loaded and focused on the local GPO from where
its being run, as Figure 1.3 shows.

Figure 1.3: Viewing the Group Policy snap-in console tool gpedit.msc.

In this section, I discuss using MMC and MMC console tools to create custom GPO tools. If you need
a refresher on using MMC and creating MMC console tools, check out the MMC overview on
Microsofts MS Developers Network Web site at
http://www.microsoft.com/windows2000/techinfo/howitworks/management/mmcover.asp. In addition,
check Realtimepublishers Web site at http://www.realtimepublishers.com for other free online titles
that discuss using MMC.

In Figure 1.3, you can see two distinct sections to this local GPO. The Computer Configuration
section holds policy definitions for computer-specific settings. As I mentioned earlier in this
6

Chapter 1
chapter, computer-specific policy is processed by Win2K workstations and servers when they
start up.
While its true that most computer-specific policies only run when a workstation or server starts up,
some policy items, such as certain security settings, are processed periodically to ensure that the
policy is enforced without regard to a computer restarting.

The User Configuration section holds policy definitions for user-specific policies, and its
typically processed when the user logs on (or logs off, in the case of logoff script policy). In the
next section of this chapter, Capabilities of GPOs, Ill drill into these two sections to further
explore their policy capabilities.
Gpedit.msc is a pre-defined MMC console tool that lets you view and edit a local GPO. The
actual MMC snap-in file that provides GPO editing functionality is called gpedit.dll and is
located in %Systemroot%\System32. Gpedit.msc is locked down using MMC authoring features,
so it only provides scope over the local GPO.
A more likely scenario is that youll need to edit either GPOs defined on an AD domain or local
GPOs defined on a remote workstation or server. In this case, youll need to create your own
MMC console tool. Choose Start, Run, then type
mmc.exe

Once the blank MMC console appears, select Console, Add/Remove Snap-in, then click Add. A
list of available snap-ins will appear, as in Figure 1.4.

Figure 1.4: Viewing available MMC snap-ins on a Win2K device.

Scroll down to the Group Policy snap-in, select it, then click Add (or double-click Group Policy).
The dialog box shown in Figure 1.5 will appear and let you choose the particular GPO that you
want to manage (local or AD-based).

Chapter 1

Figure 1.5: Choosing a GPO to load in the MMC console.

Click Browse to choose a GPO located on a local computer; in an AD domain, site, or OU; or all
objects available in the current AD domain.
As you can see in Figure 1.5, the Group Policy snap-in provides a check box that allows you to
change the focus of the GPO tool from the command line. The reason is that if you check this box,
then save your MMC tool to an .msc file, you can change which GPO the tool focuses on when you
launch MMC from the command-line. (However, in my testing, this feature doesnt work at all
launching an MMC tool from the command-line and providing the name of a different GPO to focus on
is simply ignored.)

Once youve chosen a GPO to focus on and loaded the Group Policy snap-in, you can either stop
there or add GPO references to this MMC tool. In fact, you can create custom MMC tools to
meet a variety of GPO editing needs. For example, I like to create an MMC tool that has all of
the GPOs I typically need to view and edit in my infrastructure, loaded in a single console for
easy access. Figure 1.6 shows an example of such a tool.

Chapter 1

Figure 1.6: Viewing an MMC console tool that references multiple GPOs.

In this figure, Ive loaded into one console four GPOs (and four instances of the Group Policy
snap-in) that I frequently use, making it easy for me to get to them and edit them in one fell
swoop. Similarly, if you have GPOs linked to OUs that are administered by different
administrators in your enterprise, you can create MMC tools with just those GPO references
loaded, then distribute those console tools to your OU administrators.
These console tools provide you with some level of control over who is viewing and editing
GPOs in your AD infrastructure. Of course, you can still delegate AD access rights on a
particular GPO, and this allows you to control who can access and edit a GPO. But the MMC
console-tool approach is quick and easy.
Once youve loaded the references to the GPOs youre interested in managing, choose Console
from the MMC menu and Save (or Save As) to give a name to your .msc file. I like to name my
GPO console files descriptively to help distinguish their function (for example, Domain-Wide
GPOs or Finance OU GPOs).
The GPO snap-in organizes GPO capabilities into nodes. You can expand these nodes to drill
into each capability. For example, if I expand the Computer Configuration node of the local GPO
shown in Figure 1.3, I see a number of different categories of functionalitySoftware Settings,
Windows Settings, and Administrative Templates. The same is true under User Configuration. In
each of these categories are the nodes that describe the individual policy functionality provided
by this GPO. Ill talk more about this functionality in the next section, but lets drill into one in
particular to see how you can edit a GPO.
In Figure 1.7, Ive drilled into the Windows Settings, Security Settings node under Computer
Configuration in my local GPO.

Chapter 1

Figure 1.7: Viewing the expanded Security Settings node in a local GPO.

In this figure, you can see that the Security Settings node is where I can set a variety of security
policy in this local GPO. Indeed, on a local workstation or server that isnt part of an AD
domain, this node provides the equivalent functionality to NT 4.0s User Manager\Policy menu
items.
Within Security Settings, there are three subcategoriesAccount Policies, Local Policies, and
Public Key Policies. If you drill into each of these, you see additional capabilities. For example,
under Account Policies, you see the Password Policy, which lets you set restrictions such as
minimum password length and age. Figure 1.8 shows where Ive drilled into Password Policy to
expose the actual policy items available.

10

Chapter 1

Figure 1.8: Viewing the policy options under the Password Policy section of a local GPO.

This figure shows the actual policy items in the results pane in the MMC snap-in. If you doubleclick one of the items, such as Minimum Password Age, you can set the policy in this GPO.
When you set a policy item in a GPO, there is no concept of saving or undoing it. Once you
make a change, the change is committed unless you change it to another value. For example, if
you set Minimum Password Age to 10 days, then click OK, the policy is set. You dont need to
save the GPO (in fact, there is no place in the MMC snap-in to save it). Likewise, you cant
simply click an Undo button to back out of the change. You need to go back into the Minimum
Password Age dialog box and reset the value to 0.
This issue underscores an important point when youre editing GPOs: Make sure you document
the changes youre making. Unfortunately, there is no good automated way to manage GPO
changes in Win2K, but I suspect that third-party software companies will develop products that
solve this problem in the near future. In the meantime, one tip that you might find useful is to
disable the GPO before you edit it. This will prevent users who may be logging on or restarting
their computers from processing your GPO while youre in the middle of changing it.
In Chapter 3, I describe how you can disable a GPO before you edit it (or for other reasons).

In Figure 1,8, you see two columns in the results pane of the MMC console toolLocal Setting
and Effective Setting. This distinction is important to understand if youre working in an AD
environment with AD-based GPOs.
As I mentioned, every Win2K device comes with a local GPO, which is what Figure 1.8 is
focused on. The Local Setting column shows the policy that has been set for that item in the local
11

Chapter 1
GPO. The Effective Setting column shows what the current policy is actually set to. This may be
different than the Local Setting value in an AD environment because AD-based GPOs are
processed after the local GPO (remember LSDOU) and therefore can override settings made in a
local GPO. Of course, for Win2K devices that arent members of a domain, Local Setting and
Effective Setting values should be identical.
The distinction between Local Setting and Effective Setting is a function of the Security Settings node.
Other policy nodes in a GPO may or may not present this information.

Keep in mind that each GPO node has its own requirements for enabling or disabling policy. For
example, in the Security Settings section, you may be required to provide an absolute numeric
value like number of days between password changes. However, in other areas, it may be a
matter of simply enabling or disabling policy. Still other areas, such as logon scripts, may require
you to enter the path to a file or folder. The important thing to remember is that there is no one
standard way of manipulating GPOs.

Capabilities of GPOs
Now that Ive introduced the basic concepts of GPOs and how you can view and edit them, Ill
describe the policy capabilities that are available out-of-the-box for Win2K GPOs. The
capabilities of GPOs are formidable and complex. In this section (and this entire book), Ill
discuss all that GPOs are capable of and help you use them in your enterprise to your best
advantage. While the GPO infrastructure is extensible, allowing developers of third-party
applications to develop their own CSEs and policy features, this section describes what
Microsoft has developed in Win2Kand the major features of each policy area.
Chapter 3 discusses the hands-on use of each of these GPO capabilities.

Table 1.1 shows a brief overview of the default GPO capabilities available.
Computer Configuration (specific to computer objects)
Setting

Description

Software Settings| Software

Installation

Lets you assign Windows Installerbased application installation

packages to AD machine objects.

Windows Settings| Security

Settings

Provides machine-specific security configuration using security

configuration templates.

Windows Settings|
Scripts(Startup/Shutdown)

Provides machine-specific startup or shutdown scripts. These can be

batch files, executables, or Windows Script Host (WSH) scripts.

Administrative Templates

Provides machine-specific Administrative Templates that let you

control registry settings in the HKEY_LOCAL_MACHINE registry hive
(Similar to NT 4.0 System Policy).

User Configuration (specific to user objects)

Setting

Description

Software Settings| Software

Installation

Lets administrators assign Windows Installer-based application

installation packages to AD user objects.

Windows Settings| Internet

Lets you manage Internet Explorer (IE) configurations for each user.

12

Chapter 1
Explorer Maintenance

Transfers the capabilities of the Internet Explorer Administration Kit

(IEAK) to GPOs.

Windows Settings| Folder

Redirection

Redirects Windows Explorer folders such as the Desktop, My

Documents, and Startup to server-based folders rather than the users
profile.

Windows Settings|
Security Settings

Enforces public key infrastructure (PKI) policy for AD user objects.

Windows Settings| Remote

Installation Services

Defines how the Remote Install Services (RIS) works on a per-user

basis.

Windows Settings| Scripts

(Logon/Logoff)

Provides user-specific logon and logoff scripts. Similar to startup and

shutdown scripts in that they support any number of scripting
environments.

Administrative Templates

Provides user-specific Administrative Templates that let you control

registry settings in the HKEY_CURRENT_USER registry hive (similar
to NT 4.0 System Policy).

Table 1.1: The default capabilities of GPOs.

I discuss each of these capabilities in the sections that follow.

Software Settings | Software Installation
Software Installationboth user- and computer-specificis a key feature in Microsofts GPO
infrastructure. You can think of Software Installation as a mid-range software-distribution
capability, similar to what Microsoft provides with the Systems Management Server (SMS) for
larger enterprises. Software Installation differs from products like SMS in several important
ways, however. Its missing many of the features that large enterprises look for in a robust
software distribution product, such as

The ability to capture hardware and software inventory (asset management)

Robust, centralized reporting on the success and failure of software distributions

The ability to distribute software to servers in an unattended way (Software Installation is

really designed for desktop-based deployments)

Solid, centralized troubleshooting tools

Interestingly, not many capabilities of SMS 2.0 have been integrated into Software Installation.
Despite that fact, Software Installation provides a good software-distribution capability for
small- to medium-sized enterprises. It lets you assign applications on a per-computer basis and
assign and publish applications on a per-user basis. Ill describe assignment and publishing in a
moment. But first, I want to talk a little bit more about Software Installation and the Windows
Installer.
Software Installation leverages Microsofts Windows Installer, which ships with Win2K to
perform application installations. The Windows Installer is an application-packaging format,
installation engine, and set of APIs, and it provides a better application setup than earlier
technologies. Windows Installer packages have an .msi file extension. Applications such as
Microsoft Office 2000 are good examples of software that leverages the .msi package format.
One of the big advantages of the .msi format and the Windows Installer engine is the ability to
install applications using an elevated security context. This means that applications that normally
13

Chapter 1
require administrator access to install can be installed by regular users without an administrators
intervention and without the need to grant the users privileged access to their workstations.
When an application is deployed using Software Installation, its called a managed application,
and it can thus take advantage of the elevated security privileges in Windows Installer. Figure
1.9 shows an example of an application that has been deployed in Software Installation.

Figure 1.9: Defining an application deployment using GPO-based Software Installation.

In this figure, Ive assigned the Win2K Support Tools application to be deployed in this GPO
called App Deployment Policy. This is a computer-specific deployment, so all computers subject
to this GPO will have the application installed.
Assignment vs. Publishing
Applications can be deployed using Software Installation to either computers or users. An
application deployed to a Win2K computer is installed the next time that computer is restarted.
Applications deployed to users can either be partially installed when the users log on
(assignment), or installed on demand by the users themselves (publishing).
Applications that are assigned to a user are advertised to that user the next time the user logs on.
Advertisement is a feature of Windows Installer packages (.msi files) that is tightly integrated
into the Windows Explorer shell. Advertisement puts an applications presence on the users
desktop. A presence may be a shortcut to an application placed on the users Start menu, a file
association to the application (for example, .doc files are associated with Microsoft Word), or
even a Component Object Model (COM) component registration that refers to the application.

14

Chapter 1
However, during advertisement, the application isnt really installed. Rather, these presences are
placed in the users environment. The first time a user activates one of these presences (for
example, clicks a shortcut or opens a file with an advertised association), the Windows Installer
engine starts up and installs the application from its setup package. This is known as Install on
Demand, and its a powerful feature of GPO-based Software Installation deployments. It means
that only those applications and application features that the user needs are installed when
theyre needed.
Publishing takes a different approach from assignment in GPO-based Software Installation.
Publishing an .msi-packaged application makes it available to the user in the Add/Remove
Programs applet in Control Panel that comes on every Win2K device. Figure 1.10 shows an
example of an application that has been published in a GPO.

Figure 1.10: Using Software Installation publishing to make applications available in the Add/Remove
Programs applet.

In this figure, you see that the Win2K Support Tools application has been published so that a
user can install it by clicking Add. In GPO-based software installation, you can also categorize
published applications to make it easier for your users to find and install them. Notice the
Category drop-down list in Figure 1.10. You can define categories in the GPO Software
Installation node to help delineate your applications in the Add/Remove Programs applet. For
example, in Figure 1.10, I created a category called Administrative Tools, in which Ive placed
this published application.
Another useful feature of Software Installation is managing the life cycle of applications.
Managing a life cycle is upgrading, patching, rolling back, and uninstalling applications
centrally, and whats more important, cleanly. Managing a life cycle in Software Installation

15

Chapter 1
depends on the Windows Installer technology to succeed. However, its an important feature that
more advanced products, such as SMS, dont do or do poorly.
In Software Installation, you can create update dependencies among applications. When a new or
patched release of an application comes out, all those users or computers that previously had the
application installed can be set to receive the new version. Additionally, if youre trying to retire
an application, you can deploy it using Software Installation in such a way that if the application
is no longer deployed using Group Policy, itll be uninstalled. These life cycle management
features are tremendously valuable for organizations that are deploying and uninstalling many
applications over time.
Windows Settings | Security Settings
The Security Settings feature in GPOs may be one of the most confusing for many
administrators. The ability to set many basic security policies in Win2K is now only done using
Group Policy (either local or AD-based GPOs). This differs dramatically from NT 4.0, where
features such as account and audit policy were set from the User Manager, and more advanced
security features like setting service and file system permissions could be managed using the
Security Control Manager (SCM).
Microsoft folded the capabilities of SCM into Group Policy. In fact, Security Settings policy in a
GPO can use the same security template files (file names usually ending in .inf) to set security
policy settings that SCM (both the NT 4.0 and Win2K versions) uses. At the same time,
Microsoft augmented the capabilities found in NT 4.0 SCM to provide a one-stop shop for
setting all security policy in Win2K. Indeed, you can think of the Security Settings featureboth
computer- and user-specificas being an excellent centralized tool for managing security across
all of your AD-based Win2K devices.
The confusing part about GPO-based Security Settings comes when you try to ensure that the
right security policy is applied to the right set of computers and users. For example, machinebased security policy defined in GPOs that are processed by domain controllers affects policy for
the entire domain. Whereas, security policy defined in GPOs that are processed by member
servers or workstations only affects the local Security Account Manager (SAM) and resources on
those local computers.
I mentioned earlier that machine-based policy is typically processed when a computer restarts
and user-based policy when a user logs on. However, the Security Settings policies are also
processed on a periodic basis (by default, every 90 minutes).
You can also manually force security policy to refresh by issuing the following command:

secedit /refreshpolicy machine_policy

or

secedit /refreshpolicy user_policy

The Security Settings capability provides a number security policy features, discussed in the
following sections.

16

Chapter 1
Account Policies
Account Policies are machine-specific policies. Account Policy defined for an entire AD domain
can only be set in a domain-linked GPO. That is, if you have an AD domain controller that is
subject to a GPO linked to an OU, and that GPO contains Account Policy settings, theyll be
ignored in favor of the Account Policy defined in any domain-linked GPOs that are present.
Account Policy includes three sectionsPassword Policy, Account Lockout Policy, and
Kerberos Policy. Password Policy, as Figure 1.11 shows, is where you set policy such as
minimum password length, password age, and password complexity enforcement (rules that say
that a password must contain numbers and capital letters, for example).

Figure 1.11: Viewing Password Policy options in GPO-based Security Settings.

Account Lockout Policy is where you set policy to determine whether and for how long a user
account is locked out after a number of incorrect password attempts. Kerberos Policy is new in
Win2K and supports the MIT Kerberos V implementation that Win2K uses as its default
authentication protocol. Figure 1.12 shows the options available in Kerberos Policy.

17

Chapter 1

Figure 1.12: Viewing Kerberos Policy options in GPO-based Security Settings.

As the figure shows, Kerberos Policy lets you set features of the Kerberos protocol such as ticket
lifetime and ticket renewal intervals.
Local Policies
Local Policies, as the name implies, lets you set security policy that is relevant to the local
computer. Local Policy defined in a domain-linked GPO affects all computers in that domain
(unless explicitly excluded), including domain controllers. Local Policy applied to a domain
controller becomes the local policy for that domain. Local Policy applied to workstations or
member servers is just specific to those devices. Local Policies includes three sectionsAudit
Policy, User Rights Assignment, and Security Options.
Audit Policy
Audit Policy is similar to the NT 4.0 User Managers Policy Audit menu item. Figure 1.13 shows
the options available in Win2K Audit Policy.

18

Chapter 1

Figure 1.13: Viewing Audit Policy options in GPO-based Security Settings.

Audit Policy allows you to enable auditing events for various kinds of system access. Audit
events are stored in the Security event log on the Win2K system where theyre generated. As
with Account Policy, Audit Policy defined in a GPO that is processed by a domain controller
will become the policy for that AD domain. Audit Policy defined on GPOs processed by
workstations or member servers affects only those devices. Auditing success indicates that you
want to raise an event log entry each time that particular type of event (for example, Audit
Account Management) succeeds. Similarly, auditing failure means that you want to raise an
event log entry when that type of event fails.
Auditing NT File System (NTFS) and registry access is a two-part process. First you must enable
the Audit Object Access event type. Then, in the file system or registry itself, you need to enable
auditing for a particular folder or key.
User Rights Assignment
User Rights Assignment is similar to NT 4.0 Users Managers Policy User Rights menu item.
Its where you define which users and groups have the right to perform certain kinds of
operations. Typical user rights include the ability to shut down a computer, log on to the local
console of the computer, and add computer accounts to a domain. Win2K adds quite a few rights
above and beyond what NT 4.0 provided, so its worth scanning through them to see if there are
any that offer some useful additional protection. Again, User Rights Assignment defined on a
GPO that is processed by domain controllers becomes the user rights policy for that domain.

19

Chapter 1
Security Options
Security Options lets you set what I call the miscellaneous security lockdowns. Many of the
security settings you see in this section previously required registry tweaks to set or werent
available at all. Figure 1.14 shows many of the policies in this section.

Figure1.14: Viewing Security Options in GPO-based Security Settings.

As you can see in this figure, features such as Message text for users attempting to log on was
typically something you had to set directly in the registry (or using System Policy). You can
think of the Security Options section as the dustbin of Win2K security policy. Everything that
was left over when Microsoft created the other security policy sections was placed in here!
However, it also contains some useful features, especially if youre deploying Internet-facing
Win2K systems, so its worth having a look.
Event Log
The Event Log policy section is another computer-specific security setting. This section lets you
centrally define, in a GPO, the event log settings you want to enforce across computers in your
domain (or locally on a computer, in the case of the local GPO). Figure 1.15 shows the options
available in this section.

20

Chapter 1

Figure 1.15: Viewing Event Log policy settings in GPO-based Security Settings.

To enforce some consistency of logging in NT 4.0, you had to set these options on every nondomain controller computer. Using Group Policy, you can control how big event log files can
grow and what to do with them when theyve reached their limit.
Most of the security policy Ive been discussing in this section lets you define a policy item with a
particular value or leave it as Not Defined. Note that Not Defined isnt the same as disabled. That is, a
particular security policy (such as Application Event Log Size) may come with a default value when
you install Win2K. Not defining in a GPO simply means that the default value remains, not that (as in
this example) application event logging has been disabled.

Restricted Groups
Restricted Groups is an interesting, if not complicated, security policy to implement in GPO.
Restricted Groups allows you to define particular user groups who can only have a specific set of
users as members. Similarly, you can define a Restricted Groups policy that says that a particular
user group must always be a member of another group or groups.
In the former situation, you can use the Restricted Groups feature to say that only Joe Admins
account and the local Administrator account can be members of the local Administrators group
on computers subject to the GPO policy. This means that if a user account called Bill Evil is able
to compromise a computer and add itself to the local Administrators group, the next time a GPO
containing Restricted Groups policy is processed by that computer, Bill Evils account is
automatically removed from the group.
Using the second part of the Restricted Groups feature, you can ensure that a particular user
group cannot be removed from other groups. For example, suppose you want to ensure that the
user group Desktop Administrators, defined on your AD domain, is always a member of the
21

Chapter 1
local Administrators group. If you define this policy in Restricted Groups, any computers that
process the GPO containing this policy will always enforce this restriction. If someone tries to
remove your Desktop Administrators group from the local Administrators group on a
workstation, the next time the GPO is applied, the policy will be enforced, and your group will
be added back in.
As you can probably see, Restricted Groups is a powerful feature. Misusing or misunderstanding
how and when it applies, especially when youre restricting group membership to a set of
particular users, can cause you to lock yourself out of a particular workstation, a server, or
potentially even an entire AD domain. Use Restricted Groups with caution, and remember that
when you set a Restricted Group policy in a GPO, any computer that processes that GPO will
enforce your policy.
System Services
In the System Services policy, you can define the default startup mode for a particular service.
Whats more important from a security perspective, you can define users and groups that have
the right to start, stop, pause, and change the configuration of a particular service. This is a
powerful feature when it comes time to delegate administration of Win2K resources on your
network. You can set a System Services policy, for example, that lets you grant your Help desk
user group the right to start and stop the printer Spooler service only on a designated set of
Win2K print servers that are subject to that GPO. Figure 1.16 shows an example of the dialog
boxes available in the System Services policy.

Figure 1.16: Setting the Windows service policy options under the System Services policy.

In this figure, Ive set the default startup mode of the Windows Time service to Automatic, and
Ive granted the Authenticated Users group the ability to start, stop, and pause the service (as
22

Chapter 1
well as read, write, and delete the services configuration information from the registry). When a
computer subject to this policy processes the GPO, these service settings will be enforced, and
only Authenticated Users will be able to manage this particular service.
Keep in mind that the list of system services that appears in this policy section is somewhat a
function of where youre running the MMC Group Policy snap-in. Ordinarily, the list of services
is built using what is currently installed on the computer where youre editing the GPO. This
may not be sufficient if you want to control services that only exist on certain types of Win2K
devices. For example, you may have a third-party backup application that runs as a service on
your servers, but not on the workstation where youre editing the GPO. In that case, you need to
either open the Group Policy snap-in on that server and create your service security settings or
manually edit the security template file that is being used by that GPO.
For more information about security templates, see Chapter 3.

Registry
The registry security policy section allows you to centrally enforce security permissions on
registry keys on computers that are subject to the policy. For example, for security reasons, you
may want to lock down a particular registry key that enables users to change some aspect of their
workstation configuration. You can use the registry security policy to enforce this lockdown.
You can also use registry security policy to enforce a particular access control list (ACL) on a
particular registry key. For example, you may want to maintain a particular ACL on a key no
matter who comes along with another GPO and tries to reset it. If you set this policy in a GPO
that is processed high in the LSDOU order of precedencefor example, at the domain levela
subsequent OU-based GPO that tries to change the permissions on that key will be ignored.
Figure 1.17 shows an example of the options available for propagating ACLs in the registry
policy.

Figure 1.17: Viewing the ACL propagation (or protection) options in the registry security policy.

23

Chapter 1
In this figure, if you selected Do not allow permissions on this key to be replaced, youd achieve
the effect I just describedprotecting the ACLs on this key. You can use registry security policy
to enforce registry key security on computers that process a given GPO. Because the registry is
unique on every Win2K device, this policy is enforced on every device that is subject to it,
including all domain controllers, member servers, and workstations.
File System
The File System security policy functions very much like the registry security policy except that
it applies to an NTFS volume rather than registry keys. File System security lets you centrally
manage NTFS permissions on servers and workstations. Keep in mind that this is different than
share permissions, which cant be managed using this policy.
File System policy is handy when you want to enforce security on files or folders across multiple
servers in your AD infrastructure. However, like registry security, it can be tricky to manage. For
one thing, File System policy requires that you set security restrictions using an absolute drive
letter (or environment variable that evaluates to a drive letter) and folder name. For example,
suppose you have a number of servers that have a file folder called \Apps, but on each server,
\Apps may be on the C drive or the D drive. File System policy requires that you specify an
absolute drive letter (see Figure 1.18).

Figure 1.18: Setting up File System security policy using an absolute drive letter.

This figure shows how Ive set up File System security policy on the E volume under the apps
folder. When computers process the GPO containing this policy, and if they have an E:\Apps
folder, the permission policy will be applied.

24

Chapter 1
Public Key Policies (Machine and User)
This policy lets you specify behavior related to both computer- and user-specific use of a PKI
implementation based on Microsofts Certificate Services. Let me just point out that many
enterprises may not be implementing a PKI solution that is integrated with their Win2K
infrastructure. If thats the case, this policy section wont have much value for you. However, for
those who are implementing PKI, and especially a Microsoft-based PKI solution, the Public Key
policies listed here support that implementation. Specifically, on a per-machine basis, the
following policies are supported:

Encrypted Data Recovery AgentsLets you specify users or groups who can decrypt
files that have been encrypted by users using Win2Ks Encrypting File System (EFS)
feature. Recovery Agents are used when the person who encrypted a file or files is unable
or unavailable to decrypt them.

Automatic Certificate Request SettingsLets you specify that machines that are subject
to this policy automatically receive prescribed public key certificates from AD.

Trusted Root Certification AuthoritiesLets you import lists of trusted public key
certificates, Certificate Authorities (CAs), or certificate revocation lists (CRLs), which
are then distributed to all machines that are subject to this policy.

Enterprise TrustThis feature lets you assign certificate trust lists (CTLs) to machines
that are subject to this policy. CTLs are lists of root CAs. If a computer has a list of valid
root CAs, it can accept certificates they certify without question.

On a per-user basis, there is a Public Key policy, similar to the Enterprise Trust machine policy,
that lets you assign a CTL to users who are subject to the GPO. The final machine-specific
Public Key policy is called IP Security Policies on Active Directory. Using this policy (shown in
Figure 1.19), you can enforce Internet Protocol Security Protocol (IPSec) usage on computers
that are subject to this GPO.

Figure 1.19: Viewing the IP security policy settings in a GPO.

25

Chapter 1
For example, using this policy, you can specify that all IP traffic to and from servers that are
subject to this policy can request or require encrypted (IP SecurityIPSec) communications.
Windows Settings | Scripts (Startup/Shutdown)
NT 4.0 supported the notion of logon scripts that were defined on a per-user basis in User
Manager. Logon scripts could be batch files, executables, WSH scripts, or even Perl scripts. In
Win2K, the concept has been extended in Group Policy. (Per-user logon scripts are still
supported in AD users objects.)
GPOs support computer-specific startup and shutdown scripts. Startup and shutdown scripts
work just as the names imply. When a Win2K workstation or server subject to a GPO-based
startup script starts up, it processes the GPO and runs the startup script in the context of the
special LocalSystem user account. Similarly, when the workstation or server shuts down, any
shutdown scripts defined by the GPO are processed at that time.
Startup and shutdown scripts can help you perform administrative tasks that dont require user
intervention or report on the behavior of computers when they restart. For example, you can
write a shutdown script that sends an email to a particular mailbox whenever a server or group of
servers subject to a GPO shuts down. Because these scripts are based on a GPO, and because a
computer can be subject to multiple GPOs at various levels (site, domain, and OU), a computer
might process many shutdown and startup scripts. Depending on your perspective, this behavior
can be either a good or a bad thing.
Windows Settings | Scripts (Logon/Logoff)
Like shutdown and startup scripts in GPOs, logon and logoff scripts are per-user scripts that run
in a users security context whenever a user subject to a GPO that defines these scripts logs on to
or off of a Win2K device. Figure 1.20 shows how logon scripts are defined in a GPO.

26

Chapter 1

Figure 1.20: Defining a logon script in a GPO.

In addition to defining multiple scripts across GPOs, you can define multiple logon or logoff scripts in
a single GPO. As you can see, using this feature can quickly become overwhelming.

Windows Settings | Internet Explorer Maintenance

Internet Explorer Maintenance policies are user-specific policies designed to apply the features
that are available in the IEAK to GPO-based policy that can be centrally managed. Using
Internet Explorer Maintenance, you set policy under five categoriesBrowser User Interface,
Connection, URLs, Security, and Programs.
Browser User Interface
This policy section lets you control aspects of the IE user interface (UI) for those users who are
subject to the GPO. UI elements such as the IE window title, custom bitmaps, and custom logos
are controlled from here.
Connection
This policy section lets you enforce IE configuration related to network connections, automatic
proxy configuration scripts (or manual proxy settings), and supported user-agent strings. Figure
1.21 shows an example of setting Connection policy for a manual proxy.

27

Chapter 1

Figure 1.21: Setting manual proxy settings using the Internet Explorer Maintenance Connection policy.

URLs
The URLs policy lets you define pre-set lists of favorites (bookmarks), important URLs such as
home page and search page buttons, and Active Desktop channels.
Security
This policy item lets you define and enforce the different IE security-zone settings (Intranet,
Internet, Trusted, and so on) as well as content-rating settings (which restrict content based on its
rating). You can also enforce Microsoft Authenticode support in this policy. Authenticode
guarantees that code that is downloaded by IE is safe to use, and it uses public key certificates to
certify the trustworthiness of the code. The Security policy section lets you defined trusted
authorities, whom you trust to allow your users to download code from within IE.
Programs
The Programs policy section lets you enforce the support programs that your IE users use within
the context of a Web browsers. For example, if a user clicks an email address on a Web site,
which email program is launched? Or if a user wants to edit an HTML file, which HTML editor
is launched? Figure 1.22 shows the settings that are available in the Programs section.

28

Chapter 1

Figure 1.22: Viewing the settings available in the Programs policy item.

Windows Settings | Folder Redirection

Folder Redirection is a user-specific GPO policy that lets you redirect certain well-known userprofile directories to alternative file paths. NT 4.0 System Policy had a similar feature known as
Custom Shell Folders. However, Folder Redirection in Group Policy is much smarter than the
old NT 4.0 approach in a number of ways. However, before I describe how Folder Redirection is
smarter, lets look at what folders can be redirected:

Application Data

Desktop

My Documents (and My Pictures in My Documents)

Start menu

Each of these folders typically resides in the users profile (usually stored in
%Systemroot%\Documents and Settings\%Username%). When users are subject to a GPO-based
Folder Redirection policy, Folder Redirection provides a way to redirect these profile-based
folders to alternative locations. For example, you might choose to redirect the My Documents
folder for all of the users in a particular OU to a server-based home share that is backed up
frequently.
Whereas NT 4.0 redirected all users subject to a particular GPO, Folder Redirection allows you
to redirect users to different server-based folders based on their group membership. This is
known as advanced (as opposed to basic) redirection, and its illustrated in Figure 1.23.

29

Chapter 1

Figure 1.23: Defining the advanced Folder Redirection feature in a GPO.

In this figure, for users processing this GPO who are members of the Finance Users group, Ive
defined an advanced Folder Redirection policy to redirect My Documents to the home share
folders \\Financeserver\Home\%Username% .
Folder Redirection is smart in other ways too. For example, you can define settings for a Folder
Redirection policy that instruct the GPO to move the contents of, for example, My Documents
from the users profile to the new, redirected location when the GPO is first applied. But if the
user is no longer subject to the policy, you can also tell Folder Redirection to either move the
contents back to the users profile or leave them where they are.
Folder Redirection can also grant exclusive security rights to a folder that has been redirected, as
you might want to do for personal documents typically found in My Documents. In this case,
Folder Redirection takes care of applying ACLs to the folder so that only the user who is being
redirected has access to that folder and its contents. Folder Redirection is also useful for
redirecting user folders to read-only server shares. This is especially appropriate for folders such
as Start menu or Application Data, whose contents you might want to be identical for all users.
Windows Settings | Remote Installation Services
The Remote Installation Services RIS policy is fairly simple. If youre using RIS to install
Win2K workstations, you know that one of the first steps is to log on to an AD domain. If you
log on using an AD user account that is subject to a GPO on which RIS policy is defined, that
policy may restrict what you can and cannot do in the RIS menus. Figure 1.24 shows the RIS
policy options that are available.

30

Chapter 1

Figure 1.24: Viewing the Remote Installation Services policy settings.

In this figure, you can see that the policy provides the ability to control four aspects of a RIS
setupautomatic setup, custom setup, restart setup, and tools. Each section has three policy
settingsAllow, Dont Care, and Deny. If, for example, you define a Deny policy for custom
setup, users subject to this GPO cannot choose the manual setup option from the RIS installation
menus. In the normal course of your work with GPOs, Id be surprised if you find much use for
this policy. But its useful to know its available.
Administrative Templates
Administrative Templates are available in both the per-user and per-computer parts of a GPO.
Administrative Templates are NT 4.0 System Policyor more specifically, an enhanced version
of NT 4.0 System Policy. They let you enforce particular registry settings in either the
HKEY_CURRENT_USER (per-user) or HKEY_LOCAL_MACHINE (per-machine) hives.
Administrative Templates use an approach similar to System Policy to define which registry
keys and values can be set. Namely, Microsoft provides (and you can define) .adm files that use
a special macro language to define the keys and values that you want to control. When you set
Administrative Template policy, you choose from three states for a given policy item:

EnabledThe policy item is actively enforced (corresponds to a checked value in NT 4.0

System Policy).

DisabledThe policy item is actively not enforced or not done. In other words, if a
registry value is set to 1, and 0 is its off state, disabling the policy will set the registry
value to 0. (This corresponds to an unchecked value in NT 4.0 System Policy.)

31

Chapter 1

Not ConfiguredThe value for this registry policy item is left alone. That is, if the value
in the registry is 1, a GPO with Not Configured defined for that value will have no
impact. (This corresponds to a grayed value in NT 4.0 System Policy.)

The .adm files that ship in Win2K are more numerous and provide more registry-based policy
settings than those provided in NT 4.0. This makes sense when you consider the number of
additional features in Win2K. Figure 1.25 shows an example of some of the Administrative
Template settings available in Win2K GPOs.

Figure 1.25: Viewing some Administrative Template policy settings in a GPO.

This figure happens to show some Administrative Template policies that you can set to control
the behavior of GPO processing itself on a given computer.
In NT 4.0 System Policy, if you set a registry value by policy and that policy file was removed or
no longer applied, the value would remain as the policy had specifiedit would remain
tattooed. However, in Win2Ks Administrative Templates, Microsoft now distinguishes
between registry settings that are policies and those that are preferences.
A policy is defined as any values that are modified under one of the following four registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies (per machine)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
(per machine)

HKEY_CURRENT_USER\Software\Policies (per user)

32

Chapter 1

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies (per
user)

The policies defined by these registry keys dont suffer the tattooing fate. If a GPO-based
Administrative Template policy is no longer active, the registry value is removed as if the policy
had never been there. Preferences, however, are Administrative Template-based policy that
makes changes to registry keys other than the four previously listed. If a GPO that sets a
preference is removed, the registry values set by that preference are left as is.
Finally, just as with NT 4.0 System Policy, you can customize existing or create new .adm
template files to add registry lockdown functionality to your GPOs. Youll find that the macrolanguage syntax in Win2K is quite similar to NT 4.0 .adm files, and indeed, NT 4.0 .adm files
typically work without change in Win2K.
One nice enhancement Microsoft made to Administrative Templates is support for a new .adm
tag called Explain. The Explain tag lets you add detailed textual explanations of what a particular
policy item is doingright in the Group Policy snap-in. Youll notice that Microsoft has done a
pretty good job of using this feature to document the .adm files that they provide. If you create
your own custom files, I encourage you to follow suit.

Summary
In this chapter, I reviewed the purpose of GPOs, how theyre processed, how to edit them, and
what features they provide. As you can begin to see, GPOs are a powerful and complex tool that
can either greatly enhance or greatly harm your Win2K infrastructure.
The rest of this book focuses on how to use GPOs to enhance your infrastructure and prevent
them from harming it. Chapter 2 discusses a GPO in detail and how it interacts with AD,
Chapters 3 and 4 drill into the features described in this chapter with an eye to helping you use
them in practice and design and deploy an effective GPO infrastructure, Chapter 5 talks about
some of the limitations youre likely to encounter as you use this technology, and Chapter 6
provides some tools and troubleshooting techniques for managing your GPOs when things go
awry.

33

Chapter 2

Chapter 2: Group Policy Structure and Processing

In Chapter 1, I discussed the history of policy and described the enhancements Microsoft
delivered in the Win2K GPO. Of course, these enhancements add complexity. The complexity of
GPOs is generally hidden from the administrator by the simple interface used to control the
settings. This interface was described in Chapter 1.
In fact, pieces of GPOs can be found in AD and in the shared SYSVOL folder found on each AD
domain controller. Understanding the structure of GPOs and how GPO processing works in
conjunction with AD and SYSVOL will help you more effectively deploy, manage, and
troubleshoot Group Policy.
In this chapter, Ill start by describing how GPOs are structured and how they interact with AD
and SYSVOL. Then Ill move into a discussion of how GPOs are processed by users and
computers in your AD infrastructure.

Structure of the GPO

The GPO doesnt exist as a single object. Rather, its a collection of settings stored in AD and a
corresponding set of files stored in SYSVOL. As Ive described in Chapter 1, the administrator
typically views a GPO using the MMC Group Policy snap-in (see Figure 2.1).

Figure 2.1: The Group Policy snap-in showing the GPO Default Domain Policy.

34

Chapter 2
The GPO really consists of two components. The first part is stored in AD as a container object.
This part of the GPO is referred to as the GPC. The GPC AD object is derived from a special AD
class called, as you would expect, groupPolicyContainer. The second part of the GPO is stored as
files in the file system in the shared SYSVOL folder on every domain controller. This second
part is called the GPT.
The exception to this model is the local GPO. As I mentioned in Chapter 1, the local GPO
resides on every Win2K device that you install. It doesnt have a GPC in AD or a GPT in
SYSVOL. Rather, it simply stores what would correspond to its GPT in the local file system of a
workstation or server. In this chapter, Im going to focus on AD-based GPOs rather than the
local variety, so thats all Ill say about local GPOs for now.
Given this reliance of GPOs on AD and a domain controller infrastructure, its easy to
understand why, as I explained in Chapter 1, you need to have an AD infrastructure in place to
take full advantage of GPO functionality. But this reliance implies something else as well
namely, that GPOs belong to a particular domain in which theyre created. That is, in a multidomain AD forest, each GPO you create must be stored in a single domain.
However, its also important to remember that while GPOs live in a single domain, they can be
linked to objects outside the domain. As you can imagine, this cross-domain linking can have
an impact on the performance of GPO processing. Ill discuss that topic later in the Group
Policy Processing section of this chapter. Next, lets dive into the details of the two parts of the
GPOthe GPC and GPT.
The GPC
The GPC is critical to ensuring that computers and users in AD environments correctly process
policies. To view the GPC, open the MMC Active Directory Users and Computers snap-in.
Make sure you have the advanced features view enabled. Select the system container, and
beneath that, the Policies container in the domain. There youll find all the policies defined in the
domain. Each GPO is represented as a container named with a 128-bit GUID (see Figure 2.2).

35

Chapter 2

Figure 2.2: GPCs exposed through the Active Directory Users and Computers tool.

By default, you cannot see the System\Policies container when you first start the Active Directory
Users and Computers tool. To see the container, choose View, Advanced Features (shown in Figure
2.3).

Figure 2.3: Advanced Features selected on the MMC View menu.

Now lets think about which GPC object in Figure 2.2 maps to a recognizable GPO, like the one
shown in Figure 2.1. Typically, we compare the GUID string in the Policies container with a
GUID string on the GPO, as seen in the MMC Group Policy tool. If you right-click the GPO
name in the Group Policy tool, then choose Properties from the context menu, you can view the
36

Chapter 2
properties of the GPO in the Properties dialog box. Youll see its GUID listed on the General tab
as Unique Name (see Figure 2.4).

Figure 2.4: Viewing the GUID of a GPO using the Group Policy tool.

Once you know the GUID of the GPO youre editing, its easy to find the corresponding GPC
object in the Policies container of the domain in which the policy is stored. In addition, if youre
reviewing a GPO and are unsure which domain is mastering it, just look at the value for Domain
on the General tab of the policys Properties dialog box. The domain shown there is the domain
in which the GPC, and thus the GPO, is stored.
Finding GPO Friendly Names from Their GUIDs
The need to derive a GPOs friendly name from its GUID (that is, to perform a reverse policy
name lookup) doesnt occur very often, but if you need to perform such an operation, you can
use a tool called ADSIEdit.
You can install ADSIEdit as a part of the Support Tools from the Win2K Professional, Server,
Advanced Server, or Datacenter CD-ROMs. Its also available in the Win2K resource kit.

37

Chapter 2

You may not have security clearance to install Support Tools on your servers. In this case, consider
registering the adsiedit.dll for one-time use. Simply find a copy of adsiedit.dll (on any system on which
youve installed the previous tool set). Copy the adsiedit.dll to your systems %systemroot%\system32
folder, and run the following code to register the dll:
Regsvr32 %systemroot%\system32\adsiedit.dll
Un-registering is as simple as executing the following command:
Regsvr32 /u %systemroot%\system32\adsiedit.dll

Once youve installed ADSIEdit, you can start it by choosing Start, Run, then typing
adsiedit.msc

in the dialog box or by loading the ADSIEdit snap-in into an MMC console. When you start the
tool, three folders are listedDomain NC, Configuration Container, and Schema. These are
ADs three naming contexts.
Naming contexts are partitions in AD. A full discussion of them is beyond the scope of this
book, but for our purposes, GPCs are always stored in the Domain NC folder. Expand this folder,
and youll see a structure very similar to that shown in the Active Directory Users and
Computers tool. If you select CN=System, then CN=Policies, youll see a list of folders, named
with their GUIDs. These are the GPCs that reside in the domain (see Figure 2.5).

Figure 2.5: Using ADSIEdit to view GPC objects.

38

Chapter 2
Once youve exposed the GPC objects using ADSIEdit, you can review the properties of each
GUID to find a GPO by its friendly name. Right-click a GUID and choose Properties from the
context menu. The Properties dialog box appears. For example, suppose youre looking for the
Default Domain Controller policy. In the Select a Property to View text box, choose the
displayName property from the drop-down list (see Figure 2.6). The Value(s) text box at the
bottom of the dialog box displays the friendly name for that GPO.

Figure 2.6: Reviewing GPC property information in ADSIEdit.

In this next section, Ill take a look at the GPOs template information, or what is commonly
referred to as the file-system part of a GPO.
The GPT
The GPT provides an additional level of storage as it pertains to the GPC. The GPT stores policy
settings that dont store well in AD. The GPT is a template or a suite of files stored on a Win2K
domain controller. A particular GPT is tied to its associated GPC through a special property on
the GPC object under the Policies container.
GPTs and GPCs have a one-to-one relationship. In other words, you generally cant (and shouldnt)
have a particular GPT referenced by more than GPC.

39

Chapter 2
To see the relationship between a GPT and a GPC, display the Properties dialog box for a GPC
in ADSIEdit. In the Select a Property to View text box, choose the gPCFileSysPath property
from the drop-down list. This property translates to the path to the GPT for this particular GPC.
(See Figure 2.7.)

Figure 2.7: Viewing the gPCFileSysPath property on a GPC object.

As you look at the Value(s) text box in Figure 2.7, youll see a rather long entry. The following
is a typical example:
\\domain.tld\sysvol\domain.tld\Policies\{6AC1786C-016F-11D2-945F00C04fB984F9}

Note that the GUID in the entry above is the same as the title bar in Figure 2.7. This shows that
the GPC and the GPT share the use of the GUID to ensure consistency, regardless of the GPOs
friendly name.
The value of the GPT is that it gives software vendors (Microsoft included) who want to Group
Policyenable their applications the flexibility to provide policy-related configuration data (for
example, files and file folders) that isnt conducive to being stored in AD. This apparent
disconnection between the GPT and the GPC can cause many problems with GPO processing
that youll need to be aware of. (This is discussed in greater detail in Chapter 6.) Later in this
chapter, Ill discuss GPO versioning, which is the principal method by which Microsoft attempts
to ensure that for a particular GPO, the contents of both the GPC and the GPT are synchronized
before being processed by a user or computer. (See GPO Versioning.)
40

Chapter 2

Figure 2.8:Viewing GPT file-system objects.

Compare Figure 2.8 with Figure 2.7, and youll see that the title bars show the same GUID, but
the content in Figure 2.8 is a view of the file system on a Win2K domain controller. Specifically,
Figure 2.8 is the SYSVOL share point found on all domain controllers, and it shows the contents
of a GPT. As you can see, its composed of a number of files and folders, which Ill describe in a
later section. (See GPT Storage.)
Because a GPT is stored in SYSVOL, its replicated to all domain controllers in a particular
domain. When you create or edit a GPO, in effect, youre creating or editing a GPC on the
domain controller that youre currently focused on, and youre correspondingly creating or
editing a GPT on the same domain controller in SYSVOL. As the domain controller replicates
AD and SYSVOL, so is your GPO distributed throughout your AD infrastructure.
The NT File Replication Service (NTFRS) is responsible for replicating the SYSVOL structure among
domain controllers. However, AD is replicated using a different mechanism and can replicate on a
different schedule from NTFRS.

In the next section, Ill drill into GPC and GPT storage. Namely, Ill take a close look at the
contents and subcontainers of the GPC and the GPT.

Storing Group Policy Settings

The mechanism used by Group Policy for storing settings is versatile. However, this versatility
breeds some complications. Its critical that you understand the underlying storage mechanisms
in order to effectively manage and troubleshoot GPOs in your infrastructure.

41

Chapter 2
As I mentioned earlier and in Chapter 1, Group Policy allows software vendors to Group Policy
enable their applications. When making the decision to integrate with Group Policy, developers
must consider their storage options.
Group policy settings can be stored in three places; these are shown in Table 2.1.
Location

Content Should Be

Container

AD

Typically less than 100KB in size, binary, alphanumeric, and so on. Doesnt change very often.

GPC

SYSVOL\policies\<GUID>\<User
or Machine>\Registry.pol

Administrative Template (that is, registry) policy.

GPT

SYSVOL\policies\<GUID>\<User
or Machine>\<vendor or custom
folder>\customFile

Any policy-related configuration data.

GPT

Table 2.1: Options for storing settings in GPOs.

Ill start with a more detailed description of GPC storage, then move into whats stored on the
file system under the SYSVOL share point.
Storing GPC Information
A GPC object has two important subcontainers in AD. These two subcontainers (see Figure 2.9)
correspond to the AD objects we envision Group Policy managingnamely, people (users) and
machines (computers).

Figure 2.9: User and Machine subcontainers in a GPC.

42

Chapter 2
As with the GPT, any software vendor has the ability to extend the user or machine
subcontainers to provide AD-based policy storage for their applications. Earlier in this chapter, I
discussed using ADSIEdit to view some of the properties on a GPC object. Table 2.2 provides a
description of some of the more interesting properties in a GPC.
Property

Description

displayName

The Group Policy friendly name shown in the MMC Group Policy
tool and on the Group Policy tab of Sites, Domains and OUs.

gPCFileSysPath

The file-system location of the GPT. It typically points to the

SYSVOL share point.

gPCFunctionalityVersion

Defines the version of the MMC Group Policy extension that created
this GPO.

GPCMachineExtensionNames

Describes, in GUID form, the extension DLLs, or Group Policy

functionality, defined for computers on this GPO. If Disable
Computer Configuration Settings is selected in the policys
Properties dialog box, this is blank.

GPCUserExtensionNames

Describes, in GUID form, the extension DLLs, or Group Policy

functionality, defined for users. If Disable User Configuration
Settings is selected in the policys Properties dialog box, this is
blank.

VersionNumber

The version of the policy in the directory. Its compared to the

version in the gpt.ini file in the GPT to determine how a client
extension might react to the GPC or GPT being outofsync. (For
details about GPO versioning, see GPO Versioning further on in
this chapter.)

Table 2.2: A list of some important properties on GPC objects in the Policies container.

The Class Store Container

In Chapter 1, I described the GPO software installation feature, which lets an administrator
publish or assign applications to users and computers. If you look at a GPC in ADSIEdit where
an application has been published or assigned using software settings, youll see the Class Store
container listed under either the user or the machine subcontainers. The Class Store container has
yet another subcontainer called Packages. The Packages container stores objects of class
packageRegistration, which represent each application that has been assigned or published on
this GPO (see Figure 2.10).

43

Chapter 2

Figure 2.10: Viewing the Class Store subcontainer of a GPC.

The Class Store provides a powerful tool for developers and administrators. Think of the Class
Store as an AD-based version of the Win2K registry. More specifically, its an AD version of
HKEY_CLASSES_ROOT, the registry subtree that holds useful configuration information about
file-extension associations and COM objects that are installed on a particular system.
As discussed in Chapter 1, when you assign an application to a user, the application registers up
to three advertisements on the users computer. These advertisements include file shortcuts, fileextension associations, and COM interfaces (if any). For this last form of advertisement, COM
class registration, the Class Store provides a central repository of registration that lets a computer
or user processing GPOs know what COM objects have been deployed.
In addition, when a user wants to use the Add/Remove Programs applet in the Control Panel to
review which GPO-published applications are available from the network, the Winlogon process
on the computer uses an application programming interface (API) called GetGPOList to query
the associated GPCs for GPOs that apply to them. Once the API has identified the applicable
GPCs, it queries the Class Store package container to determine which applications are available
to the user, and the Add/Remove Programs applet is populated with a list of available
applications. Likewise, when GPOs are processed when a computer starts up or a user logs on,
the GetGPOList API methods review all assigned applications .
GetGPOList is an API documented by Microsoft that allows the system to pass in user or computer
information and have returned a list of applicable GPOs. GetGPOList is discussed later in this chapter
in Group Policy Processing.

44

Chapter 2
As I mentioned in Chapter 1, Group Policy makes it possible to deploy applications that you
install using file-extension activation. Normally, when a user double-clicks a file with an
extension that hasnt been registered to an application with HKEY_CLASSES_ROOT, the
familiar Open With dialog box appears, prompting the user to choose an application to open the
file.
Group Policy uses a combination of the Class Store and a file called an application assignment
script (.aas file, stored in the GPT) to guarantee that file-extension associations are advertised
when an application has been assigned to a computer or user. When a computer or user accesses
a file using that extension, Win2K then automatically installs applications with registered fileextension associations as part of a GPO-deployed application.
For example, if you assign Microsoft Office using Group Policy, a number of file extensions are
associated with it in the GPC and GPT (for example, .doc, .xls, .ppt). The next time a user logs
on or a computer restarts, these file extensions are registered in the computers local registry. If a
user then clicks a file with a registered extensionfor example, a Word .doc filethe Office
package will be installed at that time.
There are several reasons why developers can take advantage of the Class Store too. Developers
can create applications installed using the Windows Installer engine and packaging format.
These application packages contain information about DLL files, or COM objects, that might be
needed by other applications. When an application is published or assigned in a GPO, references
to any COM objects that are exposed by that application are stored in the GPC in the
packageRegistration object for that application. These references are stored, using their
associated GUID, in the cOMClassID property on the object.
If an application running on the workstation makes a subsequent call to a COM object that has
been published or assigned, the API that calls the object queries the packageRegistration objects
in the GPC to determine whether the necessary COM object has been registered. If it has, the
application package that contains the COM object is installed automatically from the MSI
package defined in the GPO.
The Class Store provides a valuable way for developers to use AD to make their COM components
widely and automatically available to their users.

Table 2.3 lists some of the more interesting properties in the packageRegistration object.
Property

Description

canUpgradeScript

The script that would be called if the package had an upgrade associated with it.
(See Chapter 3 for a discussion of establishing upgrade relationships.) Its
typically in the form \\domain.tld\sysvol\policies\domain.tld\policies\GUID.

categories

Contains references to application categories that an administrator can define to

help organize applications that appear in the Control Panel Add/Remove
Programs applet.

cOMClassID

The GUID(s) associated with the COM object(s) that this package contains.
When an instance of an object is created, this property is queried by APIs to
determine if the application package contains the required object.

cOMInterfaceID

Defines COM interface IDs available from this package (similar to cOMClassID).

cOMProgID

Defines the COM ProgID contained in the package. (A ProgID is the userfriendly textual representation of a COM objects Class ID.) For example, you

45

Chapter 2

Property

Description
see ProgIDs used when a Visual Basic (or VBScript) application creates a new
object instance.

cOMTypelibld

Lists any COM type libraries available with this package.

displayName

Is the display name of the application as its written in the Windows Installer
package.

installUiLevel

Is a numeric value that describes whether the basic or maximum installation UI

is used. Basic is 3. Maximum is 5.

localeID

A numerical code representing the language of the Windows Installer package.

You can find these codes in the Win2K resource kit documentation
(w2rkbook.chm) by searching on the phrase language codes.

machineArchitecture

Defines the type of system on which the package can be deployed. If the policy
were multi-platform, you could deploy packages to users on different systems.

msiFileList

Identifies the location on the network of the MSI package that installs this
application. If you changes the server where your applications were deployed
from, youd modify the 0:<File Location> value to reflect that change. Ironically,
once youve deployed the package, you cant change this value in the Group
Policy snap-in, so modifying this property is your only choice. (See the caution
below this table for information about making changes to the GPC using
ADSIEdit.) The format of this property is <n:file location>, where n can be 0
and <file location> is a valid network resource like a distributed file system (Dfs)
share point. Any value of 1 or higher identifies a Windows Installer transform file
that was identified on the Modifications tab when the application was deployed
in the GPO.

msiScriptPath

Identifies the application assignment script (.aas file) that should be called when
installing or removing an application. (This is discussed in more detail in the
next section, GPT Storage.)

packageFlags

A computed value based on settings on the Deployment tab of a GPC.

packageName

The actual name of the package in the Group Policy tool.

packageType

A numeric value differentiating Windows Installer (.msi) packages from custom

script packages called .zap files. (For more information on .zap files, see
Chapter 3.) Windows Installer is 5. ZAP is 3.

productCode

Octet representation of the product code, shown in the form of xxxxx-xxxxxxxxxx-xxxxx.

setupCommand

The value used in .zap files for installation.

url

The application-vendor URL that is listed on the general page of a package.

versionNumberHi

Because version numbers use dotted decimal notation, this describes the whole
number, or the tens place. For example, in Version 2.0, 2 is the
versionNumberHI.

versionNumberLow

Related to versionNumberHi Represents everything to the right of the dotted

decimal notation version number. In the example of Version 2.0,.0 is the
versionNumberLow.

Table 2.3: Important properties on packageRegistration objects in the GPC.

46

Chapter 2

Be careful about editing the properties of a GPC directly in ADSIEdit. As Ill explain later in this
chapter, GPO versioning is the mechanism by which Win2K computers validate whether the GPC and
GPT are in sync when processing a GPO. (See the section entitled GPO Versioning.) Versioning is
normally controlled using the MMC Group Policy snap-in. When you make a change to a GPO, the
GPC and GPT version information is incremented to reflect the change. When you make a change to
a GPO, it may require changes to both the GPT and the GPC or to one but not the other, but the
Group Policy tool will increment version information on both. If you make a change to a GPC using a
tool such as ADSIEdit, you may be circumventing GPO versioning, creating a situation where your
Win2K computers think your GPOs are in sync when in fact, theyre not.

Storing GPT Information

Recall from the last section the property on the GPC called gPCFileSysPath; it points to a folder
on the domains SYSVOL share point that references the associated GPT for that GPC. An
example is \\domain.tld\sysvol\domain.tld\Policies\{6AC1786C-016F-11D2-945F00C04fB984F9}.
If we step up one level from the path shown above, we see that SYSVOL contains a number of
GUIDs representing the GPTs for each GPO defined in the domain. Remember, all policy has to
be stored somewhere. Its always stored on domain controllers in some domain in the forest.
In a new AD domain, the Policies folder contains at least two GUIDs relating to the default
GPOs available for the domain. Table 2.4 shows the relationship between GUID and policy for
default domain policies.
GUID

Policy Name

{31B2F340-016D-11D2-945F-00C04FB984F9}

Default Domain Policy

{6AC1786C-016F-11D2-945F-00C04fB984F9}

Default Domain Controller Policy

Table 2.4: GUID-to-policy mapping for default domain policies.

Once you open a GUID folder using file explorer, whether its a default policy or one that youve
created, you start to see the guts of the GPT. If you refer back to Figure 2.8, youll see the default
top-level folders for a GPT. Table 2.5 describes the purpose of these folders.
Object

Purpose

Adm

All of the Administrative Templates (.adm files) for a policy. If you add an
administrative template (.adm) file to a policy its stored here and replicated
throughout the domain.

Machine

All machine policy, including registry policy.

User

All user policy, including registry policy.

GPT.ini

Version information about the GPT. It allows extensions to gracefully fail if there is a
synchronization problem between the GPC and the GPT.

Table 2.5: A description of the contents of the Objects folder in a GPT.

To expand on the information in Table 2.5, the Adm folder stores Administrative Templates
(.adm files) used by the Group Policy editor. The default files in the Adm folder are:

conf.admManages Net Meeting settings using policy

47

Chapter 2

inetres.admManages IE settings

system.admManages all registry settings associated with the OS

The Machine and User folders are very similar in structure, so Ill discuss them in tandem. If you
look at the User folder in the GPT GUID, youll find something similar to Figure 2.11.

Figure 2.11: The folder structure of a User GPT.

Ill now drill down into each folder in the User and Computer folders and describe its function.
Applications Folder
The Applications folder in Figure 2.11 stores files relating to applications being deployed using
the Software Installation feature in Group Policy. The files in this folder contain application
assignment scripts using the file-name format <GUID>.aas. The GUID refers to the
packageRegistration object in the Class Store of the GPC. The files can be viewed in Notepad,
but the .aas extension has no default association. As I mentioned above, the .aas script allows
advertisements to be registered for a particular application deployed using Group Policy.
Documents and Settings Folder
Figure 2.11 shows the Documents and Settings folder. This folder appears only when youve
configured the Folder Redirection feature in Group Policy. The Folder Redirection extension
code on the client reads this folder when the user logs on, and the extension determines the folder
redirection settings for the user.
The Documents and Settings folder contains a special text file named fdeploy.ini that contains
configuration-related information. An example of the file is shown in Listing 2.1.

48

Chapter 2

[FolderStatus]
Application Data=39
Desktop=39
My Documents=39
My Pictures=2
Start Menu=28
Programs=2
Startup=2
[Application Data]
s-1-5-21-970468228-843086746-623648099-1714=\\dks\corp\musers\%username%\appdata
[Desktop]
s-1-5-21-970468228-843086746-623648099-1714=\\dks\corp\musers\%username%\desktop
[My Documents]
s-1-5-21-970468228-843086746-623648099-1714=\\dks\corp\musers\%username%\docs-n-pics
[My Pictures]
[Start Menu]
s-1-5-21-970468228-843086746-623648099-1714=\\dks\corp\musers\%username%\startmenu
[Programs]
[Startup]
Listing 2.1: The fdeploy.ini file, which is located in a users Documents and Settings folder.

The FolderStatus section describes the options selected on the Settings tab of each redirected
folder. The sections beneath FolderStatus refer the workstation to the correct network or filesystem location for the redirected folder. In the example above, members of a user group
(represented by their security identifiers, or SIDs) are being redirected to various folders under a
Dfs share point (for example, \\dks\corp).
The SIDs that appear within the file (for example, s-1-5-21.and so on) refer to the SIDs of
users and groups and are used instead of friendly names because such names can change. Using
SIDs ensures that the user folders are always redirected regardless of the user or group names.
Microsoft Folder
The Microsoft folder is really just a vendors folder and is found under both the machine and
user sub-folders within a GPT. Any application vendor can, and by design should, create a folder
within the GPT for its applications that are Group Policyenabled. In Microsofts case, several
applications are Group Policyenabled and are stored in this foldernamely the Security
Configuration Editor, the IEAK and RIS settings.

The Security Configuration Editor settings are stored in the Machine sub-folder. The
Security Configuration Editor tool was first introduced in NT 4.0. In Win2K, we
commonly refer to it as Secedit. Its data is stored in a template file in
SYSVOL\domain\policies\<GPO GUID>\Machine\Microsoft\Windows
NT\Secedit\gtptmpl.inf.

49

Chapter 2

The Microsoft folder also stores settings used by the IEAK. Its data is found in a series of
folders under SYSVOL\domain\policies\<GPO GUID>\User\Microsoft\IEAK and
contains information that the IEAK would typically create and that an administrator
would deploy. Having these settings integrated into Group Policy is a convenient way of
enforcing IE configuration and branding settings across multiple machines
simultaneously.

Finally, the RemoteInstall folder, also found under SYSVOL\domain\policies\<GPO

GUID>\User\Microsoft, provides settings to a client machine starting up without an OS
and is trying to run a Win2K installation from the RIS server. The settings in the folder
are very basic and can be discerned by reviewing the oscfilter.ini file.

Any vendor can create a companyName folder in the User or Machine folder to store file-based
configuration data for its applications.

Scripts Folder
The Scripts folder exists in both the User and Machine folders and provides a mechanism for
distributing logon, logoff, shutdown, and startup scripts to users and computers in your
environment. The Scripts folder in the User folder stores logoff scripts in the Logoff folder and
logon scripts in the Logon folder. In the Machine folder, the Scripts folder stores shutdown
scripts in the Shutdown folder and startup scripts in the Startup folder.
When youre adding a script to a GPO, if you select the script file from a local file system, such
as your administrative workstation, the Group Policy tool doesnt automatically copy the script
file to the appropriate Scripts folder in the GPT. Before you add a reference to the script file in
the Group Policy tool, you must copy the file manually to the appropriate folder in the GPT.
Once you create references to scripts in a GPO, they automatically appear in a scripts.ini file.
This file is created in the Scripts folder; it controls the processing order of the scripts and
references their locations in the file-system. Its important to note that just because a script exists
in the Logon or Logoff folder, it isnt necessarily processed. The scripts must be assigned in the
scripts.ini file, which is populated using the Group Policy snap-in UI. The following is an
example of a User scripts.ini file:
[Logon]
0CmdLine=\\DCServer\sysvol\domain.tld\Policies\{5DE00B1E-29184B82-8CEF-790296F4DFF8}\User\Scripts\Logon\startup.cmd
0Parameters=
[Logoff]
0CmdLine=\\DCServer\sysvol\domain.tld\Policies\{5DE00B1E-29184B82-8CEF-790296F4DFF8}\User\Scripts\Logoff\cleanup.cmd
0Parameters=

The file above can be interpreted slash for slash. In this example, the first of possibly many
logon scripts is referenced by a numeric prefix (that is, 0). The script that is executed is provided
by the 0CmdLine key. The 0Parameters key lists any optional command-prompt parameters
that you provide for starting the script.

50

Chapter 2
Registry.pol
The registry.pol file exists in both User and Machine folders. It stores all of the settings that have
been activated in the Administrative Templates section in a GPO. The Adm folder mentioned
earlier has an impact on this folder. When you open the Group Policy tool, it loads the
Administrative Templates (.adm files) stored in the Adm folder, and these files control the
settings that you see in the Administrative Templates section. When you expand on the
Administrative Templates folder in the Group Policy tool, the registry.pol file is loaded for the
appropriate node youre viewing (User or Machine).
The registry.pol file is also read by the client OS when a computer starts up and when a user logs
on. Its then reread periodically thereafter.
GPO Versioning
GPOs track version numbers each time you make a change to them. This version data is
referenced by the code that processes a GPO on the client machine. Namely, its used to
determine whether something in the GPO has changed from the last time it was processed and
whether the GPT and GPC are in sync (and can therefore be reliably processed). If the version
numbers of the GPT and GPC for a GPO arent the same, a Win2K system querying that GPO
will simply not attempt to process it. In this section, Im going to explain how GPOs track
version numbers.
In the GPT, the version number is kept in a file in SYSVOL\<domain>\policies\<GUID> called
gpt.ini. This is a simple text file like the example below, which shows that the version of the
GPT is 65:
[General]
Version=65

In the case of the GPC, version number information is stored as a property in AD called
versionNumber. As youd expect, you can view this property using the ADSIEdit tool described
earlier in the chapter. (See Finding GPO Friendly Names from Their GUIDs.)
For a GPO to be considered in sync, the version numbers of the GPC and GPT must be identical
on each domain controller in the domain. Replication problems in AD or SYSVOL can cause a
GPO to get out of sync on some domain controllers.
You can easily see which GPOs in a given domain are in sync on a domain controller by using
the Replication Monitor (Replmon.exe) tool that comes with the Win2K Support Tools. Rightclick a domain controller in Replmon and choose Show Group Policy Object Status from the
context menu. Youll see a listing of all the GPOs in your domain for that domain controller (see
Figure 2.12) as well as the current versions of the GPC (listed under Version) and GPT (listed
under SysVol Version). If the GPC and GPT versions of any GPO are out of sync, a check mark
will appear in the Sync column on the left of the table.

51

Chapter 2

Figure 2.12: Viewing Group Policy replication status using ReplMon.

Youd think that whenever you edited a GPO, the version numbers for the GPT and GPC would
be incremented by 1. However, thats not the case, and the actual versioning process isnt the
slightest bit intuitive. As you know, there are two sections in a GPOcomputer and user. Each
of these sections actually maintains its own version information. This is because when a Win2K
device is processing a GPO, it needs to know, for computer and user sections, whether there has
been a change from the last time the GPO was processed. If only one version number were kept
for both computer and user sections, there would be no way to know if a change was made to one
section but not the other.
Because a separate version number is kept for each section, only the section of the GPO that has
changed will be processed the next time the system reads the GPO. You can view version
information for each section in a GPO by opening the GPO in the Group Policy MMC snap-in,
selecting the GPO name, right-clicking, then selecting Properties from the context menu. On the
General tab, the Revisions property displays values for both Computer and User (see Figure
2.13).

52

Chapter 2

Figure 2.13: Viewing the revision information for a GPO.

These revision numbers will often be different from the actual version numbers stored in the
GPC and GPT, and thats where GPO versioning starts to become counterintuitive. Version
numbers for each section of a GPO increment at different rates. Specifically, each change to the
computer section of a GPO increments the version number by 1. However, each change to the
user section of a GPO increments the version number by 65536! For example, if Ive made ten
changes to the user section of a GPO and none to the computer section, the Revisions property in
the General tab of the GPO will read:
0 (Computer), 10 (User)

The corresponding version numbers for the GPT (in GPT.ini) and GPC (in the versionNumber
property) will be 10 x 65536 or 655360. When I make the first edit to the computer section on
that GPO, the Revisions property will show:
1 (Computer), 10 (User)

However, the version number stored in gpt.ini and the versionNumber property in the GPT and
GPC, respectively, will show 655361 (655360+1). Each additional change I make to computer
section of that GPO will increase the version number by 1, and each additional user section
change increases it by 65536.
To reiterate, the revision numbers you see on the GPOs General properties tab is the number of
changes made to either the user or the computer section of the GPO since it was created. The

53

Chapter 2
version number of the GPO is a calculated value that is kept for both the GPC and GPT; it
determines whether each is in sync with the other.
Group Policy Processing
Group Policy processing flows as follows: identifying which policies are associated with a user
or computer, calling the appropriate CSE DLLs, reading the policy information from the GPT
and GPC, and updating the computer and user settings appropriately. Before we get into that,
lets first think about how the system determines which policies are associated with a user or
computer.
I discussed in Chapter 1 that Win2K Group Policy can be linked at three different levels: by site,
domain, and OU. Whenever you link a policy to a site, domain, or OU, the policys distinguished
name (DN) becomes an entry in a special property of the site, domain, or OU called gPLink (see
Figure 2.14).
For more information about gPLink, see Chapter 3.

Figure 2.14: Viewing the gPLink property with the DN of the GPC object. The first half of the DN is shown in
the Edit Attribute text box, while the second half is shown in the Value(s) text box.

Win2K uses the previously described GetGPOList API to identify which GPOs should be
processed on the client. While GetGPOList is being executed on a computer, the computer name

54

Chapter 2
and IP address are used to determine the correct site of the GPOs that may be associated with the
computer. Similarly, wherever the computer (or user) exists in the domain and in an OU,
GetGPOlist uses this info to determine whether any additional GPOs apply.
Next, once the list of applicable GPOs is discovered, version information and other GPO options
are examined to determine which of the required GPOs must actually be processed during the
current cycle. For example, GPOs that havent changed since the last time they were processed
wont be processed again unless the administrator has forced such an operation.
Finally, the required CSE DLLs will process policy for each applicable GPO. These DLLs are
installed by default on a Win2K system and registered in the registry under
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions.
Of course, Group Policy is extensible by any software vendor, so the CSEs registered on a given
Win2K system may not be identical to a default Win2K installation. Its important to remember
that CSEs do the real work of enforcing GPO policy. They read the settings stored in the GPT
and GPC and use that data to apply policy for whichever feature theyre responsible for.
Bringing It All Together
As users start their computers and proceed to log on to a Win2K system, Group Policy
processing begins. As the system is starting, it obtains an IP address statically or from the
Dynamic Host Configuration Protocol (DHCP) server. This IP address allows the system to
communicate with a domain controller for authentication and secure channel connection to the
domain.
Once a secure channel is created, the client calls GetGPOList. The client identifies its site based
on its IP address and site information stored in AD. Having a computer account allows
GetGPOList to find the domain the account belongs in as well as the OU. Once the client has
obtained the list of GPOs, it prioritizes all of the GPOs, then queries gPCFileSysPath for each
GPO so that it can find the GPT.
Once the final computer-specific GPO is processed, the user is presented with the CTRL-ALTDEL dialog box. When the user types in a user name and password, a login is sent across the
secure channel the computer has with a domain controller. The domain controller replies to the
user with Kerberos tickets, and the policy processing for the user begins. Once all of the GPOs
are processed by the appropriate CSE DLLs, policy processing is complete.

Summary
In this chapter, I began by describing the architecture of Group Policy. The GPO is really
composed of a GPC, stored in AD, and a GPT, stored with the SYSVOL share on each domain
controller. Later in the chapter, I tied together the details of the GPC, GPT, and settings storage
in the form of policy processing.

55

Chapter 3

Chapter 3: Creating Group Policies Step by Step

In Chapter 1 of this book, I explained GPOs and what capabilities they provide. Chapter 2
dissected the structure of GPOs and their interaction with AD. In this chapter, Ill take you
through the next stepthe details and process of creating and maintaining GPOs. As I hope
youve gleaned by reading the first two chapters, GPOs are considerably more complex than the
old NT 4.0 system policies.
My focus in this chapter is on creating GPOs in an AD environment. Local GPOs can be
interesting and useful in certain situations and when you dont have an AD infrastructure, but
where the real power (and complexity) lies is in AD-based GPOs. To that end, Ill use Chapter 4
to talk about real-life considerations for designing a GPO implementation for your enterprise.
However, first things firstlets dive into the details of creating and maintaining GPOs.

Creating AD-Based GPOs

In Chapter 1, I introduced the MMCbased Group Policy snap-in. This tool is your primary (and,
indeed, only) interface for creating and editing GPOs. So this is where Im going to start. Lets
suppose you want to create a GPO linked to a domain called mycompany.com. The first thing
you need to do is start the Active Directory Users and Computers MMC tool. If youre creating a
GPO that is linked to an AD site object, youll need to start the AD Sites and Services MMC
snap-in instead.
If you dont have the Active Directory Users and Computers or AD Sites and Services MMC console
tools installed on your Win2K workstation, you can install them by locating the .msi file called
adminpak.msi, located in the i386 folder on the Win2K Server CD-ROM. Installing this file will install
all the Win2K server administration snap-ins on your workstation.

To begin, you need to ensure that youre logged in to your AD domain with a user ID that is
capable of creating GPOs. Ill talk more about GPO security later in this chapter (see Security
Settings) and in Chapter 5, but to create (and edit) a GPO in a default AD installation, you need
to be a member of one of the following groups:

Domain Admins (Global Group)

Administrators (Domain Local Group)

Enterprise Admins (Global Group)

Group Policy Creator Owners (Global Group)

When the Active Directory Users and Computers MMC tool loads, itll focus on the domain to
which the workstation or server from where youre running the tool belongs. So, if youre
running the tool from a workstation that is a member of the mycompany.com domain, the tool
will be focused on that domain when it starts. To create a GPO linked to a domain, right-click the
domain name listed at the top of the left-hand pane in the MMC tool. My example shows
mycompany.com. Choose Properties from the context menu, then in the Properties dialog box
click the Group Policy tab to see the Group Policy page, shown in Figure 3.1.

56

Chapter 3

Figure 3.1: Viewing the Group Policy page for the domain properties in the Active Directory Users and
Computers MMC snap-in.

The view you see in Figure 3.1 shows you the GPOs that are currently linked to the
mycompany.com domainin this case, its just the Default Domain Policy. The Default Domain
Policy is a special GPO in AD. This policy exists in all default AD installations and in fact cant
be deleted by normal means. If you attempt to delete this GPO using the Group Policy snap-in,
your request will appear to succeed, but the GPO wont actually be removed.
This is because this GPO serves a special functionnamely, guaranteeing that there is always a
way of defining domain security policy, irrespective of whether youre using GPOs for any other
purpose. Remember from Chapter 1 that one of the key features of the GPO is security
configuration management. And, in particular, domain account policy can only be defined in a
GPO linked at the domain level. The persistence of the Default Domain Policy guarantees that
there is always a way of defining account policy on a domain.
In my example, Im going to create a GPO, linked to the mycompany.com domain, called Test
GPO. To create a GPO, I simply click New on the Group Policy page. A GPO is created with the
temporary name New Group Policy Object. Now Im free to edit the name to something more
meaningful for my installation.
When I click New, two operations are happening behind the scenes. First, the physical GPO is
created in AD and the SYSVOL share, (For more information about the physical structure of
GPOs, see Chapter 2.) Then a link is created between the GPO and the domain. As you saw in

57

Chapter 3
Chapter 2, the link is really an AD attribute on the objectdomain, site, or OUthat youre
linking to. When these steps are complete, you have a fully functional GPO. And by fully
functional, I mean that from that moment forward, your GPO is live and can be processed by any
user or computer in the domain with permissions to do so.
Later in this chapter, Ill show you how you can create a GPO without actually linking it to an AD
object. This technique comes in handy if youre creating GPOs that you dont want users or
computers to process right away.

Of course, the important part, editing the GPO to set up your management functionality, is the
next step.

Editing GPOs
Once youve created the GPO, you can turn to the task of editing it. In the Properties dialog box
where you created the GPO, select your new GPO and click Edit. At that point, an instance of the
Group Policy MMC snap-in opens in a separate MMC console, focused on the new GPO. As you
can see, the familiar Group Policy editor interface, as described in Chapter 1, is presented here.
Remember that GPOs break configuration information into computer and user nodes. Under each
node is the functionality that is available.
To illustrate the editing process, Ill walk through setting up some security policy on my Test
GPO. Lets suppose that I want to set up auditing policy for all computers in the domain
mycompany.com. Because Test GPO is linked to the domain, all computers that are members of
the mycompany.com domain will process this GPO.
GPOs linked to a domain are processed by all computers and users in that domain. The exception to
this rule is that you can filter the processing of GPOs using AD security groups. Ill talk more about
security-group filtering later in this chapter (see Security Settings).

To set up auditing policy, I need to drill into the Computer Configuration section of the GPO
under Windows Settings, Security Settings, Local Policies. Figure 3.2 shows where Audit Policy
is located in a GPO.

58

Chapter 3

Figure 3.2: Viewing Audit Policy in the Computer Configuration section of a GPO.

As you can see in the right-hand pane in this figure, you can set a number of audit categories. For
example, setting Audit Account Logon Events to log success events tells any Win2K computer
subject to this GPO to create entries in the security event log any time a user successfully logs
onto that account. Domain controllers ignore local policy (for example, auditing policy) set at the
domain level in favor of local policy defined in the Default Domain Controllers Policy GPO.
However, you can set local policy in a domain-linked GPO for processing by workstations and
member servers in the domain. To set auditing policy, simply double-click the policy item of
interest in the right-hand pane of the Group Policy console. Youll be presented with the Security
Policy Setting dialog box, like that shown in Figure 3.3.

59

Chapter 3

Figure 3.3: Viewing options available when setting auditing policy.

As shown in Figure 3.3, you enable auditing policy by clicking the Define These Policy Settings
check box, then choosing to log success events and/or failure events. Specifying success events
indicates that you want to generate a security event log entry every time an operation of the
chosen type succeeds. For example, in Figure 3.3, Im enabling auditing of directory service
access. Whenever someone successfully accesses AD on a particular domain controller, a
success event is registered in the security event log. Likewise, if you specify failure events, when
someone attempts to access AD and is denied access for whatever reason, a failure event is
logged on that domain controller.
When you click OK in the Security Policy Setting dialog box, your change is immediately
committed to the GPO and is available for processing. This example explains editing just one
section of a GPO. Ill spend more time later in this chapter detailing how you can set policy on
some of the other GPO nodes of functionality.
Setting GPO Options
In addition to making basic edits to a GPO to set the policys functionality, you have a couple of
options that you can set on the GPO to further control its effect. On the Group Policy page of the
Properties dialog box shown in Figure 3.1, youll notice the Options button. Clicking Options
displays the Test GPO Options dialog box, shown in Figure 3.4.

Figure 3.4: Viewing the options settings available on a GPO.

60

Chapter 3
The two check boxes in this dialog box allow you to set the No Override and Disabled options on
a GPO.
No Override
When you click the No Override check box, an attribute is set on the container object in AD
where this GPO is linked. This attribute, introduced in Chapter 2, is called gPLink. For example,
if my Test GPO is linked at the domain level, gPLink is defined on the domain object called
mycompany.com in my AD. This object is viewable using the ADSI Edit tool introduced in
previous chapters. Setting the No Override option for a GPO linked to a container modifies the
gPLink attribute on that container.
Normally, the gPLink attribute on a container contains a bracket ([])delimited list of the GPOs
that are linked to it. The GPOs are referred to by their Lightweight Directory Access Protocol
(LDAP) DNsas described in Chapter 2. An example is shown here:
LDAP://CN={BB8724E4-8BD8-4C31-BA12EA7E69246D16},CN=Policies,CN=System,DC=mycompany,DC=com

The gPLink attribute contains a list of these LDAP distinguished names, with an option flag
tacked onto the end of each GPO referenced. If No Override is enabled, this option flag is set to
the value 2, as shown in Figure 3.5. (A normal GPO linked to a container without No Override
enabled will have a value of 0.)

Figure 3.5: Enabling No Override on the gPLink attribute for a linked GPO.

61

Chapter 3
The gPLink value for a GPO with No Override enabled looks like the following:
[LDAP://CN={BB8724E4-8BD8-4C31-BA12EA7E69246D16},CN=Policies,CN=System,DC=mycompany,DC=com;2]

Because No Override is set at the gPLink level, a GPO can be linked to, say, a domain, and be
set to No Override. However, the same GPO can also be linked to an OU in that domain without
No Override being set on that OU. The point here is that the No Override feature is set at the
container GPO link level rather than as an option in the GPO itself.
So now that we know what gets set in AD when No Override is enabled, what does this feature
actually do? No Override enforces a particular GPOs settings that could otherwise be nullified
by another GPO that is processed afterwards. For example, suppose Ive defined an
Administrative Template policy that has been linked at the domain level in my AD domain. This
policy performs a particular desktop lockdown that I want to enforce across all users in my
domain.
Now suppose an administrator who manages an OU in my domain creates a GPO that sets a
contradictory Administrative Template policy to mine and links that GPO to his OU. Normal
GPO processing precedence, if youll remember from Chapter 1, is: local, site-linked, domainlinked, and OU-linked. This means that the OU administrators OU-linked GPO will process last
and override my own domain-linked GPO. By setting No Override as an option on my domainlinked GPO, I prevent that from happeningthe OU-based GPO settings for Administrative
Template lockdown are simply ignored.
Its important to note that No Override is implemented at the CSE level. That is, if I set No
Override on a GPO linked to my domain, and only define Administrative Template settings in
that domain GPO, other settings defined by OU-linked GPOs, such as local security policy or
software installation settings, wont be overridden by my domain-linked policy. If, after I create
my domain-linked GPO, I decide to edit that GPO to add a software installation policy, the No
Override option will kick in and override any software installation policy defined on the OUlinked GPO.
Disabled
The other GPO option that you can set is called Disabled. This option is again specific to the
container to which the GPO is linked. And as with No Override, Disabled is implemented by
setting the value at the end of the LDAP distinguished name for a particular GPO contained in
the gPLink attribute. As I mentioned, No Override sets this value to 2. Clicking Disabled sets
this value to 1.
If you set both No Override and Disabled for a GPO link, the value placed in the gPLink attribute for
that GPO will be 3.

The Disabled option does just as its name implies: It disables the GPO linked to the particular
container (for example, site, domain, or OU). A disabled GPO link is no longer processed by
computers or users who are subject to it. In addition, if a GPO link is disabled, any settings that
had previously been enforced by that GPO are supposed to be undone during the next processing
cycle by the computers subjected to it.

62

Chapter 3
I say supposed to because Ive experienced situations where this was not the case. Specifically,
after I implemented the Folder Redirection feature in a GPO, disabling that GPO didnt undo
Folder Redirection. Ive reproduced this reliably and suggest that you test this in your own
environment before making assumptions about what the Disabled option can do for you.
You can also access the No Override and Disabled options by right-clicking the name of the GPO in
the GPO Properties dialog box on a given container. For example, on the Group Policy page (see
Figure 3.1), if I right-click Test GPO, I get a context menu with the No Override and Disabled options
at the top. Choosing one has the same effect as clicking the corresponding check box in the Test
GPO Options dialog box (see Figure 3.4).

Blocking Policy Inheritance

Refer again to Figure 3.1 and notice the Block Policy Inheritance check box. As you know,
GPOs are processed using a particular order of precedence. You often see this order represented
by the acronym LSDOU. First the local GPO (LGPO) is processed, then any GPOs linked at the
site, domain, or OU levels are processed in turn. If a workstation or user is defined in a nested
OU hierarchy (for example, the workstation or user is part of the Accounting OU, which is part
of the Finance OU, which is part of the US-Corp OU), that workstation or user may be
processing any number of GPOs linked at each level of the hierarchy.
Normally, GPOs are inherited. This means that GPOs linked to a domain are automatically
processed by all computers and users in that domain. Those GPOs linked to a parent OU are
processed by all computers and users who are a member of that OU as well as in nested OUs.
This is called policy inheritance, and it can be turned off at either the domain or OU level by
clicking the Block Policy Inheritance check box shown in Figure 3.1. (Policy inheritance cant be
turned off at the site level: site GPOs are always processed first and cant be nested within each
other.)
You block policy inheritance at the container level (that is, at the domain or OU level). Blocking
policy inheritance at the domain level means that any site-linked GPOs are ignored by users or
computers processing GPOs. Blocking policy inheritance at the OU level means that site,
domain, and any higher-level OU-linked GPOs are ignored. Figure 3.6 illustrates how blocking
policy inheritance works.

63

Chapter 3

Figure 3.6: Blocking policy inheritance in an AD domain.

In this figure, a number of GPOs are defined at the domain, site, and OU levels. When we block
policy inheritance on the Accounting OU, not all upstream GPOs are processed by users and
computers defined in Accounting. Only the Accounting OU GPO is processed.
You block policy inheritance by setting an attribute on the container where you set this feature.
Using the ADSI Edit MMC snap-in, right-click the container object in the console, then choose
Properties from the context menu. In the Properties dialog box, click the Attributes tab. When
block policy inheritance is enabled, the gPOptions attribute is set to 1; when its not, its set to 0.
Figure 3.7 illustrates setting this value.

64

Chapter 3

Figure 3.7: Viewing the gPOptions attribute set on an AD container (domain or OU) object.

There is one exception to how the block policy inheritance feature is used. If an administrator for
a higher-level container (site, domain, or parent OU) specifies that a linked GPO supports the No
Override option (see No Override earlier in this chapter), that GPO cannot be blocked by a
downstream container. This allows an administrator at, for example, the domain level to make
sure that a particular policy is enforced regardless of what a downstream administrator may
attempt to do.
Preventing a downstream container from being blocked is useful for enforcing policy related to
security or desktop lockdown, and it may be corporate policy for all company computers. For
example, I use No Override in a GPO linked to my domain to enforce a particular set of event
log settings on all computers that are part of my domain. This guarantees that all computers have
event logs of sufficient size and rollover behavior to capture system, application, and security
events that Im interested in.
Setting GPO Properties
Another button on the Group Policy page of the Properties dialog box shown in Figure 3.1 is
Properties. Clicking Properties displays the Test GPO Properties dialog box, shown in Figure
3.8. This dialog box lets you set three types of propertiesgeneral, links, and security.

65

Chapter 3

Figure 3.8: Viewing the GPO Properties dialog box.

General
The General page, shown in Figure 3.8, lets you view general information about a GPO and also
lets you disable either computer or user settings in the GPO. Chapter 2 describes most of the
information on this page, including the GUID for this GPO, its version number, and domain.
The two check boxes, which were also described briefly in Chapter 2, let you disable one or both
sides of GPO processing in this specific GPO. These settings are GPO-specific. This means that
if this GPO is linked to multiple sites, domains, or OUs, clicking one of these check boxes will
have an impact on them all. This feature lets you optimize the performance of GPO processing in
cases where a GPO may only be using part of its total policy functionality.
For example, if Ive defined a GPO that only processes user-based software installation policy, I
might want to click the Disable Computer Configuration Settings check box. This tells the CSE
on a Win2K device that is processing this GPO to simply ignore any computer-specific CSE
processing because none is set. (Even if theyre defined, they wont be processed.) This can have
the effect of speeding the processing of GPOs in cases where a user or computer must process
many GPOs on logon or startup. Ill talk more about designing a GPO implementation with an
eye towards performance in Chapter 4.
Links
The Links page is useful for locating other container objects that have linked to this GPO. For
example, as Figure 3.9 shows, I can select a domain in my AD forest to search, then click Find
Now.

66

Chapter 3

Figure 3.9: Searching for all links to the selected GPO using the Links page in the Test GPO Properties dialog
box.

As Figure 3.9 shows, this particular GPO, called Test GPO, was found linked at both the domain
level (in mycompany.com) and OU level (in the Finance OU). This search capability can also
locate links that cross domain boundaries because, as Chapter 2 pointed out, youre free to link to
GPOs that are stored across domains in a forest.
Security
The final page is Security. Clicking the Security tab displays the familiar Win2K ACL Editor
dialog box. Just as with other objects in AD, GPOs have security associated with them. Security
is in place for two reasons: to control who can edit or link to a particular GPO and to control
what computers and users can process a particular GPO.
Ill describe using security as a GPO processing filter in more detail later in this chapter. (I also
describe using GPO security to delegate administration of GPOs in Chapter 4.) For now, suffice
it to say that you can use security, in addition to the No Override and block policy inheritance
features described earlier in this chapter, to control at a fine level of granularity what computers
and users can process.
Controlling GPO Precedence
As youve probably guessed by now, the Group Policy page of the Properties dialog box, shown
in Figure 3.1, is the hub of activity for my discussions of the various capabilities of GPOs that
you can enable! This figure provides a container-view of GPOs. That is, for a given site,
domain, or OU, it shows all of the GPOs currently linked to the container.
Youll note that when multiple GPOs are listed, the Up and Down buttons become available.
These buttons let you control the ordering, or precedence, of GPO processing at any container
67

Chapter 3
level. This makes sense when you think about it. There has to be some predictable order in which
GPOs are processed not only across containers (for example, LSDOU) but also in a container.
This Up/Down capability is very similar to the Group Priority capability that was available in NT
4.0 system policy. In the case of system policy, when a user was a member of multiple policy
groups, user groups that were assigned to a particular policy were given an order of precedence
that controlled which group-specific policy was processed first.
The Up and Down buttons on a container control which GPO is processed first, second, third,
and so on. In the case of GPO processing, the higher a GPO is in the list, the later its processed,
and therefore, the more overriding its policy. For example, in Figure 3.10, three GPOs are linked
at the domain levelDefault Domain Policy, Test GPO, and Domain User Policy. The Default
Domain Policy has the highest priority because its at the head of the list and is processed last.

Figure 3.10: Viewing the precedence of multiple GPOs defined on an AD container.

Behind the scenes, this precedence is controlled, again, using the gPLink attribute on the
container to which the GPOs are linked. Each GPO is referenced in this attribute by its GUID,
starting from the lowest GPO to the highest. The string in Listing 3.1 represents a dump of the
gPLink attribute for the container shown in Figure 3.10:
[LDAP://CN={BB8724E4-8BD8-4C31-BA12EA7E69246D16},CN=Policies,CN=System,DC=mycompany,DC=com;0][LDAP://CN={4
BF6C10B-9DDC-4E11-B702E58F8EC52534},CN=Policies,CN=System,DC=mycompany,DC=com;0][LDAP://CN={3
1B2F340-016D-11D2-945F00C04FB984F9},CN=Policies,CN=System,DC=mycompany,DC=com;0]
Listing 3.1: Example of the LDAP path contents of a containers gPLink attribute.

68

Chapter 3
Note that this listing shows the LDAP path to the three GPOs. In this case, the GUID that starts
with 31B2F is the Default Domain Policy, and the one that starts with BB872 is the Domain User
Policy.
In Listing 3.1, the ;0 after each LDAP path represents the value that holds the GPO options described
in Setting GPO Options earlier in this chapter. A 0 means that neither No Override nor Disabled is
configured for any of these three GPO links.

If I were to reorder the three GPOs listed in Figure 3.10, the precedence of the gPLink attribute
would change to reflect this.
Its important to keep this precedence in mind when youre designing your GPO implementation.
Its very possible that two GPOs linked in the same container could have policy settings that
contradict each other. In this case, the GPO with the higher precedence (higher in the list) would
win, resulting in potentially unwanted policy consequences.
Adding New GPO Links
Ive described almost all the buttons and check boxes shown on the Group Policy page of the
Properties dialog box, shown in Figure 3.1. One I have yet to mention is the Add button. How is
this button different from New? Well, New lets you create a brand new GPOwith its attendant
GPT and GPCand link it to the current container, all in one fell swoop. (For more information
about the GPC and GPT, see Chapter 2.) However, if you simply want to create a link from an
existing GPO that was defined elsewhere to this container, click Add. This displays the Add a
Group Policy Object Link dialog box, shown in Figure 3.11.

Figure 3.11: Viewing the Add a Group Policy Object Link dialog box from the GPO Properties dialog box.

This figure shows this dialog box for an OU called Test. Test is a child OU to another OU called
East, which is yet another child OU to an OU called Finance. This dialog box has three tabs
Domains/OUs, Sites, and All. The Domains/OUs tab displays any GPOs currently linked to the
container selected in the Look In text box. In this case, no GPOs are currently linked to the Test
OU.
69

Chapter 3
To see whether the GPO Im interested in linking to is present, I can select the parent OU from
the drop-down list. Or if the GPO Im interested in linking to is defined on a site, I can click the
Sites tab. Finally, to see all of the GPOs defined in this domain (or, using the drop-down list,
any domain in the forest), I can click the All tab. If I select a GPO to link to and click OK, the
GPO is added to the gPLinks attribute on the selected containerand any computers or users in
this container will process the GPO. Its that simple!
On the All page in the Add a Group Policy Object Link dialog box, you can also create a GPO without
performing the second step described abovethe linking process. That is, you can create a physical
GPO but not link it to any AD object. This can be useful if youre creating large numbers of GPOs in a
production domain but dont want them to be processed yet. To create an unlinked GPO, click the All
tab, then perform one of two actions. In any white space in the portion of the dialog box that lists the
GPO, right-click and choose New from the context menu. A GPO is created there, and you can give it
a name. Or click the icon in the upper right of the dialog box that looks like the Win2K user group
icon. In either case, you can create a GPO (with associated GPC and GPT) without linking it to a
container.

You can think of the Add function as providing the inverse of the functionality provided by the
Links page shown in Figure 3.9. The Links page lets you search the AD for all containers that
have linked to the selected GPO. The Add function lets you survey all available GPOs defined in
a forest, then choose one to link to the currently selected container.
Deleting GPOs
The final button on the Group policy page in the Properties dialog box shown in Figure 3.1 is
Delete. This button, as its name implies, lets you delete a GPO link from the selected container.
When you click Delete, there are actually two options available to you, shown in Figure 3.12.

Figure 3.12: Viewing the options for deleting a GPO or GPO link from an AD container.

As this figure shows, you can either remove the link associating this GPO to the container object,
or you can remove the link and delete the GPO itself (that is, its associated GPT and GPC). If
you choose the latter option, any other links to that GPO on other container objects will also be
removed. For example, if my Test GPO is linked to both the mycompany.com domain and the
Finance OU, deleting the link to mycompany.com and deleting the GPO itself also removes the
link to the Finance OU.
You can delete a link to a GPO without much consequence. But deleting the GPO itselfincluding its
attendant GPT and GPC piecesis an irreversible process. There is no Undo button. You can
restore a GPO from a backup of both AD and SYSVOL, but its very difficult, if not impossible, to
restore an individual GPO from such a backup without affecting all other GPOs in the domain.

70

Chapter 3

Setting Domain Controller Options

Im going to shift gears now and describe a feature that allows you to set domain controller
options. Its available in the Group Policy MMC snap-in when you open a GPO for editing.
When you choose DC Options from the View menu, the Options for Domain Controller
Selection dialog box opens, shown in Figure 3.13.

Figure 3.13: Viewing the Options for Domain Controller Selection dialog box from the Group Policy MMC
snap-in.

This dialog box controls which domain controller youre focused on (and connected to)
whenever you edit a GPO. Why is this important? As Chapter 2 presented, the physical GPO is
composed of two components: the GPC (stored in AD) and the GPT (stored in SYSVOL). Each
of these components replicates on a different schedule, and each is replicated to every domain
controller in a domain. If more than one person is editing a GPO, each can be doing so from
copies of the GPT/GPC stored on different domain controllers. This can obviously cause lots of
unexpected and undesirable results in that GPO as each domain controller replicates its changes
to the other.
To minimize this possibility, whenever an administrator starts up the Group Policy snap-in,
focused on a particular GPO, a connection is made to the PDC Operations Master role-holder in
that domain. Any changes the administrator makes to the GPO are made against the GPC/GPT
copy stored on the PDC role-holder. This minimizes the chance that two people, editing a GPO,
will make changes that will be out of sync with each other. However, you can override this
behavior using the Options for Domain Controller Selection dialog box shown above. Its the
default setting. The second optionThe One Used by the Active Directory Snap-Instells the
snap-in to use the domain controller that is currently focused on and connected to by any AD
snap-ins that are loaded.
For example, because you often launch the Active Directory Users and Computers MMC snap-in
before editing a GPO setting this option opens the Group Policy snap-in against the same domain
controller that is currently in focus for Active Directory Users and Computers. (You can see
which domain controller an AD snap-in is currently connected to by viewing the server name
shown in brackets next to the name of the snap-in in the left-hand pane of the MMC tool.)
The third optionUse Any Available Domain Controllertells the Group Policy snap-in to use
the first domain controller it can find. No particular GPO is preferred. This last option is
obviously the most risky, but its almost the most robust.
If the PDC role-holder was the preferred domain controller for GPO editing and that server was
down, the GP snap-in would fail to load. The Use Any Available Domain Controller option
71

Chapter 3
allows an administrator to always be able to connect to a domain controller and edit the GPO.
You can use this option safely if you have tight control over who is editing GPOs and when. If
one person always edits GPOs in your forest, this option may be acceptable.

Using Security Groups to Filter the Processing of GPOs

As I mentioned earlier, you have several ways of controlling which GPOs are processed by
which computers and users. Of course, you can link GPOs to particular OUs. Any users or
computers that arent members of the OU (or its child OUs) wont process the GPO simply by
virtue of the rules of inheritance. You can also use one of the features discussed above, such as
No Override or blocking policy inheritance, to control GPO processing.
But Win2K also provides a more fine-grained feature for controlling GPO processingnamely,
filtering based on security groups. Security-group filtering leverages the fact that both users and
computers are security principals in AD. Both users and computers can belong to security
groupsbe they local, global, or Universal groups. Thus, security groups provide access to a
variety of resources, including file systems, printers, shares, and so on. It follows that you should
also be able to use security groups to control access to and processing of GPOs. This is indeed
the case.
Figure 3.14 shows the familiar ACL editor dialog box youre presented with when you click the
Security tab in the Properties dialog box on a GPO.

Figure 3.14: Viewing the security on a GPO in the familiar ACL editor dialog box.

As you can see in this figure, the Authenticated Users group has two permissions on this Finance
Desktop Lockdown Policy: Read and Apply Group Policy. As it turns out, these are the same
two permissions that are required to process a GPO. Together, they grant the right to process a
72

Chapter 3
GPO. If you have one but not the other, GPO processing will fail, and the computer or user
trying to read the GPO will receive errors in the computers application event log, indicating
permission problems.
When you create a GPO, the Authenticated Users group is automatically granted these two
permissions on the new GPO. Authenticated Users applies to both computer and user accounts;
this means that by default, all computers and users who are subject to the GPO will process it. Of
the other access control entries (ACEs) listed in the dialog box in Figure 3.14, none of the others
have the Apply Group Policy permission. This means that only the Authenticated Users ACE
controls the processing of this GPO.
It also means that, by default, members of the various built-in administrative groups like Domain
Admins and Enterprise Admins dont process GPOs. This makes sense if you think about it
because many policies might have a tendency to hobble an administrators day-to-day work. Of
course, if an administrator is also part of the Authenticated Users group, he or she would still be
subject to the policy. You might also note that other permissions are listed in the ACL editor
dialog box, such as Full Control, Write, Create All Child Objects, and Delete All Child Objects.
These permissions have to do with delegating the editing of a GPO, and Ill discuss them in more
detail in Chapter 4.
Changing the Default Processing
Knowing this little bit of information, you can begin to see how you can use security groups to
filter the processing of a GPO. The first step to change the default processing of a GPO is to
remove the Authenticated Users ACE. You can do this in the ACL Editor dialog box shown in
Figure 3.14 by highlighting Authenticated Users and clicking Remove.
The next step is to add the user or computer group for which you want to allow policy
processing. For example, suppose this desktop lockdown policy only applies to a subset of users
in the Finance OU who are members of a group called Locked Down Finance Users. Click Add
in the ACL editor dialog box, then browse to the Finance OU where this group is defined. Select
the group and add it to your list of permitted groups. Youll see that it automatically receives the
Read permission on the GPO. You only need to add the Apply Group Policy permission to
complete the filtering of this GPO. Figure 3.15 shows what this will look like.

73

Chapter 3

Figure 3.15: Using security groups to filter the processing of GPOs.

Youll want to use user-based security groups to filter the processing of user-specific portions of
a GPO and computer-based security groups to filter the processing of computer-specific portions
of a GPO. For example, if you have a GPO that only sets computer-specific Administrative
Template policy, adding an ACE that filters the processing of that GPO based on membership in
a user group wont affect processing. This is because what youre really interested in is
controlling which computers process a GPO, not which users. The inverse is true as well, of
course. However, keep in mind that security-group filtering is an all-or-nothing approach for
controlling GPO processing. You cant filter out only certain nodes of functionality in a GPO.
(The exception to this is software installation security, which Ill discuss in Security Settings
later in this chapter.) If you remove the Apply Group Policy permission for a particular group,
the members of that group will no longer be able to process that GPO.
Using the Deny ACE
Another approach you can take is to grant the permission to process a GPO to a wide audience
like Authenticated Users, then add whats called a Deny ACE, which takes away that right from
a particular subset of users or computers. A Deny is a type of ACE that revokes a set of
permissions to an object. As you might expect, a Deny ACE overrules any normal Allow ACEs
that might be defined on an object. So for example, I might have a group in my Finance OU
called Open Users that I dont want to be subject to my desktop lockdown policy. I can add a
Deny ACE to the ACL on my GPO to exclude this group from the processing of the GPO. This
is shown in Figure 3.16.

74

Chapter 3

Figure 3.16: Using a Deny ACE to filter the processing of a GPO.

In this figure, youll see that Ive set the Read and Apply Group Policy permissions to Deny for
the Open Users group, while the Authenticated Users group still has those permissions set to
Allow. This means that all users except those who are members of the Open Users group will
process this GPO.
Treading Carefully
As you can imagine, using security-group filtering to affect GPO processing can get tricky and
complicated very quickly. This is especially true if you begin to use Deny ACEs to control
processing. I recommend not using Deny ACEs unless you really want to exclude a small subset
of users or computers from processing a GPOand only if that group isnt likely to grow. Deny
ACEs make troubleshooting GPO-processing problems very difficult because of the sheer
complexity of managing all the permutations. This is especially true if your users or computers
process many GPOs at logon or startup.
I also recommend going easy on security-group filtering of GPOs to begin with. Even that
approach can be fraught with peril: If youre managing a lot of GPOs, you may start to lose track
of what permissions youve granted to which GPOs.
If you plan to use security-group filtering on your GPOs to any large degree, I highly recommend that
you use a tool that supports RSoP calculations, such as FAZAM 2000 from FullArmor.
(http://www.fullarmor.com). Such tools make troubleshooting these kinds of scenarios simpler by
providing you with information about what the RSoP is for a particular user on a particular computer in
a particular OU.

75

Chapter 3

Using GPO Functionality

In this section, Im going to drill into using some key aspects of GPOs. In particular, the
Administrative Template policy, Software Installation, Folder Redirection, and Security Settings
features warrant further discussion. Each policy section has its own quirks and configuration
options. So its useful to describe how you can use each one in situations that youre likely to
encounter in your own environment.
Administrative Template Policy
Administrative Template policy was born out of NT 4.0 system policy. As discussed in Chapters
1 and 2, Administrative Template policy lets you set HKEY_LOCAL_MACHINE and
HKEY_CURRENT_USER registry values using the familiar .adm template files, which are
stored in the GPT for each GPO. In Chapter 1, I also mentioned the difference between
preferences and policies as well as the benefits that policies provide by their lack of tattooing of
the registry. In this section, Ill walk through setting, and techniques for effectively editing,
Administrative Template policy.
To begin with, lets set up some Administrative Template policy. Im going to open a Group
Policy snap-in focused on my Finance OU, called Finance GPO. Lets suppose Im setting
Administrative Template policy on a per-user basis. Expand User Configuration, Administrative
Templates, as shown in Figure 3.17.

Figure 3.17: Viewing user-based Administrative Template policy.

In this section, Im going to set some common desktop lockdown policies. To do this, I need to
drill down into Windows Components, Windows Explorer. The policies available under this
76

Chapter 3
node include restrictions such as Remove Map Network Drive, Disconnect Network Drive,
and Prevent Access to Drives from My Computer. To set a particular policy, I double-click that
policy item in the right-hand pane of the Group Policy snap-in. All Administrative Template
policy takes a form very similar to that shown in Figure 3.18.

Figure 3.18: Viewing a typical policy setting in Administrative Templates policy.

This dialog box gives me three options for the policyNot Configured, Enabled, and Disabled.
As described in Chapter 1, these settings ignore, set, and de-select this policy item. This dialog
box also contains an Explain tab. This is a new feature in Win2K Administrative Templates, and
it provides a detailed explanation of what a policy setting does. The Explain text, as well as the
registry key and value behind the policy setting, are stored in the .adm file(s) that are part of this
GPOs GPT, as discussed in Chapter 2.
After youve set a number of policy items, theres no easy way to see where all policy has been
set in a GPO. To get around this, Microsoft provides the Show Configured Policies Only
command on the Group Policy snap-in View menu. Choosing this command displays only those
Administrative Template policies that have a value other than Not Configured. This is illustrated
in Figure 3.19, where only policy defined in the Windows Components, Windows Explorer
section has been set on this GPO.

77

Chapter 3

Figure 3.19: Viewing only Administrative Template policy that has been set.

If youve modified or defined your own custom .adm files, you must load them into the GPO
using the Group Policy snap-in tool. Specifically, if you right-click the word Administrative
Templates on either the User or the Computer configuration nodes, then choose Add/Remove
Templates from the context menu, youll be presented with the Add/Remove Templates dialog
box, shown in Figure 3.20.

Figure 3.20: Viewing the Add/Remove Templates dialog box in Administrative Templates policy.

From here, you can add your new or modified .adm file to the GPO. Because .adm files are
stored in individual GPOs, if you want the .adm file to be used across multiple GPOs, youll
need to repeat this loading operation on each GPO. (Or you can make the change on one GPO
that youve designated to hold your .adm changes, then link to it from multiple containers.)

78

Chapter 3
If you click Add in the Add/Remove Templates dialog box shown in Figure 3.20, the familiar
Open dialog box appears, focused on the %systemroot%\inf folder on the computer where the
GP snap-in tool is running. This folder typically contains the default .adm files shipped by
Microsoft in Win2K. (If your .adm file is stored in a different folder, you can, of course, point to
it.)When you select the appropriate .adm file and click Open, the file is automatically copied to
the ADM folder in the GPT defined for that GPO (as described in Chapter 2). The .adm file is
now part of the GPT, and the source file that you copied it from remains separate and
independent.
If you have to make a change to the original .adm file, you need to edit the copy that is now in
the GPT in the ADM folder. Or you must edit your local copy, remove the template file from the
GPO, then add it again using the new version.
While its impossible in the space of this book to define all of the policy items available in the
default .adm files shipped for use by Administrative Template policy, Table 3.1 attempts to
present the major categories of Administrative Template policy and their purposes. This table
includes both policies and preferences, as I defined them in Chapter 1.
Policy

Description

Computer & User Configuration|Windows

Components|NetMeeting

Per-machine and per-user settings for the

NetMeeting conferencing Application. For
example, this policy allows you to disable the
whiteboard or chat features in NetMeeting for
users subject to this policy.

Computer & User Configuration|Windows

Components|Internet Explorer

Per-machine and per-user settings for Internet

Explorer. This policy includes items that let you
lock down IE, such as preventing users from
changing security-zone policy and accessing
certain tabs on the IE Internet Options page. This
policy section provides complementary IE
controls to the Internet Explorer Maintenance
policy node in a GPO.

Computer & User Configuration|Windows

Components|Task Scheduler

Per-machine and per-user settings for the Task

Scheduler. Both computer and user settings are
identical, and they let you control things like
users ability to create scheduled tasks or delete
existing tasks.

Computer & User Configuration|Windows

Components|Windows Installer

Per-machine and per-user settings that let you

control the behavior of the Windows Installer
engine. On the per-machine side, you can set
policy such as enabling Windows Installer logging
or disabling the Installer engine altogether. On
the per-user side, you can control behavior such
as application rollback (when an installation fails)
and whether the Installer engine can escalate a
users privilege level during installation.

User Configuration|Windows
Components|Windows Explorer

Setting a number of Explorer UI locks on a peruser basis only. For example, included in this
policy section are lockdowns such as hiding
particular drives in My Computer and removing
the Map Network Drive and Disconnect Network
Drive options from Explorer.

User Configuration|Windows

On a per-user basis, which MMC snap-ins users

79

Chapter 3

Policy

Description

Components|Microsoft Management Console

can load; also, whether users can enter MMC

Author mode from a pre-defined MMC console
tool.

Computer & User Configuration|System

Per-machine and per-user settings for

miscellaneous system lockdowns. For example,
under the per-machine policy section, you can
disable the CD-ROM autoplay feature and
remove the Welcome screen at logon. Similarly,
on the per-user side, you can disable registryediting tools and specify only a particular list of
applications that a user can run.

Computer Configuration|System|Logon

Controlling behavior at logon, including whether

logon and startup scripts run synchronously; also,
what constitutes a slow network connection for
roaming user profile download behavior.

User Configuration|System|Logon/Logoff

Similar restrictions to the previous per-machine

logon policy. Also adds restrictions that let you
remove certain options from the Start menu, like
Log Off, and certain elements from the Ctrl-AltDel dialog box, such as the Task Manager.

Computer Configuration|System|Disk Quotas

Per-machine policy that lets you set disk quota

behavior, such as whether to enable disk quotas,
whether to enforce them, and how to warn the
user if theyre exceeded.

Computer Configuration|System|DNS Client

Per-machine policy that lets you specify a DNSsuffix search order on machines that are subject
to this GPO. A suffix search order is used if you
have DNS subdomains on your network that you
want to search when trying to resolve unqualified
host names.

Computer & User Configuration|System|Group

Policy

Per-machine and per-user policy that lets you

control the behavior of GPO processing. On a
per-machine basis, this policy lets you specify
whether a particular CSE can process GPOs in
the background (when supported), how
frequently background processing occurs, and
whether to process a GPO if it hasnt changed.
(The default behavior is to not process GPOs that
havent changed.) In addition, per-machine and
per-user settings determine when a slow network
connection is detected and how that affects GPO
processing. In some cases, like Folder
Redirection and Software Installation, those
CSEs dont run when a slow network is detected.

Computer Configuration|System|Windows File

Protection

Per-machine policy that lets you control the

behavior of Windows File Protection (WFP). For
example, you can control how often WFP scans
critical files for changes and how big a cache
should be allocated to store the correct versions
of system files should the current copies get
corrupted.

Computer & User Configuration|Network|Offline

Per-machine and per-user policy that lets you

80

Chapter 3

Policy

Description

Files

control the behavior of the Offline Files and

Folders feature in Win2K. Lets you set policy to
disable use of offline folders altogether, force
synchronization of offline files at logoff, and set
event logging on offline files and folders.
Policies in the User and Computer Configuration
sections in the GPO are duplicated, and in most
cases, the Computer Configuration policy
overrides the User Configuration policy. For more
information about this, see the Explain text for a
policy.

Computer & User Configuration|Network|Network

and Dial-up Connections

Per-machine and per-user policy related to the

Internet Connection Sharing (ICS) feature and to
the use of Remote Access Service (RAS). The
per-machine policy lets you disable ICS for
computers subject to this policy. The per-user
policy lets you control what users can do with
LAN and RAS connections.

Computer Configuration|Printers

Per-machine policy that lets you control how

printer objects are published, browsed, and
located in AD. This policy is used in conjunction
with AD sites and location information on subnets
to let your users locate printers based on the site
they belong to.

User Configuration|Start Menu & Taskbar

Per-user policy that lets you control all aspects of

the Start menu. Included in this policy section
are, among others, settings for removing the
Run, Search, and Help dialog boxes from the
Start menu as well as forcing personalized
menus on or off.

User Configuration|Desktop (includes Active

Desktop and AD policies as well)

Per-user policy that controls the behavior of the

users Desktop and Active Desktop features, if
enabled. The Active Directory folder in this policy
lets you set the behavior of the AD Search dialog
box that can be opened from the Start menu.
Examples of user desktop policy include
removing all icons from the desktop and
removing the My Network Places and Internet
Explorer icons from the desktop.

User Configuration|Control Panel

Per-user policy that lets you hide the Control

Panel, or specific applets in the Control Panel,
from the user.

User Configuration|Control Panel|Add/Remove

Programs

Per-user policy that lets you control the behavior

of the Add/Remove Programs interface, including
the ability to prevent the user from searching
outside your organization for new applications
and updates. You can also hide the Add/Remove
Programs option altogether, effectively disabling
the applet.

User Configuration|Control Panel|Display

Per-user policy that lets you control the options

available in the Display applet (a Control Panel),
including screen saver and background bitmap

81

Chapter 3

Policy

Description
settings. You can also hide the tabs on the
Display applet (for example, Settings,
Background, and so on) to prevent users from
modifying those settings.

User Configuration|Control Panel|Printers

Per-user policy that let you disallow users from

adding printers. This policy also includes a neat
feature that lets you specify a Web site where
users can find lists of available printers on your
network. If you enable this feature, its an option
added to the Add Printer wizard (choose Start,
Settings, Printers).

User Configuration|Control Panel|Regional

Options

Per-user policy that lets you restrict which

languages a user can use.

Table 3.1: Administrative Template policies and their purposes.

As you explore the various Administrative Template policies that ship out of the box, youll
notice that quite a few policies overlap each other. The way to work around this is to carefully
read the text on the Explain tab accompanying each policy item. In a lot of cases, the Explain
text will point out other similar policy and let you know which take priority.
Software Installation
The Software Installation feature in Group Policy is, as I mentioned in Chapter 1, a way of
distributing software by leveraging the Windows Installer engine that comes with Win2K. In this
section, Ill walk through the process for deploying an application using this feature.
To leverage Software Installation your applications need to be packaged using the Windows
Installer packaging format (that is, .msi files). The exception to this rule is that you can publish
applications for individual users to the Add/Remove Programs Control Panel applet using a setup
description file called a .zap file.
A .zap file is a text file that can be referenced by Software Installation to install an application
that doesnt use the .msi packaging format. However, applications published in this manner dont
accrue some of the benefits of .msi packaged applications. For example, you cant install .zap
files using the escalated privilege feature, and they dont provide the life-cycle management
features that the Windows Installer engine provides. Listing 3.2 shows an example of the format
of a .zap file.
[Application]
FriendlyName = ABC App 1.0
SetupCommand = p:\abc_app\setup.exe
DisplayVersion = 1.0
Publisher = ABC Software Inc.
URL=http://abcsoftware.com
[ext]
ABC=
Listing 3.2: Viewing the format of a ZAP file.

82

Chapter 3
In this listing, Ive simply created a text file that lets me call the old-style setup application called
setup.exe for an application called ABC App. In this file, the FriendlyName and SetupCommand
key-value pairs are required fields, but the others arent. The additional information will simply
appear in the application information field in the Add/Remove Programs Control Panel applet
when the application is published. The [ext] tag lets you associate a particular file extension with
this published application.
In this example, if the user double-clicked a file with an .abc extension and the ABC App was
not installed, itd be automatically faulted in and installed on the computer. The Software
Installation feature lets you gain some of the benefits of managed applications without having
to immediately repackage your application using the .msi format. Now that Ive introduced the
exception.zap filesIll talk about using .msi packaged applications to leverage the Software
Installation feature in Group Policy.
For more information about the Windows Installer technology, check out Chapter 3 of The Definitive
Guide to Windows 2000 Administration at http://www.realtimepublishers.com. The site also contains
links to other books that go into more detail about this technology.

Suppose I have a .msi package that I want to assign to users subject to a GPO that Ive defined.
My first step is to make that .msi package accessible to all users who might be installing it. In a
Win2K AD environment, you can accomplish this in a number of ways. For example, you can
put the package on a server share that is universally accessible to all of your users. This might be
a good approach in a small network, but it could become a performance issue if you have
hundreds of users installing the application across a worldwide network.
Alternatively, you can use Win2Ks fault-tolerant Dfs to create a replicated share point across
your AD infrastructure. In this case, the application setup package is placed under a fault-tolerant
Dfs root and replicated across servers on your network that house replicas of that root. This
approach is commonly used in conjunction with the Software Installation feature; the read-only
nature of application setup packages lend themselves well to using Dfs.
For more information about Dfs, read Chapter 5 of The Definitive Guide to Windows 2000
Administration by Sean Daily and Darren Mar-Elia (Realtimepublishers.com). Youll find a link to this
book at http://www.realtimepublishers.com.

Lets assume that Ive created my fault-tolerant Dfs root and have copied my .msi-based
application setup packages to a Dfs folder. Now Im going to walk through the process of
assigning that application to a set of users using GPO-based Software Installation.
The first step is to open the Group Policy MMC snap-in, focused on the GPO youre interested in
editing. Next, drill down into Computer Configuration, Software Settings, Software Installation.
Right-click the Software Installation node, then choose the option on the context menu for
creating a new package. The familiar Open dialog box appears and lets you locate your .msi
package.
Here its important to enter a relative path to your .msi package rather than an absolute one.
Thats because the user processing the GPO needs to be able to find the package anywhere on
your network. So dont use a drive letter designation (for example, d:\apps\mysetup.msi).
Instead, use a relative path, ideally pointing to your Dfs share (such as
\\mycompany.com\dfsroot\appsetups\outlook2000\setup.msi).Once you click Open, the Deploy

83

Chapter 3
Software dialog box opens, where you can choose Published, Assigned, or Advanced Published
or Assigned (see Figure 3.21).

Figure 3.21: Viewing the options available when deploying a new application in Software Installation.

Unless I know that I want to make absolutely no customizations to my package deployment, I

choose Advanced Published or Assigned. Then the Properties dialog box opens, shown in Figure
3.22.

Figure 3.22: Viewing the Advanced Published or Assigned options in Software Installation.

The functionality provided by the six pages in this dialog box is described in Table 3.2.
Page

Description

General

Provides basic overview information about the application name, version, and
publisher.

Deployment

Lets you choose the type of deployment (Published or Assigned), deployment

options, and UI verbosity. Under Deployment Options, if you choose to publish the
84

Chapter 3

Page

Description
application, you can also choose to have it install itself based on any file
extensions that are associated with it. In addition, a check box indicates that if the
GPO no longer applies to the user, you need to uninstall the application.
You also have an option to prevent the application from appearing in the
Add/Remove Programs Control Panel applet. This might be useful if you only
want to assign the application using GPO, without giving the user the option to
install it manually. You can also specify that, when the setup runs, it should show
the user a basic or maximum UI. A basic UI shows minimal progress and
requires no user interaction. If the package is coded to support it, the maximum
UI presents the user with the full setup UI, including prompts that the user must
respond to.
Clicking Advanced on this tab displays the Advanced Deployment Options dialog
box, shown in Figure 3.23. In this page, you can indicate that you want to ignore
whatever language preferences may have been specified during setup. You can
also specify that any instances of this application that were not installed by GPO
should be removed. Note that this feature works only if the product code (shown
in the Advanced Diagnostic Information section) for both the GPO-deployed
application and the non-GPO-deployed application is identical. If it isnt, for
whatever reason, Software Installation will simply install the application on top of
existing installations.
This page also includes some advanced diagnostic information on the package
being deployed, including its product code (derived from the .msi package), a
deployment count (which in my experience doesnt work), and the path in the
GPT to the application assignment script (.aas file) that is generated when the
package is deployed.

Upgrades

This page lets you set up upgrade relationships between the application that
youre deploying and older versions of the application that were previously
deployed using this GPO. Note that when you set up an upgrade relationship
between, for example, ABC application v1.0 and ABC application v2.0, any users
(or computers) that installed v1.0 will automatically receive v2.0. An upgrade
package is different from a setup package in that it assumes that the 1.0 version
has already been installed. Generally speaking, upgrade packages only update
key files and registrations as needed. So if you set up an upgrade relationship
between two versions of an application, its important that the original version of
the application remain available for users who havent yet installed it. In that
case, v1.0 will be installed, then v2.0 will be installed on top of it.
If the new version of your software isnt a true upgrade to the previously
deployed version, the best approach may be to remove the previously installed
version (described below) and then republish or reassign the new version.

Categories

Categories let you define a way of grouping applications that appear in the
Add/Remove Programs Control Panel applet. (They were described in Chapters
1 and 2.) Categories must be defined ahead of time before they can be selected
from this page. To define categories, simply right-click the Software Installation
node in a GPO in your domain. Choose Properties from the context menu, and
youll see the Software Installation Properties dialog box, shown in Figure 3.24.
This dialog box presents some default options for Software Installation. If you
click the Categories tab, you can define new categories, which will then become
visible on the Categories page of your new package installation process.

Modifications

This tab lets you associate Windows Installer package transform files (.mst files)
with a given setup. Transform files are custom modifications that you can
perform on a default .msi setup package. Typical transform operations include
choosing particular features to install in an application, changing the default
installation folder for an application, or having an application install in Run from

85

Chapter 3

Page

Description
Network mode.

Security

Presents the familiar ACL editor interface. The Security tab gives you the ability
to assign permissions on individual applications in a GPO. I mentioned earlier in
this chapter that you can assign permissions on a whole GPO to filter the
processing of that GPO to a particular group of users or computers. Well, you
can actually filter the installation of particular applications by modifying the
permissions shown in this dialog box. For a user or computer to see an
application that has been deployed using GPO, that user or computer must be a
member of a group that has Read permission on the application. By default,
Authenticated Users has Read permission on any application that is deployed
using Software Installation. However, you can remove this ACE (just as we did
above in Using Security Groups to Filter the Processing of GPOs) and grant
Read permissions to subsets of user or machine groups. This gives you a very
fine-grained control over who receives which applications, even in a single GPO.
However, when it comes time to troubleshoot problems, this also increases the
complexity of the GPO by an order of magnitude.

Table 3.2: Software Installation page options and their functions.

Figure 3.23: Viewing the advanced options available on the Deployment page in Software Installation.

86

Chapter 3

Figure 3.24: Viewing the Categories page of the Software Installation Properties dialog box in which you can
create Software Installation categories.

Ive talked about how you can install a new application using Software Installation, but how
about if youre ready to retire an application? Well, its just as easy to remove a previously
installed application. In the GPO snap-in, right-click the application that you want to remove.
Choose All Tasks from the context menu, then choose Remove from the submenu. The Remove
Software dialog box will appear, shown in Figure 3.25.

Figure 3.25: Viewing the options for removing a previously deployed application.

This figure shows two options. Either you can remove the application and have it uninstalled
from all users and computers who received it, or you can simply leave it on the computers of
those users who previously installed it and prevent any future installs. In either case, the
application is no longer listed in the GPO and is no longer available for installation. There is also
a Re-deploy Application command on the All Tasks submenu. This command tells the GPO to
trigger a new installation on any computers or users who are subject to this GPO as though it
were the first time the application was being deployed.
87

Chapter 3
The Re-deploy Application option is useful if youve changed one or two files in an application
setup and dont want to have to repackage it or set up an upgrade relationship between the old
and the new versions. By re-deploying the application, the patched application is re-installed,
and your new files are distributed to all users of the application. This approach is different from
the one used by Windows Installer patch files, which are actually separate file packages with a
specific purpose and relationship to the original .msi file. Folder Redirection
The Folder Redirection feature in Group Policy is an enhanced version of what was available in
NT 4.0 system policy. Keep in mind that Folder Redirection is a user-specific policy onlyit has
no relevance for computers. Also, if the workstation processing a GPO detects a slow network
link, Folder Redirection it isnt processed. Folder Redirection lets you control the following userprofile-based folders:

Application Data

Desktop

My Documents (and My Pictures in My Documents)

Start menu

Folder Redirection supports two types of redirectionbasic and advanced. In basic redirection,
you specify a server share to which you want to redirect the selected user profile folder. Users
who process the GPO are then redirected to that single server share. This approach works best
when youre redirecting parts of the user profile, such as the Start Menu, to read only data that
you want all users to see.
Setting Up Advanced Folder Redirection
The advanced redirection option allows you to specify a different server share, one that is
conditional on the users group membership. Figure 3.26 shows an example of how you might
set up advanced folder redirection.

88

Chapter 3

Figure 3.26: Using Advanced Folder Redirection in a GPO.

As the figure shows, Ive redirected the My Documents folder to two different shares
\\servera\home\finance users\%username% and \\servera\home\accounting users\%username%
based on membership in the Finance Users and Accounting Users groups.
Folder Redirection in Win2K doesnt support using mapped drives or environment variables (other
than %username%) when you specify a path to a server share for redirection. Youll need to use
Uniform Naming Convention (UNC) paths or local drive letters instead. I suspect this issue will be
resolved in future releases of the product because it represents a step backwards in functionality from
NT 4.0 system policy and the Custom Shared Folders feature.

The options available on the Settings page are shown in Figure 3.27.

89

Chapter 3

Figure 3.27: Viewing the Settings options for Folder Redirection.

The Settings page gives you the ability to grant exclusive rights to the folder that is being
redirected. This option is only relevant for My Documents, Application Data, and Desktop
redirection (not Start menu). However, if you use it, be cautious. Its really only meant for
folders that are user-specific. For example, if youre redirecting everyones Desktop folder to a
single server share, you wouldnt want to select this option. This would assign the server share
granting the first user who processed the redirection exclusive rights to the folder. This option
actually changes NTFS file system permissions to enforce the exclusion, so be careful!
The next option tells Folder Redirection that when redirecting a folder for the first time, it should
move any files and subfolders in that folder to the server share that has been specified. This is
generally desirable to do unless youre sure you dont want to bring old content along with your
users. However, if you dont select this option and your users have critical files stored in the user
profile version of their folders, they may not be able to easily retrieve them after redirection
occurs: The folder will be pointing at a server share. You can specify that a folder be left in the
new location or be redirected to the user profile location.. This is an important distinction.
Deleting the GPO or denying the user access to it isnt the same as removing the folder
redirection policy. To remove Folder Redirection, you actually have to undo folder redirection
policy on this GPO. The next time the user processes the GPO, itll behave as you specified.
Namely, itll either leave the folder where it was redirected (for example, a server share) or copy
the contents of the redirected folder back underneath the user profile folder where it belongs.
Take my word for itremoving folder redirection can be complicated. You need to thoroughly
test the process you want to use to undo folder redirection before implementing it, or the
consequences may be very undesirable.

90

Chapter 3
Security Settings
In this section, I want to make you comfortable with setting security policy in GPOs and
knowing what to expect when you do. To start with, as was indicated in Chapter 2, there is a
relationship between the security settings nodes in a GPO and the security templates on the one
hand and the Security Configuration and Analysis MMC snap-ins that come with Win2K on the
other. GPO security settings simply apply the security templates that you create using these other
tools to many computers at a time. GPOs provide the transport, if you will, for enforcing
organization-wide security policy. You can do it in real time by opening a GPO for editing and
setting the options in it manually. Or you can pre-create a security template that contains all the
settings you need, then import that template into a GPO. Its the latter process that I want to
describe here.
About Security Templates
To begin with, all Win2K devices come with a standard set of security templates, usually located
in %systemroot%\security\templates. Figure 3.28 shows an example of these template files.

Figure 3.28: Viewing the security templates that come with Win2K.

91

Chapter 3
These templates are simple text files that use a particular format for specifying each of the
security settings that you see supported in computer-based GPO security (for example, audit
policy, user rights, file system security, and so on). The Security Templates MMC snap-in that
comes with Win2K lets you edit one of these existing template files or create one. In either case,
if you know the syntax, you can edit these files using a tool like Notepad. However, using the
Security Templates MMC tool is easier and safer.
Lets suppose I want to create my own security template. It will set a number of audit policy
settings that I want to import into a GPO. To begin with, Ill load the Security Templates MMC
snap-in. When I open the tool and expand the top-level node, it automatically loads the templates
located on the computer where Im running the tool into the %systemroot%\security\templates
folder.
Creating Security Templates
To create a security template, I simply right click the path listed and select New Template. Im
prompted to supply a name for my template and some descriptive text. Ill call this template
Darrens Audit Policy. Once Ive created the template, if I expand the folders underneath it, I see
settings very similar to what is available in the computer-specific security settings in a GPO.
Figure 3.29 shows an example of this.

Figure 3.29: Creating a custom security template.

As you can see, Ive drilled down to the Local Policies, Audit Policy section of the template and
selected a number of audit policy settings. Once my changes are made, I save the changes to my
template file by right-clicking the template name and choosing Save from the context menu.
(Template files have a .inf extension.)

92

Chapter 3
Importing Security Templates into a GPO
Now all I need to do is import my new template into the GPO where I want to enforce my audit
settings. I open the Group Policy snap-in, focused on the GPO I want to edit, then drill down to
Computer Configuration, Windows Settings, Security Settings. I right-click the Security Settings
node, then choose to Import Policy from the context menu. In the Open dialog box, I select my
new template. Once it loads, if I drill down into the audit policy on that GPO, Ill see my changes
made exactly as specified in the original template file. Figure 3.30 reflects this.

Figure 3.30: Viewing a GPO after importing a security template into the security policy settings.

As soon as I import the new policy template file into the GPO, the security settings become
active, and the next computer to process the GPO will receive those new settings. In addition, if I
make changes to other GPO security settings not specified in the template file, then reload the
original template, the template file will overwrite any changes I made in the GPO itself.
However, using templates as the definitive source for all GPO security settings, you build in a bit
of change control that editing a GPO itself doesnt necessarily provide. You can think of security
templates as the .adm files of GPO security.

Summary
In this chapter, I discussed creating and editing GPOs. I started by talking about how GPOs are
linked to containers and discussed simple editing of policy. Then I moved into a detailed review
93

Chapter 3
of the options available to you when you edit a GPO. From there, I described topics such as
filtering GPO processing using security groups. I then discussed in detail how some of the more
popular features in Group PolicyAdministrative Template Policy, Software Installation, Folder
Redirection, and Security Policycan be used to create useful GPOs.

94

Chapter 4

Chapter 4: Designing and Implementing Group Policy in the

Enterprise
In the first three chapters of this book, I gave you the foundation for creating and managing
GPOs in your AD infrastructure. But to realize the benefits of GPOsbenefits such as reducing
the costs of managing a Win2K infrastructure, you need to be able to apply what youve learned
so far to a real-world environment. My goal in this chapter is to build on the previous chapters by
giving you practical advice for deploying GPOs in a large-scale Win2K infrastructure. Indeed,
the capabilities and complexity of GPOs dont become evident until you begin to design and
deploy group policy in a real-world situation.
The challenges of designing a GPO implementation correctly have resulted in a relatively slow
rate of deployment in the enterprise. If you look at most large enterprises that have deployed
Win2K, a small percentage have made the jump to an AD implementation, and an even smaller
percentage have committed to a robust deployment of GPOs.
In this chapter, Ill describe my experiences in designing such a deployment and provide best
practices for deploying this powerful technology. The exciting thing about GPOs is that they
have the potential to give you unprecedented control over your Windows infrastructure. The
challenge is that they require a lot of careful planning and even more careful management to
fulfill this promise.

Integrating Group Policy Design in Your AD Infrastructure

The first step in deploying group policy is planning a design that works with your AD
infrastructure. In fact, I recommend having a good idea about how you want to use GPOs during
your AD planning process. If you think about how GPOs are structured and the fact that theyre
linked to sites, domains, and OUs, you can see why a particular AD design might make it more
or less difficult to deploy a viable GPO design. As I discussed in Chapter 3 of this book, the goal
of your AD design is to meet your business needs as well as those of your technology.
For example, if your company is organized into divisions (Engineering, Finance, Sales, and so
on), you might be inclined to create an OU design that mimics that structure. However, if you
also plan to use GPOs to manage the resources in the company, think about how a GPO
implementation might map into such a structure. And, perhaps just as important, wholl manage
the GPOs that you design, and how much latitude will you grant them to make changes or create
new ones?
In fact, this last point often goes to the very heart of integrating a GPO design with an AD
design. Remember that AD provides very granular delegation for administering objects. Your
Engineering OU might be managed centrally by your corporate system administrators, or
management might be delegated to someone in the Engineering division who is responsible for
just those objects. In either case, youll need to think about where youll link GPOs and wholl
manage them.
Remember that GPOs are inherited. So if you link one GPO at the domain level and another at
the Engineering OU level, both GPOs can affect the users and computers in that Engineering
OU. And, as I discussed in earlier chapters, you can filter the effects of policy using security
groups. Thus, you might be trying to decide whether to link most of your GPOs at the domain
95

Chapter 4
level, letting security-group filtering control where they apply, or to link more selectively at the
OU level for a given set of users and computers.
To complicate matters even more, GPOs are monolithic. That is, a particular GPO, by default,
can contain policy for everything from security to IE lockdown to Administrative Template
lockdown. You can work around this to some degree by not allowing certain GPO administrators
to load certain MMC snap-ins related to Group Policy. (See Scenario BMultiple AD
Domains later in this chapter.) But in the end, you may opt to create many GPOs, each of which
provides single (or few) policy functions as opposed to fewer GPOs that do everything. Lastly,
any GPO design needs to take GPO processing performance into consideration. A situation in
which a computer or user has to process tens or hundreds of GPOs that may be housed in more
than one domain might result in an unacceptable user experience.
By now, youre probably asking yourself why in the world anyone would deploy GPOs and how
anyone can reap the expected benefits from them in the face of this complexity. I know Ive
asked this question myself on several occasions! Let me assure you that you can design and
deploy a GPO implementation that maximizes the incredible control this feature provides while
minimizing the management complexity of the resulting infrastructure.
What Ive talked about so far in this chapter can be distilled into the following five questions,
which you need to consider as youre designing your GPO implementation:
1. Does your AD design take into consideration how youll use GPOs?
2. What GPO functionality do you want to use in your environment?
3. Will you create and manage AD objects (and thus GPOs) from a central group in your

organization, or will management be delegated across many business units? (Its possible
and perfectly reasonable that GPO delegation wont match your planned delegation of
AD objects.)
4. Will you create GPOs and link them right to the container where they apply (say, at an

OU)? Or will you link them at a higher level (such as at the domain level) and use
security-group filtering to control their effect?
5. How will you manage aspects of GPO administration such as change control, Resultant

Set of Policy (RSoP), and GPO processing performance, and will the GPO delegation
design youve created allow such management?
My goal for the rest of this chapter is to help you answer these questions and to discuss some of
the technical issues you might encounter as you design your own GPO deployment.

Managing the Complexity of GPOs

Anyone who has designed infrastructure deployments of NT or Win2K knows that Microsoft
imposesalbeit unknowinglya perpetual trade-off. On the one hand, you can reap the benefit
of the lowered cost of ownership of advanced technologies like AD and GPOs, but you run the
risk of negating that benefit by trying to manage their complexity. The reality for most
enterprises is that theyre generally not in the business of running a Windows infrastructure.
Theyre in the business of running a business, and the Windows infrastructure is a tool to get that
core job done. So, whenever you can use technology as an aid rather than a hindrance, life is
good.
96

Chapter 4
GPOs fall squarely into this category. Use them incorrectly, and theyll cost you a lot more
money than they save. Use them well, and youre a hero, and you can truly claim that youre
taking full advantage of the infrastructure and saving your company money. Ive found that the
best way to take full advantage of any complex technology is to use that technology in baby
steps. Unless youre completely comfortable with all aspects of your Win2K infrastructure and
its management, theres no reason to deploy all of the features of GPOs all at once. Start small
and start simple!
Your initial GPO design should seek to do very little. As I pointed out in chapters 1 and 2, the
minimum youll need to do is use GPOs to set security policy on your domain. If youve been
using system policies in NT 4.0, you might decide to duplicate that desktop lockdown
functionality using Administrative Template policy within a GPO or two. If youre using the
IEAK to lock down your users IE configurations, you might add some IE Maintenance policies
to your GPO. As I said, the idea is to start with aspects of GPOs that youre familiar with.
When youre deciding where to link the GPOs, againstart simple by linking them to the
domain and having them apply to all users and computers. If you dont want a policy setting
applying to everyone in a particular domain, link it to an OU, but dont go overboard. Finally,
when you begin to deploy your GPO implementation, dont immediately delegate control of the
GPOs to every administrator on your network. Keep them centrally managed by a group of folks
who are familiar with the technology. This gives you time to refine your GPO change control,
management, and deployment processes before rolling out a larger deployment.
The following points summarize these keep-it-simple tips for your initial GPO deployment:

Start with features in GPOs that youre already familiar with from NT 4.0 (for example,
Administrative Templates and IE Maintenance).

Initially, link GPOs to a few containers (such as domain or OU) to get a feel for
managing and controlling them.

Only deploy a couple of GPOs to begin with. Dont go all out and deploy dozens of
GPOs at all levels of your AD infrastructure.

Maintain centralized control and management of GPOs during their initial deployment
phases until you understand GPO delegation and can put good change-control processes
in place.

Once youve mastered the complexity of GPOs, you can experiment with more complex
implementations or a larger number of GPOs. In the next section, Ill present some approaches to
GPO deployment that you can use in your own AD infrastructure.

Designing the Implementation

How does one go about actually designing a GPO implementation? Earlier in this chapter (see
Integrating the Design into Your AD Infrastructure), I presented five questions that you need
to ask yourself as youre designing your implementation. Now Ill present two scenarios based
on different possible answers to those questions. Scenario A describes a fairly simple, singledomain implementation of GPOs, showing how to migrate from NT 4.0 system policies to a
GPO environment. Scenario B is more complex; it considers multiple AD domains and the
various ways you can design and deploy GPOs in such an environment.

97

Chapter 4
Scenario AOne AD Domain
In this scenario, Company A is deploying a single AD domain, migrating from its current NT 4.0
infrastructure, and wants to start using GPOs slowly. Table 4.1 shows how Company A answers
the five questions I presented earlier in this chapter (see Integrating the Design into Your AD
Infrastructure).
Question

Answer

Does your AD design take into consideration

how youll use GPOs?

We designed our AD to meet our business goals. We

didnt really take GPOs into consideration.

What GPO functionality do you want to use in

your environment?

We know we want to use desktop lockdown

(Administrative Templates) and Folder Redirection,
but were not sure about other features. We want to
be able to seamlessly migrate our NT 4.0 system
policy lockdown to Administrative Templates.

Will you create and manage AD objects (and

thus GPOs) from a central group within your
organization, or will management be delegated
across many business units?

We only have one central IT group for support, so itll

handle all AD and GPO administration centrally.

Will you create GPOs and link them right to the

container where they apply (say, at an OU)? Or
will you link them at a higher level (such as at
the domain level) and use security-group
filtering to control their effect?

We want to avoid too much complexity, but we need

total control of GPO management.

How will you manage aspects of GPO

administration such as change control, RSoP,
and GPO processing performance, and will the
GPO delegation design youve created allow
such management?

We havent thought about any of these aspects, but

we want to avoid them if possible.

Table 4.1: Company As answers to the five GPO design questions.

Given the answers shown in Table 4.1, what is the best GPO design for Company A? Of course,
there are probably a couple of answers to this question, but lets start by looking at its AD
design. Figure 4.1 shows what Company As AD infrastructure will look like.

98

Chapter 4

Figure 4.1: Company As AD namespace.

As you can see in this figure, Company As AD domain is called companya.com. It contains
three top-level OUs: WesternRegion, CentralRegion, and EasternRegion, and within each of
these top-level OUs are two OUs called Sales and Finance. User and machine accounts reside in
each Sales and Finance OU under each region. Each regional OU structure is physically located
in a different part of the country, and thus each region is in a different AD site from the other.
Company A wants to take advantage of the Administrative Templates and Folder Redirection
features of GPOs. In fact, it relied heavily on system policy in its NT 4.0 environment to lock
down the desktops of its users based on their membership in a user group. Company A
differentiated desktop lockdown in system policy among the following six user groups:

WesternSales

WesternFinance

CentralSales

CentralFinance

EasternSales

EasternFinance

The ntconfig.pol file used in Company As NT 4.0 environment is shown in Figure 4.2 below.

99

Chapter 4

Figure 4.2: Company As NT 4.0 system policy file.

In NT 4.0 system policy, a single policy file could apply different desktop-lockdown settings to
different user groups. Unfortunately, in Win2K Group Policy, each GPO only holds a single set
of Administrative Template settings. Company A can filter the effects of a particular GPO to
only apply to a particular user group, but to gain the same lockdown functionality that its
ntconfig.pol file provided, the company may need to build a single GPO for each user group that
it wants to apply policy to. This means six GPOs in Win2K compared to one NT system policy
file in NT 4.0. This may sound less than ideal, but there are steps the company can take to
mitigate the disadvantages of this approach, and Ill present them shortly.
Now lets look at what Company A needs to implement Folder Redirection. Remember that there
are two types of Folder Redirection in Group Policybasic and advanced. In basic redirection,
all users who are subject to the GPO containing the policy have the prescribed folder redirected
to a single destination (for example, \\server\share\%usename%). In advanced redirection, you
can redirect the folder to different destinations (such as different servers or shares) based on
group membership.
Company A would like to redirect the My Documents folder to servers local to each user group.
Given that requirement, it can actually choose one of three GPO designs. It can create:

A single GPO, linked to the company.com domain, that uses advanced redirection based
on user groups defined in each OU where users are to be redirected (for example,
WesternRegion\Sales, EasternRegion\Finance, and so on).

Three GPOs linked to each regional OU (Western, Central, and Eastern), then use basic
redirection to redirect users within each regional OU structure.

Six GPOs, each of which is linked to each of the regional Sales and Finance OUsagain
using basic redirection. This design gives administrators the ability to redirect each OU to
a different location without using advanced redirection.

100

Chapter 4
In the new AD structure, instead of having user groups to differentiate users, Company A can
segregate its users into the various OUs. This is a very common trade-off as youre designing
and deploying both AD and GPOs. It also brings up a key pointnamely, groups and OUs
perform complementary and overlapping functions. You can segregate users (and computers) by
placing them in OUs or by placing them in groups (in which case they may span multiple OUs).
OUs are a more logical place to segregate resources because they dont require explicit
maintenance. That is, when you create a new user in an OU, all of the GPOs linked to that OU
(and inherited by the OU) are automatically applied. However, if you use security groups to
segregate users or computers and filter the effects of GPOs, your administrators need to
remember, each time a new user is added, to place the user in the correct groups. In either case,
this trade-off will affect how complex your GPO design needs to be and how complex your AD
delegation model is.
There is an inherent trade-off in AD between using OUs to segregate users and computers and using
security groups. In some cases, one or the other may better meet your needs, but for the sake of
simplicity, always organize users and computers in OUs rather than security groups.

Two Implementation Options

With this background information, lets look at a couple of possible GPO implementations that
will meet Company As needs. Figure 4.3 shows the first option.

Figure 4.3: A possible GPO implementation for Company A.

101

Chapter 4
Figure 4.3 shows a total of seven GPOs (shown in dark blue) defined in Company As AD
domain. The first GPO, called Domain Folder Redirection GPO, is linked to the domain level
and uses advanced redirection based on user groups defined in each of the regional Sales and
Finance OUs below it. Of course, I could have linked this GPO lower in the AD hierarchyat
the OU level, for example. To do that, however, Id have needed three GPOs (one each for the
Western, Central, and Eastern regional OUs) to accomplish the same task as one, and Id still
have needed to use advanced redirection to redirect each Sales and Finance OU to a different
location.
Now lets look at the six other GPOs in Figure 4.3. Because my requirements were to emulate
the desktop-lockdown functionality in Company As NT 4.0 environment, I had no choice but to
create a separate GPO for each OU where the user accounts reside. If Id placed three GPOs at
the regional OU levels, I wouldnt have been able to differentiate Administrative Template
policy for the two OUs (Sales and Finance) in this regional OU. Thus, Im forced to create six
nearly identical GPOs and link them to each OU where I want to set Administrative Template
policy. Fortunately, each user or computer in the Sales and Finance OUs only has to process, at
most, two GPOsthe domain-linked Folder Redirection GPO and the OU-linked Administrative
Template GPOs.
As with many things, there is no one correct answer. Figure 4.4 shows another option that will
meet Company As needs.

Figure 4.4: A second possible GPO deployment for Company A.

102

Chapter 4
Lets suppose that Company As administrators looked at the GPO design in Figure 4.3 and
thought that there were too many GPOs to administer. In that figure, each GPO only did one
thingeither Folder Redirection or Administrative Template lockdown. With only a slight
change in requirements, Figure 4.4 reduces the number of GPOs required and presents a more
reasonable management picture. What has changed?
In Figure 4.4, the Domain Folder Redirection GPO gained some functionalitynamely,
Administrative Template lockdown. On taking a closer look at the lockdown that Company A
required, I saw that 90 percent of the policies were identical among all of the OUs subject to that
policy. So I applied that 90 percent to the domain-linked GPOthus applying that lockdown to
all users. For those users and computers that required a slightly different lockdown, I created the
requisite GPOs and linked them to the OUs in question. Only Western Sales, Central Finance,
and Eastern Sales required a different lockdown from the domain-based policy.
Of course, if each OU really requires some differentiated lockdown, Figure 4.3 is probably my
better option. The point in Figure 4.4 is that by making some compromises and combining
multiple functionality in a single GPO, I was able to reduce the number of GPOs that I needed to
manage by three.
Both of the solutions that Ive presented for Company A are possible because its centrally
managed and has total control over creating and managing its GPOs. Life gets more complicated
in Scenario B below, as I present a company with more complexity and a more distributed
administrative environment.
Scenario BMultiple AD Domains
In this scenario, Ive created a large multinational corporation called ABC Corp., which wants to
implement a multi-domain AD forest. Table 4.2 shows the responses for this scenario to the five
questions listed in Integrating the Design into Your AD Infrastructure earlier in this chapter.
Question

Answer

Does your AD design take into consideration

how youll use GPOs?

GPO usage was a key part of how the AD namespace

was designed.

What GPO functionality do you want to use in

your environment?

Most GPO functionality will be required, especially

Folder Redirection, Administrative Template policy, IE
Maintenance, and Software Installation.

Will you create and manage AD objects (and

thus GPOs) from a central group within your
organization, or will management be delegated
across many business units?

Creating GPOs will be handled centrally, as will linking

GPOs to domain and sites. Special GPOs, such as
those for domain-wide security, will also be managed
centrally. However, the task of linking GPOs to
particular OUs will be distributed to regional AD
administrators. Administrative Templatebased policy
will be used to restrict which administrators can load
which GPO snap-in extensions.

Will you create GPOs and link them right to the

container where they apply (say, at an OU)? Or
will you link them at a higher level (such as at
the domain level) and use security-group
filtering to control their effect?

GPOs will be linked to the container closest to the

users or computers where theyre applied. GPO
security-group filtering will be used, but only sparingly.

How will you manage aspects of GPO

administration such as change control, RSoP,
and GPO processing performance, and will the

All GPOs will be version-controlled using their display

name. RSoP tools will be used to test policy changes
and determine the impact on users or computers
103

Chapter 4

Question

Answer

GPO delegation design youve created allow

such management?

before deployment. To maximize processing

performance of GPOs, no user or computer will be
subjected to more than ten GPOs.

Table 4.2: ABC Corp.s answers to the five GPO design questions.

Table 4.2 gives us a lot to talk about. Lets start by looking at the AD namespace for ABC Corp.,
as shown in Figure 4.5.

Figure 4.5: ABC Corp.s AD namespace.

As you can see, theres a lot going on in ABC Corp.s AD infrastructure. First, the forest
contains three domainsabccorp.com is the forest root domain, and us.abccorp.com and
europe.abccorp.com are children of the root domain. In the forest root domain, one OU is
defined, called ITAdmins, where the forest administrators user accounts are stored. Each of the
two child domains contains a number of OUs of differing structure. In the US child domain,
there are three top-level OUs called Mfg, Sales&Mktg, and HQ. Under Sales&Mktg are two
OUs called Western and Eastern because the Sales and Marketing division is divided into two
regions. Under the HQ OU are two sub-OUs called IT and Finance. They hold users and
computers in the IT and Finance departments at ABC Corp.
104

Chapter 4
Now, if we shift over to the Europe domain, we see a different OU organization. The three toplevel OUs are organized by countryFrance, UK, and Italy. Under each of these top-level OUs
are two OUsSales&Mktg and Engineering. As you can see, this AD forest appears to have no
consistent approach to how OUs are built and organized. In the US domain, top-level OUs are a
combination of department and location, whereas in Europe, the three top-level domains define
countries, and departments are housed in the sub-OUs under each country.
This seeming mix of organization has a rationale. The OUs are organized according to the
various IT support organizations in the company. For example, in the US domain, the
Sales&Mktg OU is administered by a separate group of administrators from the one that
administers the HQ OU. By organizing OUs according to their administrative authority, its
easier to delegate administration of AD (and GPO) management cleanly along OU lines. In
Europe, one support organization is responsible for each of the top-level OU hierarchies. As
youll see later in this section, this lends the GPO design a degree of simplicity thats required
for these users and computers.
Now youre probably thinking, I thought this was a chapter on GPO design, not AD design.
My goal in describing this AD design in detail was to show that the AD and GPO designs are
linked and one cannot be discussed without the other. Now Ill discuss GPOs for ABC Corp.
As Table 4.2 pointed out, ABC Corp. wants to use several features of GPOs. It also wants GPOs
to be created centrally but wants to be able to delegate the linking of some GPOs to OU
administrators. Given the complexity of its AD namespace, this company wants to minimize the
use of security filtering of GPOs by linking them close to the users and computers that theyre
intended for.
By close, I mean that if the company creates a GPO to lock down the desktop of the
HQ\Finance users in the US domain, it wants to link that GPO to the Finance OU under HQ.
Otherwise, if the company links the GPO higher in the AD treeperhaps at the domain levelit
has to use security groups to ensure that the lockdown policy defined in that GPO is only
processed by an HQ\Finance user group. This is another example of the trade-off between using
OUs or using security groups to segregate usersin this case, for the purpose of filtering Group
Policy.
Two Implementation Options
Figures 4.6a and 4.6b show two GPO design options for ABC Corp.

105

Chapter 4

Figure 4.6a: In the first design option, the US subdomain is part of the GPO design.

106

Chapter 4

Figure 4.6b: In the second design option, the Europe subdomain is part of the GPO design.

There is a lot going on in the figures above, so lets walk through them. The colors of each set of
GPOs represent the administrative group that is responsible for managing them. All GPOs were
initially created by the forest administrators (represented by dark blue). These forest
administrators also manage the domain security policy linked on each domain in the forest. Each
domain has its own security policy. I could have easily created a single security GPO in the
forest root domain (abccorp.com) and linked to it from each of the two child domains, but
because abccorp.com has different security requirements from the US and Europe, I would have
had to create three GPOs.
In the US domain (Figure 4.6a), three GPOs (light blue, green, and dark red) are linked to each
of the three top-level domains. This indicates that a different IT administrative group maintains
each GPO. However, the same set of GPO functionality is defined in each GPOnamely, Folder
Redirection, Administrative Template policy, Software Installation, and IE Maintenance. There
may be subtle differences among the GPOs, but the important thing to remember is that a
different group manages each one.
Of course, the approach Ive shown in Figure 4.6a assumes that each sub-OU under the top-level
OUs needs the same policy settings as its neighbor. This may not be the case, and if so, the
administrators of this domain may need to create additional GPOs, linked to either the top-level
OUs (with security-group filtering to control who gets what policy) or the lower-level OUs
(where the users and computers physically reside).

107

Chapter 4
In the Europe domain (Figure 4.6b), the GPOs are red and have the same name. Theyre the
same color because only one IT group administers this domain. In addition, because the GPO
needs of each top-level OU and its subordinate sub-OUs are identical, only one GPO is actually
defined (hence the same name for each), and it has then been linked to by each of the three toplevel OUs. Of course, this is generally the exception rather than the rule. Its very likely that the
needs of any country will differ at least slightly from those of the other two. However, the
concept of linking to a single GPO from multiple OUs is a common one, and I wanted to
represent it here.
Handling Delegation Requirements
As was the case with Company A, there are probably a few variations to Figures 4.6a and 4.6b
that would meet the needs of ABC Corp. But from a GPO delegation perspective, ABC Corp.
has different requirements than Company A. As I mentioned in Table 4.2 above, the forest
administrators wanted to be able to create all of the GPOs in the forest but leave the task of
linking and managing OU-based GPOs to regional or departmental administrators. (Remember
from Chapter 3 that you can create a GPO without linking it to a container.)
Its important to know how your AD design will lend itself to these delegation requirements. (Ill
discuss the challenges of GPO delegation in greater detail in Chapter 5.) In the meantime, keep
in mind that the ability to link and un-link a GPO from an OU or domain (or site) is granted by a
right on the particular container (either site, OU, or domain), while the ability to edit that GPO is
granted by modifying permissions on the GPO (actually, on the Group Policy Container, or
GPC) itself using the Security page of that GPO (see Figure 4.7).

Figure 4.7: The security properties that control delegation of administration on a GPO.

108

Chapter 4
To see the Security page, right click the GPO name in the Group Policy MMC snap-in, then
choose Properties from the context menu. In the Properties dialog box, click the Security tab. (I
described this dialog box in Using Security Groups to Filter the Processing of GPOs in
Chapter 3.) To control who processes a policy, you simply need to grant the Read and Apply
Group Policy rights to that user, machine, or group. To control who can edit a policy, you need
to grant other rights to that policy (such as Read, Write, Create All Child Objects, and Delete All
Child Objects). In the case of ABC Corp., if Im interested in granting editing rights to the HQ
GPO for HQ administrators, Id modify the security permissions on that GPO to grant a group
that includes the HQ admins the rights to modify that GPO. Ill talk more about GPO delegation
later in this chapter (see Managing Change Control).
Multi-domain Considerations
Scenario B is different from Scenario A in one important wayit includes multiple AD
domains. From a GPO perspective, multiple domains are important because they give
administrators the opportunity to link to a GPO that is stored in a domain other than their own.
This is, of course, perfectly legitimate. As I mentioned above, ABC Corp. could have created a
single GPO in the forest root domain to set security policy, then linked each of the two child
domains to that GPO.
However, there are a couple of reasons why you should seek to minimize the amount of crossdomain linking of GPOs that you use.

Whenever a user or computer must traverse domain boundaries to resolve the GPC and
GPT of a remote GPO, a certain amount of extra overhead occurs as that user or
computer traverses the associated trust relationships, passing its credentials from one
domain to the next. This slows down the processing of a GPO that is remotely linked.

Linking across domain boundaries introduces complexity into your GPO design and
makes it harder to troubleshoot problems should they arise. Because the domain is
remote, the administrator linking to the GPO may not know anything about its
managementfor example, whether its currently functional, in the process of being
changed, and so on.

Site-Linked GPOs
I havent spent any time yet discussing linking GPOs to AD sites. As you know, sites are AD
objects that help control directory replication among domain controllers. You, as the
administrator, define AD sites and the IP subnets that belong to each site. Then you define site
links to connect sites together to form an AD replication topology. You can link GPOs to sites
just as you link them to domains or OUs. When a GPO is linked to a site, all users and computers
that reside in that site are subject to that GPO. You link GPOs to sites using the AD Sites and
Services MMC snap-in (see Figure 4.8).

109

Chapter 4

Figure 4.8:Using the AD Sites and Services MMC snap-in to link GPOs to sites.

In this figure, the SanFrancisco site contains the subnet object 192.168.1.0. If you right-click this
site object, then choose Properties from the context menu, the Properties dialog box appears.
When you click the Group Policy tab, you can create a new GPO that is linked to this site or add
a link to an existing GPO defined elsewhere.
The important question for this chapter is: Why would anyone use site-linked GPOs? Indeed,
Ive found very few circumstances where GPOs linked to a site are actually valuable. Remember
that sites can span multiple AD domains, so you can have devices from multiple domains in a
particular site. However, GPOs themselves are stored in a single domain. This means that if you
define a site-based GPO that is stored in abccorp.com, for example, it can be processed by a
computer or user residing in a different domain in the same site. As I discussed in Multi-domain
Considerations above, whenever GPO processing has to cross domain boundaries, youre likely
to get some degradation of performance.
Aside from that, however, you may find it difficult, as I have, to justify why a GPO would need
to be linked to a site as opposed to a domain or OU. Because sites are really just collections of
subnets, you can think of site-linked GPOs as a way of providing Group Policy based on where
on your network a particular machine resides. One valuable use of such policy might be the
machine-specific IPSec policy I described in Chapter 1. You might want to set policy to specify
that any machine that is on your corporate network, on a particular set of IP subnets, must use
IPSec to communicate with other computers. Similarly, you might have a number of mobile
users who always dial into your network on a well-known IP subnet, and you might want to
provide them with some specific mobile policy that applies only to them when theyre dialing in.
Unfortunately, there are a couple of challenges to site-linked GPOs. First, because in the Site,
Domain, Organizational Unit (SDOU) order of precedence, site-linked GPOs are processed first,
they can be easily overwritten by GPOs linked to domains or OUs, which are processed later.

110

Chapter 4
This means that for any policy you set in a site-linked GPO to stand, it needs to be unique (that
is, only defined there) for all machines and users processing it.
Second, because its more likely that machines will change their IP subnet (for example, when
they move or are mobile), you need to ensure that as machines move from site to site, the GPOs
that are applied to them provide a consistent and expected experience. For example, in certain
sites, a GPO linked there might lock down aspects of your users desktops that theyre not used
to. You almost need to think in advance about how a machine or user will be affected as it moves
around before you can define effective site-linked policy.
Given these caveats, however, site-linked policy can be a powerful tool in situations where
proximity on your corporate network is a significant enough factor to determine which policy
applies.
Adopting GPO Naming Conventions
Another aspect to consider as youre designing your GPO implementation is the naming
convention for your GPOs. As you saw in Chapter 2, GPOs are uniquely identified in AD by
their GUID. However, every GPO has a display name, or friendly name, that you see when
youre opening one for viewing or editing with a tool like the Active Directory Users and
Computers MMC snap-in. Its this name that were interested in when we talk about GPO
naming.
Just as with other objects in your AD infrastructure, its important to come up with a good,
standardized naming convention for GPO display names. The trick is that the convention must
take into consideration that, while the display name is stored with the GPO itself, GPOs can be
linked to any number of containers in your AD. For example, if you name your GPOs using a
convention that includes the name of the container to which theyre originally linked (such as
Finance OU Lockdown Policy), then link that GPO to other containers, your convention may fall
apart.
For that reason, I recommend coming up with a container-neutral naming convention. This
means that in Scenario B above, for example, instead of naming my GPOs after the containers
they were linked to, I should have given them names that are less container-specific. For
example, instead of having an HQ GPO, a better name would be something like FR,SI,AT,IE #1
GPO. This code, if you will, simply lists the functions in the GPO that Im using (FR=Folder
Redirection, SI=Software Installation, AT=Administrative Templates, and so on). The #1
indicates that there may be more of this kind of GPO, such as #2, #3, and so on.
The key here is to keep the names as generic, but as descriptive, as possible. Of course, if you
dont plan to link GPOs from all over your AD infrastructure, its perfectly reasonable to give a
GPO a location-specific name (such as Europe Lockdown GPO). Remember that the display
name for a GPO can be changed to your hearts content because its the GPOs GUID that really
matters to AD.
Another tip you might want to consider is including some kind of version information in a
GPOs name. As you know from Chapter 2, GPCs and GPTs keep their own version-control
information to ensure that theyre synchronized across your AD infrastructure. To maintain
change control over GPOs, you can include version numbers in your naming convention to
ensure that administrators who are linking to a particular policy know that theyre linking to the
correct version. Figure 4.9 shows GPOs that use version numbers in their names.

111

Chapter 4

Figure 4.9: Using version numbers in GPO display names.

As you can see in this figure, the names of the three GPOs contain version information, which
tells administrators what theyre dealing with. Each time a GPO is edited, the person who makes
the change needs to change the GPOs display name to increment its version number. In
addition, the names of the GPOs themselves describe the functions that they perform (for
example, Admin Template, Software Installation, and Audit policy). Of course, you can always
use the revision information displayed on the General page on the GPO (see Figure 4.10) to keep
version-control information.

112

Chapter 4

Figure 4.10: Displaying revision information in a GPO.

The bottom line is that you need to devise a naming convention that you apply consistently to all
GPOs and maintain as they change.
Maintaining Change Control
And speaking of changechange control is another issue that youll have to face in a GPO
implementation, especially in large AD infrastructures. Unlike normal software-release or
configuration-management processes, there are no built-in mechanisms for decent change control
of GPOs. You need a way of knowing who did what to which GPO and when they did it.
You can use AD and file-system auditing on SYSVOL to determine at least part of this
information, but this entails wading through security logs on potentially multiple domain
controllers to figure out what happened. Also, as I mentioned earlier in this book, the GPO
editing tools dont provide any staging of GPO changes; you can only test your changes in a nonproduction AD infrastructure. Once you click Apply or OK to a change, its committed and starts
to replicate to all domain controllers.
In Chapter 3, I talked about a technique for creating GPOs without linking them to a container.
You can use this no-link approach to phase new GPOs into production. This is a good approach
for ensuring a phased implementation of new GPOs, but it isnt useful for existing GPOs. When
you have to change an existing GPO, you have few choices to ensure that it doesnt adversely
affect your production users.
The first and most obvious step to take is to have a test AD forest available in your environment.
This test forest would mimic some or all of your production forest and would provide you with

113

Chapter 4
an environment for trying out the effects of new GPO changes. Once a GPO change is validated
in the test forest, you can apply it to your production environment with relative safety.
Another technique you can use when making multiple changes to GPOs in a large AD
infrastructure is to first disable a GPO that you plan to change. Remember that in Chapter 3, I
described how you can disable a GPO to prevent it from being processed. Figure 4.11 shows the
dialog box under GPO Options where you can disable a GPO.

Figure 4.11: Disabling a GPO while editing.

If youre making multiple changes to a GPO, you dont want users to be processing itand
getting unexpected results. Disabling the GPO before editing ensures that no user is processing it
while youre making changes.
Disabling a GPO doesnt remove the policy that was previously applied to it. It simply tells the
computer or user subject to it that its not available during the current processing cycle. Once you
complete your changes, enable the GPO using the dialog box in Figure 4.11, and during the next
processing cycle, your users and computers will receive the updated policy.

GPO change-control issues become more challenging if youve delegated administration of

GPOs across your infrastructure. You need to make sure that all of your administrators are aware
of the implications of editing GPOs. This is especially true when GPOs are linked to from
multiple containers.
My recommendation is to only delegate administration of GPOs that arent linked to from
multiple containers. For example, if an OU administrator wants to maintain his or her own GPO,
make sure that that GPO is only used in that OU structure and isnt linked to by other OU
administrators. If you need to use GPOs that are linked to from multiple containers, ensure
change-control consistency by keeping them controlled by a centrally managed group. Despite
ADs strong handling of delegated administration, GPOs are one of those aspects of the
technology that may better be delegated slowly and in a limited way.
Tying It All Together
Ive presented two GPO design scenarios, and Ive raised issues about the related challenges of
designing and managing a GPO implementation. Now I want to tie all this together in a few
general guidelines for creating a good GPO design. The following list summarizes the points Ive
discussed in this section:
1. Minimize the complexity of your initial GPO design until youre comfortable with the

technology.
114

Chapter 4
2. When you need to manage one policy separately from the others, consider creating

single-function GPOs (for example, just security or just Administrative Templates).

3. If youre working in a multi-domain AD environment, for performance and

troubleshooting reasons, minimize cross-domain linking of GPOs.

4. Minimize the number of GPOs that need to be processed by a user or computer. Use

some of the techniques described earlier in this booksuch as disabling computer- or

user-configuration policy for GPOs that dont use it to speed up the processing of existing
GPOs. Less than ten GPOs is a nice round number to aim for. If you need more GPOs,
make sure that only those GPOs that absolutely have to be processed by a user or
computer are indeed processed, limiting others using techniques like disabling user or
computer configuration or security-group filtering.
5. Always try to link GPOs as close to their intended target audience as possible. For

example, if you need to set security policies for all machines in a domain, link the GPO at
the domain level. But if youre setting security policy on a set of machines that resides in
a single OU, link at that OU only. (The alternative to this approach is to link higher in the
AD hierarchy, then use security groups to filter the effect of a GPO. However, this is less
desirable because it makes troubleshooting effective policy more challenging and less
obvious.) Finally, when you need to enforce network-specific policy such as IPSec, link
GPOs to sites.
6. Delegate administration of GPOs only to the extent that is needed to support your

business goals. In general, its a good idea to keep as many of your GPOs centrally
managed as possible to ensure good change control and consistency of use. And because
GPOs (that is, their component GPCs and GPTs) are replicated to all domain controllers
in a domain, its important that forest-wide administrators know whats being done to
their infrastructure.
7. Develop a good and consistent process for naming and changing GPOs, then ensure that

everyone in the forest follows it.

Considering Technical Issues

In addition to creating a good initial design of your GPO infrastructure, youll face some
technical issues as you deploy GPOs. These issues may significantly affect your design or its
performance, so its important to keep them in mind.
Asynchronous, Slow Network, and Periodic Background GPO Processing
Some types of processing in GPOs can affect your design process. These effects are summarized
in Table 4.3 below.
Feature

Effect

Asynchronous GPO
processing

GPOs are normally processed synchronously. That is, a computer

processes all GPOs before it presents a user dialog box, and a user
processes all GPOs before the Desktop is presented. Using asynchronous
processing speeds the machine startup and user logon process, but it
doesnt guarantee that the necessary GPOs will have finished processing
by the time each event occurs.

115

Chapter 4
Slow-network detection
processing

When a machine starts up and a slow network link is detected, certain

GPO policy is disabled (for example, Folder Redirection and Software
Installation). This limits the effectiveness of these policies for roaming
users.

Periodic background
processing

Certain policy (such as machine security and Administrative Templates)

isnt just applied when a machine starts up or a user logs on. Its re-applied
periodically thereafter (by default, every 90 minutes).

Table 4.3: GPO processing that can affect your GPO design.

As you plan your GPO rollout, its important for you to recognize the effects of these three types
of processing. For example, if many of your users access your AD infrastructure over slow
linksby default, less than 500 kilobits per second (Kbps)some policies, like Software
Installation and Folder Redirection, wont be applied. Using these policies may therefore not be
effective in your environment. Or if youre worried about the processing performance of GPOs
in your environment, you can enable asynchronous GPO processing for the machine or user (or
both), thus reducing the wait time the machine incurs processing GPOs.
Finally, its important to know that background processing occurs for certain policy, such as
security and Administrative Templates. This means that even if your users attempt to foil a
particular policy on their local machines, their futzing will be undone later when policy is reapplied.
Controlling Their Effects
You can control the effects of these three types of processing using Administrative Template
policy in a GPO. These GPO processing policies are found in the Computer and User sections of
Administrative Templates, under Administrative Templates, System, Group Policy. Figure 4.12
shows an example of the machine-specific GPO processing policies available.

116

Chapter 4

Figure 4.12: The machine-specific GPO processing policies available in Administrative Templates.

If you view each of the policy items available in this policy section, you can change the default
behavior for a number of GPO processing options. For example, if you dont want Folder
Redirection to be disabled when a slow network link is detected, select Folder Redirection Policy
Processing. In the Properties dialog box, click Enabled, then click Allow Processing across a
Slow Network Connection (see Figure 4.13).

117

Chapter 4

Figure 4.13: Enabling Folder Redirection across a slow network connection.

If you want to change what Win2K considers to be a slow network connection for machines
subject to this policy, you can modify Group Policy Slow Link Detection to specify a link speed
greater or less than the default 500Kbps. Choosing a larger numbersuch as 700Kbpstells the
machines to consider any link slower than 700Kbps to be a slow link. When the machines detect
a link slower than 700Kbps, they wont process any policies that are set not to process.
Specifying a lower numbersay, 60Kbpstells the machines that, unless their detected link
speed is below 60Kbps, they should consider the link a fast link and process all GPOs normally.
For more information about slow-link detection in Win2K, check out the following Microsoft Support
article http://support.microsoft.com/support/kb/articles/Q227/2/60.ASP.

The Apply Group Policy for Computers Asynchronously during Startup and Apply Group Policy
for Users Asynchronously during Logon policy items control whether asynchronous policy
processing happens.
If you decide to modify the default behavior of each of these processing options, make sure that
the GPO that controls the behavior is one that is centrally managed. This GPO might be a good
candidate for control by your forest-wide administrators. You might also decide that you only
want to link this GPO to selected OUs or, more appropriately for a policy like slow-link
detection, to particular AD sites.
In addition, keep in mind that processing options like slow-link detection are put in place for a
reason. If you have a Software Installation policy that delivers Microsoft Office to a set of users
and you override the slow-link behavior for Software Installation, users dialing in to your

118

Chapter 4
corporate network on 56-Kbps modems may suffer an interminable wait as many megabytes
worth of Office try to install.
GPO Loopback Processing
Finally, I want to say a word about a feature called GPO loopback processing. Ill discuss this
feature in greater detail in Chapter 5, but for now, I want to introduce the concept. Consider the
problem where you have a special kind of workstation in your AD infrastructure. It may be a
kiosk or other single-function device that is meant to run one application and one application
alone. If a user defined in your AD environment walks up to that workstation, he or she will
receive any machine-specific GPOs defined for that device as well as any user-specific GPOs
defined for his or her user account. However, an administrator may not want the user to receive
the normal user-specific GPOs on this particular device.
To handle this situation, Microsoft has developed loopback processing. (See the User Group
Policy Loopback Processing Mode policy item in Figure 4.12 above.) As I said, Ill go into more
detail about this in Chapter 5, so suffice it to say that loopback processing lets you disable a
users normal policy processing in favor of any defined on the GPO(s) that apply to the device he
or shes logging on to. Its a special kind of user-policy override meant especially for machines
with unique application requirements.

Summary
In this chapter, I discussed the challenges and decision points for designing and deploying GPOs
in the enterprise. The key themes here are to start slow and keep it simpleusing the features
youre familiar with, such as Administrative Templatesbefore going full bore into the complex
stuff. That said, youll still want to ensure that part of your GPO rollout plan includes good
version and change control, just as you would with any other infrastructure or application.
Unfortunately, with no tools built in to Win2K to perform these tasks, youll have to go it alone
until third parties catch up and provide this functionality.
Finally, youll need to consider the inherent special behavior that GPOs provide, like
background, asynchronous, and slow-link detection processing. You can modify this behavior if
necessary, but youll need to balance that against good user experience and good GPO
processing performance.

119

Chapter 5

Chapter 5: Working around Group Policy Limitations

In the preceding four chapters, I described GPO function and structure and how you can make
practical use of these functions in your own environment. The last two chapters of this book are
directed at those of you whove actually gone so far as to implement GPO technology and are
now coming up against its limitations. In particular, this chapter will discuss how to work around
some limitations and challenges Ive discovered while working with GPOsparticularly GPO
delegation. In Chapter 6, Ill describe some techniques Ive come up with for troubleshooting
GPO problems and tools for managing GPOs before problems arise.
I think its reasonable to expect that with any new software technology, the first implementation
wont have every capability or anticipate the end users every need. This is of course true with
Microsofts Group Policy implementation. This isnt to say that Microsoft hasnt done a
yeomans job with this first version. But as with most software, real-life user problems are
difficult to anticipate and code for the first time around. That said, Ill look at some of the
thornier aspects of GPO implementation and describe ways that Ive found to get around them.

Controlling GPO Delegation

Why is a seemingly basic GPO function discussed in this chapter on Group Policy limitations?
The answer is simple. In Chapter 4, I alluded to the challenges you can face when delegating
administration of GPOs. These challenges make delegation of GPOs counterintuitive and
difficult to do correctly. This section seeks to clear up some of these difficulties and help you
manage GPO delegation effectively.
To review, youre going to be interested in delegating to your administrators three GPO tasks.

CreatingWho is allowed to create GPOs and delete them in your AD infrastructure?

LinkingLinking (and un-linking) a GPO to a containerbe it a site, domain, or OU.

(By default, when you use a tool like Active Directory Users and Computers or AD Sites
and Services to create a new GPO, creating and linking occur in one step, but theyre
actually two distinct steps.)

EditingOnce youve created and linked a GPO, you need to edit it.

In Chapter 3, I described how you can create a GPO without actually linking it to a container. See the
tip in the section Adding New GP Links.

As you know, AD delegation is all about granting security rights to AD objects to permit certain
users access to specific objects and their properties. You carry out GPO delegation using the
same techniqueby granting rights to certain AD objects related to GPOs (such as the GPC).
The principal tool for controlling GPO delegation is your old friend, the ACL editor.
As I mentioned in Chapter 4, to display the ACL editor, right-click the GPO display name in a
Group Policy MMC snap-in, then choose Properties from the shortcut menu. In the Properties
dialog box, click the Security tab. Figure 5.1 shows the ACL editor, focused on a GPO.

120

Chapter 5

Figure 5.1: The ACL editor, focused on a GPO.

The ACL editor for GPOs has a dual function. You use it to filter security groups and thereby
control which users and computers process a particular GPO. However, for the purposes of this
discussion, you use it to control who can create, edit, and link to a particular GPO. When you
delegate creating and editing of GPOs, you set security on the GPO itself (as in Figure 5.1).
When you delegate linking GPOs to container objects like sites, domains, and OUs, you grant
rights on the container object itself, as you might expect.
Default Rights
When you install Win2K and AD out of the box, a certain set of default rights is granted on AD.
As they affect the three roles I discussed above, these default rights are shown in Table 5.1.
Group

Rights

Enterprise Admins (global group or universal

group in native mode)

Create, delete, and edit GPOs and link (and un-link)

GPOs in all sites, domains, and OUs in a forest.

Domain Admins (global group)

Create, delete, and edit GPOs and link (and un-link)

GPOs in the domain and in all OUs (but not sites) in
which the Domain Admins group resides. Members of
the Domain Admins group in the forest root domain can
also link (and un-link) to sites in a forest.

Group Policy Creator Owners (global group)

Can create (but not delete) GPOs in the domain to

which the group belongs. The user who is a member of
Group Policy Creator Owners can also edit any GPOs
that he or she creates, but other members of that group
cannot. In addition, members of this group cannot link to
any site, domain, or OU.

121

Chapter 5

Group

Rights

Administrators (built-in local group)

Can create GPOs in the domain to which the group

belongs. Can only edit or delete GPOs that were
created by members of this group. Can link and un-link
GPOs at the domain and on all OUs.

Table 5.1: The default AD rights that control GPO delegation.

As you can see from Table 5.1, the default GPO delegation configuration in AD is less than
straightforward. No one group with the exception of the forest-wide and all-powerful Enterprise
Admins group can create, delete, edit, link, or un-link GPOs universally in a forest. However, if
youre trying to design a GPO delegation model that grants limited capabilities to your
administrators, youre not going to want to make these administrators members of the Enterprise
Admins group (or even Domain Admins or local Administrators) because these groups confer
other, power capabilities as well. This leaves you using the Group Policy Creator Owners group
(for brevity, Ill call this the GPCO group from now on) as a way of delegating GPO creation,
then coming up with other solutions to take care of the other roles. As you can see, if you want to
build a decent GPO delegation model, you have to modify AD security.
There are several approaches that you can take to solve the GPO delegation problem. The first is
to modify the rights of one of the existing groups above. But because all but the GPCO group
confer many other rights to their members, its probably best to start from scratch and create a
new group. Before I describe such an approach, I want to talk about the problems associated with
using the GPCO group to delegate GPO management.
As I mentioned, the GPCO group only grants a member the ability to create GPOs in a domain; it
doesnt allow the member to link these GPOs to any container. If user Joe Admin is a member of
the GPCO group and he creates a GPO, he alone can edit this GPO by default. The reason is that
when the Group Policy MMC snap-in creates the GPO in the domain, it doesnt assign the
GPCO group as having the rights to the GPO. Rather, GPCO is a special kind of group that is
just a placeholder for the actual user who is a member of the group and performing the operation.
When rights are assigned based on an operation performed by a member of the GPCO group, the
ACE is actually assigned to the users account rather than to the group. As an example, lets
suppose you have a user id in your AD domain called admDarren. The administrator for your
domain has placed this user account in the GPCO group. You want to create a GPO, so you
display the Group Policy MMC snap-in, and using the method described in Chapter 3, you create
a GPO without linking it to a container (because members of the GPCO group cannot, by default,
link GPOs to any container). Figure 5.2 shows what the ACE looks like on the newly created
GPO when you view the security properties on the GPO.

122

Chapter 5

Figure 5.2: The security properties on a GPO created by a member of the GPCO group.

As you can see in Figure 5.2, none of the ACEs list the GPCO group. This is because the user
idadmDarrenreplaced the GPCO group in the ACE when you created the GPO. Why is this
a problem? Well, once you create a GPO, you may want others to be able to edit it. Sounds
reasonable, doesnt it? One would think that if a member of the GPCO group creates the GPO,
another member of the group can edit it. Unfortunately, its not as simple as that. The group only
acts as a placeholder for the real user who is doing the creating. As you can see from the ACL in
Figure 5.2, this account (in addition to the other groups), not the GPCO group, can modify the
GPO.
So how do you get around this? To provide an answer, I need to explain where and how GPO
delegation occurs in AD, and to do that, you need to recall concepts from Chapter 2 on the
structure of GPOs.
How GPO Delegation Works
As Ive mentioned previously, two sets of tasks can be delegated as part of GPO management.
The first set of tasks is creating, editing, and deleting a GPO in the domain. The second is linking
the GPO to a site, domain, or OU.
Delegating Creation, Editing, and Deletion GPOs
Remember from Chapter 2 that GPOs belong to a particular domain and are broken into two
physical piecesthe GPC and the GPT. The GPC is the part of a GPO that resides in AD. GPC
objects can be found in the Active Directory Users and Computers MMC snap-in (in Advanced
View mode) under the System\Policies folder (see Figure 5.3).

123

Chapter 5

Figure 5.3: The GPC portion of a GPO, displayed in the Active Directory Users and Computers MMC snap-in.

Figure 5.3 shows a number of GUID-named folders under the System\Policies folder that
correspond to GPOs created in this domain. Just as with other objects in AD, these folders have
security rights associated with them. These rights control who can do what to a particular GPO.
Figure 5.4 shows the ACL editor for one of these folders.

124

Chapter 5

Figure 5.4: The security properties of a GPC in the Active Directory Users and Computers MMC snap-in.

Youll notice that the permissions shown in Figure 5.4 are identical to those listed in Figure 5.2.
In fact, theyre for the same GPOadmDarrens GPO. Figure 5.2 showed the security settings
on the GPO using the Properties command on the shortcut menu in the Group Policy MMC snapin, whereas Figure 5.4 shows the security settings on the GUID-named GPC folder
corresponding to that GPO.
As you can see, Figure 5.2 shows a sanitized version of the rights assigned to the GPC.
Furthermore, if you were to look at the file permissions on the GPT for this GPO in the
SYSVOL share in this domain, youd see file security like the AD security shown above. Figure
5.5 shows the ACL editor focused on the GPT for this GPO.

125

Chapter 5

Figure 5.5: The NTFS security rights on a GPT in SYSVOL.

Of course, because NTFS rights are a bit different from AD rights, figures 5.4 and 5.5 dont list
identical ACEs, but the same users and groups are listed in the ACL, and the control theyre
granted over the GPT is similar to the control granted in the GPC.
It isnt mere coincidence that the GPC and GPT have nearly the same rights assigned to them for
a particular GPO. When you create a GPO using the Group Policy MMC snap-in, several things
go on behind the scenes to ensure that the GPO has the correct security assigned to it. The
security rights granted to a new GPO are controlled based on simple inheritance. In the case of
the GPC, when a new GPO is created, a new GUID-named folder is created, like those shown in
Figure 5.3. This folder inherits the permissions granted to its parent folder, System\Policies.
The rights granted at the folder level control who in a domain can create, edit, and delete a GPO.
Similarly, on the GPT side, the same users or groups who have rights to create, edit, and delete
GPC objects are granted such rights over the GPTs parent folder. Because the GPT resides in
the SYSVOL share on domain controllers in a domain, this parent folder is found on the path
\\<domain>\SYSVOL\<domain>\policies.
When you view the security properties on a GPO from a Group Policy MMC snap-in (as shown
in Figure 5.2), youre viewing the security as its assigned on the GPC folder for that GPO. But
to be able to create, delete, or edit the GPO, you also need to have the corresponding rights in the
GPT folder for the GPO. In a default AD installation, if you keep the default groups that have
permissions to manage GPOs, you dont ever need to be concerned about the security
permissions applied to either the GPC or the GPT Policies folder. However, if you want to do
any customization to GPO delegation, you need to modify these default permissions on the GPC
or GPT.

126

Chapter 5

You may be inclined to ask why the Delegation of Control wizard provided with the Active Directory
Users and Computers and AD Sites and Services snap-ins doesnt allow you to customize the
delegation of GPO creating, deleting, and editing. Its a good question, and one with no easy answer.
The Delegation of Control wizard is essentially a shortcut to the ACL editor, so its a simple and rather
stupid tool. If you run the Delegation of Control wizard against a container such as a site, domain, or
OU, there appears to be a way to delegate creating GPC objects. However, this is in fact not what
occurs.
Because GPC objects are created under the special System\Policies folder in an AD domain, you
actually need to run the Delegation of Control wizard on that folder rather than on a particular site,
domain, or OU. Makes sense, right? However, simply running the Delegation of Control wizard
against the System\Policies container doesnt grant the rights needed to delegate creating GPOs.
This is because the Delegation of Control wizard does nothing to handle creating permissions in the
GPT in SYSVOL. As a result, if you use the Delegation of Control wizard to delegate the creating of
GPOs to a new group, then as a member of that group, try to create a GPO in the domain, youll get
an Access Denied message. Later in this section, Ill describe the methods you can use to
successfully delegate creating, deleting, and editing of GPOs.

The first step to correctly delegate GPO administration is knowing which rights confer which
capabilities. Lets look at exactly what rights you need on the GPC and GPT to be able to view,
edit, create, and delete GPOs. Table 5.2 below shows the rights that must be granted on the
System\Policies folder or a GPC to confer a particular GPO management capability. (These
rights correspond to the ACL editor view shown in figures 5.2 and 5.4.) The Apply Group Policy
permission isnt listed because it doesnt affect delegation of GPOs.
Right

Allows the User or Group To

Full Control

View, create, delete, and edit the GPO.

Read

View the GPO and its properties in the Group Policy MMC snap-in
but not open the GPO for editing.

Write

View and edit the GPO. (Write doesnt confer the ability to read a
GPO as well; that permission must be explicitly granted.)

Create All Child Objects

Create and edit (but not delete) GPOs.

Delete All Child Objects

Delete GPOs.

Table 5.2: The rights used on GPC objects to delegate GPO management.

Table 5.3 below lists the corresponding NTFS rights that must be set on the GPT folders to grant
capabilities like those listed in Table 5.2 above.
Right

Allows the User or Group To

Full Control

View, create, delete, and edit the GPO.

Modify

View, create, delete, and edit the GPO.

Read & Execute

List Folder Contents
Read

View the GPO. When you select the Read & Execute right, the List
Folder Contents and Read rights are granted automatically.

Write

View, create, delete, and edit the GPO.

Table 5.3: The rights used on GPT objects to delegate GPO management.

127

Chapter 5

Its possible to confer one set of rights on the GPC portion of a GPO and another set on the GPT
portion. The results, as you can imagine, arent good. For example, you can grant Write access to a
GPO in the GPC. This theoretically lets you edit the GPO, and indeed, you can open and edit the
GPO just fine in the Group Policy MMC snap-in. However, if you dont have the corresponding Write
permission on the GPT portion of the GPO, any changes you make to the GPO are lost without any
kind of warning or message about a lack of access. It seems that the Group Policy MMC snap-in only
checks to ensure that you have the correct permissions on the GPC before allowing you to edit that
GPO.

Of course, creating and editing GPOs is only one side of the delegation equation. The other side
is linking and un-linking GPOs from a site, domain, or OU.
Linking GPOs
Once you understand the delegation process for creating, deleting, and editing GPOs in your AD
domains, the next step is to decide who can link these GPOs to sites, domains, and OUs. As I
mentioned above, while delegating control of tasks such as creating GPOs requires setting
security rights on the GPC and GPT, delegating the linking and un-linking of GPOs is done at
the container level.
For example, if you want a group of administrators in the Finance OU to be able to link GPOs to
its own OU, you need to set security rights on the OU rather than on the GPC or GPT for the
GPOs. Fortunately, unlike delegating the creating of GPOs, where you have to worry about
security on both AD and SYSVOL, delegating GPO linking only involves setting AD security on
the container objects in question.
There are actually two rights that you can grant to a user or group at the container level.
Remember from Chapter 3 the discussion of the gPLink and gPOptions attributes that are present
on container objects. The gPLink attribute contains the GUIDs of all GPOs linked to the selected
container. Figure 5.6 shows the contents of the gPLink attribute on the HQ OU in a test domain
using the ADSI Edit tool.

128

Chapter 5

Figure 5.6: The contents of the gPLink attribute on an OU in ADSI Edit.

The Value(s) text box shows a string containing the LDAP DN of a GPO in the domain. The
ability to write to the gPLink attribute on a given site, domain, or OU container object is what
gives a user or group the ability to link and un-link GPOs to that container.
In addition to being able to manipulate the gPLink attribute, you can delegate the ability for a
user or group to use the Block Policy Inheritance feature, described in Chapter 3. The gPOptions
attribute on a container object controls whether this feature can be used. If the user or group can
write to this attribute, they can enable or disable this feature. If they cannot write to this attribute,
they cannot change it. Thus, even if you allow someone to link a GPO to their OU, for example,
you can prevent him or her from disabling upstream GPOs by not granting sufficient
permissions on the gPOptions attribute.
There are two ways to delegate security rights (and thus be able to link and un-link GPOs) for the
gPLink and gPOptions attributes. You can use:

The Delegation of Control wizard to grant rights to users and groups in your domain

The ACL editor directly.

Ill explain how to delegate security rights using the ACL editor. The Delegation of Control
wizard is only good for one-time ACL changes, and eventually, youll have to use the ACL
editor anyway.
First start the Active Directory Users and Computers MMC snap-in. (If youre granting rights to
users or groups on site objects, start the AD Sites and Services snap-in.) Lets suppose you have
an OU called HQ, and you want to grant linking and un-linking rights to an administrative group
in this OU called HQ Group Policy Admins. The first thing you need to do is get to the ACL

129

Chapter 5
editor for the HQ OU. Right-click the HQ OU, then choose Properties from the shortcut menu. In
the Properties dialog box, click the Security tab. Figure 5.7 shows the ACL editor for this OU.

Figure 5.7: The ACL Editor, focused on the HQ OU.

To grant (or revoke) rights for the gPLink and gPOptions attributes on this OU, click Advanced
to see additional permissions. Figure 5.8 shows the advanced ACL editor view.

130

Chapter 5

Figure 5.8: The advanced ACL editor view on an OU.

To delegate the linking and disable inheritance rights on this OU, click Add, then add the HQ
Group Policy Admins group to the ACL. Select the group, and the Permission Entry dialog box
appears, where you can assign the actual rights to the gPLink and gPOptions attributes. This
dialog box has two tabsObject and Properties. Object is selected by default and shows the
permissions available on the OU object itself. However, youre interested in the Properties tab.
Click this tab, then set permissions on the individual properties on this OU. Figure 5.9 shows the
Properties tab as well as the permissions for gPLink and gPOptions.

131

Chapter 5

Figure 5.9: The permissions on properties (attributes) that you can assign on an OU.

As you can see in Figure 5.9, both gPLink and gPOptions have Read and Write permissions
associated with them. Read permissions are required for a user or computer processing GPOs
because it needs to be able to read the gPLink attribute to see which GPOs are linked to the site,
domain, or OU in question. However, the Write permission is of more interest here. By selecting
the Write gPLink permission, you grant the HQ Group Policy Admins group the ability to link
GPOs to the HQ OU. And by selecting the Write gPOptions permission, you grant this group the
ability to enable or disable inheritance on this OU.
How will you know if youve successfully granted or revoked from an administrator the ability
to link or un-link GPOs to or from a container object? When the administrator hasnt been
granted the Write gPLink permission, then attempts to create a GPO or add a link to an existing
GPO from a container object, that option will be grayed out.
You can see this, for example, in the Active Directory Users and Computers snap-in. If you
right-click HQ OU, choose Properties from the shortcut menu, then click the Group Policy tab in
the Properties dialog box, youll see the familiar Group Policy dialog box (shown in Figure
5.10), where the New, Add, Options, and Delete buttons are all grayed out. Removing the Write
permission on gPLink effectively prevents this user from adding any new GPOs or linking
existing ones to this OU. And because the user cant change the gPLink attribute, he or she also
cant delete a GPO or its link from this dialog box.

132

Chapter 5

Figure 5.10: The Group Policy dialog box after the gPLink Write permission has been revoked.

Interestingly enough, the Block Policy Inheritance check box is also grayed out, even though this
user still has Read and Write permissions for the gPOptions attribute. Now, I personally think
that users should still be able to block policy inheritance in this situation, but apparently the
person at Microsoft who coded this UI didnt think so! Another seemingly odd thing is that if a
user has Write permission on gPLink, but not on gPOptions, he or she can select the Block
Policy Inheritance check box, but then receives an error, indicating that the change cant be
made. Youd think that the better way to handle this would be to gray out the check box, as
shown in Figure 5.10 above.
Now that Ive discussed how you can delegate GPO creating, editing, deleting, and linking, its
time to pull it all together and go through a real scenario where you delegate OU administration
in your AD domain.
Putting GPO Delegation into Practice
Lets suppose that youve installed your AD domain, and now you want to use your newfound
knowledge about GPO delegation to delegate the management of GPOs in your domain. The first
thing youll do is delegate the ability to create, edit, and delete GPOs. Remember from the
discussions so far that these are domain-wide rights. That is, a GPO exists in a domain in a single
placein the GPC (and GPT). So when you delegate administration of GPO creation, deletion,
and editing, you do so across the domain. If you grant users the ability to create GPOs in a
domain, they can create as many as they want until you stop them. On the other hand, if you
grant users the ability to link a GPO to the Finance OU, theyre fairly limited to how much
damage they can do.

133

Chapter 5
The point is that delegating GPO creation and deletion is pretty much an all-or-nothing task, one
that should be done with prudence. Because each new GPO creates its corresponding GPC and
GPT, which starts out at just under 1 megabyte (MB) in size, a user who creates thousands of
GPOs just for the fun of it can seriously affect seemingly unrelated things, such as AD and
NTFRS replication traffic on your network. So consider GPO creation (and deletion) a rare right
that shouldnt be abused!
That said, you do have some ability, once a GPO has been created, to go back and remove
permissions to prevent a user from deleting it or even editing it. Ill talk in this section about how
to delegate the creation process from scratch as well as how to change existing permissions on a
GPO to prevent further changes.
Making Changes to the Policies Folder
As I mentioned in the previous section, delegating the creation of GPOs is controlled using the
permissions contained in the GPC System\Policies folder in an AD domain and the NTFS file
permissions on the SYSVOL-based Policies folder on your domain controllers. Therefore, if you
want to grant new rights to create GPOs, you need to make changes to these folders.
To reiterate, you only have to manually modify GPC and GPT permissions when youre delegating
the creation of GPOs to a new user group. To grant users the ability to modify or delete a GPO, you
can use the ACL editor.

Lets suppose youve created a special domain-wide global group called GPO Admins. You want
to be able to give this group the ability to create, delete, and edit GPOs in your domain. Youll
then delegate editing and linking rights on an as-needed basis to those groups that require them.
Ill walk through this entire scenario now to describe the challenges and complexities of
implementing a truly flexible GPO delegation.
Depending on the size of your environment, you may make some groups responsible for creating,
editing, and deleting GPOs and delegate to others the ability to link GPOs. This is important to keep
in mind as you plan your GPO implementation because the various groups dealing with GPOs must
be in sync at all times.

Open the Active Directory Users and Computers MMC snap-in, focused on your domain
specifically, the domain controller in your domain that is currently the primary domain controller
(PDC) operations master)and drill down to the System\Policies folder.
To focus on a particular domain controller in the Active Directory Users and Computers snap-in, rightclick the domain name at the top of the left-hand (scope) pane, then choose Connect to Domain
Controller. In the Change To dialog box, type the name of the domain controller that has the PDC
operations master role for your domain. The reason I suggest the PDC operations master to focus on
for your GPC changes is that its the domain controller that the Group Policy snap-in focuses on by
default whenever you edit the GPO. Focusing on the same domain controller each time you make
changes to a GPO (whether using the MMC snap-in or directly on the GPC or GPT) ensures that two
people dont edit the same GPO on two different domain controllers and potentially overwrite each
others changes.

Right-click this folder and choose Properties from the shortcut menu. Then in the Properties
dialog box, click the Security tab. When you open the ACL editor on this folder, you see the
134

Chapter 5
default GPO permissions that are listed in Table 5.1 earlier in this chapter. At this point, youre
ready to grant create, edit, and delete permissions to the GPO Admins group.
Click Add, then select the GPO Admins from the list. Now that youve added an ACE for the
group, you need to modify the permissions youre granting to it. How do you know which
permissions to grant to a group to convey sufficient results? Well, from Table 5.2 earlier in this
chapter, you know that you need to grant at least the Create All Child Objects and Delete All
Child Objects permissions to give the group the ability to create and delete GPOs.
If you dont grant the Delete All Child Objects permission, the group members can create but not
delete GPOs in the domain.

You can also grant Read permission, but you dont need to, because the Authenticated Users
group, of which all users defined in the domain are members, already has Read access to the
System\Policies folder by default. Figure 5.11 shows the necessary permissions to grant the GPO
Admins group the ability to create, edit, and delete GPOs in your domain.

Figure 5.11: The permissions on the GPC-based System\Policies folder required to delegate creating,
deleting, and editing of GPOs.

At this point, youre only half done. To really allow the GPO Admins group to be able to create,
delete, and edit GPOs, you also have to grant the equivalent rights in the GPT. The easiest way
to do this is to log on to a domain controller in your AD domain and change the NTFS
permissions on the folder.

135

Chapter 5

Be careful which domain controller youre focused on when you make the change. Just as with the
System\Policies folder discussed above, its a good idea to change GPT permissions on the PDC
operations master for your domain because this is the server, by default, that the Group Policy MMC
snap-in focuses on when creating, editing, and deleting GPOs.

Log on to the PDC operations master, navigate to the volume where youve defined SYSVOL on
that server, then drill down to the Policies folder under the SYSVOL share. The path will look
something like this:
%systemroot%\sysvol\sysvol\<domain>

where <domain> is the name of your domain. In the domain folder, there should be at least two
foldersPolicies and Scripts. If you right-click Policies, then choose Properties from the
shortcut menu, you can set security on the GPT. In the Properties dialog box, click the Security
tab, then add the GPO Admins group and grant it the appropriate rights to create, edit, and delete
GPOs. In this case, the Modify permission will accomplish your goal, so grant GPO Admins the
Modify permission on the Policies folder (see Figure 5.12).

Figure 5.12: The permissions on the GPT-based Policies folder required to delegate creating, deleting, and
editing GPOs.

Youve now completely delegated creating, deleting, and editing GPOs to the GPO Admins
group. The next step is to delegate linking to other user groups. Then Ill show you how to
modify existing GPO permissions to change access to a GPO.
Lets say you have an OU called Finance that wants to be able to link to some GPOs in your
domain. In the Finance OU is a group called Finance GPO Admins, to whom youll delegate the
ability to link and un-link GPOs. As I mentioned earlier in this chapter (see Linking GPOs),
136

Chapter 5
you need to grant linking permissions on the container (for example, site, domain, or OU) where
the linking is to occur. So as an administrator, youll grant linking permissions to the Finance
GPO Admins group on the Finance OU.
The person who is changing security on the OU must have the rights to do this. In many cases, OU
administrators themselves may be able to grant this permission. On the other hand, you may want a
higher-level administrator to do this; you may not want to delegate the ability to change permissions
on an OU to the administrator of the OU!

To delegate the linking permission, start in the Active Directory Users and Computers snap-in
and right-click the Finance OU. Choose Properties from the shortcut menu, then in the Properties
dialog box, click the Security tab. In the familiar ACL editor, click Advanced. In the advanced
ACL editor view, click Add to add the Finance GPO Admins group as the target group for the
new ACE. The Permission Entry dialog box will appear. Click the Properties tab to set
permissions on the OUs properties (attributes), then select the Read gPLink and Write gPLink
permissions.
You can also grant the Finance GPO Admins group the ability to block policy inheritance on the
OU by granting the Read gPOptions and Write gPOptions permissions. Figure 5.13 shows what
the resulting ACE looks like after youve granted linking permissions on the Finance OU.

Figure 5.13: The permissions required to delegate linking and un-linking of GPOs.

Once youve granted these permissions, the Finance GPO Admins group will be able to link any
GPOs that it has Read permissions on to the Finance OU. This is an important point. If there are
GPOs in your AD forest that you dont want to allow certain administrators to link to, you need
137

Chapter 5
to set permissions on those GPOs to prevent them from even being read. Remember that, by
default, all GPOs are created with an ACE that allows the built-in Authenticated Users group
Read and Apply Group Policy permissions. If there are particular GPOs that administrators
shouldnt link to, you need to remove the ACE and replace it with a similar one that grants
access only to the intended target group.
Remember, too, that once you remove this ACE, no users or computers will be able to read or
process the GPO, so make sure that you replace it with one that grants the access you really need.
An administrator needs at least the Read permission to be able to link to the GPO. As I
mentioned in Chapter 3, the Apply Group Policy permission controls which users and computers
actually process the policy, and an administrator doesnt have to be able to link to that GPO.
Modifying Permissions on Existing GPOs
As I alluded to above, you may need to modify the permissions on existing GPOs rather than
modify permissions directly on the System\Policies and SYSVOL folders to delegate new GPO
creation. If this is the case, I suggest using the Group Policy snap-in ACL editor instead of
modifying permissions on each GPOs GPC and GPT folders. This minimizes mistakes and
ensures that the permissions that you intended are indeed applied. I can think of a couple of
examples where you might want to go back and modify existing GPO permissions.
In one situation, lets suppose youve decided to use the GPCO group to delegate creating and
deleting GPOs. As I mentioned earlier in this chapter (see Default Rights), when you use this
group, the ACE that is written to the newly created GPO is created for the user account that
created the policy rather than the GPCO group. This means that, in the future, only that user can
modify or delete the GPO. This may not be a desirable scenario, so it might be worthwhile to
modify permissions on that GPO to give additional users or groups the Write or Modify
permission. You can do this in the Group Policy MMC snap-in by focusing on that GPO and
changing its security properties. (I discussed how to do this in How GPO Delegation Works
earlier in this chapter.)
In another case, you might want to delegate administration of the two built-in GPOsDefault
Domain Policy and Default Domain Controllers Policy. By viewing the properties of these two
GPOs from MMC, you can determine their GUIDs, and you can modify the System\Policies and
SYSVOL Policies folders to allow users other than Domain Admins, local Administrators, and
Enterprise Admins to edit them.
Linking GPOs to a Site Object
Now I want to say a word about site-linked GPOs. Everything Ive discussed in this chapter so
far applies to creating and linking site GPOs, but you need to be aware of a few minor
differences. The first and most obvious one is that to link GPOs to a site, you use the AD Sites
and Services MMC snap-in. You simply right-click a site object in the snap-in, choose Properties
from the shortcut menu. This is shown in Figure 5.14. Then in the Properties dialog box, click
the Group Policy tab as you would in the Active Directory Users and Computers tool.

138

Chapter 5

Figure 5.14: Linking GPOs to a site object in the AD Sites and Services snap-in.

The principal difference between site-based GPOs and domain- or OU-based GPOs is where
theyre created by default. If youre using the MMC snap-in to create and link a GPO to a site in
one step, the GPO is automatically created in the forest root domain. If you have a multi-domain
AD forest, you need to have GPO creation permissions on the GPC and GPT in the forest root
domain to create and link site-based GPOs in one step. Otherwise, you can create a GPO, then
link it in any domain in your forest to a site object.

Using Security-Group Filtering on GPOs

Now that Ive discussed the challenges of controlling GPO delegation, I want to cover a related
topicusing security-group filtering on GPOs. In previous chapters, I described how securitygroup filtering of a GPO prevents selected users and computers from processing it. In this
chapter, I want to point out some challenges you need to be aware of when using security-group
filtering.
As you can imagine, GPO security-group filtering can become complex in a hurry. If you have
lots of GPOs at many levels in your AD infrastructure, security-group filtering isnt advisable.
You need to trade off linking GPOs higher in your AD hierarchy and filtering their effects
narrowly using security groups against linking at the OU level, right where your target users and
computers are, and not filtering at all. In large, complex GPO implementations, I always
recommend the latter if possible. However, you may find that security-group filtering is the only
way you can control who gets a certain GPO. In that case, you need to be aware of a few points.
First, security is applied to the GPO, not the link! This is important. For example, if multiple
OUs have been linked to a single GPO, the security that is applied on each of them is the same
and is whatever has been set on the GPO (that is, the GPC and GPT). This can get confusing! If
Joe Admin creates a GPO for desktop lockdown, then sets permissions so that only the Finance
139

Chapter 5
Users security group has Read and Apply Group Policy permissions on that GPO, no one else
who links to the GPO may be able to process it unless they too modify the permissions. This is
another good argument for having a centralized group control GPO creation and maintenance
and allowing your OU administrators to simply link and un-link GPOs.
Second, remember that you have to first remove the Authenticated Users ACE from the default
GPO permissions before you can effectively use security groups to filter the GPOs effects. This
is because Authenticated Users includes every user and computer in your AD forest. You wont
have any luck filtering a GPO if that ACE is still in place. Remember, however, that when you
remove that ACE and add a new security group, only those users and computers that are part of
the new group will be able to view and process the GPO.
Finally, be aware that security-group filtering applies to the whole GPO. For example, it might
be nice if you could filter Folder Redirection for one set of users and Administrative Templates
for another set of computers in a single GPO. No can do! However, you do have some
granularity of control in the Software Installation feature in GPOs, and Ill talk about that next.
Security-Group Filtering for Applications
When I first encountered GPOs, I thought itd be really nice to have more granular control of
security-group filtering. That would allow me, in a single GPO, to control which users and
computers processed which features. Unfortunately, for the most part, security-group filtering of
a GPO is an all-or-nothing affair.
The good news is that Microsoft does provide more fine-grained control when youre using the
Software Installation feature in a GPO to publish or assign applications to your users. If you
publish or assign several applications in a single GPO, you can control which user or computer
groups will see them. If they cant see them, the applications wont get installed. Software
Installation is a kind of down-market version of the Microsoft SMS user and computer group
based Software Advertisement feature.
For an explanation of publishing and assignment, see Chapters 1 and 3.

For example, suppose you have a domain-linked Software Installation GPO and you want to use
it to deploy all of your applications using the Software Installation feature in Group Policy.
However, you want to be able to control who receives certain applications in the GPO. You can
do this by modifying permissions on the individual applications that youve published or
assigned. Figure 5.15 shows a GPO with two applications deployedMicrosoft Office 2000 and
Win2K Administration Tools.

140

Chapter 5

Figure 5.15:Applications deployed using the GPO-based Software Installation feature.

Lets say you want to give everyone access to Office 2000, but you want only certain members
of an administrator group to have access to Win2K Admin Tools. Perhaps youve removed the
Authenticated Users ACEwhich grants all users and computers Read and Apply Group Policy
permissions on a GPOand replaced it with a security group that is targeted to specific users or
computers. Now you want to set permissions on Win2K Admin Tools so that only members of a
particular administrative group receive it.
Before the group members can read the permissions you assign to Win2K Admin Tools, they
must have permission to process the GPO as a whole. Thus, before you use security-group
filtering on an application, the GPO has to be visible and available for processing by all users (or
computers).
That said, Ill show you how to set permissions on the two applications shown in Figure 5.15 to
meet these requirements. The first thing you need to do is edit the GPO, so start the Group Policy
MMC snap-in, focused on Domain Software Installation Policy. Next, drill down to the User
Configuration, Software Settings, Software Installation node, where your two applications have
been deployed. Then right-click Office 2000 and choose Properties from the shortcut menu. In
the Properties dialog box, click the Security tab to show the permissions on the application (see
Figure 5.16).

141

Chapter 5

Figure 5.16: Security permissions on applications deployed by GPO-based Software Installation.

The only permission that a user or computer needs to receive the deployed application from the
GPO is the Read permission. As you can see in Figure 5.16 above, the Authenticated Users
group, by default, has Read permission on all deployed applications. This means that all users
who process this GPO will receive these applications. Office 2000 is fine the way it is, but you
need to modify the permissions on Win2K Admin Tools to only allow selected administrative
groups to receive it.
You edit that applications security permissions just like any other ACL editor operation. In this
case, however, first remove the Authenticated Users ACE that grants all users access to this
application by clicking Remove in the ACL editor. A message appears, as shown in Figure 5.17.

Figure 5.17: The warning message that appears when you try to remove an inherited ACE.

You cant delete the Authenticated Users ACE because its been inherited from a parent
container, so you need to break inheritance between this application and its parent. On the
Security page of the Properties dialog box, clear Allow Inheritable Permissions from Parent to
Propagate to This Object, then click OK. Another dialog box appears, asking whether you want
to copy all inherited ACEs to this object and break inheritance, remove all inherited ACEs from
142

Chapter 5
this object, or cancel the operation altogether. Because you dont want to remove all inherited
ACEs (just Authenticated Users), click Copy, then Apply.
This breaks the security that the application inherits from its parent container object. However, it
may not be apparent what the parent container for an application is. To find out, we have to go
back to Chapter 2. In fact, the parent container for an application is a folder in the GPC called
Packages. The Packages folder is contained in the Class Store in the GPC (see Figure 5.18).

Figure 5.18: The Packages folder in the GPC, from which deployed applications inherit permissions.

As you can see in Figure 5.18, the right-hand (results) pane shows the two applications that are
deployed in the GPO, represented as packageRegistration objects in the GPC.
Getting back to our example, once youve broken inheritance between the application and the
Packages container, you can remove the Authenticated Users ACE and add your new group
permissions. Figure 5.19 shows the resulting ACL for Win2K Admin Tools.

143

Chapter 5

Figure 5.19: The modified permissions on an application object in a GPO.

This figure shows three user groups addedHQ Group Policy Admins, Server Admins, and the
built-in Server Operatorsand granted each Read permissions to this application. Thus, the next
time a member of one of these groups logs on to the domain, Win2K Admin Tools will be
advertised to his or her desktop, ready for installation. No other users will receive the
applicationas youd expect!
The example above describes the two applications as per-user deployments. Thus, any securitygroup filtering you do on these applications needs to be based on user groups, rather than computer
groups, because the applications are processed by users, not computers. If one or both of these
applications is deployed per computer (assigned), youll need to use computer groups to filter which
computers receive which applications.

Application-specific security-group filtering gives you the ability to direct application

deployment to specific user or computer groups in a single GPO. Of course, if youre deploying
many applications using GPOs and plan to use security-group filtering on each one, things can
get pretty complicated. So, as with other features in Group Policy, balance complexity with
capability and make sure that you design an infrastructure that is manageable, well documented,
and immune to staff changes.

Using Loopback Processing

When Microsoft was designing Group Policy, several large customers wanted to have a way to
override policy settings that would normally apply to users who logged on to a special-purpose
computer on the AD network. Special-purpose computers can take a number of forms but

144

Chapter 5
include kiosk-type computers, or single-function computers, which present users with a different
desktop than they see at their own workstations.
This need also applies to an environment using Windows Terminal Server (WTS) environment.
Users log on to Windows terminals using the same credentials they normally use on their own
computers, but while theyre logged on, you may not want their home GPOs to process.
In these cases, Microsoft has provided an interesting workarounda feature known as loopback
processing. Loopback processing is enabled on individual computers using a GPO-based
Administrative Template policy. When a user logs on to a computer that is using loopback
processing, the computer overrides the user accounts own home GPOs and temporarily
applies any GPOs that it processes instead.
To enable loopback processing, you need to open a Group Policy snap-in focused on a GPO and
drill into Computer Configuration, Administrative Templates, System, Group Policy. Figure 5.20
shows where the loopback policy setting is located in a GPO.

Figure 5.20: Loopback policy settings in Administrative Template policy.

Loopback can work in two modesMerge and Replace. Each mode determines how userspecific policy is merged into a users existing user-specific GPO-based settings. In Merge
mode, when a user logs on to a computer that has loopback processing enabled, any user-specific
GPO policy that the computer is processing will be merged with any policy that the user brings
from GPOs that he or she normally processes. Figure 5.21 attempts to illustrate how this works.

145

Chapter 5

Figure 5.21: How GPO loopback processing works.

In the figure above, Joe User has an account in the Finance OU, and he normally logs on to a
computer in that OU as well. A Finance GPO provides Joes computer- and user-specific policy.
User-specific policy may include Folder Redirection, Administrative Template lockdown, IE
Maintenance policy, and so on. When Joe User logs on to the computer labeled Kiosk in the
Kiosks OU, the user-specific policy that he typically receives in his own OU can be overridden
using loopback processing.
If you use loopback processing in Merge mode, any user-specific policy settings that have been
defined on the Loopback GPO will be merged with Joes home policy settingsthose that
were applied from the Finance GPO. For example, perhaps Joe normally receives a Folder
Redirection policy from the Finance GPO that redirects his My Documents folder to a server
share but leaves other folders (like Start Menu, Desktop, and so on) where they are by default.
Now lets say that in the Loopback GPO, you create a Folder Redirection policy that redirects all
users Desktop folders to a server share. Using Merge mode, the result is that Joes My
Documents and Desktop folders are redirected to server shares. If any of these user policy

146

Chapter 5
settings conflict during the merge process, the policy defined on the Loopback GPO will
override what was defined on the Finance GPO.
If you use loopback processing in Replace mode, any user policy that Joe User receives from the
Finance GPO will be completely replaced by what is defined on the Loopback GPO (see Figure
5.21). Joes My Documents folder will no longer be redirected to the server share; his Desktop
folder will be redirected instead.
To enable loopback processing, make sure youre in the Group Policy snap-in as shown in Figure
5.20, then open User Group Policy Loopback Processing Mode. In the Properties dialog box,
click Enabled, then specify a mode (see Figure 5.22).

Figure 5.22: Setting loopback processing with a GPO.

You can see how loopback processing can be ideal in a Windows terminal environment. You can
lock down certain aspects of a users desktop when he or she logs on to a terminal but let the user
roam free when he or she is sitting at their own computer. To use this approach, simply enable
loopback processing using one of the two modes I described above on a GPO that is processed
by your terminal server(s). Then, either on that same GPO or on different ones, define a set of
user-specific policy settings that will take effect when any user logs on to a terminal.
I recommend that you start using loopback processing in Replace mode rather than Merge mode.
As you can imagine, calculating the RSoP for a user who is receiving the results of multiple
merged GPO settings can be a nightmare unless you have a really good lock on what policies
youve set in your environment. Using Replace mode, you always know that the only policies a
user is getting are the ones defined on the GPOs that are processed by the computer with
loopback processing enabled.

147

Chapter 5

Summary
In this chapter, I described ways to work around some challenging issues in your GPO
infrastructure. Delegation, security-group filtering, and loopback processing are all tools that,
once you master them, can make using GPOs more worthwhile. When you use delegation, the
key is to understand the differences among delegating creation, editing, and deletion of GPOs,
and linking and un-linking them, and what permissions enable each.
I also discussed the GPCO security group and some important differences between the
Delegation of Control wizard and setting ACLs directly. With respect to security-group filtering
of GPO processing, the key is to keep it simple and balance security-group filtering with proper
GPO linking. Finally, loopback processing gives you a way of overriding users native user
policy settings when they log on to specialized computers in your AD infrastructure. In the next
and final chapter, Ill look at tools and techniques for managing and troubleshooting your GPO
infrastructure.

148

Chapter 6

Chapter 6: Troubleshooting and Managing Group Policy

The final chapter of this book is devoted to keeping your Group Policy infrastructure up and
running after youve applied everything Ive described in Chapters 1 through 5. This chapter will
provide you with a kit of tools and techniques to keep your GPOs running and to determine
why theyre not when something goes wrong. Most of the tools I describe are available in the
Win2K resource kit, in the Win2K Support Tools, or from Microsofts Web site.
This chapter will fill in some gaps left when Microsoft released Win2K and Group Policy. Plenty
of policy functionality was built into the product, but very few management and troubleshooting
tools were provided out-of-the-box. For example, there is currently no way in the product to
create, delete, or edit a GPO using a script, although you can write a script to link GPOs to AD
containers. You also cant back up or restore individual GPOs. And there is no single interface or
log that you can view to find out about problems when GPOs arent working as expected.
As of this writing, there are very few third-party products on the market to help you manage your
GPO deployments. One tool that does exist, and that Ill talk about later in this chapter, is
FullArmors Zero Administration for Windows 2000 (FAZAM 2000), which provides some of
the missing capabilities. (A reduced functionality version, called FAZAM 2000 RFV, is
available in the Win2K resource kit.) As GPOs become a more widely deployed technology in
Windows infrastructures, I look forward to seeing other vendors step up to the plate and provide
more value.

Examining Common GPO Problems

GPO problems can be divided into two general categoriesthose that result from operator
error and those that are caused by a breakdown in Win2K or AD. The former includes things
like not realizing that youve disabled a GPO, applying security filters to a GPO in a way that the
intended user or computer no longer receives it, and overwriting the effects of one GPO with the
settings from another that is processed after the first. These kinds of problems are easily
mitigated by having good system documentation, a well-controlled delegation model (discussed
in Chapter 5), and change control on your GPO infrastructure. Even though Group Policy doesnt
come with a structured version-control mechanism, I described a way to fudge it in Chapter 4
by simply adding a version number to the display name of the GPO.
Its the second class of problems that will be the focus of most of this chapterthose that result
from a breakdown in one of the moving parts in a GPO infrastructure. As I think Ive shown,
GPOs are complex; to perform as expected, several pieces of technology must be synchronized.
Knowing where to look when things go awry and what tools to use will go a long way towards
helping you keep your GPO infrastructure healthy.
I discuss tools in the next section (see Using GPO Troubleshooting Tools). Here, Ill present a
troubleshooting matrix (Table 6.1 below) that talks about some of the problems youre likely to
encounter, their most likely causes, and potential solutions.
Problem

Probable Cause

Potential Solutions

One or more
GPOs hang
when a user
logs on or a

There are a number of reasons why

a GPO will hang, but it often
happens in conjunction with script
policy. You might have entered a bad

Check all of your paths to the script files in the

GPTs for these GPOs to ensure that theyre
correct and that the permissions on the files
allow them to be executed by the user or

149

Chapter 6

Problem

Probable Cause

Potential Solutions

computer starts
up.

path to a script file in logon/logoff or

shutdown/startup script policy. Or a
script may be poorly written and
caught in some kind of loop or
timeout condition.

computer. Run the scripts manually outside

the GPO to ensure that they dont hang during
processing.
To control how long a GPO can run, you can
set per-computer GPO timeouts in an
Administrative Template policy (see Figure
6.1). The policy shown in Figure 6.1 is a
cumulative limit on the time it takes to run all
scripts that a user or computer is subject to.
If youre unsure what per-user and percomputer scripts are running, check in the
registry under HKCU and HKLM in
\Software\Policies\Microsoft\Windows\System\
Scripts for a list of logon/logoff and
startup/shutdown scripts that the computer
has run.

A single GPO
isnt processed
at all, or only
parts of it are
processed.

Many things can cause a GPO to

simply not be processed, including:
missing or incorrect permissions on
the GPC or GPT; the GPO is out of
sync (that is, the GPT and GPC dont
have the same version number); the
GPO is configured to process only if
its changed since the last
processing cycle.

First check that the Read and Apply Group

Policy permissions are applied on the GPO for
the users and computers whom you intend to
receive the policy. (For more info about using
security to affect which GPOs are processed
by a given user or computer, see chapters 3
and 4.) If the policy isnt being processed
consistently or at all, verify that its actually
supposed to.
For GPOs that might be out of sync, see the
discussion in Chapter 2 on using the
Replication Monitor (replmon.exe) utility for
validating GPO synchronization.
Policies such as Administrative Template,
Software Installation, and Folder Redirection
wont run if nothing in the GPO has changed
since the last time it was run. To verify what
version of the GPO ran most recently, look in
a workstations or servers registry under
HKLM or HKCU in:
\Software\Microsoft\Windows\CurrentVersion\
GroupPolicy\History (see Figure 6.2). There
youll see a number of GUID-based keys that
correspond to the CSEs that are installed on
the computer. Under each CSE is a numbered
key that corresponds to a GPO processed by
that key. The key stores information about the
most recent version of a GPO that was
processed.
You can change whether a CSE processes a
GPO, regardless of whether its changed, by
using Administrative Template policy.
Specifically, in Computer Configuration|
Administrative Templates|System\Group
Policy, each CSE has a policy item that lets
you control its policy-processing behavior (see
Figure 6.3). In these policy items, you can
have the CSE always process a GPO

150

Chapter 6

Problem

Probable Cause

Potential Solutions
regardless of whether its changed since the
last time. Of course, this increases the time it
takes to process policies when a computer
starts up or a user logs on, but it can ensure
that a policy is always enforced.

A single GPO
isnt processed
at all, or only
parts of it are
processed.

The workstation may have detected

a slow network link between itself
and the domain controller that its
using as the source of the GPO. In
this case, Folder Redirection and
Software Installation policy are by
default not processed.

Verify whether a workstation or server has

detected a slow link between itself and a
domain controller by viewing the userenv.log
file. I describe this log file and how to use it to
troubleshoot GPOs later in this chapter (see
Enabling GPO Logging).

A single GPO
isnt processed
at all, or only
parts of it are
processed.

If only parts of a GPO arent being

processed, there could be a problem
with the CSE DLL that is responsible
for processing that policy function.
(For more details about CSEs, see
Chapter 2.)

If a GPO is failing because of a problem with

a CSE, there are a few things you can do.
First, verify that all of the CSEs that should be
registered on the computer indeed are by
comparing the keys under
HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions
on the bad computer with those on a known
good one. Then verify that the DLLs listed
under each registry key are actually found in
the file system where theyre expected to be
(for Microsoft-provided CSEs, this is usually in
%systemroot%\system32).

The wrong
GPOs are
being
processed.

If a computer or user is processing

GPOs that you think they shouldnt
be, a number of problems may be
occurring. For example, a computer
may think its in the wrong site and
thus receiving a site-linked GPO that
youre not expecting.

You can verify which site a computer thinks

its in by viewing the registry value
HKLM\System\CurrentControlSet\Services\
Netlogon\Parameters\DynamicSiteName or
using the nltest.exe utility in Win2K Support
Tools using the following syntax:

nltest /server:<machine name>

/dsgetsite
where <machine name> is the workstation or
server whose site information youre trying to
retrieve.
If a workstations or servers site is incorrect,
use the AD Sites and Services MMC snap-in
to verify that the subnet that the computer
belongs to is associated with the correct site.

The wrong
GPOs are
being
processed

A user may be getting user-based

policy that doesnt correspond to the
OU that he or she resides in. In this
case, the computer being logging in
to may have loopback policy applied.
(For a discussion of loopback, see
Chapter 5.)

Verify that a workstation or server is set to

loopback processing by examining the registry
key HKLM\Software\Policies\
Microsoft\Windows\System. If the key
contains the UserPolicyMode value and its
set to a value of 1 or 2, loopback processing
is active on the computer.

The wrong
GPOs are
being
processed

A GPO could be linked to a container

that you dont expect.

Sometimes an administrator inadvertently

links a GPO to a container that it wasnt
intended to be linked to. If so, your users and
computers in the Finance OU could receive a
lockdown policy from your Help Desk OU. You

151

Chapter 6

Problem

Probable Cause

Potential Solutions
can use the Group Policy MMC snap-ins Link
Search feature to find all of the links to a
particular GPO: In the Active Directory Users
and Computers MMC snap-in, select a
container object such as a domain or OU,
right-click it, then choose Properties from the
shortcut menu. Click the Group Policy tab and
highlight the GPO that you want to search for
links to. Click Properties, then the Links tab.
Select the domain in which you want to
search for links, then click Find Now. All links
to the GPO are displayed (see Figure 6.4).

No GPO
processing is
occurring

Your users or computers may not be

receiving any GPOs. There are a few
possible reasons for this, including:
The trust relationship between a
computer and the domain is broken,
so no GPOs can be processed. (In
this case, the user cant log on to the
domain either.)
Domain Name System (DNS) nameresolution problems are preventing a
client machine from resolving domain
controller services required for GPO
processing.
Large-scale AD or NTFRS replication
problems are causing GPO
synchronization problems.

You can validate the trust between a

computer account and its domain using the
nltest.exe utility with the following syntax:

nltest /server:<machine name>

/sc_query:<domain>
Where <machine name> is the name of the
workstation or server whose trust connection
youre trying to validate and <domain> is the
domain name youre trying to validate with.
You can also use the netdom.exe utility using
the form:

netdom verify <machine name>

/domain:<domain>
If DNS problems might be preventing proper
resolution of domain controllers and thus
GPOs, use netdiag.exe in the Win2K Support
Tools to troubleshoot DNS problems. (See
Using GPO Troubleshooting Tools later in
this chapter.)
If the problem has to do with AD or NTFRS
replication, use replmon.exe to view problems
with these infrastructure services that might
be affecting GPO processing.

Table 6.1: Common GPO problems, their causes, and solutions.

152

Chapter 6

Figure 6.1: Enabling the Administrative Template policy to limit the amount of time that GPO-based scripts
(logon, startup, and shutdown) will run.

Figure 6.2:Using the History key in the registry to verify what version of the GPO ran most recently.

153

Chapter 6

Figure 6.3: Using policy to ensure that a CSE always processes a GPO, regardless of whether its changed
since the last processing cycle.

Figure 6.4: Using the Group Policy MMC snap-ins Link Search feature to find all of the links to a GPO.

154

Chapter 6

Using GPO Troubleshooting Tools

When there are problems with your GPO infrastructure, its good to have a set of tools that you
can use to help diagnose the problem. Fortunately, the Win2K resource kit and Support Tools
contain a few useful command-line and GUI-based utilities for dealing with GPO problems. In
this section, Ill describe the most useful tools and how you can use them in your own
environment. Ill also talk about the one third-party tool on the market as of this writing for
dealing with GPOsFAZAM 2000 from Full Armor.
A reduced functionality version of FAZAM 2000 is available for free from Microsoft at
//www.microsoft.com/windows2000/techinfo/reskit/tools/existing/fazam2000-o.asp.

Group Policy Result Tool (gpresult.exe)

The Group Policy Result tool (gpresult.exe) is a Win2K resource kit command-line utility that
reports on the current state of a workstation and user with respect to GPOs. It shows what GPOs
have run for the current computer and user and, to some extent, what policy settings each GPO
has provided. Figure 6.5 shows the command-line options available for gpresult.exe.

Figure 6.5: The command-line options available in gpresult.exe.

As you can see, gpresult.exe supports four options: Verbose mode (/V), Super Verbose mode
(/S), Computer Settings Only (/C), and User Settings Only (/U). There are a few differences
between Verbose mode and Super Verbose mode.

The main difference is that in Super Verbose mode, registry values that are set by
Administrative Template policy, and use the REG_BINARY data type, are fully
displayed; in Verbose mode, the contents of binary registry values arent displayed

In Super Verbose mode, any applications made available using Software Installation
policy are listed, whereas in Verbose mode, theyre not

In Verbose mode, each GPO version is listed as a single value. However, in Super
Verbose mode, the version information is broken down by GPT and GPC so that you can
see whether any synchronization problems exist between them.

155

Chapter 6
One noticeable piece of information that gpresult.exe doesnt provide is information about any
security settings that have been delivered using GPO. This is an unfortunate limitation that
makes the tool less valuable. The tool will show that you received security policy from one or
more GPOs, but it instructs you to use the security configuration and analysis MMC snap-in to
view actual security policy. Unfortunately, the security configuration and analysis snap-in
doesnt tell you which GPOs are delivering which security policy; it only tells you what effective
policy is currently running on the computer. For this more detailed RSoP functionality, you have
to turn to a tool like FAZAM 2000 from Full Armor or wait until Microsoft delivers it in the next
version of Windows.
The last two modes in gpresult.exe are Computer Settings Only and User Settings Only. They let
you display GPO policy per user or per computer, so that you can exclude one or the other from
a report. (The default is to present both). This helps minimize the amount of data the tool returns.
You can also use the /c or /u option with the /v or /s option to select the verbosity level.
In general, gpresult.exe is a good tool for giving you an overall sense of which GPOs are being
processed by the current user and computer. You cant run the tool remotely against a different
computer/user combination, but you can get some useful information out of it when you run it
locally. Figure 6.6 shows some sample gpresult.exe output. As you can see, the first part of the
report shows a lot of useful information about the computer and user running the report,
including the site the computer is in (SanFrancisco), the users distinguished name in AD
(CN=Administrator,CN=Users,DC=mar-elia,DC=com), the groups they belong to, and the
security rights they have on the domain.

Figure 6.6: Using gpresult.exe to display details of the computer and user running a report.

156

Chapter 6
The second part of the report (not shown here) lists the GPOs processed by the user and
computer, and its organized by CSE (for example, Administrative Template, Software
Installation, Folder Redirection, and so on).
The gpresult.exe tool is quite useful for identifying when a particular Administrative Template
policy is being applied because it lists individual registry entries set by a given GPO. It also
provides some summary information about each GPO, and this can be handy when youre
troubleshooting problems. This information includes things like the GPOs friendly name, its
GUID, version information, and what its linked to. This information is shown in Listing 6.1.
The user received Application Management settings from these GPOs:
Domain Software Installation Policy (v1.0)
Revision Number:13 (Active Directory) 13 (Sysvol)
Unique Name:{7D48C869-4882-40D7-A2A7-97193664F282}
Domain Name:mar-elia.com
Linked to:Domain (DC=mar-elia,DC=com)

Listing 6.1: The output of gpresult.exe, displaying information about a GPO.

While gpresult.exe isnt a full-featured RSoP tool, itll do in a pinchsuch as when you need to
find out whats happening on a workstation or server right now.
Group Policy Object Verification Tool (gpotool.exe)
The Group Policy Object Verification tool (gpotool.exe) in the Win2K resource kit, is valuable
for ensuring that your GPO infrastructure is functioning properly. Rather than focusing on the
effects of GPOs on a single workstation or user, as gpresult.exe does, gpotool.exe surveys all
GPOs in a given domain and ascertains their health. It does this by querying each domain
controller in a domain and verifying whether the GPT and GPC are in sync (that is, of the same
version). If not, it reports errors.
gpotool.exe also provides a bit more control over the scope of the search using a number of
command-line options. These are shown in Figure 6.7 and listed below.

Figure 6.7: The command-line options for gpotool.exe.

/gpo Searches for a particular GPO, rather than all GPOs.

157

Chapter 6

/domain:nameSearches in a domain other than the one in which its runningthat is,
you can perform cross-domain consistency checks on GPOs.

/dc Searches on a particular domain controller, or in a list of domain controllers, rather

than in all of the domain controllers in a domain.

/checkaclIs supposed to validate whether the permissions on the GPT for a given GPO
are consistent with those on the GPC. However, in tests that I ran using this option, after
changing permissions on a GPT for a GPO, gpotool.exe registered no problems
whatsoever. So my guess is that this feature wasnt quite implemented!

/verboseInstead of merely reporting back that GPOs are OK, lists version and other
information on all GPOs that you report on. Listing 6.2 shows an example of the verbose
output on a GPO reported by gpotool.exe.

Policy {BB5758D9-30FF-4BC5-A262-482321D9F928}
Policy OK
Details:
DC: yquem.mar-elia.com
Friendly name: HQ Lockdown Policy
Created: 3/11/2001 2:52:04 AM
Changed: 5/1/2001 3:39:56 AM
DS version:
3(user) 4(machine)
Sysvol version: 3(user) 4(machine)
Flags: 0
User extensions: [{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE-702011D2-842D
00C04FA372D4}][{A2E30F80-D7DE-11D2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-0
0A0C90347FF}]
Machine extensions: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957D509E-11D1-A
7CC-0000F87571E3}]
Functionality version: 2

Listing 6.2: Finding information about a GPO using the verbose option in gpotool.exe.

In this listing, gpotool.exe reports the following on the HQ Lockdown Policy GPO:

That the policy is OK

The details of the domain controller on which the policy was found

The friendly name for the policy, when it was created and last changed, and its current
GPC (DS) and GPT (Sysvol) versions

The Flags field shows whether user or computer policy settings have been disabled on the
GPO. In the previous listing, a value of 0 indicates that both computer and user settings
are enabled on this GPO.

The User and Machine extensions fields show the GUIDs of the CSEs used in this GPO
(or example, the GUID {A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B} corresponds
to the IE Maintenance CSE, which has been set in this GPO)

158

Chapter 6

The functionality version corresponds to the version of the Group Policy snap-in tool that
was used to create this GPO.

Lets look at an example of how gpotool.exe finds problems in an environment. Lets say you
suspect that there is a problem with the HQ Lockdown Policy GPO on one of your domain
controllers. Using the tool with the following syntax, you can zero in on the problem:
gpotool /gpo:HQ Lock /dc:yquem

You use the /gpo option to search for this GPO. You dont need to enter the entire GPO friendly
name; you can enter just the first few characters. (You cant enter another part of the name, such
as Lockdown.) You also use the /dc option to specify a domain controller by the name of Yquem,
which is where you want to focus your reporting. Figure 6.8 shows the output of this command.

Figure 6.8: Locating an error in a GPO using gpotool.exe.

This figure shows that there is a problem on this GPO because the version on the GPT (196613)
is different than the version on the GPC (196612). In this case, because the version on the GPT is
greater, you might infer that AD replication problems on this domain controller are preventing
the latest GPO changes from replicating to the GPC. A quick look in the AD event log on this
server should confirm such a problem.
Network Connectivity Tester (netdiag.exe)
Another useful Win2K resource kit utility is Network Connectivity Tester (netdiag.exe). This tool
has many capabilities, but its basically designed to validate that all network-related aspects of
your Win2K device are functioning correctly. Netdiag.exe can do everything from checking the
status of your network cards to verifying that all of the correct DNS entries are registered for a
given domain controller. If youre having a problem like that described in Table 6.1, where none
of the GPOs for a given computer or user in your domain are being processed, this is the tool to
use.

159

Chapter 6
Netdiag.exe detects problems with modems, network interface cards (NICs), infrared portsyou
name it, this tool finds it. It even has a facility to fix certain basic problems (for example, DNS
registrations that are missing). In Debug mode, the tool lists an amazing array of data, including
routing information on each NIC installed, current Transmission Control Protocol (TCP) ports
connected or listening on, detailed AD configuration information, and so on. Its range is really
quite extensive. Listing 6.3 shows all of the tests that netdiag.exe can perform.
Ndis - Netcard queries Test
IpConfig - IP config Test
Member - Domain membership Test
NetBTTransports - NetBT transports Test
Autonet - Autonet address Test
IpLoopBk - IP loopback ping Test
DefGw - Default gateway Test
NbtNm - NetBT name Test
WINS - WINS service Test
Winsock - Winsock Test
DNS - DNS Test
Browser - Redir and Browser Test
DsGetDc - DC discovery Test
DcList - DC list Test
Trust - Trust relationship Test
Kerberos - Kerberos Test
Ldap - LDAP Test
Route - Routing table Test
Netstat - Netstat information Test
Bindings - Bindings Test
WAN - WAN configuration Test
Modem - Modem diagnostics Test
Netware - Netware Test
IPX - IPX Test
IPSec - IP Security Test
Listing 6.3: A list of tests available in netdiag.exe.

For the purposes of troubleshooting GPOs, the tests of interest are the DNS test and domain
membership test. The DNS test verifies that a server, workstation, or domain controller is
correctly registered with its DNS servers, while the domain membership test ensures that the
membership between the device where the utility is being run and the domain is valid.
The syntax for performing just the DNS test is as follows:
netdiag /test:DNS

or for verbose output:

netdiag /v /test:DNS

The results of this test are shown in Figure 6.9.

160

Chapter 6

Figure 6.9: Running the DNS test using netdiag.exe.

I ran this utility from a domain controller in my domain. Note that netdiag.exe runs a number of
tests by default without explicitly specifying them (for example, the domain membership and
NetBT transports test). As you can see at the end of the output, the DNS test failed with errors
indicating missing entries on the DNS server that Im pointing at. At this time, I can wait to see
if the missing entries replicate from another DNS server, or I can use netdiag.exes /fix option to
try and fix the problem.
The /fix option compares the records registered by the domain controller in DNS with the ones
that should be registered; theyre well known for a given domain controller in a domain. If it
finds one or more records missing, it registers them for the server. The syntax for this command
is:
netdiag /fix

Listing 6.4 shows the results reported by netdiag.exe after I ran this command on my domain
controller with the DNS problem.
DNS test . . . . . . . . . . . . . : Failed
[FIX] re-register DC DNS entry _ldap._tcp.SanFrancisco._sites.marelia.com.
on DNS server 192.168.1.151 succeed.
FIX PASS - netdiag re-registered missing DNS entries for this DC
successful
y on DNS server 192.168.1.151.
[FATAL] No DNS servers have the DNS records for this DC registered.
Listing 6.4: The output of the netdiag.exe /fix option.

161

Chapter 6
This listing shows that netdiag.exe was able to fix the missing DNS entry, which was in the
_tcp.SanFrancisco._sites.mar-elia.com zone.
Software Installation Diagnostics (addiag.exe)
Software Installation Diagnostics (addiag.exe) is another Win2K resource kit utility that
provides a wide range of troubleshooting functionality related to GPOs and, more specifically, to
Software Installation in GPOs. This utility is a veritable treasure trove of functionality. It
provides not only detailed information on applications that have been installed using GPO-based
Software Installation but also general GPO information, such as GPO history (GPO version
numbers registered during the last policy-processing cycle).
This tool also lets you enable some Software Installationrelated logging using command-line
options. Normally, you must enable this logging using Administrative Template policy or
registry hacks on a given computer. Lets take a look at how you can use addiag.exe to
troubleshoot GPO-based Software Installation issues. Lets suppose you want to find out what
applications have been installed using Software Installation on a particular workstation. The
following syntax will provide the answers youre looking for:
addiag /test:ServerApps

This form of the command will dump a list of applications installed for both the computer and
the user using GPO-based Software Installation. Figure 6.10 shows an example of the output for
this command.

Figure 6.10: Checking for GPO-deployed applications using addiag.exe.

162

Chapter 6
Figure 6.10 shows the following information:

The GPOs GUID, friendly name, which is Domain Software Installation Policy (v1.0),
and the applications it deploysMicrosoft Office 2000 SR-1 Premium and the Win2K
Administration Tools.

Each installed application, along with its object GUID, its unique product code, and the
options, or package flags, which the administrator chose when the application was
deployed. For example, in the previous figure the Win2K Administration Tools
application was assigned on a per-user basis. In addition, I enabled the option to have the
application installed by a file-extension association (OnDemandInstall in the figure) was
also checked.

The OrphanOnPolicyRemoval flag means that the administrator chose not to have the
application uninstalled when the GPO carrying that application no longer applies to this
user.

Another feature of addiag.exe that I mentioned earlier is its ability to enable various logging
features related to Software Installation on a Win2K device. Using the /trace option, addiag.exe
lets you enable four types of logging. Table 6.2 lists these options and describes what they do.
Ill discuss logging further in Enabling GPO Logging later in this chapter.
Trace Option

Description

AppmgmtOn

Enables a log file in %systemroot%\debug\usermode called appmgmt.log that

performs extensive logging during a GPO-based Software Installation operation.

CstoreOn

Provides additional verbose logging for the AppmgmtOn option.

MSIOn

Turns on Windows Installer logging to log the actual installation steps of a

Windows Installer application. Enabling this option creates log files in either
%systemroot%\temp or %temp% with names like msi*.log for each application
that is installed per computer or per user, respectively. Note that this is the same
logging that is enabled using the Administrative Template policy item called
Logging under Computer Configuration, Administrative Templates, Windows
Components, Windows Installer.

UserEnvOn

Enables verbose logging of GPO and user-profile processing to the

%systemroot%\debug\usermode\userenv.log file.

Table 6.2: The trace logging options that are available in addiag.exe.

Addiag.exe is a useful tool for providing information on your GPO-based software installations.
But sometimes you just need to know what policies are being applied to a particular computer or
user. This is where a tool like FAZAM 2000 comes in handy.
FAZAM 2000
FAZAM 2000 from FullArmor Corporation (http://www.fullarmor.com/) performs several GPOrelated functions, including letting you calculate RSoP and manage all of your domain GPOs
from a single interface. Ill talk more about these features in Managing GPOs later in this
chapter. In this section, Ill focus on this tools troubleshooting capabilities.
Two main features provide diagnostics. The first is a simple function in the Auditing and
Diagnostics module called Client Side Auditing. This tool, shown in Figure 6.11, provides a

163

Chapter 6
filtered view of the application event log, showing only events related to GPO processing. This
makes it easier to scan the event log for interesting events.

Figure 6.11: Using the Client Side Auditing feature in FAZAM 2000 to show events related to GPO processing.

The other feature in FAZAM 2000 is its ability to perform remote diagnostics. Its like a
graphical version of gpresult.exe, but it can also provide information on remote computers and
users. Specifically, you connect to a computer of interest using the remote diagnostics feature,
then FAZAM 2000 displays all of the GPOs and their current policy settings for the currently
logged-on user and selected computer. This feature is handy for pointing out when you might
have conflicting policy settings among several GPOs being applied to a given user or computer.

Enabling GPO Logging

When you troubleshoot problems with a GPO infrastructure, there is fortunately no shortage of
logging available. Unfortunately, it has some disadvantages: Its scattered amongst several
different log files on a given Win2K device; in some cases, it must be enabled manually on each
device; and it requires the interested parties to collect each set of logs from each individual
device theyre interested in troubleshooting. Nevertheless, when you need the information, its
good to know how to get to it. This section will describe where and how GPO logging occurs
and how you can enable it to your benefit.
The following list describes the main types of logs available for this purpose:

164

Chapter 6

Application event logsPerform high-level logging of GPO processing per workstation

or server

%systemroot%\debug\usermode log filesText files that display very in-depth

information about GPO and user-profile processing

Windows Installer log filesFor Software Installation specifically, log applicationinstallation details for applications deployed using Group Policy.

The Application Event Log

Of the previous bullet points, the application event log is the first point of entry into any GPOtroubleshooting operation. By default, extended logging isnt enabled, so you have to enable it
explicitly on every workstation or server on which you want to capture events. To enable event
logging for GPO and related functions, you need to edit the registry to add a series of keys and
values. All of these logging entries reside in the Diagnostics key. It isnt present by default on a
Win2K computer, so you must create it manually under the following registry path:
HKLM\Software\Microsoft\Windows NT\CurrentVersion

Once you create the Diagnostics key under CurrentVersion, you need to add values particular to
the type of logging you want to carry out. Table 6.3 describes the required values and what kinds
of logging they perform.
Registry Value (Name, Type, Value)

Logging Capability

RunDiagnosticLoggingGlobal
REG_DWORD = 0x1

Logs all Group Policyrelated processing, including

Folder Redirection, RIS policy, Software Installation
policy, and so on in the application event log in
verbose mode.

RunDiagnosticLoggingGroupPolicy
REG_DWORD= 0x1

Logs only high-level GPO processing step by step.

RunDiagnosticLoggingIntellimirror
REG_DWORD=0x1

Logs only events related to RIS policy.

RunDiagnosticLoggingAppDeploy
REG_DWORD= 0x1

Logs only events related to GPO-based Software

Installation.

Table 6.3: The registry values required to enable event-log auditing of GPOs.

Once youve enabled event logging, the application event log generates a new log entry for each
step that a computer and user go through as they process their applicable GPOs.
You can create a custom .adm template file to enable GPO application event logging on all
computers in your Win2K infrastructure. The following .adm template snippet will add the
RunDiagnosticLoggingGlobal flag to computers that process the GPO that contains it:
CLASS MACHINE
CATEGORY !!Custom
POLICY !!GPOLogging
KEYNAME Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
EXPLAIN !!GPOLogging_Help
VALUENAME RunDiagnosticLoggingGlobal
165

Chapter 6

VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END POLICY
END CATEGORY ; Custom
[strings]
GPOLogging=Enable Verbose GPO Logging
GPOLogging_Help=By enabling this policy, you are turning on verbose logging of all GPO events in
the application event log
Custom=Custom Preference

You can actually scroll through each event log to follow which GPOs are processed and whether
any high-level errors are generated during a particular step. Figure 6.12 shows an example of one
such event-log entry after enabling verbose global logging.

Figure 6.12: Viewing a log entry after enabling GPO logging.

GPO-related events typically appear in the application event log from one of three sources. Each
source represents a different set of policy processing.

UserenvThe event source responsible for enumerating the applicable GPOs and
figuring out which ones apply or dont, as shown in Figure 6.12

Application ManagementShows software-installation events

166

Chapter 6

ScecliRepresents security policyprocessing events

In some cases, a log event might return some fairly obscure error messages, which you may find
no help at all. Listing 6.5 shows the text returned by one such event.
The Group Policy client-side extension Security was passed flags (17)
and returned a failure status code of (5).
Listing 6.5: An error message returned by the application event log during GPO processing.

How do you know what these flags and status codes mean? The flags refer to error messages that
are part of the Win2K DLL responsible for handling much of the processing of GPOs and user
profiles, userenv.dll. The actual error codes can be found in the header file for this DLL
userenv.h in the Microsoft Platform Software Developer Kit (SDK).
Table 6.4 shows the values and a description of the flags related to GPO. These flags are given in
hexadecimal (hex) values, but the event log shows decimal values, so you need to convert them.
Flag Value in Hexadecimal
(and Decimal)

Description

0x00000001 (1)

The policy being applied is a computer-based (not user) policy.

0x00000010 (16)

This is a background refresh of policy. (That is, its not happening as a

function of a user logging on or a computer starting up.)

0x00000020 (32)

The policy is currently being applied across a slow link.

0x00000040 (64)

The policy is set to output status in verbose mode to the event log.

0x00000080 (128)

No changes were detected for this GPO from the last processing
cycle.

0x00000100 (256)

The network-link speed has changed between the last time the policy
was processed and the current processing cycle.

Table 6.4: The flags that are shown in GPO-specific event-log entries.

The values shown in the event log, like the ones in Listing 6.5, are displayed in decimal notation
and are calculated using a bitwise operation on the relevant flags shown in Table 6.4. For
example, Listing 6.5 shows a flag value of 17. You do a bitwise OR operation on the 0x1 and
0x10 flags shown in the table to obtain the hex value, which is 11. Thus, the flag value of 17
indicates that the policy being reported on is a computer policy and that its a background refresh
event, as opposed to a policy that is processed when a user logs on or a computer starts up.
The failure status codes shown in Listing 6.5 are simply Win32 error codes. You can figure out
what those errors are by looking in the winerr.h header file in the platform SDK or simply typing
the following at a command prompt:
Net helpmsg <#>

where <#> is the decimal error code. In Listing 6.5, Win32 error code 5 is Access Denied.
Usermode Logs
Usermode logs are a set of log files that you can activate in the %systemroot%\debug\usermode
folder on a Win2K system. Depending on what youve activated, this folder contains several log
files of interest. These logs provide very detailed logging of what is actually happening during

167

Chapter 6
GPO processing. If you dont obtain the information that you need from the application event
log, these usermode logs are your next point of investigation.
The userenv.log File
The main log file that contains detailed trace information on GPO and user-profile processing is
userenv.log. This file is created by default when you install Win2K, but to enable verbose
logging of policies and profiles, you need to set the following registry value:
HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\Userenvdebuglevel= REG_DWORD 0x10002

Scanning through the userenv.log file to troubleshoot GPO problems can be a tedious process.
This log file is very low-level, so to find what youre looking for, you need to exercise patience.
Figure 6.13 shows an example of the output from this log, with verbose logging enabled.

Figure 6.13: The output of the userenv.log file with verbose logging enabled.

Youll immediately notice a couple of things about the userenv.log file. First, no event dates are
shown, only times. This means that you have to guess that the most recent events occurred on the
current day. Next, the log file is filled, as youd expect, from top to bottom, so newer events are
at the end, not the beginning, of the file.
The figure shows some useful information. First, you see that GPO processing starts at
23:03:19:260. At 23:03:19:280, you see an operation called PingComputer. This is where the
workstation processing the GPO tests its network connection to the domain controller that is
providing that GPO. If the workstation detects a fast link, as is shown here, normal policy
processing occurs. If it detects a slow link, this is where you can discover it, and then see which
CSEs are being skipped as a result.

168

Chapter 6
Figure 6.14 shows the output a little further on in this log. It shows how each GPO is evaluated
to determine whether anything has changed since the last processing and, if something has
changed, which CSE has to process which GPO.

Figure 6.14: The userenv.log file also shows how GPOs are processed.

At the top of the figure, you see that a GPO has been found, that the computer processing it has
access to it, and that its friendly name (display name) is Default Domain Controllers Policy.
After all GPOs are found that are applicable to this computer and user, each CSE then figures out
which GPOs it needs to process and does so in turn. You see this towards the bottom of the
figure, where the following are processed sequentially: the registry extension (that is,
Administrative Templates), Folder Redirection, disk quota, then scripts.
Other Log Files
You can enable other logs in the usermode folder to provide additional troubleshooting. These
additional logs, and the registry values required to enable them, are shown in Table 6.5 below.
Log Function

Needs This Registry Value to Enable This Log

Enable logging during GPO editing

(client-side errors only) produces
gpedit.log

HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPEditDebugLevel = REG_DWORD
0x10002

Enable logging of the loading of

.adm template files from the GPT
produces gptext.log

HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPTextDebugLevel =
REG_DWORD 0x10002

Enable logging of Folder

Redirection processing produces
fdeploy.log

HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Diagnostics\FdeployDebugLevel=
REG_DWORD 0x0f

Enable logging of Software

HKLM\Software\Microsoft\Windows
169

Chapter 6
Installation processingproduces
appmgmt.log

NT\CurrentVersion\Diagnostics\AppmgmtDebugLevel=
REG_DWORD 0x9b

Table 6.5: Enabling usermode logging of various GPO-based policy.

Windows Installer Logging

The last area of logging that Ill mention are the logs related to Windows Installerbased
application installations. If you plan to use the Software Installation feature in Group Policy to
deploy applications that have been packaged using the Windows Installer (.msi) technology,
youll want to enable some amount of logging on your Win2K systems.
Unlike the application event logs or usermode logs, however, which you need to enable using
manual registry hacks, you can enable Windows Installer logging using an existing
Administrative Template policy. Specifically, in Computer Configuration, Administrative
Templates, Windows Components, Windows Installer, a policy item called Logging lets you
enable verbose logging of .msi-based application installations. Figure 6.15 shows an example of
enabling this policy.

Figure 6.15: Enabling verbose Software Installation logging using Administrative Template policy.

Depending on how much verbosity you need, you can choose a number of different levels of
logging. After enabling logging on a Win2K system, application-installation logs are stored in
one of two places:

%systemroot%\tempWhen a GPO-deployed .msi-packaged application is installed

from the computers security context (for example, if the application was a computerbased assignment)

170

Chapter 6

%temp% (the users temporary folder)When the installation is triggered by a user.

In Software Installation Diagnostics (addiag.exe) earlier in this chapter, I mentioned that you
can also enable Software Installation logging using addiag.exe. It does the same thing as
Administrative Template policy, shown in Figure 6.15. However, addiag.exe doesnt give you a
choice of the logging level; it enables all logging. Each application installation generates its own
unique log file, which has a name using the form msi*.log, where * is some unique set of
hexadecimal characters.
As Figure 6.16 shows, the contents of a Software Installation log file are fairly esoteric. Unless
you have some in-depth knowledge of how the Windows Installer technology works, your best
bet is to log only errors. That will give you a better chance of discovering problems without
having to wade through a lot of unrelated messages.

Figure 6.16: The output of a Windows Installer log file.

Managing GPOs
Now that Ive discussed all the ways that you can instrument your GPO infrastructure to
discover and troubleshoot problems, lets look at some of the more day-to-day management
challenges that youre likely to face and ways to handle them.
Managing your GPO infrastructure involves a number of key tasks, which fall outside the scope
of basic troubleshooting, including:

Planning for new GPOs and seeing their potential effect on users and computers in a
forest

Backing up and restoring individual GPOs in a forest

Viewing the current effective policy for a given workstation

Scripting GPO creation and editing

171

Chapter 6
Some of these capabilities are available out-of-the-box, but most of them either dont exist yet or
are available with third-party tools. In this section, Ill talk about each of these capabilities and
how you can achieve them using available techniques and tools.
RSoP
Ive referred to the idea of RSoP several times in this book. RSoP is the ability to view and plan
for the effects of GPOs on a particular user-and-computer combination. You need to perform
real-time analysis of the effects of multiple GPOs on a given user or computer in a given OU or
domain. You also need to be able to perform what-if scenarios before you move a user or
computer to a new OU or change its group membership. Its these two requirements that really
encompass RSoP.
In Group Policy Result Tool (gpresult.exe) earlier in this chapter, I described how the
gpresult.exe utility, to a small degree, lets you view the current effective policy on a given user
and computer. However, you cant run this tool against remote computers easily, and it cant
help you if you want to perform what-if scenarios on future changes.
This is where RSoP tools like FAZAM 2000 come in. FAZAM 2000 has a planning and analysis
module that lets you create what-if scenarios and experiment with the effects of moving a user or
computer into new OUs or new groups (or removing them from groups). Figure 6.17 shows an
example of the kinds of scenarios you can create with FAZAM.

Figure 6.17: Creating a scenario using the what-if planning feature in FAZAM 2000.

In this figure, Im asking the tool to tell me what my effective policy will be if the user account
for user Darren Mar-Elia, logged on to the computer called Yquem, is added to the HQ Users
group. Im also telling the tool to include in the calculation site-based policy for the San
172

Chapter 6
Francisco site and the local GPO. Once I complete the scenario, FAZAM calculates my new
effective policy settings and reports three things.

User hierarchyWhich GPOs apply to the chosen user from which containers

Computer hierarchyWhich GPOs apply to the chosen computer from which containers

Resultant policyWhat the effective policy settings are at the computer and for the user.

Figure 6.18 shows the results of this analysis.

Figure 6.18: The results of an RSoP analysis in FAZAM 2000.

As you can see in this figure, Darren Mar-Elia at Yquem is the scenario I established, and the
resulting user and computer policy hierarchies are shown in the scope pane on the left. The
results pane on the right shows a portion of the individual policy settings that the user and
computer in my scenario will receive. From this information, I can determine what effect adding
my user account to the HQ Users group will have.
You can see that if you have a large GPO infrastructure and are making frequent changes to both
GPOs and users or computers, this kind of functionality can be very useful. Microsoft has plans
to provide some RSoP tools in the next version of Win2K, but for now, youll need to rely on
tools like FAZAM 2000 to provide this valuable capability.
Backing Up and Restoring GPOs
Another function missing from the Win2K product line is the ability to easily back up and restore
individual GPOs. You can, of course, use backup utilities to back up the System State on a given

173

Chapter 6
domain controller, including AD and SYSVOL. Unfortunately, the restore process isnt granular
and doesnt allow you to restore selective parts of these elements.
Remember that a GPO consists of two partsthe GPC and the GPT. This means that a backup
utility needs to back up both AD and SYSVOL components for a particular GPO, then restore
them, while maintaining any unique elements of that GPO. In addition, because container objects
like sites, domains, and OUs link to a GPO by its GUID, you need to ensure that when the
backup utility restores a GPO, it re-creates its original GUID in AD. Otherwise, you have to relink container objects to the new GPO.
Fortunately, FAZAM 2000 (and the reduced functionality version, called FAZAM 2000 RFV,
that comes in the Win2K resource kit) provides a backup and restore capability that lets you back
up individual GPOs to a file system, then restore them to the original domain or, what is more
interesting, to other domains and even other forests. Figure 6.19 shows FAZAM 2000s backup
capability.

Figure 6.19: Using the backup capability in FAZAM 2000.

The Role of the Local GPO

Throughout this book, Ive focused mostly on AD-based GPOs because this is where most of the
power and features of Group Policy are enabled. However, as I finish this chapter and this book,
I want to talk about the role of the local GPO in Win2K.
As I mentioned earlier in this book, the local GPO is stored on every Win2K device in the
%systemroot%\system32\GroupPolicy folder. The local GPO is processed first, before site,
domain, or OU policies, so settings that are specified in the local GPO are overwritten by GPOs
processed later. However, the local GPO can be useful in a number of different scenarios, so Ill
describe how it works and how to manage it.
The easiest way to open a local GPO on a workstation or server is to choose Start, Run, then in
the Run dialog box, type gpedit.msc. This starts a pre-created Group Policy MMC snap-in tool
that is focused on the local GPO. The first thing youll notice about the local GPO is that it

174

Chapter 6
doesnt support a few of the policy functions that are present in AD-based GPOsfor example,
Software Installation or Folder Redirection policy.
Despite these limitations, local GPOs do provide some interesting capabilities. First, if you dont
have an AD infrastructure supporting your Win2K devices, you can of course use local GPOs to
manage policy. The challenge here is to manually edit each local GPO on each workstation or
server in your enterprise to set local policy. Well, thats not exactly the case.
Because local GPOs are stored in the local Win2K file system, and not spread across AD and
SYSVOL, you can simply copy the contents of the %systemroot%\system32\GroupPolicy folder
from one computer to the next, and the policy settings that you set on the source are used by the
destination. This makes it easy to set local GPO policy the way you want on one computer, then
clone it to all of the other Win2K devices without using special tools.
Another neat thing about local GPOs is that you can use them to view the effective security
policy on a given computer. For whatever reason, Microsoft decided to provide this view of
effective policy in the Security Settings node in the Group Policy MMC snap-in but not in any
other nodes. The local GPO shows a view of the local security setting compared to the effective
settingsthose that are being enforced by AD-based GPOs. You can see this in Figure 6.20
below.

Figure 6.20: Viewing the effective security policy compared to local security policy in a local GPO.

In this figure, the Local Setting column shows what audit policy has been set in the local GPO
in this case, none. However, based on information received from AD-based GPOs that this
computer has processed, the Effective Setting column says what the current audit policy really is
for this computer. This can come in handy when youre trying to troubleshoot security-related
problems in your AD infrastructure. Unfortunately, however, there is no way to know which
175

Chapter 6
AD-based GPO delivered these auditing settings to the computer. This is where a more fullfeatured RSoP tool comes in handy.

Summary
In this chapter, I started by discussing some of the most common problems youre likely to
encounter in your GPO infrastructure. Then I moved on to describe useful tools for
troubleshooting GPOs. From there, I examined the multitudinous logging options available to
you to keep track of what your GPOs are really up to. Finally, I discussed some of the
management issues with AD and local GPOs and the tools that you can use to address them.
Id like to thank you all for reading and supporting this book, and I hope its been as useful for
you to read as it was fun for me to write!

176

Appendix A

List of Acronyms and Abbreviations

Acronym

Meaning

ACE

access control entry

ACL

access control list

AD

Active Directory

API

application programming interface

CA

Certificate Authority

COM

Component Object Model

CRL

certificate revocation list

CSE

client-side extension

CTL

certificate trust list

Dfs

distributed file system

DHCP

Dynamic Host Configuration Protocol

DLL

dynamic-link library

DN

distinguished name

DNS

Domain Name System

EFS

Encrypting File System

GPC

Group Policy Container

GPO

Group Policy Object

GPT

Group Policy Template

GUID

globally unique ID

ICS

Internet Connection Sharing

IE

Internet Explorer

IEAK

Internet Explorer Administration Kit

IP

Internet Protocol

IPSec

IP Security

ISV

independent software vendor

LDAP

Lightweight Directory Access Protocol

LSDOU

Local, Site, Domain, OU

MMC

Microsoft Management Console

NIC

network interface card

NTFRS

NT File Replication Service

NTFS

NT File System

OS

operating system

OU

organizational unit

PDC

primary domain controller

PKI

public key infrastructure

RAS

Remote Access Service

177

Appendix A
RIS

Remote Installation Services

RSoP

Resultant Set of Policy

SAM

Security Accounts Manager

SCM

Service Control Manager

SDK

Software Developer Kit

SMS

Systems Management Server

TCO

total cost of ownership

TCP

Transmission Control Protocol

UI

user interface

UNC

Uniform Naming Convention

WFP

Windows File Protection

Win2K

Windows 2000

WSH

Windows Script Host

WTS

Windows Terminal Server

178