realtimepublishers.

com
tm

Tips and Tricks Guide To

tm

Windows 2000
Group Policy

Darren Mar-Elia
Introduction

By Sean Daily, Series Editor

Welcome to The Tips and Tricks Guide to Windows 2000 Group Policy!
The book you are about to read represents an entirely new modality of book publishing and a
major first in the publishing industry. The founding concept behind Realtimepublishers.com is
the idea of providing readers with high-quality books about today’s most critical IT topics—at no
cost to the reader. Although this may sound like a somewhat impossible feat to achieve, it is
made possible through the vision and generosity of corporate sponsors such as FullArmor, who
agree to bear the book’s production expenses and host the book on its Web site for the benefit of
its Web site visitors.
It should be pointed out that the free nature of these books does not in any way diminish their
quality. Without reservation, I can tell you that this book is the equivalent of any similar printed
book you might find at your local bookstore (with the notable exception that it won’t cost you
$30 to $80). In addition to the free nature of the books, this publishing model provides other
significant benefits. For example, the electronic nature of this eBook makes events such as
chapter updates and additions, or the release of a new edition of the book possible to achieve in a
far shorter timeframe than is possible with printed books. Because we publish our titles in “real-
time”—that is, as chapters are written or revised by the author—you benefit from receiving the
information immediately rather than having to wait months or years to receive a complete
product.
Finally, I’d like to note that although it is true that the sponsor’s Web site is the exclusive online
location of the book, this book is by no means a paid advertisement. Realtimepublishers is an
independent publishing company and maintains, by written agreement with the sponsor, 100%
editorial control over the content of our titles. However, by hosting this information, FullArmor
has set itself apart from its competitors by providing real value to its customers and transforming
its site into a true technical resource library—not just a place to learn about its company and
products. It is my opinion that this system of content delivery is not only of immeasurable value
to readers, but represents the future of book publishing.
As series editor, it is my raison d’être to locate and work only with the industry’s leading authors
and editors, and publish books that help IT personnel, IT managers, and users to do their
everyday jobs. To that end, I encourage and welcome your feedback on this or any other book in
the Realtimepublishers.com series. If you would like to submit a comment, question, or
suggestion, please do so by sending an email to feedback@realtimepublishers.com, leaving
feedback on our Web site at www.realtimepublishers.com, or calling us at (707) 539-5280.

Thanks for reading, and enjoy!

Sean Daily
Series Editor

i
Note to Reader: This book presents tips and tricks for eight Windows 2000 and Windows XP
Group Policy topics. For ease of use, the questions and their solutions are divided into chapters
based on topic, and each question is numbered based on the chapter, including:
• Chapter 1: GPOs vs. NT 4.0 System Policies
• Chapter 2: How GPOs Work
• Chapter 3: Creating and Editing GPOs
• Chapter 4: Designing a GPO Infrastructure
• Chapter 5: Administering and Delegating GPOs
• Chapter 6: Tools for Managing GPOs
• Chapter 7: Advanced GPO Features and Functions
• Chapter 8: Troubleshooting GPOs.
Introduction...................................................................................................................................... i
By Sean Daily, Series Editor ................................................................................... i
Chapter 1: GPOs vs. NT 4.0 System Policies..................................................................................1
Q 1.1: What are the principal differences between Windows 2000 and Windows XP Group
Policy and Windows NT 4.0 System Policy? ..................................................................................1
Flexibility.............................................................................................................................1
Ease of Administration ........................................................................................................3
Administrative Tools ...........................................................................................................4
Q 1.2: What is registry tattooing, and how do Windows 2000 and Windows XP Group Policy
Objects prevent it from happening?.................................................................................................5
Q 1.3: How do .adm files differ between Windows NT 4.0 and Windows 2000 and Windows
XP?...................................................................................................................................................9
Q 1.4: If I’m using user groups to control policy application in a Windows NT 4.0 system policy,
how does that map to Windows Group Policy?.............................................................................14
Q 1.5: Can Windows 2000 or Windows XP clients process both Windows NT 4.0 System
Policies and Group Policy Objects?...............................................................................................19
Q 1.6: Do Group Policy Objects contain all the same policy settings that I used in Windows NT
4.0 System Policy?.........................................................................................................................20
Q 1.7: Can I still use poledit.exe to view Group Policy Objects? .................................................22
Q 1.8: Can I store my Windows NT 4.0 policies in the same place that Group Policy Objects are
stored? ............................................................................................................................................23
Chapter 2: How GPOs Work .........................................................................................................26
Q 2.1: How do I know whether my Windows 2000 or Windows XP workstation is correctly
processing Group Policy Objects that are defined in my Active Directory infrastructure? ..........26
GPO Background ...............................................................................................................26

ii
 Is Your Computer Processing GPOs?................................................................................26
GPResult ................................................................................................................26
Event Logs .............................................................................................................27
RSoP ......................................................................................................................28
Q 2.2: How does Group Policy Object security group filtering work? .........................................29
Q 2.3: What is the purpose of No Override and Block Inheritance? .............................................32
Q 2.4: How do site-linked Group Policy Objects (GPOs) work? ..................................................35
Q 2.5: Why are changes to Group Policy Objects always written first to the PDC emulator in
Active Directory?...........................................................................................................................38
Q 2.6: Can I permission a Group Policy Object such that someone can view its settings but not
edit them?.......................................................................................................................................40
Q 2.7: Is the Group Policy Object architecture extensible—can I create new types of Group
Policy Objects? ..............................................................................................................................44
Q 2.8: What is happening during background refresh of a Group Policy Object and how do I
change background refresh behavior? ...........................................................................................45
Chapter 3: Creating and Editing GPOs..........................................................................................49
Q 3.1: How can I create a Group Policy Object that is not linked to a container object? .............49
Q 3.2: How can I set account policy on a domain? .......................................................................51
Q 3.3: How do I use the restricted groups feature in Group Policy Object security policy?.........54
Q 3.4: How do I use Administrative Templates policy to lockdown my desktops?......................58
Darren’s Desktop Lockdown Rules ...................................................................................59
Q 3.5: How can I distribute Group Policy Object changes in a non-Active Directory
environment?..................................................................................................................................60
Q 3.6: How do I use Internet Explorer Maintenance policy? ........................................................63
Q 3.7: How can I use Group Policy to ensure that certain scripts are executed each time users log
off or shut down their computers? .................................................................................................66
Q 3.8: Can I use Group Policy Object-based software installation to deploy a Windows service
pack? ..............................................................................................................................................71
Chapter 4: Designing a GPO Infrastructure...................................................................................74
Q 4.1: How can I have version control for my Group Policy Objects? .........................................74
Embed Version Information in a GPO’s Friendly Name...................................................74
Create Custom .ADM Files................................................................................................75
Third-Party Tools...............................................................................................................78
Q 4.2: How many Group Policy Objects can I create in a domain before I start affecting the
performance of my workstations?..................................................................................................78
Asynchronous vs. Synchronous Processing.......................................................................78

iii
 GPOs that Don’t Change Aren’t Processed .......................................................................79
Disable Portions of a GPO that Aren’t in Use ...................................................................80
Q 4.3: How do I deal with multiple domain forests and Group Policy Objects? ..........................82
Q 4.4: How do I deal with change control in my Group Policy Object infrastructure? ................84
Q 4.5: What is the best scheme for allowing my organizational unit administrators to create and
edit Group Policy Objects? ............................................................................................................87
Q 4.6: If I have an empty forest root domain, do I need to create or use Group Policy Objects in
that domain?...................................................................................................................................90
Q 4.7: What are the challenges of “sharing” Group Policy Objects between organizational units?91
Q 4.8: Can I use the Group Policy Object-based software installation feature to replace my
existing software distribution tools? ..............................................................................................94
Chapter 5: Administering and Delegating GPOs...........................................................................97
Q 5.1: How do I delegate the ability to edit and link Group Policy Objects in Active Directory?97
Delegate GPO Editing........................................................................................................97
Delegate GPO Linking.......................................................................................................99
Q 5.2: How does the Delegation of Control wizard work for Group Policy Objects? ................101
Q 5.3: How can I prevent certain users from administering portions of my Group Policy Objects?104
Q 5.4: Can I delegate administration for just a part of a Group Policy Object?..........................106
Q 5.5: How can I audit who has made a change to a Group Policy Object? ...............................108
Q 5.6: What is the difference between deleting a Group Policy Object and deleting a Group
Policy Object link?.......................................................................................................................113
Q 5.7: How can I delegate administration of a Group Policy Object to users who reside in
different organizational units? .....................................................................................................115
Q 5.8: How can I view who has the rights to create Group Policy Objects in my domain?........116
Chapter 6: Tools for Managing GPOs .........................................................................................120
Q 6.1: How can I create customized tools for my administrators who need to manage Group
Policy Objects? ............................................................................................................................120
Create Locked Down Tools .............................................................................................120
Limit Tools Even More....................................................................................................122
Q 6.2: Can I script the creation of Group Policy Objects? ..........................................................122
Q 6.3: Which tool can I use to force Group Policy Object processing from the command line?124
Q 6.4: Can I create a tool that gives me a consolidated view of all my Group Policy Objects at
once? ............................................................................................................................................126
Q 6.5: Do I have any control over how quickly the SYSVOL (Group Policy Template) portion of
a Group Policy Object is replicated to other domain controllers? ...............................................128
Q 6.6: Can I get information about the Group Policy Objects in my domain via scripts? ..........130

iv
Q 6.7: How can I add or remove particular policy extensions within the Group Policy Object
editor tool? ...................................................................................................................................133
Q 6.8: What is the difference between the Local Security Policy tool and using gpedit.msc to edit
the local Group Policy Object? ....................................................................................................137
Chapter 7: Advanced GPO Features and Functions ....................................................................141
Q 7.1: How can I view the internals of a Group Policy Object? .................................................141
Locate the GUID..............................................................................................................141
Navigate to the GPC ........................................................................................................142
Determine the GPT ..........................................................................................................143
Q 7.2: What is loopback policy and how does it work? ..............................................................145
Q 7.3: How can I change the path to a deployed application’s .msi file once I’ve published or
assigned the application? .............................................................................................................146
Q 7.4: How do I use software restriction policy in Windows XP?..............................................150
Q 7.5: Can a client machine disable the processing of a Group Policy Object?..........................155
Q 7.6: How do I enable Windows XP policies in a Windows 2000 Active Directory domain? .157
Q 7.7: How is Group Policy Object history stored and used on the client? ................................158
Q 7.8: I’ve heard that Windows .NET Server will provide the ability to filter Group Policy
Objects using a Windows Management Instrumentation filter. What is that? ............................161
Chapter 8: Troubleshooting GPOs...............................................................................................164
Q 8.1: What is the best tool to show me whether all of my Group Policy Objects have been
replicated correctly to all domain controllers?.............................................................................164
GPOTool.exe ...................................................................................................................164
Replmon.exe ....................................................................................................................165
Q 8.2: How can I use event log entries to troubleshoot Group Policy Object problems? ...........167
Q 8.3: What is the best way to determine whether security policy is being delivered to a
workstation or server?..................................................................................................................170
Q 8.4: How can I determine whether Domain Name System problems are affecting my Group
Policy Objects’ functionality?......................................................................................................172
Q 8.5: Why am I having trouble enabling security policy such as auditing and event log settings
on my domain controllers?...........................................................................................................173
Q 8.6: Why can I sometimes view a Group Policy Object in the list of Group Policy Objects
linked to a container, but can’t edit that object? ..........................................................................175
Q 8.7: When I try to edit a Group Policy Object, I get an error message that says the domain
controller is not found. DNS isn’t the problem, what else could it be?.......................................177
Q 8.8: I’m having problems with security policy processing. Is it possible to get more in-depth
troubleshooting information than that provided by the event logs? ............................................179

v
Copyright Statement
© 2002 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 NON-INFRINGEMENT. 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: GPOs vs. NT 4.0 System Policies

Q 1.1: What are the principal differences between Windows 2000 and
Windows XP Group Policy and Windows NT 4.0 System Policy?
A: Windows NT 4.0 System Policy allows you to set registry values across users, computers,
and groups within your NT 4.0 (or Windows 2000—Win2K) domains. Win2K and Windows XP
Group Policy include a superset of NT 4.0 System Policy functionality.

Flexibility
In addition to the ability to set registry value policy—called Administrative Templates in Win2K
and Windows XP Group Policy, Group Policy Objects (GPOs) include the ability to set security
configurations, enforce Internet Explorer (IE) browser settings, distribute software applications,
and redirect elements of users’ Desktop, My Documents, and Start menu to locations other than
their user profiles. Figure 1.1 shows the Group Policy Microsoft Management Console (MMC)
snap-in, focused on a Win2K GPO.

Figure 1.1: Viewing the standard policy nodes in a Win2K GPO.

1
 Chapter 1

Although GPOs provide significantly more policy features than NT 4.0 System Policy provides,
GPOs are stored and processed differently than NT 4.0 System Policy is. In NT 4.0, the System
Policy file (often called ntconfig.pol) is stored in the Netlogon share on domain controllers
within an NT 4.0 domain. When an NT 4.0 user logs onto a workstation in an NT 4.0 domain,
the system reads the System Policy file from the Netlogon share, then sets registry values that are
specific to a computer, user, or user group according to the policy file. NT 4.0 allows only a
single policy file to be processed at a given time. NT 4.0 System Policy could apply to a specific
computer (or all computers), a specific user (or all users), or an NT 4.0 domain global group.
In contrast, GPOs are composed of two parts: the Group Policy Container (GPC), which is stored
within Active Directory (AD), and the Group Policy Template (GPT), which is stored within the
replicated SYSVOL folder on all AD domain controllers in a domain. Whereas System Policy is
processed only when a user logs onto an NT 4.0 workstation, GPOs are processed at both
machine startup (at which point machine-specific policy is processed) and user logon (at which
point user-specific policy is processed). Again, in contrast to System Policies, you can define a
virtually unlimited number of GPOs within an AD domain (though practically speaking, large
numbers of GPOs will take a long time to process). And, whereas System Policies apply to
individual users, individual computers, and NT security groups, GPOs are processed only by AD
users and computers. However, AD security groups composed of either machines or users can
filter GPOs’ effects. This filtering capability, in conjunction with the ability to have multiple
GPOs processed by a given user or computer, can provide much greater policy flexibility than is
available in NT 4.0. Figure 1.2 shows an example of how you can use security groups to filter
the effects of a GPO.

Figure 1.2: Viewing the use of AD security groups to filter the effects of a GPO.

2
 Chapter 1

Ease of Administration
A single NT 4.0 System Policy can be associated to a single NT 4.0 domain at a given time;
GPOs can be linked, or associated with an AD domain, an AD site (a collection of IP subnets), or
an AD organizational unit (OU). When a GPO is linked to a domain, site, or OU, all users and
computers that reside under those container objects in an AD infrastructure will process that
GPO. Figure 1.3 shows an example of what this setup would look like in a typical AD
infrastructure.

Figure 1.3: Viewing GPOs linked to multiple container objects in an AD infrastructure.

Note that in Figure 1.3, multiple GPOs can be linked to each container object (for example, site,
domain, or OU). The users and computers in the Sales OU, for example, would process GPOs
linked directly to that OU as well as upstream GPOs linked to the domain and any AD sites to
which the computers belong. In fact, GPO processing follows an order of precedence that helps
control which GPOs are processed first. Namely, GPOs linked to sites are processed first, then

3
 Chapter 1

those linked to domains, and finally those linked to OUs. This order of precedence is often
referred to as SDOU (as in sites, domains, then OUs).
Note that each Win2K and Windows XP device also has its own local GPO that isn’t associated
with an AD infrastructure. This local GPO is actually applied before any AD-linked GPOs.

Administrative Tools
The final significant difference between System Policy and GPOs relates to the tools you use to
create and edit each. GPO editing tools are significantly different than the Policy Editor tool
(poledit.exe) provided in NT 4.0. GPOs rely on MMC snap-ins for creation and to be edited. The
following steps walk you through how to create a new GPO:
1. From the Win2K or Windows XP Administrative Tools program group, choose the
Active Directory Users and Computers snap-in to create domain or OU-linked GPOs, or
select the Active Directory Sites and Services snap-in to create site-linked GPOs.
2. Highlight the container object (the domain, site, or OU) for which you want to create the
new linked GPO, and right-click to expose the context menu for that container.
3. Choose the Properties menu item, and in the resulting window, select the Group Policy
tab.
4. Click New. In the Group Policy Object Links dialog box, a new GPO is created and
highlighted so that you can change its name (as Figure 1.4 shows).

Figure 1.4: Adding a new GPO to your AD.

4
 Chapter 1

From this point, all you need to do is change the name of the GPO to be descriptive and, with the
GPO highlighted, click Edit to start an MMC Group Policy snap-in tool focused on your new
GPO. You can then begin making changes to the GPO.

Q 1.2: What is registry tattooing, and how do Windows 2000 and

Windows XP Group Policy Objects prevent it from happening?
A: Registry tattooing occurs when a Windows NT 4.0 System Policy makes a registry change
that is left in place even if the policy no longer applies. Tattooing is a big problem in NT 4.0
System Policy. Its effects cause a variety of problems. For example, suppose you’ve set a
number of registry settings in an NT 4.0 System Policy and you want to back them out.
Logically, you would think that you could just remove the policy file (for example, ntconfig.pol)
from the Netlogon share on your NT 4.0 domain controllers, and users would no longer get that
policy. However, such is not the case at all. In fact, the registry settings that System Policy
applies are permanent, unless explicitly un-done by a policy that reverses their effect. The effects
from these lingering registry settings are called tattooing because the registry is tattooed with
those settings.

Tattooing is the process that occurs when an NT 4.0 System Policy applies registry settings that are
not removed when the System Policy no longer applies.

Although NT 4.0 doesn’t include an easy mechanisms to undo the tattooing process, Windows
2000 (Win2K) and Windows XP both allow for registry settings to be removed when a Group
Policy Object (GPO) no longer applies to a user or computer. However, this statement is not
universally true for any registry setting that is set through the GPO Administrative Template
policy. Win2K and Windows XP differentiate between policies and something called
preferences. Policies are those Administrative Template policy settings that are set within a
particular set of registry keys:
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies
• HKEY_CURRENT_USER\Software\Policies
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies
The first two registry keys are set within computer-specific GPO Administrative Template
policy. The last two keys are user-specific. Thus, if you set policy that makes changes to values
within one of these four keys, that policy will be removed (that is, not tattooed) if the GPO that
sets the policy is no longer processed by the computer or user.
If you define an Administrative Template setting that modifies registry values outside of the four
keys, such a setting is considered a preference—preferences do tattoo the registry. Microsoft
recommends that all applications that use Group Policy-based Administrative Template policy
write their policy settings to one of the previously mentioned four keys. Thus, those settings are
placed into the registry and will be removed when the GPO no longer applies.

5
 Chapter 1

Within the Group Policy Microsoft Management Console (MMC) snap-in tool, you can filter the
view of Administrative Templates to view only policies that don’t tattoo the registry (that is,
those that make changes only to the keys listed earlier) or both policies and preferences. The
mechanism to filter the view is different between Win2K and Windows XP, but the effect is the
same. In Windows XP, from the Group Policy MMC snap-in, highlight and right-click either the
Administrative Templates node in either Computer or User configuration. From the resulting
context menu, select View, then choose Filtering from the sub-menu. The dialog box that Figure
1.5 shows will appear.

Figure 1.5: Viewing the filtering options in the Windows XP-based Group Policy editor tool.

In Figure 1.5, there is an option that says Only show policy settings that can be fully managed.”
The term “fully managed” is Windows XP’s way of saying that the policy setting does not tattoo
the registry. If you clear this check box, you will see both policy settings as well as preferences.
The MMC Group Policy tool differentiates policies and preferences by associating different
colors to the icons representing each. In Figure 1.6, I’ve created a custom .adm template file that
sets a preference within the registry. You can see that my preference Set current GPO version for
User has a red icon associated with it.

6
 Chapter 1

Figure 1.6: Viewing a preference, indicated by a red icon, within the Group Policy MMC tool.

The other policy items in Figure 1.6 have blue icons associated with them indicating that they are
non-tattooing policies.

Win2K’s Group Policy MMC tool works the same as in Windows XP. However, the menu item that
you use to filter the view of policies and preferences is different. Namely, from the Win2K Group
Policy MMC tool, highlight an Administrative Templates node, right-click, select View from the context
menu, and clear the Show Policies Only check box to view both policies and preferences.

So now we know the effects of tattooing. To better understand the actual process, let’s look at
how it works behind the scenes. The specific registry keys and values that are modified within
GPO-based Administrative Template policy is controlled by the .adm template files associated
with that GPO. Listing 1.1 shows a snippet from an .adm template file in Windows XP.

7
 Chapter 1

CATEGORY !!Logon
#if version >= 4
EXPLAIN !!Logon_Help
#endif
POLICY !!NoWelcomeTips
#if version >= 4
SUPPORTED !!SUPPORTED_Win2kOnly
#endif

KEYNAME
"Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
EXPLAIN !!NoWelcomeTips_Help
VALUENAME "NoWelcomeScreen"
END POLICY

Listing 1.1: Viewing a snippet from a Windows XP .adm template file.

In Listing 1.1, the NoWelcomeScreen registry value is being modified under the registry key
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer. From Listing 1.1, this key is
under the path listed as one that protects from tattooing. Now, as you probably know, an
Administrative Template policy can take three states—not configured, enabled, or disabled (see
Figure 1.7).

Figure 1.7: Viewing the three states of an Administrative Template policy.

8
 Chapter 1

When a state is set to not configured, the registry value specified within the .adm file has not
been set. For example, in Listing 1.1, a not configured setting would mean that the
NoWelcomeScreen registry value does not exist on machines that are processing the GPO on
which that policy is defined. If the policy is enabled, the registry value is created and the data
within the value is set according to the .adm file. In some cases, it may mean simply setting the
value to 1 or 0. In other cases, it may be filling the value with some text string, but in either case,
making the policy enabled means that the registry value exists and is set to some value. If the
policy is set to disabled, the registry value is set to the opposite value, as specified by the .adm
file, from the enabled state. Again, looking at the .adm snippet in Listing 1.1, this policy dictates
that the NoWelcomeScreen value is created and set to 1 when the policy item is enabled and 0
when its not.

When a policy item defined in the .adm template file does not explicitly call out what the values should
be for the enabled and disabled states, the default is to take a REG_SZ type value of 1 for enabled
and a REG_SZ type value of 0 for disabled.

If an Administrative Template policy item such as the one that Listing 1.1 shows makes changes
to the “magic” keys in the registry that prevent tattooing, that value will change from enabled or
disabled when the GPO is processed by the computer or user to not configured if the GPO no
longer applies to the computer or user. However, if the policy item does not make a change to
one of the “magic” keys, whatever change it makes to the registry—be it enabled or disabled—
will remain even after the GPO has been removed or no longer applies to the computer or user.
To get rid of it, you would need to explicitly set that preference to not configured to remove the
tattooed registry value. So, as you can see, there is a significant reduction in the policy
maintenance you have to do on a system if you use policies instead of preferences.

Q 1.3: How do .adm files differ between Windows NT 4.0 and Windows
2000 and Windows XP?
A: Microsoft has added quite a few new features to the Administrative Template .adm
“language” between Windows NT 4.0 and Windows XP. Most of the new features are in the
form of new keywords that enable new Group Policy features and functions. For example, in
Windows 2000 (Win2K), Microsoft added the EXPLAIN tag to allow for the text explanations
that you find in the Group Policy Microsoft Management Console (MMC) snap-in (see Figure
1.8).

9
 Chapter 1

Figure 1.8: Viewing the Explain text associated with an Administrative Template policy.

Listing 1.2 shows an example of how the EXPLAIN tag is called within an .adm file.

POLICY !!NoSecurityMenu
KEYNAME
"Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
EXPLAIN !!NoSecurityMenu_Help
VALUENAME "NoNTSecurity"
END POLICY

Listing 1.2: An example of the EXPLAIN tag used in Win2K and Windows XP .adm files.

In Listing 1.2, the EXPLAIN tag references some text, defined using a label (in this example,
!!NoSecurityMenu_Help), which is usually defined at the end of an .adm file within a section
called out by the [strings] tag. Within the [strings] section, each label is defined to equal a text
string that defines what that label means. It’s this text string that is shown in the Group Policy
editor tool to explain a policy item. Win2K and Windows XP EXPLAIN tags improve upon the
NT 4.0 System Policies by providing an explanation of what a given policy actually does and
how you can use it. If you create custom .adm files, you should strongly consider creating
accompanying EXPLAIN tags that explain your custom policy.
In addition to the EXPLAIN tag, Win2K and Windows XP include some additional logic within
the .adm file to test the version of policy editor tool that is loading the .adm file. Because the NT
4.0 policy editor won’t understand newer tags supported in Win2K and Windows XP, .adm files
created for these newer Windows versions use special logic to test for the version of the policy
editor tool. At the beginning of most Win2K and Windows XP .adm files, you will see a set of
statements, an example of which Listing 1.3 shows.

10
 Chapter 1

#if version <= 2

CLASS USER

CATEGORY !!GPOnly

POLICY !!GPOnlyPolicy
KEYNAME "Software\Policies"

PART !!GPOnly_Tip1 TEXT

END PART

PART !!GPOnly_Tip2 TEXT

END PART

PART !!GPOnly_Tip3 TEXT

END PART

PART !!GPOnly_Tip4 TEXT

END PART

PART !!GPOnly_Tip5 TEXT

END PART
END POLICY

END CATEGORY

CLASS MACHINE

CATEGORY !!GPOnly

POLICY !!GPOnlyPolicy
KEYNAME "Software\Policies"

PART !!GPOnly_Tip1 TEXT

END PART

PART !!GPOnly_Tip2 TEXT

END PART

PART !!GPOnly_Tip3 TEXT

END PART

PART !!GPOnly_Tip4 TEXT

END PART

PART !!GPOnly_Tip5 TEXT

END PART
END POLICY

END CATEGORY

#endif

Listing 1.3: Viewing the logic in Win2K and Windows XP .adm files that prevents NT 4.0 policy editor tools
from loading a newer .adm file.

11
 Chapter 1

Note that in Listing 1.3, the first statement is #if version <= 2. This statement checks to see
whether the version of policy editor tool is equal to or less than version 2. Version 2 corresponds
to the NT 4.0 policy editor tool (poledit.exe) or earlier policy tools. If the NT 4.0 policy editor
tool attempts to load and use an .adm file created for Win2K or Windows XP, the only policy
entry you will see is that shown in Figure 1.9.

Figure 1.9: Viewing the effects of loading a Win2K .adm file using the NT 4.0 policy editor tool.

The sections of text that you see in Listing 1.3 after the version check are there to create the
screen you see in Figure 1.9. That is, the various labels such as GPOnly_Tip1 thru Tip5 contain
the text shown in the Settings for System.adm section of the dialog shown in this figure. Listing
1.3 is saying that if the version is 2 or less (that is, the NT 4.0 system policy editor tool), show
the text specified by the various tips, which basically explains that you need a newer version of
the policy tool to view the contents of the .adm file.
If the NT 4.0 policy editor tool is version 2, it stands to reason that version 3 is the Win2K
MMC-based Group Policy snap-in, and version 4 is the GPO snap-in that comes with Windows
XP. In Win2K- and Windows XP-based .adm files, you will see version checks for versions 3
and 4 as well.
Windows XP also includes a new twist. Windows XP lets you view and filter Administrative
Template policy items based on which platform is required by a given policy. For example, if
you have an .adm policy that works only on Windows XP, you want to know that setting the
policy will have no effect on Win2K machines that process the policy. To do so, .adm files in
Windows XP use a new tag called SUPPORTED. The SUPPORTED tag is used to indicate the
minimum required OS version with which the policy item works. Listing 1.4 shows an example
of a policy section from a Windows XP .adm file that uses the SUPPORTED tag.

12
 Chapter 1

POLICY !!ShutdownReason
#if version >= 4
SUPPORTED !!SUPPORTED_WindowsXP
#endif

EXPLAIN !!ShutdownReason_Help
KEYNAME "Software\Policies\Microsoft\Windows NT\Reliability"

PART !!ShutdownReason_Box DROPDOWNLIST REQUIRED

VALUENAME "ShutdownReasonUI"
ITEMLIST
NAME !!ShutdownReason_Never VALUE NUMERIC 0
DEFAULT
NAME !!ShutdownReason_Always VALUE NUMERIC 1
END ITEMLIST
END PART

END POLICY

Listing 1.4: Viewing the use of the SUPPORTED tag in an XP .adm file.

The SUPPORTED tag is not a hard restriction. That is, unlike the version checks, it doesn’t
prevent the Win2K version of the Group Policy editor tool from loading a Windows XP .adm file
and setting policies. In fact, a Win2K Group Policy editor will simply ignore the SUPPORTED
tag because the tag is always surrounded by the statement #If version >= 4, which indicates to
the Group Policy tool reading the file that the section within the #if and #endif clauses be read
only by a Windows XP (version 4) version of the Group Policy editor tool.
For Windows XP, the SUPPORTED tag allows two capabilities. The first is that, on the main
dialog box of each policy item, the SUPPORTED tag is read to indicate which version of the OS
the current policy supports (see Figure 1.10).

Figure 1.10: Viewing the use of the SUPPORTED tag in a Windows XP policy.

13
 Chapter 1

In addition, Windows XP uses the SUPPORTED tag to let you filter policy items based on their
OS requirement. From the Group Policy MMC snap-in tool, if you highlight the Administrative
Templates node (either per computer or per user), and select View, Filtering, you will see the
dialog box that Figure 1.11 shows.

Figure 1.11: Using the SUPPORTED tag within the Windows XP Group Policy editor tool to allow filtered
views of .adm policy.

From the dialog box that Figure 1.11 shows, you can view Administrative Template policy items
that are specific to a particular OS so that you know which policies will affect which clients on
your network.

Q 1.4: If I’m using user groups to control policy application in a

Windows NT 4.0 system policy, how does that map to Windows Group
Policy?
A: Windows 2000 (Win2K) Group Policy Objects (GPOs) don’t have the same concept of
creating multiple user–group–specific policies within a single policy file, but you can achieve
similar results using a combination of GPO-based features. In Windows NT 4.0, you could create
a policy file (usually ntconfig.pol) that contained specific policy for a number of different users,
machines, or user groups. For example, I could have default computer and default user policy
applying to all users and specific policy applying to a specific user or user group in my NT 4.0
domain. In Figure 1.12, you see an NT 4.0 system policy file that provides policy settings for the
Finance Admins and Finance Users domain global groups.

14
 Chapter 1

Figure 1.12: Viewing an NT 4.0 system policy file that uses global groups to specify policy.

When you’re ready to migrate your NT 4.0 system policies to Win2K GPOs, you may find that
the scheme you had used in your system policies doesn’t quite map to how GPOs work.
Specifically, there is no analogous concept in GPOs to that of creating user, machine, or user–
group–specific policy settings within a single policy file. If you want to target a set of policy
settings to a particular user, machine, or group, you need to use GPO-based security group
filtering to achieve the desired results. What that means is that a single ntconfig.pol file in NT
4.0 that contains three user–group–specific policies will require three separate GPOs in Win2K
to achieve the equivalent policy control. Let’s take a look at how this might work.
In NT 4.0, you typically created policy groups like those that Figure 1.12 shows within your
system policy file to provide different desktop lockdown settings for different sets of user
groups. For example, again referring to Figure 1.12, I might have a looser set of desktop
restrictions for the Finance Admins group than I do for the Finance Users Group. Now, that’s all
fine until it comes time to start implementing equivalent desktop lockdown in Win2K or
Windows XP Group Policy. By using a tool such as gpolmig.exe from the Win2K Server
resource kit, you can take system policy settings and merge them into a GPO.

Make sure you use the version of gpolmig.exe that comes in supplement 1 of the Win2K Server
resource kit. The version that ships in the original Win2K Server resource kit doesn’t work! (Thanks to
Derek Melber of braincore.net for this tip.)

Gpolmig.exe lets you take specific policy settings in an NT 4.0 system policy file and export
them into Administrative Templates policy within a GPO. Let’s take the system policy that
Figure 1.12 shows and convert it to equivalent desktop lockdown policy in a Win2K domain.
The first step in the conversion process is to create the target GPOs that will house your NT 4.0
policy settings. In my example, I want to take the settings that I’ve created for the Finance
Admins and Finance Users groups and migrate them to Group Policy. To do so, I need to create
two separate GPOs, then use security group filtering to control which user groups process them.
The following steps describe the creation of the GPOs and how you set up security group
filtering. I’m going to make the assumption that the GPOs are linked to an organizational unit
(OU) called Finance, which contains the Finance Admins and Finance Users groups.

15
 Chapter 1

1. Start the Active Directory Users and Computers Microsoft Management Console (MMC)
snap-in tool. Highlight the OU to which the GPOs will be linked (in this case, Finance),
and right-click the OU.
2. Choose Properties from the context menu, then select the Group Policy tab.
3. From the Group Policy dialog box, click New, then name the GPO “Finance Admins
Lockdown.”
4. Repeat Step 3, creating a GPO called “Finance Users Lockdown.” Figure 1.13 shows the
two GPOs you’ve just created.

