Windows 2000 Group Policy

8/15/2019 Windows 2000 Group Policy

http://slidepdf.com/reader/full/windows-2000-group-policy 1/186

Windows 2000

Group Policy

Darren Mar-Elia

tm

realtimepublishers.com

Tips and Tricks Guide Totm



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 amajor first in the publishing industry. The founding concept behind Realtimepublishers.com isthe idea of providing readers with high-quality books about today’s most critical IT topics—at nocost to the reader. Although this may sound like a somewhat impossible feat to achieve, it ismade possible through the vision and generosity of corporate sponsors such as FullArmor, whoagree to bear the book’s production expenses and host the book on its Web site for the benefit ofits Web site visitors.

It should be pointed out that the free nature of these books does not in any way diminish theirquality. 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 othersignificant benefits. For example, the electronic nature of this eBook makes events such aschapter updates and additions, or the release of a new edition of the book possible to achieve in afar 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 theinformation 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 onlinelocation of the book, this book is by no means a paid advertisement. Realtimepublishers is anindependent publishing company and maintains, by written agreement with the sponsor, 100%

editorial control over the content of our titles. However, by hosting this information, FullArmorhas set itself apart from its competitors by providing real value to its customers and transformingits 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 valueto 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 authorsand editors, and publish books that help IT personnel, IT managers, and users to do theireveryday jobs. To that end, I encourage and welcome your feedback on this or any other book inthe Realtimepublishers.com series. If you would like to submit a comment, question, orsuggestion, please do so by sending an email to [email protected], 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

http://www.realtimepublishers.com/

http://titan/RTP/Books/Definitive%20Guide%20Series/Front%20Matter%20Templates/[email protected]



http://titan/RTP/Books/Definitive%20Guide%20Series/Front%20Matter%20Templates/[email protected]




Note to Reader: This book presents tips and tricks for eight Windows 2000 and Windows XPGroup 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 GroupPolicy 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 WindowsXP?...................................................................................................................................................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 SystemPolicies and Group Policy Objects?...............................................................................................19

Q 1.6: Do Group Policy Objects contain all the same policy settings that I used in Windows NT4.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 arestored?............................................................................................................................................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 inActive Directory?...........................................................................................................................38

Q 2.6: Can I permission a Group Policy Object such that someone can view its settings but notedit them?.......................................................................................................................................40

Q 2.7: Is the Group Policy Object architecture extensible—can I create new types of GroupPolicy Objects? ..............................................................................................................................44

Q 2.8: What is happening during background refresh of a Group Policy Object and how do Ichange 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 Directoryenvironment?..................................................................................................................................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 logoff 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 andedit 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 inthat 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 myexisting 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 GroupPolicy Object link?.......................................................................................................................113

Q 5.7: How can I delegate administration of a Group Policy Object to users who reside indifferent 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 GroupPolicy 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 atonce? ............................................................................................................................................126

Q 6.5: Do I have any control over how quickly the SYSVOL (Group Policy Template) portion ofa 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 Objecteditor tool? ...................................................................................................................................133

Q 6.8: What is the difference between the Local Security Policy tool and using gpedit.msc to editthe 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 orassigned 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 PolicyObjects 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 beenreplicated 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 aworkstation or server?..................................................................................................................170

Q 8.4: How can I determine whether Domain Name System problems are affecting my GroupPolicy 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?...........................................................................................................173Q 8.6: Why can I sometimes view a Group Policy Object in the list of Group Policy Objectslinked 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 domaincontroller 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-depthtroubleshooting information than that provided by the event logs? ............................................179

v



Copyright Statement

© 2002 Realtimepublishers.com, Inc. All rights reserved. This site contains materials thathave been created, developed, or commissioned by, and published with the permissionof, Realtimepublishers.com, Inc. (the “Materials”) and this site and any such Materials areprotected 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 IMPLIEDWARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,TITLE AND NON-INFRINGEMENT. The Materials are subject to change without noticeand do not represent a commitment on the part of Realtimepublishers.com, Inc or its website sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors beheld liable for technical or editorial errors or omissions contained in the Materials,including without limitation, for any direct, indirect, incidental, special, exemplary orconsequential damages whatsoever resulting from the use of any information containedin the Materials.

The Materials (including but not limited to the text, images, audio, and/or video) may notbe copied, reproduced, republished, uploaded, posted, transmitted, or distributed in anyway, 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 modifyor obscure any copyright or other proprietary notice.

The Materials may contain trademarks, services marks and logos that are the property ofthird parties. You are not permitted to use these trademarks, services marks or logoswithout prior written consent of such third parties.

If you have any questions about these terms, or if you would like information aboutlicensing materials from Realtimepublishers.com, please contact us via e-mail [email protected].

vi

mailto:[email protected]