Figure 1.13: Viewing the GPOs created to hold converted NT 4.0 system policy settings.

5. After creating the two new GPOs, we need to set up the security filters to control how
they’re applied. From the GPO dialog box that Figure 1.13 shows, highlight the “Finance
Admins Lockdown” GPO, and click Properties.
6. From the Properties dialog box, choose the Security tab. Because we want this GPO to
only apply to the Finance Admins group, you need to prevent other users from processing
it. Highlight the Authenticated Users Access Control Entry (ACE) in the security dialog
box, and clear the Apply Group Policy permission for this group.
7. Click Add from the top of the dialog box, and choose the Finance Admins group from the
domain list.
8. With the Finance Admins group highlighted, select the Apply Group Policy permission to
ensure that only this group processes the GPO (see Figure 1.14).The Read permission
should be created by default, but if it isn’t, you must also select it to allow GPO
processing.

16
 Chapter 1

Figure 1.14: Adding a security filter to a GPO to control which user group processes it.

9. Repeat Steps 6 through 8 for the Finance Users Lockdown GPO, adding the Finance
Users global group to the security permissions rather than Finance Admins.
Now you’re ready to migrate the NT 4.0 system policies into Win2K GPOs. The first step is to
confirm that the gpolmig.exe tool actually sees all the policy groups that you’ve created in your
NT 4.0 system policy file. From a command line, type the following to list the contents of your
system policy file:
Gpolmig c:\policy\ntconfig.pol /list
where c:\policy\ntconfig.pol is the path to your NT 4.0 system policy file. You should see output
similar to that which Figure 1.15 shows.

Figure 1.15: Viewing the output of the list option of the gpolmig.exe utility.

17
 Chapter 1

To actually migrate the settings for each policy group, you need to know the globally unique ID
(GUID) for the target GPO. There are a couple of ways to identify a GPO’s GUID, but the
easiest is to use the gpolmig tool to do the work for you. The first thing to do is open up one of
your target GPOs using the Group Policy MMC snap-in. Then, from the command-line, issue the
following gpolmig command:
Gpolmig c:\policy\ntconfig.pol /listgpo
The output is similar to that which List 1.5 shows.
Using Downlevel policy file: ntconfig.pol
Processing GPOs currently being edited...

Current Group Policy Objects Open

(open the Properties of GPOs and locate the
'Unique Name' to identify the Globally Unique
Identifier, or GUID, that is displayed here)
---------------------------------------------
{D5D09664-0319-4BEC-97B2-5AC31B75D09B}Machine
{D5D09664-0319-4BEC-97B2-5AC31B75D09B}User

Listing 1.5: Viewing the output from a gpolmig listgpo command.

The last two lines of this output are the GUIDs for the GPO that is currently open on your
desktop. Note that they are both the same, but are differentiated by the computer- and user-
specific portions of every GPO. Because we are migrating user group policies from an NT 4.0
system policy, our target is the user-specific settings within a GPO. To actually perform the
conversion, we’re going to take the output from the last two gpolmig commands and use the
information to generate the command that will do the actual conversion. In the case of my
example, I’m going to migrate the settings in the Finance Admins system policy into my new
Finance Admins lockdown GPO using the following command:
gpolmig ntconfig.pol /migrate group "Finance Admins" {D5D09664-
0319-4BEC-97B2-5AC31B75D09B}User
This command tells gpolmig to migrate the NT 4.0 “group” type policy called “Finance Admins”
to the Administrative Template user portion of the GPO specified by the GUID. After this
command executes, all settings that can be migrated to my new GPO will be.

Gpolmig is not a perfect tool. Some settings that exist in NT 4.0 .adm template files may not exist in
Win2K GPO .adm files and thus won’t be migrated. If you have created custom .adm files for your NT
4.0 system policies, you need to be sure to load those into your new GPO prior to attempting a
migration.

If you repeat this migration process for the Finance Users, you will effectively have the same
policy lockdown features in two Win2K GPOs that you had in a single NT 4.0 system policy file.
Of course, GPOs give you added flexibility that you never had in NT 4.0 system policy, but at
the very least, you still get the desktop lockdown via Administrative Templates!

18
 Chapter 1

Q 1.5: Can Windows 2000 or Windows XP clients process both

Windows NT 4.0 System Policies and Group Policy Objects?
A: Windows 2000 (Win2K) and Windows XP can process both Group Policy Objects (GPOs)
and Windows NT 4.0 System Policies. However, the rules for which gets processed when
depends upon where user and machine accounts reside.
An NT 4.0 System Policy file (for example, ntconfig.pol) is only applied when the corresponding
user or machine accounts still reside within an NT 4.0 domain. For example, many enterprises, in
the midst of migrating from NT 4.0 to Win2K AD, migrate user accounts into Active Directory
(AD) but leave machine accounts in NT 4.0 resource domains. In such cases, any computer-
specific System Policies (policies that make changes in the registry to
HKEY_LOCAL_MACHINE) that you’ve created in your NT 4.0 domains are applied to the
Win2K or Windows XP machine when the AD user logs onto the AD domain from that
workstation. However, no user-specific NT 4.0 System Policy settings are processed if the user
account resides in an AD domain. To better understand this concept, let’s explore the scenario
that Figure 1.16 illustrates.

Figure 1.16: Viewing a mixed NT 4.0 and AD environment.

19
 Chapter 1

In the example that Figure 1.16 shows, we have a Win2K client machine whose machine account
resides in the NT 4.0 domain called Sales. There is a user named Bob, who has an account
defined in the AD domain called myorg.tld. Bob logs onto the Win2K client workstation in
Sales. Which policies will Bob receive? Because the machine account of the workstation on
which Bob is logging on is in an NT 4.0 domain, as soon as Bob logs onto that machine, any
machine-specific NT 4.0 System Policy file that exists in the Netlogon share on the myorg.tld
AD domain controllers will be processed.

Even on a Win2K or Windows XP client, a user must log onto the machine before the NT 4.0 System
Policy is processed. This requirement contrasts machine-specific GPO policy, which only requires a
machine restart to trigger processing. In addition, the ntconfig.pol file must reside on the domain
controllers of the authentication domain—in this case, an AD domain called myorg.tld.

In the previous example, only computer-specific System Policy will be processed. If a “Default
Computer” or machine-specific policy has been defined in the NT 4.0 System Policy, that policy
will be processed. No user-specific System Policy will be read, even if it is defined, because the
user account in this example resides in an AD domain, and thus will only process user-specific
Group Policy.
It’s also worth noting that if an NT 4.0 user account logs onto a Win2K or Windows XP machine
that resides in an NT 4.0 domain, no GPOs (other than the local machine GPO) are processed—
only NT 4.0 System Policy is processed. Also remember that if you want NT 4.0 System Policy
to be processed in a mixed AD and NT 4.0 domain environment, you need to make sure that your
policy file—ntconfig.pol—is found in the Netlogon share of the domain controllers in the
authentication domain (the myorg.tld domain in the previous example). On NT 4.0 domain
controllers, this location is typically in %systemroot%\system32\repl\import\scripts. On AD
domain controllers, Netlogon is shared only for backward compatibility as part of the replicated
SYSVOL structure and can be found under %systemroot%\sysvol\sysvol\<domain
name>\scripts. If you place your ntconfig.pol files in this folder, they will automatically be
replicated to other AD domain controllers in the domain. Finally, if you decide that you don’t
want NT 4.0 System Policies to be processed for certain machines or users, you can always
disable System Policy processing by changing the value of the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update\UpdateMode registry
subkey from 1 to 0.

Q 1.6: Do Group Policy Objects contain all the same policy settings
that I used in Windows NT 4.0 System Policy?
A: The quick answer to this question is no. You will find that some of the policy settings that
you might have relied upon in Windows NT 4.0 System Policy are no longer supported in
Windows 2000 (Win2K)- and Windows XP Group Policy Object (GPO)-based policy, for good
reason. Some of the changes in the Win2K and Windows XP shell environment facilitated the
need to drop support for certain NT 4.0 settings. In other cases, settings that were implemented
as .adm files in NT 4.0 might have been folded into other mechanisms in Group Policy. For
example, in NT 4.0 there was a user-specific policy within the winnt.adm template file that let
you redirect certain folders within a user’s profile to a different location (for example, a server
share). Figure 1.17 shows an example of this type of policy.

20
 Chapter 1

Figure 1.17: Viewing the shared folder policy in NT 4.0 System Policy.

However, in Win2K and Windows XP, this feature has been usurped and improved upon by the
Folder Redirection policy. You won’t find the Custom Folders policy item anywhere in Group
Policy. Instead, Folder Redirection lets you redirect certain user profile-based folders, such as
Desktop, to alternative locations (usually server shares) for all users subject to that GPO or based
on a user’s group membership (see Figure 1.18).

Figure 1.18: Viewing GPO-based folder-redirection policy.

In fact, if you’ve done a lot of policy setting in your NT 4.0 System Policies, you might find it
downright frustrating trying to discover what happened to those policies as you migrate to GPOs.
Table 1.1 shows some commonly used settings in NT 4.0 System Policy and the location of their
equivalents in Win2K-based Group Policy.

21
 Chapter 1

NT 4.0 Policy Setting Equivalent Win2K or Windows XP GPO Setting

Default Computer, Windows NT System,
Logon, Do not display last logged on user
name
Default Computer, Windows NT User Profiles,
Delete cached copies of roaming profiles
Default User, Control Panel, Display, Restrict
Display, Hide Screen Saver Tab
Default User, Shell, Restrictions, Remove Run
command from Start Menu
Default User, Shell, Restrictions, Hide Drives in
My Computer
Default User, System, Restrictions, Disable
Registry editing tools
Default User, Windows NT User Profiles, Limit
profile size
Computer Configuration, Windows Settings, Security
Settings, Local Policies, Security Options, Do not
display last user name in logon screen (Windows XP:
Interactive Logon: Do not display last user name)
Computer Configuration, Administrative Templates,
System, Logon, Delete cached copies of roaming
profiles (Windows XP: Computer Configuration,
Administrative Templates, System, User Profiles,
Delete cached copies of roaming profiles)
User Configuration, Administrative Templates, Control
Panel, Display, Hide Screen Saver Tab
User Configuration, Administrative Templates, Start
Menu & Taskbar, Remove Run menu from Start Menu
User Configuration, Administrative Templates,
Windows Components, Windows Explorer, Hide these
specified drives in My Computer
User Configuration, Administrative Templates, System,
Disable registry editing tools (Windows XP: Prevent
access to registry editing tools)
User Configuration, Administrative Templates, System,
Limit Profile Size

Table 1.1: Viewing some NT 4.0 policy settings and their equivalents in Win2K Group Policy.

As you can see from the table, you might have to do some serious hunting to locate the NT 4.0
System Policy setting that you want to implement in Win2K or Windows XP Group Policy. The
good news is that there seem to be very few NT 4.0 policy settings that simply aren’t supported
in Win2K or Windows XP.

Q 1.7: Can I still use poledit.exe to view Group Policy Objects?

A: As I’ve mentioned in previous tips, Group Policy Objects (GPOs) contain more policy
information than the registry-based .adm policies that Windows NT 4.0 supports. Still, a .pol file,
called registry.pol, is stored within the machine and/or user folder under a GPO’s Group Policy
Template (GPT) folder structure under SYSVOL (see Figure 1.19).

Figure 1.19: Viewing the registry.pol file that is stored in a GPO’s GPT.

22
 Chapter 1

Unfortunately, Microsoft changed the format of the registry.pol file from that which was
supported in NT 4.0 .pol files. NT 4.0 pol files were actually registry hive files that could be
loaded using poledit or even regedt32.exe. GPO-based registry.pol files do not follow that same
pattern; thus, you won’t be able to load a registry.pol file using poledit.exe. In addition, you can’t
load some Windows 2000 (Win2K) or Windows XP-specific .adm template files with
poledit.exe, as they will show up as unsupported.
So if you’re used to using poledit.exe to manage policy in NT 4.0, you will have to leave it by
the wayside for managing most GPO-based policy. Of course, you can still use the open registry
option in the File menu of poledix.exe to view the current registry settings of a local Win2K or
Windows XP computer (see Figure 1.20).

Figure 1.20: Viewing poledit.exe opened on the local registry of a Win2K computer.

In local registry mode, you will only see the policy items that are presented by the currently
loaded .adm files. Thus, you will have to either load Win2K- or Windows XP-based .adm files
that support poledit.exe, or you will need to limit what you can view to registry values supported
by NT 4.0-based .adm settings that are still supported in Win2K or XP. All in all, you’re better
off sticking with the Microsoft Management Console (MMC)-based GPO tools to view and
modify GPOs.

Q 1.8: Can I store my Windows NT 4.0 policies in the same place that
Group Policy Objects are stored?
A: As you know, Windows NT 4.0 System Policy files were typically stored in the Netlogon
share on NT 4.0 domain controllers. However, in Windows 2000 (Win2K), Group Policy files
are stored in the replicated SYSVOL share on domain controllers within a domain. The Netlogon
share is still supported on Win2K domain controllers, but it’s in a different part of SYSVOL
from where your Group Policy Objects (GPOs) are stored.

23
 Chapter 1

SYSVOL and NTFRS replication completely replaces the old NT 4.0 directory replication
service that supported replication of the Netlogon share. If you view the default shares that are
created on a Win2K domain controller, you’ll see that both SYSVOL and Netlogon exist on the
server but that they are located in different paths within the NTFRS replication tree (see Figure
1.21).

Figure 1.21: Viewing the Netlogon and SYSVOL shares on a Win2K domain controller.

As you can see in Figure 1.21, both Netlogon and SYSVOL are shared under the
%systemroot%\SYSVOL\sysvol folder on a domain controller. Files that are part of a GPO’s
Group Policy Template (GPT) are stored in SYSVOL\<domain name>\policies, whereas files
that are shared as Netlogon are stored in SYSVOL\<domain name>\scripts.

Note that the path %systemroot%\SYSVOL\sysvol\<domain name> is actually a symbolic link (or
junction point) to the folder %systemroot%\SYSVOL\domain. So both folders point to the same place
in the file system.

If you have NT 4.0 machines in your Win2K Active Directory (AD) domains (or Win2K
machines in NT 4.0 domains that are authenticating to AD domains), you might need to maintain
some NT 4.0 System Policy processing capability. In that case, you would have to copy your
ntconfig.pol files into the Netlogon-shared “scripts” folder on your Win2K domain controllers.
NTFRS automatically replicates all content under %systemroot%\SYSVOL\domain to all
domain controllers within a domain. Given that, you only need to copy your ntconfig.pol file to
the scripts folder on one domain controller to have it replicate everywhere. You can, of course,
redirect where an NT 4.0 or Win2K system will look for the ntconfig.pol file. There is a registry
key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update that lets you
override the default behavior of looking in the Netlogon share at logon time for the System
Policy file. By adding two registry values under the Update key, you can modify this default
behavior. Those values are:

24
 Chapter 1

• UpdateMode of type REG_DWORD and must have a value of 0x2 in order to specify a
path to the ntconfig.pol file other than Netlogon.
• NetworkPath of type REG_SZ and points to the UNC path where the file is located (for
example, \\myserver\sysvol\mar-elia.com\policies\ntconfig.pol).
If you specify a path to a single Win2K domain controller, you lose the fault tolerance that
NTFRS provides. However, if you have a fault-tolerant DFS tree at your disposal that replicates
content across multiple Win2K servers, you could enter the path to that DFS tree in the
NetworkPath registry value. Note that these two registry values must be added on all NT 4.0 and
Win2K machines that you expect to process System Policy against your AD domain.

25
 Chapter 2

Chapter 2: How GPOs Work

Q 2.1: How do I know whether my Windows 2000 or Windows XP

workstation is correctly processing Group Policy Objects that are
defined in my Active Directory infrastructure?
A: There a number of ways to tell whether your workstations or servers are processing Group
Policy Objects (GPOs). But first, it helps to understand the mechanisms behind GPO processing.

GPO Background
The details behind GPO processing are fairly straightforward. A GPO is really composed of two
pieces—the Group Policy Template (GPT) and the Group Policy Container (GPC). The GPC is a
set of Active Directory (AD) objects and their attributes that define the basic GPO. The GPT is a
set of files and folders within the SYSVOL share on each domain controller in an AD domain.
The GPT contains most of the settings for the policy items you select within the Group Policy
Microsoft Management Console (MMC) snap-in. When a Windows 2000 (Win2K) or Windows
XP workstation boots or a user logs onto a machine, a process running on the workstation or
server called Winlogon.exe calls a set of DLLs called client side extensions (CSEs).

You can view the list of CSEs registered on a particular Win2K or Windows XP computer by going
into the registry and viewing the subkeys listed under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions. Each subkey listed describes a CSE. The values under
each subkey describe which policy processing functionality that DLL provides—for example, folder
redirection, disk quota, registry settings (administrative templates)—as well as settings related to how
that CSE behaves when processing a GPO.

CSEs are the code responsible for reading the GPC and GPT for each GPO that the computer or
user must process and for applying the policy settings to that computer or user. This processing
can happen in the background while other tasks are going on (asynchronous), or in the
foreground, preventing other tasks from happening until GPO processing is complete
(synchronous).

Is Your Computer Processing GPOs?

Now that we have an overview of how GPO processing occurs, let’s look at ways to know
whether your computer or user is actually processing the GPO. There are several approaches you
can take to check GPO processing.

GPResult
Gpresult.exe is a Win2K resource kit and Windows XP built-in utility that provides a command-
line mechanism for viewing which GPOs are being applied to a given machine. The Win2K
version is limited in that it can be run only on the machine for which you want to analyze GPO
processing. It has no capability to report on remote machines. The Windows XP version offers
this remote capability. And, while the Win2K version of GPResult can report on which registry
values have been set through an administrative template policy, the Win2K version cannot report

26
 Chapter 2

details about any security policy that has been set on the machine. The Windows XP version
does not have this limitation. To access a listing similar to the one that Figure 2.1 shows, type
gpresult
at a command prompt.

Figure 2.1: Viewing the output of the gpresult.exe tool.

GPResult supports a couple of command-line switches, including /v and /s, which output the
results in verbose and super-verbose modes, respectively.

Gpresult.exe is best used as a quick and dirty tool for viewing which GPOs are in effect on a given
workstation or server. However, for more robust reporting, use one of the Resultant Set of Policy
(RSoP)-based approaches described later.

Event Logs
The Win2K event logs can be useful for viewing the effects of GPO processing (as well as for
GPO troubleshooting, as you’ll see in Chapter 8). All GPO-related events are reported in the
Application event log in Win2K and Windows XP. By default, some events are logged out-of-
the-box. However, to get the best results from the event logs, you need to set some registry
values to enable more verbose GPO logging. To get more verbose logging, add the following
registry subkey (if it doesn’t already exist) to any Win2K or Windows XP machine on which you
want logging to occur: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Diagnostics. Under the Diagnostics subkey, add a REG_DWORD value
called RunDiagnosticLoggingGlobal, and give it a value of 0x1. You will need to reboot for the
logging to take effect, but once it does, you will see a series of Application event log events each
time GPO processing occurs. This logging is handy for telling you which GPOs are being

27
 Chapter 2

processed during each processing cycle. However, this logging won’t tell you which settings
were applied to your machines. For that additional functionality, you will need some kind of
RSoP tool, like those described below.

RSoP
RSoP provides the ability to view, for a given user logging onto a given computer, the GPOs that
have been applied. There are a couple of tools on the market that provide RSoP capability for
Win2K and Windows XP, including FullArmor’s FAZAM. This product not only allows you to
view effective policy for a given user and computer, but also lets you perform what-if analysis
for users and computers that you plan to move around your AD (for example, change
organization units—OUs), view and edit a domain’s GPOs at-a-glance, and perform diagnostics
and auditing on GPOs. The planning capability is useful in that it can tell you what the effective
policy would be if you moved an existing user or computer. Figure 2.2 shows a view of the
FAZAM analysis capability.

Figure 2.2: Viewing the results of an analysis using FAZAM.

Windows XP also includes a rudimentary RSoP MMC snap-in that you can use to analyze policy
(but not perform what-if scenarios) on local or remote computers for any user. Follow these steps
to bring up the Windows XP RSoP tool:
1. From the Start menu, select Run, and in the resulting text box, launch mmc.exe to bring
up a blank MMC console.
2. From the Console menu in Win2K or the File menu in XP, choose Add/Remove Snap-in,
and click Add. From the list of available snap-ins, choose Resultant Set of Policy.
3. You are then led through a wizard that lets you choose the user and computer you want to
analyze. Once completed, current GPO settings will be displayed in the MMC in a
familiar GPO editor-style tree with results showing which policy has been applied to your
computer or user and which GPO the policy setting comes from.

28
 Chapter 2

Q 2.2: How does Group Policy Object security group filtering work?
A: Group Policy Object (GPO) security group filtering is the process by which you can filter the
effects of a GPO by restricting which user or computer groups can “view” that GPO. In most
cases, the best way to restrict which computers or users will process a GPO is to link that GPO at
an appropriate level within Active Directory (AD). If you don’t want a GPO to be processed by
all users in an AD domain, don’t link it to the domain level but rather to the site or organizational
unit (OU) level.
However, there may be cases in which you need to apply a GPO to most of the users in your
domain, but you want to exclude a small group of users. Similarly, you may have a GPO linked
to an OU, but you want to let only a small group of users within that OU process the GPO. In
either case, using security group filtering is the right solution.
Security group filtering of GPOs is very similar to restricting access to certain NT File System
(NTFS) files and folders on a server or workstation. In both cases, you are applying access
permissions to the resource in question to allow or deny certain groups of users or computers
access to that resource. The access control list (ACL) on a resource contains a list of access
control entries (ACEs) that specify who can access that resource—regardless of whether the
resource is a file folder on a server or a GPO defined in AD. Figure 2.3 shows an example of
what an ACL on a GPO looks like.

Figure 2.3: Viewing the ACL for a GPO.

29
 Chapter 2

To navigate to the dialog box that Figure 2.3 shows, you need to load a Group Policy Microsoft
Management Console (MMC) snap-in tool, focused on a GPO within your AD domain, or you
can view the properties on a GPO from either the Active Directory Users and Computers snap-in
or the AD Sites and Services snap-in. If you choose the latter approach, once the tool is loaded,
highlight the container object (site, domain, or OU) to which the GPO of interest is linked, right-
click the container, and select Properties from the context menu. Next, select the Group Policy
tab, highlight the GPO you want to view, click Properties, and select the Security tab.
The ACL that Figure 2.2 shows has two roles. The first role is to set permissions for who can
edit the GPO. The second role is to control who will process the GPO. For now, we’re interested
in the latter role. There are two permissions that control whether a particular user or computer
will process a GPO—the Read permission and the Apply Group Policy permission. The
combination of these two permissions allows a user or computer the ability to process a GPO. In
fact, a computer or user must have both permissions defined to process the GPO—having one
but not the other will not work.
Before you’re ready to start applying security group filters to your GPOs, you should understand
a few key points. First, by default, all GPOs will have the Authenticated Users group with Read
and Apply Group Policy permissions set. This setting means that all users and computers (yes,
computers) will process the GPO. Computers are considered part of the Authenticated Users
group as well as users because each computer account in an AD domain has a user account
created for it to allow it to securely connect to the domain.

All domain computers and users are considered part of an AD domain’s Authenticated Users group.

The next step for using security group filtering depends upon whether you’re restricting the GPO
to a small group of users or computers or allowing all but a small group of users or computers to
process a GPO. Let’s look at the first case.
If you want to restrict a GPO so that only a particular group of users or computers can process it,
the first thing you’re going to need to do is remove the ACE for the Authenticated Users group.
From the ACL editor that Figure 2.3 shows, simply highlight the Authenticated Users group and
click Remove to remove the ACE. Next, you need to add the new ACE for the computer or user
group that you want to grant access to the GPO. Click Add at the top of the ACL editor dialog
box, and choose the computer or user group you want to grant access to.

You can add ACEs granting Read and Apply Group Policy rights to individual users and computers
instead of groups. However, doing so is not recommended because it adds complexity and, as the list
of permissions on a GPO grows, slows down the processing of this GPO as the computer or user sifts
through all the ACEs.

Once you’ve added the group, select the Read and Apply Group Policy permissions under the
Allow column in the ACL editor, as Figure 2.4 shows.

30
 Chapter 2

Figure 2.4: Adding a new ACE on a GPO.

In Figure 2.4, the Finance Users group has been granted access to process a GPO called Desktop
Lockdown Policy that has been linked to the Finance GPO. Notice that the Authenticated Users
group is nowhere to be found on this GPO. Thus, only the Finance Users group (and any other
group that has Read and Apply Group Policy rights) will process this GPO.
Now, let’s look at the second case, in which we want to exclude a small group of users or
computers from processing a GPO that otherwise would be processed by every user or computer.
In this case, we will use a Deny ACE to prevent a group from processing the GPO. Figure 2.5
shows an example of this.

Figure 2.5: Using a Deny ACE to prevent a group from processing a GPO.

31
 Chapter 2

In Figure 2.5, I’ve added an ACE for the Finance Servers group to the Default Domain Policy
GPO. The Finance Servers group is a group of servers in the Finance OU that I don’t want to
process the computer portion of the Default Domain Policy GPO. As you can see, the
Authenticated Users ACE is still in place on this GPO, guaranteeing that all users and computers
subject to this GPO (which is linked at the AD domain level) will process it. However, by adding
a Deny ACE for the Finance Servers, which overrides any Allow ACEs automatically, I
effectively prevent this computer group from processing the GPO.

In this example scenario, I could have simply added a Deny ACE for the Read permission because
denying Read effectively prevents the group from processing the GPO, regardless of whether the
Apply Group Policy permission was allowed. Remember, a group must have both permissions to
process a GPO.

You can use these methods of adding Allow and Deny ACEs to selectively filter the effects of a
GPO for particular groups of users and computers. However, because long ACLs on a GPO add
to the time required to process that GPO, I recommend being judicious about how you use
security group filtering. In addition, you can create a confusing situation if you add many ACEs
to a GPO—some that allow access to particular groups and some that deny access—especially if
users or computers belong to groups that have both been granted and denied access (the Deny
ACE will always take precedence over an Allow ACE). In the case of security group filtering,
keeping it simple is a good rule to follow.

Q 2.3: What is the purpose of No Override and Block Inheritance?

A: No Override and Block Inheritance are two Group Policy Object (GPO) features that let you
control how Group Policy propagates throughout Active Directory (AD). You can consider them
opposing forces to each other.
In a nutshell, No Override lets a Group Policy administrator ensure that his or her GPO is always
processed by downstream users and computers. For example, if I define a GPO linked to a
domain, I can use No Override to guarantee that that GPO is always processed by users and
computers in that domain. However, if I’m an administrator of an organizational unit (OU), I
might want to block upstream GPOs that have been linked to the domain or site of which my
users are members, but which I don’t want my users and computers to receive. Such upstream
blocking is accomplished by virtue of the Block Inheritance feature. However, No Override
always “trumps” Block Inheritance. That is, if an administrator sets a No Override flag on a GPO
higher up in the AD hierarchy (for example, at the site or domain level, or even at a higher-level
OU in the case of nested OUs), no Block Inheritance will prevent downstream users and
computers from processing that GPO. Although this behavior might seem unfair, there are
certain types of policy (for example, security) that you absolutely positively need to know that
every user and computer that should receive the GPO is in fact receiving it. Using No Override
achieves this goal.

No Override always “overrides” Block Inheritance. That is, no amount of inheritance blocking will
protect you from a GPO that has No Override set.

No Override is set on a per-GPO basis, but Block Inheritance is set per-container object (for
example, site, domain, or OU). This difference makes sense because, as an OU administrator,

32
 Chapter 2

you would want to block inheritance of upstream GPOs at your OU, rather than on a per-GPO
basis. Likewise, a domain or site administrator might only want to selectively force a given GPO
to be inherited using No Override.
A good example of when No Override comes in handy is for enforcing security policy. For
example, a domain administrator may have some corporate security settings that all users and
computers must receive. If the administrator enables No Override on this security GPO, all
downstream users and computers will always process that GPO. The following steps walk you
through how to enable No Override on a GPO:
1. Open the Active Directory Users and Computers (or AD Sites and Services for site-
linked GPOs) Microsoft Management Console (MMC) snap-in tool.
2. Right-click the container object (for example, site, domain, or OU) linked to the GPO
that you want to enable with No Override.
3. From the context menu, choose Properties, then select the Group Policy tab.
4. You will see a dialog box similar to the one that Figure 2.6 shows.

Figure 2.6: Viewing Group Policies linked to a domain.

5. Highlight the GPO that you want to enable for No Override, then click Options.
6. In the resulting dialog box, select the No Override check box, and click OK to confirm.
7. Repeat this process for each GPO you want to set to No Override.

33
 Chapter 2

As I mentioned earlier, Block Inheritance is set at the container level. As you can see in Figure
2.6, there is a Block Policy inheritance check box at the bottom of the dialog box. By selecting
this check box, you effectively form a wall (albeit a soft wall) that prevents upstream GPOs from
being processed by your users and computers (unless those GPOs use No Override). Block
Inheritance does not block GPOs linked to the container which you’re blocking, only upstream
ones. For example, Figure 2.7 shows that Block Inheritance has been set on OU2.

Figure 2.7: AD domain showing the use of No Override and Block Inheritance.

Setting block inheritance on OU2 means that users and computers that reside in OU2 and OU5
will only process OU GPO2 and Domain GPO2 because Domain GPO2 has had the No Override
flag set, so it cannot be blocked. However, Block Inheritance does effectively block OU GPO1,
Site GPO, Domain GPO1, and Domain GPO3.

34
 Chapter 2

Q 2.4: How do site-linked Group Policy Objects (GPOs) work?

A: Linking your Active Directory sites to your Group Policy Objects (GPOs) is an often over-
looked feature within Group Policy that can provide some interesting benefits. As you know, you
can link GPOs to domains, organizational units (OUs), and sites, but in my experience site-
linked GPOs seem to be fairly rare. The reason for this rarity likely has to do with the purpose of
sites in your AD infrastructure. A site is a collection of IP subnets that are typically connected by
high-speed interconnects. For example, a set of subnets on a high-speed campus backbone would
typically belong to the same AD site. Sites (and subnets) are managed using the AD Sites and
Services Microsoft Management Console (MMC) snap-in (dssite.msc). Figure 2.8 shows the
process of creating a subnet and associating it with a site.

Figure 2.8: Adding a subnet to the SanFrancisco site using the AD Sites and Services MMC snap-in.

Sites are typically used to control replication between AD domain controllers as well as allow
you to group workstations and servers together for the purpose of guaranteeing that services such
as distributed file system (Dfs) and authentication are handled locally. But sites can also be the
target of GPO linking. So why would you link a GPO to a site? When it is done, it’s done
because you want to provide some policy settings to your users and computers that are specific to
their location on the network. The most common reason is to force the use of IP Security (IPSec)
network-layer encryption if users are on a specific set of subnets. (For example, if your
executive’s computers are all located within a single site and you want to ensure that their traffic
is encrypted.) Another use might be to deliver a particular set of policy lockdown if you have
users dialing in and accessing your network via a Virtual Private Network (VPN). Those clients
will typically get a range of IP addresses on one or more subnets that you can collect into a site
and attach to a GPO.
The thing to remember about site-linked GPOs, unlike domain or OU-linked ones, is that the
effect of site-linked GPOs crosses domain boundaries. That is, any computer that belongs to a
site (and the user who logs onto that computer), regardless of which domain it’s in, will process
the GPO. This action makes sense when you think about it because sites can contain users,
computers, or domain controllers from multiple AD domains within a single forest. And,

35
 Chapter 2

although domains and OUs are stored within the domain-naming context for a particular domain
and thus are only replicated to domain controllers within that domain, site information is stored
in the configuration naming context (see Figure 2.9), which is replicated to all domain controllers
in a forest regardless of domain membership.

Figure 2.9: Using the ADSI Edit MMC tool to view sites within the configuration naming context in AD.

Remember that GPOs are processed using the order local, site, domain and finally, OU. Thus,
after the local GPO is processed, any site-linked GPOs are processed first, before those that are
domain and OU-linked. Thus, if any GPOs processed after your site-linked ones contradict any
site-specific policy settings, those site-specific settings will be cancelled out by the time the
computer or user processes all their GPOs. Site-linked GPOs in this case are “low man on the
totem pole” and so you need to make sure you design them with that fact in mind. You can use
the No Override feature in Group Policy (see Figure 2.10) to ensure that a particular site-linked
GPO is always processed and can’t be overridden by “downstream” GPOs, but, because site-
linked GPOs are the first in line, you can’t use the Block Policy Inheritance feature to ensure that
upstream GPOs don’t take precedence (because there aren’t any upstream GPOs to those that are
site-linked).

36
 Chapter 2

Figure 2.10: Viewing the use of No Override on a site-linked GPO.

One final thing to know about site-linked GPOs—I mentioned that sites are actually stored
within the configuration naming context and thus replicated to every domain controller in a
forest. However, the Group Policy Template (GPT) portion of a GPO is still stored within
SYSVOL on domain controllers within a single domain. If you create a site-linked GPO using
the AD Sites and Services tool, by default, the GPT for that GPO is created in the forest root
domain—the first domain in a forest. However, if you create a domain or OU-linked GPO in
another domain other than the forest root, then link that GPO to a site at a later time, the GPT
exists in whatever domain it was first created in. The reason that this fact is important is that you
need to have a good sense of where all your site-linked GPOs actually reside as compared with
your users. You don’t want users or computers having to cross slow WAN links just to find the
GPOs that they need to process, so you might find that you need to keep some domain
controllers from the domain where your site-linked GPOs are stored at locations close to your
users to ensure good performance.

37
 Chapter 2

Q 2.5: Why are changes to Group Policy Objects always written first
to the PDC emulator in Active Directory?
A: Because it is possible for two people, working in different geographic regions, to write
changes to a single Group Policy Object (GPO) from two different domain controllers, Microsoft
sought to provide a way to minimize collisions. By default, when you open the Microsoft
Management Console (MMC) Group Policy snap-in focused on an Active Directory (AD)-based
GPO, the copy of the GPO you are actually editing resides on the PDC emulator domain
controller in your AD domain. The reason is that the GPO editor tool will always try to edit the
copy of a GPO on the PDC emulator for that domain to limit collisions between two people
editing the same GPO. For example, if a systems administrator in New York and a systems
administrator in San Francisco both try to edit the Default Domain Policy at the same time, they
will both be focused on the PDC emulator domain controller to make the change. In that case,
the first user to edit the GPO will put a “lock” on that GPO. When the second user attempts to
edit that same GPO, the user will get an error message similar to the one that Figure 2.11 shows.

Figure 2.11: Viewing the error received when two people try to edit the same GPO at the same time.

This setup is a good thing because it ensures that two people editing the same GPO can’t
overwrite each other’s changes, which is especially important if the changes being edited are
security policies. You can actually see which domain controller you are currently focused on
while editing a GPO from the MMC Group Policy snap-in tool. The current domain controller
will appear in brackets to the right of the GPO name in the left pane of the tool (see Figure 2.12).

38
 Chapter 2

Figure 2.12: Viewing the currently focused domain controller (yquem.mar-elia.com) while editing a GPO.

However, there may be circumstances in which you want to override this behavior and edit a
GPO while focused on a different AD domain controller. In such a case, you change which
domain controller the Group Policy MMC tool focuses on when you edit GPOs by choosing
View, Domain Controller Options from the MMC menu. Figure 2.13 shows the list of your
options.

Figure 2.13: Viewing the options for focusing editing of GPOs.

As you can see in Figure 2.13, the default choice is to connect to the PDC emulator. However,
you can choose the second option, which will connect to whichever domain controller your
Active Directory Users and Computers or AD Sites and Services MMC tools are currently
focused on. Typically, when you open these tools, they connect to the closest domain controller
to you, which is normally a domain controller within the same AD site as your administrative
workstation. If you select the third choice, the next time you open the Group Policy MMC snap-
in, the tool will randomly select a domain controller to connect to within the same site from
which you’re connecting.

39
 Chapter 2

When you choose any of these three options, you need to stop and restart your Group Policy tool for
the changes to take effect. In addition, the changes are in effect only for the Group Policy MMC snap-
in on the machine on which you make the change. The choice does not follow your user ID to another
machine unless you have a Group Policy Administrative Template policy in place to enforce the
choice across a group of users or machines.

A good practice is to not mess with this setting unless you have a really good reason. One good
reason for focusing a GPO editor on a different domain controller is if the PDC emulator domain
controller is currently down or unavailable and you need to make quick changes to a GPO.

You can easily determine which domain controller in your AD domain currently holds the PDC
emulator role by using the netdom.exe utility that comes with the Windows 2000 (Win2K) Support
Tools. To use netdom.exe to determine the current PDC emulator, type:
Netdom query fsmo
Where fsmo is the acronym for floating single master operation—the original name for the operations
masters roles. When you type this command, the utility will return all five role holders within your
current domain and forest:
Schema owner yquem.mar-elia.com
Domain role owner yquem.mar-elia.com
PDC role yquem.mar-elia.com
RID pool manager yquem.mar-elia.com
Infrastructure owner yquem.mar-elia.com
The command completed successfully.
In this case, all five roles are held by one domain controller, which is generally not a good thing!

Q 2.6: Can I permission a Group Policy Object such that someone can
view its settings but not edit them?
A: Strangely enough, there is no such thing as a read-only Group Policy Object (GPO). There is
no way to give someone view-only permissions on a GPO. This limitation seems counterintuitive
because we’ve seen throughout this book that GPOs are highly permissionable. However, you
can’t grant an administrator read access to a GPO—the administrator won’t be able to access that
GPO. For example, if I want a member of the Finance Admins group to be able to view but not
change GPOs that have been linked to the Finance OU, I might try setting the GPO’s
permissions as the window in Figure 2.14 shows.

40
 Chapter 2

Figure 2.14: Viewing read permissions on a GPO.

However, the permissions as shown in the figure will result in an access denied error when a
member of the Finance Admins group tries to load the GPO into a Microsoft Management
Console (MMC) snap-in tool. At minimum, a user needs the Read and Write permissions to be
able to view a GPO. And, once the Write permission is granted, the user can then edit that GPO.
The one ability that the user doesn’t have with only Read and Write permissions is to change the
permissions on the GPO. This level of control over a GPO requires the Full Control permission.
If you really need to be able to give users read-only views of your GPOs, your best bet is to give
them indirect access by creating reports that show the current settings for GPOs. There are quick
and dirty ways that you can do so by using tools such as GPResult.exe, which only shows the
current settings in text form that apply to a particular user or computer. Or you can let your users
use the Resultant Set of Policy (RSoP) tool that comes with Windows XP to generate a report of
GPO settings that they’re receiving on their workstations. (Figure 2.15 shows an example of a
Windows XP-based RSoP report.) Users that have only read permissions on a GPO can run the
RSoP tool to access information about the resulting policies that are being processed.

41
 Chapter 2

Figure 2.15: Viewing the output of the Windows XP RSoP tool.

If you really want to give your administrators read-only access to all policy settings on a given
set of GPOs, you have another option, albeit not out-of-the-box. Using a tool such as
FullArmor’s FAZAM 2000, you can generate HTML reports of the current settings for a given
GPO. One of the benefits of FAZAM’s reporting feature is that you can script report creation.
Thus, you could very easily automate the generation of reports about your GPOs’ settings and
have the reports automatically moved to a Web site that administrators and other users can
access remotely.
To accomplish this scripting, you need to write a fairly simple Windows Script Host (WSH)
script from a Win2K or Windows XP system on which FAZAM 2000 is installed. FAZAM
installs some COM automation objects that facilitate the calling of reports from WSH scripts.
Listing 2.1 shows an example of a script that reads the settings from one of my GPOs and
outputs the results to an HTML file within my IIS Web server directories (the numbers have
been added to aid this discussion).
1. Set rptGPO= CreateObject("FAZAM2000.PolicyManager")
2. rptGPO.ReportPolicy "LDAP://CN={22684D8D-44D2-449C-9A60-
DE345A22BCB1},CN=Policies,CN=System,DC=mar-
elia,DC=com","c:\inetpub\wwwroot\gpo\Finance Users Lockdown GPO.htm",1
3. set rptGPO=nothing

Listing 2.1: A FAZAM 2000 script to automate reporting of GPO settings to an HTML file.

42
 Chapter 2

In line 1 of the listing, I instantiate an object called rptGPO from the FAZAM COM automation
object called FAZAM2000.PolicyManager. In line 2, I call a method called ReportPolicy, which
does all the work in this script. ReportPolicy is passed three arguments, including the full
Lightweight Directory Access Protocol (LDAP) path (referred to by globally unique ID—GUID)
to the GPO I want to report on (in the example, LDAP://CN={22684D8D-44D2-449C-9A60-
DE345A22BCB1},CN=Policies,CN=System,DC=mar-elia,DC=com), the path to the output file
(in the example, c:\inetpub\wwwroot\gpo\Finance Users Lockdown GPO.htm), and the type of
report to generate—a numeric 1 indicates an HTML report, 2 indicates output to an MS-Access
database, and 3 indicates output to the printer. The output of this example script is an HTML
report—part of which is shown in Figure 2.16. Line 3 simply releases the reference to the
rptGPO object.

Figure 2.16: Viewing the HTML output of GPO settings using a FAZAM 2000 report script.

This scripting mechanism is a handy way to generate automated, read-only reports about your
GPOs for everyone to see, without granting them editing rights on your GPOs.

43
 Chapter 2

Q 2.7: Is the Group Policy Object architecture extensible—can I create

new types of Group Policy Objects?
A: Yes, Microsoft designed Group Policy to be extensible, which means that a developer can
add policy functionality to a Group Policy Object (GPO). If you think about the way GPOs work,
their extensibility seems natural. GPOs store their settings in Active Directory (AD—the Group
Policy Container—GPC) and SYSVOL (the Group Policy Template—GPT). There is nothing
special to these settings; they are just AD objects with attributes or files and folders in the file
system. They have meaning to a particular GPO policy function (for example, folder redirection,
administrative templates) but otherwise these settings are nothing special. The actual work of
policy processing is done by so-called client-side extensions. CSEs are simply DLLs that are
installed on the Windows 2000 (Win2K) or Windows XP workstation or server. These DLLs do
the actual heavy lifting of policy enforcement. It is the CSE that cares about what is stored in the
GPT and GPC, and it is the CSE that can be extended to add new policy processing functionality.
Microsoft has written several canned CSEs that ship with Win2K and Windows XP. In addition,
the APIs for writing custom CSEs that extend GPO functionality are published on Microsoft’s
Web site (http://www.microsoft.com). You will have to know C++ to develop new CSEs, but it
is highly do-able! The general idea is that you build a new client-side DLL that looks at a
particular location within either the GPC (if the settings are AD-based) or the GPT (if the
settings are SYSVOL based).
For example, let’s suppose you wanted to develop a CSE that controls the behavior of an in-
house application that you have developed for your business. The CSE might read a settings file
from SYSVOL, then, based on the contents of that file, decide on certain behavior for your
application (for example, whether to show the user certain parts of the application based on
policy settings or something similar). That is the underlying flow of how a custom GPO
extension would work. You can, of course, do almost anything with policy extensions. However,
you must keep in mind that if you decide to develop a custom CSE, you will also need to develop
a Microsoft Management Console (MMC) snap-in or other type of user interface that lets
administrators set the policy for the CSE that you’ve created. For example, out-of-the box,
Microsoft not only provides a CSE for folder redirection policy but also an MMC snap-in
extension that lets administrators actually set the policy for a given GPO. MMC snap-ins and
extensions are registered on a given Win2K or Windows XP machine under the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns.
Each snap-in is registered with its unique GUID under that key. As Figure 2.17 shows, the folder
redirection editing snap-in is registered under that key and is implemented within the DLL called
fde.dll.

44
 Chapter 2

Figure 2.17: Viewing the registered MMC snap-in for folder redirection policy.

So, for you to implement your own custom CSE, you will also need to implement a companion
editor tool that lets administrators create and edit the settings for your policy.

Q 2.8: What is happening during background refresh of a Group

Policy Object and how do I change background refresh behavior?
A: Group Policy Objects (GPOs) are refreshed in the background every 5 minutes on Windows
2000 (Win2K) domain controllers and every 90 minutes on Win2K and Windows XP
workstations and Win2K servers. This cycle provides ongoing policy enforcement in the event
that a GPO’s policy settings change between normal processing cycles (machine restart or user
logon) or users manage to undo policies that they have received.
But what is actually going on during such a policy processing cycle? In fact, background
processing performs the very same operations that go on when a user boots his or her computer
or logs onto Active Directory (AD). In the background, when each refresh interval arrives (plus a
randomized interval to ensure that all machines don’t process their GPOs at the same time), the
client-side extensions (CSEs) for each policy area fire up and query AD to find out which GPOs
apply to the current user and computer. Then, as each GPO is processed, the CSEs compare the
GPO history information (described in Question 7.7) held in the registry with the current
versions of the GPOs to be processed. If the GPO has not changed since the last processing cycle
and you haven’t set administrative template policy to force the computer or user to process the
policy that the CSE implements regardless of whether it has changed, then the CSE will skip
processing of that GPO.

45
 Chapter 2

You can modify the default behavior of a CSE during regular and background refresh of policy
by setting administrative template policy for the machines whose behavior you want to modify.
The settings that control background refresh behavior for all of the default Win2K and Windows
XP CSEs are stored in Computer Configuration, Administrative Templates, System, Group
Policy.
Remember that policy processing is performed by the CSE. That is, one CSE will process all of
the GPOs that implement its policy (for example, folder redirection or administrative templates),
and then the next CSE does the same, and so on. So during the refresh cycle, some CSEs might
process many GPOs and some might not process any.
You can change the default background refresh interval for domain controllers, workstations, and
servers from the default setting. Keep in mind that the refresh interval on domain controllers is
set to 5 minutes to ensure that there is minimal latency in the updating of important policy such
as security. It’s important to keep this behavior in mind if you lengthen the background
processing interval for the security CSE.
To change the background refresh intervals, create a GPO that will apply to all machines that
you want to have a different background processing policy. You can do so by drilling into the
computer-specific Administrative Template policy, and setting either Group Policy refresh
interval for computers or Group Policy refresh interval for domain controllers (see Figure 2.18).
These policies are the same policy in both Win2K and Windows XP.

Figure 2.18: Viewing the Administrative Template policy to change the background refresh interval on
domain controllers.

46
 Chapter 2

As Figure 2.18 shows, you can also set a random time value in addition to the base refresh
interval. As I mentioned, the random time guarantees that not all machines within a particular
domain end up requesting policy at the same time. If you enter a value in minutes, the actual
random time will be any value up to the number of minutes you select. So if you select a 5-
minute refresh time and a 5-minute randomization, the actual time between policy refreshes
could be anywhere from 5 to 10 minutes.
Now let’s look at how you can change the background refresh behavior for a given CSE. As I
mentioned, normal GPO processing behavior is for CSEs to not process a GPO if it has not
changed since the last refresh period. In most cases, you can override this behavior to force a
CSE to process regardless of whether the GPO has changed. However, it’s important to
remember that not all CSEs support background refresh of policy. Table 2.1 shows which of the
most common CSEs support it and which don’t.
CSE Background Processing Support
Administrative Templates (that is, registry policy) Yes
Folder Redirection No
Internet Explorer Maintenance No
EFS Recovery Yes
Scripts No
Security Yes
Software Installation No

Table 2.1: Viewing which CSEs support background GPO processing.

As you can see from the table, there are only a few CSEs that actually support background
processing. You can adjust which CSEs are enabled for background processing by using
Administrative Template policy in Computer Configuration, Administrative Templates, System,
Group Policy (see Figure 2.19).

47
 Chapter 2

Figure 2.19: Viewing the option to disable or enable background processing of a CSE.

It’s important to note, however, that even though some CSEs, such as the Scripts CSE in Figure
2.19, show the option to enable or disable background processing, the CSE itself does not
support background processing. Your best bet is to refer to Table 2.1 to ensure that those CSEs
that you want to process in the background are actually able to do so.

48
 Chapter 3

Chapter 3: Creating and Editing GPOs

Q 3.1: How can I create a Group Policy Object that is not linked to a
container object?
A: Normally, when you create a new Group Policy Object (GPO), you are focused on a
particular container object in Active Directory (AD—for example, a site, domain, or
organizational unit—OU). Thus, when you create the GPO, it is automatically linked to that
container object at creation time. This link might not be desirable, so I’ll show you a way to
create in AD a new GPO that isn’t linked to a site, domain, or OU.
The normal process for creating a GPO is as follows:
1. Start the Microsoft Management Console (MMC) Active Directory Users and Computers
snap-in or Sites and Services snap-in, and highlight the container object on which you
want to create the new GPO.
2. Right-click that container object, select Properties, and in the resulting window, select the
Group Policy tab.
3. Click New, and name your new GPO.
Once you click New, the Group Policy Container (GPC) and Group Policy Template (GPT) that
make up the GPO are created. In addition, an attribute on that container object called gpLink is
modified to add the globally unique ID (GUID) for that GPO to its list. Once the GPO is linked,
it is “live” on your AD infrastructure.

When you create a GPO normally, it is automatically linked to a site, domain, or OU and is “live” as
soon as you create it. This process can lead to problems with controlling the use of the GPO prior to
fully editing it. Consider creating the GPO without linking it to a container first.

That is, any changes you make to your new GPO are instantly available for processing by
computers and users on your network. This availability makes staging of new GPOs
problematic—you may want to choose the time when your new GPO is active in production. It is
useful to be able to create a new GPO, edit it the way you want, then link it to one or more
container objects when you’re ready. There are a number of similar approaches you can use to
create an unlinked GPO. The following steps show one of those approaches to create a new,
unlinked GPO in AD.
1. From the Start menu, select Run, then type mmc.exe in the text box to start a blank
Microsoft Management Console (MMC) console.
2. From the MMC Console menu, select Add/Remove Snap-in, and on the Standalone tab,
click Add.
3. From the list of available standalone snap-ins, navigate to Group Policy, and click Add.
4. On the Select Group Policy Object dialog box, click Browse to browse available GPOs in
your AD domain.

49
 Chapter 3

5. Select the All tab to view all current GPOs. Then, with your mouse in a white space
within the All GPO dialog box, right-click, and select New from the properties menu, as
Figure 3.1 shows.

Figure 3.1: Creating a new, unlinked GPO in AD.

6. Once you’ve created the new GPO and renamed it, you will now have a GPO that is not
linked to any particular container object.
To edit this new, unlinked GPO, you will need to load the Group Policy MMC snap-in as you did
in the previous steps, navigate to the All tab, right-click the unlinked GPO, and select Edit from
the context menu. Let’s now assume that you’ve edited the new, unlinked GPO, and you want to
link it to an OU called HQ in your AD domain. Follow these steps to give the GPO a home:
1. Start the Active Directory Users and Computers MMC snap-in. Right-click the OU (or
another container object) that you want to link to the GPO.
2. Choose Properties from the context menu, then select the Group Policy tab.
3. Click Add to link the new GPO to this OU. From the Add a Group Policy Object Link
dialog box, select the All tab to find your newly created, unlinked GPO.
4. Highlight the GPO, and click OK to complete the linking process, as Figure 3.2
illustrates.

50
 Chapter 3

Figure 3.2: Linking a GPO to an AD container object.

Once you’ve completed the linking process, the GPO is now “live” on your AD network and can
be processed by users and computers.

Q 3.2: How can I set account policy on a domain?

A: In Windows NT 4.0, setting the account policy on a domain had absolutely nothing to do
with System Policy. Rather, you used the User Manager for Domains tool to create and edit
account policies, such as required password length and account lockout counts.
However, in Active Directory (AD) domains, you must use Group Policy to set account policy
on a domain. In fact, the domain’s account policy must be set at a Group Policy Object (GPO)
linked at the domain level only. It cannot be set on a GPO linked at either site or organizational
unit (OU) levels (though you can set account policy for local workstations and servers at the OU
or site level). By default, when you install AD, it installs a GPO called the Default Domain
Policy, as Figure 3.3 shows.

51
 Chapter 3

Figure 3.3: Viewing the Default Domain Policy GPO created when you install AD.

This Default Domain Policy GPO is the ideal place to create your account policy, as it is a
special GPO. This GPO is special because it can’t be deleted—even if you accidentally try to
delete this GPO, your command is ignored and the GPO remains. Thus, you know that the
account policy defined in this GPO is always available and enforced. Of course, you can also
create your own domain-linked GPO to define account policy.
The important thing to know about account policy in AD is that it can apply to domain
controllers as well as member servers and workstations. Thus, if you set a minimum password
length policy on a domain-linked GPO that is processed by both AD domain controllers and
member servers or workstations, you will be required to use that minimum password length
regardless of whether you are logging onto the domain (handled by the domain controller) or
logging on to a local workstation or server. This behavior is important because it means that if
you want to have two separate account policies—one for domain controllers (that is, for domain
authentication) and one for local workstation or server accounts, you would need to define two
separate, domain-linked GPOs, then use security group filtering to control which set of machines
processes which account policy.

52
 Chapter 3

To illustrate how you can create a domain account policy, let’s walk through the process of
defining minimum password length and password age on an AD domain.
1. The first step is to open the Active Directory Users and Computers Microsoft
Management Console (MMC) snap-in tool, focused on your AD domain.
2. Right-click the domain name within the left-hand scope pane of the tool, and choose the
Properties context menu.
3. Select the Group Policy tab, and you see a dialog box showing all the GPOs currently
linked at the domain level of your domain. At the very least, you should see the Default
Domain Policy GPO described earlier. Let’s use that GPO for our example.
4. Highlight the Default Domain Policy, and click Edit to start the Group Policy editor tool,
focused on the GPO.
5. Next, expand the Computer Configuration node within the left-hand scope pane of the
Group Policy tool, and drill into Windows Settings, Security Settings, Account Policies,
Password Policies.
6. After you’ve highlighted the Password Policies node, you should see the dialog box that
Figure 3.4 shows.

Figure 3.4: Viewing Account Policy settings within a GPO.

7. To set the password length, we need to double-click the Minimum Password Length
policy item in the right-hand results pane, and set the value to the minimum number of
characters required for a password.
8. To set the password age, we need to double-click the Maximum Password Age policy
item, and set it to the number of days after which the password is considered expired.

53
 Chapter 3

Once you’ve set the policy within the GPO, the new account policy will go into effect on the
domain the next time an AD domain controller processes the GPO, which is typically every 5
minutes during the background GPO refresh cycle. That’s all there is to setting account policy in
an AD domain!

Q 3.3: How do I use the restricted groups feature in Group Policy

Object security policy?
A: Restricted groups are part of Group Policy Object (GPO) security policy and let you control
membership in groups on workstations and servers in your Active Directory (AD) infrastructure.
The goal of the restricted groups feature is to give you the ability to control group membership
on machines managed by GPO such that, if a user tries to put his or herself into a group in which
the user doesn’t belong, at the next policy processing cycle, the restricted Group Policy will
automatically remove the user. This feature can be handy, but there are some limitations within
the restricted group feature. Before we discuss these limitations, let’s look at how you can set
restricted Group Policy.
As I mentioned, restricted Group Policy is part of computer-specific security policy. You can
find it within a GPO under Computer Configuration, Windows Settings, Security Settings,
Restricted Groups, as Figure 3.5 shows.

Figure 3.5: Viewing restricted Group Policy within a GPO.

54
 Chapter 3

Let’s create a new restricted Group Policy that controls the membership of an administrative
group. If you want to add a new restricted Group Policy, right-click the Restricted Groups node,
and select Add Group. The group that you select here is the group that you want to manage via
Restricted Groups—the target group. With restricted Group Policy, you can do two things with
the group you choose here. You can set which users or groups are allowed to be a member of this
group. And you can choose which groups you want this chosen group to be a member. After I
select the group in the Add Group dialog box, the new group is added to the right-hand results
pane that Figure 3.5 shows.
The next step is to define the actual policy. To do so, right-click the selected group, and choose
Security. You will then see a dialog box like that shown in Figure 3.6.

Figure 3.6: Viewing the dialog box for setting restricted Group Policy.

This dialog box lets you perform the two operations I mentioned earlier. The Members of this
group section says, in effect, the users and groups I choose here are the only users and groups
that can be placed in this target group.
For example, suppose I have a domain local group called MyAdmins. On a GPO that is
processed by the domain controller, I create a restricted Group Policy that says that only the
Finance Admins group can be a member of MyAdmins. This policy means that when the domain
controllers process this GPO, if there are any users or groups that are currently a member of
MyAdmins, they will be removed, and the Finance Admins group will be put in their place! As
you can imagine, this policy is powerful and has much potential for damage.
For example, suppose you define a restricted Group Policy that was processed by the domain
controllers in your domain that says that the domain local Administrators group will only contain
the Finance Admins group. When the domain controllers in your domain process that policy, all

55
 Chapter 3

of the existing members of the domain local Administrators group—including the domain
administrator account, domain admins, and enterprise admins—will be removed and replaced by
Finance Admins! As you can imagine, this functionality could cause problems.
The second feature within restricted Group Policy is less powerful. The This group is a member
of section says that you always want the target group to be a member of a chosen list of groups.
For example, if we reverse the earlier scenario, suppose I want the Finance Admins group to
always be a member of the MyAdmins group, but I don’t want to affect the current members of
MyAdmins. If I choose the Finance Admins group as the target for my restricted Group Policy,
then add MyAdmins to the This group is a member of list, the next time the domain controller
processes the GPO, Finance Admins will be added to the MyAdmins group, and any other
groups or users in MyAdmins will remain intact. Figure 3.7 shows what this policy would look
like.

Figure 3.7: Using restricted groups to make sure one group is always a member of another.

Keep in mind that you can use restricted Group Policy to control membership in domain groups
as well as groups on workstations and servers. If you’re trying to control domain group
membership, you need to define the policy on a GPO that is processed by your AD domain
controllers (the easiest thing to do here is to link the GPO to the Domain Controllers OU). If you
want to control workstation or member server local group membership, you’ll need to do so on a
GPO linked to a container that includes those workstations and member servers. If a machine
processes a restricted Group Policy for a group that it does not know about (for example, a
domain controller processes a policy for a local group defined on a member server elsewhere in
the domain), that policy is simply ignored.
Another thing to keep in mind with restricted Group Policy is that it is processed just like other
GPO-based security policy. Domain controllers, workstations, and member servers will process

56
 Chapter 3

the policy on system startup, and domain controllers process security policy in the background
every 5 minutes (workstations and servers do background processing every 90 minutes).
However, keep in mind the following scenario: You set up a restricted Group Policy that makes
the group Finance Admins a member of the domain local Administrators group. The policy is
processed by the domain controllers and Finance Admins is added to the domain local
Administrators group. Then, a domain admin comes around, wonders why Finance Admins is in
the domain local Administrators group, and removes it. You would expect that, during the GPO
processing cycle, the restricted Group Policy would again add the Finance Admins group to the
domain local Administrators group. However, by default, such is not the case because, by
default, GPOs whose version numbers have not changed since the last processing cycle will not
be processed. Thus, only if a change is made to the GPO will that restricted Group Policy be re-
enforced.
There is one way, however, to force security policy to be refreshed during every processing cycle
regardless of whether the GPO has changed. You can set an Administrative Template policy to
force this processing behavior. That Administrative Template policy is found in Computer
Configuration, Administrative Templates, System, Group Policy , Security policy processing
under both Windows XP and Windows 2000 (Win2K). Figure 3.8 shows how you set this policy
to force background refresh regardless of whether the GPO has changed.

Figure 3.8: Setting Administrative Template policy to force background security policy to refresh.

After you’ve made the change to this Administrative Template policy, any inadvertent changes
to restricted Group Policy will be automatically undone each time the GPO is reprocessed
regardless of whether it changes. This Administrative Template policy is probably a good one to
use for security policy processing in general because you typically want to make sure it’s as up-
to-date as possible.

57
 Chapter 3

Q 3.4: How do I use Administrative Templates policy to lockdown my

desktops?
A: Just as in Windows NT 4.0 system policy, you can easily use Administrative Template policy
within your Group Policy Objects (GPOs) to restrict certain aspects of the user’s desktop. In fact
Windows 2000 (Win2K) and Windows XP GPOs provide so many different desktop control
policies, that it’s hard to keep them all straight. But before I show you how you can use these
policies to support desktop lockdown, I want to explain exactly what desktop lockdown
provides.
Since Windows 95, desktop lockdown through policy was a way for enterprise administrators to
restrict which knobs and dials within Windows a user can futz with. The thought was that the
fewer buttons the user could press, so to speak, the less chance there was that the user would do
something that would require a call to a Help desk or visit from a support person. Thus,
Microsoft provided desktop lockdown policies as a way of hiding various elements of the
Windows shell environment. It’s important to note that desktop lockdown, for the most part, is
just obfuscation. It is not real system security and cannot substitute for real system security. For
example, a common desktop lockdown policy lets you hide the drives that a user can see within
the My Computer dialog box. The industrious user can still access those drives using any number
of methods outside of My Computer. On the contrary, if you used NTFS security to lockdown
which files and directories to which a user has access, you are providing real security rather than
simply hiding access to the drive via the most common mechanism. Such is true for most all of
the desktop lockdown policies that are available in Administrative Templates. Some of the
policies require a little more work to get around, but the bottom line is that you shouldn’t rely on
them to keep your users (and especially your power users) from sensitive material. Now that we
know desktop lockdown’s limitations, let’s look at how you can use the feature to restrict your
users’ desktops.
There is no one category that corresponds to desktop lockdown within Administrative Template
policy. In general, any policy settings that restrict users from performing some task on their
desktops that they would normally be able to do qualify as desktop lockdown. Administrative
Template settings are broken down into policies and preferences (see the description of the two
in Question 1.2). Desktop lockdown policy may be either policies or preferences, but are
generally implemented by Microsoft as policies to prevent them from tattooing the registry if the
policy no longer applies. In Windows XP, most of the common user-specific desktop lockdown
settings can be found in User Configuration, Administrative Templates, Windows Components,
Windows Explorer (see Figure 3.9) and User Configuration, Administrative Templates, Desktop.

58
 Chapter 3

Figure 3.9: Viewing the desktop lockdown policies in Windows XP.

The process for enabling desktop lockdown is really quite simple, but the number of “knobs and
switches” you can throw can be daunting. As you can see in Figure 3.9, there are a myriad of
aspects of the user shell that you can control. Remember that Administrative Template policy
settings have three options—Not Configured, Enabled, and Disabled. Not configured means just
that—the policy setting is left unset. The meanings of Enabled and Disabled can be confusing
because their effects vary depending upon the policy. For example, in Figure 3.9, the policy item
called Remove DFS tab lets you remove the Dfs option from wherever they appear in the
Windows Explorer. To enable this policy, you simply select the policy item and select the
Enabled check box. If you disable this policy, it means that the Dfs tab can’t be removed from
the Windows Explorer shell (not that anyone would actually try).
However, it gets tricky when you try to apply this rule to policies that are worded “negatively.”
For example, what happens when you enable the Do not request alternate credentials policy?
Enabling this policy means that the alternative credentials prompt isn’t presented to a user when
the user doesn’t have sufficient rights to install software on his or her computer. Clear?! So
disabling this policy means that the user is always presented with the alternative credentials
prompt when the user doesn’t have sufficient rights to install software. It can get very confusing
very quickly.

Darren’s Desktop Lockdown Rules

As I mentioned, there are a myriad of desktop lockdown options available in Group Policy—
almost too many if you ask me. With such in mind and based on experience deploying desktop
lockdown in the NT 4.0 and Win2K environments, I’ve created a few rules to help guide your
use of desktop lockdown. These are good rules to follow if you’re just starting out with Group
Policy–based lockdown or if you are trying to unravel lockdown gone awry.

59
 Chapter 3

1. Stick to the minimum amount of desktop lockdown you need to keep your users from
futzing. Less is more in this case. You don’t want to spend as much time troubleshooting
and answering user calls as to why they can’t do something that’s been locked down as
you would deal with the results of their futzing. If you think you need to lock something
down, think again.
2. As a corollary to Rule 1, the best defense against user futzing is to use real security (that
is, file system and registry security) to protect desktop resources. No amount of desktop
lockdown policy is going to help you if you make all yours users Administrators on their
desktops.
3. Avoid having desktop lockdown policy in multiple GPOs that contradict each other as
they are applied to users. For example, if you have a GPO linked to the domain that
removes the Run option from the Start menu and another GPO linked to an OU that puts
it back for only certain users, you will have a very difficult time troubleshooting—
especially if you’ve configured this setup for 40 or 50 policy items. If you choose to take
this path, make sure you have a very good Resultant Set of Policy (RSoP) tool (for
example, FullArmor’s FAZAM or the RSoP tools built into Windows XP) at your
disposal.
4. As a corollary to Rule 3, if you have contradicting policies linked to different levels of
your infrastructure, try to avoid further complicating things by then using security groups
to filter the effects of those GPOs.
5. In the end, what you will likely find is that you’ve overly restricted what your users can
do. However, it may be easier to ease restrictions over time than to increase them. The
best solution is to choose a set of lockdowns that gives you the protection you need for
your environment, and no more. Then put it in front of your users and get their
acceptance on what you’ve done. User acceptance testing of your desktops cannot be
underrated!

Q 3.5: How can I distribute Group Policy Object changes in a non-

Active Directory environment?
A: Ordinarily, changes to Group Policy Objects (GPOs) rely on an Active Directory (AD)
infrastructure to propagate to and policy all users and machines in a domain or forest. However,
there is some allowance for manually distributing some GPO policy to non-AD domain-based
machines.
As you know, every Windows 2000 (Win2K) and Windows XP system has a local GPO that
contains a subset of the policy settings and capabilities available on AD-based GPOs; however,
software installation and folder redirection are not supported in local GPOs. Notwithstanding
these missing pieces, local Group Policy has many of the important features you might want or
need on non–AD–based machines (for example, security and administrative templates). There
might also be compelling reasons why you don’t want to put a particular Win2K or Windows XP
machine in an AD domain. For example, many enterprises often opt not to create a domain when
they place Win2K servers on DMZ segments exposed to the Internet. In such cases, you can
choose not to deploy AD, but you might still want to leverage Group Policy to configure a group
of machines. So what can you do? The solution is actually quite simple—you can copy the

60
 Chapter 3

contents of a local GPO between machines to ensure that policy changes are deployed
consistently across many non–AD–based machines.
First, you need to know where the policy files for the local GPO are stored. On both Win2K and
Windows XP systems, the local GPO can be found in %systemroot%\system32\GroupPolicy. As
you can see in Figure 3.10, the contents of the local GPO look very similar to what you find in
the Group Policy Template (GPT) portion of an AD-based GPO. (In Windows Explorer, the
%systemroot%\system32\Group Policy folder is hidden by default. Make sure you enable the
option to view hidden files and folders to see this folder.).

Figure 3.10: Viewing the contents of a local GPO on a Windows XP workstation.

As Figure 3.10 shows, the local GPO contains three folders and a file. The gpt.ini file holds the
current version information for the local GPO. The Adm folder holds the .adm template files in
use for this GPO. The Machine and User folders contain the current policy settings for this local
GPO for the computer and user configuration portions of the GPO. If you drill into both the
Machine and User folders, you will find the registry.pol file that contains the current
Administrative Template settings as well as other folders for startup and shutdown or logon and
logoff scripts and Internet Explorer (IE) maintenance and remote installation options. What you
won’t find is a file corresponding to per-machine security settings such as account policy, local
user rights, or password lockout. The reason is that, unlike Administrative Template policy,
which is stored in the registry.pol file, changes to local GPO security settings are made against
the live Security Account Manager (SAM) database that resides on the machine. Therefore, as
we discuss how to copy local GPO settings from one machine to another, you won’t be able to
copy security settings across machines using the same mechanism. Indeed, the only way to
“copy” security settings across machines in a non-AD environment is to use a mechanism such
as the Microsoft Management Console (MMC)-based Security Configuration and Analysis tool,
or its companion command-line version—the secedit.exe utility.
For our example, let’s suppose you want to copy Administrative Template policy settings to a
group of non-AD machines. The process is fairly straightforward. First, you need to ensure that
you have the Administrative Template settings that you desire on your “prototype” machine. The
easiest and quickest way to edit the local GPO is to type gpedit.msc from the Start menu Run text
box. Doing so will bring up an MMC tool focused on the local GPO.

61
 Chapter 3

Next, you’ll need to edit the Administrative Template policy as you want it to appear on all
machines. Make note as to whether you’re editing computer-specific policy, user-specific policy,
or both. After you finish editing the policies, you’re ready to copy your prototype settings to the
destination machines. If you edited computer-specific policy only, you will need to copy only the
registry.pol file from %systemroot%\system32\GroupPolicy\machine. If you also edited the user-
specific policy or only edited the user-specific policy, you’ll need to copy registry.pol from
%systemroot%\system32\GroupPolicy\user. In either case, copy the required registry.pol file
from the folders on your source machine to the identical folders on all target machines. Any
existing Administrative Template policy set locally on the target machines will be overwritten
when you copy the new files.
If you created any custom .adm template files on your source machine, you’ll need to copy them
to the target computer(s) in addition to copying the registry.pol files. This step is important to
remember because after you’ve copied the policy files to the target machines, if anyone were to
edit those local GPOs, they would not see all the correct policy settings if the adm files that were
used to create the source GPO are missing. Copy any custom .adm files from
%systemroot%\system32\GroupPolicy\adm to the same folder on the target machine. Then,
when an administrator edits the local GPO on the target machines, the administrator will need to
ensure that the custom .adm file is loaded.
There is one more piece of the puzzle that needs to be completed before your copied policy is
functional. Local GPOs keep version information about themselves just as AD-based GPOs do.
This information is kept in the gpt.ini file in the root of the local GPO folder. If the version
number held in this file (shown as Version in Listing 3.1) is 0, local GPO processing will be
skipped during machine startup or user logon. Such is typically the case on new Win2K and
Windows XP machines.
[General]
gPCFunctionalityVersion=2
gPCMachineExtensionNames=[{35378EAC-683F-11D2-A89A-
00C04FBBCFA2}{0F6B957D-509E-11D1-A7CC-0000F87571E3}{53D6AB1D-2488-11D1-
A28C-00C04FB94F17}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1D-
2488-11D1-A28C-00C04FB94F17}]
Version=196639
gPCUserExtensionNames=[{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE-
7020-11D2-842D-00C04FA372D4}][{35378EAC-683F-11D2-A89A-
00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}][{A2E30F80-D7DE-
11D2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-00A0C90347FF}]