mailto:[email protected]



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 XPGroup 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 Win2Kand Windows XP Group Policy, Group Policy Objects (GPOs) include the ability to set securityconfigurations, 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 SystemPolicy file (often called ntconfig.pol) is stored in the Netlogon share on domain controllerswithin 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 asingle policy file to be processed at a given time. NT 4.0 System Policy could apply to a specificcomputer (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 storedwithin Active Directory (AD), and the Group Policy Template (GPT), which is stored within thereplicated 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 bothmachine 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 avirtually unlimited number of GPOs within an AD domain (though practically speaking, largenumbers 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 ADusers and computers. However, AD security groups composed of either machines or users canfilter GPOs’ effects. This filtering capability, in conjunction with the ability to have multipleGPOs processed by a given user or computer, can provide much greater policy flexibility than isavailable in NT 4.0. Figure 1.2 shows an example of how you can use security groups to filterthe 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), oran AD organizational unit (OU). When a GPO is linked to a domain, site, or OU, all users andcomputers 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 ADinfrastructure.

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 GPOslinked directly to that OU as well as upstream GPOs linked to the domain and any AD sites towhich the computers belong. In fact, GPO processing follows an order of precedence that helpscontrol 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 oftenreferred 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 associatedwith 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 tocreate 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. Thefollowing steps walk you through how to create a new GPO:

1. From the Win2K or Windows XP Administrative Tools program group, choose theActive Directory Users and Computers snap-in to create domain or OU-linked GPOs, orselect 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 thenew 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 Policytab.

4. Click New. In the Group Policy Object Links dialog box, a new GPO is created andhighlighted 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 theGPO highlighted, click Edit to start an MMC Group Policy snap-in tool focused on your newGPO. You can then begin making changes to the GPO.

Q 1.2: What is registry tattooing, and how do Windows 2000 andWindows XP Group Policy Objects prevent it from happening?

A: Registry tattooing occurs when a Windows NT 4.0 System Policy makes a registry changethat is left in place even if the policy no longer applies. Tattooing is a big problem in NT 4.0System Policy. Its effects cause a variety of problems. For example, suppose you’ve set anumber 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 Policyapplies are permanent, unless explicitly un-done by a policy that reverses their effect. The effectsfrom 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 arenot removed when the System Policy no longer applies.

Although NT 4.0 doesn’t include an easy mechanisms to undo the tattooing process, Windows2000 (Win2K) and Windows XP both allow for registry settings to be removed when a GroupPolicy Object (GPO) no longer applies to a user or computer. However, this statement is notuniversally 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 valueswithin 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 fourkeys, such a setting is considered a preference—preferences do tattoo the registry. Microsoftrecommends that all applications that use Group Policy-based Administrative Template policywrite 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 theview 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. Themechanism to filter the view is different between Win2K and Windows XP, but the effect is thesame. 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 resultingcontext menu, select View, then choose Filtering from the sub-menu. The dialog box that Figure1.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 tattoothe 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 differentcolors to the icons representing each. In Figure 1.6, I’ve created a custom .adm template file thatsets 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 arenon-tattooing policies.

Win2K’s Group Policy MMC tool works the same as in Windows XP. However, the menu item thatyou use to filter the view of policies and preferences is different. Namely, from the Win2K GroupPolicy MMC tool, highlight an Administrative Templates node, right-click, select View from the contextmenu, 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 athow it works behind the scenes. The specific registry keys and values that are modified withinGPO-based Administrative Template policy is controlled by the .adm template files associatedwith that GPO. Listing 1.1 shows a snippet from an .adm template file in Windows XP.

7



Chapter 1

CATEGORY !!Logon#if version >= 4EXPLAIN !!Logon_Help#endifPOLICY !!NoWelcomeTips

#if version >= 4SUPPORTED !!SUPPORTED_Win2kOnly#endif

KEYNAME"Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"

EXPLAIN !!NoWelcomeTips_HelpVALUENAME "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 keySoftware\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, anAdministrative Template policy can take three states—not configured, enabled, or disabled (seeFigure 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 onwhich that policy is defined. If the policy is enabled, the registry value is created and the datawithin 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 .admfile, from the enabled state. Again, looking at the .adm snippet in Listing 1.1, this policy dictatesthat the NoWelcomeScreen value is created and set to 1 when the policy item is enabled and 0when its not.

When a policy item defined in the .adm template file does not explicitly call out what the values shouldbe for the enabled and disabled states, the default is to take a REG_SZ type value of 1 for enabledand 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 changesto the “magic” keys in the registry that prevent tattooing, that value will change from enabled ordisabled when the GPO is processed by the computer or user to not configured if the GPO nolonger applies to the computer or user. However, if the policy item does not make a change toone 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 thetattooed registry value. So, as you can see, there is a significant reduction in the policymaintenance 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 theform of new keywords that enable new Group Policy features and functions. For example, inWindows 2000 (Win2K), Microsoft added the EXPLAIN tag to allow for the text explanationsthat you find in the Group Policy Microsoft Management Console (MMC) snap-in (see Figure1.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 !!NoSecurityMenuKEYNAME

"Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"

EXPLAIN !!NoSecurityMenu_HelpVALUENAME "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 sectioncalled out by the [strings] tag. Within the [strings] section, each label is defined to equal a textstring that defines what that label means. It’s this text string that is shown in the Group Policyeditor 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 creatingaccompanying EXPLAIN tags that explain your custom policy.

In addition to the EXPLAIN tag, Win2K and Windows XP include some additional logic withinthe .adm file to test the version of policy editor tool that is loading the .adm file. Because the NT4.0 policy editor won’t understand newer tags supported in Win2K and Windows XP, .adm filescreated for these newer Windows versions use special logic to test for the version of the policyeditor tool. At the beginning of most Win2K and Windows XP .adm files, you will see a set ofstatements, an example of which Listing 1.3 shows.

10



Chapter 1

#if version <= 2

CLASS USER

CATEGORY !!GPOnly

POLICY !!GPOnlyPolicyKEYNAME "Software\Policies"

PART !!GPOnly_Tip1 TEXTEND PART





END POLICY

END CATEGORY

CLASS MACHINE

CATEGORY !!GPOnly

POLICY !!GPOnlyPolicyKEYNAME "Software\Policies"





PART !!GPOnly_Tip5 TEXT

END PARTEND 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 seewhether the version of policy editor tool is equal to or less than version 2. Version 2 correspondsto the NT 4.0 policy editor tool (poledit.exe) or earlier policy tools. If the NT 4.0 policy editortool attempts to load and use an .adm file created for Win2K or Windows XP, the only policyentry 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 thescreen you see in Figure 1.9. That is, the various labels such as GPOnly_Tip1 thru Tip5 containthe text shown in the Settings for System.adm section of the dialog shown in this figure. Listing1.3 is saying that if the version is 2 or less (that is, the NT 4.0 system policy editor tool), showthe text specified by the various tips, which basically explains that you need a newer version ofthe 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 Win2KMMC-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 3and 4 as well.

Windows XP also includes a new twist. Windows XP lets you view and filter AdministrativeTemplate policy items based on which platform is required by a given policy. For example, ifyou 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 inWindows XP use a new tag called SUPPORTED. The SUPPORTED tag is used to indicate theminimum required OS version with which the policy item works. Listing 1.4 shows an exampleof 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_HelpKEYNAME "Software\Policies\Microsoft\Windows NT\Reliability"

PART !!ShutdownReason_Box DROPDOWNLIST REQUIREDVALUENAME "ShutdownReasonUI"

ITEMLISTNAME !!ShutdownReason_Never VALUE NUMERIC 0

DEFAULTNAME !!ShutdownReason_Always VALUE NUMERIC 1END 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 fileand setting policies. In fact, a Win2K Group Policy editor will simply ignore the SUPPORTEDtag because the tag is always surrounded by the statement #If version >= 4, which indicates tothe Group Policy tool reading the file that the section within the #if and #endif clauses be readonly 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 maindialog box of each policy item, the SUPPORTED tag is read to indicate which version of the OSthe 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 theirOS requirement. From the Group Policy MMC snap-in tool, if you highlight the AdministrativeTemplates node (either per computer or per user), and select View, Filtering, you will see thedialog 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 itemsthat 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 aWindows NT 4.0 system policy, how does that map to Windows GroupPolicy?

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 achievesimilar results using a combination of GPO-based features. In Windows NT 4.0, you could createa 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 policyapplying to all users and specific policy applying to a specific user or user group in my NT 4.0domain. In Figure 1.12, you see an NT 4.0 system policy file that provides policy settings for theFinance 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 thatthe 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 policysettings to a particular user, machine, or group, you need to use GPO-based security groupfiltering to achieve the desired results. What that means is that a single ntconfig.pol file in NT4.0 that contains three user–group–specific policies will require three separate GPOs in Win2Kto 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 yoursystem 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 desktoprestrictions for the Finance Admins group than I do for the Finance Users Group. Now, that’s allfine until it comes time to start implementing equivalent desktop lockdown in Win2K orWindows XP Group Policy. By using a tool such as gpolmig.exe from the Win2K Serverresource 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 Serverresource kit. The version that ships in the original Win2K Server resource kit doesn’t work! (Thanks toDerek 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 thatFigure 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 FinanceAdmins and Finance Users groups and migrate them to Group Policy. To do so, I need to createtwo 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 groupfiltering. 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 AdminsLockdown.”

4. Repeat Step 3, creating a GPO called “Finance Users Lockdown.” Figure 1.13 shows thetwo 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 howthey’re applied. From the GPO dialog box that Figure 1.13 shows, highlight the “FinanceAdmins Lockdown” GPO, and click Properties.

6. From the Properties dialog box, choose the Security tab. Because we want this GPO toonly apply to the Finance Admins group, you need to prevent other users from processingit. 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 thedomain list.

8. With the Finance Admins group highlighted, select the Apply Group Policy permission toensure that only this group processes the GPO (see Figure 1.14).The Read permissionshould 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 FinanceUsers 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 toconfirm 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 yoursystem 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 outputsimilar 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 theeasiest is to use the gpolmig tool to do the work for you. The first thing to do is open up one ofyour target GPOs using the Group Policy MMC snap-in. Then, from the command-line, issue thefollowing gpolmig command:

Gpolmig c:\policy\ntconfig.pol /listgpo

The output is similar to that which List 1.5 shows.

Using Downlevel policy file: ntconfig.polProcessing GPOs currently being edited...

Current Group Policy Objects Open(open the Properties of GPOs and locate the'Unique Name' to identify the Globally UniqueIdentifier, 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 yourdesktop. 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.0system policy, our target is the user-specific settings within a GPO. To actually perform theconversion, we’re going to take the output from the last two gpolmig commands and use theinformation to generate the command that will do the actual conversion. In the case of myexample, I’m going to migrate the settings in the Finance Admins system policy into my newFinance 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 thiscommand 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 inWin2K GPO .adm files and thus won’t be migrated. If you have created custom .adm files for your NT4.0 system policies, you need to be sure to load those into your new GPO prior to attempting amigration.

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 atthe 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 bothWindows 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 whendepends upon where user and machine accounts reside.

An NT 4.0 System Policy file (for example, ntconfig.pol) is only applied when the correspondinguser or machine accounts still reside within an NT 4.0 domain. For example, many enterprises, inthe 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 toHKEY_LOCAL_MACHINE) that you’ve created in your NT 4.0 domains are applied to theWin2K or Windows XP machine when the AD user logs onto the AD domain from thatworkstation. However, no user-specific NT 4.0 System Policy settings are processed if the useraccount 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 accountresides in the NT 4.0 domain called Sales. There is a user named Bob, who has an accountdefined in the AD domain called myorg.tld. Bob logs onto the Win2K client workstation inSales. Which policies will Bob receive? Because the machine account of the workstation onwhich 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.tldAD 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 SystemPolicy is processed. This requirement contrasts machine-specific GPO policy, which only requires amachine restart to trigger processing. In addition, the ntconfig.pol file must reside on the domaincontrollers 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 “DefaultComputer” or machine-specific policy has been defined in the NT 4.0 System Policy, that policywill be processed. No user-specific System Policy will be read, even if it is defined, because theuser 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 machinethat 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 Policyto 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 theauthentication domain (the myorg.tld domain in the previous example). On NT 4.0 domaincontrollers, this location is typically in %systemroot%\system32\repl\import\scripts. On ADdomain controllers, Netlogon is shared only for backward compatibility as part of the replicatedSYSVOL 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 bereplicated to other AD domain controllers in the domain. Finally, if you decide that you don’twant NT 4.0 System Policies to be processed for certain machines or users, you can alwaysdisable System Policy processing by changing the value of theHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update\UpdateMode registrysubkey from 1 to 0.

Q 1.6: Do Group Policy Objects contain all the same policy settingsthat 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 inWindows 2000 (Win2K)- and Windows XP Group Policy Object (GPO)-based policy, for goodreason. Some of the changes in the Win2K and Windows XP shell environment facilitated theneed to drop support for certain NT 4.0 settings. In other cases, settings that were implementedas .adm files in NT 4.0 might have been folded into other mechanisms in Group Policy. Forexample, in NT 4.0 there was a user-specific policy within the winnt.adm template file that letyou redirect certain folders within a user’s profile to a different location (for example, a servershare). 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 theFolder Redirection policy. You won’t find the Custom Folders policy item anywhere in GroupPolicy. Instead, Folder Redirection lets you redirect certain user profile-based folders, such asDesktop, to alternative locations (usually server shares) for all users subject to that GPO or basedon 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 itdownright 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 theirequivalents 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 username

Computer Configuration, Windows Settings, SecuritySettings, Local Policies, Security Options, Do notdisplay last user name in logon screen (Windows XP:Interactive Logon: Do not display last user name)

Default Computer, Windows NT User Profiles,Delete cached copies of roaming profiles

Computer Configuration, Administrative Templates,System, Logon, Delete cached copies of roamingprofiles (Windows XP: Computer Configuration,

Administrative Templates, System, User Profiles,Delete cached copies of roaming profiles)

Default User, Control Panel, Display, RestrictDisplay, Hide Screen Saver Tab

User Configuration, Administrative Templates, ControlPanel, Display, Hide Screen Saver Tab

Default User, Shell, Restrictions, Remove Runcommand from Start Menu

User Configuration, Administrative Templates, StartMenu & Taskbar, Remove Run menu from Start Menu

Default User, Shell, Restrictions, Hide Drives inMy Computer

User Configuration, Administrative Templates,Windows Components, Windows Explorer, Hide thesespecified drives in My Computer

Default User, System, Restrictions, DisableRegistry editing tools

User Configuration, Administrative Templates, System,Disable registry editing tools (Windows XP: Preventaccess to registry editing tools)

Default User, Windows NT User Profiles, Limitprofile size

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.0System Policy setting that you want to implement in Win2K or Windows XP Group Policy. Thegood news is that there seem to be very few NT 4.0 policy settings that simply aren’t supportedin 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 PolicyTemplate (GPT) folder structure under SYSVOL (see Figure 1.19).

22

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



Chapter 1

Unfortunately, Microsoft changed the format of the registry.pol file from that which wassupported in NT 4.0 .pol files. NT 4.0 pol files were actually registry hive files that could beloaded 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’tload 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 bythe wayside for managing most GPO-based policy. Of course, you can still use the open registryoption in the File menu of poledix.exe to view the current registry settings of a local Win2K orWindows 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 currentlyloaded .adm files. Thus, you will have to either load Win2K- or Windows XP-based .adm filesthat 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 betteroff sticking with the Microsoft Management Console (MMC)-based GPO tools to view andmodify GPOs.

Q 1.8: Can I store my Windows NT 4.0 policies in the same place thatGroup 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 filesare stored in the replicated SYSVOL share on domain controllers within a domain. The Netlogonshare is still supported on Win2K domain controllers, but it’s in a different part of SYSVOLfrom where your Group Policy Objects (GPOs) are stored.

23



Chapter 1

SYSVOL and NTFRS replication completely replaces the old NT 4.0 directory replicationservice that supported replication of the Netlogon share. If you view the default shares that arecreated on a Win2K domain controller, you’ll see that both SYSVOL and Netlogon exist on theserver but that they are located in different paths within the NTFRS replication tree (see Figure1.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 filesthat 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 placein the file system.

If you have NT 4.0 machines in your Win2K Active Directory (AD) domains (or Win2Kmachines in NT 4.0 domains that are authenticating to AD domains), you might need to maintainsome NT 4.0 System Policy processing capability. In that case, you would have to copy yourntconfig.pol files into the Netlogon-shared “scripts” folder on your Win2K domain controllers.

NTFRS automatically replicates all content under %systemroot%\SYSVOL\domain to alldomain controllers within a domain. Given that, you only need to copy your ntconfig.pol file tothe 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 registrykey at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update that lets youoverride the default behavior of looking in the Netlogon share at logon time for the SystemPolicy 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 (forexample, \\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 replicatescontent 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 andWin2K machines that you expect to process System Policy against your AD domain.

25

http://myserver/sysvol/mar-elia.com/policies/ntconfig.pol

http://myserver/sysvol/mar-elia.com/policies/ntconfig.pol



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 aredefined 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 aset of Active Directory (AD) objects and their attributes that define the basic GPO. The GPT is aset 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 PolicyMicrosoft Management Console (MMC) snap-in. When a Windows 2000 (Win2K) or WindowsXP workstation boots or a user logs onto a machine, a process running on the workstation orserver 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 goinginto the registry and viewing the subkeys listed underHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions. Each subkey listed describes a CSE. The values undereach subkey describe which policy processing functionality that DLL provides—for example, folderredirection, disk quota, registry settings (administrative templates)—as well as settings related to howthat CSE behaves when processing a GPO.

CSEs are the code responsible for reading the GPC and GPT for each GPO that the computer oruser must process and for applying the policy settings to that computer or user. This processingcan happen in the background while other tasks are going on (asynchronous), or in theforeground, 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 knowwhether your computer or user is actually processing the GPO. There are several approaches youcan 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 Win2Kversion 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 offersthis remote capability. And, while the Win2K version of GPResult can report on which registryvalues 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 versiondoes 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 theresults 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 givenworkstation or server. However, for more robust reporting, use one of the Resultant Set of Policy(RSoP)-based approaches described later.

Event Logs

27

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 theApplication 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 registryvalues to enable more verbose GPO logging. To get more verbose logging, add the followingregistry subkey (if it doesn’t already exist) to any Win2K or Windows XP machine on which youwant logging to occur: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics. Under the Diagnostics subkey, add a REG_DWORD valuecalled RunDiagnosticLoggingGlobal, and give it a value of 0x1. You will need to reboot for thelogging to take effect, but once it does, you will see a series of Application event log events eachtime GPO processing occurs. This logging is handy for telling you which GPOs are being



Chapter 2

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

RSoP

RSoP provides the ability to view, for a given user logging onto a given computer, the GPOs thathave been applied. There are a couple of tools on the market that provide RSoP capability forWin2K and Windows XP, including FullArmor’s FAZAM. This product not only allows you toview effective policy for a given user and computer, but also lets you perform what-if analysisfor users and computers that you plan to move around your AD (for example, changeorganization units—OUs), view and edit a domain’s GPOs at-a-glance, and perform diagnosticsand 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 theFAZAM 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 stepsto bring up the Windows XP RSoP tool:

1. From the Start menu, select Run, and in the resulting text box, launch mmc.exe to bringup 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 toanalyze. Once completed, current GPO settings will be displayed in the MMC in afamiliar GPO editor-style tree with results showing which policy has been applied to yourcomputer 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 mostcases, the best way to restrict which computers or users will process a GPO is to link that GPO atan appropriate level within Active Directory (AD). If you don’t want a GPO to be processed byall users in an AD domain, don’t link it to the domain level but rather to the site or organizationalunit (OU) level.

However, there may be cases in which you need to apply a GPO to most of the users in yourdomain, but you want to exclude a small group of users. Similarly, you may have a GPO linkedto an OU, but you want to let only a small group of users within that OU process the GPO. Ineither 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 computersaccess 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 theresource is a file folder on a server or a GPO defined in AD. Figure 2.3 shows an example ofwhat 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 MicrosoftManagement Console (MMC) snap-in tool, focused on a GPO within your AD domain, or youcan view the properties on a GPO from either the Active Directory Users and Computers snap-inor 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 Policytab, 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 canedit the GPO. The second role is to control who will process the GPO. For now, we’re interestedin the latter role. There are two permissions that control whether a particular user or computerwill process a GPO—the Read permission and the Apply Group Policy permission. Thecombination of these two permissions allows a user or computer the ability to process a GPO. Infact, 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 understanda few key points. First, by default, all GPOs will have the Authenticated Users group with Readand 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 Usersgroup as well as users because each computer account in an AD domain has a user accountcreated 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 GPOto 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 andclick Remove to remove the ACE. Next, you need to add the new ACE for the computer or usergroup 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 computersinstead of groups. However, doing so is not recommended because it adds complexity and, as the listof permissions on a GPO grows, slows down the processing of this GPO as the computer or user siftsthrough all the ACEs.

Once you’ve added the group, select the Read and Apply Group Policy permissions under theAllow 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 DesktopLockdown Policy that has been linked to the Finance GPO. Notice that the Authenticated Usersgroup is nowhere to be found on this GPO. Thus, only the Finance Users group (and any othergroup 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 orcomputers 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.5shows an example of this.

31

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



Chapter 2

In Figure 2.5, I’ve added an ACE for the Finance Servers group to the Default Domain PolicyGPO. 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, theAuthenticated Users ACE is still in place on this GPO, guaranteeing that all users and computerssubject 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, Ieffectively prevent this computer group from processing the GPO.

In this example scenario, I could have simply added a Deny ACE for the Read permission becausedenying 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 toprocess a GPO.

You can use these methods of adding Allow and Deny ACEs to selectively filter the effects of aGPO for particular groups of users and computers. However, because long ACLs on a GPO addto the time required to process that GPO, I recommend being judicious about how you usesecurity 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 ifusers or computers belong to groups that have both been granted and denied access (the DenyACE 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 themopposing 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 adomain, I can use No Override to guarantee that that GPO is always processed by users andcomputers in that domain. However, if I’m an administrator of an organizational unit (OU), Imight want to block upstream GPOs that have been linked to the domain or site of which myusers 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 Overridealways “trumps” Block Inheritance. That is, if an administrator sets a No Override flag on a GPOhigher up in the AD hierarchy (for example, at the site or domain level, or even at a higher-levelOU in the case of nested OUs), no Block Inheritance will prevent downstream users andcomputers 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 thatevery user and computer that should receive the GPO is in fact receiving it. Using No Overrideachieves this goal.

No Override always “overrides” Block Inheritance. That is, no amount of inheritance blocking willprotect 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 (forexample, 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 GPOto be inherited using No Override.

A good example of when No Override comes in handy is for enforcing security policy. Forexample, 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, alldownstream users and computers will always process that GPO. The following steps walk youthrough 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 GPOthat 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 Figure2.6, there is a Block Policy inheritance check box at the bottom of the dialog box. By selectingthis 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). BlockInheritance 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 OU5will only process OU GPO2 and Domain GPO2 because Domain GPO2 has had the No Overrideflag 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, youcan 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 ofsites in your AD infrastructure. A site is a collection of IP subnets that are typically connected byhigh-speed interconnects. For example, a set of subnets on a high-speed campus backbone wouldtypically belong to the same AD site. Sites (and subnets) are managed using the AD Sites andServices 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 allowyou to group workstations and servers together for the purpose of guaranteeing that services suchas distributed file system (Dfs) and authentication are handled locally. But sites can also be thetarget 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 totheir 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 yourexecutive’s computers are all located within a single site and you want to ensure that their trafficis encrypted.) Another use might be to deliver a particular set of policy lockdown if you haveusers dialing in and accessing your network via a Virtual Private Network (VPN). Those clientswill typically get a range of IP addresses on one or more subnets that you can collect into a siteand attach to a GPO.

The thing to remember about site-linked GPOs, unlike domain or OU-linked ones, is that theeffect of site-linked GPOs crosses domain boundaries. That is, any computer that belongs to asite (and the user who logs onto that computer), regardless of which domain it’s in, will processthe 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 domainand thus are only replicated to domain controllers within that domain, site information is storedin the configuration naming context (see Figure 2.9), which is replicated to all domain controllersin 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 aredomain and OU-linked. Thus, if any GPOs processed after your site-linked ones contradict anysite-specific policy settings, those site-specific settings will be cancelled out by the time thecomputer or user processes all their GPOs. Site-linked GPOs in this case are “low man on thetotem pole” and so you need to make sure you design them with that fact in mind. You can usethe No Override feature in Group Policy (see Figure 2.10) to ensure that a particular site-linkedGPO 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 aresite-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 storedwithin the configuration naming context and thus replicated to every domain controller in aforest. However, the Group Policy Template (GPT) portion of a GPO is still stored withinSYSVOL on domain controllers within a single domain. If you create a site-linked GPO usingthe AD Sites and Services tool, by default, the GPT for that GPO is created in the forest rootdomain—the first domain in a forest. However, if you create a domain or OU-linked GPO inanother domain other than the forest root, then link that GPO to a site at a later time, the GPTexists in whatever domain it was first created in. The reason that this fact is important is that youneed to have a good sense of where all your site-linked GPOs actually reside as compared withyour users. You don’t want users or computers having to cross slow WAN links just to find theGPOs that they need to process, so you might find that you need to keep some domaincontrollers from the domain where your site-linked GPOs are stored at locations close to yourusers to ensure good performance.

37



Chapter 2

Q 2.5: Why are changes to Group Policy Objects always written firstto 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, Microsoftsought to provide a way to minimize collisions. By default, when you open the MicrosoftManagement Console (MMC) Group Policy snap-in focused on an Active Directory (AD)-basedGPO, the copy of the GPO you are actually editing resides on the PDC emulator domaincontroller in your AD domain. The reason is that the GPO editor tool will always try to edit thecopy of a GPO on the PDC emulator for that domain to limit collisions between two peopleediting the same GPO. For example, if a systems administrator in New York and a systemsadministrator in San Francisco both try to edit the Default Domain Policy at the same time, theywill 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 toedit 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’toverwrite each other’s changes, which is especially important if the changes being edited aresecurity policies. You can actually see which domain controller you are currently focused onwhile editing a GPO from the MMC Group Policy snap-in tool. The current domain controllerwill 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 aGPO while focused on a different AD domain controller. In such a case, you change whichdomain controller the Group Policy MMC tool focuses on when you edit GPOs by choosingView, Domain Controller Options from the MMC menu. Figure 2.13 shows the list of youroptions.

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 yourActive 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 controllerto you, which is normally a domain controller within the same AD site as your administrativeworkstation. 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 fromwhich you’re connecting.

39



Chapter 2

When you choose any of these three options, you need to stop and restart your Group Policy tool forthe 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 anothermachine unless you have a Group Policy Administrative Template policy in place to enforce thechoice 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 goodreason for focusing a GPO editor on a different domain controller is if the PDC emulator domaincontroller 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 PDCemulator role by using the netdom.exe utility that comes with the Windows 2000 (Win2K) SupportTools. 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 operationsmasters 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 canview 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, youcan’t grant an administrator read access to a GPO—the administrator won’t be able to access thatGPO. For example, if I want a member of the Finance Admins group to be able to view but notchange 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 amember of the Finance Admins group tries to load the GPO into a Microsoft ManagementConsole (MMC) snap-in tool. At minimum, a user needs the Read and Write permissions to beable 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 givethem indirect access by creating reports that show the current settings for GPOs. There are quickand dirty ways that you can do so by using tools such as GPResult.exe, which only shows thecurrent settings in text form that apply to a particular user or computer. Or you can let your usersuse 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 aWindows XP-based RSoP report.) Users that have only read permissions on a GPO can run theRSoP 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 givenset of GPOs, you have another option, albeit not out-of-the-box. Using a tool such asFullArmor’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 andhave the reports automatically moved to a Web site that administrators and other users canaccess 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. FAZAMinstalls 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 andoutputs 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",13. 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 automationobject called FAZAM2000.PolicyManager. In line 2, I call a method called ReportPolicy, whichdoes all the work in this script. ReportPolicy is passed three arguments, including the fullLightweight 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 ofreport to generate—a numeric 1 indicates an HTML report, 2 indicates output to an MS-Accessdatabase, and 3 indicates output to the printer. The output of this example script is an HTMLreport—part of which is shown in Figure 2.16. Line 3 simply releases the reference to therptGPO 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 yourGPOs 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 createnew types of Group Policy Objects?

A: Yes, Microsoft designed Group Policy to be extensible, which means that a developer canadd 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 GroupPolicy Container—GPC) and SYSVOL (the Group Policy Template—GPT). There is nothingspecial to these settings; they are just AD objects with attributes or files and folders in the filesystem. 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 areinstalled on the Windows 2000 (Win2K) or Windows XP workstation or server. These DLLs dothe actual heavy lifting of policy enforcement. It is the CSE that cares about what is stored in theGPT 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 itis 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 thesettings 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 filefrom SYSVOL, then, based on the contents of that file, decide on certain behavior for yourapplication (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 GPOextension 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 letsadministrators 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-inextension that lets administrators actually set the policy for a given GPO. MMC snap-ins andextensions are registered on a given Win2K or Windows XP machine under the registry keyHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns.

Each snap-in is registered with its unique GUID under that key. As Figure 2.17 shows, the folderredirection editing snap-in is registered under that key and is implemented within the DLL calledfde.dll.

44

http://www.microsoft.com/

http://www.microsoft.com/



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 companioneditor tool that lets administrators create and edit the settings for your policy.

Q 2.8: What is happening during background refresh of a GroupPolicy 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 XPworkstations and Win2K servers. This cycle provides ongoing policy enforcement in the eventthat a GPO’s policy settings change between normal processing cycles (machine restart or userlogon) 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 computeror logs onto Active Directory (AD). In the background, when each refresh interval arrives (plus arandomized interval to ensure that all machines don’t process their GPOs at the same time), theclient-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 theGPO history information (described in Question 7.7) held in the registry with the currentversions of the GPOs to be processed. If the GPO has not changed since the last processing cycleand 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 WindowsXP CSEs are stored in Computer Configuration, Administrative Templates, System, GroupPolicy.

Remember that policy processing is performed by the CSE. That is, one CSE will process all ofthe 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, andservers from the default setting. Keep in mind that the refresh interval on domain controllers isset to 5 minutes to ensure that there is minimal latency in the updating of important policy suchas 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 thecomputer-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 refreshinterval. As I mentioned, the random time guarantees that not all machines within a particulardomain end up requesting policy at the same time. If you enter a value in minutes, the actualrandom 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 Imentioned, normal GPO processing behavior is for CSEs to not process a GPO if it has notchanged since the last refresh period. In most cases, you can override this behavior to force aCSE to process regardless of whether the GPO has changed. However, it’s important toremember that not all CSEs support background refresh of policy. Table 2.1 shows which of themost 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 usingAdministrative 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 Figure2.19, show the option to enable or disable background processing, the CSE itself does notsupport 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, ororganizational unit—OU). Thus, when you create the GPO, it is automatically linked to thatcontainer object at creation time. This link might not be desirable, so I’ll show you a way tocreate 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 Computerssnap-in or Sites and Services snap-in, and highlight the container object on which youwant to create the new GPO.

2. Right-click that container object, select Properties, and in the resulting window, select theGroup Policy tab.

3. Click New, and name your new GPO.

Once you click New, the Group Policy Container (GPC) and Group Policy Template (GPT) thatmake up the GPO are created. In addition, an attribute on that container object called gpLink ismodified 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” assoon 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 bycomputers 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 isuseful to be able to create a new GPO, edit it the way you want, then link it to one or morecontainer objects when you’re ready. There are a number of similar approaches you can use tocreate 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 inyour AD domain.

49



Chapter 3

5. Select the All tab to view all current GPOs. Then, with your mouse in a white spacewithin the All GPO dialog box, right-click, and select New from the properties menu, asFigure 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 notlinked to any particular container object.

To edit this new, unlinked GPO, you will need to load the Group Policy MMC snap-in as you didin the previous steps, navigate to the All tab, right-click the unlinked GPO, and select Edit fromthe context menu. Let’s now assume that you’ve edited the new, unlinked GPO, and you want tolink 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 (oranother 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 Linkdialog 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.2illustrates.

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 dowith System Policy. Rather, you used the User Manager for Domains tool to create and editaccount policies, such as required password length and account lockout counts.

However, in Active Directory (AD) domains, you must use Group Policy to set account policyon 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 organizationalunit (OU) levels (though you can set account policy for local workstations and servers at the OUor site level). By default, when you install AD, it installs a GPO called the Default DomainPolicy, 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 aspecial GPO. This GPO is special because it can’t be deleted—even if you accidentally try todelete this GPO, your command is ignored and the GPO remains. Thus, you know that theaccount policy defined in this GPO is always available and enforced. Of course, you can alsocreate 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 domaincontrollers as well as member servers and workstations. Thus, if you set a minimum passwordlength policy on a domain-linked GPO that is processed by both AD domain controllers andmember servers or workstations, you will be required to use that minimum password lengthregardless of whether you are logging onto the domain (handled by the domain controller) orlogging 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 domainauthentication) and one for local workstation or server accounts, you would need to define twoseparate, 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 ofdefining minimum password length and password age on an AD domain.

1. The first step is to open the Active Directory Users and Computers MicrosoftManagement 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 theProperties context menu.

3. Select the Group Policy tab, and you see a dialog box showing all the GPOs currentlylinked at the domain level of your domain. At the very least, you should see the DefaultDomain 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 theGroup 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 thatFigure 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 ofcharacters required for a password.

53

8. To set the password age, we need to double-click the Maximum Password Age policyitem, and set it to the number of days after which the password is considered expired.



Chapter 3

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

Q 3.3: How do I use the restricted groups feature in Group PolicyObject 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 membershipon machines managed by GPO such that, if a user tries to put his or herself into a group in whichthe user doesn’t belong, at the next policy processing cycle, the restricted Group Policy willautomatically remove the user. This feature can be handy, but there are some limitations withinthe restricted group feature. Before we discuss these limitations, let’s look at how you can setrestricted Group Policy.

As I mentioned, restricted Group Policy is part of computer-specific security policy. You canfind 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 administrativegroup. 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 viaRestricted Groups—the target group. With restricted Group Policy, you can do two things withthe 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 Iselect 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 chooseSecurity. 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 groupsthat 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 theFinance Admins group can be a member of MyAdmins. This policy means that when the domaincontrollers process this GPO, if there are any users or groups that are currently a member ofMyAdmins, they will be removed, and the Finance Admins group will be put in their place! Asyou 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 domaincontrollers in your domain that says that the domain local Administrators group will only containthe 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 domainadministrator account, domain admins, and enterprise admins—will be removed and replaced byFinance 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 toalways be a member of the MyAdmins group, but I don’t want to affect the current members ofMyAdmins. 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 othergroups or users in MyAdmins will remain intact. Figure 3.7 shows what this policy would looklike.

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 groupsas 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 domaincontrollers (the easiest thing to do here is to link the GPO to the Domain Controllers OU). If youwant to control workstation or member server local group membership, you’ll need to do so on aGPO 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, adomain controller processes a policy for a local group defined on a member server elsewhere inthe domain), that policy is simply ignored.

Another thing to keep in mind with restricted Group Policy is that it is processed just like otherGPO-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 backgroundevery 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 makesthe 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 inthe 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 thedomain local Administrators group. However, by default, such is not the case because, bydefault, 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 cycleregardless of whether the GPO has changed. You can set an Administrative Template policy toforce this processing behavior. That Administrative Template policy is found in ComputerConfiguration, Administrative Templates, System, Group Policy , Security policy processing

under both Windows XP and Windows 2000 (Win2K). Figure 3.8 shows how you set this policyto 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 changesto restricted Group Policy will be automatically undone each time the GPO is reprocessedregardless of whether it changes. This Administrative Template policy is probably a good one touse 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 mydesktops?

A: Just as in Windows NT 4.0 system policy, you can easily use Administrative Template policywithin 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 torestrict which knobs and dials within Windows a user can futz with. The thought was that thefewer buttons the user could press, so to speak, the less chance there was that the user would dosomething 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 theWindows 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 withinthe My Computer dialog box. The industrious user can still access those drives using any numberof methods outside of My Computer. On the contrary, if you used NTFS security to lockdownwhich files and directories to which a user has access, you are providing real security rather thansimply hiding access to the drive via the most common mechanism. Such is true for most all ofthe 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 onthem to keep your users (and especially your power users) from sensitive material. Now that weknow desktop lockdown’s limitations, let’s look at how you can use the feature to restrict yourusers’ 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 theirdesktops that they would normally be able to do qualify as desktop lockdown. AdministrativeTemplate settings are broken down into policies and preferences (see the description of the twoin Question 1.2). Desktop lockdown policy may be either policies or preferences, but aregenerally 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 lockdownsettings 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 andswitches” you can throw can be daunting. As you can see in Figure 3.9, there are a myriad ofaspects of the user shell that you can control. Remember that Administrative Template policysettings 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 itemcalled Remove DFS tab lets you remove the Dfs option from wherever they appear in theWindows Explorer. To enable this policy, you simply select the policy item and select theEnabled check box. If you disable this policy, it means that the Dfs tab can’t be removed fromthe 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 whenthe user doesn’t have sufficient rights to install software on his or her computer. Clear?! Sodisabling 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 confusingvery quickly.

Darren’s Desktop Lockdown Rules

59

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 desktoplockdown in the NT 4.0 and Win2K environments, I’ve created a few rules to help guide youruse of desktop lockdown. These are good rules to follow if you’re just starting out with GroupPolicy–based lockdown or if you are trying to unravel lockdown gone awry.



Chapter 3

1. Stick to the minimum amount of desktop lockdown you need to keep your users fromfutzing. Less is more in this case. You don’t want to spend as much time troubleshootingand answering user calls as to why they can’t do something that’s been locked down asyou would deal with the results of their futzing. If you think you need to lock somethingdown, think again.

2. As a corollary to Rule 1, the best defense against user futzing is to use real security (thatis, file system and registry security) to protect desktop resources. No amount of desktoplockdown policy is going to help you if you make all yours users Administrators on theirdesktops.

3. Avoid having desktop lockdown policy in multiple GPOs that contradict each other asthey are applied to users. For example, if you have a GPO linked to the domain thatremoves the Run option from the Start menu and another GPO linked to an OU that putsit 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 takethis path, make sure you have a very good Resultant Set of Policy (RSoP) tool (forexample, FullArmor’s FAZAM or the RSoP tools built into Windows XP) at yourdisposal.

4. As a corollary to Rule 3, if you have contradicting policies linked to different levels ofyour infrastructure, try to avoid further complicating things by then using security groupsto filter the effects of those GPOs.

5. In the end, what you will likely find is that you’ve overly restricted what your users cando. 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 foryour environment, and no more. Then put it in front of your users and get theiracceptance on what you’ve done. User acceptance testing of your desktops cannot beunderrated!

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

As you know, every Windows 2000 (Win2K) and Windows XP system has a local GPO thatcontains 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. Notwithstandingthese missing pieces, local Group Policy has many of the important features you might want orneed on non–AD–based machines (for example, security and administrative templates). Theremight also be compelling reasons why you don’t want to put a particular Win2K or Windows XPmachine in an AD domain. For example, many enterprises often opt not to create a domain whenthey place Win2K servers on DMZ segments exposed to the Internet. In such cases, you canchoose not to deploy AD, but you might still want to leverage Group Policy to configure a groupof 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 deployedconsistently across many non–AD–based machines.

First, you need to know where the policy files for the local GPO are stored. On both Win2K andWindows XP systems, the local GPO can be found in %systemroot%\system32\GroupPolicy. Asyou 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 theoption 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 thecurrent 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 localGPO for the computer and user configuration portions of the GPO. If you drill into both theMachine and User folders, you will find the registry.pol file that contains the currentAdministrative Template settings as well as other folders for startup and shutdown or logon andlogoff scripts and Internet Explorer (IE) maintenance and remote installation options. What youwon’t find is a file corresponding to per-machine security settings such as account policy, localuser 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 againstthe live Security Account Manager (SAM) database that resides on the machine. Therefore, aswe discuss how to copy local GPO settings from one machine to another, you won’t be able tocopy 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 suchas 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 agroup of non-AD machines. The process is fairly straightforward. First, you need to ensure thatyou have the Administrative Template settings that you desire on your “prototype” machine. Theeasiest 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 allmachines. 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 thedestination machines. If you edited computer-specific policy only, you will need to copy only theregistry.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 filefrom the folders on your source machine to the identical folders on all target machines. Anyexisting Administrative Template policy set locally on the target machines will be overwrittenwhen you copy the new files.

If you created any custom .adm template files on your source machine, you’ll need to copy themto the target computer(s) in addition to copying the registry.pol files. This step is important toremember because after you’ve copied the policy files to the target machines, if anyone were toedit those local GPOs, they would not see all the correct policy settings if the adm files that wereused 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 toensure that the custom .adm file is loaded.

There is one more piece of the puzzle that needs to be completed before your copied policy isfunctional. 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 versionnumber held in this file (shown as Version in Listing 3.1) is 0, local GPO processing will beskipped during machine startup or user logon. Such is typically the case on new Win2K andWindows XP machines.

[General]gPCFunctionalityVersion=2gPCMachineExtensionNames=[{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=196639gPCUserExtensionNames=[{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 filesto target machines, you also need to edit the gpt.ini file on those machines to ensure that thevalue is not 0. Although GPOs use a fairly elaborate scheme to calculate versions (the versionnumber is incremented 1 for each computer-specific change and 65536 for each user-specificone), you don’t need to worry about whether you provide the correct version number as long as itis a non-0 value. To be safe, set the version value to 65537 (65536+1) so that both user andcomputer 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 twomodes of operation—maintenance and preference. Maintenance mode is meant to providemandatory, non-changeable settings for various browser configuration options. If the userchanges a maintenance-mode policy, that policy will be reset the next time the Group PolicyObject (GPO) containing that policy is processed. Preference mode is less strict. It lets medeliver IE Maintenance policy settings one time to a user; after that initial setting, the policy isno 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 modeis not. Both IE maintenance and preference mode policies are per-user settings and can be foundunder 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 ineach of those GPO. IE Maintenance policy is meant to be used with IE-related AdministrativeTemplate policies. The IE-related Administrative Template policies can be found at Computer

63



Chapter 3

Configuration, Administrative Templates, Windows Components, Internet Explorer and UserConfiguration, Administrative Templates, Windows Components, Internet Explorer. TheAdministrative Template policies are meant to let me lock down which settings a user can fiddlewith in IE; then maintenance-mode IE Maintenance policy controls what the variousconfiguration 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 afterthe initial policy setting.

For example, let’s see how I can use IE Maintenance policy to set a certain proxy configurationon your user’s browser, then use Administrative Template policy to prevent the user fromchanging his or her proxy settings. The first step is to use IE Maintenance to set the proxyinformation. Within your GPO, drill to User Configuration, Windows Settings, Internet ExplorerMaintenance, Connection, Proxy Settings. From here, I can configure manual proxy informationfor 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 UserConfiguration, Administrative Templates, Windows Components, Internet Explorer, and enablethe 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 proxysettings and auto-proxy settings. After you’ve completed configuring these settings, a user whologs onto his or her Win2K workstation and processes this GPO will have browser proxy settingsas 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 inFigure 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 wecan enable preference-mode policies. To do so, simply right-click the Internet ExplorerMaintenance 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 Browsersettings context menu item to clear all current IE Maintenance mode settings. Alternatively, youshould 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 IEMaintenance node, called Advanced. The Advanced policies let you control additional IEsettings 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 ableto change them unless you disable the underlying functionality by using AdministrativeTemplate lockdown. Typically, when designing your IE Maintenance policy, you will end upusing some combination of maintenance-mode and preference-mode GPOs along with asprinkling of Administrative Template lockdown to get the perfect IE configuration for yourusers.

Q 3.7: How can I use Group Policy to ensure that certain scripts areexecuted 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 andshutdown events and perform actions based on them. In Windows NT 4.0, I can’t tell you howmany times I wanted a way to perform some action, like killing a process or running anenvironmental 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 WindowsXP, it is easy to do so.

GPO-based script policy can support any number of “executable” types, from DOS-style batchfiles to Perl scripts to Windows Script Host (WSH) scripts, and even compiled executables. Thisfunctionality provides for a lot of power in executing tasks based on these types of user-drivenevents. Creating startup/shutdown or logon/logoff policy is easy. After you start the GroupPolicy 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 decidingwhen you want the script to run. Computer-based scripts run with a different security contextfrom user-based ones. Namely, computer-based scripts run under the security context ofLocalSystem, and user-based scripts run under the context of the logged on user. Thus, startupand 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, becauseshutdown and startup scripts run in the context of LocalSystem, they cannot access otherWindows resources located remotely from where they’re running. It’s important to understandthat 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 theirtasks. However, it’s always a good idea to test your scripts first—I have found cases in whichcertain commands did not work because they made assumptions about the environment that wereno 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 affectthe 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 wereallowed 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 particulartwist in the way GPOs are processed on domain controllers. You will need to implement yourshutdown scripts within the built-in Default Domain Controllers Policy GPO. If you try to implementshutdown 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, beaware 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 foruser response if your default WSH script executable is Wscript.exe rather than Cscript.exe. Ifyou 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 thatthere is a good chance that a user is actually present when the script executes. If no user is presentto confirm a dialog box or answer a question, the script will just sit there until the default 10 minutetimeout passes, at which point the script will be killed and Windows will continue the logoff orshutdown 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 administrativetemplate policy to show verbose script execution. This policy can be found in ComputerConfiguration, Administrative Templates, System, Scripts (run startup scripts visible and runshutdown scripts visible) or User Configuration, Administrative Templates, System, Scripts (runlogon scripts visible or run logoff scripts visible). Figure 3.15 shows how you can enable visiblescript 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 thatthe scripts may generate. Visible processing simply shows the command window that isgenerated by a batch file or other command shell driven script. It can be valuable fortroubleshooting 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 forselecting and finding scripts within Group Policy are less than intuitive. Keep in mind that thescript files—whether they are batch files or WSH scripts—are stored within the Group PolicyTemplate (GPT) in SYSVOL for each GPO that references the script. So if you have a script thatis implemented in 10 GPOs, the script file will be stored 10 times within the GPTs of those 10GPOs. Figure 3.16 shows the dialog box for adding a logoff script to a GPO. All of the types ofscripts 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 aGPO. It’s also perfectly legal to have multiple scripts assigned to a single GPO (and, of course, auser or computer can also process multiple GPOs, leading to many scripts running during alogoff or shutdown sequence). When you have multiple scripts on a given GPO, they process inorder 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 ShowFiles, a Windows Explorer windows will open focused on the SYSVOL folder in which thescripts 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. Toadd the new script, click Add, then click Browse. You will be taken to an open file dialog boxfocused on the GPT folder in which you just pasted your new script. From here, you simplyhighlight the script, and select Open to add the script to the list of those being processed by theGPO. You can also add to the script any command-line parameters, which are parameters thatyou 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 inthe GPT, there is an alternative way to call a new script. If you click Add, as before, then clickBrowse, you can browse the file system to locate the script that you want to add. In that case, theGPO 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 theC:\ folder. The problem with this scenario is that that script needs to be in C:\ on every machinethat the GPO processes on—or it won’t be found. An alternative approach is to reference a scriptlocated 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 acomputer-based startup or shutdown script policy, because they are running under theLocalSystem security context and won’t have access to network shares. I suggest that in mostcases you simply copy your scripts into the GPT for that GPO so that the scripts can bereplicated with the rest of your GPOs. The only case in which it makes a lot of sense to have ascript referenced from a network share is when that script changes often and is used by manydifferent GPOs. In such a case, having to keep the script synchronized across many differentGPTs would be difficult.

Q 3.8: Can I use Group Policy Object-based software installation todeploy 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 filecalled 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 ratherthan any other mode within software installation. Machine assignment means that at the nextreboot, the computer will process its GPOs and when it comes across the service pack updatethat has been defined, will run the update before the user can logon. Typically at the end of theupdate 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 XPworkstation to a new service pack using GPO-based software installation. The very first task youneed to do is get the network install version of the new service pack. This version usually comesin an executable file format. Once you have this file, copy the service pack file into a directoryon the server that will source the service pack update. This directory could be a folder that isreplicated 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 folderwithin the service pack files and be called update.msi. Locate that file. Open the Group Policyeditor tool focused on the GPO that will be used to deploy the service pack update, and drill intoComputer Configuration, Software Settings, Software Installation. Right-click the software

installation node, and choose New, Package. When you enter the path to update.msi, make sureyou 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 packageor choose other options using Advanced published or assign. I always choose the latter as it givesme 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 (seeFigure 3.20). For example, if you only wanted this service pack update to go to a select group ofmachines, you could select the Security tab and adjust permissions such that only the computeror 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 packsshouldn’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 backgroundrefresh, 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 youdon’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 todetermine 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 tocomplete. 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 theusers 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-controlsystem for managing changes to your Group Policy Objects (GPOs), there are several low- andhigh-tech approaches you can take to ensure a consistent GPO environment. A key factor in thesuccess of designing and deploying a substantial GPO-based infrastructure is the ability tomanage and maintain that infrastructure over time. Similar to other aspects of your ITinfrastructure, you need to be able to track and document changes to GPOs, and support formalrelease-management processes that most companies require. Unfortunately, there are nomechanisms 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 versioningmechanism 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 mostcases, this internal versioning scheme won’t be useful for your company’s version-control needsbecause 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 withinGPOs. 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 toyour 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 reflectthat. 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 yourGPO. 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) thatcontains all the default Administrative Template settings within a Windows XP-based GPO. Youcan find the spreadsheet athttp://www.microsoft.com/windowsxp/pro/techinfo/productdoc/gpss.asp. This spreadsheetserves as a good starting point for keeping version information, though you will have to add rowsfor other policy areas such as security and software installation. Figure 4.2 shows an example ofhow 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 templatefile that “tattoos” version information into the registry of each computer (and user) that receivesa particular GPO. This approach allows you to go to a workstation and see what version of GPOhas been processed. I like this approach because not only does it let you know which version of

75

http://www.microsoft.com/windowsxp/pro/techinfo/productdoc/gpss.asp

http://www.microsoft.com/windowsxp/pro/techinfo/productdoc/gpss.asp



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 !!CustomPolicy !!MachineGPOVersionKEYNAME "SOFTWARE\MyCompany\GPO\Desktop Lockdown Policy"

EXPLAIN !!GPOVersion_HelpPART !!Blank EDITTEXT

VALUENAME "CURRENTVERSION"END PART

END POLICY

END CATEGORY ; MY CUSTOM MACHINE POLICIESCLASS USERCATEGORY !!CUSTOM

POLICY !!UserGPOVersionKEYNAME "SOFTWARE\MyCompany\GPO\Desktop Lockdown Policy"

EXPLAIN !!GPOVersion_HelpPART !!Blank EDITTEXTVALUENAME "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 .admfile. You will need to customize the .adm file for each GPO for which you embed versioninformation. In case you’re wondering what this customization will look like within theMicrosoft 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 amachine 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 theversion 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 aspreadsheet 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 keyfeatures that you might need for a fully functional version-control environment within yourinfrastructure. The high-tech approach is to use a product such as FullArmor’s FAZAM GPRepository. 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 inyour AD, the Repository can keep track of version information for your GPOs. Moreimportantly, 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 iskey 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 domainbefore 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 moreGPOs 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 acomputer 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 infrastructurecan support.

Asynchronous vs. Synchronous Processing

By default in Win2K computers and users process GPOs synchronously. This means that, whenthe computer boots up, it processes all computer-specific GPOs it is subject to before presentingthe 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 thecomputer to present the logon dialog box to the user without waiting for all computer-specific GPOs tofinish processing.

Asynchronous processing allows the computer to start up and present a logon dialog box to theuser 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-specificGPOs 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 policyfeatures within the GPO—such as folder redirection and software installation—can take two userlogon cycles to take effect.

You can set asynchronous vs. synchronous behavior on a per computer basis through anAdministrative 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, becauseGPOs are set to asynchronous processing by default, you need to set only one policy item toconfigure synchronous policy processing. Namely, in Computer Configuration, AdministrativeTemplates, 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 aroundGPO versioning. Whenever you make a change to a GPO, an internal version number that theGPO keeps is incremented by the number of changes you make. In addition, workstations andservers 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

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. Todisable 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 andthus 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 orcomputer 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 todeploy a large application such as Microsoft Office to your computers, make sure that theserver on which the Office installation bits are stored are not across a slow WAN linkfrom the clients processing the GPO.

81



Chapter 4

• Ensure that any startup, shutdown, logon, or logoff scripts that you write are testedthoroughly to ensure that they don’t hang during processing. If a script delivered by aGPO 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 delaysin the overall GPO processing time.

• Minimize GPOs linked across domain boundaries. In AD, you can define a GPO in onedomain within your forest, and link it to a container in another domain. However, thiscross-domain linking can cause increased processing time as the client computer mustauthenticate across domain trust boundaries to access the remote GPO. A better solutionis to copy the GPO from the source domain to the target domain using tools such as thosefound in FullArmor’s FAZAM utility.

Q 4.3: How do I deal with multiple domain forests and Group PolicyObjects?

A: If your Active Directory (AD) forest consists of multiple domains or maybe even multipledomain trees, you might need to take a step back in your Group Policy Object (GPO) design andfigure out how your GPOs can be used and managed across multiple domains. The challenges ofdesigning a GPO implementation for a multi-domain forest are more complicated than those youneed to consider in a single domain environment. First and foremost, you need to understandhow each of the domains will be administered. Remember that GPOs are created and exist withina single domain but can be linked to across domain boundaries. However, linking to GPOsacross domain boundaries imposes a certain performance penalty on the users and computerswho process those cross-domain GPOs.

So when you’re designing a GPO infrastructure that will span domains, what is the best approachto 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 willthe GPO infrastructure be a hybrid of some centrally managed GPOs and some managed withineach domain? Each approach will call for a different design. The key challenge you will face in amulti-domain environment is ensuring consistency. Because each domain will end up creating itsown 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 GPOsdiverge and conflict in their configuration.

The problem is compounded because there are no native tools in Windows 2000 (Win2K) orWindows XP that let you copy a GPO from one domain to the next. Third-party tools such asFullArmor’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 clearlydocumenting your GPOs and making that documentation available to all domain administratorsin your forest. Additionally, you should develop up-front some good for when you want to letGPOs 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—forexample 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 havehighly available, you create the GPOs in each domain in which they’re needed. Then you canmake 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 hasits own Security GPO, linked at the domain level. In addition, there are a number of OU-linkedGPOs 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 thatGPO from OU4. Likewise, the organizational unit (OU) administrator of OU2 in tld.org wants touse the Internet Explorer (IE) maintenance policy defined in Us.tld.org and currently linked toOU32. 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 toremember to do is grant access to the appropriate groups to read and process your GPOs. To doso, you need to apply the Read (but not write) and Apply Group Policy permissions to yourGPOs for the “remote” administrator to link to and process the GPO. For example, if I’m anadministrator 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. Bydefault, if the Authenticated Users group has read and apply Group Policy permissions on aGPO, anyone in the forest should be able to link to it and process it. However, if theadministrator of the GPO has removed the Authenticated Users access control entry (ACE), theadministrator will need to explicitly add an ACE that grants permission to the administrator ofOU4 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 restrictwho can link to your GPO either within or across domain boundaries. I always recommend thatif you have a GPO that you don’t want just any administrator in your forest to link to, you shouldensure that you have modified its default permissions to remove the Authenticated Users ACEand 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 Objectinfrastructure?

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 formanaging 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 thosecapabilities in Win2K and Windows XP. In this section, I’ll talk about how you might handle thechange 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 strictchange control processes to track the change event. How strict your processes are usuallydepends upon how large your organization is and how great of an impact the change will have. Inthe case of your GPO infrastructure, there simply are no tools out of the box that can providegood 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 ofimplementing a change management system for GPOs.

The first thing that most change processes require is a way of documenting what is changing. Asyou know, it can be very difficult to document all of the various policy settings within a singleGPO, 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 orother manual mechanism. You can use command-line tools such as gpresult.exe to documenthow a GPO effects your users, but you can’t use that tool to actually document the contents of aGPO, 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 ofchanges in your Win2K or Windows XP infrastructure, you can’t script a GPO change becausethere are no scripting interfaces into the GPO infrastructure. To document a change for anadministrator to implement, you need to actually spell out the step-by-step instructions thatdescribe 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 GPOchanges have some familiarity with GPO technology.

The ability to back out of changes is another big problem with the current technology. There issimply no clean way to back out of a GPO change. Depending upon the type of policy you needto 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 someuser’s desktops. Now let’s assume that, as a result of the change, an application has stoppedworking 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’vereturned the environment to its pre-change state, but rather an undo of what the policy previouslydid. Generally speaking, if the policy is a true policy as defined in Question 1.2, you should beable 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 setthe 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 nolonger 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 longerapplies.

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, whichcould cause other problems if the GPO has other settings that you are implementing. As you cansee, there are no easy answers when it comes to backing out. The easiest answer is test your GPOchanges 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 toimplement it? There are a couple of tactics for doing so. The first and easiest is to take advantageof the fact that new GPOs can be created without linking them to a container object (seeQuestion 3.1 for more information about how to do so), or they can be created without linkingthem 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, thenwhen you’re ready to move it into production, simply add the link to the ultimate containerobject. This approach works great if you’re implementing a new GPO, but what about stagingchanges to existing GPOs? Again, this process is very difficult out-of-the-box unless you have athird-party tool that provides for offline editing of GPOs. The best you can do is to test yourchanges on a different GPO that has the same settings as the production GPO, then, after you’veverified 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 thatusers 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 orcomputers that logon or startup while the GPO is disabled won’t process the GPO. This behavioris 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 softwareinstallation), you should try to make GPO changes of this kind after hours when users aren’tlikely to logon.

86



Chapter 4

Q 4.5: What is the best scheme for allowing my organizational unitadministrators 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 GroupPolicy within their environment. On the other hand, Group Policies that are meant for a singleGPO can impact an entire Active Directory (AD) domain. Thus, it’s important to balance whatan OU administrator can do with what is best for the AD. Remember that delegation of GPOadministration 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 thatcapability in the Group Policy Creator Owners group. After the GPO has been created, the useror group needs the Read, Write, and Create All Child Objects permissions to be able to edit theGPO. Read, Write, and Delete All Child Objects permissions are required to be able to delete theGPO (see Figure 4.11).

87

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



Chapter 4

In Figure 4.11, you see that the Finance Admins group has the ability to both edit and delete theexisting GPO called Finance Admins Lockdown. The ability to link or unlink a GPO to acontainer object is controlled by permissions on the AD container object itself. Specifically, tolink and unlink a GPO to a site, domain, or OU, the user or group needs the Read and WritegPLink 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 alsogrant the gPLink and gPOptions permissions individually through the AD Access Control List(ACL) editor within the Microsoft Management Console (MMC) Active Directory Users andComputers or AD Sites and Services snap-ins. Right-click the container object in question, andchoose Properties from the context menu. Then choose the Security tab to bring up the ACLeditor. The easiest way to grant the Read and Write permissions I mentioned earlier is toimmediately click Advanced to choose the advanced ACL editor. Then add the user or group towhich 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? Theanswer 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 OUadministrators. 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 againresponsible for handling those tasks. In this scenario, you need only delegate the linking andunlinking permissions to the OU(s) involved, and grant all creation and editing permissions toyour 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 whocan 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 createin your domain. Perhaps the administrator creates hundreds or even thousands! The result is thatevery 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 mightnot be a huge problem in most cases, you might have parts of your network that can’t afford theextra replication overhead of such activity. To take it one step further, suppose a malicious OUadministrator were to create a GPO that contains a logon script that is 5GB in size! This logonscript 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 somecases, replication of this logon script could cause servers to run out of disk space. The point isthat an OU administrator that has limited rights over your domain could wreak havoc over thatdomain 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 administratorsthe ability to create and/or edit GPOs. Or you could simply grant those administrators the abilityto edit certain GPOs while keeping others off limits. (Permissioning GPOs is not an all ornothing operation—you can grant permissions to edit a select group of GPOs and leave others tothe 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 anyone 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 GPOenvironment. A single GPO can be linked to multiple container objects (multiple OUs). Thus, ifyou have a GPO that is providing policy for multiple OUs, you need to ensure that you aren’tgranting editing rights to each of the administrators of those OUs without requiring some kind ofcoordination between the two. If you don’t require this kind of coordination, you could have OUadministrators overwriting each other’s changes or making policy changes that significantlyimpact 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 useGroup 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 iscommon in child domains. It also holds user groups such as the Enterprise Admins and SchemaAdmins groups, which have special rights over the entire forest. So, in large organizations, it’s agood 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) tomanage 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, onthis domain, you will most assuredly want to set strict account policy that determines whichusers can access the domain and which users can perform operations on domain objects. Anothergood 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 amember of these groups is the Administrator account for the domain. You might want to controlthis membership very strictly because anyone who can become an Enterprise Admins groupmember can potentially wreak havoc on your forest. In addition, you might want to set RestrictedGroups policy to ensure that only certain users or groups can be placed in the Enterprise Adminsgroup (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 linkedto the Domain Controllers organizational unit (OU)—most logically the Default DomainControllers policy.

You might also want to set up some Administrative Template policy that warns users who logonto 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, WindowsSettings, Security Settings, Local Policies, Security Options, Message text for users attempting tologon) 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 undamagedas possible, which is a beneficial state because the forest root domain is irreplaceable and cancause massive havoc in your AD infrastructure if it’s damaged.

Q 4.7: What are the challenges of “sharing” Group Policy Objectsbetween organizational units?

A: As you know, it is possible to create a Group Policy Object (GPO) that is shared betweenmultiple organizational units (OUs), domains, or Active Directory (AD) sites. That is, you canlink to a GPO from any number of these container objects. However there are some things tokeep 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. Forexample, as long as an OU administrator has the permissions to link a GPO to his or her OU, andas long as the administrator has permissions to read a GPO, he or she can link it and have usersor computers in the OU start processing it. Doing so can be challenging because, although a GPOmay 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 recommendcreating a clear distinction between “shared” GPOs and those that are created specifically for theuse of a single or small set of container objects. Shared GPOs will need to have a more stringentchange-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 onlyexists in one place, any changes you make to it, as I mentioned earlier, affect all those who havelinked to that GPO This includes, most obviously, the permissions that have been set on thatGPO. If an administrator creates a GPO with the express intention of using it to provide policyfor the Finance Users group within the Finance OU, the administrator might decide to permissionthat 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 thisGPO (called Finance Users Lockdown) is the Finance Users group. Now, suppose the OUadministrator 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 goesahead and does so. The next time her Sales users log onto their Windows 2000 (Win2K) orWindows 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 theFinance 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 Readand 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 yourgroups if you add Sales users to the Finance Users group simply to allow GPO processing. In thesecond case, there is no way to grant the Sales users group the ability to just modify permissionson the Finance Users Lockdown GPO to allow the Sales Admins group to also be able to processthe GPO. You will need to grant Write permissions on the GPO to allow permission editing, andif you do grant that permission, the Sales Admins group can not only modify permissions butalso 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 ModifyPermissions 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 arealso granted the Write All Properties permission. I consider this a bug in the way GPO control isdelegated!

Given the ramifications for sharing GPOs, what can you do? Well, the first and easiest thing todo is to avoid sharing GPOs! Doing so might seem like a lot of work up front, but it will proveits worth as you try to share more and more of your GPOs. You can use the capabilities of a toolsuch as FullArmor’s FAZAM 2000 to copy the contents and settings of one GPO to another ifyou want to re-use a particular GPO’s policies but don’t want to manual re-enter them again andagain. If you decide to share some GPOs, make sure you know who you’re affecting each timeyou make a change to those GPOs. The easiest way to do so is to use the “links finder” capabilitywithin 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 thedomain in which you want to search for links to the selected GPO, and click Find Now. Allcontainers 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 ofheadaches 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 installationfeature to replace my existing software distribution tools?

A: When administrators come across the software installation features in Group Policy, the firstthing they wonder is whether they can use this feature exclusively and throw out their existingsoftware distribution tool. Unfortunately, the answer I usually give when someone asks me aboutthis 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 NT4.0, with which you had to use Systems Management Server (SMS) or a similar highly complexsoftware distribution tool to deploy software to desktops and servers in your environment. GroupPolicy 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 Windows2000 (Win2K) or Windows XP. The Group Policy software installation features truly providesome elegant features not found in other distribution tools:

• Supports per-machine and per-user installation of applications. Thus, you can deployapplications to machines or users based on the organizational unit (OU) they are in or thegroups of which they are a member.

94



Chapter 4

• Supports the concept of application advertisement. Advertising an application means thatthe application’s icons and shortcuts are installed but the full application isn’t actuallyinstalled until the user first uses it.

• Leverages privilege elevation to let a user run an application installation that the userordinarily 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 repairfeatures. The software installation feature requires that you package your applicationinstallations 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 ofdefault packages using transforms. The software installation feature does support aformat 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 privilegeelevation, 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 theapplication 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 gothrough.

However, the Group Policy software installation feature is missing some key functionality thatmost enterprise software distribution tools provide:

• No centralized way to report on the success or failure of an application installation acrossmany machines. Because GPO-based software installation deploys software when a GPOis 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 haveto 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 whichsoftware 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 whichusers and computers are receiving which applications.

• No inventory component within the software installation feature. Most softwaredistribution tools, such as SMS, provide an inventory component that lets you look atwhich hardware and software is installed on machines under management.

• No support for software distribution across slow or dial-up links. Some softwaredistribution tools support trickle-down installations of applications. The softwareinstallation feature not only does not support this functionality, but the softwareinstallation 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 installationsupported 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 acceptablein most server environments.

• No support for license metering or a way of limiting the number of users or computersthat install an application (other than restricting an application by user or computergroup).

If these limitations aren’t critical to you—if you’re working in a small to midsized environmentin which Sneakernet is your only other software distribution tool option, GPO-based softwareinstallation 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 Figure4.17) can be a great way to provide your users with a low-maintenance, self-service way ofinstalling optional applications that your enterprise supports but doesn’t necessarily want toinstall on every desktop.

Figure 4.17: Viewing an application that has been published via GPO-based software installation to the

Add/Remove Programs applet.

96

As you can see in Figure 4.17, I have published the Win2K Administration Tools to users thatmight 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’tinstalled until the user clicks Add. This kind of “software distribution” has low overhead becausean administrator need only publish it once for it to be available to hundreds or thousands ofusers.



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 theGPO itself, depending upon the function you are delegating.

Delegation of AD rights can often be a challenging process. In the Microsoft ManagementConsole (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 ofdelegating administration of AD objects. But the Delegation of Control wizard is only good forsetting the initial permissions on an AD object and can’t delegate administration of GPOs. If youneed 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 thanwith the Delegation of Control wizard. First, let’s examine how you can delegate editing ofGPOs. The first thing to know about GPO delegation is that it’s all about modifying the accesscontrol list (ACL) of the GPO. A GPO is composed of the Group Policy Container (GPC, whichis an object in AD) and the Group Policy Template (GPT, which is a set of folders and files inSYSVOL). Thus, you need to be able to modify the permissions of these two pieces of the GPOto grant users and groups the ability to modify the GPO. Fortunately, there is a fairly easy way tomodify these permissions that does not require you to directly manipulate the ACLs on each. Thefollowing 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 DelegatedGPO:

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 todelegate 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 thechoice 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’redelegating editing rights on this GPO.

6. Once you’ve added the group to the ACL editor, make sure that the group name ishighlighted, then check the following permissions for that group to grant GPO editingrights: Read, Write, Create All Child Objects, and Delete All Child Objects, as Figure 5.2shows.

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 combinationof Read and Apply Group Policy rights means that the groups with those two rights willalways 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’treally do much with your GPOs—they won’t be processed by any computers or users withinyour AD infrastructure. You can use the Delegation of Control wizard to delegate the linkingright, 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 wizardto set it up initially. Once again, the delegation process for the right to link to GPOs is aboutmodifying AD security—in this case, on the container object directly instead of on the GPO. Solet’s suppose that you want to delegate the linking right to the same GPO Admins group I usedearlier for the HQ OU. Thus, you want any member of the GPO Admins group to be able to linkGPOs 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 onwhich you want to set up delegation.

99



Chapter 5

2. Right-click the OU, choose Properties from the context menu, then select the Securitytab.

3. You will now see the familiar ACL editor dialog box focused on the OU. Click Add toadd the GPO Admins group as a new access control entry (ACE), and click OK toconfirm 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.3shows.

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

6. You will see a long list of AD properties for this OU object that you can set permissionson. 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 thisOU. (Note that the Read gPLink and Read gPOptions properties should already beselected.) 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 abilityto link GPOs to the container object. Why? What you did in the previous steps was grant thegroup 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 GPOslinked to the container object and options (gPOptions) that you’ve selected. A group must havethe 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?

101

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 allowsyou 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 limitedfor delegating control of Group Policy Object (GPO) administration. What the Delegation ofControl wizard provides with respect to GPO administration is the ability to delegate the processof linking and unlinking GPOs to container objects within a domain. This functionality is auseful capability to delegate in your AD infrastructure. For example, you might want to retain



Chapter 5

control of the creation and editing of GPOs within a central group, but then allow administratorsof 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 containerobject. 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) onAD objects within your domain. For example, if you’re delegating control of an OU to a groupof administrators, you’re basically setting permissions on that OU that allow the administratorsto perform the proper operations over AD objects within that OU. The Delegation of Controlwizard prompts you to select the target to delegate and the group being delegated to, then doesthe work of modifying the ACLs on the target to provide access to the group. However, thewizard 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 subsequenttweaking of permissions.

Now, let’s look at how you can delegate linking and unlinking of GPOs to particular containerobjects. First, I’ll provide a little background about the linking process. When you link a GPO toa container object such as a site, domain, or OU, what you’re really doing is modifying a coupleof 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 ofthe 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 andunlink a GPO from a container object involves granting the permissions to modify these twoattributes, 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 youwant 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’scheck box. Alternatively, you could have selected the Create a custom task to delegateradio button and manually selected which permissions you wanted to grant on whichkinds 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 isconsidered an advanced permission, so once you have the ACL editor up and focused on the siteobject, you’ll need to click Advanced to view advanced permissions. Figure 5.6 shows that twoACEs were created for the group (SF Site Administrators) to which I chose to delegate thelinking 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 thelinking and unlinking permission on a container object—gPLinks and gPOptions. If I were tohighlight each of these permissions and click View/Edit, I would see read/write permissionsgranted 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 properrights have been granted to them.

Q 5.3: How can I prevent certain users from administering portions ofmy 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 canedit it. However, if you want to restrict only certain parts of a GPO, the only way to do so is touse Administrative Template policy. There is a set of Administrative Template policies that letyou 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 theMMC, and thus control what they can edit. These policies are not real security but simply blocka user’s ability to get to the proper tools for editing a particular part of a GPO. This feature cancome in handy when you have a GPO that provides a number of functions—for example, folderredirection, Administrative Template policy, and software installation—and you want to delegateadministration 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 toGPOs are located in the same place in both Windows 2000 (Win2K) and Windows XP, underUser Configuration, Administrative Templates, Windows Components, Microsoft ManagementConsole, 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 havea 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 policythat 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 abilityto edit the software installation policy on my GPO to deploy some departmental applications, butI don’t want Joe Admin to be able to edit any of the Administrative Template or security policyon 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 JoeAdmin 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 looklike.

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.9shows 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 settingsnodes are missing. The other option that you have using this policy is to actually restrict allGPO-related snap-ins, then only allow access to the specific snap-ins that you want to expose tothe 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 tousers who are subject to the GPO on which the policy is set. If you then go into the Group Policyfolder under this node, you can explicitly enable those GPO-specific snap-in extensions that youwant to allow.

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

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 settingglobal 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 fromthe 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 usefulfor controlling who can actually change the permissions on a particular application. To accesssecurity permission for an application that has been published or assigned using SoftwareInstallation, 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 applicationinstallation, you assign Read permissions to that target group. When you want to delegate therights to modify the permissions on an application, you need to grant the Write permission. Forexample, suppose I want to grant the Finance Admins group the ability to change who can installthe WinInstall LE package that Figure 5.10 shows. I would add the Finance Admins group to theaccess control list (ACL) that the figure shows, and grant them (at the least) Write permissions tothe 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 GPOat a more granular level than the whole GPO. FullArmor’s FAZAM tool provides you with someability 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 isa 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 bythe groups that need to manage them. Although this option will have a performance impact onyour users and computers (more GPOs requires more time to process them), it can simplifyadministration of GPOs. So, for example, if the Finance Admins group needs to administerSoftware Installation policy in GPO A, and the Accounting Admins group needs to administerAdministrative 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 musthave modify permissions on the whole GPO to modify their various pieces. And, after they havemodify permissions on the whole GPO, there is nothing to keep them from modifying pieces thatthey 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 theAccounting 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” andunsupported means. Namely, it is possible to modify permissions on individual parts of theGroup Policy Container (GPC) and Group Policy Template (GPT) to individually control whocan do what within a single GPO. I mention this option only as an educational exercise because Iwouldn’t recommend doing it in production. The reason is that things can get very complex ifyou 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 AdministrativeTemplate policy) or individual containers within Active Directory (AD) for the GPC (forexample, 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 iseasy enough to be undone if someone simply decides to re-apply permissions to a GPO at thewhole GPO level. These permissions can easily be propagated down to the individual GPC andGPT sub-containers and folders and wipe out any custom changes you’ve made. As I said, it’s anice academic exercise to know that you can do it, but I wouldn’t recommend doing it inanything but a test environment.

Q 5.5: How can I audit who has made a change to a Group PolicyObject?

A: Unfortunately, one of the limits of the Group Policy Object (GPO) infrastructure is that thereis no really straightforward way to audit who has made which change to a GPO. What is requiredis that you set up Windows security auditing on the Active Directory (AD) and SYSVOL to beable 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 thinkabout when working with GPOs. In other words, I’d like to know if Joe Admin made a change tothe Desktop Lockdown GPO, and if so, what that change was. Unfortunately, as a result of thestructural nature of GPOs—the fact that they are really two “pieces” in the Group PolicyTemplate (GPT) and Group Policy Container (GPC)—it is very difficult to audit GPO operationsout-of-the-box because there isn’t any one thing that you can audit. However, I’ll show you howyou 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 ADdomain controllers. Auditing is enabled on domain controllers by editing the special DefaultDomain Controllers Policy GPO that is installed by default in every AD installation and linked tothe Domain Controllers organizational unit (OU). To enable AD auditing, start the ActiveDirectory Users and Computers Microsoft Management Console (MMC) snap-in, right click theDomain Controllers OU, and choose Properties from the context menu. Next, choose the GroupPolicy tab, highlight the Default Domain Controllers Policy, and click Edit. Within the GPO,drill into Computer Configuration, Windows Settings, Security Settings, Local Policies, AuditPolicies. 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 haveto 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 alldomain 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 theGPO—not the GPT. However, this level of auditing is usually effective to track who is accessinga GPO, because the GPC and GPT are automatically accessed each time you open or edit a GPOusing the MMC snap-in tools. What this auditing won’t catch is specific changes made to fileswithin the GPT. For that, you need to enable the Audit Object Access item that Figure 5.11shows, 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 ofaccess 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 operationsyou’re interested in logging. To access auditing settings within a GPO, you need to bring up theACL editor on the GPO. If you are already editing the GPO, you can access the ACL editor byright-clicking the GPO’s name within the MMC snap-in tool, and choosing Properties from thecontext menu. Next, choose the Security tab, then click Advanced. Finally, click the Auditing tabto access the auditing SACLs window (see Figure 5.12).

109





Chapter 5

And, if I select the Properties tab in this dialog box, the tab will shows me which attributes onthe GPC are being audited for access. If I am setting up auditing on a particular GPO that islinked to an OU, I might want to remove the Everyone entry from the auditing list and only auditaccess 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 beenedited and view the logs to determine who has been in that GPO. For example, as Figure 5.14shows, 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 thatthe event shows that the administrator wrote a new value to the versionNumber attribute on thatGPC. 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 ofthe 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 inyour 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 Policiesfolder, and choose Properties from the context menu. Next, choose the Security tab, and clickAdvanced. Finally, click Auditing to see what auditing has been enabled on this folder. Unlikethe 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 andlocating 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 calledFinance 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 ammost interested in auditing the activities that would cause a change in the files or folders thatexist 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 aGPO 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 theregistry.pol file under the user subfolder of the GPT. This description tells me that jadmin madea per-user Administrative Template policy change to this GPO, though it does not tell me whatthe change was.

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

A: There is a significant difference between deleting a Group Policy Object (GPO) and deletinga GPO link—one is permanent and irreversible and the other merely disassociates a GPO from acontainer 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 thatobject (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 containerobject—in my example here it’s the Finance OU. By unlinking the GPO, you simply disassociatefrom the container object—the OU. The GPO will no longer be processed by users andcomputers in this OU, but the GPO still exists in the domain and can be re-linked to anothercontainer 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 theGPO 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 itsconstituent parts—the Group Policy Container (GPC) and Group Policy Template (GPT) fromActive 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). Thisoperation completely removes all vestiges of the GPO from AD. If the GPO that you’re deletingis linked to other container objects in your AD forest, those links will be removed as well. Noorphan links will be left. Obviously, it’s important to choose the correct option when deleting alink (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 tousers 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 caneasily delegate administration of GPOs to a group of users (or other groups) that reside inmultiple OUs and even multiple domains.

This question is more about the capabilities of Active Directory (AD) groups than it is aboutGPO delegation, but it’s an important topic to discuss because it is likely to come up oftenthroughout your AD and GPO administrative chores. As you know, you can delegate the abilityto 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 onthat 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 anddomains that all need the ability to edit a GPO. In that case, you can use some of the capabilitiesof 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 OUswithin the Us.mycompany.tld AD domain. You also have two administrators in thecorresponding Finance and Sales OUs within Europe.mycompany.tld. All eight of theseadministrators need to be able to edit the GPO that resides in Us.mycompany.tld calledMycompany 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 containsusers (it could just as easily contain groups) from both AD domains. Then, I’ve used theuniversal group, called MyCompany Lockdown Admins, to permission the MycompanyLockdown Policy GPO that is defined in Us.mycompany.tld. This setup is a very easy andeffective way to create a virtual OU of administrators (using universal groups) who can then begranted permissions to various AD objects, such as GPOs.

Q 5.8: How can I view who has the rights to create Group PolicyObjects 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 editan 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. Butviewing 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 (theGroup Policy Template—GPT—and the Group Policy Container—GPC), a user has to have theappropriate rights in the domain in which the GPO is created on both the GPT and GPC. TheGPC 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 theGPC 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 thedomain. Navigate to the System container, and expand it to expose the Policies container (seeFigure 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 thedomain (the GPCs are the GUID-named folders you see in the right pane). It is the permissionson the Policies container that control who can create new GPC objects, and thus new GPOs, onthe domain. So to find out who can create GPOs in your domain, right-click the Policiescontainer, and select Properties from the context menu. Select the Security tab to view thecurrent permissions on the container. Figure 5.21 shows the default permissions that exist on thePolicies 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 asAdministrators, 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 CreatorOwners 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. Forexample, the Group Policy Creator Owners group can only create new GPOs, but DomainAdmins and Enterprise Admins can create and delete GPOs, while members of the localAdministrators group can only create but not delete, GPOs. Finally Authenticated Users have theRead 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 underSystem 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 exclusivelyto 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 atremendous amount of flexibility, you can use the customization features within the MMC tocreate 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 distributeto your administrators. The advantage of creating these custom tools is that you can expose onlythose 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 youradministrators access to the Active Directory Users and Computers snap-in and expecting themto navigate to the correct container object in which the GPO they need to manage is linked, youcan 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 toyour Active Directory (AD) domain. You want to create a tool that exposes only those threeGPOs to them. Following these steps, you can create a custom MMC tool to accomplish thisgoal.

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 GPOsin your AD domain.

5. Select the GPO you want to add to the MMC console. Repeat steps 3 and 4 for all GPOsyou want to add.

6. Once you’ve added all the desired GPOs, you need to lock down the console tool so thatyour 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 modethat the tool will be opened in. In this case, choose User mode—limited access, singlewindow from the Console mode drop-down list.

8. Check the Do not save changes to this console check box, as Figure 6.1 illustrates, thenclick 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. Itcannot 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 thistool cannot add any other MMC snap-ins and basically can only administer the three GPOslisted.

Limit Tools Even More

You can provide an even more limited MMC console. For example, you might have a GPO thatuses the software installation feature to deploy applications. To illustrate this point, suppose youhave 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 theadministrator. 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, drillinto 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 softwareinstallation node window is maximized such that it takes up all the real estate on the MMCconsole and blocks visual access to any other policy settings within the GPO. Next, set theconsole 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 theresulting 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 settingsnor 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 technicalskill 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 aresome 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 availablethrough the Windows Script Host (WSH) and the Active Directory Service Interfaces (ADSI)COM objects available in Win2K and Windows XP. The Microsoft article “Scripting theAddition 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 theserver 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. Butchoosing the PDC emulator is preferable because GPO changes, by default, are always madeagainst 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.DLLis a library of functions that let you perform administrative scripting activities on AD and relatedobjects. For example, the line in the script (modified to include my domain name and servername)

Result=DLL.GetGPOs("mar-elia.com","DC1")

uses the IADSTools method called GetGPOs() to return a list of all GPOs defined in the domaincalled mar-elia.com. DC1 is the name of the PDC emulator for the domain that the functionqueries. 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 thevariable called SDOU to add the new GPO link. By default the script is set up to link GPOs tothe 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 simplymodifying this statement. For example, if I want to add a GPO link to an OU called Finance, Iwould 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 processgets 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 wantto 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 OUexamples. 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 thedomain, as Listing 6.1 shows.

123

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q248392






Chapter 6

C:\> cscript gpollink.vbsMicrosoft (R) Windows Script Host Version 5.1 for WindowsCopyright (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 LockdownPolicy)

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. Assumingthat the script finds the name of your GPO, it creates the link on the container object and returnsa success message.

This script only adds GPO links to a container object—it does not remove them. However, withsome clever string manipulation, you could modify the same script to do the removal process aswell. 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 forthe chosen GPO.

Expect later releases of Windows as well as third-party products to provide the ability to scriptthe creation and editing of GPOs. This ability will most likely come in the form of WindowsManagement 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 aWin2K 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 useuser_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 thecomputer, but nevertheless, secedit can trigger reprocessing. GPO policy items such as folder

redirection and software installation are not actually triggered to run using secedit. Theseextensions 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 supportfor refreshing GPO-based policy. With gpupdate.exe, we get a more full-featured command-linemechanism 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 ofall 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 andfolder 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 thecommand 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 instructsgpupdate to process all applicable GPOs and, if there are any policies that require a logon eventto actually become visible, this option forces a user to logoff. Similarly, the Boot option does thesame thing for policies that require a system restart (such as machine-based softwareinstallation). After all applicable GPOs are processed, if a reboot is required, the system willreboot. Finally, the Sync option is a very useful one in that it lets you override asynchronousGPO processing (also known as fast logon optimization in Windows XP) for the next processingcycle only. By calling the Sync option, the next time a computer starts or a user logs on to amachine, 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 youneed to test that fact.

Finally, it’s important to note that even though secedit and gpupdate provide command-linemechanisms for refreshing policy, such refreshes are still logged in the Application event log asthey 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 myGroup Policy Objects at once?

A: Yes, using the features of the Microsoft Management Console (MMC), you can easily createa 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 youknow, using the Active Directory Users and Computers or AD Sites and Services MMC snap-intools, you usually have to hunt around to get to each GPO in which you’re interested. Bycreating a custom MMC console that shows all the relevant GPOs in a single view, you can savetime and ensure that you are always working on the right GPOs. The following step-by-stepinstructions 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/RemoveSnap-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 inyour AD. If you don’t know where the GPO(s) of interest are linked, choose the All tabto 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 and5 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/Removesnap-in dialog box.

126



Chapter 6

8. The final step is to save your tool. From the Console menu (or File menu in WindowsXP), choose Save, then give the tool a name. The resulting file will have an .mscextension.

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 mewithin this single MMC window. I can expand and edit each GPO as I would normally, and haveall the GPOs of interest available next to the others if I need to compare one or the other. I canalso 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. Ican create a favorite that takes me quickly to this policy item by first expanding into the requirednode (in this case User Configuration, Administrative Templates, Windows Components,Windows Explorer). Then, from the Favorites menu on the MMC toolbar, I can choose AddFavorites 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 createdmy favorites, I can use the Favorites tab to navigate quickly and easily right to the policy item Ineed to edit. For example, in Figure 6.7, I’ve created three favorites, which I’ve named first byidentifying 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 Ihighlight each favorite. This feature is super handy for frequently edited GPO settings, and Ihighly recommend pre-creating these custom MMC tools for GPO administrators. It will makeyour 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 toother 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 usedto replicate SYSVOL to domain controllers in an AD domain. FRS relies on inter- and intra-siteAD connection objects that are built by the Knowledge Consistency Checker (KCC) to replicatecontent between domain controllers. However, FRS content will not necessarily replicate on thesame schedule as AD objects. Often, between domain controllers within sites, file replicationhappens very quickly, as soon as a file has changed and the domain controller has notified itsreplication 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 ADsite 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 schedulethat is used to replicate changes. Unlike AD replication, for which you can use the AD Sites andServices snap-in to force a replication trigger between domain controllers, FRS doesn’t providethat kind of interface. You are pretty much at the mercy of FRS to replicate SYSVOL contentwhen 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 cannotoccur. 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 selectProperties from the context menu, the system will present you with the SYSVOL propertiesdialog box. In this window, click Change Schedule to bring up the SYSVOL schedule, as Figure6.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 togglereplication on or off during certain times of the day. This feature gives you some flexibility ifyou’re replicating large numbers of SYSVOL changes and have slow links that you want toremain available during business hours. You could schedule SYSVOL replication to happen afterhours in that case. Of course, that means that any changes you make to your GPOs would not besynchronized 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 calledntfrsutl.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 thenew version of the utility over the old one.

129



Chapter 6

Q 6.6: Can I get information about the Group Policy Objects in mydomain 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 easilyaccess 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 becalled from Windows Script Host (WSH) scripts.

To use IADSTools, you first need to register the DLL on any machine on which you plan to runscripts. 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 isregistered, it exposes several methods for performing all kinds of Active Directory (AD) andGPO-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 inthe Group Policy Container (GPC—within AD).

GetGPOSysVolVersion() Returns the version number of a GPO as held inthe Group Policy Template (GPT—withinSYSVOL).

GetGPOs() Returns a list of GPOs found on a given domaincontroller. The list can be enumerated using thefollowing two functions (GPOName() andGPOGuid()).

GPOName() Returns the friendly name of a GPO as retrievedusing GetGPOs().

GPOGuid() Returns the globally unique ID (GUID) of a GPO asretrieved using GetGPOs()

GPOVersion() Returns the GPC version number of a GPO asretrieved using GetGPOs(). Note that this functionis different than GetGPOVersion() as it requiresGetGPOs() to be run to enumerate a collection ofGPOs prior to being called.

GPOSysVolVersion() Returns the GPT version number of a GPO asretrieved using GetGPOs(). Note that this functionis different than GetGPOSysVolVersion() as itrequires GetGPOs() to be run to enumerate acollection 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. Thefollowing script compares the GPC and GPT versions of a GPO and reports back if they are outof sync. Listing 6.3 shows a script that uses the GetGPOVersion and GetGPOSysVolVersionmethods to check the versions on a GPO (the line numbers have been added to the strict to aid inthis 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: " & GPCVer9. Wscript.echo "GPT Version is: " & GPTVer10. if GPCVer <> GPTVer then11. Wscript.Echo vbCRLF & "Versions are out of sync"

12. else13. 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 inevery IADSTools script. In line 2, I’ve called the EnableDebugLogging method, which sends allactivity 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 Iwant to query in lines 3, 4, and 5. You can just as easily pass these into the script usingcommand-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, ifthey are different, the following code in lines 11,12, and 13 reports that they are different. Figure6.9 shows a sample output of the script running twice—once with GPO versions in sync andonce 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 ussome 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 arrGPOs7. 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) &vbCRLF11. 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 codethe domain and domain controller name into the script as before. Line 5 calls the GetGPOsfunction, 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 getinformation from it, which is then printed to the screen in lines 7, 8, 9, and 10. Figure 6.10 showsthe 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 versionhealth checks on your GPOs. Using the previous scripts, you could check version information ofeach GPO on every domain controller in your environment and easily report errors to a log or toemail.

Q 6.7: How can I add or remove particular policy extensions within theGroup 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 (forexample, 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 toolsare implemented. Each policy capability within the default Windows 2000 (Win2K) andWindows XP installations has two pieces. The first is the client-side extension (CSE), which is aDLL that actually processes Group Policy Object (GPO) settings and applies them to the user orcomputer. 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 asAdministrative Templates, Security Settings, Software Installation, and Folder Redirection isimplemented in a separate DLL. Likewise, the DLLs for editing those capabilities areimplemented 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 acustom MMC tool that exposes only certain MMC extensions, and thus only lets the user editcertain portions of a GPO. This approach contrasts with the feature that lets you useAdministrative Template policy to physically prevent a user from loading certain MMC GPOextensions within an MMC tool. In the approach that I discuss here, you’re not preventing theuse of the extensions if the user knows how to get to them. You are simply taking them out of theuser 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-inis one that can be loaded into an MMC console on its own and does not require any other supportingsnap-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 Policystandalone snap-in. You’ll need to choose a GPO to focus on as you add it to the console. Afteryou’ve completed adding it to the console, you will see a dialog box similar to the one thatFigure 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 thiscase, we’re going to select the Extensions tab to view which extensions have been loaded (seeFigure 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 Policysnap-in. However, if you clear the Add all Extensions check box, you can select whichextensions 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 GPOadministrators. It will be a tool focused on the local GPO, but I don’t want to include any PublicKey policy options because I don’t use Public Key in my infrastructure. To do so, I am going toselect Security Settings from the Snap-ins that can be extended drop-down text box. When Ichoose this snap-in, the list in the Available extensions section changes to show me which MMCextensions 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 optionwill 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 administratorwill no longer see an option for Public Key policies under User Configuration, WindowsSettings, 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 GroupPolicy 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 majornodes such as Administrative Templates (users or computers or both).

136



Chapter 6

Q 6.8: What is the difference between the Local Security Policy tooland 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 Startmenu 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) toolcalled gpedit.msc. The Local Security Policy tool (see Figure 6.15) is called as an MMC toolnamed 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 looksidentical 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 parentnodes 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 inFigure 6.15 is simply a stripped down, focused view of the local GPO that you can view in itsentirety 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 inthe Local Security Policy tool. It’s as if the Local Security Policy tool has “re-rooted” theSecurity 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 typingmmc

in the Start menu Run dialog box, select File (or Console for Win2K MMC users), Add/Removesnap-in, and load the Group Policy snap-in focused on the local computer. You’re now viewingthe 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 thesame 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 inthe figure, there are more menu choices along the top of the tool. Namely, the Favorites andWindow menu items are missing from the Local Security Policy tool. What you’re witnessing isa feature of the MMC that lets an MMC tool author “lock-down” a particular consoleconfiguration 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 theconsole 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 loadthat 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 PolicyMMC 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 authormode 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 soon. User mode is not hard security on a tool but simply a way of keeping a user from futzingwith 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 usingsome very simple tools.

The ability to view the “guts” of a GPO can give you good insight into how this complicatedinfrastructure works. The GPC is an object in Active Directory (AD) that contains severalsettings related to its corresponding GPO. The GPT is a set of folders and files that are storedunder the SYSVOL share on an AD domain controller. Every GPO has exactly one GPC andGPT. The key value that identifies a GPO and its constituent GPC and GPT is its globally uniqueID (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 aGPO 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 andServices Microsoft Management Console (MMC) snap-in.

2. Right-click the container object (the site, domain, or organizational unit—OU) in whichthe 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 ofthe 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 wayto examine the GPC is to use a familiar tool—the Active Directory Users and Computers MMCsnap-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 onthe 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 containershould 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 theGPO.

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, youwould see several properties related to the GPO, including its current internal version, the path toits 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 asubfolder called Class Store and a folder underneath that called Packages. The Class Store andPackages folders are present if you have set any software installation policy within the GPO. TheClass Store is an AD object that keeps information related to how the package was published orassigned 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 replicatedfolder structure present on every AD domain controller. The easiest way to view the contents ofSYSVOL is to log on to the console of a domain controller in your AD domain, select Run fromthe 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 yourcurrent 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 foundwhen we examined the GPC. If you open the same GUID-named folder that we did when wewere looking at the GPC, you will likely see the subfolders and files that Figure 7.4 shows. Thecontents of this GUID-named folder make up the GPT for the GPO.

143





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 issubject to loopback.

Loopback policy is particularly useful for computers that function as kiosks and for terminalservers. Specifically, loopback gives you a way of overriding a user’s default Group Policies byusing 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- anduser-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 existelsewhere within an AD domain and that have special restrictions that apply only to thosecomputers—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. Youenable 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 Figure7.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 thisis 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 inthe 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 computersthat reside in Kiosk process GPOs using loopback. What this setting means is that when jsmithlogs onto the kiosk computer, he will no longer receive the user-specific policy settings that hewould 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, youmight not want a user’s desktop folder to be re-directed using Folder Redirection policy whenthat user logs onto a kiosk. Mechanically what happens is that when the user logs onto acomputer 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 appliedinstead. When the user returns to his or her normal workstation, the loopback policies areremoved and the user’s home policies are restored.

Loopback policy processing is also useful in terminal server environments because you mightneed to lock down a user’s desktop far more restrictively when the user is logging onto amachine 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 mergemode, 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 loopbacksettings “win” and are applied. In most cases, I recommend using the replace mode, as it can getextremely 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 fileonce 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 ifyou need to change a fair number of applications and don’t want to have to delete them and startover. However, you will have to use the redeploy feature within software installation, whichresults 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, whichcontains the ADSI Edit Microsoft Management Console (MMC) snap-in tool. Let’s walk throughthis technique with an example. Figure 7.6 shows that I’ve created a GPO that deploys theWin2K 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 ADSIEdit, I can directly edit the AD attribute that controls where that package is found. Here are thesteps to follow to edit this application’s path:

1. From the Group Policy editor tool, right-click the name of the GPO, and select Propertiesto 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 thedomain naming context for your domain.

3. Under the domain naming context, drill down into the CN=system, CN=policies folderand locate the folder that corresponds to the GUID of your GPO, as Figure 7.7 shows.

147

http://yquem/packages/adminpak.msi

http://yquem/packages/adminpak.msi



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 toreveal a CN=Class Store subfolder.

If you expand the Class Store subfolder, you will expose a CN=Packages folder that contains one ormore GUID-named objects of class packageRegistration (see Figure 7.8). Each packageRegistrationobject 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 willneed 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, choosedisplayName 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 havemultiple 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 packagecan be found.

7. To edit a path value, select the value to edit, and click Remove to move the path into theedit 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 inSYSVOL 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 yourdomain.

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 theapplication name, choose Tasks from the context menu, then choose Re-deployApplication. 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, calledtemp.aas, has been created. Delete this file, and move the old .aas file back into thisfolder.

12. Again, return to the GPO editor tool and redeploy the application one more time. Youshould not receive any errors, and the application will now be installed from the newlocation!

You may very well be thinking that this process is too much work to go through just to changean application’s deployment path. That may be true, but there may be reasons why you can’tsimply 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 overwhich applications a user can run on a Windows XP desktop. Software restriction policy doesnot exist in Windows 2000 (Win2K) clients or earlier versions of the Windows desktop OS. Itcan be found in Windows XP under User Configuration, Windows Settings, Security Settings,Software Restriction Policies. To access software restriction policy on a local machine, selectAdministrative Tools from the Start menu, then select the Local Security Policy MicrosoftManagement 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 yourusers from executing certain types of files. Figure 7.11 shows this tool as it appears in an ActiveDirectory (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 thecontext menu, two new folders, called Security Levels and Additional Rules, are created underthe node. In addition, three new policy items are listed off the root node. These new policy itemsare called Enforcement, Designated File Types, and Trusted Publishers. Let’s look at each of thefeatures 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 thedefault state, but if you double-click the Disallowed item, and choose Set as Default thenthis “arms” the software restriction policy. After Disallowed is set, no software will runfor any end user who is subject to that policy (unless you make exceptions, as we’ll seelater).

• Additional Rules—The Additional Rules folder lets you set up four kinds of rules tocontrol 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 theAdditional 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 setwhether software signed by that certificate is allowed or disallowed. For example, if youdeploy 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 ascript 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 areunique values that are derived by taking information about a file’s size, date andtimestamp, and other information to create a fingerprint of that file. Figure 7.13 shows anexample of a hash rule for which I simply chose to disallow a particular .gif file of aspecific hash value. You can manually enter a hash value rather than letting the ruledialog box create one from a known file. This feature is useful if you’ve found a virus filethat 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 whichInternet zones (for example, Intranet, Internet, Trusted Sites, Restricted Sites) your usersmay run Windows Installer packages. Internet Zone Rules are specific to WindowsInstaller (.msi files) packages only.

• Path Rules—Path Rules let you specify disallowed or unrestricted execution policy forcertain folders or files on your users’ hard drives. For example, as Figure 7.14 shows, youmight specify a directory (in which mail attachments are typically stored) as disallowedas a way of preventing rogue mail attachments from executing. For example, Outlook XPwill store attachments in a user’s profile under %userprofile%\Local Settings\TemporaryInternet Files prior to executing the attachment. You could create a path rule to thatsubdirectory, then any files located within or under it will not execute. (Path Rulessupport 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, DesignatedFiles Types, and Trusted Publishers. The Enforcement option lets you decide whether you wantto include DLLs within the possible types of files that are restricted by the rules you set. Bydefault, DLLs aren’t included, and if you do include them, you will need to spend a lot of timefiguring 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 andPath Rules previously described. So if you allow applications signed by a particular certificate, itwill cover all file types (file extensions) listed in this section. You’ll notice that the default filetypes listed are common types of “executable” code such as .exes, batch files, and WindowsScript 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’totherwise specify a particular file type.

Finally, the Trusted Publishers policy lets you control who can specify a trusted publisher andlets you specify that you want to check with a certificate authority to see whether the publisherhas been revoked before allowing an application to run.

As you can see, software restriction policy is an extremely powerful new feature in Windows XPthat allows you to have very fine-grained control over what your users can and cannot do. Thisability can really come in handy as a second line of defense against viruses, especially when yourantivirus 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 PolicyObject?

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 receiveGPOs. 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 PolicyTemplate (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 somethingwith them. That code is called a Client Side Extension (CSE), and is found by default on everyWin2K 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 alsokeep a list of registered CSEs for a given machine within the registry atHKEY_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 whetherthat CSE will process a GPO even if its version number has not changed since the last processingcycle. Win2K and Windows XP use this list of CSEs in the registry to determine which policyfeatures to process. Thus, in Figure 7.16, if I were to delete the key shown, which, as you can seefrom the right pane of the registry editor, controls the Folder Redirection feature, thatworkstation would no longer be able to process Folder Redirection policy. The same holds truefor other policy processing. If I delete the key that begins with “{8273D19E…”, I will bedisabling security policy processing on that workstation, and thus preventing any security policyfrom 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 thismechanism to foil your security and other GPO-based controls.

There are better ways to prevent a workstation from processing a GPO. As an administrator, youcan 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 disablesome or all GPO features. By manipulating which CSEs are registered on a workstation orserver, 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 ActiveDirectory domain?

A: Windows XP introduces quite a few new Group Policy Object (GPO)-based AdministrativeTemplate 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 ActiveDirectory (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 SideExtensions (CSEs) on the workstation or server that is processing the GPO. As such, it makescomplete sense that Windows XP comes with newer or more capable policies than those found inWin2K. So if you want to deploy Windows XP in your existing Win2K AD domain, how do youtake advantage of those new policies without breaking policy on your Win2K machines? It’squite simple really.

The first thing you need to do is to be able to open GPOs using the standard MicrosoftManagement Console (MMC) snap-ins that you are used to in Win2K. Unfortunately, the servermanagement tools, such as Active Directory Users and Computers and AD Sites and Servicesthat are part of the Win2K Administration Tools Pack, no longer work in Windows XP. As ofthis writing, the only way you can manage AD-based GPOs on a Windows XP machine is todownload and install the .NET Server Beta 3 Administration Tools Pack .MSI file fromMicrosoft’s Web site.

The .NET Server Beta 3 administration tools for Windows XP can be found athttp://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 youneed 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 GPOupgrades 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 yourAD domain that you want to support XP clients.

What’s happening behind the scenes during this process is pretty straightforward. Remember thatthe Group Policy Template (GPT) portion of a GPO holds the actual files and settings thatrepresent 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 withinthe GPT for that GPO (see Figure 7.17).

157

http://www.microsoft.com/downloads/release.asp?ReleaseID=34032&area=search&ordinal=9

http://www.microsoft.com/downloads/release.asp?ReleaseID=34032&area=search&ordinal=9



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 isWindows XP–specific to be set within that GPO. Windows XP introduces the SUPPORTED taginto Administrative Template .adm files. This tag lets the client determine whether the policy ismeant 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, theindividual 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 editthem using either Win2K or Windows XP administration tools.

Q 7.7: How is Group Policy Object history stored and used on theclient?

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 theclient know whether the GPO has changed? The answer is that the client knows by using GPOHistory.

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 isstored both a per-user and per-computer basis, corresponding to the fact that GPOs have bothcomputer- and user-specific parts. The per-computer history can be found in theHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group

Policy\History subkey. And the per-user history is in the corresponding key inHKEY_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 tothe various client-side extensions (CSEs) that implement policy on a given machine. You cancross-reference these CSE GUIDs to the actual policy function they provide by looking in theHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions subkey. Under each GUID-named key is thenumerically named subkeys that correspond to each GPO that the computer or user has processedfor 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 detailabout 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 GPOwas linked to when it was processed. The number 4 corresponds to an OU-linked GPO. Anumber 1 in this value corresponds to the local GPO, 2 to a site-linked GPO, and 3 to adomain-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 forthis GPO.

160



Chapter 7

• The Version value shows the current version of this GPO. This is the version numberstored in the GPT and GPC, not the number of revisions on the GPO. This versionnumber is key because it helps the user or computer know whether the GPO has changedon 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 notonly in determining whether a GPO has changed from the last processing cycle, but also inhelping 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 tofilter Group Policy Objects using a Windows ManagementInstrumentation 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 theability to dynamically filter GPO effect based on WMI parameters such as hardwareconfiguration, software configuration, and so on.

WMI is a set of management providers that ships in Windows 2000 (Win2K) and Windows XPthat provides very detailed management information about your Windows systems. WMI isMicrosoft’s implementation of the Web-Based Enterprise Management (WBEM) initiativecreated by the Desktop Management Task Force (DMTF). The ability to filter the effects of aGroup 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 editoron a Windows .NET Server, you will see a new tab on the GPO’s properties page—called WMIFilter (see Figure 7.20). This tab lets you select a WMI Query Language (WQL)-based query toassociate 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 showsan 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 thisGPO as a result of the query filter. The format of the query that Figure 7.21 shows is a standardWQL query (SELECT * from Win32_TimeZone WHERE StandardName=”Pacific StandardTime”), 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 arelikely to perform will use the CIMv2 namespace.

Although a full discussion of WMI and WQL are beyond the scope of this book, an excellent resourcefor 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 thecomputer 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 whichyou really need to filter a GPO based on a parameter specific to the computer that can’t berepresented 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 domaincontrollers?

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 arereplicated to all domain controllers in your Active Directory (AD) domain on separatereplication mechanisms. Thus, if a GPO gets out of sync, it will not be processed by a computeror 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 acommand-line tool called GPOTool.exe that verifies the consistency of one or more GPOs withinyour domain across all domain controllers. Suppose I want to determine whether a GPO calledHQ Lockdown Policy on a particular domain controller called YQUEM is in sync. I can issue thefollowing 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 DSversion for directory service in the figure) and the GPT (referred to as Sysvol version). In somecases, version mismatch problems may point to a problem with either AD or SYSVOLreplication. If GPOTool shows a version-mismatch problem, check the System and DirectoryServices 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 morewidespread.

Replmon.exe

In addition to GPOTool, the Win2K and Windows XP Support Tools contains a GUI-based toolcalled 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 statuson a per-domain controller basis. Follow these steps to check GPO replication status on a domaincontroller:

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, andselect 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 islocated, 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 thedomain 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 windowsimilar 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 GPCand GPT are out of sync. You can also see that they’re out of sync to the right—the versionnumbers are different (the Version column represents the GPC and the SysVol Version columnrepresents the GPT).

Replmon is a good tool for giving you a view of all GPOs on a given domain controller. You canalso add domain controllers to the Replmon monitor list, and view GPO status across manydomain 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 GroupPolicy 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 entriescreated by this logging to determine where problems are occurring in your GPO processinginfrastructure.

The key to using GPO event logging is to know how to read the entries that are generated. Whena computer starts up, in the Application event log, you will see a number of entries that have asource of Userenv. These entries represent one of the main sources for GPO processing. You cantrace 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 (seeFigure 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.5shows the step in which the computer has identified all GPOs to which it is subject (including thelocal 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, whenentries are generated to describe exactly what’s happening during the processing cycle. Forexample, in Figure 8.6, the computer has checked the GPOs it must process and has found thatnone of them have changed since the last time they were processed. Therefore, the computersimply 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 processingevents. 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 runninglogon 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 tothe effect of The operation generated error # xx and returned flags # yy. These messages mightseem cryptic and not very well defined, but they indeed correspond to real error codes inWindows. Specifically, the error codes correspond to Win32 error codes, which you can find inthe Microsoft Platform software development kit (SDK) in a file called winerr.h or you can findthem 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 afile called userenv.h. Fortunately, as Figure 8.8 shows, Windows XP does a much better job ofdetailing the errors behind the error codes and flags than Win2K does.

169

http://www.microsoft.com/windows2000/techinfo/reskit/ErrorandEventMessages/default.asp

http://www.microsoft.com/windows2000/techinfo/reskit/ErrorandEventMessages/default.asp



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 whysomething isn’t working in GPO processing. However, interestingly, Windows XP marks all theGPO-related event log processing entries as error messages, rather than just informationalmessages in the event logs. This classification can be disconcerting when you start looking at theevent logs and see a sea of red x’s. Just be aware that when you open the message, it might ormight not be a critical error worthy of concern.

Q 8.3: What is the best way to determine whether security policy isbeing delivered to a workstation or server?

A: The answer to this question depends to some degree upon whether you’re using Windows2000 (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 usesome built-in tools to determine which are your effective security settings on a workstation orserver, 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 viewsecurity 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 localsettings, 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 tosee which GPO is delivering which security policy, you really need to look to third-party toolssuch as FullArmor’s FAZAM 2000.

However, in Windows XP, the story gets a bit better. The gpresult.exe command-line tool thatcomes with Windows XP has the ability to resolve security settings (the Win2K version doesnot) and the Resultant Set of Policy (RSoP) MMC snap-in tool (stored as rspop.msc) that comeswith Windows XP also has the ability to view effective security settings. Of course, in WindowsXP, you can still look at the local GPO to see the current effective security at the workstation orserver.

171



Chapter 8

Q 8.4: How can I determine whether Domain Name System problemsare 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 determinewhether DNS is causing your problems. Correct GPO processing relies on the ability for aWindows 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 DirectoryAccess Protocol (LDAP) to determine where GPOs are linked in AD’s hierarchy and where theGroup 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 isused to query for the SRV record called _ldap._tcp.<sitename>._sites.dc._msdcs.<domainname>, where <sitename> is the name of thesite the workstation resides in and <domainname> is the name of the AD domain where thatmachines 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 processingoccurring. The confounding thing about this problem is that it is still possible for the user tosuccessfully authenticate to the domain and logon as if there were no problems. Such usuallyoccurs in domains in which NetBIOS over TCP/IP (NetBT) is still enabled and the WindowsInternet Naming Service (WINS) is still in use. Although DNS is not working correctly, theworkstation 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 thedomain controllers in your AD domain are not correctly registering all their SRV records withDNS. 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 thisregistration does not happen, and in that case, the records are never found. If that turns out to bea 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 appropriateSRV records in DNS.

Check out the Microsoft article “SRV Records Missing After Implementing Active Directory andDomain 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 tocontact DNS or may be contacting the wrong DNS servers. There could be several reasons forthis behavior, including network problems, bad DNS client configurations, or an incorrect DNSserver configuration. In any case, you can easily troubleshoot the problem by using the nslookuputility.

172



Chapter 8

Like its UNIX counterpart, nslookup is an important tool for validating DNS client operation. Tocheck whether a client is successfully finding the key SRV record needed for proper GPOoperation, simply start nslookup by typing

nslookup

at a command prompt. When you reach the nslookup shell, you need only type the name you’retrying to resolve and, if successful, nslookup returns the IP address for the name (see Figure8.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 theserver or to the client’s configuration to resolve the problem.

Q 8.5: Why am I having trouble enabling security policy such asauditing 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-widesecurity 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 canset other account policy for member servers elsewhere in your AD infrastructure, but domaincontrollers 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 DomainControllers 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 DomainControllers 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 anyGPO 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 willsave yourself a lot of troubleshooting time trying to figure out why you’re domain controllersdon’t have auditing enabled by setting auditing policy on a GPO linked to the DomainControllers OU.

You might think that you can simply disable the Block Policy Inheritance option on the DomainControllers OU to allow security policy to be set elsewhere. In fact, you can’t! If you disable thisoption, 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 loggingenabled will show).

This feature prevents any “rogue” GPOs upstream from the Domain Controllers OU fromundoing 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 isthat none of your upstream policies seem to be applied.

174





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 aGPO. By removing this permission, you effectively prevent all users from being able to read, andthus process a GPO. A user receiving an inaccessible error message can sometimes be a goodthing. For example, if the GPO controls security on your domain, you probably don’t want a useraccount that doesn’t process machine-specific security GPO in the first place to even be able tosee 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 asimple 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 messagethat 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 GroupPolicy when Microsoft File and Print Sharing has been disabled on the PDC role holder in yourdomain. 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 MicrosoftManagement Console (MMC) snap-in tries to connect to the PDC emulator within your ADdomain first when opening a GPO. If File and Print Sharing services are not running on the PDCrole 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 errormessage, 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 youtry to view the GPOs in your domain from that Active Directory Users and Computers MMCsnap-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 areenabled 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 Connectionapplet, choose Properties from the context menu, and make sure that the File and Printer Sharingfor 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 editGPOs. The interesting part of this problem is that, with this service disabled, you can’t evenconnect 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 itpossible to get more in-depth troubleshooting information than thatprovided 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 iswritten to the Application event log or %systemroot%\debug\usermode\userenv.log. To enableverbose security policy logging, you will need to add a value to the registry. Fire up regedit.exeor regedt32.exe and navigate toHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions\{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