Listing 3.1: Viewing the contents of a local GPO’s gpt.ini file.

In Listing 3.1, the version number shown is 196639. When you’re copying local registry.pol files
to target machines, you also need to edit the gpt.ini file on those machines to ensure that the
value is not 0. Although GPOs use a fairly elaborate scheme to calculate versions (the version
number is incremented 1 for each computer-specific change and 65536 for each user-specific
one), you don’t need to worry about whether you provide the correct version number as long as it
is a non-0 value. To be safe, set the version value to 65537 (65536+1) so that both user and
computer sides of the GPO have changed. This setting will ensure that the local GPO is
processed on the next cycle.

62
 Chapter 3

Q 3.6: How do I use Internet Explorer Maintenance policy?

A: Internet Explorer (IE) Maintenance policy provides similar functionality to the standalone IE
Administration Kit (IEAK), and lets you enforce browser configurations and branding across
your Windows 2000 (Win2K) or Windows XP desktops. IE Maintenance policy supports two
modes of operation—maintenance and preference. Maintenance mode is meant to provide
mandatory, non-changeable settings for various browser configuration options. If the user
changes a maintenance-mode policy, that policy will be reset the next time the Group Policy
Object (GPO) containing that policy is processed. Preference mode is less strict. It lets me
deliver IE Maintenance policy settings one time to a user; after that initial setting, the policy is
no longer enforced and the user may change settings as he or she sees fit.
You must choose one mode. If preference mode is enabled for a given GPO, maintenance mode
is not. Both IE maintenance and preference mode policies are per-user settings and can be found
under User Configuration, Windows Settings, Internet Explorer Maintenance (see Figure 3.11—
you must right-click the Internet Explorer Maintenance node to select the preference option).
Again, you can only choose one mode within a single GPO.

Figure 3.11: Viewing IE Maintenance policy in a Win2K GPO.

You can, of course, have two GPOs that apply to a user, and you can specify a different mode in
each of those GPO. IE Maintenance policy is meant to be used with IE-related Administrative
Template policies. The IE-related Administrative Template policies can be found at Computer

63
 Chapter 3

Configuration, Administrative Templates, Windows Components, Internet Explorer and User

Configuration, Administrative Templates, Windows Components, Internet Explorer. The
Administrative Template policies are meant to let me lock down which settings a user can fiddle
with in IE; then maintenance-mode IE Maintenance policy controls what the various
configuration options in IE should be. I can also use Administrative Template policy with
preference-mode IE Maintenance policy to control which settings a user can freely modify after
the initial policy setting.
For example, let’s see how I can use IE Maintenance policy to set a certain proxy configuration
on your user’s browser, then use Administrative Template policy to prevent the user from
changing his or her proxy settings. The first step is to use IE Maintenance to set the proxy
information. Within your GPO, drill to User Configuration, Windows Settings, Internet Explorer
Maintenance, Connection, Proxy Settings. From here, I can configure manual proxy information
for IE (see Figure 3.12).

Figure 3.12: Setting IE Maintenance proxy policy.

After you’ve configured the proxy information, you can restrict the user from changing his or her
proxy settings by using Administrative Template policy. To do so, drill down to User
Configuration, Administrative Templates, Windows Components, Internet Explorer, and enable
the Disable changing proxy settings policy. In this case, you should also enable the Disable
changing automatic configuration settings policy so that the user has no ability to modify proxy
settings and auto-proxy settings. After you’ve completed configuring these settings, a user who
logs onto his or her Win2K workstation and processes this GPO will have browser proxy settings
as Figure 3.13 shows.

64
 Chapter 3

Figure 3.13: Viewing locked-down browser proxy settings.

As Figure 3.13 shows, not only is the manual proxy server set to the setting that we specified in
Figure 3.12, but the whole dialog box is grayed out and cannot be changed by the user.
So far, I’ve talked only about maintenance mode IE Maintenance policies. Let’s look at how we
can enable preference-mode policies. To do so, simply right-click the Internet Explorer
Maintenance policy node within a GPO, and select Preference mode.

If you already have IE Maintenance policy on the GPO, you will need to first select the Reset Browser
settings context menu item to clear all current IE Maintenance mode settings. Alternatively, you
should create a new GPO to house your preference-mode settings separate from your maintenance-
mode ones.

With preference-mode enabled, you will now see an additional policy option under the IE
Maintenance node, called Advanced. The Advanced policies let you control additional IE
settings that are not exposed via maintenance-mode policies (see Figure 3.14).

65
 Chapter 3

Figure 3.14: Viewing Advanced IE Maintenance policy settings exposed in preference mode.

Because these advanced options are only implemented in preference mode, the user will be able
to change them unless you disable the underlying functionality by using Administrative
Template lockdown. Typically, when designing your IE Maintenance policy, you will end up
using some combination of maintenance-mode and preference-mode GPOs along with a
sprinkling of Administrative Template lockdown to get the perfect IE configuration for your
users.

Q 3.7: How can I use Group Policy to ensure that certain scripts are
executed each time users log off or shut down their computers?
A: Group Policy Objects (GPOs) provide for computer-based startup or shutdown and user-
based logon or logoff scripts. Using these scripting capabilities, you can “trap” for logoff and
shutdown events and perform actions based on them. In Windows NT 4.0, I can’t tell you how
many times I wanted a way to perform some action, like killing a process or running an
environmental cleanup script, before the user ended their session either by shutting down or
logging off. With Active Directory (AD)-based GPO in Windows 2000 (Win2K) and Windows
XP, it is easy to do so.
GPO-based script policy can support any number of “executable” types, from DOS-style batch
files to Perl scripts to Windows Script Host (WSH) scripts, and even compiled executables. This
functionality provides for a lot of power in executing tasks based on these types of user-driven
events. Creating startup/shutdown or logon/logoff policy is easy. After you start the Group
Policy editor tool, navigate to either Computer Configuration, Windows Settings\Scripts,
(Startup/Shutdown) or Computer Configuration, Windows Settings\Scripts, (Logon/Logoff).

66
 Chapter 3

Deciding whether you need to use a shutdown script or a logoff script is more than just deciding
when you want the script to run. Computer-based scripts run with a different security context
from user-based ones. Namely, computer-based scripts run under the security context of
LocalSystem, and user-based scripts run under the context of the logged on user. Thus, startup
and shutdown scripts have privileges to do pretty much anything they want on the local
computer, but logon and logoff scripts are limited to what the user can do. However, because
shutdown and startup scripts run in the context of LocalSystem, they cannot access other
Windows resources located remotely from where they’re running. It’s important to understand
that both logoff and shutdown scripts execute at the beginning of the logoff and shutdown
processes, respectively. Thus, they should have the entire environment they need to perform their
tasks. However, it’s always a good idea to test your scripts first—I have found cases in which
certain commands did not work because they made assumptions about the environment that were
no longer valid. This scenario is especially a possibility for shutdown scripts.
You also need to be aware that shutdown and logoff scripts always run synchronously. That is,
when the scripts start running, no other tasks are happening in the background that might affect
the scripts proper execution. This behavior makes sense because Windows might start shutting
down valuable resources required for a shutdown or logoff script to execute if those scripts were
allowed to run asynchronously, as startup and logon scripts can.

If you want to enable shutdown scripts on your Win2K domain controllers, be aware of a particular
twist in the way GPOs are processed on domain controllers. You will need to implement your
shutdown scripts within the built-in Default Domain Controllers Policy GPO. If you try to implement
shutdown scripts on domain controllers in another GPO, it will simply be ignored.

If you need to provide some kind of user dialog box within your logoff or shutdown scripts, be
aware that depending upon the type of dialog box that you display, your users might not see it.
For example, if you’re running a WSH script and you use the Wscript.echo method to output a
dialog box for the user to confirm, the dialog box will appear only as a popup box that waits for
user response if your default WSH script executable is Wscript.exe rather than Cscript.exe. If
you need to show the user a dialog box for confirmation as part of your WSH script, you’re
better off using the VBScript msgbox function or its equivalent in JScript.

If you expect a user to confirm a script dialog box, especially during a shutdown script, make sure that
there is a good chance that a user is actually present when the script executes. If no user is present
to confirm a dialog box or answer a question, the script will just sit there until the default 10 minute
timeout passes, at which point the script will be killed and Windows will continue the logoff or
shutdown sequence.

If, for troubleshooting purposes, you want to see the command window that is running behind
the scenes when your scripts execute, you can set a computer- or user-specific administrative
template policy to show verbose script execution. This policy can be found in Computer
Configuration, Administrative Templates, System, Scripts (run startup scripts visible and run
shutdown scripts visible) or User Configuration, Administrative Templates, System, Scripts (run
logon scripts visible or run logoff scripts visible). Figure 3.15 shows how you can enable visible
script execution for shutdown scripts.

67
 Chapter 3

Figure 3.15: Enabling verbose shutdown script execution through administrative template policy.

Enabling visible processing of scripts doesn’t change the behavior of any user dialog boxes that
the scripts may generate. Visible processing simply shows the command window that is
generated by a batch file or other command shell driven script. It can be valuable for
troubleshooting if your script sends status messages to a command window during execution.
Now let’s look at the process for enabling shutdown or logoff scripts. The dialog boxes for
selecting and finding scripts within Group Policy are less than intuitive. Keep in mind that the
script files—whether they are batch files or WSH scripts—are stored within the Group Policy
Template (GPT) in SYSVOL for each GPO that references the script. So if you have a script that
is implemented in 10 GPOs, the script file will be stored 10 times within the GPTs of those 10
GPOs. Figure 3.16 shows the dialog box for adding a logoff script to a GPO. All of the types of
scripts supported in Group Policy follow the same pattern for adding scripts.

68
 Chapter 3

Figure 3.16: Viewing the dialog box for adding scripts to a GPO.

As you can see in Figure 3.16, it’s perfectly “legal” to have different types of scripts within a
GPO. It’s also perfectly legal to have multiple scripts assigned to a single GPO (and, of course, a
user or computer can also process multiple GPOs, leading to many scripts running during a
logoff or shutdown sequence). When you have multiple scripts on a given GPO, they process in
order from those higher in the list to those lower. So, with the setup that Figure 3.16 shows,
shut.vbs runs first and new.bat runs second.
If you want to add a new script to the list, there are a few tricks you can use. If you click Show
Files, a Windows Explorer windows will open focused on the SYSVOL folder in which the
scripts are stored (see Figure 3.17).

69
 Chapter 3

Figure 3.17: Viewing the GPT folder within a GPO where logoff scripts are stored.

If you have scripts located in other folders, you can simply copy and paste them into this folder.
That is the first step in the process. The next step is to add the new script to the list of scripts
being processed by this GPO. This list is the list that you see in the top half of Figure 3.16. To
add the new script, click Add, then click Browse. You will be taken to an open file dialog box
focused on the GPT folder in which you just pasted your new script. From here, you simply
highlight the script, and select Open to add the script to the list of those being processed by the
GPO. You can also add to the script any command-line parameters, which are parameters that
you might want to pass to the script as its executing (see Figure 3.18).

Figure 3.18: Adding command-line arguments for script execution.

If you haven’t already pasted the script that you want to add to the GPO into the correct folder in
the GPT, there is an alternative way to call a new script. If you click Add, as before, then click
Browse, you can browse the file system to locate the script that you want to add. In that case, the
GPO will run the script from wherever the script is located (see Figure 3.19).

70
 Chapter 3

Figure 3.19: Adding a script from an alternative file location.

In the example scenario that Figure 3.19 shows, I’ve added a script called listGPO.vbs from the
C:\ folder. The problem with this scenario is that that script needs to be in C:\ on every machine
that the GPO processes on—or it won’t be found. An alternative approach is to reference a script
located on a server share somewhere on your network and accessible from all machines.
However, keep in mind that if you take this approach, the script will not be accessible from a
computer-based startup or shutdown script policy, because they are running under the
LocalSystem security context and won’t have access to network shares. I suggest that in most
cases you simply copy your scripts into the GPT for that GPO so that the scripts can be
replicated with the rest of your GPOs. The only case in which it makes a lot of sense to have a
script referenced from a network share is when that script changes often and is used by many
different GPOs. In such a case, having to keep the script synchronized across many different
GPTs would be difficult.

Q 3.8: Can I use Group Policy Object-based software installation to

deploy a Windows service pack?
A: In fact, you can! This process is fairly straightforward as long as the service pack provides an
.MSI file that can be run to perform the update. Most Windows service packs provide a file
called update.msi that can be used in a Group Policy Object (GPO)-based software installation
policy to deliver service pack updates to workstations or even member servers.

71
 Chapter 3

The key is that you need to deploy the service pack using a machine-based assignment rather
than any other mode within software installation. Machine assignment means that at the next
reboot, the computer will process its GPOs and when it comes across the service pack update
that has been defined, will run the update before the user can logon. Typically at the end of the
update and before the user can log on, a reboot is triggered to complete the service pack update. I
will provide the steps you can follow to update a Windows 2000 (Win2K) or Windows XP
workstation to a new service pack using GPO-based software installation. The very first task you
need to do is get the network install version of the new service pack. This version usually comes
in an executable file format. Once you have this file, copy the service pack file into a directory
on the server that will source the service pack update. This directory could be a folder that is
replicated or made available via Active Directory (AD)-based Distributed File System (DFS).
Extract the files into the folder using the –x option (for example, xpsp1_en_x86.exe –x).
After the files are extracted, the file of interest will usually be stored in the i386\update folder
within the service pack files and be called update.msi. Locate that file. Open the Group Policy
editor tool focused on the GPO that will be used to deploy the service pack update, and drill into
Computer Configuration, Software Settings, Software Installation. Right-click the software
installation node, and choose New, Package. When you enter the path to update.msi, make sure
you refer to it using a relative path, such as a UNC path (for example,
\\server\packages\sp3\update.msi, rather than an absolute path, like c:\sp3\update.msi).
After you choose the .MSI file, you will see a dialog box that lets you simply assign the package
or choose other options using Advanced published or assign. I always choose the latter as it gives
me the chance to review all of my options before committing the application.
Within the advanced options screen, you can change various behaviors of the deployment (see
Figure 3.20). For example, if you only wanted this service pack update to go to a select group of
machines, you could select the Security tab and adjust permissions such that only the computer
or group of computers that you want to target have read permissions on this package.

72
 Chapter 3

Figure 3.20: Viewing the application deployment options within Group Policy software installation.

As you can see in Figure 3.20, I don’t want to select the Uninstall this application when it falls
out of the scope of management check box. Doing so would be bad because most service packs
shouldn’t be uninstalled just because the workstation or server is no longer processing a GPO.
When you’ve got all the options set the way you want them, click OK, and the application will
be live and available for deployment to the next workstation or server that is restarted.
Remember that software installation policy does not process during normal GPO background
refresh, so you will need to restart your computers to have this policy be processed.
When your computers restart, you should see a message in the Windows banner that comes up
before the logon screen is presented, indicating that the service pack is being installed. If you
don’t see such a message, the GPO that is offering the service pack is probably not being
processed. You can look in the userenv.log file in the %systemroot%\debug\usermode folder to
determine whether the GPO is actually being processed, and if so, which, if any, errors might be
preventing the update from installing. If you’re planning to deploy a service pack to a number of
machines in your environment using this method, expect the installation to take a while to
complete. You might want to time it such that you deploy the service pack at the end of a
business day and either force a reboot of all target workstations after your users leave or have the
users perform a shutdown/restart as they’re leaving.

73
 Chapter 4

Chapter 4: Designing a GPO Infrastructure

Q 4.1: How can I have version control for my Group Policy Objects?
A: Although Windows 2000 (Win2K) and Windows XP don’t include a built-in version-control
system for managing changes to your Group Policy Objects (GPOs), there are several low- and
high-tech approaches you can take to ensure a consistent GPO environment. A key factor in the
success of designing and deploying a substantial GPO-based infrastructure is the ability to
manage and maintain that infrastructure over time. Similar to other aspects of your IT
infrastructure, you need to be able to track and document changes to GPOs, and support formal
release-management processes that most companies require. Unfortunately, there are no
mechanisms within the GPO product to do so; thus, we have to create our own.

When I refer to the lack of version control within GPOs, I am not referring to the internal versioning
mechanism that GPOs use to ensure their Group Policy Container (GPC) and Group Policy Template
(GPT) are in sync as they are replicated to your Active Directory (AD) domain controllers. In most
cases, this internal versioning scheme won’t be useful for your company’s version-control needs
because it keeps numerical track of only each individual change that you make to a GPO.

Embed Version Information in a GPO’s Friendly Name

As I mentioned, you can take several approaches to overcome the lack of version control within
GPOs. The first approach I’ll talk about is simple but can meet your needs in many cases.
Specifically, you can embed version information within the “friendly name” of your GPOs.
Thus, the name of the GPO becomes the place where you keep track of changes you make to
your GPOs. Figure 4.1 shows an example of how this scheme might work.

Figure 4.1: Using version information within a GPO’s friendly name.

74
 Chapter 4

As Figure 4.1 shows, I have three GPOs linked to my domain that contain version information.
Each time I make a set of changes to a GPO, I change the version in the friendly name to reflect
that. Of course, the version information isn’t meaningful without some information as to what is
behind the number. For that, you can use a spreadsheet to track each change you’ve made to your
GPO. You’re probably thinking that creating such a spreadsheet would take forever, given the
number of settings that are contained within a default GPO. Fortunately, you can get some help.
Microsoft has created a spreadsheet for Windows XP (that works for Win2K as well) that
contains all the default Administrative Template settings within a Windows XP-based GPO. You
can find the spreadsheet at
http://www.microsoft.com/windowsxp/pro/techinfo/productdoc/gpss.asp. This spreadsheet
serves as a good starting point for keeping version information, though you will have to add rows
for other policy areas such as security and software installation. Figure 4.2 shows an example of
how you might use this spreadsheet as a way to track version info for your GPOs.

Figure 4.2: Using the Microsoft GPO settings spreadsheet to track version information for your GPOs.

Create Custom .ADM Files

Another approach you can take for storing GPO version information is a slight variation on the
previously mentioned approach. Namely, you can create a custom .adm administrative template
file that “tattoos” version information into the registry of each computer (and user) that receives
a particular GPO. This approach allows you to go to a workstation and see what version of GPO
has been processed. I like this approach because not only does it let you know which version of

75
 Chapter 4

GPO a computer or user has received, but also provides a good way to tell whether GPOs are
being processed correctly—if the version information is not delivered to the registry correctly,
you know there is a problem with the GPO. To use this approach, you have to create a custom
.adm file. I’ve created just such a file, which Listing 4.1 shows.
CLASS MACHINE
CATEGORY !!Custom
Policy !!MachineGPOVersion
KEYNAME "SOFTWARE\MyCompany\GPO\Desktop Lockdown Policy"
EXPLAIN !!GPOVersion_Help
PART !!Blank EDITTEXT
VALUENAME "CURRENTVERSION"
END PART
END POLICY

END CATEGORY ; MY CUSTOM MACHINE POLICIES

CLASS USER
CATEGORY !!CUSTOM
POLICY !!UserGPOVersion
KEYNAME "SOFTWARE\MyCompany\GPO\Desktop Lockdown Policy"
EXPLAIN !!GPOVersion_Help
PART !!Blank EDITTEXT
VALUENAME "CURRENTVERSION"
END PART
END POLICY

END CATEGORY ;
[strings]
Custom="Custom Preference"
MachineGPOVersion="Set current GPO version for machine"
GPOVersion_Help="Enter the version number for this GPO"
Blank=" "
UserGPOVersion="Set current GPO version for user"

Listing 4.1: A custom .adm file for inserting GPO version information into the registry.

The name of the GPO (for example, “Desktop Lockdown Policy”) is embedded within the .adm
file. You will need to customize the .adm file for each GPO for which you embed version
information. In case you’re wondering what this customization will look like within the
Microsoft Management Console (MMC) Group Policy editor tool, Figure 4.3 shows you.

76
 Chapter 4

Figure 4.3: Viewing the custom .adm policy created for storing GPO version information in the registry.

And, finally, Figure 4.4 shows what this customization looks like if I go to the registry on a
machine that has processed this GPO.

Figure 4.4: Viewing the effects of a GPO version policy delivered to a computer.

77
 Chapter 4

In Figure 4.4, we’re viewing the version information for the computer
(HKEY_LOCAL_MACHINE) rather than the user. Although you might want to keep the
version number of a GPO the same across both computer and user settings, you can, of course,
maintain different numbers, depending upon your needs. You will still want to keep a
spreadsheet that describes what each version number corresponds to within the GPO.

Third-Party Tools
Although the two approaches I’ve just described are easy to implement, they lack several key
features that you might need for a fully functional version-control environment within your
infrastructure. The high-tech approach is to use a product such as FullArmor’s FAZAM GP
Repository. The Repository is an offline store that solves a number of GPO management
problems at once. In addition to letting you make changes to GPOs offline before they are live in
your AD, the Repository can keep track of version information for your GPOs. More
importantly, the product can keep a history of GPO changes that tracks who made the change,
when the change was made, and why it was made. This kind of thorough change management is
key if your company starts to rely more heavily on GPOs to support your Win2K or Windows
XP infrastructure.

Q 4.2: How many Group Policy Objects can I create in a domain

before I start affecting the performance of my workstations?
A: There are many factors that affect Group Policy Object (GPO) processing performance.
There are things you can do to reduce the time it takes to process a GPO, and thus allow more
GPOs to run before your users notice a significant impact.
There are a number of behaviors within the normal GPO processing cycle that affect how long a
computer or user(s) takes to process a GPO. There is no one answer to how many GPOs you can
use before you affect the user experience. However, understanding the behaviors that affect
performance can go a long way toward helping you gauge how many GPOs your infrastructure
can support.

Asynchronous vs. Synchronous Processing

By default in Win2K computers and users process GPOs synchronously. This means that, when
the computer boots up, it processes all computer-specific GPOs it is subject to before presenting
the logon dialog box to the user. Similarly, when the user logs on, all user-specific GPOs are
processed before the desktop is shown to the user. In Windows XP, just the opposite is true.
Windows XP uses asynchronous GPO processing, also known as fast logon optimization.

Fast logon optimization in Windows XP is just asynchronous GPO processing, which allows the
computer to present the logon dialog box to the user without waiting for all computer-specific GPOs to
finish processing.

Asynchronous processing allows the computer to start up and present a logon dialog box to the
user even though all computer-specific GPOs have not finished processing. Asynchronous
processing also allows a user to log on and get control of the desktop before all user-specific
GPOs have finished processing. Asynchronous processing can speed up the overall GPO
processing cycle because the computer or user do not have to wait for all GPOs to finish

78
 Chapter 4

processing before moving on to the next step. However, the downside is that some policy
features within the GPO—such as folder redirection and software installation—can take two user
logon cycles to take effect.
You can set asynchronous vs. synchronous behavior on a per computer basis through an
Administrative Template policy. In Win2K, the policies that control synchronous and
asynchronous processing are found in Computer Configuration, Administrative Templates,
System, Group Policy. Specifically the policy items are Apply Group Policy for computers
asynchronously during startup and Apply Group Policy for users asynchronously during logon.
If you enable these policy items, GPOs are processed asynchronously. In Windows XP, because
GPOs are set to asynchronous processing by default, you need to set only one policy item to
configure synchronous policy processing. Namely, in Computer Configuration, Administrative
Templates, System, Logon, the Always wait for the network at computer startup and logon
policy item, which Figure 4.5 shows, should be enabled to enable synchronous policy
processing.

Figure 4.5: Enabling synchronous GPO processing in Windows XP.

GPOs that Don’t Change Aren’t Processed

You will get some GPO processing performance benefits from some default behavior around
GPO versioning. Whenever you make a change to a GPO, an internal version number that the
GPO keeps is incremented by the number of changes you make. In addition, workstations and
servers hold a history of the last version of a particular GPO that was processed in their registry.
The default behavior in Win2K and Windows XP is that, if a GPO hasn’t changed since the last

79
 Chapter 4

time it was processed (and thus its version number is the same as the history information stored
in the registry), the GPO is not processed; it is simply skipped.
If you have a large number of GPOs, but they are fairly static, your computers and users will
incur a performance penalty the first time they are processed, but after that the processing time
will be short because the GPO is not actually processed. You can, of course, override this
behavior and force all GPOs to be processed regardless of whether their version numbers change.
You set the Administrative Template policy to control this behavior on a per client-side
extension (for example, per folder redirection, software installation, security, and so on) basis
and can be found in the same location within Win2K and Windows XP—namely Computer
Configuration, Administrative Templates, System, Group Policy. Figure 4.6 shows an example
of how you can modify the Security Policy Processing item to process security policy even if the
GPO hasn’t changed since the last processing cycle.

Figure 4.6: Modifying client-side extension behavior to process a GPO even though it hasn’t changed.

By processing only those policy extensions that are required, regardless of whether the GPO has
changed, you can further minimize GPO processing time and thus process more GPOs.

Disable Portions of a GPO that Aren’t in Use

You can further reduce GPO processing overhead—and thus process more GPOs—if you are not
using portions of a GPO (by disabling either computer-specific policy or user-specific policy).
For example, let’s say that you’ve defined a GPO that only affects per-computer security

80
 Chapter 4

policy—there is no user policy defined. You can disable the user side of the GPO, and a system
processing that GPO at user logon will simply not take the time to try and read the GPO. To
disable one side or another of a GPO, open the Group Policy Microsoft Management Console
(MMC) snap-in tool focused on the GPO, and right-click the GPO’s name in the left-hand scope
pane. Choose Properties from the context menu. You will see the dialog box that Figure 4.7
shows.

Figure 4.7: Disabling the computer or user portions of a GPO to speed GPO processing.

As Figure 4.7 shows, you can select either the Disable Computer Configuration settings or
Disable User Configuration settings check boxes to disable the unused portion of the GPO and
thus improve overall GPO processing throughput.
These are the principal behaviors that exist within an AD domain that reduce the time it takes to
process GPOs. There are some things you can do in your GPO design that will further improve
the processing speed of a GPO, and thus increase the number of GPOs that a given user or
computer can process before their experience is significantly degraded. Some of these design
points include:
• Ensuring that domain controllers and servers are always close to your client computers,
from a network perspective. For example, if you are using software installation policy to
deploy a large application such as Microsoft Office to your computers, make sure that the
server on which the Office installation bits are stored are not across a slow WAN link
from the clients processing the GPO.

81
 Chapter 4

• Ensure that any startup, shutdown, logon, or logoff scripts that you write are tested
thoroughly to ensure that they don’t hang during processing. If a script delivered by a
GPO hangs, the client will wait until the script times out (10 minutes by default) before
proceeding to process the rest of the GPOs. This behavior can cause interminable delays
in the overall GPO processing time.
• Minimize GPOs linked across domain boundaries. In AD, you can define a GPO in one
domain within your forest, and link it to a container in another domain. However, this
cross-domain linking can cause increased processing time as the client computer must
authenticate across domain trust boundaries to access the remote GPO. A better solution
is to copy the GPO from the source domain to the target domain using tools such as those
found in FullArmor’s FAZAM utility.

Q 4.3: How do I deal with multiple domain forests and Group Policy
Objects?
A: If your Active Directory (AD) forest consists of multiple domains or maybe even multiple
domain trees, you might need to take a step back in your Group Policy Object (GPO) design and
figure out how your GPOs can be used and managed across multiple domains. The challenges of
designing a GPO implementation for a multi-domain forest are more complicated than those you
need to consider in a single domain environment. First and foremost, you need to understand
how each of the domains will be administered. Remember that GPOs are created and exist within
a single domain but can be linked to across domain boundaries. However, linking to GPOs
across domain boundaries imposes a certain performance penalty on the users and computers
who process those cross-domain GPOs.
So when you’re designing a GPO infrastructure that will span domains, what is the best approach
to take? The first thing you have to do is decide who is going to control the GPOs within each
domain. Will they all be centrally managed? Will each domain control their own GPOs? Or will
the GPO infrastructure be a hybrid of some centrally managed GPOs and some managed within
each domain? Each approach will call for a different design. The key challenge you will face in a
multi-domain environment is ensuring consistency. Because each domain will end up creating its
own GPOs, even if they are all centrally managed, they will be physically distinct. Over time,
unless you have very good change-management processes in place, you may find that GPOs
diverge and conflict in their configuration.
The problem is compounded because there are no native tools in Windows 2000 (Win2K) or
Windows XP that let you copy a GPO from one domain to the next. Third-party tools such as
FullArmor’s FAZAM let you back up a GPO from one domain and restore it to another, but that
is the closest you can currently get to being able to duplicate your GPOs across domain
boundaries. And, because there is no synchronization mechanism for these cross-domain GPOs,
you will need to take some extra pains to ensure consistency. You can do so by clearly
documenting your GPOs and making that documentation available to all domain administrators
in your forest. Additionally, you should develop up-front some good for when you want to let
GPOs be linked across domain boundaries.
Linking across domain boundaries imposes performance penalties on users and computer that
process them. You might be tempted to just define all your GPOs in a single domain—for
example the forest root domain. This approach is certainly a possibility but it will be the poorest

82
 Chapter 4

performing approach, and it leaves you open to GPO problems if there are problems with inter-
domain trust relationships. I recommend that for those GPOs that you absolutely need to have
highly available, you create the GPOs in each domain in which they’re needed. Then you can
make other less-critical GPOs available to other domains via cross-linking as they’re needed.
Figure 4.8 shows an example of how you might implement a multi-domain GPO infrastructure.

Figure 4.8: Viewing a multi-domain implementation of GPOs.

In Figure 4.8, you see that there are three domains in this forest called tld.org. Each domain has
its own Security GPO, linked at the domain level. In addition, there are a number of OU-linked
GPOs in each domain. Europe.tld.org has decided that it wants to use the public key security
policy that is defined in tld.org and linked to OU22, so it has created a cross-domain link to that
GPO from OU4. Likewise, the organizational unit (OU) administrator of OU2 in tld.org wants to
use the Internet Explorer (IE) maintenance policy defined in Us.tld.org and currently linked to
OU32. So, she has created a link from that GPO to OU2.

83
 Chapter 4

Cross-domain linking of GPOs is pretty straightforward. However, the one thing you do need to
remember to do is grant access to the appropriate groups to read and process your GPOs. To do
so, you need to apply the Read (but not write) and Apply Group Policy permissions to your
GPOs for the “remote” administrator to link to and process the GPO. For example, if I’m an
administrator of OU4 in Europe.tld.org, I need to have permissions to be able to read and apply
Group Policy on the public key security GPO to link to it and have my users process it. By
default, if the Authenticated Users group has read and apply Group Policy permissions on a
GPO, anyone in the forest should be able to link to it and process it. However, if the
administrator of the GPO has removed the Authenticated Users access control entry (ACE), the
administrator will need to explicitly add an ACE that grants permission to the administrator of
OU4 in Europe.tld.org and to the appropriate user groups that will be processing that GPO.
Indeed, using groups to control who can access and process a GPO is an ideal way to restrict
who can link to your GPO either within or across domain boundaries. I always recommend that
if you have a GPO that you don’t want just any administrator in your forest to link to, you should
ensure that you have modified its default permissions to remove the Authenticated Users ACE
and grant only the required permissions to the groups that need them.

Q 4.4: How do I deal with change control in my Group Policy Object

infrastructure?
A: There is no built-in capability in Windows 2000 (Win2K) or Windows XP to support Group
Policy Object (GPO) change control. In other words, there are no tools out of the box for
managing the process of implementing and rolling back GPO changes.
In Question 4.1, I discussed ways of doing version control of your GPOs in the absence of those
capabilities in Win2K and Windows XP. In this section, I’ll talk about how you might handle the
change control process that is required in most enterprise environments. If your environment is
managed like most organizations, any changes that are made to production systems require strict
change control processes to track the change event. How strict your processes are usually
depends upon how large your organization is and how great of an impact the change will have. In
the case of your GPO infrastructure, there simply are no tools out of the box that can provide
good change management. As such, you either have to craft your own solution or look to third-
party tools such as FullArmor’s Group Policy Repository. Let’s look at some of the challenges of
implementing a change management system for GPOs.
The first thing that most change processes require is a way of documenting what is changing. As
you know, it can be very difficult to document all of the various policy settings within a single
GPO, let alone several spread across your Active Directory (AD) infrastructure. In these cases,
there are simply no good ways to do so out of the box without assistance from a spreadsheet or
other manual mechanism. You can use command-line tools such as gpresult.exe to document
how a GPO effects your users, but you can’t use that tool to actually document the contents of a
GPO, irrespective of what users or computers it’s targeted at.
Another challenge is in the automation of the application of a GPO change. Unlike other types of
changes in your Win2K or Windows XP infrastructure, you can’t script a GPO change because
there are no scripting interfaces into the GPO infrastructure. To document a change for an
administrator to implement, you need to actually spell out the step-by-step instructions that
describe the check boxes in the Administrative Template or security policies you’ve

84
 Chapter 4

implemented. This task can be tedious and error prone and requires that the implementer of GPO
changes have some familiarity with GPO technology.
The ability to back out of changes is another big problem with the current technology. There is
simply no clean way to back out of a GPO change. Depending upon the type of policy you need
to back out, this process can get downright nasty. For example, let’s assume that you’ve applied
a GPO change to an existing policy; this change creates a few more desktop restrictions on some
user’s desktops. Now let’s assume that, as a result of the change, an application has stopped
working and you need to roll back the change. You may need to go into the GPO and edit the
policy items that you changed, disabling the policy function that you previously enabled (or vice-
versa depending upon the policy). This process isn’t really a back out in the sense that you’ve
returned the environment to its pre-change state, but rather an undo of what the policy previously
did. Generally speaking, if the policy is a true policy as defined in Question 1.2, you should be
able to return the policy setting to Not Configured and that is enough to remove the policy.
However, if it’s a preference that you’re dealing with, to back it out, you will need to actually set
the policy to its opposite state.
What about backing out Folder Redirection or Software Installation policy? Both of these
policies have options that you can select that revert state back to its original form if the policy no
longer applies to the user or computer. In Figure 4.9, there is an option in Folder Redirection to
point the user’s redirected folder back to the user’s local user profile if the policy no longer
applies.

Figure 4.9: Viewing the option to remove Folder Redirection policy when it no longer applies.

85
 Chapter 4

The back out routine for this policy requires that the user no longer processes this policy, which
could cause other problems if the GPO has other settings that you are implementing. As you can
see, there are no easy answers when it comes to backing out. The easiest answer is test your GPO
changes thoroughly up front so that you rarely need to back out.
A final issue that you’ll have to deal with in the realm of change management is staging of GPO
changes. That is, how do you make a change ahead of the time that you actually want to
implement it? There are a couple of tactics for doing so. The first and easiest is to take advantage
of the fact that new GPOs can be created without linking them to a container object (see
Question 3.1 for more information about how to do so), or they can be created without linking
them to the target container object on which they will ultimately be implemented.
For example, you could create a test OU to which you initially link the GPO for testing, then
when you’re ready to move it into production, simply add the link to the ultimate container
object. This approach works great if you’re implementing a new GPO, but what about staging
changes to existing GPOs? Again, this process is very difficult out-of-the-box unless you have a
third-party tool that provides for offline editing of GPOs. The best you can do is to test your
changes on a different GPO that has the same settings as the production GPO, then, after you’ve
verified the changes, you can implement them in production.

Before editing a GPO, disable it from the Options dialog box (which Figure 4.10 shows) in AD so that
users and computers aren’t processing it while you’re in mid-edit.

Figure 4.10: Viewing the option to disable a GPO prior to making changes to it.

The challenge with using disable while you’re making GPO changes is that any users or
computers that logon or startup while the GPO is disabled won’t process the GPO. This behavior
is usually not a big problem, as subsequent logon and startup events will succeed, but if you’re
relying on the GPO for key desktop functionality (for example, for folder redirection or software
installation), you should try to make GPO changes of this kind after hours when users aren’t
likely to logon.

86
 Chapter 4

Q 4.5: What is the best scheme for allowing my organizational unit

administrators to create and edit Group Policy Objects?
A: Delegation of Group Policy Object (GPO) administration is a delicate balancing act. On the
one hand, you want to allow organizational unit (OU) administrators the ability to manage Group
Policy within their environment. On the other hand, Group Policies that are meant for a single
GPO can impact an entire Active Directory (AD) domain. Thus, it’s important to balance what
an OU administrator can do with what is best for the AD. Remember that delegation of GPO
administration falls into roughly three pieces:
• Delegation of the initial creation of a new GPO
• Delegation of editing and deletion of existing GPOs
• Delegation of the ability to link and unlink GPOs from container objects such as sites,
domains, and OUs
To delegate the ability to create a new GPO, you must place the user or group who needs that
capability in the Group Policy Creator Owners group. After the GPO has been created, the user
or group needs the Read, Write, and Create All Child Objects permissions to be able to edit the
GPO. Read, Write, and Delete All Child Objects permissions are required to be able to delete the
GPO (see Figure 4.11).

Figure 4.11: Viewing a GPO’s permissions that grant edit and delete capabilities.

87
 Chapter 4

In Figure 4.11, you see that the Finance Admins group has the ability to both edit and delete the
existing GPO called Finance Admins Lockdown. The ability to link or unlink a GPO to a
container object is controlled by permissions on the AD container object itself. Specifically, to
link and unlink a GPO to a site, domain, or OU, the user or group needs the Read and Write
gPLink and Read and Write gPOptions permissions on the object. Typically these are obtained
by granting the user or group Read and Write permissions on the container object. You can also
grant the gPLink and gPOptions permissions individually through the AD Access Control List
(ACL) editor within the Microsoft Management Console (MMC) Active Directory Users and
Computers or AD Sites and Services snap-ins. Right-click the container object in question, and
choose Properties from the context menu. Then choose the Security tab to bring up the ACL
editor. The easiest way to grant the Read and Write permissions I mentioned earlier is to
immediately click Advanced to choose the advanced ACL editor. Then add the user or group to
which you want to grant permissions, select the Properties tab, and select the appropriate
permissions, as Figure 4.12 shows.

Figure 4.12: Granting GPO linking and unlinking permissions on a container object.

After you have worked out how to delegate the various tasks around GPO creation, maintenance,
and use, the next question is, What is the best approach to use in granting these rights? The
answer depends on your environment, but there are a couple of approaches that you can take.
The first approach is to delegate the linking and unlinking process to only your OU
administrators. In this scenario, some central group is responsible for creating and editing GPOs,
then you leave it up to the OU administrator to decide which of those GPOs they want to link to

88
 Chapter 4

their OU. For GPOs that need to be linked to the domain and site level, the central group is again
responsible for handling those tasks. In this scenario, you need only delegate the linking and
unlinking permissions to the OU(s) involved, and grant all creation and editing permissions to
your central group.
The advantage of this approach is that you have total control over the creation and editing of
GPOs within your AD domain. Although GPOs can be linked to containers within a domain,
they are available to the entire domain. Thus, it might be a good thing to be able to control who
can create or edit GPOs—especially if you consider the worst-case scenario.
Suppose you grant an OU administrator the ability to create GPOs in your AD domain. Then,
either knowingly or not, that administrator decides to see how many GPOs he or she can create
in your domain. Perhaps the administrator creates hundreds or even thousands! The result is that
every domain controller in your AD domain will need to replicate the Group Policy Container
(GPC) and Group Policy Template (GPT) for each of those GPOs. Although this situation might
not be a huge problem in most cases, you might have parts of your network that can’t afford the
extra replication overhead of such activity. To take it one step further, suppose a malicious OU
administrator were to create a GPO that contains a logon script that is 5GB in size! This logon
script must be replicated to all instances of the GPT on all domain controllers for that GPO.
Again, not only might the network traffic bring some of your links to their knees, but in some
cases, replication of this logon script could cause servers to run out of disk space. The point is
that an OU administrator that has limited rights over your domain could wreak havoc over that
domain if granted the ability to create or edit GPOs at will.
If you’re not worried about such a scenario, you could grant a select group of OU administrators
the ability to create and/or edit GPOs. Or you could simply grant those administrators the ability
to edit certain GPOs while keeping others off limits. (Permissioning GPOs is not an all or
nothing operation—you can grant permissions to edit a select group of GPOs and leave others to
the purview of your central group.) If you maintain central control over the creation of GPOs and
limit the editing of certain GPOs to certain administrators, you can more easily ensure that any
one administrator will not run hog wild on your AD infrastructure.
There’s one more point to keep in mind as you decide who gets to do what within your GPO
environment. A single GPO can be linked to multiple container objects (multiple OUs). Thus, if
you have a GPO that is providing policy for multiple OUs, you need to ensure that you aren’t
granting editing rights to each of the administrators of those OUs without requiring some kind of
coordination between the two. If you don’t require this kind of coordination, you could have OU
administrators overwriting each other’s changes or making policy changes that significantly
impact each other’s users. The simple way around this scenario: When you have GPOs that will
be linked at the OU level, never share those GPOs among multiple OUs. This setup, however,
means that you will have to manage more GPOs in your overall infrastructure than if you were
sharing.

89
 Chapter 4

Q 4.6: If I have an empty forest root domain, do I need to create or use

Group Policy Objects in that domain?
A: Although this question might seem esoteric, it’s important to consider how you will treat
your empty forest root domain. Some administrators are obliged to simply ignore the forest root
because it is empty (that is, it does not contain any discretionary user or computer accounts).
However, there is probably some value in setting some policy for that domain up front.
The forest root domain is a common fixture in larger Active Directory (AD) implementations. Its
purpose is as a placeholder to protect this important first domain from day-to-day futzing that is
common in child domains. It also holds user groups such as the Enterprise Admins and Schema
Admins groups, which have special rights over the entire forest. So, in large organizations, it’s a
good idea to keep the empty forest root as pristine and untouched as possible.
However, you will still probably find a need to create some Group Policy Objects (GPOs) to
manage this domain—for preventative reasons if for no other reason. GPOs can be used in the
forest root domain to further protect the resources that reside in that domain. For example, on
this domain, you will most assuredly want to set strict account policy that determines which
users can access the domain and which users can perform operations on domain objects. Another
good use for GPOs in the forest root domain is to control which users can be members of the all-
powerful Enterprise Admins and Schema Admins groups. By default, the only user who is a
member of these groups is the Administrator account for the domain. You might want to control
this membership very strictly because anyone who can become an Enterprise Admins group
member can potentially wreak havoc on your forest. In addition, you might want to set Restricted
Groups policy to ensure that only certain users or groups can be placed in the Enterprise Admins
group (see Figure 4.13).

Figure 4.13: Viewing a Restricted Groups policy for the Enterprise Admins group.

90
 Chapter 4

To ensure that this policy is enforced on the entire forest root domain, define it on a GPO linked
to the Domain Controllers organizational unit (OU)—most logically the Default Domain
Controllers policy.
You might also want to set up some Administrative Template policy that warns users who log
onto the forest root domain that they are treading on “sacred” ground. For example, you could
use descriptive logon banners and warning text (found in Computer Configuration, Windows
Settings, Security Settings, Local Policies, Security Options, Message text for users attempting to
logon) to inform users about the sensitive nature of the domain.
All of these mechanisms simply help to keep your forest root domain as pristine and undamaged
as possible, which is a beneficial state because the forest root domain is irreplaceable and can
cause massive havoc in your AD infrastructure if it’s damaged.

Q 4.7: What are the challenges of “sharing” Group Policy Objects

between organizational units?
A: As you know, it is possible to create a Group Policy Object (GPO) that is shared between
multiple organizational units (OUs), domains, or Active Directory (AD) sites. That is, you can
link to a GPO from any number of these container objects. However there are some things to
keep in mind when you do so, as doing so can cause some confusion.
You can re-use GPOs within your AD forest across different sites, domains, and OUs. For
example, as long as an OU administrator has the permissions to link a GPO to his or her OU, and
as long as the administrator has permissions to read a GPO, he or she can link it and have users
or computers in the OU start processing it. Doing so can be challenging because, although a GPO
may be linked to from any number of container objects, it only physically exists in one place.
Any changes that are made to a GPO impact every container object that has linked to that GPO.
It’s important that you approach your GPO design with a firm grasp on who will be allowed to
link GPOs to their container objects and who will be allowed to edit those GPOs. I recommend
creating a clear distinction between “shared” GPOs and those that are created specifically for the
use of a single or small set of container objects. Shared GPOs will need to have a more stringent
change-control process and a clear set of rules about who can link to them and when.
There are a few things to keep in mind about shared GPOs as well. First, because a GPO only
exists in one place, any changes you make to it, as I mentioned earlier, affect all those who have
linked to that GPO This includes, most obviously, the permissions that have been set on that
GPO. If an administrator creates a GPO with the express intention of using it to provide policy
for the Finance Users group within the Finance OU, the administrator might decide to permission
that GPO to only allow users in that group to process the policy (see Figure 4.14).

91
 Chapter 4

Figure 4.14: Viewing a GPO permissioned to allow only the Finance Users group members to process it.

As Figure 4.14 shows, the only group with the Read and Apply Group Policy permissions on this
GPO (called Finance Users Lockdown) is the Finance Users group. Now, suppose the OU
administrator for the Sales OU would like to re-use this GPO and its settings on her own OU.
She has the permissions to link the Finance Users Lockdown GPO to the Sales OU, and goes
ahead and does so. The next time her Sales users log onto their Windows 2000 (Win2K) or
Windows XP workstations, they will get policy from the Finance Users Lockdown GPO, right?
No, because the permissions on that GPO only allow members of the Finance Users group to
process it. Thus, the Sales OU administrator would either have to add her Sales users to the
Finance Users group (probably not a great idea for future manageability) or modify the
permissions on the Finance Users Lockdown GPO to allow her Sales users group to have Read
and Apply Group Policy permissions on that GPO.
In either case, the solution is not perfect. In the first case, you start to lose the meaning of your
groups if you add Sales users to the Finance Users group simply to allow GPO processing. In the
second case, there is no way to grant the Sales users group the ability to just modify permissions
on the Finance Users Lockdown GPO to allow the Sales Admins group to also be able to process
the GPO. You will need to grant Write permissions on the GPO to allow permission editing, and
if you do grant that permission, the Sales Admins group can not only modify permissions but
also modify the settings on that GPO (see Figure 4.15). If they don’t understand that the GPO is
being shared by other OUs, many problems could arise.

92
 Chapter 4

Figure 4.15: Granting the Sales Admins group the rights to modify permissions on the Finance Users
Lockdown GPO.

You would think that just by granting the Sales Admins group the Read Permissions and Modify
Permissions rights, members would only be able to change permissions on the GPO.
Unfortunately, that is not the case. They can’t actually adjust GPO permissions until they are
also granted the Write All Properties permission. I consider this a bug in the way GPO control is
delegated!
Given the ramifications for sharing GPOs, what can you do? Well, the first and easiest thing to
do is to avoid sharing GPOs! Doing so might seem like a lot of work up front, but it will prove
its worth as you try to share more and more of your GPOs. You can use the capabilities of a tool
such as FullArmor’s FAZAM 2000 to copy the contents and settings of one GPO to another if
you want to re-use a particular GPO’s policies but don’t want to manual re-enter them again and
again. If you decide to share some GPOs, make sure you know who you’re affecting each time
you make a change to those GPOs. The easiest way to do so is to use the “links finder” capability
within the Microsoft Management Console (MMC) Group Policy snap-in tool. The links finder is
available from the Properties dialog box of any GPO. Simply select the Links tab, choose the
domain in which you want to search for links to the selected GPO, and click Find Now. All
containers that contain a link to the current GPO will be listed (see Figure 4.16).

93
 Chapter 4

Figure 4.16: Using the links finder to locate which container objects are linking to the selected GPO.

The bottom line is that sharing GPOs can save a lot of time, but can also create a lot of
headaches if you don’t keep a tight rein on who can link to a GPO and who can edit it.

Q 4.8: Can I use the Group Policy Object-based software installation

feature to replace my existing software distribution tools?
A: When administrators come across the software installation features in Group Policy, the first
thing they wonder is whether they can use this feature exclusively and throw out their existing
software distribution tool. Unfortunately, the answer I usually give when someone asks me about
this opportunity is, “Not quite!”, and here’s why.
The software installation feature in Group Policy is a big step up from the days of Windows NT
4.0, with which you had to use Systems Management Server (SMS) or a similar highly complex
software distribution tool to deploy software to desktops and servers in your environment. Group
Policy Object (GPO)-based software installation brings a fairly simple and straightforward AD-
based deployment tool to those shops that have deployed Active Directory (AD) and Windows
2000 (Win2K) or Windows XP. The Group Policy software installation features truly provide
some elegant features not found in other distribution tools:
• Supports per-machine and per-user installation of applications. Thus, you can deploy
applications to machines or users based on the organizational unit (OU) they are in or the
groups of which they are a member.

94
 Chapter 4

• Supports the concept of application advertisement. Advertising an application means that

the application’s icons and shortcuts are installed but the full application isn’t actually
installed until the user first uses it.
• Leverages privilege elevation to let a user run an application installation that the user
ordinarily wouldn’t have sufficient privileges to do. This functionality is available only to
“managed” applications that have been deployed using GPO-based software installation.
• Leverages the Windows Installer technology to provide robust install, rollback, and repair
features. The software installation feature requires that you package your application
installations using the .MSI format, but once you have, you get all the benefits that .MSI
provides, including auto-repair of advertised application features and transformation of
default packages using transforms. The software installation feature does support a
format called .ZAP, which lets you publish to your users applications that have not yet
been packaged using .MSI. However, the .ZAP format does not support privilege
elevation, so you might not be able to use it for many of your users.
• Supports the concept of upgrade relationships. After you deploy an application using the
Group Policy software installation features, you can automatically upgrade the
application to the next version. You can also remove applications that no longer apply.
The software installation feature has good application lifecycle management capabilities,
making it easier to manage the install, upgrade, and retire cycle that most applications go
through.
However, the Group Policy software installation feature is missing some key functionality that
most enterprise software distribution tools provide:
• No centralized way to report on the success or failure of an application installation across
many machines. Because GPO-based software installation deploys software when a GPO
is processed by a user or computer, there is no centralized place to go to determine
whether a distribution “event” was 90 percent or 70 percent successful. You would have
to cull the logs of each target machine to determine this information.
• Unlike most software distribution tools, there is no at-a-glance way to view which
software has been distributed to which users and machines. Resultant Set of Policy
(RSoP) tools, such as FullArmor’s FAZAM 2000, are your best bet for seeing which
users and computers are receiving which applications.
• No inventory component within the software installation feature. Most software
distribution tools, such as SMS, provide an inventory component that lets you look at
which hardware and software is installed on machines under management.
• No support for software distribution across slow or dial-up links. Some software
distribution tools support trickle-down installations of applications. The software
installation feature not only does not support this functionality, but the software
installation CSE will not, by default, process a GPO if a slow link is detected.

95
 Chapter 4

• No support for server-based software distribution. There are two modes of installation
supported in software installation—assignment and publishing. Publishing is user-
specific and requires that a user be logged onto a machine to trigger an installation.
Assignment is user or machine specific. In the case of machine-based assignment,
although a user does not have to be logged on to trigger the installation, the computer
needs to be rebooted to do so. This reboot triggering mechanism is usually not acceptable
in most server environments.
• No support for license metering or a way of limiting the number of users or computers
that install an application (other than restricting an application by user or computer
group).
If these limitations aren’t critical to you—if you’re working in a small to midsized environment
in which Sneakernet is your only other software distribution tool option, GPO-based software
installation is a great tool for automating the delivery and installation of software to your users.
If you are in a large enterprise environment and are already using a tool such as SMS, GPO-
based software installation can be a great compliment to your existing capabilities. Software
installation-based publishing of applications to the Add/Remove Programs applet (see Figure
4.17) can be a great way to provide your users with a low-maintenance, self-service way of
installing optional applications that your enterprise supports but doesn’t necessarily want to
install on every desktop.

Figure 4.17: Viewing an application that has been published via GPO-based software installation to the
Add/Remove Programs applet.

As you can see in Figure 4.17, I have published the Win2K Administration Tools to users that
might need them (I could restrict this application to only appear for administrative users by
permissioning the application within the GPO for a particular user group). The application isn’t
installed until the user clicks Add. This kind of “software distribution” has low overhead because
an administrator need only publish it once for it to be available to hundreds or thousands of
users.

96
 Chapter 5

Chapter 5: Administering and Delegating GPOs

Q 5.1: How do I delegate the ability to edit and link Group Policy
Objects in Active Directory?
A: Delegation of Group Policy Object (GPO) management involves modifying Active Directory
(AD) security on either a container object (a site, domain, or organizational unit—OU) or the
GPO itself, depending upon the function you are delegating.
Delegation of AD rights can often be a challenging process. In the Microsoft Management
Console (MMC) Active Directory Users and Computers snap-in, Windows 2000 (Win2K)
provides the Delegation of Control wizard to help manage AD rights for the purpose of
delegating administration of AD objects. But the Delegation of Control wizard is only good for
setting the initial permissions on an AD object and can’t delegate administration of GPOs. If you
need to modify those rights, the wizard has little value.

Delegate GPO Editing

Let’s take a look at how you can delegate the editing and linking of GPOs more directly than
with the Delegation of Control wizard. First, let’s examine how you can delegate editing of
GPOs. The first thing to know about GPO delegation is that it’s all about modifying the access
control list (ACL) of the GPO. A GPO is composed of the Group Policy Container (GPC, which
is an object in AD) and the Group Policy Template (GPT, which is a set of folders and files in
SYSVOL). Thus, you need to be able to modify the permissions of these two pieces of the GPO
to grant users and groups the ability to modify the GPO. Fortunately, there is a fairly easy way to
modify these permissions that does not require you to directly manipulate the ACLs on each. The
following step-by-step instructions walk you through changing the security on a GPO to allow a
new user group (for example, GPO Admins) the ability to edit the GPO called My Delegated
GPO:
1. Start the Active Directory Users and Computers (or Active Directory Sites and Services)
MMC snap-in.
2. Right-click the container object (site, domain, or OU) to which the GPO you want to
delegate is linked.
3. Select Properties from the context menu, then select the Group Policy tab.
4. Highlight the GPO you want to delegate, then click Properties. You will be given the
choice of three tabs—General, Links, and Security. Choose the Security tab to bring up
the ACL editor focused on the GPO, which Figure 5.1 shows.

97
 Chapter 5

Figure 5.1:Viewing the ACL editor focused on a GPO for delegation.

5. Click Add at the top of the dialog box to choose the user group to which you’re
delegating editing rights on this GPO.
6. Once you’ve added the group to the ACL editor, make sure that the group name is
highlighted, then check the following permissions for that group to grant GPO editing
rights: Read, Write, Create All Child Objects, and Delete All Child Objects, as Figure 5.2
shows.

98
 Chapter 5

Figure 5.2: Delegating GPO editing rights to the GPO Admins group.

7. You can also control who processes a GPO from the same dialog box. The combination
of Read and Apply Group Policy rights means that the groups with those two rights will
always process the GPO.
There’s nothing more to delegating the editing of an existing GPO than what I’ve just described.

Delegate GPO Linking

Now lets look at how you can delegate the task of linking an existing GPO to a container object.
Without the ability to link a GPO to a container object such as a site, domain, or OU, you can’t
really do much with your GPOs—they won’t be processed by any computers or users within
your AD infrastructure. You can use the Delegation of Control wizard to delegate the linking
right, but I’m going to show you how to do delegate the linking right directly because the
Delegation of Control wizard doesn’t let you change the delegation once you’ve used the wizard
to set it up initially. Once again, the delegation process for the right to link to GPOs is about
modifying AD security—in this case, on the container object directly instead of on the GPO. So
let’s suppose that you want to delegate the linking right to the same GPO Admins group I used
earlier for the HQ OU. Thus, you want any member of the GPO Admins group to be able to link
GPOs to HQ. You can follow these steps to set up this delegation.
1. Start the Active Directory Users and Computers MMC snap-in, and highlight the OU on
which you want to set up delegation.

99
 Chapter 5

2. Right-click the OU, choose Properties from the context menu, then select the Security
tab.
3. You will now see the familiar ACL editor dialog box focused on the OU. Click Add to
add the GPO Admins group as a new access control entry (ACE), and click OK to
confirm the new addition.
4. With the GPO Admins group name highlighted in the top half of the ACL editor dialog
box, click Advanced to bring up the Advanced ACL editor dialog box, which Figure 5.3
shows.

Figure 5.3:Viewing the Advanced ACL editor focused on an OU.

5. Again, with the GPO Admins group highlighted, click View/Edit, then select the
Properties tab.
6. You will see a long list of AD properties for this OU object that you can set permissions
on. In this case, we are interested in two of those—Write gPLink and Write gPOptions.
Select these two rights to grant the GPO Admins group the ability to link GPOs to this
OU. (Note that the Read gPLink and Read gPOptions properties should already be
selected.) Figure 5.4 shows what these selections will look like.

100
 Chapter 5

Figure 5.4: Viewing the rights that need to be set to delegate GPO linking.

7. Click OK through three dialog boxes to confirm the change.

Once you’ve granted these two rights, the group or user you’ve designated will have the ability
to link GPOs to the container object. Why? What you did in the previous steps was grant the
group called GPO Admins the ability to modify the AD properties called gPLink and gPOptions.
These two properties, or attributes as they’re often called, contain the list (gPLink) of GPOs
linked to the container object and options (gPOptions) that you’ve selected. A group must have
the ability to write to both of these attributes to properly link a GPO.

Q 5.2: How does the Delegation of Control wizard work for Group
Policy Objects?
A: The Delegation of Control wizard comes with the Active Directory Users and Computers
(and AD Sites and Services) Microsoft Management Console (MMC) snap-in tools, and allows
you to delegate administration of Active Directory (AD) objects such as organizational units
(OUs), users, computers, and so on. However, the Delegation of Control wizard is fairly limited
for delegating control of Group Policy Object (GPO) administration. What the Delegation of
Control wizard provides with respect to GPO administration is the ability to delegate the process
of linking and unlinking GPOs to container objects within a domain. This functionality is a
useful capability to delegate in your AD infrastructure. For example, you might want to retain

101
 Chapter 5

control of the creation and editing of GPOs within a central group, but then allow administrators
of individual OUs the ability to link those GPOs that you’ve created to their respective OUs.
Thus, you’ll need to delegate the ability to create and remove those links on each container
object. In this situation, the Delegation of Control wizard can help.
But first, you should be aware of a couple of limitations in the Delegation of Control wizard.
What the wizard does is simply automate the process of editing access control lists (ACLs) on
AD objects within your domain. For example, if you’re delegating control of an OU to a group
of administrators, you’re basically setting permissions on that OU that allow the administrators
to perform the proper operations over AD objects within that OU. The Delegation of Control
wizard prompts you to select the target to delegate and the group being delegated to, then does
the work of modifying the ACLs on the target to provide access to the group. However, the
wizard is stateless. That is, once you’ve made a delegation for a particular AD object to a
particular group, there is no easy way to go back and change that delegation through the wizard.
To do so, you must go into the AD ACL editor for that object and manually modify permissions.
So, the wizard is good for first-time delegation of resources, but not as useful for subsequent
tweaking of permissions.
Now, let’s look at how you can delegate linking and unlinking of GPOs to particular container
objects. First, I’ll provide a little background about the linking process. When you link a GPO to
a container object such as a site, domain, or OU, what you’re really doing is modifying a couple
of attributes on that container object in AD. Those attributes are called gPLink and gPOptions.
The gPLink attribute contains a list of globally unique identifiers (GUIDs) that represent each of
the GPOs linked to that container object. gPOptions indicates whether the Block Policy
Inheritance feature has been selected on the container object. To delegate the ability to link and
unlink a GPO from a container object involves granting the permissions to modify these two
attributes, which is exactly what the Delegation of Control wizard does. Let’s step through this
process by delegating the ability to link and unlink GPOs from a site object.
1. Open the AD Sites and Services MMC snap-in tool.
2. Highlight and right-click the site to which you want to delegate administration.
3. Select Delegate Control from the context menu to start the Delegation of Control wizard.
Click Next to begin the delegation process.
4. From the Selected Users and Groups dialog box, add all users or groups to which you
want to grant the ability to link and unlink GPOs from this site object, and click Next.
5. On the next dialog box, which Figure 5.5 shows, you’ll see that a site object has only one
pre-defined task that you can delegate—Manage Group Policy links; select that option’s
check box. Alternatively, you could have selected the Create a custom task to delegate
radio button and manually selected which permissions you wanted to grant on which
kinds of objects, but using the common tasks reduces the number of steps you need to
perform. Click Next, then Finish to finish the wizard and complete the delegation
process.

102
 Chapter 5

Figure 5.5: Delegating administration of GPO links on a site object.

To confirm that the proper permissions were indeed delegated to the site object by the wizard,
you can go into the properties on the site object, and view its security ACL. GPO linking is
considered an advanced permission, so once you have the ACL editor up and focused on the site
object, you’ll need to click Advanced to view advanced permissions. Figure 5.6 shows that two
ACEs were created for the group (SF Site Administrators) to which I chose to delegate the
linking permissions.

Figure 5.6: Viewing the permissions we used the Delegation of Control wizard to create.

103
 Chapter 5

In Figure 5.6, the SF Site Administrators group has been granted the Read/Write Property
permission twice. Why? Well, remember that two AD attributes contribute to the granting of the
linking and unlinking permission on a container object—gPLinks and gPOptions. If I were to
highlight each of these permissions and click View/Edit, I would see read/write permissions
granted to precisely these two attributes. Now, when users in the SF Site Administrators group
want to link GPOs to the San Francisco site, they can do so successfully, knowing that the proper
rights have been granted to them.

Q 5.3: How can I prevent certain users from administering portions of

my Group Policy Objects?
A: As you probably know, the usual way to restrict administration of a Group Policy Object
(GPO) to a particular user group is to set security permissions on that GPO that control who can
edit it. However, if you want to restrict only certain parts of a GPO, the only way to do so is to
use Administrative Template policy. There is a set of Administrative Template policies that let
you control which Group Policy editor extensions can be loaded into the Microsoft Management
Console (MMC). These policies, in effect, restrict which parts of a GPO a user can load into the
MMC, and thus control what they can edit. These policies are not real security but simply block
a user’s ability to get to the proper tools for editing a particular part of a GPO. This feature can
come in handy when you have a GPO that provides a number of functions—for example, folder
redirection, Administrative Template policy, and software installation—and you want to delegate
administration of only one part (for example, software installation) of that GPO.
The Administrative Template policy that controls the list of permitted MMC snap-ins related to
GPOs are located in the same place in both Windows 2000 (Win2K) and Windows XP, under
User Configuration, Administrative Templates, Windows Components, Microsoft Management
Console, Restricted/Permitted snap-ins, Group Policy. Figure 5.7 shows the policy options that
are available.

Figure 5.7: Viewing the Administrative Template policy for restricting the use of GPO extension functionality.

104
 Chapter 5

As an example, let’s walk through a real-life scenario to show how these policies are used. I have
a GPO linked to an organizational unit (OU) called Finance in my Active Directory (AD)
domain. That GPO contains some desktop lockdown settings via Administrative Template
policy, some security settings for users of that OU, as well as some software installation policy
that supports publishing of applications to the Finance OU user desktops. Now let’s suppose that
I want to grant a local administrator of the Finance OU—we’ll call him Joe Admin—the ability
to edit the software installation policy on my GPO to deploy some departmental applications, but
I don’t want Joe Admin to be able to edit any of the Administrative Template or security policy
on that GPO. The first thing I need to do is define a GPO restriction policy that limits the snap-
ins that Joe Admin can load. I can do so from within the same GPO that I will be allowing Joe
Admin to edit because I won’t be letting him edit the Administrative Templates that I’ve defined.
From the windows that Figure 5.7 shows, I need to disable the Administrative Templates (Users)
and Security Settings extension policies. Figure 5.8 shows what this modification would look
like.

Figure 5.8: Enabling policy to restrict the use of certain GPO extensions for editing.

With these settings, when Joe Admin attempts to load the GPO into the MMC editor tool, he will
simply not see the user-specific Administrative Templates and security settings nodes. Figure 5.9
shows the view that Joe will see when he loads the MMC Group Policy tool focused on a GPO.

105
 Chapter 5

Figure 5.9: Viewing an MMC Group Policy tool that has been restricted by Administrative Template policy.

In Figure 5.9, the user-specific Administrative Template and computer-specific security settings
nodes are missing. The other option that you have using this policy is to actually restrict all
GPO-related snap-ins, then only allow access to the specific snap-ins that you want to expose to
the user. You can do so by setting the policy called Restrict Users to explicitly permitted list of
snap-ins under Computer Configuration, Administrative Templates, Windows Components,
Microsoft Management Console. By enabling this policy, all MMC snap-ins are unavailable to
users who are subject to the GPO on which the policy is set. If you then go into the Group Policy
folder under this node, you can explicitly enable those GPO-specific snap-in extensions that you
want to allow.

Q 5.4: Can I delegate administration for just a part of a Group Policy

Object?
A: In most cases, the answer is no, you cannot delegate one part (for example, folder redirection
policy) of a Group Policy Object (GPO). Delegation is done at the whole GPO level by setting
global security on that GPO. However, there are a few exceptions to this rule. Out of the box,
individual applications within Software Installation policy can be permissioned separately from
the whole GPO. This feature is useful for controlling which groups of users and computers will
“see,” and thus process, the Software Installation policy for that application. But it’s also useful
for controlling who can actually change the permissions on a particular application. To access
security permission for an application that has been published or assigned using Software
Installation, you simply double-click the application and select the Security tab (see Figure 5.10).

106
 Chapter 5

Figure 5.10: Viewing the security permissions on an application deployed via GPO Software Installation.

Typically, when you’re trying to control which users or computers will process the application
installation, you assign Read permissions to that target group. When you want to delegate the
rights to modify the permissions on an application, you need to grant the Write permission. For
example, suppose I want to grant the Finance Admins group the ability to change who can install
the WinInstall LE package that Figure 5.10 shows. I would add the Finance Admins group to the
access control list (ACL) that the figure shows, and grant them (at the least) Write permissions to
the application. When a Finance Admins group member then wants to modify who has Read
permissions to an application, the member can do so.
Unfortunately, this functionality is really the extent to which you can delegate control of a GPO
at a more granular level than the whole GPO. FullArmor’s FAZAM tool provides you with some
ability to delegate Administrative Template policy by controlling who can access which .adm
template files; but outside of that, you don’t have any other options.
The best solution I have found for providing more granular delegation of GPO administration is
a two-part solution. First, if you need to have different people or groups manage parts of a GPO,
you should probably consider breaking that single GPO into multiple GPOs that are managed by
the groups that need to manage them. Although this option will have a performance impact on
your users and computers (more GPOs requires more time to process them), it can simplify
administration of GPOs. So, for example, if the Finance Admins group needs to administer
Software Installation policy in GPO A, and the Accounting Admins group needs to administer
Administrative Template and computer security policy in GPO A, you have a problem if you

107
 Chapter 5

don’t want the Finance Admins to also be able to modify Administrative Template and security
policy. The reason for the problem is that both Finance Admins and Accounting Admins must
have modify permissions on the whole GPO to modify their various pieces. And, after they have
modify permissions on the whole GPO, there is nothing to keep them from modifying pieces that
they shouldn’t. In this case, the best solution is to place the Software Installation policy settings
in a new GPO, GPO B, that is only available to the Finance Admins group, and leave the
Accounting Admins group to administer the remaining policy in GPO A.
Finally, I will say that it is possible to delegate parts of a GPO using “unconventional” and
unsupported means. Namely, it is possible to modify permissions on individual parts of the
Group Policy Container (GPC) and Group Policy Template (GPT) to individually control who
can do what within a single GPO. I mention this option only as an educational exercise because I
wouldn’t recommend doing it in production. The reason is that things can get very complex if
you try to control permissions on individual files within SYSVOL for the GPT (for example,
setting the permissions on the registry.pol file to control who can change Administrative
Template policy) or individual containers within Active Directory (AD) for the GPC (for
example, modifying the permission of the Class Store container to control who can publish and
assign applications). The problem with this approach, although technically feasible, is that it is
easy enough to be undone if someone simply decides to re-apply permissions to a GPO at the
whole GPO level. These permissions can easily be propagated down to the individual GPC and
GPT sub-containers and folders and wipe out any custom changes you’ve made. As I said, it’s a
nice academic exercise to know that you can do it, but I wouldn’t recommend doing it in
anything but a test environment.

Q 5.5: How can I audit who has made a change to a Group Policy
Object?
A: Unfortunately, one of the limits of the Group Policy Object (GPO) infrastructure is that there
is no really straightforward way to audit who has made which change to a GPO. What is required
is that you set up Windows security auditing on the Active Directory (AD) and SYSVOL to be
able to track who has made a change to the pieces of the GPO.
It would be nice if Microsoft provided a way to audit GPO changes at the level that you think
about when working with GPOs. In other words, I’d like to know if Joe Admin made a change to
the Desktop Lockdown GPO, and if so, what that change was. Unfortunately, as a result of the
structural nature of GPOs—the fact that they are really two “pieces” in the Group Policy
Template (GPT) and Group Policy Container (GPC)—it is very difficult to audit GPO operations
out-of-the-box because there isn’t any one thing that you can audit. However, I’ll show you how
you can use native tools to achieve some level of auditing so that you can narrow who made
which change to which GPO. First, you need to ensure that auditing is enabled on your AD
domain controllers. Auditing is enabled on domain controllers by editing the special Default
Domain Controllers Policy GPO that is installed by default in every AD installation and linked to
the Domain Controllers organizational unit (OU). To enable AD auditing, start the Active
Directory Users and Computers Microsoft Management Console (MMC) snap-in, right click the
Domain Controllers OU, and choose Properties from the context menu. Next, choose the Group
Policy tab, highlight the Default Domain Controllers Policy, and click Edit. Within the GPO,
drill into Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit
Policies. From here, double click the Audit Directory Service Access item, select the Define

108
 Chapter 5

these policy settings check box, then select the Success and Failure check box. (You don’t have
to select the Failure option, but doing so will let you know who tried but failed to access a GPO.)
Figure 5.11 shows what this configuration will look like.

Figure 5.11: Enabling AD auditing on the Default Domain Controllers Policy.

After you’ve enabled AD auditing and this policy has replicated and been processed on all
domain controllers (and especially the PDC emulator), any changes you make to your GPOs will
be audited. Enabling AD auditing only effectively catches access to the GPC portion of the
GPO—not the GPT. However, this level of auditing is usually effective to track who is accessing
a GPO, because the GPC and GPT are automatically accessed each time you open or edit a GPO
using the MMC snap-in tools. What this auditing won’t catch is specific changes made to files
within the GPT. For that, you need to enable the Audit Object Access item that Figure 5.11
shows, then enable auditing on the actual GPO.
After you’ve enabled general auditing through the Default Domain Controllers Policy, you need
to customize GPO auditing on a per-GPO basis to determine what kind of auditing is actually
performed. By default, all GPOs are set up with the Everyone group enabled for a variety of
access logging. Just to review, the process of setting up a System Access Control List (SACL)
involves telling Windows for which user or group you want to log access and which operations
you’re interested in logging. To access auditing settings within a GPO, you need to bring up the
ACL editor on the GPO. If you are already editing the GPO, you can access the ACL editor by
right-clicking the GPO’s name within the MMC snap-in tool, and choosing Properties from the
context menu. Next, choose the Security tab, then click Advanced. Finally, click the Auditing tab
to access the auditing SACLs window (see Figure 5.12).

109
 Chapter 5

Figure 5.12: Viewing a GPO’s SACLs (auditing settings).

If I highlight the Everyone group in the window that Figure 5.12 shows, then click View/Edit, I
can see which types of AD access are being audited, as Figure 5.13 shows.

Figure 5.13: Viewing detailed AD auditing options within the ACL editor.

110
 Chapter 5

And, if I select the Properties tab in this dialog box, the tab will shows me which attributes on
the GPC are being audited for access. If I am setting up auditing on a particular GPO that is
linked to an OU, I might want to remove the Everyone entry from the auditing list and only audit
access by the OU administrators who would regularly be accessing that GPO.
Typically, when a change is made to a GPO with AD auditing enabled, there are event log
entries written to the Security log on the domain controller on which the changes are being made
(typically at the PDC emulator by default). Thus, you can go to that server after a GPO has been
edited and view the logs to determine who has been in that GPO. For example, as Figure 5.14
shows, you see that the user administrator made a change to the GPC that has the GUID shown.

Figure 5.14: Viewing a security event log entry showing auditing of a GPO.

If I were to scroll down the description in the window that Figure 5.14 shows, you would see that
the event shows that the administrator wrote a new value to the versionNumber attribute on that
GPC. Such is the extent of the GPO auditing that is available to you within AD. You are left to
determine which GPO is represented by that GUID, and what kind of change was actually made.
In the latter case, you can glean a bit more info by enabling auditing on the SYSVOL portion of
the file system that holds the GPT portion of a GPO.
To enable file system auditing for GPOs, the best thing to do is log on to the PDC emulator in
your domain and open Windows Explorer in %systemroot%\sysvol\sysvol\<domain name>,
where <domain name> is the name of your AD domain. From this point, right-click the Policies
folder, and choose Properties from the context menu. Next, choose the Security tab, and click
Advanced. Finally, click Auditing to see what auditing has been enabled on this folder. Unlike
the GPO itself, no auditing is set up by default on the Policies folder.

111
 Chapter 5

You can also setup auditing of the GPT on a particular GPO by drilling into the Policies folder and
locating the GUID-named folder of the GPO in question.

For my example, I’m going to enable auditing of the entire Policies folder for the group called
Finance Admins. When I add this group to my list, I am taken to the list of available auditing
options, from which I can choose which kinds of access to audit. As Figure 5.15 shows, I am
most interested in auditing the activities that would cause a change in the files or folders that
exist in the GPT for a given GPO, so I’ve selected the four entries shown.

Figure 5.15: Viewing options for enabling SYSVOL auditing of GPT changes.

After I enable this auditing on SYSVOL, any changes that a user makes to a GPO are tracked in
the Security event log on all domain controllers in the domain, starting with the PDC emulator.
In Figure 5.16, the user jadmin, a member of the Finance Admins group, made a change on a
GPO that is recorded in the event log on the PDC emulator.

112
 Chapter 5

Figure 5.16: Viewing an audit event generated on SYSVOL by a GPO change.

As you can see from the event, the user accessed and made some kind of change to the
registry.pol file under the user subfolder of the GPT. This description tells me that jadmin made
a per-user Administrative Template policy change to this GPO, though it does not tell me what
the change was.

Q 5.6: What is the difference between deleting a Group Policy Object

and deleting a Group Policy Object link?
A: There is a significant difference between deleting a Group Policy Object (GPO) and deleting
a GPO link—one is permanent and irreversible and the other merely disassociates a GPO from a
container object. When you are in the Active Directory Users and Computers or AD Sites and
Services Microsoft Management Console (MMC) snap-ins, you can focus on a container object,
such as a site, domain, or organizational unit (OU), and see which GPOs have been linked to that
object (see Figure 5.17).

113
 Chapter 5

Figure 5.17: Viewing GPOs linked to a container object.

As you can see from Figure 5.17, there is a button that you can use to delete the selected GPO.
However, if you click Delete, you will receive the prompt that Figure 5.18 shows.

Figure 5.18: Viewing the options to delete a GPO or its link.

The first option you see in this prompt lets you simply unlink the GPO from this container
object—in my example here it’s the Finance OU. By unlinking the GPO, you simply disassociate
from the container object—the OU. The GPO will no longer be processed by users and
computers in this OU, but the GPO still exists in the domain and can be re-linked to another
container object by clicking Add in the dialog box that Figure 5.17 shows.

114
 Chapter 5

If you select the second option, you are doing two things: First, you are removing the link to the
GPO from this container object. Second, and more permanent, you are actually deleting the
physical GPO from the domain. That is, when you delete the actual GPO, you are deleting its
constituent parts—the Group Policy Container (GPC) and Group Policy Template (GPT) from
Active Directory (AD) and SYSVOL, respectively. After the GPO is deleted, you cannot recover
it (unless you have recently backed up the System State on your domain controllers). This
operation completely removes all vestiges of the GPO from AD. If the GPO that you’re deleting
is linked to other container objects in your AD forest, those links will be removed as well. No
orphan links will be left. Obviously, it’s important to choose the correct option when deleting a
link (or the GPO), as the consequences can be difficult to recover from!

Q 5.7: How can I delegate administration of a Group Policy Object to

users who reside in different organizational units?
A: Although the answer to this question might seem straightforward, delegating administration
of a Group Policy Object (GPO) to users in different organizational units (OUs) requires some
thought and planning. Typically, you will want to delegate control of a GPO to a group of users,
and so far we’ve only talked about groups of users that reside in the same OU. However, you can
easily delegate administration of GPOs to a group of users (or other groups) that reside in
multiple OUs and even multiple domains.
This question is more about the capabilities of Active Directory (AD) groups than it is about
GPO delegation, but it’s an important topic to discuss because it is likely to come up often
throughout your AD and GPO administrative chores. As you know, you can delegate the ability
to edit GPOs to user groups by adjusting the security access control lists (ACLs) on a GPO.
Usually, you do so by granting a user, or more preferably a group, read and write permissions on
that GPO. However, oftentimes the boundary that defines who can edit a GPO is not constrained
to a single OU or even a single domain. You might have administrators spanning OUs and
domains that all need the ability to edit a GPO. In that case, you can use some of the capabilities
of AD groups to create “virtual OUs” for the purposes of delegating control of GPOs.
For example, let’s assume that you have two administrators each in the Finance and Sales OUs
within the Us.mycompany.tld AD domain. You also have two administrators in the
corresponding Finance and Sales OUs within Europe.mycompany.tld. All eight of these
administrators need to be able to edit the GPO that resides in Us.mycompany.tld called
Mycompany Lockdown Policy. Figure 5.19 illustrates the layout of this domain.

115
 Chapter 5

Figure 5.19: Viewing delegation of a GPO across domains and OUs.

As Figure 5.19 illustrates, for this example scenario, I’ve created a universal group that contains
users (it could just as easily contain groups) from both AD domains. Then, I’ve used the
universal group, called MyCompany Lockdown Admins, to permission the Mycompany
Lockdown Policy GPO that is defined in Us.mycompany.tld. This setup is a very easy and
effective way to create a virtual OU of administrators (using universal groups) who can then be
granted permissions to various AD objects, such as GPOs.

Q 5.8: How can I view who has the rights to create Group Policy
Objects in my domain?
A: The process of granting who can create and edit Group Policy Objects (GPOs) is separate
from the ability to link GPOs to container objects. You can easily view who has the rights to edit
an existing GPO by viewing the security properties of that GPO in the Active Directory Users
and Computers or Sites and Services Microsoft Management Console (MMC) snap-ins. But
viewing who has rights to create a new GPO requires a little more work.
Because GPOs are created within an Active Directory (AD) domain and contain two parts (the
Group Policy Template—GPT—and the Group Policy Container—GPC), a user has to have the
appropriate rights in the domain in which the GPO is created on both the GPT and GPC. The
GPC is simply a set of objects in AD, and the GPT is a set of files and folders in SYSVOL. Thus,
the ability to create a GPO in an AD domain is governed by the rights to create objects within the
GPC portion of AD and the rights to create files and folders within the GPT portion of SYSVOL.
The easiest way to see who has rights to create a GPO is to fire up the Active Directory Users

116
 Chapter 5

and Computers MMC snap-in focused on your domain. From the View menu of the console,
make sure you have selected the Advanced Features option to see all available containers in the
domain. Navigate to the System container, and expand it to expose the Policies container (see
Figure 5.20).

Figure 5.20: Viewing the Policies container within an AD domain.

The Policies container that Figure 5.20 shows is the parent container for all GPCs defined in the
domain (the GPCs are the GUID-named folders you see in the right pane). It is the permissions
on the Policies container that control who can create new GPC objects, and thus new GPOs, on
the domain. So to find out who can create GPOs in your domain, right-click the Policies
container, and select Properties from the context menu. Select the Security tab to view the
current permissions on the container. Figure 5.21 shows the default permissions that exist on the
Policies container in AD.

117
 Chapter 5

Figure 5.21: Viewing the default permissions on the Policies container in AD.

If you examine the permissions on this container, you will notice that groups such as
Administrators, Domain Admins, and Enterprise Admins all have the ability to create new GPOs,
defined by the permission to Create All Child Objects. In addition, the Group Policy Creator
Owners built-in group also has this permission (in fact, it’s the only permission this group has).
Thus these groups can all create new GPOs, but some have more capabilities than others. For
example, the Group Policy Creator Owners group can only create new GPOs, but Domain
Admins and Enterprise Admins can create and delete GPOs, while members of the local
Administrators group can only create but not delete, GPOs. Finally Authenticated Users have the
Read permission only on GPOs. This setting makes sense because users (and computers) need to
be able to read the GPC (or GPO) to process the GPO.
You can also view the permissions within the GPT in SYSVOL to find out who can create new
GPOs in a domain. The Policies folder under SYSVOL corresponds to the Policies folder under
System that we just looked at. If you navigate to the Policies folder in Explorer, and view the
NTFS permissions on that folder, you should see a slightly different set of users with a similar
(albeit different because NTFS permissions are different than AD permissions) set of
permissions. Figure 5.22 shows you what these permissions look like by default.

118
 Chapter 5

Figure 5.22: Viewing the default NTFS permissions on the Policies folder within SYSVOL.

The Policies folder that Figure 5.22 shows is the parent folder to all of the GPTs defined within
the domains. Because the permissions on the GPC parent folder and permissions on the GPT
parent folder don’t correspond exactly, I find it best to look at the GPC permissions exclusively
to determine who has the rights to create a GPO in an AD domain.

119
 Chapter 6

Chapter 6: Tools for Managing GPOs

Q 6.1: How can I create customized tools for my administrators who

need to manage Group Policy Objects?
A: The principal interface for editing Group Policy Objects(GPOs) is the Microsoft
Management Console (MMC) Group Policy snap-in. Although the tool does not provide a
tremendous amount of flexibility, you can use the customization features within the MMC to
create some custom tools for your administrators.

Create Locked Down Tools

The MMC gives you the ability to create locked down “tools” (.msc files) that you can distribute
to your administrators. The advantage of creating these custom tools is that you can expose only
those management interfaces that a set of administrators needs to do their job. This feature can
be useful for distributing GPO administration tasks as well. For example, instead of giving your
administrators access to the Active Directory Users and Computers snap-in and expecting them
to navigate to the correct container object in which the GPO they need to manage is linked, you
can give them a custom MMC tool that exposes only the GPO or GPOs they need to manage.
Let’s suppose you have a group of administrators that needs to administer three GPOs linked to
your Active Directory (AD) domain. You want to create a tool that exposes only those three
GPOs to them. Following these steps, you can create a custom MMC tool to accomplish this
goal.
1. From the Start menu, select Run, and in the Run dialog box, type
mmc.exe
to bring up a blank MMC console.
2. From the MMC Console menu, select Add/Remove snap-in, and click Add.
3. From the list of available standalone snap-ins, navigate to Group Policy, and click Add.
4. From the Select Group Policy Object dialog box, click Browse to browse available GPOs
in your AD domain.
5. Select the GPO you want to add to the MMC console. Repeat steps 3 and 4 for all GPOs
you want to add.
6. Once you’ve added all the desired GPOs, you need to lock down the console tool so that
your administrators can’t change it once you give it to them. To do so, open the Console
menu, and select Options.
7. From the Options dialog box, you can give your console a name and choose the mode
that the tool will be opened in. In this case, choose User mode—limited access, single
window from the Console mode drop-down list.
8. Check the Do not save changes to this console check box, as Figure 6.1 illustrates, then
click OK to complete the option setting.

120
 Chapter 6

Figure 6.1: Viewing the options for locking down an MMC console tool.

9. Finally, save the console file with a unique name (for example, GPOAdmins.msc).
You can then distribute the .msc file to your Group Policy administrators.

Note that this .msc file can be run only from a Windows 2000 (Win2K) or Windows XP workstation. It
cannot be run from a Windows NT 4.0 workstation.

The resulting tool looks like the one that Figure 6.2 shows.

Figure 6.2: Viewing the locked down MMC GPO tool created for GPO administrators.

121
 Chapter 6

As you can see in Figure 6.2, the Console menu is no longer present. The administrator using this
tool cannot add any other MMC snap-ins and basically can only administer the three GPOs
listed.

Limit Tools Even More

You can provide an even more limited MMC console. For example, you might have a GPO that
uses the software installation feature to deploy applications. To illustrate this point, suppose you
have an administrator who is solely responsible for deploying software through that one GPO,
and you don’t want to expose any other policy settings within that single GPO to the
administrator. You can follow a slight variation of the earlier process to form such tool. First,
follow steps 1 through 5 to add the GPO into a new MMC console. Once it’s been added, drill
into the appropriate software installation node. With the software installation node highlighted,
right-click and select New window from here on the context menu. Ensure that the software
installation node window is maximized such that it takes up all the real estate on the MMC
console and blocks visual access to any other policy settings within the GPO. Next, set the
console options for the tool as Figure 6.1 shows to lock down what the user can do using the
settings I showed in step 7. Then save the tool to an .msc file. Figure 6.3 shows what the
resulting tool will look like.

Figure 6.3: Viewing a locked down GPO tool focused on a single policy function.

Using the tool that Figure 6.3 shows, users can neither modify additional GPO policy settings
nor can they even tell which GPO they are setting software installation policy for. This setup can
be useful when you need to delegate GPO administration tasks to a user who has little technical
skill and just needs to follow simple directions to deploy software.

Q 6.2: Can I script the creation of Group Policy Objects?

A: The short answer to this question is no. Neither Windows 2000 (Win2K) nor Windows XP
allow you to script the creation or editing of a Group Policy Object (GPO). However, there are
some scripting capabilities available related to GPOs.

122
 Chapter 6

You can script the process of linking a GPO to a container object. This capability is available
through the Windows Script Host (WSH) and the Active Directory Service Interfaces (ADSI)
COM objects available in Win2K and Windows XP. The Microsoft article “Scripting the
Addition of Group Policy Links” at http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q248392 provides a sample VBScript WSH script called gpollink.vbs, that lets you add (but
not remove) GPO links to container objects.
You have to modify the script to replace generic domain names (for example, mydomain.com)
and server names (that is, all instances of servername) with your own domain name and the
server name of the Primary Domain Controller (PDC) emulator for your Active Directory (AD)
domain. You could choose any domain controller to make the change to the GPO link. But
choosing the PDC emulator is preferable because GPO changes, by default, are always made
against the PDC emulator role-holder. That script also leverages a Component Object Model
(COM) object called IADSTools.DLL that is part of the Win2K Support Tools. IADTools.DLL
is a library of functions that let you perform administrative scripting activities on AD and related
objects. For example, the line in the script (modified to include my domain name and server
name)
Result=DLL.GetGPOs("mar-elia.com","DC1")
uses the IADSTools method called GetGPOs() to return a list of all GPOs defined in the domain
called mar-elia.com. DC1 is the name of the PDC emulator for the domain that the function
queries. The script then uses another IADSTools method called gponame()
if lcase(DLL.gponame(i))=lcase(askGUID) then
to determine, of the GPOs found earlier, which GPO the user has chosen to link to the container.
The script then uses ADSI to modify the gPLinks attribute on the container object defined by the
variable called SDOU to add the new GPO link. By default the script is set up to link GPOs to
the domain level, by virtue of the following statement:
Set SDOU=GetObject("LDAP://DC1/dc=mar-elia,dc=com")
However, you can also use the script to add links to organizational units (OUs) or sites by simply
modifying this statement. For example, if I want to add a GPO link to an OU called Finance, I
would modify the statement to look like the following example:
Set SDOU=GetObject("LDAP://DC1/OU=Finance,dc=mar-elia,dc=com")
With the text OU=Finance, the new part of this statement. If I want to link to a site, the process
gets a bit trickier because sites are found in a different Lightweight Directory Access Protocol
(LDAP) path from domains and OUs. Suppose I have a site called SanFrancisco to which I want
to link a GPO. The syntax for the statement would look like the following example:
Set SDOU=GetObject("LDAP://DC1/
CN=SanFrancisco,CN=Sites,CN=Configuration,dc=mar-elia,dc=com")
The SanFrancisco site is located within the Configuration naming context of the domain mar-
elia.com. Thus, the LDAP path to the site looks a bit different from the domain and OU
examples. Now let’s run the script to see how it works. From the command line, simply type
cscript gpollink.vbs
to invoke the script. The first thing the script does is return a list of GPOs it has found in the
domain, as Listing 6.1 shows.

123
 Chapter 6

C:\> cscript gpollink.vbs

Microsoft (R) Windows Script Host Version 5.1 for Windows
Copyright (C) Microsoft Corporation 1996-1999. All rights reserved.

Default Domain Policy

{31B2F340-016D-11D2-945F-00C04FB984F9}
Default Domain Controllers Policy
{6AC1786C-016F-11D2-945F-00C04fB984F9}
Desktop Lockdown Policy
{FE43AA62-AF7D-40CD-A27C-01384938FB53}

The SDOU you will be modifying is:

LDAP://DC1/CN=SanFrancisco,CN=Sites,CN=Configuration,dc=mar-
elia,dc=com

Successfully added a link to this SDOU for the GPO (Desktop Lockdown
Policy)

Listing 6.1: Viewing the output from the gpollink.vbs script.

The script also returns the path to the container object to which you’re linking. Next, you’re
prompted by a pop-up input box to enter the friendly name of the GPO that you want to link to.
The friendly name is the name that you see when you’re editing the GPO (for example, Desktop
Lockdown Policy) rather than the globally unique identifier (GUID) name of the GPO. Assuming
that the script finds the name of your GPO, it creates the link on the container object and returns
a success message.
This script only adds GPO links to a container object—it does not remove them. However, with
some clever string manipulation, you could modify the same script to do the removal process as
well. The link that builds the gPLink attribute
currentGPLIST=currentGPLIST & "[LDAP://CN=" & DLL.gpoguid(i) &
",CN=Policies,CN=System," & DLL.getdefaultnamingcontext("Yquem")
& ";0]"
could be manipulated using the regular expression function within WSH to remove the GUID for
the chosen GPO.
Expect later releases of Windows as well as third-party products to provide the ability to script
the creation and editing of GPOs. This ability will most likely come in the form of Windows
Management Instrumentation (WMI) objects that allow script-based manipulation of GPOs.

Q 6.3: Which tool can I use to force Group Policy Object processing
from the command line?
A: Windows 2000 (Win2K) offers only limited capability to force Group Policy Object (GPO)
processing from the command line. Win2K comes with a command-line tool called secedit.exe.
Ostensibly, secedit.exe is part of the security configuration toolset, but when you run secedit on a
Win2K device, it can force a reprocessing of GPO settings. For example, using the command

124
 Chapter 6

Secedit /refreshpolicy machine_policy

forces the computer to reprocess all machine-specific GPOs that affect that computer. (If you use
user_policy instead of machine_policy, user-specific GPOs are processed.) Of course, by default,
GPOs that have not changed since the last processing cycle will not be reprocessed by the
computer, but nevertheless, secedit can trigger reprocessing. GPO policy items such as folder
redirection and software installation are not actually triggered to run using secedit. These
extensions cannot run via a background refresh, and thus aren’t triggered just by using secedit.
Windows XP includes a new command called gpupdate.exe that allows more complete support
for refreshing GPO-based policy. With gpupdate.exe, we get a more full-featured command-line
mechanism for triggering GPO processing. Gpupdate lets you target a refresh of user or machine
policy just as secedit does. In addition, gpupdate provides options that let you force a refresh of
all policy settings, regardless of whether the GPO has changed since the last processing cycle.
You can also use gpupdate to handle those policy settings—such as software installation and
folder redirection—that require a system restart or user logoff/logon in order for those policies to
be applied. Listing 6.2 shows the command-line options available to gpupdate.exe.
Syntax: GPUpdate [/Target:{Computer | User}] [/Force] [/Wait:<value>]

[/Logoff] [/Boot] [/Sync]

Listing 6.2:Viewing the syntax for the gpupdate tool.

The force option, as I mentioned, lets you force GPO processing to occur for all applicable
policy settings even if the GPO(s) did not change since the last time it (or they) was processed.
The Wait option simply lets you tell gpupdate how long, in seconds, to hold control of the
command shell before releasing it back to the user. This option does not control how long GPO
processing actually takes, but rather tells gpupdate to not relinquish command until either the
time you specify has expired or all GPO processing has completed. The Logoff option instructs
gpupdate to process all applicable GPOs and, if there are any policies that require a logon event
to actually become visible, this option forces a user to logoff. Similarly, the Boot option does the
same thing for policies that require a system restart (such as machine-based software
installation). After all applicable GPOs are processed, if a reboot is required, the system will
reboot. Finally, the Sync option is a very useful one in that it lets you override asynchronous
GPO processing (also known as fast logon optimization in Windows XP) for the next processing
cycle only. By calling the Sync option, the next time a computer starts or a user logs on to a
machine, all applicable GPOs process synchronously (one after the other) rather than in parallel.
This feature is useful if you suspect that asynchronous processing is causing problems and you
need to test that fact.
Finally, it’s important to note that even though secedit and gpupdate provide command-line
mechanisms for refreshing policy, such refreshes are still logged in the Application event log as
they would be during normal GPO processing.

125
 Chapter 6

Q 6.4: Can I create a tool that gives me a consolidated view of all my

Group Policy Objects at once?
A: Yes, using the features of the Microsoft Management Console (MMC), you can easily create
a tool that gives you access to all of your Group Policy Objects (GPOs) within a single view. I
find it very useful to be able to have a single view of all the GPOs that I need to manage,
regardless of where they’re linked within my Active Directory (AD) infrastructure. As you
know, using the Active Directory Users and Computers or AD Sites and Services MMC snap-in
tools, you usually have to hunt around to get to each GPO in which you’re interested. By
creating a custom MMC console that shows all the relevant GPOs in a single view, you can save
time and ensure that you are always working on the right GPOs. The following step-by-step
instructions describe how you can create such a tool:
1. To begin, open a blank MMC console by typing
mmc
from the Start menu Run dialog box in either Windows 2000 (Win2K) or Windows XP.
2. From the Console menu in Win2K (File menu in Windows XP), choose Add/Remove
Snap-in, then click Add.
3. Scroll down the list of available snap-ins to the Group Policy snap-in, and click Add.
4. When you get to the Select Group Policy dialog box, click Browse to search for a GPO in
your AD. If you don’t know where the GPO(s) of interest are linked, choose the All tab
to show all GPOs defined in AD (see Figure 6.4).

Figure 6.4: Viewing all GPOs defined in an AD domain.

5. Select a GPO to add from the list, and click OK, then click Finish.
6. Before returning to the console, add another Group Policy add-in, and repeat Steps 4 and
5 for the rest of the GPOs you want to manage.
7. When you’ve added all instances of GPOs to manage, click OK from the Add/Remove
snap-in dialog box.

126
 Chapter 6

8. The final step is to save your tool. From the Console menu (or File menu in Windows
XP), choose Save, then give the tool a name. The resulting file will have an .msc
extension.
Figure 6.5 shows a consolidated GPO management tool (called MYGPOs.msc) that I created.

Figure 6.5: Viewing a consolidated GPO management tool using the MMC.

As you can see in Figure 6.5, I have five GPOs loaded in my tool. Each of these GPOs may be,
and indeed are, linked at different levels of the AD hierarchy but are visible and available to me
within this single MMC window. I can expand and edit each GPO as I would normally, and have
all the GPOs of interest available next to the others if I need to compare one or the other. I can
also use the MMC’s Favorites feature to store frequently used views of each of the GPOs.
For example, let’s suppose that I frequently need to go in and modify the user-specific Windows
Explorer policies within the Administrative Templates policy in the Desktop Lockdown GPO. I
can create a favorite that takes me quickly to this policy item by first expanding into the required
node (in this case User Configuration, Administrative Templates, Windows Components,
Windows Explorer). Then, from the Favorites menu on the MMC toolbar, I can choose Add
Favorites to add this policy item to the Favorites list (see Figure 6.6).

Figure 6.6: Adding a favorite policy to the MMC Favorites list.

127
 Chapter 6

I can use this favorites feature for any type of policy within my console tool. After I’ve created
my favorites, I can use the Favorites tab to navigate quickly and easily right to the policy item I
need to edit. For example, in Figure 6.7, I’ve created three favorites, which I’ve named first by
identifying the GPO, then by the policy item.

Figure 6.7: Using MMC favorites to navigate quickly to policy items of interest.

As you can see in Figure 6.7, the actual policy items appear in the right-hand results pane when I
highlight each favorite. This feature is super handy for frequently edited GPO settings, and I
highly recommend pre-creating these custom MMC tools for GPO administrators. It will make
your lives much easier over time!

Q 6.5: Do I have any control over how quickly the SYSVOL (Group
Policy Template) portion of a Group Policy Object is replicated to
other domain controllers?
A: The short answer to this question is that you have limited control over SYSVOL replication,
as compared with Active Directory (AD) replication. The File Replication Services (FRS) is used
to replicate SYSVOL to domain controllers in an AD domain. FRS relies on inter- and intra-site
AD connection objects that are built by the Knowledge Consistency Checker (KCC) to replicate
content between domain controllers. However, FRS content will not necessarily replicate on the
same schedule as AD objects. Often, between domain controllers within sites, file replication
happens very quickly, as soon as a file has changed and the domain controller has notified its
replication partners. Between sites, replication is typically scheduled based on the Site Link
configuration found in the Microsoft Management Console (MMC) AD Sites and Services snap-
in tool. Depending upon how many files have changed and the schedule you’ve created for AD
site links, you might experience delays before FRS data is in sync everywhere.
Unfortunately, you don’t have much control over the actual replication topology or the schedule
that is used to replicate changes. Unlike AD replication, for which you can use the AD Sites and
Services snap-in to force a replication trigger between domain controllers, FRS doesn’t provide
that kind of interface. You are pretty much at the mercy of FRS to replicate SYSVOL content
when files change and based on your AD site topology. Also be aware that prior to Windows

128
 Chapter 6

2000 (Win2K) Service Pack 2 (SP2), FRS does not compress file changes when replicating
between sites, as AD does.
What little you can tweak in FRS is the schedule as to when FRS replication can and cannot
occur. To change this schedule, open the Active Directory Users and Computers MMC snap-in,
make sure that the Advanced view is enabled, and within your AD domain, drill into System\File
Replication\Domain System Volume (SYSVOL Share). If you right-click this node and select
Properties from the context menu, the system will present you with the SYSVOL properties
dialog box. In this window, click Change Schedule to bring up the SYSVOL schedule, as Figure
6.8 shows.

Figure 6.8: Viewing the FRS replication schedule for SYSVOL.

If you select a square or range of squares in the window that Figure 6.8 shows, you can toggle
replication on or off during certain times of the day. This feature gives you some flexibility if
you’re replicating large numbers of SYSVOL changes and have slow links that you want to
remain available during business hours. You could schedule SYSVOL replication to happen after
hours in that case. Of course, that means that any changes you make to your GPOs would not be
synchronized across all domain controllers until SYSVOL replication is allowed to happen.
There is also a utility that you can use to check the status of FRS replication. It is called
ntfrsutl.exe and is included in the Win2K resource kit. This tool lets you view the “metadata” on
a particular domain controller to see its state and the state of replication on that server.

Ntfrsutl.exe was updated in Win2K SP2 with some improvements for getting information from FRS.
To get this version, you need to extract the full SP2 installation using the /x command, then copy the
new version of the utility over the old one.

129
 Chapter 6

Q 6.6: Can I get information about the Group Policy Objects in my

domain via scripts?
A: In a previous chapter, I mentioned that currently there is no way to script the edit or creation
of Group Policy Objects (GPOs). However, there is a useful scripting tool that lets you easily
access information about your GPOs. The name of the tool is IADSTools.DLL, and it comes as
part of the Windows 2000 (Win2K) Support Tools. IADSTools.DLL is a COM object that can be
called from Windows Script Host (WSH) scripts.
To use IADSTools, you first need to register the DLL on any machine on which you plan to run
scripts. Registering the DLL is easy; to do so, simply type
regsvr32 iadstools.dll
and the DLL is registered in HKEY_CLASSES_ROOT for use by your scripts. After the DLL is
registered, it exposes several methods for performing all kinds of Active Directory (AD) and
GPO-related tasks. For our purposes, we’ll just focus on the GPO-related methods. Table 6.1
shows the GPO-related methods and their purpose.
IADSTools Method Name Purpose
GetGPOVersion() Returns the version number of a GPO as held in
the Group Policy Container (GPC—within AD).
GetGPOSysVolVersion() Returns the version number of a GPO as held in
the Group Policy Template (GPT—within
SYSVOL).
GetGPOs() Returns a list of GPOs found on a given domain
controller. The list can be enumerated using the
following two functions (GPOName() and
GPOGuid()).
GPOName() Returns the friendly name of a GPO as retrieved
using GetGPOs().
GPOGuid() Returns the globally unique ID (GUID) of a GPO as
retrieved using GetGPOs()
GPOVersion() Returns the GPC version number of a GPO as
retrieved using GetGPOs(). Note that this function
is different than GetGPOVersion() as it requires
GetGPOs() to be run to enumerate a collection of
GPOs prior to being called.
GPOSysVolVersion() Returns the GPT version number of a GPO as
retrieved using GetGPOs(). Note that this function
is different than GetGPOSysVolVersion() as it
requires GetGPOs() to be run to enumerate a
collection of GPOs prior to being called.

Table 6.1: Viewing the methods available in IADSTools.DLL to query GPO information.

130
 Chapter 6

Now let’s look at how you might use IADSTools methods to query information in GPOs. The
following script compares the GPC and GPT versions of a GPO and reports back if they are out
of sync. Listing 6.3 shows a script that uses the GetGPOVersion and GetGPOSysVolVersion
methods to check the versions on a GPO (the line numbers have been added to the strict to aid in
this discussion).
1. Set objIADS=CreateObject("IADsTools.DCFunctions")
2. objIADS.EnableDebugLogging(3)
3. strdomain="mar-elia.com"
4. strDC="yquem"
5. strGUID="{D5D09664-0319-4BEC-97B2-5AC31B75D09B}"
6. GPCVer=objIADS.GetGPOVersion(cstr(strdomain),cstr(strDC),
cstr(strGUID),0)
7. GPTVer=objIADS.GetGPOSysVolVersion(cstr(strdomain),cstr(strDC),
cstr(strGUID),0)
8. Wscript.echo "GPC Version is: " & GPCVer
9. Wscript.echo "GPT Version is: " & GPTVer
10. if GPCVer <> GPTVer then
11. Wscript.Echo vbCRLF & "Versions are out of sync"
12. else
13. Wscript.Echo vbCRLF & "Versions are in sync"
14. End if

Listing 6.3: Viewing a WSH script that compares GPC and GPT versions for a GPO.

In Listing 6.3, I start off in line 1 by instantiating the IADSTools object, which is required in
every IADSTools script. In line 2, I’ve called the EnableDebugLogging method, which sends all
activity related to the script to the Application event log on the system on which the script runs.
I’ve simplified things by hard coding the domain name, domain controller, and GPO GUID that I
want to query in lines 3, 4, and 5. You can just as easily pass these into the script using
command-line arguments. Lines 6 and 7 do the hard work, which is to call the two version
methods and retrieve version info. Lines 8 and 9 report out the version numbers found and, if
they are different, the following code in lines 11,12, and 13 reports that they are different. Figure
6.9 shows a sample output of the script running twice—once with GPO versions in sync and
once when they’re not.

131
 Chapter 6

Figure 6.9: Viewing the output of the GPO version checking script.

Now let’s look at a script that enumerates the GPOs on a particular domain controller and tells us
some information about the GPOs. Listing 6.4 shows such a script (again, the line numbers have
been added for this discussion).
1. Set objIADS=CreateObject("IADsTools.DCFunctions")
2. objIADS.EnableDebugLogging(3)
3. strdomain="mar-elia.com"
4. strDC="yquem"
5. arrGPOs=objIADS.GetGPOs(cstr(strdomain),cstr(strDC))
6. For x = 1 to arrGPOs
7. Wscript.Echo "GPO NAME: " & objIADS.GPOName(x)
8. Wscript.Echo "GPO GUID: " & objIADS.GPOGUID(x)
9. Wscript.Echo "GPC Version #: " & objIADS.GPOVersion(x)
10. Wscript.Echo "GPT Version #: " & objIADS.GPOSysvolVersion(x) &
vbCRLF
11. Next

Listing 6.4: Viewing a script that uses the GetGPOs function to retrieve a list of GPOs on a domain controller.

The script in Listing 6.4 starts off similar to the script in Listing 6.3. I have decided to hard code
the domain and domain controller name into the script as before. Line 5 calls the GetGPOs
function, which stores the number of GPOs found on the domain controller in the variable called
arrGPOs. In line 6 through line 11, I use a For…Next loop to go through each GPO and get
information from it, which is then printed to the screen in lines 7, 8, 9, and 10. Figure 6.10 shows
the output from this script.

132
 Chapter 6

Figure 6.10: Viewing the output of an IADSTools script that enumerates all GPOs on a domain controller.

As you can see, the IADSTools DLL can provide some handy capabilities for scripting version
health checks on your GPOs. Using the previous scripts, you could check version information of
each GPO on every domain controller in your environment and easily report errors to a log or to
email.

Q 6.7: How can I add or remove particular policy extensions within the
Group Policy Object editor tool?
A: Although the ability is not readily exposed, you can create a Microsoft Management Console
(MMC) tool for Group Policy editing that simply does not contain certain policy extensions (for
example, folder redirection, IP security policy, and so on). Although this capability really
belongs to the MMC, your question highlights a fact about how the Group Policy editing tools
are implemented. Each policy capability within the default Windows 2000 (Win2K) and
Windows XP installations has two pieces. The first is the client-side extension (CSE), which is a
DLL that actually processes Group Policy Object (GPO) settings and applies them to the user or
computer. The other piece is the DLL that gives administrators the capability to create policy

133
 Chapter 6

settings within a GPO—the editing tools for GPOs. Each policy capability, such as
Administrative Templates, Security Settings, Software Installation, and Folder Redirection is
implemented in a separate DLL. Likewise, the DLLs for editing those capabilities are
implemented as separate DLLs—specifically MMC extension snap-ins.
Usually when you load a GPO into an MMC tool, all extensions are included by default, and thus
you will see all the available policy capabilities. However, it is possible and very easy to create a
custom MMC tool that exposes only certain MMC extensions, and thus only lets the user edit
certain portions of a GPO. This approach contrasts with the feature that lets you use
Administrative Template policy to physically prevent a user from loading certain MMC GPO
extensions within an MMC tool. In the approach that I discuss here, you’re not preventing the
use of the extensions if the user knows how to get to them. You are simply taking them out of the
user interface (UI) so that they aren’t obviously visible if not needed. Let’s see how this works.

The MMC differentiates between standalone snap-ins and snap-in extensions. A standalone snap-in
is one that can be loaded into an MMC console on its own and does not require any other supporting
snap-ins. Snap-in extensions, however, cannot be loaded on their own and require a standalone
snap-in to be loaded first to “host” them.

The first thing you need to do is to open a blank MMC console. Next choose Add/Remove Snap-
ins from the Console menu (or the File menu in Windows XP), and add the Group Policy
standalone snap-in. You’ll need to choose a GPO to focus on as you add it to the console. After
you’ve completed adding it to the console, you will see a dialog box similar to the one that
Figure 6.11 shows (in this case, focused on the local GPO in Windows XP).

Figure 6.11: Viewing an MMC console tool with the Group Policy snap-in loaded.

134
 Chapter 6

Usually, you simply click OK in this dialog box, then start editing the GPO. However, in this
case, we’re going to select the Extensions tab to view which extensions have been loaded (see
Figure 6.12).

Figure 6.12: Viewing the loaded extensions within the Group Policy snap-in.

As you can see, all extensions are typically loaded by default when you load the Group Policy
snap-in. However, if you clear the Add all Extensions check box, you can select which
extensions you want to expose in this console tool.
For example, suppose that I have a GPO tool that I want to create to give to my GPO
administrators. It will be a tool focused on the local GPO, but I don’t want to include any Public
Key policy options because I don’t use Public Key in my infrastructure. To do so, I am going to
select Security Settings from the Snap-ins that can be extended drop-down text box. When I
choose this snap-in, the list in the Available extensions section changes to show me which MMC
extensions can be run within the parent snap-in. To disable the Public Key security policy
extensions, I simply clear the Public Key Policies check box (see Figure 6.13), and the option
will not be included when I save this MMC tool.

135
 Chapter 6

Figure 6.13: Excluding Public Key policies from an MMC Group Policy tool.

As a result, when an administrator goes to edit the local GPO using my tool, the administrator
will no longer see an option for Public Key policies under User Configuration, Windows
Settings, Security Settings (see Figure 6.14).

Figure 6.14: Viewing an MMC GPO tool with the Public Key policies extension removed.

You can, of course, use this approach to remove any number of extensions. If you select Group
Policy from the Snap-ins that can be extended drop-down list, you can pick or choose any of the
policy nodes that are available within a normal GPO editing tool and can even remove major
nodes such as Administrative Templates (users or computers or both).

136
 Chapter 6

Q 6.8: What is the difference between the Local Security Policy tool
and using gpedit.msc to edit the local Group Policy Object?
A: Simply put, the Local Security Policy tool that you find in the Administrative Tools Start
menu group on Windows 2000 (Win2K) and Windows XP is a narrowed view of the local Group
Policy Object (GPO) that can be accessed using the Microsoft Management Console (MMC) tool
called gpedit.msc. The Local Security Policy tool (see Figure 6.15) is called as an MMC tool
named secpol.msc.

Figure 6.15: Viewing the Local Security Policy MMC tool.

If you’re familiar with GPO-based security policy, you will notice that Figure 6.15 looks
identical to the Security Settings node within a Group Policy under Computer Configuration,
Windows Settings, Security Settings. What you don’t see in Figure 6.15 is any of the parent
nodes within a normal GPO, such as the Windows Settings or Computer Configuration nodes.
You also don’t see any mention of which GPO you’re focused on. In fact, the view you see in
Figure 6.15 is simply a stripped down, focused view of the local GPO that you can view in its
entirety by launching gpedit.msc (see Figure 6.16).

137
 Chapter 6

Figure 6.16: Viewing the local GPO from the gpedit.msc MMC tool.

As you can see in Figure 6.16, the nodes under Security Settings are identical to those shown in
the Local Security Policy tool. It’s as if the Local Security Policy tool has “re-rooted” the
Security Settings node to be the root of a new window. In fact, that is exactly what is happening.
Try this experiment. Open a blank MMC console by typing
mmc
in the Start menu Run dialog box, select File (or Console for Win2K MMC users), Add/Remove
snap-in, and load the Group Policy snap-in focused on the local computer. You’re now viewing
the local GPO, just as gpedit.msc shows it to you. Now, navigate to Computer Configuration,
Windows Settings, Security Settings, right-click the Security Settings node, and select New
Window from Here from the context menu (see Figure 6.17). Look familiar? It’s pretty much the
same view that you see in the Local Security Policy tool.

138
 Chapter 6

Figure 6.17: Viewing a new window on the local GPO focused on Security Settings.

The main difference between the view in Figure 6.17 and the Local Security Policy tool is that in
the figure, there are more menu choices along the top of the tool. Namely, the Favorites and
Window menu items are missing from the Local Security Policy tool. What you’re witnessing is
a feature of the MMC that lets an MMC tool author “lock-down” a particular console
configuration to provide a focused set of administrative tasks for the user. In my tool that Figure
6.17 shows, if I were to select File (or Console for Win2K MMC users), Options from the
console menu, and change the mode of the console from Author Mode to User Mode-Limited
Access, single window (see Figure 6.18), then save the tool to an .MSC file, the next time I load
that tool, it will look identical to the Local Security Policy tool.

139
 Chapter 6

Figure 6.18: Changing the options on an MMC tool from author mode to user mode.

Indeed, the Local Security Policy console tool that Microsoft provides is just a Group Policy
MMC snap-in focused on the security settings node in the local GPO and saved in user mode to
prevent the user from loading other MMC snap-in extensions that show the other parts of the
GPO. You can actually easily override a tool saved in user mode and revert it back to author
mode by simply launching the .MSC file with the /a option:
Secpol.msc /a
After you do so, you’re free to modify the tool, add other MMC Group Policy extensions, and so
on. User mode is not hard security on a tool but simply a way of keeping a user from futzing
with settings that the user isn’t responsible for managing.

140
 Chapter 7

Chapter 7: Advanced GPO Features and Functions

Q 7.1: How can I view the internals of a Group Policy Object?

A: A Group Policy Object (GPO) is composed of two parts—the Group Policy Container (GPC)
and the Group Policy Template (GPT). You can see the contents of these two pieces by using
some very simple tools.
The ability to view the “guts” of a GPO can give you good insight into how this complicated
infrastructure works. The GPC is an object in Active Directory (AD) that contains several
settings related to its corresponding GPO. The GPT is a set of folders and files that are stored
under the SYSVOL share on an AD domain controller. Every GPO has exactly one GPC and
GPT. The key value that identifies a GPO and its constituent GPC and GPT is its globally unique
ID (GUID)—a 128-bit value that gets assigned to the GPO when it is created.
SYSVOL is replicated to every domain controller in an AD domain. Thus, the GPT and the GPC
for a given GPO also get replicated to every domain controller.

Locate the GUID

Let’s look at how you can examine the GPT and GPC of a GPO. First, we’ll start by examining a
GPO to determine its GUID. You can easily do so by following these steps.
1. Start either the Active Directory Users or Computers or Active Directory Sites and
Services Microsoft Management Console (MMC) snap-in.
2. Right-click the container object (the site, domain, or organizational unit—OU) in which
the GPO you want to examine is linked. Choose Properties from the context menu.
3. Select the Group Policy tab, and highlight the GPO you want to examine.
4. Click Properties, and you will see a dialog box similar to the one that Figure 7.1 shows.

Figure 7.1: Viewing the unique name for a GPO from its properties dialog box.

141
 Chapter 7

As you can see in Figure 7.1, the highlighted Unique name is the GUID for this GPO. Make a note of
the GUID as we move to examine the GPO’s GPC and GPT.

Navigate to the GPC

Now that we know the GUID for our GPO, we can look at its constituent parts. The easiest way
to examine the GPC is to use a familiar tool—the Active Directory Users and Computers MMC
snap-in. Follow these steps to view a GPO’s GPC.
1. Start the Active Directory Users and Computers MMC snap-in. Select the View menu on
the console, and ensure that the Advanced Features option is selected.
2. Expand the domain list within the left pane of the tool, then expand the System container.
3. Within the System container there is a container called Policies. Expanding this container
should reveal a series of containers named with GUIDs.
4. Locate the GUID that you identified in the series of earlier steps for your GPO, and
expand that container, as Figure 7.2 shows. This GUID-named folder is the GPC for the
GPO.

Figure 7.2: Viewing the GPC from within the Active Directory Users and Computers tool.

142
 Chapter 7

If you were to examine the AD attributes on the GUID-named folder that Figure 7.2 shows, you
would see several properties related to the GPO, including its current internal version, the path to
its GPT in SYSVOL, and its friendly name—the name you see when you’re browsing for GPOs.
In Figure 7.2, you can see two folders underneath the GUID-named folder—machine and user.
These two folders correspond to the computer and user nodes that you see when you edit a GPO
using the Group Policy MMC snap-in tool. If you expand either of these folders, you may see a
subfolder called Class Store and a folder underneath that called Packages. The Class Store and
Packages folders are present if you have set any software installation policy within the GPO. The
Class Store is an AD object that keeps information related to how the package was published or
assigned and where the Windows Installer setup file is located for the application.

Determine the GPT

Now lets look at the GPT. As I mentioned, the GPT is located within SYSVOL—the replicated
folder structure present on every AD domain controller. The easiest way to view the contents of
SYSVOL is to log on to the console of a domain controller in your AD domain, select Run from
the Start menu, and in the Run dialog box, type
\\<domainname>\sysvol
This action will open an explorer window with a subfolder that will show the name of your
current domain. If you open this folder, you should see the three folders that Figure 7.3 shows.

Figure 7.3:Viewing the contents of SYSVOL.

If you select the Policies folder, you will see a list of GUID-named folders similar to that found
when we examined the GPC. If you open the same GUID-named folder that we did when we
were looking at the GPC, you will likely see the subfolders and files that Figure 7.4 shows. The
contents of this GUID-named folder make up the GPT for the GPO.

143
 Chapter 7

Figure 7.4: Viewing the GPT for a GPO in SYSVOL.

Just as with the GPC, you see machine and user folders corresponding to machine- and user-
specific policy that is set within the GPO. In addition, the ADM folder contains any
Administrative Template .adm files associated with this GPO.

Each GPO can have its own separate and distinct set of .adm Administrative Template files. This
ability is different than Windows NT 4.0 System Policy, which lets you use only a single set of .adm
files within a domain policy.

You also see a file called GPT.INI. This file contains the internal version number for this GPT.
When a computer or user processes a GPO, this version number is compared to the one
contained with the properties of the GPC to determine whether the GPO has been replicated
correctly to all domain controllers within a domain. If the version numbers don’t match, the GPO
is considered out of sync, and is thus not processed.
If you were to drill further into the machine and user files, you would see any number of
subfolders and files corresponding to each of the various policy areas within a GPO (for
example, Administrative Templates, Security, Folder Redirection). The GPT is the storage
mechanism for the actual settings you make within the GPO when you edit it. If you make a
change to a GPO setting, that change is stored within the GPT. The one exception to this
behavior is that software installation, as I mentioned earlier, uses the GPC’s class store
mechanism as well as the GPT to store settings related to the policy.

144
 Chapter 7

Q 7.2: What is loopback policy and how does it work?

A: Loopback policy is a special mode of Group Policy Object (GPO) processing. It provides for
a way of overriding user-specific GPO policy when a user logs on to a particular computer that is
subject to loopback.
Loopback policy is particularly useful for computers that function as kiosks and for terminal
servers. Specifically, loopback gives you a way of overriding a user’s default Group Policies by
using a Group Policy defined for the particular computer to which they log on. Active Directory
(AD) users will normally log on to their own workstations and receive a set of computer- and
user-specific GPOs based on where their computer and user accounts are located in AD.
However, sometimes those users might need to log on to specialized computers that exist
elsewhere within an AD domain and that have special restrictions that apply only to those
computers—such as a kiosk or terminal server.
Typically, computers that are subject to loopback are placed in a separate organizational unit
(OU). Then a GPO is created and linked to that OU that enables loopback processing. You
enable loopback by setting an Administrative Template policy located in both Windows 2000
(Win2K) and Windows XP under Computer Configuration, Administrative Templates, System,
Group Policy. The policy item is called User Group Policy loopback processing mode, as Figure
7.5 shows.

Figure 7.5: Viewing the setting that enables loopback processing on a computer.

When you enable loopback processing, you have the option to choose two modes of operation—
replace or merge. I will describe what each of these means shortly. When a computer is set to
process GPOs using loopback, all users who log on to that computer might no longer receive any

145
 Chapter 7

user-specific GPO settings derived from where their user account is located (the exception to this
is when you select to merge user policies—as I’ll described later).
For example, take a user named jsmith whose account and principal workstation both reside in
the Finance OU. A number of GPOs are linked to the Finance OU that deliver user-specific
policy settings for jsmith, such as desktop lockdown, folder redirection, and software installation.
Now, suppose jsmith logs onto a kiosk computer located in an OU called Kiosk. All computers
that reside in Kiosk process GPOs using loopback. What this setting means is that when jsmith
logs onto the kiosk computer, he will no longer receive the user-specific policy settings that he
would receive if he logged onto his account that resides in the Finance OU. Instead, any user-
specific policies set by GPOs linked to the Kiosk OU will now take the place of jsmith’s “home”
policies.
So, for example, you might decide to set a special desktop lockdown setting through user-
specific Administrative Template policy when users log onto a kiosk machine. Likewise, you
might not want a user’s desktop folder to be re-directed using Folder Redirection policy when
that user logs onto a kiosk. Mechanically what happens is that when the user logs onto a
computer using loopback policy, the user’s “home” policies are removed, and the user-specific
policies defined in the GPOs linked to the OU where the loopback machines reside are applied
instead. When the user returns to his or her normal workstation, the loopback policies are
removed and the user’s home policies are restored.
Loopback policy processing is also useful in terminal server environments because you might
need to lock down a user’s desktop far more restrictively when the user is logging onto a
machine that is shared by many other users. In that case, loopback is an ideal solution.
The replace and merge functions of loopback that I mentioned earlier control how the user-
specific settings provided by the loopback GPOs are applied. In replace mode, all the user’s
previous GPO-based settings are removed and the loopback policy settings are applied. In merge
mode, both the user’s normal policy settings and the loopback policy settings are combined. If
there are conflicts between the user’s normal settings and loopback settings, the loopback
settings “win” and are applied. In most cases, I recommend using the replace mode, as it can get
extremely confusing to predict the resulting user policy when using merge mode.

Q 7.3: How can I change the path to a deployed application’s .msi file
once I’ve published or assigned the application?
A: Changing the path is not easy and might not be worth it for you! Ordinarily, when you
publish or assign an application using Group Policy Object (GPO)-based software installation,
you cannot go back from the GPO editor tool and change the path you assigned to the .msi file
that installs the application. Your only choice is to delete and re-add the deployed application.
However, you can directly edit the Group Policy Container (GPC) object within Active Directory
(AD), then follow a series of steps to change the path to the file.
Although this mechanism is not supported by Microsoft, it does work and is useful to know if
you need to change a fair number of applications and don’t want to have to delete them and start
over. However, you will have to use the redeploy feature within software installation, which
results in anyone who has received the application to date having it reinstalled on their next GPO
processing cycle.

146
 Chapter 7

To use this trick, you need to have installed the Windows 2000 (Win2K) Support Tools, which
contains the ADSI Edit Microsoft Management Console (MMC) snap-in tool. Let’s walk through
this technique with an example. Figure 7.6 shows that I’ve created a GPO that deploys the
Win2K Administration Tools as a published application.

Figure 7.6: Viewing an application deployed via GPO.

When I published this application, I entered the path for the .msi file package that installs it. That
path was a share on my server: \\yquem\packages\adminpak.msi. After the application is
published (or assigned), the path to the package is not exposed anywhere. However, using ADSI
Edit, I can directly edit the AD attribute that controls where that package is found. Here are the
steps to follow to edit this application’s path:
1. From the Group Policy editor tool, right-click the name of the GPO, and select Properties
to view the GPO’s globally unique ID (GUID). Make a note of the GUID.
2. Start the ADSI Edit MMC tool (adsiedit.msc) and, if you aren’t already, connect to the
domain naming context for your domain.
3. Under the domain naming context, drill down into the CN=system, CN=policies folder
and locate the folder that corresponds to the GUID of your GPO, as Figure 7.7 shows.

147
 Chapter 7

Figure 7.7: Viewing the GUID folder of a corresponding GPO in ADSI Edit.

4. After you’ve located the GUID, you will see a machine and user subfolder. In our case,
because we are editing user-based software installation, I will expand the user folder to
reveal a CN=Class Store subfolder.

If you expand the Class Store subfolder, you will expose a CN=Packages folder that contains one or
more GUID-named objects of class packageRegistration (see Figure 7.8). Each packageRegistration
object corresponds to a deployed application within the GPO.

Figure 7.8: Viewing packageRegistration objects within a GPO.

148
 Chapter 7

5. Double-click the desired packageRegistration object. (If there is more than one, you will
need to determine which one is the application you need to modify. To do so, double-
click the object, and, from the drop-down list of properties for the object, choose
displayName to see which application you’re editing).
6. After you’ve located the correct application, choose the msiFileList property to see the
list of current file paths for your application. You will notice that this list can have
multiple values. The reason is that if the original path was a distributed file system (Dfs)
share, the GPO will cache all the available replicas under the share where the package
can be found.
7. To edit a path value, select the value to edit, and click Remove to move the path into the
edit attribute dialog box (see Figure 7.9).

Figure 7.9: Editing the path to an .msi file in the deployed application.

8. You can now edit the path, being careful to leave the numeric reference (in Figure 7.9,
the reference is 0:) in place. After you’ve edited the reference to point to a new path,
click Add to commit it to the property.
9. The next step is to temporarily relocate the Application Advertisement Script (.aas file)
that was created when you first deployed the application. This .aas file contains hard-
coded references to the old .msi file path. For my example, the .aas file is located in
SYSVOL under policies\<GUID of GPO>\user\applications (see Figure 7.10). Move this
.aas file out of the SYSVOL folder on the server acting as the PDC emulator within your
domain.

149
 Chapter 7

Figure 7.10: Viewing the .aas file that is created when a GPO-based application is deployed.

10. Next, go back to your deployed application within the GPO editor tool. Right-click the
application name, choose Tasks from the context menu, then choose Re-deploy
Application. You will receive a failure message—acknowledge it.
11. If you go back to the SYSVOL folder from Step 10, you’ll see a new .aas file, called
temp.aas, has been created. Delete this file, and move the old .aas file back into this
folder.
12. Again, return to the GPO editor tool and redeploy the application one more time. You
should not receive any errors, and the application will now be installed from the new
location!
You may very well be thinking that this process is too much work to go through just to change
an application’s deployment path. That may be true, but there may be reasons why you can’t
simply delete and re-add an application. In that case, this technique works.

Q 7.4: How do I use software restriction policy in Windows XP?

A: Software restriction policy is new to Windows XP and gives you unprecedented control over
which applications a user can run on a Windows XP desktop. Software restriction policy does
not exist in Windows 2000 (Win2K) clients or earlier versions of the Windows desktop OS. It
can be found in Windows XP under User Configuration, Windows Settings, Security Settings,
Software Restriction Policies. To access software restriction policy on a local machine, select
Administrative Tools from the Start menu, then select the Local Security Policy Microsoft
Management Console (MMC) tool. Software restriction policy provides a very powerful and
proactive tool to help you combat common Windows-specific viruses as well as prevent your
users from executing certain types of files. Figure 7.11 shows this tool as it appears in an Active
Directory (AD)-based Group Policy Object (GPO).

150
 Chapter 7

Figure 7.11: Viewing software restriction policy in a Windows XP or Windows .Net GPO.

If you right-click the software restriction policies node, and select Create New Policies from the
context menu, two new folders, called Security Levels and Additional Rules, are created under
the node. In addition, three new policy items are listed off the root node. These new policy items
are called Enforcement, Designated File Types, and Trusted Publishers. Let’s look at each of the
features within the software restriction policies and what they do:
• Security Levels—Under the Security Levels node are two policies, Disallowed and
Unrestricted (this setting is an either/or setting). By default, Unrestricted is set as the
default state, but if you double-click the Disallowed item, and choose Set as Default then
this “arms” the software restriction policy. After Disallowed is set, no software will run
for any end user who is subject to that policy (unless you make exceptions, as we’ll see
later).
• Additional Rules—The Additional Rules folder lets you set up four kinds of rules to
control which types of files your users can execute. Rules override any default security
behavior set up in the Security Levels node. To access the rules, right-click the
Additional Rules folder, and choose a rule from the context menu (see Figure 7.12).

151
 Chapter 7

Figure 7.12: Viewing the available software restriction rules.

Let’s look at what each of these rules does:

• Certificate Rules—This option lets you choose a public key certificate, then lets you set
whether software signed by that certificate is allowed or disallowed. For example, if you
deploy a set of .vbs scripts in your environment, you could sign those scripts with a
public key certificate, then only grant your certificate as allowed. If a user then gets a
script file that’s not signed by you, the certificate rules will prevent the script from
running.
• Hash Rules—Similar to Certificate Rules, Hash Rules lets you specify that certain files
with unique hash values can either run or are disallowed from running. Hash values are
unique values that are derived by taking information about a file’s size, date and
timestamp, and other information to create a fingerprint of that file. Figure 7.13 shows an
example of a hash rule for which I simply chose to disallow a particular .gif file of a
specific hash value. You can manually enter a hash value rather than letting the rule
dialog box create one from a known file. This feature is useful if you’ve found a virus file
that has a well known hash value that you want to restrict.

152
 Chapter 7

Figure 7.13: Using a hash rule to prevent a file from being executed (or opened).

• Internet Zone Rules—Internet Zone Rules are used to set blanket policies from which
Internet zones (for example, Intranet, Internet, Trusted Sites, Restricted Sites) your users
may run Windows Installer packages. Internet Zone Rules are specific to Windows
Installer (.msi files) packages only.
• Path Rules—Path Rules let you specify disallowed or unrestricted execution policy for
certain folders or files on your users’ hard drives. For example, as Figure 7.14 shows, you
might specify a directory (in which mail attachments are typically stored) as disallowed
as a way of preventing rogue mail attachments from executing. For example, Outlook XP
will store attachments in a user’s profile under %userprofile%\Local Settings\Temporary
Internet Files prior to executing the attachment. You could create a path rule to that
subdirectory, then any files located within or under it will not execute. (Path Rules
support the use of environment variables such as %userprofile%.)

153
 Chapter 7

Figure 7.14: Viewing a software restriction path rule.

The final three global options within software restriction policies are Enforcement, Designated
Files Types, and Trusted Publishers. The Enforcement option lets you decide whether you want
to include DLLs within the possible types of files that are restricted by the rules you set. By
default, DLLs aren’t included, and if you do include them, you will need to spend a lot of time
figuring out which DLLs needed by approved software should be excluded from the restrictions.
Within the Enforcement screen, you can also specify whether members of the local workstation
(or server) Administrators group are subject to software restriction policies (see Figure 7.15).

Figure 7.15: Viewing the Enforcement options in a software restriction policy.

154
 Chapter 7

The Designated File Types policy lists all file types that are subject to the Certificate Rules and
Path Rules previously described. So if you allow applications signed by a particular certificate, it
will cover all file types (file extensions) listed in this section. You’ll notice that the default file
types listed are common types of “executable” code such as .exes, batch files, and Windows
Script Host (WSH) scripts, as well as common viral vectors such as .shs and .scr files. The
designated file types are global settings and apply to all software restriction policies that don’t
otherwise specify a particular file type.
Finally, the Trusted Publishers policy lets you control who can specify a trusted publisher and
lets you specify that you want to check with a certificate authority to see whether the publisher
has been revoked before allowing an application to run.
As you can see, software restriction policy is an extremely powerful new feature in Windows XP
that allows you to have very fine-grained control over what your users can and cannot do. This
ability can really come in handy as a second line of defense against viruses, especially when your
antivirus vendor has not yet have come up with a patch for a new virus.

Q 7.5: Can a client machine disable the processing of a Group Policy

Object?
A: There is no switch or registry entry that you can throw to easily disable Group Policy Object
(GPO) processing for a machine in an Active Directory (AD) domain that is destined to receive
GPOs. However, there are some drastic steps that you can take to disable some or all GPO
processing.
To understand how you can disable GPO processing, we will explore how GPOs are actually
processed. The real workhorse of GPO processing actually resides on the client side. That is,
although AD domain controllers house the Group Policy Container (GPC) and Group Policy
Template (GPT) that contain the actual policy settings for a given GPO, the code on the client—
Windows 2000 (Win2K) or Windows XP—actually reads those settings and does something
with them. That code is called a Client Side Extension (CSE), and is found by default on every
Win2K and Windows XP workstation. CSEs are implemented as dynamic-link libraries (DLLs)
and are typically found in %systemroot%\system32 on a machine. Win2K and Windows XP also
keep a list of registered CSEs for a given machine within the registry at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions.
Each CSE is registered as a key under the GPExtensions key, as Figure 7.16 shows.

155
 Chapter 7

Figure 7.16: Viewing registered CSEs on a Win2K machine.

As you might also notice from Figure 7/16, each CSE also keeps a set of default behaviors that
control how it processes GPOs. For example, the NoGPOListChanges value controls whether
that CSE will process a GPO even if its version number has not changed since the last processing
cycle. Win2K and Windows XP use this list of CSEs in the registry to determine which policy
features to process. Thus, in Figure 7.16, if I were to delete the key shown, which, as you can see
from the right pane of the registry editor, controls the Folder Redirection feature, that
workstation would no longer be able to process Folder Redirection policy. The same holds true
for other policy processing. If I delete the key that begins with “{8273D19E…”, I will be
disabling security policy processing on that workstation, and thus preventing any security policy
from being passed down to the workstation.

You must be an administrator on the local machine to actually delete these keys. Thus, as long as
you’re not granting users administrative access to your workstations, they won’t be able to use this
mechanism to foil your security and other GPO-based controls.

There are better ways to prevent a workstation from processing a GPO. As an administrator, you
can permission the GPO such that the user or machine does not ever get to process the policy.
However, there may be circumstances in which, from the client side, you might need to disable
some or all GPO features. By manipulating which CSEs are registered on a workstation or
server, you can control which policy features are processed.

156
 Chapter 7

Q 7.6: How do I enable Windows XP policies in a Windows 2000 Active

Directory domain?
A: Windows XP introduces quite a few new Group Policy Object (GPO)-based Administrative
Template settings as well as some new policy functionality—such as software-restriction
policies. If you’re deploying Windows XP clients in a Windows 2000 (Win2K)-based Active
Directory (AD) domain, you can “upgrade” your AD-based GPOs to support the new policies.
Remember that the actual processing “smarts” behind a GPO are stored in so-called Client Side
Extensions (CSEs) on the workstation or server that is processing the GPO. As such, it makes
complete sense that Windows XP comes with newer or more capable policies than those found in
Win2K. So if you want to deploy Windows XP in your existing Win2K AD domain, how do you
take advantage of those new policies without breaking policy on your Win2K machines? It’s
quite simple really.
The first thing you need to do is to be able to open GPOs using the standard Microsoft
Management Console (MMC) snap-ins that you are used to in Win2K. Unfortunately, the server
management tools, such as Active Directory Users and Computers and AD Sites and Services
that are part of the Win2K Administration Tools Pack, no longer work in Windows XP. As of
this writing, the only way you can manage AD-based GPOs on a Windows XP machine is to
download and install the .NET Server Beta 3 Administration Tools Pack .MSI file from
Microsoft’s Web site.

The .NET Server Beta 3 administration tools for Windows XP can be found at
http://www.microsoft.com/downloads/release.asp?ReleaseID=34032&area=search&ordinal=9.

After you’ve installed the Beta 3 administration tools, you’re ready to convert your existing AD-
based GPOs into Windows XP–capable policies. The process is very straightforward. All you
need to do to upgrade your GPOs, is to open each GPO in your AD domain using the Group
Policy MMC snap-in tool running on a Windows XP workstation. The act of opening the GPO
upgrades it to be able to support Windows XP–based policies; at the same time, your Win2K
policies are still intact. You need to perform this GPO open process on every GPO within your
AD domain that you want to support XP clients.
What’s happening behind the scenes during this process is pretty straightforward. Remember that
the Group Policy Template (GPT) portion of a GPO holds the actual files and settings that
represent the current policy that has been set. When you open a GPO using Windows XP,
Windows XP uploads the newer .adm Administrative Template files into the Adm folder within
the GPT for that GPO (see Figure 7.17).

157
 Chapter 7

Figure 7.17: Viewing the Adm folder within a GPO’s GPT.

This process of opening the GPO automatically enables Administrative Template policy that is
Windows XP–specific to be set within that GPO. Windows XP introduces the SUPPORTED tag
into Administrative Template .adm files. This tag lets the client determine whether the policy is
meant for its version of the OS or a newer one. If you try to set an Administrative Template
policy that is only meant for Windows XP but that is processed by Win2K workstations, the
individual policy item (not the entire GPO) will simply be ignored.
Another thing to keep in mind is that after you’ve upgraded your GPOs to be Windows XP–
capable, you aren’t limited to editing them on Windows XP clients. You can continue to edit
them using either Win2K or Windows XP administration tools.

Q 7.7: How is Group Policy Object history stored and used on the
client?
A: The default behavior of Group Policy Object (GPO) processing is that a client will not
process a GPO if the GPO has not changed since the last processing time. But how does the
client know whether the GPO has changed? The answer is that the client knows by using GPO
History.

158
 Chapter 7

GPO History is nothing more than a set of keys and values in the registry on Windows 2000
(Win2K) and Windows XP systems in which a history of GPO processing is kept. This history is
stored both a per-user and per-computer basis, corresponding to the fact that GPOs have both
computer- and user-specific parts. The per-computer history can be found in the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group
Policy\History subkey. And the per-user history is in the corresponding key in
HKEY_CURRENT_USER:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History.
Under the History keys, you fill find a number of GUID-named keys. These keys correspond to
the various client-side extensions (CSEs) that implement policy on a given machine. You can
cross-reference these CSE GUIDs to the actual policy function they provide by looking in the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions subkey. Under each GUID-named key is the
numerically named subkeys that correspond to each GPO that the computer or user has processed
for a given CSE (see Figure 7.18).

Figure 7.18: Viewing the contents of GPO History stored in the registry on a Win2K computer.

In Figure 7.18, the keys named 0 and 1 under each CSE key correspond to the GPOs that have
been processed by this computer. If I select one of these numbered folders, I can see more detail
about the GPO and its version when last processed. Figure 7.19 shows what this looks like.

159
 Chapter 7

Figure 7.19: Viewing the detailed history information for the last processing of a GPO.

What Figure 7.19 shows:

• This system ran the Scripts CSE (defined by the GUID in the left pane beginning with
{42B5F…) against the Default Domain Controllers policy.
• The DSPath value points to the Machine folder underneath the Group Policy Container
(GPC) for this GPO and the FileSysPath value points to the Machine folder within the
Group Policy Template (GPT) for this GPO.
• The Extensions value lists all the CSEs that are implemented within this particular GPO
(that is, which types of policy have been set in the GPO) by their CSE GUID.
• The GPOLink value describes where in AD or on the local computer this particular GPO
was linked to when it was processed. The number 4 corresponds to an OU-linked GPO. A
number 1 in this value corresponds to the local GPO, 2 to a site-linked GPO, and 3 to a
domain-linked one.
• The GPOName is, of course, the friendly name of this GPO.
• The Link value shows the full AD path to where this GPO was linked when it was
processed—in this case, to the Domain Controllers OU.
• IParam is an optional value that is used by some CSEs.
• The Options value shows whether No Override or Disabled flags have been enabled for
this GPO.

160
 Chapter 7

• The Version value shows the current version of this GPO. This is the version number
stored in the GPT and GPC, not the number of revisions on the GPO. This version
number is key because it helps the user or computer know whether the GPO has changed
on subsequent processing cycles. If it has not changed and the default processing
behavior has not been modified, the GPO will be skipped for this CSE until the version
number does change.
As you can imagine, the per-user and per-computer history keys provide a valuable service not
only in determining whether a GPO has changed from the last processing cycle, but also in
helping Win2K and Windows XP know when a GPO no longer applies to the user or computer.
In this case, policy settings that no longer apply can successfully be removed during the next
policy processing cycle.

Q 7.8: I’ve heard that Windows .NET Server will provide the ability to
filter Group Policy Objects using a Windows Management
Instrumentation filter. What is that?
A: Yes, Windows .NET Server will provide an additional filtering capability with Group Policy.
In addition to being able to filter the effects of Group Policy based on user or computer groups,
you will be able to create Windows Management Instrumentation (WMI) queries that provide the
ability to dynamically filter GPO effect based on WMI parameters such as hardware
configuration, software configuration, and so on.
WMI is a set of management providers that ships in Windows 2000 (Win2K) and Windows XP
that provides very detailed management information about your Windows systems. WMI is
Microsoft’s implementation of the Web-Based Enterprise Management (WBEM) initiative
created by the Desktop Management Task Force (DMTF). The ability to filter the effects of a
Group Policy Object (GPO) based on WMI information is very powerful. You could, in effect,
filter GPO processing based on how much memory a particular computer has or whether a
particular application is installed on a computer.
If you view a GPO from within the Microsoft Management Console (MMC) Group Policy editor
on a Windows .NET Server, you will see a new tab on the GPO’s properties page—called WMI
Filter (see Figure 7.20). This tab lets you select a WMI Query Language (WQL)-based query to
associate with the GPO.

161
 Chapter 7

Figure 7.20: Viewing the option in Windows .NET Server to filter a GPO using a WMI query.

If I click Browse/Manage, I can select an existing query or create a new one. Figure 7.21 shows
an example of a WMI query filter that I created on a GPO.

Figure 7.21: Viewing a WMI query created on a GPO.

162
 Chapter 7

In Figure 7.21, I have created a WMI query filter that checks the time zone of the computer that
processes the GPO. Only machines with a time zone of Pacific Standard Time will process this
GPO as a result of the query filter. The format of the query that Figure 7.21 shows is a standard
WQL query (SELECT * from Win32_TimeZone WHERE StandardName=”Pacific Standard
Time”), pre-pended by the root namespace in WMI (Root\CIMv2). You need to specify that root
namespace unless you plan to query another namespace within WMI. Most queries that you are
likely to perform will use the CIMv2 namespace.

Although a full discussion of WMI and WQL are beyond the scope of this book, an excellent resource
for learning about WMI is Marcin Policht’s WMI Essentials for Automating Windows Management
(SAMS).

When using WMI filters to filter the effects of a GPO, you will need to keep in mind the
performance impact of these WMI queries. The WMI queries are performed dynamically on the
computer on which the GPO is being processed. This operation is expensive from a CPU
perspective. Thus, a good practice is to use WMI filtering only on those rare occasions in which
you really need to filter a GPO based on a parameter specific to the computer that can’t be
represented within a regular computer-based group.

163
 Chapter 8

Chapter 8: Troubleshooting GPOs

Q 8.1: What is the best tool to show me whether all of my Group

Policy Objects have been replicated correctly to all domain
controllers?
A: As I mentioned in Chapter 7 Question 7.1, a Group Policy Object (GPO) is composed of a
Group Policy Template (GPT) and Group Policy Container (GPC). These two pieces are
replicated to all domain controllers in your Active Directory (AD) domain on separate
replication mechanisms. Thus, if a GPO gets out of sync, it will not be processed by a computer
or user.

GPOTool.exe
You need a way to determine whether a GPO has not replicated correctly. There are a couple of
quick and easy tools you can use to do so. The Windows 2000 (Win2K) resource kit contains a
command-line tool called GPOTool.exe that verifies the consistency of one or more GPOs within
your domain across all domain controllers. Suppose I want to determine whether a GPO called
HQ Lockdown Policy on a particular domain controller called YQUEM is in sync. I can issue the
following GPOTool command to run the check:
gpotool /gpo:"HQ Lockdown Policy" /dc:yquem
Figure 8.1 shows the results of this command.

Figure 8.1: Viewing errors found in GPO synchronization using the GPOTool resource kit tool.

164
 Chapter 8

In Figure 8.1, GPOTool has found a GPO version mismatch between the GPC (referred to as DS
version for directory service in the figure) and the GPT (referred to as Sysvol version). In some
cases, version mismatch problems may point to a problem with either AD or SYSVOL
replication. If GPOTool shows a version-mismatch problem, check the System and Directory
Services event logs on the domain controller showing the problem. Also, check other domain
controllers using GPOTool or Replmon.exe, which I describe next, to see if the problem is more
widespread.

Replmon.exe
In addition to GPOTool, the Win2K and Windows XP Support Tools contains a GUI-based tool
called Replmon.exe. This tool is a graphical utility for viewing the status of a variety of AD-
based replication issues. One of its side benefits is that it also reports on GPO replication status
on a per-domain controller basis. Follow these steps to check GPO replication status on a domain
controller:
1. Start the Replmon.exe tool from the Support Tools folder. If you haven’t already added a
domain controller to monitor, right-click the Monitored Servers node in the left pane, and
select Add Monitored Server.
2. Click Next, then type in the name of the server explicitly. After typing the server name,
click Finish. Your domain controller will appear under the name of the site in which it is
located, as Figure 8.2 illustrates.

Figure 8.2: Viewing a monitored domain controller within the Replmon tool.

165
 Chapter 8

As you can see, in the right pane of Figure 8.2, the replication status of the GPOs stored on the
domain controller called Yquem is shown. You can get a better view of this status by right-
clicking the server name, and selecting Show Group Policy Object Replication Status. A window
similar to the one that Figure 8.3 shows will appear.

Figure 8.3: Viewing GPO replication status from within Replmon.

As you can see in Figure 8.3, there is an X by the HQ Lockdown Policy, indicating that the GPC
and GPT are out of sync. You can also see that they’re out of sync to the right—the version
numbers are different (the Version column represents the GPC and the SysVol Version column
represents the GPT).
Replmon is a good tool for giving you a view of all GPOs on a given domain controller. You can
also add domain controllers to the Replmon monitor list, and view GPO status across many
domain controllers. GPOTool and Replmon are complimentary tools that together help you keep
an eye on GPO replication status across your infrastructure.

166
 Chapter 8

Q 8.2: How can I use event log entries to troubleshoot Group

Policy Object problems?
A: In Question 2.1 in Chapter 2, I showed you how you can enable verbose Group Policy Object
(GPO) event logging in the Windows Application event log. You can use the event log entries
created by this logging to determine where problems are occurring in your GPO processing
infrastructure.
The key to using GPO event logging is to know how to read the entries that are generated. When
a computer starts up, in the Application event log, you will see a number of entries that have a
source of Userenv. These entries represent one of the main sources for GPO processing. You can
trace the whole path of computer and user GPO processing, from start to finish, fairly easily
because event log entries are created at the start and finish of each policy processing cycle (see
Figure 8.4).

Figure 8.4: Viewing the start message for computer-specific GPO processing in the Application event log.

Each major step in the GPO processing cycle triggers an event log entry. For example, Figure 8.5
shows the step in which the computer has identified all GPOs to which it is subject (including the
local GPO, which is always processed first).

167
 Chapter 8

Figure 8.5: The computer has enumerated all the GPOs that it must process.

Where event logging really comes in handy is during the actual processing of GPOs, when
entries are generated to describe exactly what’s happening during the processing cycle. For
example, in Figure 8.6, the computer has checked the GPOs it must process and has found that
none of them have changed since the last time they were processed. Therefore, the computer
simply skips processing those GPOs.

Figure 8.6: The computer has not found any changed GPOs, so it skips processing them.

168
 Chapter 8

Of course, Userenv is not the only process that will show up as the owner of GPO processing
events. In Figure 8.7, a GPO-defined logon script that should have been found was not found,
and thus triggered an error that has a source of UserInit—the process responsible for running
logon scripts.

Figure 8.7: Viewing an error of source UserInit—a logon script was not found.

In Win2K, you will often see error codes associated with a GPO event log entry. For example,
you might see a message that includes error codes and flags. The message will say something to
the effect of The operation generated error # xx and returned flags # yy. These messages might
seem cryptic and not very well defined, but they indeed correspond to real error codes in
Windows. Specifically, the error codes correspond to Win32 error codes, which you can find in
the Microsoft Platform software development kit (SDK) in a file called winerr.h or you can find
them in a downloadable Excel file found at
http://www.microsoft.com/windows2000/techinfo/reskit/ErrorandEventMessages/default.asp.
The flag codes are specific to Group Policy, and can also be found in the Platform SDK, within a
file called userenv.h. Fortunately, as Figure 8.8 shows, Windows XP does a much better job of
detailing the errors behind the error codes and flags than Win2K does.

169
 Chapter 8

Figure 8.8 Viewing the GPO event entries in Windows XP.

As Figure 8.8 shows, Windows XP is much better that Win2K is at detailing how to find out why
something isn’t working in GPO processing. However, interestingly, Windows XP marks all the
GPO-related event log processing entries as error messages, rather than just informational
messages in the event logs. This classification can be disconcerting when you start looking at the
event logs and see a sea of red x’s. Just be aware that when you open the message, it might or
might not be a critical error worthy of concern.

Q 8.3: What is the best way to determine whether security policy is

being delivered to a workstation or server?
A: The answer to this question depends to some degree upon whether you’re using Windows
2000 (Win2K) or Windows XP. Which tool you use to validate that you’re receiving security
policy depends upon the extent of information you need. For example, in Win2K, you can use
some built-in tools to determine which are your effective security settings on a workstation or
server, but these tools won’t tell you which Group Policy Object (GPO) delivered those settings.
To get that basic information, you simply fire up the local GPO editor—gpedit.msc—and view
security settings. As Figure 8.9 shows, the local GPO editor shows you the local and “effective”
settings for a given security policy.

170
 Chapter 8

Figure 8.9:Viewing local and effective security settings on a GPO.

Local settings are those defined on the local machine. If effective settings are different than local
settings, a GPO has delivered some alternative settings that take precedence over the local ones.
You can also use GPO logging (discussed in Question 8.2) to see which GPOs are delivering
security policy, but you can’t see what those policies are for each GPO. In Win2K, if you need to
see which GPO is delivering which security policy, you really need to look to third-party tools
such as FullArmor’s FAZAM 2000.
However, in Windows XP, the story gets a bit better. The gpresult.exe command-line tool that
comes with Windows XP has the ability to resolve security settings (the Win2K version does
not) and the Resultant Set of Policy (RSoP) MMC snap-in tool (stored as rspop.msc) that comes
with Windows XP also has the ability to view effective security settings. Of course, in Windows
XP, you can still look at the local GPO to see the current effective security at the workstation or
server.

171
 Chapter 8

Q 8.4: How can I determine whether Domain Name System problems

are affecting my Group Policy Objects’ functionality?
A: Domain Name System (DNS) problems are just one of the things that can cause Group
Policy Object (GPO) failures. There are several quick and dirty tools you can use to determine
whether DNS is causing your problems. Correct GPO processing relies on the ability for a
Windows 2000 (Win2K) or Windows XP workstation (or server) to contact an Active Directory
(AD) domain controller and make several queries. The system uses the Lightweight Directory
Access Protocol (LDAP) to determine where GPOs are linked in AD’s hierarchy and where the
Group Policy Containers (GPCs) are for each GPO that is found.
To correctly locate the LDAP service on a domain controller in the workstation’s site, DNS is
used to query for the SRV record called
_ldap._tcp.<sitename>._sites.dc._msdcs.<domainname>, where <sitename> is the name of the
site the workstation resides in and <domainname> is the name of the AD domain where that
machines resides. If you’re having DNS problems that prevent the workstation from resolving
this name, GPO processing will fail, and that failure manifests itself in no GPO processing
occurring. The confounding thing about this problem is that it is still possible for the user to
successfully authenticate to the domain and logon as if there were no problems. Such usually
occurs in domains in which NetBIOS over TCP/IP (NetBT) is still enabled and the Windows
Internet Naming Service (WINS) is still in use. Although DNS is not working correctly, the
workstation can still use WINS and NetBT to authenticate the user to the domain. However,
crucial DNS information required for GPO processing is missing.
There are usually two main reasons why DNS-related GPO problems occur. The first is that the
domain controllers in your AD domain are not correctly registering all their SRV records with
DNS. This process is supposed to be automatic, in which domain controllers use dynamic DNS
(DDNS) to register all appropriate records when they come up. However, sometimes this
registration does not happen, and in that case, the records are never found. If that turns out to be
a problem, you can try running the command
Ipconfig /registerdns
from any domain controller having problems. You can also try stopping and restarting the
Netlogon service on the problem domain controller, which will usually re-register all appropriate
SRV records in DNS.

Check out the Microsoft article “SRV Records Missing After Implementing Active Directory and
Domain Name System” (Q241505) for more tips about fixing missing SRV records.

The other reason there may be DNS problems is that the client machine may not be able to
contact DNS or may be contacting the wrong DNS servers. There could be several reasons for
this behavior, including network problems, bad DNS client configurations, or an incorrect DNS
server configuration. In any case, you can easily troubleshoot the problem by using the nslookup
utility.

172
 Chapter 8

Like its UNIX counterpart, nslookup is an important tool for validating DNS client operation. To
check whether a client is successfully finding the key SRV record needed for proper GPO
operation, simply start nslookup by typing
nslookup
at a command prompt. When you reach the nslookup shell, you need only type the name you’re
trying to resolve and, if successful, nslookup returns the IP address for the name (see Figure
8.10).

Figure 8.10: Viewing a successful search for the LDAP SRV record in AD.

If the name is not found, you know you’re having DNS issues and need to look either to the
server or to the client’s configuration to resolve the problem.

Q 8.5: Why am I having trouble enabling security policy such as

auditing and event log settings on my domain controllers?
A: There is an interesting interplay between the built-in Default Domain Policy and Default
Domain Controllers Policy that can cause confusion when trying to enforce domain-wide
security policy. Security policy is a tremendous source of confusion within Active Directory
(AD), and the cause of many perceived problems. However, the rules are fairly straightforward,
and as long as you stay mindful of them, you won’t have any problems.
The first rule is: Domain-wide account policy can only be set at a Group Policy Object
(GPO) linked to the domain. Typically the Default Domain Policy is used to set account policy
because Default Domain Policy is a special system GPO and can never be deleted. However, you
can set account policy in any GPO that is linked at the domain level. Domain controllers,
regardless of where they reside in your AD (within the Domain Controllers organizational unit—
OU—or elsewhere), will only look to domain-linked GPOs to get their account policy. You can
set other account policy for member servers elsewhere in your AD infrastructure, but domain
controllers will only respect domain-linked account policy.
The second rule is just as useful: By default, the Domain Controllers OU is set to block policy
inheritance (see Figure 8.11), meaning that no “upstream” GPOs can override security
policy set within GPOs linked to this OU.

173
 Chapter 8

Figure 8.11: Viewing the Block Policy Inheritance feature enabled on the Domain Controllers OU.

The exception to this rule is the first rule—Account policy cannot be set at the Domain
Controllers OU level, only at the domain level. All other security policy for the domain should
be set in the Default Domain Controllers Policy GPO or another GPO linked to the Domain
Controllers OU, including audit policy, event log policy, services security, and so on.
The bottom line is that if you try to enable local policies such as auditing for your domain on any
GPO other than the ones linked to the Domain Controllers OU, those policies will never be
processed due to the Block Policy Inheritance check box being selected on that OU. You will
save yourself a lot of troubleshooting time trying to figure out why you’re domain controllers
don’t have auditing enabled by setting auditing policy on a GPO linked to the Domain
Controllers OU.
You might think that you can simply disable the Block Policy Inheritance option on the Domain
Controllers OU to allow security policy to be set elsewhere. In fact, you can’t! If you disable this
option, security policy processing on domain controllers in that OU will simply fail with an
SCECLI event and error flag of 81 (as the Application event log with verbose GPO logging
enabled will show).
This feature prevents any “rogue” GPOs upstream from the Domain Controllers OU from
undoing any local security policy for your entire domain. But it can cause confusion when you
believe that you’re disabling the Block Policy Inheritance feature and the only error you get is
that none of your upstream policies seem to be applied.

174
 Chapter 8

Q 8.6: Why can I sometimes view a Group Policy Object in the list of
Group Policy Objects linked to a container, but can’t edit that object?
A: Usually, this outcome is the result of a permissions issue; you might have sufficient
permissions to view a Group Policy Object (GPO) link but not to actually edit the GPO. Figure
8.12 shows an example of a message you might see when trying to edit a GPO.

Figure 8.12: Viewing an inaccessible GPO.

The error—inaccessible GPO-Access Denied—is typically caused by the fact that the user who
is trying to edit that GPO does not have Read permissions on the GPO. In this case, the access
control list (ACL) on the GPO didn’t contain the Authenticated Users group, which normally has
Read permissions as a minimum setting on all GPOs. Figure 8.13 shows this GPO’s ACL, which
doesn’t contain the Authenticated Users group, resulting in the error.

175
 Chapter 8

Figure 8.13: Viewing the ACL on a GPO that results in an inaccessible error.

Special care needs to be taken when removing the Authenticated Users group permission from a
GPO. By removing this permission, you effectively prevent all users from being able to read, and
thus process a GPO. A user receiving an inaccessible error message can sometimes be a good
thing. For example, if the GPO controls security on your domain, you probably don’t want a user
account that doesn’t process machine-specific security GPO in the first place to even be able to
see it, let alone edit it. You’ll also note that in Figure 8.12, the Edit button is grayed out,
indicating that the user doesn’t have write permissions on the GPO either.
Permission problems can be tricky, but typically the problem comes down to overlooking a
simple granting (or removal) of permissions to straighten things out.

176
 Chapter 8

Q 8.7: When I try to edit a Group Policy Object, I get an error message
that says the domain controller is not found. DNS isn’t the problem,
what else could it be?
A: This problem is a known issue when trying to edit Active Directory (AD)-based Group
Policy when Microsoft File and Print Sharing has been disabled on the PDC role holder in your
domain. Because the ability to edit a Group Policy Object (GPO) relies on File and Print Sharing
(and specifically file services) to be available, this service needs to be running in order for you to
be able to successfully edit a GPO. Remember that, by default, the Group Policy Microsoft
Management Console (MMC) snap-in tries to connect to the PDC emulator within your AD
domain first when opening a GPO. If File and Print Sharing services are not running on the PDC
role holder, you might get a message similar to the one that Figure 8.14 shows.

Figure 8.14: Viewing the error message you receive when you try to edit a GPO while File and Print Sharing
services are disabled.

If you choose one of the other options that Figure 8.14 shows, you might get another error
message, as Figure 8.15 shows.

Figure 8.15: Viewing the error message presented after the Group Policy snap-in fails to find a domain
controller to connect with.

177
 Chapter 8

After you receive the error message that Figure 8.15 shows, a curious thing will happen. If you
try to view the GPOs in your domain from that Active Directory Users and Computers MMC
snap-in, the list of GPOs linked to a particular container will appear empty; very disconcerting!
The quick and easy solution to this problem is to verify that File and Print Sharing services are
enabled on the PDC role holder in your domain (at the least). To do so, bring up the network
connections applet—I like to simply type ncpa.cpl from a command line in Windows 2000
(Win2K) or Windows XP to start the applet. Right-click the Local Primary Area Connection
applet, choose Properties from the context menu, and make sure that the File and Printer Sharing
for Microsoft Networks check box is selected (see Figure 8.16).

Figure 8.16: Viewing the dialog box to enable File and Print Sharing in Win2K.

After you re-enable File and Print Sharing, you should be able to successfully connect to and edit
GPOs. The interesting part of this problem is that, with this service disabled, you can’t even
connect to GPOs if you are sitting at the console of the PDC role holder domain controller. So
you don’t have to be remote to feel the effects of this configuration problem.

178
 Chapter 8

Q 8.8: I’m having problems with security policy processing. Is it

possible to get more in-depth troubleshooting information than that
provided by the event logs?
A: Yes, you can enable verbose security policy logging that provides much more detailed
information than you can get from even the verbose Group Policy Object (GPO) logging that is
written to the Application event log or %systemroot%\debug\usermode\userenv.log. To enable
verbose security policy logging, you will need to add a value to the registry. Fire up regedit.exe
or regedt32.exe and navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\G
PExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}. Within this GUID-named key,
add a new value of type REG_DWORD called ExtensionDebugLevel, and give it a value of 2.
The change will take effect right away. The log file that is created by this registry entry is called
%systemroot%\security\logs\winlogon.log.

If you don’t see winlogon.log appear on a Windows 2000 (Win2K) workstation after enabling logging,
try applying Service Pack 3.

Winlogon.log is a text file that contains quite a bit of information about the processing of
security policy. You can see the effects of this logging immediately by triggering a background
refresh of policy using secedit.exe:
Secedit /refreshpolicy machine_policy
Figure 8.17 shows a sample of a log file generated by this registry key change.

Figure 8.17: Viewing the winlogon.log file tracking security policy changes.

The log file will report success or failure of the processing of each section within security policy.
It will also report which GPOs are being processed, so you can ensure that all the expected
security policy is being processed.

179