M6345C 002

Deploying Group Policy
for Windows 2000, 2003,

and XP Clients
M6345C-002
November 2003
Blank
Deploying Group Policy for Windows
2000, 2003, and XP Clients
M6345C-002
November 2003
Copyright Information
Copyright 2006, 2003 by Global Knowledge Training LLC
First published 2003.
The following publication, Deploying Group Policy for Windows 2000, 2003, and XP Clients, was developed
by 3377831 CANADA, Inc. in cooperation with Global Knowledge Training LLC. All rights reserved. No
part of this publication may be reproduced or distributed in any form or by any means without the prior written
permission of the copyright holder.
This courseware may contain licensed images from the following sources: Corel Corporation, Corel Gallery;
Broderbund Company, ClickArt 200,000; Nova Development Corporation, Art Explosion 125,000.
Products and company names are the trademarks, registered trademarks, and service marks of their respective
owners. Throughout this manual, Global Knowledge has used its best efforts to distinguish proprietary
trademarks from descriptive names by following the capitalization styles used by the manufacturer.
Project Team
MARK WILKINS Course Director
NANCY DUNHAM Director, Content Development, Instructor-Led Training
KARIN GRODEN Project Manager, Content Development
JOHN VOORHEES Vice President, Proprietary and Partner Products
NINA KNIERIM Product Manager, IT Foundations
9000 Regency Parkway

Cary, North Carolina 27511
Phone: 919-461-8600
1-800-COURSES
Fax: 919-461-8646
www.globalknowledge.com Printed in Canada
Welcome!
Thank you for selecting Global Knowledge as your training provider. We offer more than
700 courses including manufacturer certifications for Cisco, Microsoft, Nortel, and Red
Hat as well as internetworking, telecommunications, and project management training.
Through our combination of instructor-led and self-paced learning delivery methods, you
can determine when, where, and how you want to receive your training.
Certification and Career Paths

For more information on certification and additional courses that can help you achieve
your career goals, please visit our Web site at http://www.globalknowledge.com.
Deploying Group Policy for Windows 2000, 2003, and XP Clients v

Global Knowledge Training LLC
About This Course
Course Objectives
As features of Windows 2000 Server begin to mature, now is the time to get up to speed
on Windows Server 2003. Discover how to migrate systems policies to Windows 2003
Group Policies. Our course will introduce you to new aspects of Active Directory and
Group Policy using profiles and Intellimirror.
Hands-on labs will show you how to design and deploy security policies for all your
Windows 2000 and Windows 2003 servers, workstations, member servers, and Windows
XP clients.
After completing this course, you will be able to:

- Distribute applications and anti-virus updates to large groups
of users
- Design and deploy security policies for all your Windows 2000/
2003 servers, workstations, member servers, and XP clients
- Change Registry permissions on client computers in seconds
- Enable Roaming Profiles for help desk and support personnel to
seamlessly roam from computer to computer and still maintain
their desktop
- Allow users to access important file and folder resources offline
just as if they were online
- Quickly restore a Windows XP computer in minutes by using RIS
- Migrate from 98/NT 4.0 System Policies to Windows 2003
Group Policies
- Roll out selected software updates and operating system patches
from your network environment and not using Windows Update
across the public Internet
vi Deploying Group Policy for Windows 2000, 2003, and XP Clients

Font Conventions Used in This Course Manual
Different fonts and font styles signify different items or tasks. The following is a key to
font usage.
Font Item or task Example

Commands, directory paths, The dir command
folders, file names, Web and c:\winnt\system
e-mail addresses, registry keys, notepad.exe
icons, and anything you would am.globalknowledge.com
Bold YesNoDialog is a subclass of Object,
see in a command line or when
programming not Dialog.
Text that can be manipulated in Check the Write the event to a
windows or dialog boxes system log box.
ALL CAPS Key names CTRL+ALT+DELETE (Press the

CTRL, ALT, and DELETE keys
simultaneously)
Messages SYN/ACK message
CALL PROCEEDING message
Courier New Computer-generated text Input a valid user id
and password.
Courier New bold Code or commands not in text <h1>Global Knowledge</h1>

flow or tables that are entered $ show cluster /continuous
by the user
Italic Placeholder variables $ more [file1 [file2...]]
The example runs cmd2 if cmd1
returns success.
Deploying Group Policy for Windows 2000, 2003, and XP Clients vii
viii Deploying Group Policy for Windows 2000, 2003, and XP Clients
Table of Contents
1 Group Policy Essentials
Section Topics ...................................................................................................1-1
Section Objectives .............................................................................................1-2
Section Overview ...............................................................................................1-2
The Philosophy of IntelliMirror ...........................................................................1-3
Active Directory Framework ........................................................................1-5
Software Packages and the Windows Installer .........................................1-11
Folder Redirection .....................................................................................1-12
Offline Files and Folders ...........................................................................1-14
Roaming User Profiles ..............................................................................1-15
Distributed File Shares ..............................................................................1-16
Remote Installation Services .....................................................................1-17
Versions of Group Policy .................................................................................1-18
Windows 2000 Interface ............................................................................1-19
Windows XP and Windows 2003 Interface ...............................................1-21
Which Clients and Servers Can Deploy Group Policy? ............................1-23
Group Policy Architecture ................................................................................1-24
The Secedit Database ...............................................................................1-24
Local Group Policy ....................................................................................1-25
Network Group Policy (Domain, OU, Site) ................................................1-26
Registry Locations .....................................................................................1-26
Group Policy Deployment ................................................................................1-27
Deployment Rules .....................................................................................1-27
Deployment Options ..................................................................................1-29
Block Policy Inheritance ............................................................................1-30
Filtering with Security Groups ...................................................................1-32
Delegation of Group Policy .......................................................................1-33
Section Summary ............................................................................................1-34
Section Review ................................................................................................1-35
Deploying Group Policy for Windows 2000, 2003, and XP Clients TOC-1
Global Knowledge Network, Inc.
2 Designing Group Policy Infrastructure
Section Topics ...................................................................................................2-1
Implementing Group Policy ...............................................................................2-3
Planning Your Group Policy Design ............................................................2-3
Designing Your Group Policy Solution .......................................................2-6
Applying Group Policy Changes ...............................................................2-12
Default Rights for Group Policy Management ...........................................2-22
Delegating Administration of Group Policy ......................................................2-26
GPO Delegation ........................................................................................2-27
Manually Assigning Permissions ...............................................................2-29
Specifying a Domain Controller for Editing Group Policy ..........................2-31
Using Loopback Processing ......................................................................2-33
Using Group Policy Inheritance .................................................................2-35
Rolling Back Domain GPOs ......................................................................2-37
Section Summary ............................................................................................2-38
Section Review ................................................................................................2-39
3 Testing and Piloting Group Policy

Section Topics ...................................................................................................3-1
Group Policy Staging: Overview ........................................................................3-3
Creating Your Staging Environment ............................................................3-4
Slow Network Links .....................................................................................3-4
Preparing the Staging Environment ............................................................3-4
VMware .......................................................................................................3-4
Testing Group Policy in the Staging Environment .......................................3-5
Logging On as a Test User .........................................................................3-5
Using Group Policy Modeling ......................................................................3-6
Using Group Policy Results ........................................................................3-6
Using Group Policy Modeling to Simulate Resultant Set of Policy ..............3-7
TOC-2 Deploying Group Policy for Windows 2000, 2003, and XP Clients
Migrating Group Policy ................................................................................3-8
Creating Lockdown Desktops ..........................................................................3-10
Lightly Managed Desktop ..........................................................................3-12
Mobile User ...............................................................................................3-13
Multi User Desktop ....................................................................................3-15
App Station (Highly Managed Desktop) ....................................................3-16
Task Station ..............................................................................................3-17
Kiosk .........................................................................................................3-18
Comparison of Features Used in Each Scenario ............................................3-19
Section Summary ............................................................................................3-20
Section Review ................................................................................................3-21
4 Deploying Security Templates

Section Topics ...................................................................................................4-1
Security Architecture .........................................................................................4-3
Security Principals .......................................................................................4-3
Access Control Lists ....................................................................................4-4
Security Groups ..........................................................................................4-4
NTUSER.DAT: The User Profile .................................................................4-5
The Registry ................................................................................................4-7
The Secedit Database .......................................................................................4-9
Security Templates ...................................................................................4-11
Using the Security Configuration and Analysis MMC ................................4-18
Using Secedit ............................................................................................4-23
Using Gpupdate ........................................................................................4-27
Customizing Security Templates .....................................................................4-28
Hardening Computer Accounts .................................................................4-30
Account Policy: Password Policy ..............................................................4-32
Security Options ........................................................................................4-38
Audit and Device Settings .........................................................................4-40
Interactive Logon Security Options ...........................................................4-42
Miscellaneous Security Settings ...............................................................4-44
User Rights Assignments ..........................................................................4-45
Microsoft Baseline Security Analyzer ..............................................................4-48
Section Summary ............................................................................................4-50
Section Review ................................................................................................4-51
5 Network Security Using Group Policy

Section Topics ...................................................................................................5-1
Deploying Member Server Security ...................................................................5-3
Member Server Baseline Policy ..................................................................5-4
OU Infrastructure Example ..........................................................................5-5
OU Infrastructure Checklist .........................................................................5-6
Domain Security ................................................................................................5-8
Deploying Domain Security .........................................................................5-9
Importing Domain Security ........................................................................5-10
Controlling File Security through the ACL .................................................5-11
Updating Registry Security Using ACLs ....................................................5-12
Controlling Network Services with Group Policy .............................................5-13
Public Key Polices .....................................................................................5-14
Enforcing an Audit Policy .................................................................................5-16
Account Logon Events ..............................................................................5-17
Account Management ...............................................................................5-18
Directory Service Access ..........................................................................5-19
Logon Events ............................................................................................5-19
Object Access ...........................................................................................5-20
Policy Change ...........................................................................................5-21
Privilege Use .............................................................................................5-22
Restricting Security Group Membership ..........................................................5-23
Restrictive Groups .....................................................................................5-24
Using Scripts ...................................................................................................5-25
Computer Startup Scripts ..........................................................................5-25
Computer Shutdown Scripts .....................................................................5-25
User Startup and Shutdown Scripts ..........................................................5-26
Processing Order ......................................................................................5-26
Managing Printers: Printer Pruning .................................................................5-28
Printer Location Tracking ..........................................................................5-28
Section Summary ............................................................................................5-29
Section Review ................................................................................................5-30
6 Explorer Shell Group Policy

Section Topics ...................................................................................................6-1
Scripts for Clients ..............................................................................................6-3
Startup and Shutdown Scripts .....................................................................6-3
Logon and Logoff Scripts ............................................................................6-5
Script Control: MMC ....................................................................................6-6
Script Control: System ................................................................................6-7
Desktop, Start Menu, and Taskbar Control .......................................................6-8
Desktop Restrictions ...................................................................................6-8
Start Menu Restrictions .............................................................................6-10
Taskbar Restrictions .................................................................................6-12
Control Panel Control ......................................................................................6-13
Top-Level Controls ....................................................................................6-13
Add/Remove Programs .............................................................................6-14
Display Control ..........................................................................................6-15
Printer Control ...........................................................................................6-16
Regional and Language Options ...............................................................6-16
Windows Components .....................................................................................6-17
Windows Explorer .....................................................................................6-17
Internet Explorer ........................................................................................6-21
Terminal Services .....................................................................................6-32
Other Windows Components ....................................................................6-33
Controlling User Profiles ..................................................................................6-34
Disabling Roaming Profiles .......................................................................6-34
Size (Quotas) ............................................................................................6-35
Folders ......................................................................................................6-36
Slow Links .................................................................................................6-37
Folder Redirection ...........................................................................................6-39
Printer Management and Pruning ....................................................................6-42
Pruning ......................................................................................................6-42
Publishing ..................................................................................................6-43
Computer Network Settings .............................................................................6-44
DNS Client ................................................................................................6-44
Offline Files ...............................................................................................6-45
Network Connections ................................................................................6-46
Section Summary ............................................................................................6-47
Section Review ................................................................................................6-48
7 Group Policy and Remote Access

Section Topics ...................................................................................................7-1
Remote Access Policy: The Same, Only Different ............................................7-3
Comparing Group Policy and RRAS or IAS Policy .....................................7-3
Overview of Remote Access Security .........................................................7-3
How the Three Parts Interact ....................................................................7-10
Creating a Custom Remote Access Policy ......................................................7-12
RRAS Authentication Problems in Mixed Networks ..................................7-13
Policy Processing over Slow Links ............................................................7-14
Remote Users and Offline Files and Folders ............................................7-19
Section Summary ............................................................................................7-23
Section Review ................................................................................................7-24
8 Assigning and Publishing Software Packages

Section Topics ...................................................................................................8-1
What Is an MSI Package? .................................................................................8-3
Background of the Problem .........................................................................8-3
Why Installation Routines Matter ................................................................8-5
Elements of a Solution ................................................................................8-5
MSI Package Architecture .................................................................................8-6
Elements of a Package ...............................................................................8-8
What Is a Transform? ..................................................................................8-9
Relationship to Group Policy .....................................................................8-11
Group Policy as a Software Deployment Method ............................................8-12
Pros and Cons of Policy-Based Software Deployment .............................8-12
Requirements for Distributing Software via Group Policy .........................8-12
Options for Policy-Based Deployment ......................................................8-13
Assigning Software ..........................................................................................8-14
Assigning Software to Computers .............................................................8-15
Assigning Software to Users .....................................................................8-18
Assigning Software to Users on Demand .................................................8-19
Publishing Software to Users ..........................................................................8-21
Upgrading Packages .......................................................................................8-22
Removing Packages ........................................................................................8-23
Using WinInstall to Create MSI Packages .......................................................8-24
Building (Authoring) an MSI Package .......................................................8-24
Repackaging an Application ......................................................................8-27
Setting up Distribution Points ..........................................................................8-29
Specify a Network Location .......................................................................8-29
Take Advantage of Sites ...........................................................................8-31
Slow Link Behavior ....................................................................................8-31
Dfs Shares ................................................................................................8-32
SMS and RIS ...................................................................................................8-33
Systems Management Server ...................................................................8-33
Remote Installation Service ......................................................................8-34
Using the Software Update Service .................................................................8-35
System Requirements and Limitations ......................................................8-35
Server and Client SUS Components .........................................................8-36
Deploying and Configuring the SUS Server ..............................................8-37
Section Summary ............................................................................................8-41
Section Review ................................................................................................8-42
9 Creating and Deploying ADM Templates
Section Topics ...................................................................................................9-1
Overview of ADM Templates .............................................................................9-3
What Are Administrative Templates Nodes? ..............................................9-3
What's in an ADM File? ...............................................................................9-5
Why Have ADM Files at All? .......................................................................9-7
Standard ADM Templates .................................................................................9-8
Windows 2000 .............................................................................................9-9
Windows XP ..............................................................................................9-10
Windows 2003 ...........................................................................................9-11
Poledit Templates .....................................................................................9-12
Office ADM Templates ..............................................................................9-13
Registry Structure Used by ADM Templates ...................................................9-17
Machine vs. User ......................................................................................9-17
True Policies vs. Preferences ...................................................................9-17
ADM Template Syntax .....................................................................................9-18
CLASS ......................................................................................................9-19
CATEGORY ..............................................................................................9-20
POLICY .....................................................................................................9-21
KEYNAME .................................................................................................9-21
VALUENAME ............................................................................................9-22
PART .........................................................................................................9-22
EXPLAIN ...................................................................................................9-23
SUPPORTED ............................................................................................9-24
STRINGS ..................................................................................................9-24
Creating Custom ADM Templates ...................................................................9-25
Programming Tips .....................................................................................9-25
A Simple Example .....................................................................................9-25
Loading Additional ADM Templates ................................................................9-29
Using the Policy Template Editor ....................................................................9-31
Section Summary ............................................................................................9-32
Section Review ................................................................................................9-33
10 Software Restriction Policies
Section Topics .................................................................................................10-1
Section Objectives ...........................................................................................10-2
Section Overview .............................................................................................10-2
What Is a Software Restriction Policy? ............................................................10-3
Who Can Use a Software Restriction Policy? ...........................................10-4
Software Restriction Components .............................................................10-4
Software Restriction Policy Architecture ...................................................10-5
How to Create a Software Restriction Policy ...................................................10-7
Creating Policy for a Local Computer .......................................................10-8
Creating Policy for a Domain-Based Computer ........................................10-8
Creating Policy for a Site ...........................................................................10-8
Software Restriction Policy Options ................................................................10-9
DLL Checking ..........................................................................................10-10
Skip Administrators .................................................................................10-10
Selecting Executables to Protect ............................................................10-11
Trusted Publishers ..................................................................................10-12
Default Security Levels and Exceptions ..................................................10-13
Additional Rules to Identify Software .............................................................10-15
The Hash Rule ........................................................................................10-17
The Certificate Rule ................................................................................10-19
The Path Rule .........................................................................................10-20
Registry Path Rules ................................................................................10-22
The Internet Zone Rule ...........................................................................10-23
Software Rules Precedence ..........................................................................10-24
Process 1 ................................................................................................10-25
Process 2 ................................................................................................10-25
Creating an Effective Software Restriction Policy .........................................10-26
Deployment Summary ...................................................................................10-28
Multiple User or Machine Policies ...........................................................10-28
Merging Machine and User Policy ..........................................................10-28
Section Summary ..........................................................................................10-29
Section Review ..............................................................................................10-30
11 Troubleshooting Group Policy
Section Topics .................................................................................................11-1
Group Policy Infrastructure ..............................................................................11-3
The Sysvol Folder .....................................................................................11-4
The PDC Emulator ....................................................................................11-6
FRS Replication ...............................................................................................11-8
Client-Side Extensions ....................................................................................11-9
Registry Client-Side Extensions ................................................................11-9
GPO Structure ...............................................................................................11-10
The Group Policy Container ....................................................................11-11
The Group Policy Template ....................................................................11-12
GPO Versioning ......................................................................................11-13
Processing Details ..................................................................................11-14
Group Policy Deployment Order ....................................................................11-15
Local Computer System ..........................................................................11-16
Site GPOs ...............................................................................................11-16
Domain GPOs .........................................................................................11-17
Organizational Unit ..................................................................................11-17
Group Policy Processing .........................................................................11-18
Using Command-Line Tools ..........................................................................11-19
Using Gpresult ........................................................................................11-19
Using Gpotool .........................................................................................11-22
Using Gpupdate ......................................................................................11-24
Using ReplMon ........................................................................................11-26
Analyzing Policy Deployment ........................................................................11-29
Using RSoP .............................................................................................11-29
Using the Windows XP Help and Support Center .........................................11-31
Enabling Group Policy Logging: the userenv.log File ....................................11-32
Tips for Troubleshooting Group Policy ..........................................................11-34
Custom Views of Administration Templates ..................................................11-36
Enabling the Administrative Tools Filter ..................................................11-37
Using the Event Logs ....................................................................................11-38
Verbose GPO Logging ............................................................................11-38
Using Gpmonitor ............................................................................................11-39
Why Is My Policy Still Not Working? ..............................................................11-40
Section Summary ..........................................................................................11-41
Section Review ..............................................................................................11-42
12 Using the Group Policy Management Console

Section Topics .................................................................................................12-1
What Is the GPMC? .........................................................................................12-3
The Problem ..............................................................................................12-3
The GPMC Solution ..................................................................................12-4
What the GPMC Is Not ..............................................................................12-4
Installing the GPMC .........................................................................................12-5
Installation Requirements ..........................................................................12-6
Running the Console .................................................................................12-7
Configuring the Console ............................................................................12-8
Version 1.0 Syndrome ...............................................................................12-9
Backing Up and Restoring GPOs ..................................................................12-10
Backing Up ..............................................................................................12-10
Restoring .................................................................................................12-14
Importing GPOs .............................................................................................12-16
Reasons for Importing GPOs ..................................................................12-17
Procedure for Importing GPOs ................................................................12-17
Copying GPOs ...............................................................................................12-18
Requirements ..........................................................................................12-18
Migration Tables ......................................................................................12-19
Searching for Existing GPOs .........................................................................12-22
Integration of RSoP Functionality ..................................................................12-25
Group Policy Results ...............................................................................12-26
Group Policy Modeling ............................................................................12-28
Report GPO Settings and RSoP Data ....................................................12-29
WMI Filters ....................................................................................................12-31
Restrictions .............................................................................................12-32
Creating WMI Filters ...............................................................................12-33
Linking a WMI Filter to a GPO ................................................................12-35
Section Summary ..........................................................................................12-36
Section Review ..............................................................................................12-37
Group Policy Essentials
Section Topics
The Philosophy of IntelliMirror
Versions of Group Policy
Group Policy Architecture
Group Policy Deployment
Deploying Group Policy for Windows 2000, 2003, and XP Clients 1-1
N Knowledge
Guide
W E
Section Objectives
S
After completing this section, you will be able to:

Describe the various facets of IntelliMirror
Describe the basic architecture of Active Directory
Explain how technologies based on Group Policy execute the IntelliMirror
strategy
Describe the mechanics of Group Policy architecture
List the basic rules of Group Policy deployment
Understand security group filtering
Section Overview
This section introduces the IntelliMirror concept: basically, that users should be able to
work with the data and programs they need, when and where they need them. It also
discusses how Group Policy functions as a key facilitator of that enterprise computing
strategy.
1-2 Deploying Group Policy for Windows 2000, 2003, and XP Clients
The Philosophy of IntelliMirror

IntelliMirror, much like the ubiquitous dot Net, is one of those Microsoft trademark
buzzwords that never really connected with IT professionals because of the following
reasons:
It was incredibly broad
Microsoft defined it in different ways at different times
However, here is an attempt at a definition:
IntelliMirror is an umbrella term covering the set of operating system
capabilities which, when properly configured by administrators, permit users
to access the data and programs and preferences they need, with the custom
user interface and security settings that they and their administrators have
chosen, anywhere and anytime they need them - on any PC, whether
connected to the network or not, whether connected to a particular network
segment or not - based on the users identities, and to do so in a fault-tolerant
manner with disaster recovery capabilities and centralized management.
Or, less formally, and more concisely:
IntelliMirror describes all the ways that what you need from your computer
follows you around.
Is this important? In many organizations, it is. Some of the reasons are:
Many users have laptops as their primary computers.
Many users work at the office, at customer sites, and at home.
The more consistent the user interface is, the less training and support is
required.
The more consistently security features are applied, the more reliable the
user environment becomes.
The more consistent the user interface and security environment can be, the
easier (and less expensive) troubleshooting becomes.
The more automatic this consistency can be, the less time technicians must
spend manually ensuring it.
The more disaster recovery procedures can be standardized, the quicker the
MTTR can be.
Notes The rest of this topic takes a brief look at the components of this
overarching philosophy called Intellimirror, and then
subsequent topics in this section focus on the part of Intellimirror
that we are concerned with in this course: Group Policy, the tool
that network administrators use to implement many IntelliMirror
features.
Helpful Hint
Think of Group Policy and Active Directory as the tactical

implementation of the IntelliMirror strategy, and you will have a
clearer understanding of both these terms.
Active Directory Framework
Where am I?
And wheres
my stuff?
Figure 1: Active Directory Framework
If, according to the preceding definition of IntelliMirror, IntelliMirror means that what
you see when you work on a given computer depends on your identity, then with Windows
2000 and higher versions of the operating system, your identity is determined by where
you and your computer exist within the framework of the Microsoft enterprise directory
service, Active Directory. (Additionally, your identity is determined by your membership
in security groups, which of course were around prior to Active Directory.)
Conversely, if IntelliMirror means that you can get to whichever files, programs, and
network services you need, then the location of those resources is also determined by
where they exist within the context of Active Directory.
Note
Active Directory is the primary way that a Windows network determines who you are,
where you are, and where everything you need is. Therefore, a basic understanding of
Active Directory is necessary to understand the IntelliMirror strategy and its primary
enabling technology, Group Policy.
Real-World Application
Computers that do not fully support Active Directory (that is, Windows 95, Windows 98, and
Windows NT 4.0) do not benefit from all aspects of IntelliMirror, even though the
downloadable Active Directory client may let them participate in Active Directory to a
limited extent.
The main components of Active Directory are:

Domains
Organizational units
Trees
Forests
Trusts
Sites
Each of these main components is surprisingly simple when broken down to the essentials.
Domains
A domain is the primary partition of Active Directory and defines a security boundary
within the organization. Every member of the domain, for example, has the same
password settings (minimum length, complexity, etc.). Domain controllers are servers that
authenticate users to the domain, maintain information about all the directory objects in
the domain, and exchange that information with each other for reasons of performance and
fault tolerance.
Beyond merely defining a security boundary, the domain also typically defines a broad
usage boundary. That is, users within a particular domain are most likely to use resources
that are also defined within that domain. While Active Directory permits users to access
resources outside their domain through the mechanism of trusts, such access can carry
significant performance penalties (although less so than in the past, thanks partly to
Kerberos authentication technology).
Windows 2000 family networks using Active Directory may be able to function
effectively with fewer domains than Windows NT 4.0 networks, largely due to a new
construct called the organizational unit. In fact, many Active Directory environments for
small and medium-sized organizations consist of a single domain. Such a model has great
appeal from the standpoint of administrative overhead.
Create a new domain by promoting a Windows 2000 or 2003 Server computer to be a

domain controller using the dcpromo command.
Organizational Units
Although they are new to the Microsoft network world, organizational units, or OUs, have
been around in the NetWare world for years. They add great flexibility to your network
design and facilitate the collapsing of domains.
If a domain is a security and usage boundary, then an OU is an administrative boundary.
Users generally are aware of what domain they are in, but they may have no idea as to
what OU they are in. The OU is there for the administrator, to make his life easier by
permitting two activities:
The delegation of control
The application of Group Policy
In fact, the OU is the smallest unit that can be delegated or assigned Group Policy.
OUs are containers: they can contain users, groups, computers, and other OUs (although
you should avoid nesting OUs too many levels deep to avoid unnecessary complexity). At
the same time, an OU is itself contained inside a domain. OUs cannot span domains, that
is, they cannot contain objects outside their own domains.
Users do not authenticate to an OU; they authenticate to a domain. But a network manager
can delegate authority for an OU to a particular security group or even to a specific
individual. A network manager can also apply Group Policy objects to OUs independently
from each other.
So, for example, a network manager who wants everyone in the Sales OU to have a
particular application but nobody in the Engineering OU to have that same application,
can deploy the program via Group Policy to the Sales OU but not the Engineering OU.
Active Directory Users and Computers
Figure 2: Creating an OU in the Active Directory Users and Computers Console
This utility, which takes the place of the old User Manager and Server Manager tools in
Windows NT 4.0, is present on Windows 2000 Server and Windows 2003 Server
computers that have been promoted to domain controllers. You can install Active
Directory Users and Computers, as well as the other Active Directory consoles, onto a
Windows 2000 or Windows XP Professional workstation via adminpak.msi, the
Administrative Tools Pack.
Note
There are different versions for Windows 2000 and Windows XP.
This software also embodies IntelliMirror philosophy in that you can administer your
entire network from any workstation that you happen to be using, as long as you have the
appropriate credentials (for example, you belong to the Domain Admins group).
Trees
A tree is a collection of domains that have a contiguous DNS namespace. For example,
gk.com, sales.gk.com, and foreign.sales.gk.com would constitute a tree of three
domains.
When you build a new domain in Active Directory, you can choose whether you want it to
start a new tree or be part of an existing tree.
Forests
A forest is, as you might suspect, a collection of trees. But it is more than that. A true
forest is built from scratch. That is, rather than merging two trees that already exist, you
build a forest by creating a new tree that will join an existing forest.
All the domains in a forest share a single schema (the data structure that defines the
objects and attributes in the directory) and a single configuration (the map of the domain
structure).
Trusts
The important thing to know about trees and forests is that, by default, all the domains in a
tree or a forest trust each other, meaning that a user in one domain can possibly access a
resource in a different domain. Windows 2000 and Windows 2003 Server build automatic,
bidirectional, transitive trusts between domains, creating a full-mesh trust.
This is an important point because it means that it is possible to create Group Policy
objects in one domain and use them in a different domain, although that is something to be
avoided where possible due to performance issues.
Sites
Slow WAN link
Lan 1 Lan 2
Active Directory site: Active Directory site:
San Jose San Francisco
Figure 3: Sites
So far, we have been discussing domains, OUs, trees, and forests, and the trusts that
connect domains within trees and forests. These are all logical constructs rather than
physical ones. Active Directory has a single physical construct, the site, defined as a
collection of well-connected PCs. For example, a LAN would be likely to comprise an
Active Directory site, whereas a slow or expensive WAN link would be likely to delineate
two separate sites.
Sites are defined in the Active Directory Sites and Services console and consist of one or
more subnets defined with the usual TCP/IP network ID and mask notation. Active
Directory uses sites to help clients find domain controllers that are physically nearby.
Active Directory also uses sites to create appropriate schedules for replication of data
between domain controllers.
Software Packages and the Windows Installer
Figure 4: Software Settings Node of Group Policy
IntelliMirror says that your stuff follows you around. A big part of your stuff is the
programs that you need to run. One of the major pieces of technology that helps to ensure
that you get the programs you need is the Windows Installer service and the Software
Settings node of the Group Policy console.
In a nutshell, via Group Policy, you can:
Deploy software in a mandatory mode or one of two on-demand modes,
depending on how important it is that users and computers get the specific
application.
Set up your network so that if users remove an application, its Start menu
entries come back the next time they boot their machine.
Upgrade, patch, and remove applications, based on user and computer
locations within Active Directory.
You may need to use Microsoft SMS rather than policy-based deployment if you need
scheduling, synchronization, inventory, status reporting, or auditing capabilities, or if you
need to support down-level client operating systems.
Folder Redirection
Figure 5: Folder Redirection
Users who store data on their PCs at work always use a consistent and rapidly recoverable
procedure to back that data up on a regular basis to reliable and verified backup media.
Now that you have picked yourself up off the floor and have stopped laughing, consider
the merit of folder redirection, that is, the ability to make the My Documents folder of a
user point to a server share instead of to a folder on the local hard drive. (The redirection is
transparent to the user, except for the speed difference.) In most organizations, servers
actually do get backed up regularly, consistently, recoverably, and reliably. This is the
genius of folder redirection. It makes it feasible to restore the data files of a damaged
computer in a predictable way.
Folders that can be redirected include: Notes

My Documents (and the subfolder My Pictures)
Desktop
Application Data
Start Menu (not recommended)
Folder redirection is implemented via Group Policy (see
Figure 5). Hopefully you are beginning to see a pattern here.
Offline Files and Folders

In implementing the IntelliMirror goal of having your data follow you around, Microsoft
offers a feature called offline files and folders to let laptop users work on (or, at least, seem
to work on) network-based files even when the users are not connected to the network.
Files and folders that have been set for working offline seem to the user to be
in the same location at all times, whether the user is connected to the network
or not.
If a user has been working offline, the synchronization manager uploads any
modified files to the server when the user reconnects.
How do you set it up? The first step is to configure the Caching Settings dialog box of the
server to permit the caching of files in a given specified folder. You can then choose one of
three options:
Manual caching for documents: This option allows users pick files they want
to be available offline.
Automatic caching for documents: This option is the popular choice.
Automatic caching for programs: This option is used for applications that
you want to execute from servers.
Helpful Hint
This facility works best with server folders that are being used by one and only one user.
The reason is that Windows offers no facility for reconciling offline files when more than one
user has updated them away from the network. Manual reconciliation is difficult for users
and almost guaranteed to create problems for support staff.
Note that the offline files and folders feature does not have to be used in concert with the
folder redirection feature. However, Microsoft has suggested that doing so is not a bad
idea. The concept here would be to redirect, for example, the My Documents folders of
users to a server location, to gain the advantage of network-based backup, then make those
server locations available offline so that users can work on their data when they are
disconnected from the network.
You can use Group Policy to control various aspects of the offline files and folders feature.
Roaming User Profiles
Figure 6: Roaming User Profiles
Users do not always log on to the same PC. However, when a user logs on to a different
PC, IntelliMirror says that his stuff should follow him around, that is, his wallpaper, his
Start menu, application program preferences, and so forth. You can set up the user
account object in Active Directory to support a server-based user profile location (see
Figure 5) that will let the user roam about the network and have his profile follow him
around to whatever PC he logs on to.
You can assign network-based profile locations in Group Policy as well, which is usually
more convenient than doing it on a user-by-user basis. Additionally, you can use the
Group Policy console to control various aspects of roaming profile behavior, including
whether profiles roam across slow links, which bits and pieces of a profile roam and which
do not, and what size profiles can occupy. Here, again, Group Policy is clearly the agent
of the IntelliMirror philosophy.
Distributed File Shares
Dfs root
Folder A
Folder C
Folder B
Server East Server West

Figure 7: Distributed File Shares
Microsoft Dfs lets administrators present shared folders to users under a unified root, even
if those folders reside on physically separate servers. Like folder redirection, this, too, is
part of the IntelliMirror concept: you can organize the network so that it makes the most
logical sense to users, even if that organization does not match the actual physical layout
of files and folders.
In Figure 7, folders A, B, and C reside on different servers but appear under a single
logical share. An administrator might set this up, for example, when moving the physical
folders might be impractical.
Remote Installation Services

RIS (Remote Installation Services) is only tangentially related to Group Policy and
Microsoft does not formally call it part of IntelliMirror. Microsoft considers both RIS and
IntelliMirror to be part of something called change and configuration management.
RIS is discussed here because it embodies some of the goals of IntelliMirror, especially
the concepts of fault-tolerance and disaster recovery. With RIS, you can recover the basic
OS and application configuration of a computer by simply putting a blank hard drive in
the PC, connecting it to the network, and turning it on.
RIS comes with the server versions of Windows 2000 and Windows 2003. It requires
Active Directory, as well as DHCP and DNS and, preferably, PC hardware that is capable
of booting remotely over the network via the PXE standard.
Like the popular Symantec Ghost product, RIS allows the administrator to create one or
more images that consist of the operating system and a base set of applications together
with a base set of desktop customizations, if desired. Thanks to Plug and Play, it is not
necessary that the target hardware be identical to the hardware used to create the RIS
image (although the target hardware must use the same HAL).
When used in conjunction with IntelliMirror features like folder redirection and Group
Policy-based desktop customization, RIS lets organizations reconstitute dead PCs
relatively quickly.
Note
You cannot use RIS to upgrade an operating system.
Notes Versions of Group Policy

Although for convenience we often speak of Group Policy as
though it were a single monolithic entity, different versions of the
Group Policy technology exist, and there are different policies
that you can set depending upon which server and client
operating systems you are running in a given network:
The Group Policy console appears somewhat
differently on a Windows 2000 Server machine than
on a Windows 2003 Server machine.
Some Group Policy settings will only apply to clients
running Windows XP Professional.
In both the Windows 2000 and Windows 2003 or Windows XP
versions of Group Policy, the following points hold true about the
user interface:
You set, manage, and modify GPOs using an MMC
interface.
The structure of the GPO appears in the left pane
(policy pane) and individual settings appear in the
right pane (details pane).
Windows 2000 Interface
Figure 8: Windows 2000 Interface
You can view and modify Group Policy settings using the Group Policy snap-in to the
MMC console, typically abbreviated as the Group Policy console.
The usual way to open a network-based policy console is to open the relevant Active
Directory utility (for example, Active Directory Users and Computers), right-click the
object of interest (domain or OU), choose Properties, click the Group Policy tab, and
click the Edit button.
An alternative method is to run mmc.exe and load the Group Policy snap-in to the
console. If you use this method, you can specify the focus of the Group Policy (see
Figure 8) when you add the Group Policy standalone snap-in.
Notes When the console is open, you will see the tree pane (policy
pane) to the left and the details pane to the right.
Expand the various nodes in the policy hierarchy by
clicking the plus (+) sign next to them.
Click a node in the left pane to display the possible
policy choices in the right (details) pane.
To view or change a policy setting, double-click the
setting in the details pane to open its property sheet.
Click the Explain tab, if present, to view additional
details about the policy setting.
Windows XP and Windows 2003 Interface
Figure 9: Windows XP and Windows 2003 Interface
The Group Policy MMC console evolved somewhat with the introduction of Windows XP
Professional, and, like many other aspects of the Windows XP user interface, those
changes found their way into Windows 2003 Server as well.
The first evolution, for administrators with wide displays, is the relocation of the
explanation text to a central column (see Figure 9). You can return to the Windows 2000
view by clicking the Standard tab at the bottom of the details pane.
The second big improvement is the Supported on compatibility information at the
bottom of the Setting tab in the property sheet of any specific policy. This information
identifies the minimum operating system level necessary to support the given policy
setting.
Notes
Figure 10: Compatibility Information
Note
Another user interface is the Group Policy Management Console.

It runs on Windows XP and Windows 2003 Server but was not
released on the distribution media for those operating systems.
GPMC is very nearly a one-stop shop for policy management.
Which Clients and Servers Can Deploy Notes
Group Policy?
Group Policy is a Windows 2000-family technology. That is to
say, the following clients and servers can participate in Group
Policy deployment:
Windows 2000 Professional
Windows XP Professional
Windows 2000 Server
Windows 2003 Server
Earlier clients (for example, Windows 95 and Windows 98) and
servers (Windows NT 4.0) can participate in something similar,
but more restricted, called System Policies. System Policies has
the following features:
The system policy editor is called poledit.exe.
Different versions of the system policy editor are
distributed with Windows 95, Windows 98, and
Windows NT. These versions are not cross-
compatible.
System policies have the undesirable side effect of not
being easily reversible, unlike Group Policy settings.
Group Policy Architecture

Group Policy architecture has various facets. The basic ones covered in this section are:
The Secedit database
Local Group Policy
Network-based policy
Registry settings
The Secedit Database

One of the most important aspects of Group Policy from an organizational viewpoint is its
ability to deploy security settings (such as NTFS permissions and registry permissions) to
client machines.
This is especially important given the inconsistency with which Microsoft has treated
these security settings when clients install Windows 2000 or Windows XP. If the instal-
lation is an upgrade, then the existing security settings are honored; however, if the
installation is a clean install, then the default security settings for the OS being installed
will apply. The bottom line is that in an organization with a mix of upgraded and clean-
installed workstations, security settings may be inconsistent.
Of course, organizations may wish to specify their own security settings, which may not
exactly match either an upgraded-Windows NT or a clean-install-Windows 2000 scenario.
You need a tool that can perform the following tasks:
Analyze the security configuration of a given computer
Apply canned security configurations contained in *.inf files
Secedit is a command-line tool that has served these purposes in the past. While it is still
available, even in Windows XP, its functionality is now available in the GUI, specifically,
in the Security Settings node of the Group Policy console.
Local Group Policy
Figure 11: Local Group Policy
Every Windows 2000 Professional or Windows XP Professional computer has a local

Group Policy database, whether the computer is connected to a network or not. You can
pull up the local Group Policy console by running the file gpedit.msc on the workstation.
The settings available in the local Group Policy console are not as broad and deep as those
available in a network context, but they may be useful in configuring computers that, for
one reason or another, will never connect to a network.
Even in the network setting, local policies may take effect, if they are not overridden at
any higher organizational level.
Network Group Policy (Domain, OU, Site)

Network-based policies are typically accessed via the property sheet of the domain, OU,
or site of interest. You will spend most of your time in most organizations dealing with
network-based policy. The two utilities that provide access are:
Active Directory Users and Computers (for domain and OU-based policy)
Active Directory Sites and Services (for site-based policy)
Registry Locations
In many ways, the Group Policy console is a fancy Registry Editor, with many of the
features that Microsoft left out of the real registry editors (Regedit and Regedt32 in
Windows 2000, and the new, unified Regedit in Windows XP Professional and Windows
2003 Server). These features include:
Descriptive explanations about the registry changes to be made
The ability to easily undo registry changes
The ability to easily view the registry changes made via Group Policy
The ability to restrict the kinds of data one can place into a registry key
In fact, the Administrative Templates nodes of both halves of the Group Policy console
are populated entirely with registry settings. Microsoft sometimes refers to the Adminis-
trative Templates settings as registry-based policy.
In order to properly secure policy settings and facilitate the reversal of policy changes,
Microsoft has restricted true Group Policy registry settings to four specific registry
keys, namely:
HKLM\Software\Policies
HKCU\Software\Policies
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies
It is possible to use the Administrative Templates nodes to modify other registry keys,
but such settings are called preferences rather than policies and may not be easily
reversible or secure.
Group Policy Deployment

How does an Active Directory network actually apply Group Policy settings? What is the
precise mechanism? The following four topics provide answers to that question:
Deployment rules (that hold true if no deployment options are set)
Deployment options (that may modify the rules)
Filtering with security groups
Delegation
Deployment Rules
Given that Group Policy may be assigned at various points in the hierarchy of an Active
Directory network, the question naturally arises: What happens when the same policy
setting is made at different levels and, perhaps, with conflicting values?
Active Directory implements a pecking order that defines who wins in the event of
multiple conflicting policy settings. The priority order is as follows, with structures at the
top of the list winning out over structures below it:
The OU closest to the user
Any intermediate OUs
The OU furthest from the user (but still containing the user)
Domain
Site
Local
Note that, if the user or computer is only in one OU, the above priority list simplifies to:
OU
Domain
Site
Local
So, if a policy is set one way at the site level and a different way at the OU level, the OUs
setting will win out in the absence of any deployment options.
Another way to view this issue is to consider the order in which Group Policy is applied.
That order is as follows:
1. Local
2. Site
3. Domain
4. The OU furthest from the user (but still containing the user)
5. Any intermediate OUs
6. The OU closest to the user
Helpful Hint
You could remember the acronym L-S-D-O-O-O as a mnemonic device. Note that the
above sequence is the inverse of the prioritization list, which makes sense when you
consider that the "last write wins."
Note
Some domain-level settings appear to be modifiable at the OU level, but are really not. For
example, the minimum password length is a domain-wide security setting, and even though
it appears to be modifiable when you open the Group Policy console for a particular OU,
such a modification would have no effect.
Deployment Options
The deployment rules set forth in the preceding section may be modified. For example, a
network administrator may want to force a particular setting out to an entire domain and
not worry about whether it might be overridden at some point by an OU-level setting.
No Override
Figure 12: No Override
To set a policy object to No Override, highlight the object in the Group Policy tab of the
domain, OU, or site property sheet and click the Options button. Finally, check the No
Override box (see Figure 12).
This is the dictatorial setting that network managers use only for policy objects
containing settings deemed so necessary, either for security, user interface consistency, or
user functionality, that they should not be able to be overruled at any lower level.
Note
It is good design practice to put mandatory policy settings into GPOs that are separate from
settings that are not mandatory (that is, settings that lower-level entities, such as OUs, can
change). The reason is that the No Override flag applies to an entire GPO, not just part of
a GPO.
Block Policy Inheritance
Figure 13: Block Policy Inheritance
You can tell Windows that you want to block the inheritance of Group Policy settings from
Active Directory structures higher in the hierarchy. For example, open the properties sheet
for an OU, choose the Group Policy tab, and check the Block Policy inheritance
checkbox (see Figure 13).
Note
What happens when the irresistible force meets the immovable object, and a policy that
was set at a higher level with No Override meets a policy that was set at the next-lower
level with Block Inheritance? As you might guess, No Override wins. If it did not, there
would be no way to enforce a domain-wide policy.
Linking Group Policy

Group Policy objects are applied to network-level constructs via linking. In this way, the
network manager has ultimate flexibility in applying those objects. GPOs may be reused
and linked to multiple Active Directory constructs, such as OUs, saving development time
and administration time.
However, there is a caveat. If a GPO is linked to multiple Active Directory objects, it is
possible to delete the GPO without being aware of the existence of all the possible links.
Disabling Group Policy

You can use the Options dialog box (discussed previously under No Override) to check a
box that says Disabled: The Group Policy object does not apply to this container. Why
would you disable the application of a GPO to a container? Here are the two most
common reasons:
You are still working on the GPO and you do not want to apply it until you are
finished making all the settings you need.
You are troubleshooting a policy problem and you want to see if the problem
goes away when you disable a specific GPO.
Note
A container can be a domain, OU, or site.
Using Multiple Policies

You can link multiple policies to the same site, domain, or OU. You might do this, for
example, if you want to set the No Override flag on one GPO, but not on one or more
other GPOs.
When you use multiple policies, Windows applies them in priority order from top to
bottom. You can change the order in which the GPOs appear and thereby change the
processing order.
Filtering with Security Groups
Figure 14: Filtering with Security Groups
Someone once said that the Holy Roman Empire was neither holy, nor Roman, nor an
empire, but that other than that, it was a good name. The Microsoft choice of the term
Group Policy is similarly ironic in that administrators can apply Group Policy to local
computers, sites, domains, and organizational units, but not to security groups (at least, not
directly). Also, Group Policy does not consist of one policy, but of several hundred
policies.
What you can do with Group Policy is filter it with security groups, by modifying the
DACLs of GPOs (see Figure 14). Notice that, by default, Domain Admins are exempt
from the Apply Group Policy permission. Why do you think that might be?
By the way, a security group is a group that you create for the purpose of assigning access
to resources, as opposed to a distribution group, which is a mailing list for e-mail. Often,
the term group is used to mean security group.
Delegation of Group Policy
Figure 15: Delegation of Group Policy
In the Active Directory Users and Computers console, you can delegate the responsibility
for managing Group Policy links to a group or (less likely) to a specific user. The
procedure is to right-click the domain or OU that you wish to delegate, choose Delegate
Control, select the group or user to whom you are delegating, and under Tasks to
Delegate, check Manage Group Policy links (see Figure 15).
The ability to delegate the administration of Group Policy provides network managers
with the ability to implement a decentralized IT infrastructure, wherein individual domain
or OU managers can take responsibility for those Active Directory structures. Of course,
the decision as to whether to delegate Group Policy tasks will depend on how well those
managers understand the power of Group Policy and its inner workings, as well as on the
overall management style of the organization.
Notes Section Summary

IntelliMirror is Microsofts way of saying Users should have
access to their data and programs and preferences. Active
Directory and Group Policy are vehicles for delivering that goal.
Active Directory provides the network structure over which
Group Policy operates. Through the myriad facets of Group
Policy, including features such as folder redirection, software
installation, security database management, and user
environment settings, organizations can ensure a more consistent,
manageable, secure, and predictable computing environment.
Knowledge
Check
Section Review
1. Name three goals of IntelliMirror.
2. What is a roaming user profile?
3. Why do organizations need to deploy consistent security settings?
4. What does Active Directory have to do with IntelliMirror?
5. What is the order in which Group Policy objects are applied?
6. Which checkbox would you choose to force policies to be inherited downstream?
7. Can security group filtering be used to apply Group Policy to a specific group directly?
8. Name one advantage that Group Policy has over System Policies.
ABC Acronyms
The following acronyms are used in this section:
DACL discretionary access control list

Dfs Distributed File System
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
GPMC Group Policy Management Console
GPO Group Policy object
GUI graphical user interface
HAL Hardware Abstraction Layer
ID identification or identifier
IT Information Technology
LAN local area network
MMC Microsoft Management Console
MTTR mean time to recovery
OS operating system
OU organizational unit
PC personal computer
PXE Preboot Execution Environment
RIS Remote Installation Services
SMS Systems Management Server
TCP/IP Transmission Control Protocol/Internet Protocol
WAN wide area network
Designing Group Policy
Infrastructure
Section Topics
Implementing Group Policy
Delegating Administration of Group Policy
Designing Group Policy Infrastructure
N Knowledge
Guide
W E
Section Objectives
S

Describe the planning process of deploying Group Policy
Match Group Policy features with company requirements
Check and verify essential network services
List OU design rules
Explain how to use groups to filter the application of Group Policy
Describe default permissions for creating and deploying Group Policy
Section Overview
This section details the steps a successful Group Policy deployment should follow linking
your design to how your company can best use the features. Essential network
components and security design are also defined.
Implementing Group Policy

Although you get many practical tips for deploying and managing Group Policy in a
classroom environment, the real test arrives when you go back to your place of work to
deploy a Group Policy in your own Active Directory enterprise.
Although deploying Group Policy presents many challenges, once you complete
deployment, the benefits of a Group Policy will be quite apparent.
The four major stages required for successfully implementing a Group Policy solution are:
Planning
Designing
Deploying
Maintaining the completed policy deployment
Planning Your Group Policy Design

What are the user requirements for the types of users in your company?
How are the IT roles in your company currently handled?
Is there a new or existing security policy that must be enforced?
What level of security is required for servers?
What level of security is desired for network clients?
What level of security is desired for public computers?
How is software distributed?
How are patches distributed?
Where is essential data stored?
Are there current managers of users and computer systems?
Figure 16: Planning Your Group Policy Design
The planning phase involves consultation with your help desk, end users, management,
and support staff to provide enough information for you to decide exactly which
components of Group Policy to deploy in your organization.
Your Group Policy design is ultimately bound by the design and implementation of your
Active Directory infrastructure. Since GPOs can be linked to sites, domains, and OUs,
your Active Directory design may make it easier to use sites rather than domain settings,
or domains instead of sites or OUs.
Corporate Reality vs. Policy Objectives
z Start by evaluating the corporate practices

currently used at your place of work.
z Decide if Group Policy can mirror an existing
user practice.
z Add security concerns to this list for
discussion.
z Realize when a policy objective will not work
for your company.
Figure 17: Corporate Reality vs. Policy Objectives
The planning process is ultimately the start of gathering information about your company
and how it carries out its day-to day business with an Active Directory network.
Throughout the design phase of Group Policy, the initial scope of Group Policy may be
broadened or reduced based on the settings that are deployed on all users versus the
settings that are applied for select groups of users.
Analyzing the way your workers do their job will help you design a plan that will be
acceptable and workable.
Your Group Policy will be deemed successful if it can seamlessly fit into your existing
Active Directory environment. Although this may seem like a stretch, remember the basic
rule of a new plan: keep it simple.
Your Group Policy design will be based on your physical and logical Active Directory
deployment. At a minimum, subnets (sites) and domains will be used; organizational units
will be used as well.
If your company has several divisions, how do you manage your network infrastructure?
Is administration centrally controlled and administrated? If this is the case, having
divisions within your company does not provide your structure for network administration
or Group Policy.
Corporate Policies vs. Company Protocol
z Computer security: Can you agree on security?

z Explorer Shell security: How far can you go?
z Software deployment: Are MSI packages useful to deploy?
z Computer scripts: Can you manage computers more
effectively?
z User scripts: Are they user or enterprise?
z Folder redirection: Will you replace roaming user profiles?
z Roaming user profiles: Are they useful?
z Internet Explorer security and configuration: What is
acceptable business practice?
z Remote Installation Services: Is there need for Ghost?
Figure 18: Corporate Policies vs. Company Protocol
The components that can be managed by a well-thought-out Group Policy design contain
the topics listed in Figure 18.
A successful Group Policy design will take into account the levels of politics practiced
within your company, and acceptable network security levels balanced against the IT
department requirements, the businesses requirements, and potentially, government
requirements.
Planning for Security

The first step in designing a functional security policy is to understand what your
company will accept and what they will reject.
Having a password policy enabled that contains complex passwords may, on paper, be a
smart security choice, as long as your users do not write the password down on a scrap of
paper and pin it to their cubicle bulletin board.
Analyzing the needs of your company and what they (management and IT) will embrace
is important in deploying a sound security policy.
A policy that enforces an 8-character password changed once a month, that is accepted
and supported by all users from the top of the management tree to the bottom, is infinitely
more secure than a policy that uses complex passwords that no one will accept and seeks
to break.
Designing Your Group Policy Solution
z Networking
z DNS services
z Time synchronization
z Administration
z Client interoperability
Figure 19: Designing Your Group Policy Solution
Networking
Active Directory must be operational in order to deploy Group Policy settings at the site,
domain, or OU. ICMP must be available to process Group Policy. The client or member
servers use ICMP for communication with domain controllers on your network.
DNS Services
DNS must be working perfectly in order to process Group Policy; FQDNs are used, not
NetBIOS names. Because Group Policy works with fully qualified domain names, you
must have DNS running in your forest in order to correctly process Group Policy.
Time Synchronization
The time synchronization for authentication between workstations and servers must be
within 5 minutes. The updating of Group Policy relies on communication between domain
controllers using DNS services and the File Replication Services.
Administrative Requirements
By default, only domain administrators or enterprise administrators can create and link
GPOs. However, you can delegate this task to other users. Local administrators can create
Group Policy but do not need to have full control of the GPO infrastructure.
Client Interoperability
Group Policy applies only to computers running Windows 2000, Windows XP Profes-
sional, or Windows Server 2003; it cannot be deployed on computers running Windows
95, Windows 98, or Windows NT 4.0. Windows Server 2003 and Windows XP Profes-
sional include many new Group Policy settings that are not supported on Windows 2000.
If the client and servers in your company primarily run Windows 2000 Professional and
you have Windows Server 2003 servers, use the Windows Server 2003 administrative
templates; they are the latest .adm files and include settings for Windows 2000, Windows
XP, and Windows 2003 computer systems.
Each GPO setting details what version of Windows it supports. If you attempt to apply a
Windows 2003 GPO containing newer settings to an older version of Windows that does
not support the applied setting, it will be ignored.
To determine which settings apply to which operating systems, look at the Supported on
information in the description for the setting. This information explains which operating
systems can read the setting.
If the destination computer is running Windows 2000, Windows XP Professional, or
Windows Server 2003, and the computer account and the account for the logged-on user
are both located in a Windows 2000 or Windows Server 2003 domain, OU, or site both the
computer and the user portions of a GPO are processed.
If either the logged-on user account or the computer account is located in a Windows NT
4.0 domain, System Policy is processed for those accounts located in the domain.
Note
Computers running Windows NT 4.0, Windows 95, or Windows 98 use System Policy
rather than Group Policy. System Policies can still be deployed from Windows 2000 or
Windows 2003 Active Directory to these older clients.
Designing Your Group Policy Model
z Where will your GPOs be linked?

z What security filtering will you use on each GPO?
z How many Group Policy objects will you have?
z What is the scope of where Group Policy is applied?
z Are all Group Policy settings applicable to all users?
z Are some Group Policy settings not applicable to all
users?
z Do users and computers get controlled based on their
roles and locations?
z Are desktop configurations based on user and
computer requirements?
z What are your user requirements for various types of
users: desktop, notebooks, mobile, terminal services?
Figure 20: Designing Your Group Policy Model
The discussion questions in Figure 20 can help tailor your Group Policy guidelines and
design to the needs of your organization.
Additional Group Policy Creation Guidelines

In addition, the following topics and questions can help you in creating a Group Policy
that meets your company needs:
Management of users and computers: centralized, decentralized, user
controlled
Current IT roles: administration, troubleshooting, help desk responsibilities
Existing corporate security policies: company, state, or federal regulations
Additional security requirements for your server and client computers
Software distribution model: MSI packages, custom packaging requirements
Data storage locations: distribution links, Dfs shares
Proper naming convention
Delegation
If possible, designate only one administrator per GPO or administrator group to be respon-
sible for all editing and linking tasks. You can delegate permission to edit and link GPOs
to different groups of administrators. However, without adequate GPO control procedures
in place, delegated administrators with overlapping responsibilities can duplicate GPO
settings or create GPOs that conflict with settings set by another administrator or that are
not in accordance with corporate standards.
Initial Creation of GPOs

Your first stab at creating and deploying GPOs should err on the side of extreme caution.
A small number of settings that work well, for example Adding Logoff to the Start Menu,
or forcing the Classic Windows Desktop, will make you a hero. Start with too many
settings and people will complain.
Use settings in your GPOs that you are already familiar with and use a domain GPO to
deploy a company-wide GPO with minimal and mutually acceptable settings to all.
Naming GPOs
Define a meaningful naming convention for GPOs that clearly identifies the purpose of
each GPO. This is a very easy habit that is usually overlooked. The name should include
the settings applied, and the date of creation and change.
GPO Functionality
The functional characteristics of GPOs are:
GPOs are inherited: If a GPO is linked at the domain level and at the OU
level, both the user and computer accounts in the domain and OU could be
affected by both OUs.
GPOs are monolithic: Each GPO is created from the same master template
and, therefore, contains the same choices regardless of its location in the site,
domain, or OU.
GPOs and performance are linked: If a computer system or user account has
to process many GPO settings, performance can suffer.
Sites and GPOs
z What is the geographical location of your

Windows 2003 sites?
The physical location of each domain controller
determines its site location.
z What are the speeds of the File Replication
Service, inter-site, and intra-site replication?
Figure 21: Sites and GPOs
DC Location
The location of your domain controllers becomes a consideration if your clients are
located on remote subnets with no DC and must authenticate across a slow WAN link.
GPOs are stored in both Active Directory and in the Sysvol folder on each domain
controller. These locations have different replication mechanisms.
Replication
Replication in Active Directory is controlled by the built-in replication system of Active
Directory. Within the same site, replication between 2003 Domain Controllers that are
running at the functional domain level of Windows 2003 Server within the same site
occurs every 15 seconds.
In environments such as a partially upgraded forest that contains domain controllers
running Windows 2000 and Windows Server 2003, a typical replication might take up to
15 minutes.
Replication of the Sysvol folder is controlled by the FRS (File Replication Service).
Within sites, replication occurs every 15 minutes. If the domain controllers are in different
sites, the replication process occurs at set intervals based on site topology and schedule;
the lowest interval is 15 minutes across a WAN link unless Notification has been enabled.
If it is critical to immediately apply a change to a specific group of users or computers in a

specific site, use Active Directory Users and Computers to connect to the domain controller
closest to these objects and then make the configuration change on that domain controller.
This technique will allow those users to get the updated policy first.
Note
All changes made to GPOs are replicated from the Domain Controller which has been
assigned the FSMO role of PDC emulator to the other DCs hosting the domain. The
SYSVOL folders within each domain are linked together and updated by the File
Replication Service.
Slow Links
Active Directory defines a link as slow when it falls below the default threshold of 500
kbps. Group Policy settings that are applied under these conditions are the Administrative
Template settings along with the security settings.
All other Group Policy settings, including software distribution and folder redirection, are
not applied across slow links. However, this default threshold for both the computer and
user can be changed by modifying the Slow Link Detection policy.
How Group Policy Measures Link Speed

1. The server is pinged with 0 bytes of data and times the number of milliseconds;
if the result is less than 10 ms, the OS assumes a fast link.
2. The server is pinged with 2 KB of uncompressible data, and times the number
of milliseconds. This value is called time2.
DELTA = time2 time1. The result is equal to the time to move 2 KB of data.
Applying Group Policy Changes
z The primary mechanisms for refreshing Group

Policy are startup and logon.
z Group Policy is also refreshed on a regular basis.
z The policy refresh interval in force affects how
quickly changes to Group Policy objects are
applied.
z Folder redirection and the assignment of software
applications require the user to log off and log on
again before they take effect.
z Software applications assigned to computers are
installed only when the computer is restarted.
Figure 22: Applying Group Policy Changes
By default, clients and servers running Windows 2000, Windows XP, or Windows 2003
check for changes to Group Policy objects every 90 minutes by using a randomized offset
of up to 30 minutes.
Any changes to Group Policy settings will not be immediately available on the desktops of
users because changes to each Group Policy object must first replicate to the appropriate
domain controller where authentication is occurring.
Security Policy settings delivered by Group Policy are reapplied every 16 hours (960
minutes) even if security settings have not changed.
Note
It is possible to change this default period modifying the registry entry

MaxNoGPOListChangesInterval in the following subkey defining changes in the number
of minutes desired:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtentions.
Domain controllers running Windows 2000 Server or Windows Server 2003 check for
computer policy changes every 5 minutes.
Default polling frequency can be changed by modifying the following settings at

Computer Configuration\Administrative Templates\System\Group Policy for
computers, and
User Configuration\Administrative Templates\System\Group Policy for users.
Group Policy Refresh Interval for Computers
Group Policy Refresh Interval for Domain Controllers
Group Policy Refresh Interval for Users
Linking GPOs to the Domain
z Linking GPOs to the domain applies equally to

all users and computers in the domain.
z All domain controllers retrieve the values of
these account policy settings from the Default
Domain Policy GPO.
z The term linked defines where the GPO was
created, or where the GPO settings are to
apply.
Figure 23: Linking GPOs to the Domain
Default Domain Policy GPO

As the name suggests, the Default Domain Policy GPO is also linked to the domain.
The Default Domain Policy GPO is created when the first domain controller in the domain
is installed and the administrator logs on for the first time.
This GPO contains the domain-wide account policy settings, Password Policy, Account
Lockout Policy, and Kerberos Policy, which are enforced by the domain controller
computers in the domain.
In order to apply account policies to domain accounts, these policy settings must be
deployed in a GPO linked to the domain. It is recommended that you set these settings in
the Default Domain Policy GPO.
Keep in mind the Group Policy inheritance model and how precedence is determined. By
default, options set in GPOs linked to higher levels of Active Directory containers (sites,
domains, and OUs) are inherited by all containers at lower levels.
Notes
Note
If you have a number of policy settings to apply to computers in a

particular physical location only (for example, network or proxy
configuration settings), these settings could be applied at the site
level. However, if the settings do not distinctly match to computers
in a single site, it is better to assign the GPO to the domain or OU
structure instead.
Designing an OU Structure that Supports Group Policy
z You can move users and computers into and

out of OUs within a single domain.
z OUs can be rearranged if necessary within the
single domain.
z Groups of users with common requirements
can be easily moved and contained.
z Users and computers can be organized based
on which administrators manage them.
Figure 24: Designing an OU Structure that Supports Group Policy
OU Organization
Make sure that your OU design is based on a solid management strategy for GPO creation
and delegation of administrative duties. The goal of your OU design is to simplify Group
Policy application and troubleshooting.
Separate OU Design
One distinct design is to place all computer accounts in one OU and all user accounts in
another. Using a structure in which OUs contain either user or computer objects but not
both, you could disable the computer section or user section of a GPO to speed up the
processing of each GPO.
However, separating the user and computer components into separate GPOs will require
more GPOs.
You can compensate for this by adjusting the GPO status to disable the user or computer
sections of each GPO that do not apply and to reduce the time required to apply a given
GPO.
Central Control
If central control is desired, consider geographically-based OUs as child OUs and
duplicate the structure for each location for a clean familiar structure.
Remember that GPOs that are linked to the higher layers of your OU structure are
inherited by all child OUs by default.
Notes
Note
Group Policy settings can also be applied at the domain level, so

consider settings at the domain level for company-wide settings,
such as password policies.
Applying Group Policy to New User and Computer Accounts
Figure 25: Applying Group Policy to New User and Computer Accounts
By default all new user and computer accounts are created in the CN=Users and
CN=Computers containers shown in Active Directory Users and Computers.
For Windows 2003 Active Directory, it is now possible to apply Group Policy directly to
these containers if you take advantage of two new command-line utilities:
redirusr.exe: For user accounts)
redircomp.exe: for computer accounts)
These command-line utilities enable you to change the default location where new user
and computer accounts are created so that you can more easily design and link GPOs
directly to newly created user and computer objects.
Redirusr and Redircmp are located in WINNT\system32 on a Windows 2003 domain
controller.
Running Redirusr and Redircmp, a domain administrator can specify the OUs into which
all new user and computer accounts are placed when they are created.
Using Security Filtering to Apply GPOs to Selected Groups
z By default, a GPO affects all users and

computers contained in the linked site,
domain, or OU.
z However, you can use security filtering on a
GPO to modify its effects.
z By modifying the permissions on the GPO,
they will apply only to a specific user or the
members of a security group.
z Using a security group filter on a GPO applied
to an OU allows you to control who does not
have the settings applied .
Figure 26: Using Security Filtering to Apply GPOs to Selected Groups
Security Filtering
In order for a GPO to apply to a given user or computer, that user or computer must have
both read and apply Group Policy permissions on the GPO.
By default, authenticated users have both apply Group Policy and read permissions
set to Allow.
If you want only a subset of users within an OU to receive a GPO, remove the authenti-
cated users from the ACL on the desired GPO.
Next, add a new group with the security filtering permissions that contains the subset of
users who are to receive the GPO.
Only members of this group that are within the site, domain, or OU where the GPO is
linked receive the GPO; members of the group in other sites, domains, or OUs will not
receive the GPO.
Isolating Administrators
You might want to prevent certain Group Policy settings from applying to the Adminis-
trator group. To accomplish this, you can do one of the following:
Create a separate OU for administrators and keep this OU out of the user
infrastructure. Administrators will then not receive most of the settings that
you provide for managed users. If this separate OU is a direct child of the
domain, the only possible settings administrators receive are settings from
GPOs linked either to the domain or the site.
Since only broadly applicable settings should be linked here it might be
acceptable to have administrators receive these settings; otherwise, the Block
Inheritance option on the administrators OU can also be set.
Have administrators use separate administrative accounts to be used only when adminis-
trative tasks are being carried out. Therefore, when not performing administrative tasks,
they would still be managed by the applied Group Policy settings.
Changing the GPO Link Order
Figure 27: Changing the GPO Link Order
Within each domain, site, and OU, the link order controls the order in which GPOs are
applied.
To change the precedence of a link, you can change the link order, moving each link up or
down in the list to the appropriate location, using the Up and Down buttons.
Links with the lowest number have higher precedence for a given site, domain, or OU.
For example, if you add four GPOs, the GPO highest in the list, for example Default
Domain Policy as shown in Figure 27, has a link order of 4. This GPO will be deployed
last, and only after the other three GPOs have been deployed. Since it is deployed last; the
settings contained in the Default Domain Policy GPO have a higher priority and will
override any identical settings defined in the other three GPOs.
Controlling GPO Delegation Notes
Delegation of Group Policy objects can be split into three distinct

tasks:
Creating GPOs: Who will create and delete Group
Policy objects in your company?
Linking GPOs: Where will GPOs be linked, or
unlinked (site, domain, or OU)?
Managing GPOs on a daily, weekly or monthly
basis: Who will do the editing?
Note
With regards to Group Policy, the ACL editor has two functions:
filtering security groups and controlling who can create, edit, and
link to a specific GPO.
Default Rights for Group Policy Management
z When Windows 2003 is installed, default

permissions are assigned to specific
administrative groups for creating, deleting,
and linking Group Policy objects.
z Only the enterprise administrator can have the
most unlimited control.
z Enterprise administrators can create, delete,
link, or unlink GPOs anywhere in the forest.
Figure 28: Default Rights for Group Policy Management
You can always modify the default permissions shown in Figure 29 that are assigned to
one of the system groups. However, that may present additional problems because a
domain admin or local administrator can perform many additional tasks, some of them
probably unwanted. It is best to create a new group for Group Policy management.
Windows 2003 Group Rights Granted
Enterprise Admin Create, delete, edit, and link GPOs in all forest containers (sites,
domains, and OUs).
Domain Admins Create, delete, edit, and link GPOs in the domain and all OUs hosted
by the domain, but not in sites. See note below for exceptions to this
rule.
Group Policy Creator Create GPOs in the domain to which the group belongs. Users who
Owners are members of this group can edit any GPOs that they create,
however other members of the group cannot. Deleting GPOs is not
allowed. Linking to a site, domain, or OU is also not allowed.
Local Administrators Create GPOs in the domain to which the group belongs. A user that is
a member of this group can edit and delete all GPOs that any other
group member has created. Linking the GPO to the domain and any
OUs hosted by the domain is also allowed.
Figure 29: Groups assigned GPO rights
You can manage three Group Policy tasks on a per-container Notes

basis in Active Directory:
Linking GPOs to the site, domain, or OU
Group Policy Modeling analysis for domains and
OUs
Reading Group Policy Results data for domains and
OUs
Note
If your Active Directory network is a single domain, be aware that

by default the local administrator is made a member of the
Domain Admins, Enterprise Admin, Schema Admins and Group
Policy Creators groups.
Group Policy Creator Owners Group
Figure 30: Group Policy Creator Owners Group
Following are the main characteristics of the GPCO (Group Policy Creator Owners)
group:
Members of the GPCO group cannot link GPOs to containers unless they have
been separately delegated the right to do so on a particular site, domain, or OU.
Being a member of the GPCO group gives the nonadministrator full control of
only those GPOs that the user creates.
Members of the GPCO group cannot link, or delete any GPOs, so this group is
not effective as the group for Group Policy management.
GPCO members do not have permissions for GPOs that they do not create.
Group Policy Creator Owner Details

Membership in the GPCO group allows each member the ability to create GPOs in a
domain. However, they cannot link any GPO that they have created to any other container.
When a nonadministrator who is a member of the GPCO group creates a GPO, that user
becomes the creator owner of the GPO and can edit the GPO and modify permissions on
the GPO.
Because the GPCO group is a domain global group, it cannot Notes

contain members from outside the domain. So if Jane Smith is
added to the GPCO group, she alone can create and edit GPOs
that she has created.
When the Group Policy MMC creates the GPO for Jane, it does
not assign the GPCO to the ACL on the GPO; it instead assigns it
directly to the user that created the GPO, in this case Jane.
The GPCO is just a placeholder for the members of the group;
once they actually create GPOs the permissions are assigned to
the specific user.
Perhaps Microsoft felt that all Group Policy administrators
should be added to the GPCO group, and permissions would next
be assigned when GPOs were created.
Delegating Administration of Group Policy

Your Group Policy design will probably call for delegating certain Group Policy adminis-
trative tasks.
Determining to what degree to centralize or distribute administrative control of Group
Policy is one of the most important factors to consider when assessing the needs of your
organization.
A centralized administration model has an IT group providing services and setting
standards for the entire company. In organizations that use a distributed administration
model, each business unit manages its own IT group.
You can delegate the following Group Policy tasks:
Creating GPOs
Managing individual GPOs (for example, granting edit or read access to a
GPO)
Performing the following tasks on sites, domains, and OUs:
- Managing Group Policy links for a given site, domain, or OU
- Performing Group Policy Modeling analyses for objects in that container
(not applicable for sites)
- Reading Group Policy Results data for objects in that container (not
applicable for sites)
- Creating WMI filters
- Managing and editing individual WMI filters
Based on the administrative model your organization, you need to determine which
components of configuration management should be handled at the site, domain, and OU
levels. Administrative responsibilities at each site, domain, and OU level might be further
delegated at each level.
When deciding whether to delegate authority at the site, domain, or OU level, remember
the following points:
Authority delegated at the domain level affects all objects in the domain if the
permission is set to inherit to all child containers.
Authority delegated at the OU level can affect either that OU only, or that OU
and its child OUs.
GPO Delegation
z The right to link GPOs can be delegated separately from the right
to create and edit GPOs
z Be sure to delegate these rights to only the groups you want to be
able to create and link GPOs
z Creation of GPOs can be delegated to any group or user
Figure 31: GPO Delegation
The Delegation of Control Wizard

The process of delegation in Windows 2000 and Windows 2003 is performed using the
Delegation of Control wizard utility, which assigns security permissions to specific users
and groups to perform specialized administrative tasks on Active Directory objects.
Internally, the ACL is doing all the work as shown in Figure 31. Unfortunately there is no
un-delegation of control wizard.
To delegate Group Policy-related permission on a site, domain, or OU, select the
appropriate container.
1. Right-click the site, domain, or OU and select Delegation.
2. To add new groups or a user, use the Add button.
3. Select the desired permission you want to manage: Link GPOs, Perform
Group Policy Modeling analyses, or Read Group Policy Results data.
Notes
Note
Group Policy Modeling and Group Policy Results are not available
for sites.
Manually Assigning Permissions
Following are guidelines for permissions needed

for creating and editing GPOs:
z The ability to create GPOs in a domain is a
permission that is managed on a per-domain
basis.
z By default, only domain administrators,
enterprise administrators, group policy creator
owners, and system can create new Group
Policy objects.
z By default, domain administrators can edit all
GPOs in the domain.
Figure 32: Manually Assigning Permissions
To manually assign permissions to a Group Policy object, right-click the GPO object from
the Group Policy MMC, and from the GPOs properties click the Security tab.
In order to be able to edit, view, link, and delete a GPO, specific rights must be granted as
shown in Figure 33.
Rights Control
Full control Create, edit, view, and delete the GPO
Read View the GPO in the Group Policy Console
(opening the GPO to edit is not allowed)
Write View and edit the GPO (Note: The read permis-
sions must also be granted to even be able to
view the GPO)
Create all child objects Create and edit GPOs (deleting is not allowed)
Delete all child objects Delete a GPO
Figure 33: Rights for GPO Control
Notes Administrative Rights

When an administrator creates a GPO, the Domain Adminis-
trators group becomes the creator owner of the Group Policy
object.
If the domain administrator wants a nonadministrator or
nonadministrative group to be able to create GPOs, that user or
group can be added to the Group Policy Creator Owners security
group.
After a non-domain administrator creates an unlinked GPO, the
domain administrator or someone else who has been delegated
permissions to link GPOs in a container can link the GPO as
appropriate.
By default, domain administrators have GPO linking permission
for domains and OUs, and enterprise administrators and domain
administrators of the forest root domain can manage links to
sites.
By default, access to Group Policy Modeling and remote access
to Group Policy Results data is restricted to enterprise adminis-
trators and domain administrators.
Specifying a Domain Controller for Editing Group Policy
z The choice of domain

controllers is important for
administrators to consider to
avoid replication conflicts.
z In each domain, the DC with
the FSMO role of PDC
emulator is used for all GPO
operations in that domain.
z This includes all operations on
the GPOs that are located in
that domain.
Figure 34: Specifying a Domain Controller for Editing Group Policy
Resolving Conflicts
If two administrators were to simultaneously edit the same GPO on different domain
controllers, you may think that the changes written by one of the administrators will be
overwritten.
If multiple administrators manage a common GPO, all administrators actually use the
same domain controller when editing a particular GPO in order to avoid collisions.
To avoid this situation from arising, the operations master token for the PDC emulator in
each domain is used as the default for editing GPOs. This ensures that all administrators
are using the same domain controller.
However, it might not always be desirable for an administrator to use the PDC to edit
GPOs. If the administrator is located in a remote site, or if the users or computers targeted
by the GPO are in a remote site, the administrator might want to choose to target a domain
controller in the site where they are located. The default location of editing GPOs on the
PDC emulator can be changed to any other domain controller in the domain, as shown in
Figure 34.
Notes For example, if you are an administrator in Canada and the PDC
emulator is in Denver, it might be inconvenient to rely on a WAN
link to access the PDC emulator in Denver.
Use the Change Domain Controller function to specify the
domain controller to be used for a given domain or for all sites in
a forest. You have four options:
The domain controller with the operations master
token for the PDC emulator (the default option)
Any available domain controller
Any available domain controller running Windows
Server 2003 or later
This domain controller: Select a specific domain
controller to be used
Using Loopback Processing
z The User Group Policy

loopback processing mode
policy setting is an advanced
option that is intended to
keep the configuration of the
computer the same,
regardless of who logs on.
z This option can be very
useful in environments such
as classrooms, public kiosks,
and reception areas.
Figure 35: Using Loopback Processing
Loopback Processing
The loopback processing mode policy setting applies the same user settings for any user
who logs onto the computer, based on the computer they log on to.
When you apply Group Policy objects to users, normally the same set of user policy
settings applies to those users when they log on to any computer.
By enabling the loopback processing policy setting in a GPO, you can configure user
policy settings based on the computer location that they log on to. Those settings are
applied regardless of which user logs on.
You set the loopback policy inside each GPO by using the User Group Policy loopback
processing mode policy setting under Computer Settings\Administrative
settings\System\Group Policy. Two options are available:
Merge: In this mode, the list of GPOs for the user is gathered during the logon
process. First the list of GPOs for the computer is gathered. Next, the list of
GPOs for the computer is added to the end of the GPOs for the user. As a
result, the GPOs of the computer have higher precedence than the GPOs of the
user.
Replace: In this mode, the list of GPOs for the user is not gathered. Instead,
only the list of GPOs based on the computer object is used. The user
configuration settings from this list are applied to the user.
Notes
Note
When you use the Replace option, you must ensure that both the
computer and user portions of the GPO are enabled.
Using Group Policy Inheritance
Guidelines for Group Policy inheritance include:

z Group policy inheritance allows you to apply
corporate standards and customized settings for
different groups of users.
z Defining a corporate standard GPO containing
setting that applies to a large number of users in
your company can be very useful.
z Typically, GPOs are assigned to the OU structure
instead of the domain or site, so child OUs can be
used to control who gets what settings applied.
Figure 36: Using Group Policy Inheritance
An example of where defining a corporate standard GPO might be useful is: Only
authorized users can access the command prompt or the registry editor.
One way to do this is to set the policy settings Prevent access to the command prompt,
and Prevent access to registry editing Tools and link these settings to an OU, for
example Domain_User_Accounts OU. This action will result in these settings being
applied to all users in the Domain_User_Accounts OU. Then create a GPO, such as an
Administrator_Policy GPO, which explicitly allows administrators access to the
command prompt and registry editing through a security group filter applied to the
Administrator_Policy GPO. Therefore, the GPO linked to the Administrator_Policy GPO
will override the settings configured in the Standard User Policy GPO.
If another group of users requires access to the command prompt, but not the registry, you
can create another child GPO that allows access. Access to the registry editing tools is still
denied because the new GPO does not override the registry tools setting made in the
Domian_User_Accounts GPO.
When you set default values for security-related settings such as restricted group
membership and file system access and registry access permissions, remember that these
settings work on a last-write-wins principle; the settings in this case are not merged.
Notes
Note
Changes to a GPO are saved immediately and, therefore, could

be applied before you intend. It is a good idea to keep the GPO
unlinked from its production location (site, domain, or OU) until
you have fully tested it in a test environment. While you are
developing the GPO, keep it either unlinked or linked to a test OU.
Rolling Back Domain GPOs
Figure 37: Rolling Back Domain GPOs
If for some reason there is a problem with the changes to the GPOs and you cannot revert
back to the previous or initial states, you can use the dcgpofix.exe tool to re-create the
default policies in their initial state.
Dcgpofix is a command-line tool that completely restores the Default Domain Policy GPO
and Default Domain Controller GPO to their original states in the event of a disaster.
Dcgpofix restores only the policy settings that are contained in the default GPOs for the
domain at the time it was first created; the default settings are found in Security, RIS, and
EFS.
Dcgpofix does not restore other GPOs that administrators create; it is only intended for
disaster recovery of the default GPOs. Dcgpofix is included with Windows Server 2003
located in the c:\Windows\Repair folder and works only in a Windows Server 2003
domain. The syntax for dcgpofix.exe is listed below.
dcgpofix [/target: domain | dc | both]
Option Function
/target Description of option
domain Recreates the Default Domain Policy
dc Recreates the Default Domain Controllers Policy
both Recreates both the Default Domain Policy and the
Default Domain Controllers Policy
Figure 38: Options for dcgpofix

This chapter described the planning process of Group Policy and
how to apply the essentials to your Group Policy design. OU,
site, and domain container design were covered along with
details on default permissions, proper permission design, and
how to properly delegate Group Policy.
Tips on redirecting user and computer creation and rolling back
Group Policy to default levels were also discussed.
Knowledge
Check
Section Review
1. What are the four major stages in a successful Group Policy design?
2. What happens when a Windows 2003 Group Policy setting is applied to a Windows 2000
Professional client?
3. What replicates the contents of the Sysvol folder in a Windows 2003 domain?
4. What does Group Policy consider as the slow link threshold?
5. How often is Group Policy refreshed to domain clients?
6. How often is Computer Policy refreshed to domain controllers?
7. Which new utility allows us to specify where new user and computer accounts are created
in Windows 2003 Active Directory?
8. Group Policy can be linked to which three containers in Active Directory?
ABC Acronyms
ACL access control list

DC domain controller
EFS Encrypting File System
FQDN fully qualified domain name
FRS File Replication service
FSMO Flexible Single Master Operation
GPCO Group Policy Creator Owners
ICMP Internet Control Message Protocol
KB kilobytes
Kbps kilobits per second
MSI Microsoft Software Installer
NetBIOS Network Basic Input/Output System
OS operating system
PDC primary domain controller
WMI Windows Management Instrumentation
Testing and Piloting Group Policy
Section Topics
Group Policy Staging: Overview
Creating Lockdown Desktops
Comparison of Features Used in Each Scenario
N Knowledge
Guide
W E
Section Objectives
S

Create a testing environment
Use the RSoP planning mode to simulate Group Policy deployment
Use the RSoP logging mode to analyze Group Policy deployment
Properly migrate Group Policy objects to your production environment
Understand the use of the Group Policy Management Console
Use the Common Desktop Management Scenarios for analysis
Section Overview
This section lays out how to create a staging and planning network for testing Group
Policy settings. Using the RSoP logging and planning tool, the Group Policy Management
Console, and understanding the Common Desktop Management Scenarios are key
components to embrace and use.
Group Policy Staging: Overview
Choices of scenarios for testing include:

z Staging domain within production forest
z Staging forest with no trusts to production
forest
z Staging forest that mirrors your future
production forest
Figure 39: Group Policy Staging: Overview
The very first step in staging involves creating a test bed created out of similar clients and
servers used in your production environment. Figure 40 explores the possible staging
scenarios to consider.
Staging
Advantages Disadvantages
Options
Staging domain Can leverage existing production infrastructure services (for Might not be
within production example, DNS, DHCP). Less hardware resources may be sufficiently isolated
forest required to implement than a completely isolated environment from production
that requires supporting DNS, and DHCP infrastructure. Easier environment to
to synchronize with production environment because all test site GPOs
settings and services are in the same forest.
Staging Forest Completely isolated from production environment; provides Difficult to keep
with no trusts to maximum protection from test GPOs affecting production synchronized with
production forest computers and users. No security overlap between staging and production forest.
production. Experiment freely with settings and configurations
without affecting the production environment.
Staging Forest that Completely isolated from production environment. Can use
mirrors your future GPMC copy operation to move GPOs between staging and
production forest production environment when available. Experiment freely with
settings and configurations without affecting the production
environment.
Figure 40: Staging Options
Creating Your Staging Environment
Two considerations for creating your staging

environment are:
z Dedicated hardware will be required for the
construction of your staging environment.
z VMware would be very useful for creating and
testing clients.
Figure 41: Creating Your Staging Environment
Slow Network Links

For example, if your production forest has workstations located across slow network links
from your domain controllers, this fact can affect the application of Group Policy because
some Group Policy settings are not applied across slow links. It is important that your test
environment reflect this situation for you to get an accurate picture of how your
production environment will be impacted by changes in Group Policy.
Preparing the Staging Environment

Check that the staging environment is running at the same operating system, service pack,
and hot fix levels as your production environment to ensure consistent test results.
Check that the supporting infrastructure, such as DNS, Dfs, and related services are also
configured the same as your production environment. A staging domain in your
production forest could use your existing production DNS infrastructure for name
services.
VMware
VMware allows you to create software servers and workstations that can run together on
one computer system at the same time. A computer system with 2 GB of RAM and a large
hard drive could run multiple instances of Windows 2000 and Windows XP at the same
time, with the virtual sessions being bridged to the physical network adapter in the
computer system.
Testing Group Policy in the Staging Environment
z Test users and computer accounts

T Deploy GPOs in a test environment
z Use the Group Policy Results tool
T Shows the effects of processed policies
z Use the Group Policy Modeling tool
T Simulates processing of policy choices
Figure 42: Testing Group Policy in the Staging Environment
Before deploying your Group Policy solution, it is critical that you assess it to determine
the effects of applying the various policy settings that you select, individually and in
combination.
Always stage Group Policy deployments using the following predeployment process:
1. Deploy new GPOs in a test environment modeled after your production
environment.
2. Use Group Policy RSoP to understand which GPO settings actually are applied
in your test environment.
3. Use Group Policy modeling to understand how a new GPO will mesh with any
existing GPOs.
Logging On as a Test User

By far the most accurate method of testing Group Policy is by using test user accounts on
real computer systems in your staging environment. Modeling tools are handy, however
they are not the same, they merely present scenarios to allow you to see any red herrings
that may occur.
Notes Using Group Policy Modeling

For Active Directory networks with at least one Windows
Server 2003 domain controller, you can use Group Policy
Modeling in GPMC to simulate the deployment of GPOs to
any destination computer running Windows 2000 Server or
Windows 2000 Professional, Windows XP Professional, or
Windows Server 2003.
The newest tool for viewing the actual application of GPOs is
Group Policy Results in the GPMC.
Group Policy Modeling was previously called RSoP planning
mode, and Group Policy Results was previously called RSoP
logging mode.
Using Group Policy Results

Use the Group Policy Results wizard to see which Group Policy
settings are actually in effect for a user or computer by gathering
RSoP data from the destination computer.
In comparison to Group Policy Modeling, Group Policy Results
reveals the actual Group Policy settings that were applied to the
destination computer. The target must be running Windows XP
Professional or later.
To run the wizard, right-click the Group Policy Results
container, and select Group Policy Results Wizard.
When you have answered all the questions in the wizard, GPMC
creates a report that shows the resultant set of policy for the user
and computer that you entered in the wizard. The display shows
which GPO is responsible for each setting on the Settings tab
under the heading Winning GPO.
Using Group Policy Modeling to Simulate Notes
Resultant Set of Policy

The built-in Group Policy Modeling wizard can calculate the
simulated effect of GPOs on users and groups in an Active
Directory environment and the effects of moving user or
computer objects to a different Active Directory container.
This simulation is performed by a service that runs on domain
controllers running Windows Server 2003. The calculated results
are reported in HTML format displayed in the management
console in the details pane for the selected GPO.
You must have at least one domain controller running Windows
Server 2003 to be able to perform a Group Policy Modeling
analysis.
When you have answered all the questions posed by the wizard,
your answers are displayed as a query showing which GPO is
responsible for each setting under the heading Winning GPO,
and which GPOs attempted to set the settings but did not succeed.
Note
GPMC Modeling does not include evaluating any local GPOs.

Because of this, in some cases you might see a difference
between the simulation and the actual results.
Migrating Group Policy
Migrating Group Policy from your test

environment involves the following steps:
z Mapping ACEs to GPOs
z Mapping security principals
z Mapping UNC drives
z Use the GPMC to deploy a copied GPO
Figure 43: Migrating Group Policy
The tool to perform migration of GPOs from the staging environment to the production
environment is the Group Policy Management Console. It allows us to copy GPOs from
one network location to another and to import GPOs from one domain to another
untrusted forest.
Mapping ACEs to GPOs

After a GPO is moved from the staging environment to the production environment, you
will need to remap ACEs on each GPO to detail which users and groups will read and
apply the new policy settings.
Mapping Security Principals

Security settings, user rights assignments, and folder redirection will need to be remapped
to the appropriate security principals in your production environment.
Mapping UNC Drives

Make sure that all UNC paths are properly remapped for software installations, folder
redirection, or user, and computer scripts.
Copying GPOs
To deploy a new GPO using the copy method, follow these steps:
1. Running GPMC in the staging domain, right-click the GPO that you plan to
migrate and choose Copy from the context menu.
2. Running GPMC in the production domain, right-click Group Policy Objects
and choose Paste from the context menu.
3. On the Cross-Domain Copying Wizard dialog box, click Next and select the
option to Preserve or migrate the permissions from the original GPOs.
Click Next.
Note
If you choose the first option, Use the default permissions for new GPOs, this GPO will
receive the default permissions that would be applied to any new GPO in the production
domain.
The second option, Preserve or migrate the permissions from the original GPOs, lets
you use a migration table to map the DACL on the staging GPO to its production
equivalents.
4. When the wizard completes the copy operation, right-click the Active
Directory site, domain, or OU to which you want to link the copied GPO, and
select Link an Existing GPO from the context menu.
5. From the Select GPO dialog box, select the GPO that you just copied.
6. After you link the new GPO and replication is complete, the GPO is live in the
production.
Note
A migration table can be created using the Migration Table Editor, a bundled GPMC tool.
Migration tables are XML in format and are created and applied to the GPOs that you want
to migrate. The command-line Mtedit tool is found in the GPMC installation location. Users,
domain local, global, and universal groups, computers, and UNC paths can be mapped in a
migration table.
Creating Lockdown Desktops
Figure 44: Creating Lockdown Desktops
Microsoft has released a number of Group Policy scenarios for testing and modeling
purposes under the banners Change and Configuration Management, and IntelliMirror:
Lightly Managed Desktop: Users who are allowed a majority of control
over their computer system
Mobile User: Notebook clients that are always on the road or work from
home a lot
Multi User Desktop: Users who can change some of their user profile
settings but cannot change hardware or network settings
App Station: (Highly Managed Desktop) Highly restricted configurations with
only a few applications are required
Task Station: Dedicated to running a single software application.
Kiosk: Used in a public area
The Common Desktop Management scenarios install a set of Notes

12 GPOs consisting of a user and computer object for each of
the 6 scenarios. The following seven steps briefly describe the
installation and configuration process.
1. Install the scenario files to a local workstation.
2. Install the scenario GPOs on the domain controller.
3. Create the OUs and link to the desired scenarios.
4. Create user and computer accounts.
5. Define environment specific settings.
6. Customize optional settings.
7. Customize any other Group Policy settings as needed
for your environment.
Lightly Managed Desktop
z A workstation that uses the Lightly Managed Desktop scenario is

the least restrictive of the six scenarios.
z This scenario allows users to customize most of the user profile
settings that affect them but prevents them from making local
registry and system changes.
Figure 45: Lightly Managed Desktop
Lightly Managed Desktop Summary Details

This scenario supports a feature that Microsoft calls free-seating, which means that
users can sit down at any computer and access all their resources (user profiles), applica-
tions (Network Applications), and data (Offline files) as though they were sitting at their
own computer.
It has a preapproved set of applications assigned to either the user or the computer. Users
can also install applications that have been published for them. Other enabled security
settings are:
Administrator and guest accounts are renamed.
The logon message is enabled.
Users can install printer drivers.
Event log settings are configured for larger application and system logs.
Restrictive access controls are applied to the root directory (everyone - read).
Mobile User
z Used for a laptop or notebook computer

z Designed for users who are away from the office a lot, use dial-up
links, and occasionally high-speed network links
z Can also be used by users who are away from the office only
occasionally and who log on by using RRAS or other remote
network links
Figure 46: Mobile User
Mobile User Details

The mobile user model provides each user access to their data and user settings at all times
regardless of whether the computer is connected to, or disconnected from, the network.
This model also supports free seating for the purpose of backing up essential user
information and enabling users to access data from other computer systems.
Users can also disconnect from the network without having to log off or shut down. Other
optional security features to consider are:
Enable deletion of remote access connections (belonging to the user).
Enable renaming of connections belonging to the current user.
Display and enable the Network Connection wizard.
Allow access to remote access connection properties of the current user.
Notes Enable access to the properties of the components of a

LAN connection.
Enable access to the properties of the components of a
remote access connection.
Enable status statistics for an active connection.
Enable the Dial-up Preferences item on the
Advanced menu.
Multi User Desktop
z A workstation that uses the Multi User Desktop scenario allows

users to perform basic customizations to their Desktop but they
cannot customize network, hardware, and system settings.
z Supports free seating: Users can log onto any computer and get
their data and settings.
z However, the normally cached user profile is removed from the
computer system when they log off.
Figure 47: Multi User Desktop
Multi User Desktop Details

Users have restricted write permissions on the shared local computer; however, they can
write to their user profile and to redirected folders.
Certain software applications are always available.
The overall security profile of the computer system is highly secure. Other security
settings implemented are:
The user can modify the Desktop and Favorites or URLs in Internet Explorer.
Control Panel is available with approved items.
The Run command can be used from the Start menu.
The command prompt is disabled.
The user can only run assigned or published applications.
Hardware devices cannot be added, removed, or modified.
App Station (Highly Managed Desktop)
z A workstation that uses the App Station scenario is a highly

restricted version of the Lightly Managed Desktop scenario.
Figure 48: App Station (Highly Managed Desktop)
App Station Details

The App Station scenario has the following added controls:
Minimal customization of the user environment is allowed.
Software applications are installed and available according to job
requirements.
The user is not allowed to add or remove any software applications.
Free seating is supported.
A simplified Desktop and Start menu is provided.
Users have restricted write permissions on the shared local computer; however,
they can write to their user profile and to redirected folders.
The overall security profile of the computer system is highly secure.
Task Station
z A workstation that uses the Task Station scenario is dedicated to

running a single software application, such as a Terminal Server
session.
Figure 49: Task Station
Task Station Details

The Task Station mode is similar to the App Station scenario, with the following
differences:
Only one software application or process is installed. It automatically starts
when the user logs on.
There is no Desktop or Start menu.
Kiosk
z A workstation that uses the Kiosk scenario is much the same as the
Task Station mode but users are anonymous, providing no personal
authentication credentials.
z No customizations are allowed and the user state is not saved.
Figure 50: Kiosk
Kiosk Details
A kiosk has the following controls:
The computer system is a public workstation.
Only one application is executed.
Only one user account is available and it is automatically logged on.
The identity of each user is unknown to the Kiosk computer system because
users do not provide any personal logon credentials.
Each kiosk workstation runs unattended and is always powered up.
The overall security profile of the computer system is highly secure.
Users cannot make changes to the default computer settings.
Data is not saved to the local hard disk.
Comparison of Features Used in Each Scenario

Comparison Scenario
Lightly Mobile User Multi User App Station Task Station Kiosk
Managed (Highly
Desktop Managed)
Number Multiple 1 Multiple Multiple Multiple 1 (users are
of Users anonymous)
User Roaming Roaming or Roaming Roaming Roaming Local
Profile Type local
Status of Cached Cached Removed at Cached Removed at N/A
Profile at logoff logoff
Logoff
Folder My My My My My No
Redirection Documents Documents Documents Documents Documents
and AppData and AppData and AppData and AppData and AppData
User Can Almost all Some or most Some settings Few settings None None
Customize settings settings
Task Bar and Yes Yes Yes Yes No No
Start Menu
Assigned Multiple Multiple Multiple Few 1 (usually 1 (computer-
Applications computer- assigned)
assigned)
Published Yes Yes Yes No No No
Applications
Security User or power User or power User User User User
Context user user
Security Secure Secure High secure High secure High secure High secure
Template workstation workstation workstation workstation workstation workstation
Figure 51: Comparison of Features Used in Each Scenario
Figure 51 compares the Windows 2000 and Windows 2003 features that are used to create
each scenario.

This section discussed the creation of a test network to begin the
deployment and analysis phase of Group Policy deployment.
How to use the Resultant Set of Policy tool to plan and review
Group Policy setting was also discussed, along with an
introduction to the GPMC. Finally a detailed view of how to use
the IntelliMirror GPOs supplied by Microsoft for testing and
planning purposes was discussed.
Knowledge
Check
Section Review
1. Which three staging options can be considered for testing Group Policy?
2. Which four steps are essential when migrating Group Policy?
3. Which new MMC allows the copying of GPOs?
4. Which two features are combined in the term free seating?
5. Although a Multi User Desktop scenario has restricted write permissions applied, what
two areas can a user write data and settings to?
6. The App Station scenario deploys software applications based on _______ requirements?
7. How many software applications does a Task Station scenario support?
8. What customizations are allowed to a Kiosk scenario client?
ABC Acronyms
ACE access control entry

GB gigabyte
HTML Hypertext Markup Language
RAM random access memory
RRAS Routing and Remote Access Services
RSoP Resultant Set of Policy
UNC Universal Naming Convention
URL Uniform Resource Locator
XML Extensible Markup Language
Deploying Security Templates
Section Topics
Security Architecture
Customizing Security Templates
Microsoft Baseline Security Analyzer
N Knowledge
Guide
W E
Section Objectives
S

List the essential system components
Explain how system components contribute to Group Policy deployment
Create custom security templates
Use the Security Configuration and Analysis Tool
Use Secedit and Gprefresh to manually update policy settings
Plan for proper security for domain computer systems
Use Microsoft Baseline Security Analyzer
Section Overview
This section defines the security model of Windows 2000, Windows 2003, and Windows
XP and details the security mechanisms and tools available to deploy security effectively
across your network to computer systems and users.
Security Architecture
The main components of a Windows 2000,

Windows 2003, and Windows XP Computer
System are:
z Security principals
z Access control lists
z Security groups
z NTUSER.DAT
z The registry
Figure 52: Security Architecture
Starting with Windows 2000 Professional and continuing with Windows XP, and
Windows 2003 Server, the security subsystem of Windows uses several key security
components (listed in Figure 52). These security components are used to deploy and
enforce security for the computer system and the network user.
Security Principals
The operating system assigns a unique SID to every created user, group, or computer
object created on a standalone Windows computer system or a computer system that is a
member of a domain. The SID of a domain-based user, group, or computer system also
contains an RID that indicates what domain the security principal was created in and
belongs to.
Some security principals are created by default by the operating system; for example, the
user Administrator, and the Everyone system group are created by the operating system
and have a specific rather than a unique SID. These types of objects are called well-
known security principals and cannot be deleted.
Access Control Lists

Every object and process created on an NTFS file-system partition can be controlled using
file and folder permissions that are usually assigned by groups containing security
principals or by individual users. Permissions are assigned using ACLs that contain a list
of security principals. The specific allow and/or deny privilege given to each security
principal is defined as a level of discretion, hence the name DACL (discretionary ACL). If
you wish to monitor the assigned level of permissions on any object or process, auditing of
selected users and groups can be performed using SACLs (system ACLs).
Security Groups
Security groups are used to assign rights and permissions to processes and objects using
the ACLs, DACLs, and SACLs. For the purpose of this course, the assumption will be
made that you are a network client on a computer system that has joined a domain.
Therefore, your level of access will be controlled using a mixture of local groups that were
created on your local workstation and domain-based groups that reside on the domain that
you belong and logged on to.
If you log on to your computer system using local account information, security from your
local security components will be enforced until you log off.
If you log on to the domain, the domain security will take precedence over your local
security components and enforce the domain level of security until you log off.
The table in Figure 53 lists the local and domain-based security group types that can be
used in Windows 2000 or Windows 2003 domains running in Windows 2000 native mode
or later, and Windows 2000 or Windows XP local systems.
Windows 2000 Windows 2000 Windows Windows 2003
Groups
Server Pro XP Pro Server
Local Groups X X X X
Domain Local Groups X X
Global Groups X X
Universal Groups X X
Figure 53: Local and Domain Groups
NTUSER.DAT: The User Profile
z Desktop settings, like

application preferences,
screen colors, update the
user profile hive portion of
the registry.
z Most of the network,
hardw are, and security
access permissions and
security parameters
update the system hive
portions of the registry.
z Group Policy information
is stored in specific policy
folders in either the user
or system hives of the
registry.
Figure 54: NTUSER.DAT: The User Profile
Part of each users user profile is hidden in the NTUSER.DAT user hive and loaded
when a user successfully logs into a Windows 2000, Windows 2003, or Windows XP
client. Many Group Policy settings that control the appearance and use of the Explorer
shell are applied to the user profile at logon.
A user profile as shown in Figure 54 is created from a Window 2000, Windows 2003, or
Windows XP registry hive plus a set of profile template directories. The user profile
registry hive is called NTUSER.DAT and is mapped immediately to the
HKEY_CURRENT_USER section of the registry after the user is logged on.
Each user must have a defined user profile combined with an active user account to be
able to use any Windows 2000, Windows 2003 or Windows XP computer system. User
profiles are stored locally by default in c:\Documents and Settings as shown in Figure
54. This directory stores the shortcut links, desktop icons, and startup applications for each
local user under two folders: All Users and Default User.
Note
A Windows NT 4.0 computer system that has been upgraded to either Windows 2000 or
Windows XP Professional will use the \WINNT\PROFILES location for user profiles.
Default User Profile

The Default User contains the default user profile NTUSER.DAT and the shortcuts to the
installed Accessories found in the Start Menu folder. This profile is used for creating all
new user profiles.
All Users Profile

The All Users folder contains the common settings for the Desktop and Start Menu.
These settings are always available, regardless of who is logged in. The quick way to view
the All User settings is by right-clicking Start button at the bottom of the screen and
selecting Explore All Users. Only the defined Administrator can create, make changes to,
or delete the common program groups.
When a new user first logs on to a Windows 2000, Windows 2003, or Windows XP
computer system for the first time, a new profile is created for the user. The default user
shortcuts and folders located in the Documents and Settings\Default User folder, the
NTUSER.DAT hive file of the default user, and the shortcuts and folders located in
Documents and Settings\All Users are all copied into the newly created user profile
folder.
Next time the user logs into the computer system, the users own profile will be loaded.
When software is installed and changes are made to the system, the user profile stores the
changes and updates. By default, a user profile is created and stored locally, and therefore
only accessible on the computer where it was created, unless roaming profiles are enabled.
The Registry
Figure 55: The Registry
Many Group Policy settings update the registry database on the local computer shown in
Figure 55, even if the settings are deployed through Active Directory.
HKEY_CURRENT_USER
This hive holds custom settings of the current logged on user. We also know this section as
the User Profile stored in Documents and Settings\Username. This root key is also a
pointer to HKEY_USERS\Security ID (SID) of the loggod on user. Group Policy
settings for all users are found here.
HKEY_LOCAL_MACHINE
This hive is the main location for global hardware and software settings, Control Panel
and Network settings, as well as startup and shutdown settings. Group Policy settings for
computer systems are found here. Other hives present in HKLM are SAM, SECURITY,
SOFTWARE and SYSTEM.
The SAM hive contains existing security information for current local user and group
accounts installed on the local computer, including passwords and domain associations.
The SECURITY hive contains the user and group security settings. An example of the
type of security information would be user rights and file permissions. This information is
hidden by default when using Regedit, the Registry Editor. We normally access this
information when we set local file and folder permissions through the Explorer shell and
when we use the Local Users and Group MMC.
HKEY_CLASSES_ROOT
Whenever you use the Explorer shell and perform the task Tools, View, Folder Options,
File Types, you are directly accessing HKEY_CLASSES_ROOT. It is a pointer to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes. Registered extensions and the
software applications that are registered to the extensions plus ActiveX, and DCOM
settings are also stored here.
HKEY_USERS
This hive contains the Default User hive profile that is running before you actually log on
to your PC, and the logged on User profile. When a user is successfully logged on to the
system, the default user profile is disabled. Note that the sub key of the current user is not
the user name but his or her SID. The settings of the active user will also be shown in
HKEY_CURRENT_USER.
HKEY_CURRENT_CONFIG
This is your computer hardware profile found in the System Icon\Hardware profile in
Control Panel. This is also a pointer to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles.
Figure 56: The Secedit database
Located in %System Root%\Security on every Windows 2000, Windows 2003, and

Windows XP computer system, the local Secedit database shown in Figure 56 contains a
collection of computer security settings, default user and group rights, registry and local
file security, and network services that are applied to the computer system when it is first
installed.
In the older Windows NT 4.0 operating system, the local registry (SAM and SECURITY)
was where security settings were written. Windows 2000, Windows 2003, and Windows
XP computer systems now use secedit.sdb.
Security settings can be enforced locally using secedit.sdb for standalone systems or for
users that are disconnected from the network. Local security settings are always applied
first, even when logging into a domain.
However, any change in security settings deployed at the domain will be applied to the
local copy of the secedit.sbd database when the computer is again connected to the
domain.
Note
Local security settings are always applied first.
Next, any domain-based security settings that have been enabled through the domain
Group Policy that are different from the local security currently in effect will be
downloaded. These settings overwrite the local settings and become the effective security
setting for the computer system.
Keep in mind that this security process is completed before the user is given the
opportunity to log on as a client.
Changes to the default security settings can be performed using several built-in tools:
Locally using the Local Security Settings MMC located on the
Administrative Tools menu
At the domain, using the Group Policy console launched from the properties of
the domain
At the OU, using the Group Policy console launched from the properties of the
OU (with the exception of Password Policy and Account Lockout Policy,
which can be enforced only at the domain)
The Security and Analysis MMC, which can be loaded into a new MMC
The command-line utility secedit.exe used to analyze, configure, export,
validate, or roll back existing security settings for Windows 2000 systems
The command-line utility Gpupdate used to refresh security settings for
Windows XP and Windows 2003 computers
Security Templates
Figure 57: Security Templates
Several default security templates shown in Figure 57 are bundled with the Windows
2000, Windows 2003, and Windows XP operating systems. The security settings that are
applied are based upon whether a clean installation or upgrade was performed. A clean
Windows 2000, Windows 2003, and Windows XP install has a more restrictive security
profile than an upgraded Windows NT 4.0 computer system.
Windows 2000, Windows 2003, and Windows XP security templates include settings for
the following security options:
Account policies: Both local and domain account polices can be configured. A
local account policy defines password and account lockout settings; domain
account policy also includes options for defining Kerberos settings.
Local policies: A local computer policy is local to the computer system
regardless of the type of computer system: workstation, domain controller, or
member server. Local policies include auditing policy, user rights and security
privileges on the specific system.
Event log: These settings allow the configuration of the application, security,
and system logs with regard to maximum log size, access restrictions, and
retention methods.
Notes Restrictive groups: This section allows you to

control group membership of the default local groups,
for example Administrators, Print Operators, Server
Operators, and Power Users. You can also add custom
groups and restrict their group membership.
System services: System services control most
network services, file and print services, and Internet
services by defining startup mode and service security
for each service.
Registry: These settings control registry keys
by applying a custom security descriptor on
specific keys.
File systems: These settings define security settings
for any file and folder.
The Security Templates Console
Figure 58: The Security Template Console
The available security template provided by Microsoft for modifying default security can
be easily viewed by loading the Security Templates MMC as shown in Figure 58. Clicking
the Action menu and selecting Set Description provides a summary of the selected
security template.
Compatible: The Compatws.inf template relaxes the default file (%System
Root%, Program Files) and local registry hive permissions and removes all
users from the Power Users group.
Secure: Both the Securedc.inf and Securews.inf templates enhance security
settings in the areas of stronger passwords, account lockout, authentication,
client-server SMB packet signing and audit policy settings for domain
controllers or workstations respectively.
Highly secure: The Hisews.inf, and Hisedc.inf templates further enhance
existing security levels with the addition of mandatory server SMB packet
signing and the disabling of NTLM authentication. In order to apply this
security template, all domain controllers must be Windows 2000, all Windows
NT 4.0 member servers must have SP4 or later applied, and all clients must be
Windows 2000 or Windows XP Professional.
Notes Root security: The Rootsec security template

contains the new security permissions found in
Windows XP and Windows 2003 Server that are
applied to the root of the hard drive.
Setup security: The Setup security template
contains the full computer security settings deployed
during a clean installation of Windows 2000,
Windows 2003, or Windows XP.
By default, after a clean installation, permissions are assigned
only to the local groups: Administrators, Power Users, and Users.
Applications that meet the Designed for Windows 2000
Application Specs can usually run successfully in the User
security context.
Creating Custom Security Templates
Figure 59: Creating Custom Security Templates
You can easily create a new security template that can then be applied to a Windows 2000,
Windows 2003, or Windows XP computer system by using the Security Templates MMC:
Right-click the default security templates path and from the context menu select New
Template as shown in Figure 59.
Notes Fill in the Template name and provide a description as shown in

Figure 60.
Figure 60: Creating a New Corporate Security Template
Adding Security Settings
Figure 61: Adding custom security levels
A newly created security template is a blank template file with no defined settings.
For Account Polices, Local Policies, and Event Log options, select the desired options
and double-click each value in the details pane to assign the selected option to the
appropriate group or user.
To assign Restricted Groups, System Services, Registry, and File Permissions,
right-click the desired security option and from the context menu select Add.
To save your custom template after designing your security options, right-click the custom
template and select Save As, enter the desired name, and click OK.
To apply a custom security template to a computer, use either the local Group Policy editor
gpedit.msc, or the domain-based Group Policy tool. Open Computer Configuration,
Windows Settings, and right-click Security Settings. Select Import policy and navigate
to where your security template is located. The default location is
Windows\Security\Templates.
Using the Security Configuration and Analysis MMC
Figure 62: Using the Security Configuration and Analysis MMC
The Security Configuration and Analysis MMC shown in Figure 62 is an optional security
tool bundled with Windows 2000, Windows 2003, and Windows XP computer systems to
allow the analysis of current system security settings against an established security
baseline. Tasks that can be performed include:
Easily identifying any current security weaknesses
Discovering security changes from accepted company standards
Testing and analyzing potential security changes to see how they will affect
current security settings
Creating a Security Baseline for Analysis Notes
To create a security standard for the purpose of comparison, the

steps are:
1. Open the Security and Configuration Analysis
console.
2. Right-click Security Configuration and Analysis
and select Open Database. Type a name for your
new database and click Open.
3. Select an existing security database to use as your
baseline and click Open to import the selected
security settings into the newly created database.
4. To analyze the current computer security against
the defined baseline, right-click the Security
Configuration and Analysis icon and click
Analyze Computer Now.
5. Accept the default log path and error log, or enter
the desired log file name.
6. Click Open and then click OK. The progress of the
analysis is shown in Figure 63.
Analyzing System Security
Figure 63: Baseline Analysis in Progress
After the analysis has completed, you will be returned to the Security Configuration and
Analysis console as shown in Figure 64. As you scroll through the selected security
results, the baseline database setting and the actual setting will be displayed in the details
pane for each security option.
Any discrepancies from the established baseline will be flagged with a red X,
indicating that the default security settings and the tested baseline do not
match.
Green check marks indicate that the baseline security and the actual security
settings match.
A question mark (?) indicates that the setting was not analyzed.
If there is no marking, the setting was not enabled in the baseline.
An exclamation mark indicates that the setting is in the baseline but not on the
analyzed system.
Exporting Security Templates
Figure 64: Security analysis results
To export an existing security template for deployment on another computer or for

deployment through Active Directory using the Group Policy Editor, follow these steps:
1. Open Security Configuration and Analysis.
2. From the top of the console tree, right-click and select Export Template.
3. Enter the desired name and location for your exported template.
Exporting security templates can be performed only by a local administrator or a member
of the Administrators group.
Importing Security Templates to a Local Computer System

To import an existing security template for deployment on another computer system,
follow these steps:
1. Open the Local Security Policy from the Administrative Tools group in
Control Panel.
2. At the top of the Security Settings console tree, right-click and select
Import Template.
3. Navigate to the location where your security template is located and
select Open.
Importing Security Templates through Group Policy

To import an existing security template for deployment through Group Policy, follow
these steps:
1. Open the Group Policy Editor from the properties of the domain or OU where
the security template is to be deployed, using Active Directory Users and
Computers.
2. Navigate to Computer Configuration\Windows Settings\Security
Settings.
3. At the top of the Security Settings console tree, right-click and select
Import Template.
4. Navigate to the location where your security template is located and
select Open.
Using Secedit
Figure 65: Using Secedit
As a command-line tool, Secedit can be used to automatically analyze and apply security
and security templates.
Secedit is the command-line utility used for Windows 2000, Windows 2003 Server, and
Windows XP Professional to analyze, configure, export, validate, refresh, or roll back
existing security settings. (For Windows XP Professional and Windows 2003 Server the
command-line utility gpupdate.exe is used to refresh Group Policy settings immediately
without rebooting.)
Analyze System Security

Secedit can analyze system security by comparing the current computer security against
another security template.
Analyze Current Security

If you wish, you can use the Secedit.sdb database to compare local security settings
against Group Policy settings that are downloaded from a domain. If you try to load the
live Secedit.sdb file, you will receive an error. So first you must make a copy for
comparison purposes. Syntax details are listed in Figure 66.
1. Navigate to the Windows\Security \Database folder.
2. Make a copy of the Secedit.sdb database.
3. Open a new MMC, load the Security Configuration and Analysis, and click
Open Database.
4. Select the copy of the Secedit.sdb file that you created in the
Windows\Security \Database folder. Click Open.
5. Right-click Security Configuration and Analysis, and click Analyze
Computer Now.
6. For the error log file and location, in the error log file path box type:
c: \Windows\Security\Logs\Testsecurity.log and click OK.
Syntax that can be used with Secedit for analysis is described in Figure 66.
secedit /analyze /db FileName .sdb [/cfg FileName] [/overwrite]
[/log FileName] [/quiet]
Secedit Syntax Description

/db Database.sdb This is the name of the database that is used to perform the analysis.
/cfg FileName This indicates what security template to import into the database prior to performing
the analysis.
/log FileName This is the optional filename where to log the status of the analysis; the default is the
secsrv.log file located in the %windir%\security\logs directory.
/quiet The complete analysis process is executed in the background.
Figure 66: Secedit Syntax for Analysis
Configure System Security

Secedit can be used to configure your computer system security by applying a security
template.
The entire security profile can be changed or one or more security areas listed in
Figure 67.
Secedit / configure / db FileName [/cfg FileName] [/overwrite]
[/areas area1 area2 ] [/log FileName][/quiet]
Export Current Security Database

Secedit can export the current security database to a security template. Export syntax is
described in Figure 67.
secedit /export [/DB FileName] [/mergedpolicy] [/CFG FileName]
[/areas Area1 Area2 ...] [/log FileName] [/quiet]
Secedit Syntax Description

/db FileName This indicates the database that is used to configure security.
/mergedpolicy This results in the merge and export of domain and local policy security settings
/CFG FileName This is the template that the settings will be exported to.
/areas Area1 Area2 ... This details the security areas to be exported to a security template. All areas are
exported unless specified.
Figure 67: Secedit Export Syntax
The security areas that can be exported separately, or in groups are listed in Figure 68.
Security Policy Includes account policies, audit policies, event log settings, and security options.
Group_Mgmt Restricted Group settings (Defined through domain group Policy)
User_Rights User rights assignment
Regkeys Registry permissions
Filestore File system permissions
Services System service settings
Figure 68: Security Areas
Import Security Templates

Secedit can also be used to import security settings using a batch or script file.
secedit /import /db FileName.sdb /cfg FileName.inf [/overwrite]
[/areas Area1 Area2 ...] [/log FileName] [/quiet]
Import security policy example:
secedit /import /db hisecws.sdb /cfg hisecws.inf /overwrite
Validate Security Templates

The syntax of a security template can also be checked using the validate option with
secedit:
secedit /validate FileName
Refresh Windows 2000 Group Policy

You can also use Secedit.exe with the /refreshpolicy switch to impose Group Policy
object settings upon a target workstation immediately as follows:
1. Secedit /Refreshpolicy Machine_Policy /Enforce: Immediately imposes
Group Policy object settings located within the machine node of relevant
Group Policy objects. Machine in this instance refers to computer policy.
2. Secedit /Refreshpolicy User_Policy /Enforce: Immediate imposes Group
Policy object settings located within the user node of the relevant Group
Policy objects. User in this instance refers to computer policy.
Using Gpupdate
Figure 69: Using Gpudate
Gpupdate is used to manually update any changes that are made to group policies.
Gpupdate.exe is used in Windows 2003 and Windows XP, replacing the /refreshpolicy
switch in the command-line tool that Secedit.exe used on Windows 2000 systems.
Usually after changes have been made to Group Policy, the changes need to be applied
immediately without waiting for the default Group Policy refresh interval of 90 minutes
on domain members and 5 minutes on domain controllers to take effect.
At a command prompt, run the Gpupdate.exe utility as shown in Figure 69. The
following information describes the utility and the different switches that can be used
with it:
GPUpdate [/Target:{Computer | User}] [/Force] [/Wait:value]
[/Logoff] [/Boot]
Useful switches for Gpupdate.exe are:
/Target:{Computer | User}: This switch is used to specify that only user or
computer policy settings that are updated will use this switch. Both user and
computer policy settings are updated if this switch is not used.
/Force: This switch results in all policy settings being reapplied. By default,
only the policy settings that have changed are applied.
/Logoff: This switch indicates that the user is logged off after policy settings
have been applied.
Customizing Security Templates
Figure 70: Security Spreadsheet for Windows 2003 Server
The security levels that are deployed on a Windows 2000, Windows 2003, and Windows
XP computer system should be viewed merely as a starting point in defining an acceptable
level of security.
Many administrators are not yet aware that most default security levels defined by the
installation can be easily changed.
Using either the Local Security Console on the local computer or the Group Policy Editor
through an Active Directory domain, security settings, account policies, and user rights
can be changed and applied with minimum effort.
In most cases, Microsoft recommends increasing the level of security whenever possible.
To that end, many guides have been published by Microsoft providing many sensible
recommendations for your considerations. Following are the highlights of Microsoft
recommendations for properly deploying security for domain-based network clients.
When viewing and analyzing existing security settings, the value Effective Default
Setting indicates that the current status of the selected setting is currently in effect.
The security guides for Windows 2000, Windows 2003, and Windows XP can be found by
following the links at www.microsoft.com/security and also at www.microsoft.com/
technet/treeview/default.asp?url=/technet/security/Default.asp
There are also various Microsoft Excel spreadsheets containing Notes

excellent details on default security configurations for Windows
2000 or Windows 2003, and Windows XP found at
www.microsoft.com/windowsxp/pro/techinfo/administration/
policy/winxpgpset.xls.
Figure 70 shows a summary listing of the Windows Default
Security and Services Configuration Excel spreadsheet.
Hardening Computer Accounts
z Hardening means beefing up the default levels

of security.
z For Windows 2000, Windows 2003, and
Windows XP, computer account security is
broken down into three subgroups.
z Increasing the default security levels is
enabled at the domain level by default.
z The default values already enabled are merely
starting points.
z Only one domain account policy is allowed in
Active Directory.
Figure 71: Hardening Computer Accounts
The term hardening when applied to computer security means beefing up the default
levels of security to:
Resist unwanted intrusion
Avoid potentially damaging hacking of the company infrastructure
For Windows 2000, Windows 2003, and Windows XP, computer account security is
broken down into three subgroups:
Account policies
Account lockout policies
Kerberos policies
Increasing the default security levels of domain controllers, member servers, and
workstations is, by default, enabled at the domain level.
Although there are some default values already enabled in the domain controllers
policy, and the default domain policy, these are merely starting points.
The important concept to grasp about the deployment of security policy in Active
Directory domains is that only one domain account policy is allowed.
Where Security Is Applied Notes
Account policy is applied to the root domain of the domain tree.

Once a computer system has been joined to the domain,
becoming a member, the current domain account policy takes
effect.
Security Settings at the OU Container

Each GPO assigned at the OU level has settings for Password
Policy and Account Lockout Policy, making it appear that
security can be enforced at the OU container. This, however, is
not the case; these settings are bogus, and do not apply to
computers contained within an OU. They may perhaps in the
future when OUs become security principals.
Windows 2000 and Windows 2003 clients are domain clients;
therefore, security can be applied only at the domain.
Account Policy: Password Policy
Figure 72: Password Policy Choices
Account policies are, by default, applied at the domain level unless local account policies
for current domain member computers have been defined at the OU level.
Password policy is defined at the following location within the Group Policy Editor shown
in Figure 72:
Computer Configuration\Windows Settings\Security Settings\Account
Policies\Password Policy
Following is a description of the settings:
Enforce password history 0 passwords remembered (Between 0 and 24)
This setting defines the number of unique and new passwords that must be
used before a previously used password can again be used. Microsoft
recommends that if this setting is enabled, then the Minimum password age
should also be set so users do not try to change their password several times at
once to immediately reuse their favorite password.
Maximum password age 42 days (Between 0 and 999)
This setting defines the length of time that passes before users must change
their password. This value should be set between 15 and 60 days. If the
password is to never expire, the value can be set to 0.
Minimum password age 0 days (Between 0 and 998)

This setting defines the number of days that a password must be used before it
can be changed. As mentioned above, if Enforce Password History is to be
enabled, this setting should also be defined. If this setting is set to 0, a new
password does not have to be chosen ever. Microsoft recommends that this
setting be set to 2 days.
Minimum password length 0 characters (Between 0 and 14)
This setting defines the absolute minimum length in characters that a valid
password can be. Password phrases can also include spaces. This setting
should be set to 8.
Password must meet complexity requirements Disabled
This setting, when enabled, defines a series of guidelines that all proposed
passwords are measured against before being accepted. The guidelines are:
- The password does not contain the user name, or parts of the user name.
- The password is at least 6 characters long.
- The password contains characters from three of these four categories:
- English uppercase characters (A-Z)
- English lowercase characters (a-z)
- Base 10 numerals (0-9)
- Nonalphanumeric characters (! $,%,#)
These rules are the default level of security for Windows 2003 Server and
cannot be easily modified unless a new copy of the library file passfilt.dll is
created (see knowledge base article: KB 151082 Password Change Filtering
and Notification in Windows NT).
If this setting is enabled with a Minimum password length of 8, a user
password could have over 218 trillion possibilities, making a brute force attack
a little harder to successfully accomplish.
Store password using reversible encryption for all users in the domain
This setting can be used by Windows 2000, Windows 2003, and Windows XP
computer systems. It actually provides a method for reversing a password that
has been encrypted. CHAP authentication and IAS requires that this setting be
enabled. Do not enable this setting unless required.
Account Lockout Policy
Figure 73: Account Lockout Policy
Account lockout policies attempt to lock out user accounts when too many incorrect
attempts are made to log in. By default, these settings are not enabled, but should be. A
proper lockout policy must also be implemented with training and proper Administrator
and Help desk response when accounts become locked out.
As password policy becomes stricter, more account lockouts will occur.
Password policy is defined at the following location within the Group Policy Editor shown
in Figure 73:
Computer Configuration \Windows Settings\Security Settings\Account
Policies\Account Lockout Policy
Account lockout duration (when enabled 1 to 99,999 minutes)
This setting, once enabled, is activated on a user account where the defined
number of invalid login attempts is exceeded. It is recommended that the
Account lockout duration be set to 30 minutes. A value of 0 specifies that
accounts will never be locked out.
Account lockout threshold (when enabled 0 to 999)
This setting, once enabled, sets the number of failed login attempts that
causes the user account to become locked out. If users use screen saver
passwords, or Task Manager to lock their user account, entering a password
to unlock their account incorrectly does not count against a defined account
lockout threshold unless the setting Interactive logon: Require Domain
Controller authentication to unlock workstation is also enabled. If the
Account lockout threshold is set to 0, this setting ensures that accounts will
not be locked out. This setting could also provide Notes

an opportunity for repeated login attempts that may
not be detected.
Reset account lockout counter after (when enabled
from 1 to 99,999 minutes)
This setting, once enabled, determines the amount of
time that must pass before the filed logon attempt
counter automatically resets to 0 bad login attempts.
Microsoft suggests setting the account lockout value
to 30 minutes; however you must have a workable
policy of how to respond to account lockouts when
they occur.
Kerberos Policy
Figure 74: Kerberos Policy
The Kerberos version 5 authentication protocols are enforced at the domain through the
default domain policy GPO. It cannot be overridden by Group Policy settings in an OU as
these settings are not available at the OU level.
For most internal Active Directory networks, these settings do not need to be changed. For
public access across the Internet and other public paths, certain changes could be
considered.
Kerberos policy settings can be changed using the Group Policy Editor at the following
location:
Computer Configuration\Windows Settings\Security Settings\
Account Policies\Kerberos Policy
Enforce user logon restrictions
This is the default setting and need not ever be changed, as every request for a
session ticket should be validated.
Maximum lifetime for service ticket (from 10 to 99,999 minutes)
This setting defines the amount of time in minutes that a session ticket, once
granted, can be used to access requested services. The minimum timeframe
is 10 minutes or greater and also less than or equal to the defined setting for
Maximum lifetime for user ticket. The Notes

recommendation for internal networks is 600
minutes, the default setting.
Maximum lifetime for user ticket
(0 to 99,999 hours)
This setting defines the time length in hours that a
user TGT is valid. Once the TGT expires, a request for
a new TGT is made. The recommendation for internal
networks is 10 hours, the default setting.
Maximum lifetime for user ticket renewal (0 to
99,999 days)
This setting defines a time frame based on the number
of days during which the TGT of a user can be
renewed. The default value is 7 days and deemed to
be sufficient.
Maximum tolerance for computer clock
synchronization (1 to 99,999 minutes)
This setting defines the allowable skew in minutes
between the clients clock and the time on the domain
controller where authentication is being performed.
The default setting is 5 minutes.
Security Options
Figure 75: Security Options
Security options are a mixture of security privileges and rights dealing with user accounts.
Options are divided into auditing, local hardware devices, domain controllers, domain
members, interactive logons, network access and security and the recovery console.
Certain settings are for specific computer systems; not every setting will be used. The
security settings that bear consideration are as follows:
Accounts: Administrator account status
The local Administrator account is a huge security risk due to its well-known
name, its well-known SID, and the fact that you are a password guess away
from getting in with Administrator privileges. It is a good idea to always
disable the local Administrator account and instead assign users to the
Administrators group.
Note
If you need this account in safe mode, it is always available, even if disabled.
Finally, the local Administrator account cannot be Notes

locked out regardless of the number of failed logons
that this account generates.
Accounts: Guest account status
This account allows logon to the network as Guest
with no password. It is usually disabled, but you
should check to make sure.
Accounts: Limit local account use of blank
passwords to console logon only
When this right is enabled, it allows logins with a
blank password only when the client is logging on to
the computer system locally.
Accounts: Rename administrator account
Renaming the local Administrative account assigns a
different name to the SID used for the Administrative
account and therefore makes it much harder to guess
the account name of the Administrator.
Accounts: Rename guest account
Renaming the local Guest account assigns a different
name to the SID that is used for the Guest account.
Therefore, it makes it much harder to guess the
account name.
Audit and Device Settings
Figure 76: Audit and Device Settings
Audit and device settings can be described as follows:

Audit: Audit the use of Backup and Restore privilege
If you require the full auditing of all backup and restore processes on every
file, then enable this setting.
Audit: Shut down system immediately if unable to log security audits
Microsoft meets this C2 security requirement: if the security log is full and the
operating system can no longer log security events, the computer system is
halted and a stop error C0000244 is displayed. An Administrator must log on
and reset the security log.
Devices: Allow undock without having to log on
This setting should be disabled so users cannot undock and walk away with a
notebook computer system without first logging on.
Devices: Allowed to format and eject removable media
In this era of CD-ROM and DVD drives, it is perhaps vital that not just any
user can eject removable media and gain access to critical data records.
Devices: Restrict CD-ROM access to locally Notes

logged-on user only
Once enabled, the CD-ROM will be accessible only to
the locally logged in user. If the user logs out, then the
CD-ROM drive could be accessible across the
network if it was shared.
Devices: Unsigned driver installation behavior
In Windows 2000 and Windows XP, this is the default
setting. In Windows 2003, this setting is not defined.
Most new hardware that the user will have access to is
hardware that connects to a USB or FireWire port on a
desktop system and additional PCMCIA slots on a
notebook system. It is a fact that almost all new
hardware ships with unsigned drivers. The option
warn but allow installation makes good sense.
Interactive Logon Security Options
Figure 77: Interactive Logon Security Options
Interactive logon security options include the following:

Interactive logon: Do not display last user name
This setting should be enabled so that any person attempting to log on to a
computer system must know the username and the password to succeed.
Interactive logon: Do not require CTRL+ALT+DEL
Pressing CTRL+ALT+DEL enables a trusted path for authentication, so the
enabling of this setting is a good security measure to enforce. It also
removes the possibility that the users have turned off this setting in Windows
2000 and Windows XP.
Interactive logon: Message text for users attempting to log on
This setting provides a message that appears at logon, which must be
acknowledged by the end user before continuing. This setting should be
enabled in companies that need to warn about legal issues.
Interactive logon: Message title for users attempting to log on
This setting provides a message title to the message text in the above setting.
Interactive logon: Number of previous logons to Notes

cache (in case domain controller is not available)
This setting determines if a user can log in to their
workstation using cached information from a
previously successful logon. It really depends on the
level of security that you wish to enforce and the
reliability of your servers on a daily basis. Setting this
value to 0 stops caching of all logon information.
However, the domain controller must be available to
authenticate all logons.
Interactive logon: Prompt user to change
password before expiration
This setting should be set to match the length of time
that users can retain their password before change is
mandated.
Interactive logon: Require Domain Controller
authentication to unlock workstation
The enabling of this setting forces reauthentication of
user credentials with the domain controller rather than
using cached credentials.
Interactive logon: Require Smart card
If smart cards are being used, you can force all logons
to use smart cards.
Interactive logon: Smart card removal behavior
If a smart card is removed, you can immediately lock
the workstation or force an automatic logoff.
Miscellaneous Security Settings

Other security settings include the following:
Microsoft network server: Disconnect clients when logon hours expire
On a large network with any shared computers, this can be a helpful setting.
Network security: Force logoff when logon hours expire
This setting works in tandem with the above setting. The only concern is open
documents that have not been properly saved.
Network security: LAN Manager Authentication levelSend LM & NTLM
responses
This setting can be used to deny access to Windows 95 and Windows 98
computer systems.
Recovery console: Allow automatic administrative logon
Make sure that if the recovery console is enabled, automatic Administrative
access is disabled.
Recovery console: Allow floppy copy and access to all drives and all
folders
This setting should be enabled to allow copying of files from removable media,
the use of wild cards, and access to all folders on the local hard drive.
Shutdown: Clear virtual memory page file
On dual boot systems or notebooks, it is a good idea to clear the swap file at
shut down to make sure that no sensitive data remains in the page file.
User Rights Assignments
Figure 78: User Rights Assignments
A user right is defined by Microsoft as a task that a user has been permitted to carry out on
a standalone computer system or at the domain.
User rights are further separated into logon rights and privileges.
A logon right defines just who can successfully log on to a computer system and the
acceptable method of logon.
A privilege controls the level of access to the system resources. The user rights for a
Windows 2000, Windows 2003, and Windows XP computer system are configured locally
with the Local Security Console and at the domain using the Group Policy Editor at the
following path:
Computer Configuration\Windows Settings\Security Settings\Local Policies\User
Rights Assignment
User rights include the following:

Access this computer from the network
This user right is required by several network protocols such as SMB,
NetBIOS, CIFS, and COM+. This right is required for authorized users to be
able to connect to shares and folder across the network. Removing this right
from the Everyone group removes the security hole of being able to read files
on any share.
Add workstations to domain
This right allows a user to add 10 workstations to a domain. This right must be
assigned to the default domain controllers policy for the domain. If users have
been given rights to the Create Computer Object in an OU or the Computers
container in Active Directory, they can add an unlimited number of user
accounts to the domain. Define a policy so that only selected members of your
support team can add workstations to the domain.
Allow logon locally
This setting allows a user to start an interactive session on the computer system
where the right is granted. The danger with this setting is with domain
controllers and member servers. Always make sure that only the Adminis-
trators group members have local logon access to all domain controllers and
member servers. For workstations this right is granted to the local Users group.
Allow logon through Terminal Services
This right appeared in Windows 2003 Server and Windows XP Professional
and allows a user to log on to the computer using a Remote Desktop
Connection. The best practice is to use the Remote Desktop Users group to
determine who will have access through Terminal Services. By default,
Administrators have the right to use Terminal Services, once enabled, as they
are an automatic member of the Remote Desktop Users group. The use of the
Deny permission may come in handy for this setting to ensure that specific
groups do not gain remote access by mistake.
Back up files and directories
This user right, once assigned, allows users to use a backup program such as
ntbackup.exe to back up files and directories that they do not have permission
to access at the NTFS prompt. They could then take the tape to a computer
where they do have access, and after taking ownership and administrative
privileges, access privileged data files. Limit this right to the members of your
support team that perform the daily or weekly backups.
Bypass traverse checking

This right allows users to pass through a folder that they may not have access
to, on the way to a destination folder where they do have proper access. This
right is required by the operating system.
Change the system time
This right allows the user to change the time on the computer internal clock.
With the advent of Kerberos authentication, perhaps this right should be
removed from the Power Users group as time synchronization is of the utmost
importance for authentication and Active Directory.
Deny access to this computer from the network
This right should be denied to the following user accounts: anonymous logon,
the local guest account, and any user accounts that you do not want connecting
back to their computer system across the network.
Force shutdown from a remote system
This setting should be limited to the Administrators group.
Generate security audits
This setting should be limited to the Local Service, and Network Service to
ensure that log files are not tampered with, such as the overwriting of events to
cover unauthorized activities.
Load and unload device drivers
New to Windows 2003 and Windows XP Professional is the requirement that
persons needing to install local printers and manage printer settings be
assigned this right. A potential notebook power user may require this
additional right.
Manage auditing and security log
This right allows you to specify object access auditing options for files, Active
Directory objects, and registry keys. Although this right is assigned only to
Administrators, in certain situations the denying of this right to all but
Administrators makes sure that mistakes do not happen and log files are not
tampered with.
Take ownership of files or other objects
By default, this right is assigned to Administrators to be able to take ownership
of every object in Active Directory, and on all NTFS volumes. In certain
situations, help desk and support professionals could also be assigned this right
for ease in carrying out their support roles.
Microsoft Baseline Security Analyzer
Figure 79: Microsoft Baseline Security Analyzer
The MBSA (Microsoft Baseline Security Analyzer) version 1.1 is a multithreaded security
scanner that analyzes an individual computer or a group of computers for missing security
patches and other security problems.
In addition to checking for easily guessed user passwords, autoadmin login, and
unnecessary services, MBSA also scans for unprotected IIS servers that have not yet run
the IIS lockdown tool.
It can also scan multiple instances of SQL server, evaluating the SQL authentication
mode, looking for blank SA passwords, and checking for any privilege escalation opportu-
nities exposed through the SQL Server service account.
You can specify hostnames, a range of IP addresses, and domain names that you would
like to scan by executing MBSA from the command line or graphical user interface.
Output is presented through an HTML interface, and data is saved in XML format.
The highlights of using MBSA are: Notes

Works on Windows NT 4.0, Windows 2000,
Windows 2003, Windows XP, and Microsoft
Exchange 5.5 and Exchange 2000, and Exchange
2003 Server.
Scans for missing security patches.
Security updates detection for Exchange 5.5,
Exchange 2000, and Windows Media Player 6.4
and higher.
Scans all instances of SQL Server.

This section explained the essential system components and how
they mapped to Group Policy deployment. The built-in security
tools were discussed in detail, including how to analyze current
system security and create custom security templates. Updating
computer policy without rebooting was also discussed. A detailed
section on user security settings to deploy to harden the current
security levels of your company was also presented.
Knowledge
Check
Section Review
1. Which file is the user profile?
2. Which registry hive is mapped to the logged-on user profile?
3. Which security template is used when a clean install of Windows 2000 or Windows XP is
carried out?
4. Which MMC is used to create custom security templates?
5. Which command-line tool is used to update Windows 2000 policy without rebooting?
6. Which command-line tool is used to update Windows 2003 and Windows XP policy
without rebooting?
7. Which version of Windows has complex password enabled by default?
ABC Acronyms

CD-ROM compact disc read-only memory
CHAP Challenge Handshake Authentication Protocol
CIFS Common Internet File System
COM+ Component Object Model Plus
DACL discretionary ACL
DCOM Distributed Component Object Model
DVD digital versatile disc
FTP File Transfer Protocol
IAS Internet Authentication Service
IIS Internet Information Services
IP Internet Protocol
LM LAN Manager
MBSA Microsoft Baseline Security Analyzer
NTLM Windows NT LAN Manager
PCMCIA Personal Computer Memory Card International Association
RID relative identifier
SA security association
SACL system ACL
SID security identifier
SMB Server Message Block
SP4 Service Pack 4
SQL Structured Query Language

TGT ticket granting ticket
USB Universal Serial Bus
Network Security Using Group
Policy
Section Topics
Deploying Member Server Security
Domain Security
Controlling Network Services with Group Policy
Enforcing an Audit Policy
Restricting Security Group Membership
Using Scripts
Managing Printers: Printer Pruning
Network Security Using Group Policy
N Knowledge
Guide
W E
Section Objectives
S

Design effective member server and network security
Create OU and domain security baselines
Explain how to deploy security templates through Group Policy
Create an effective audit policy
Describe the security features of Group Policy
Manage printers using the prepopulate search feature
Section Overview
This section details effective security design using Active Directory logical components.
How to deploy security templates, effective audit policy, and registry and file security
deployment through Group Policy is also detailed.
Deploying Member Server Security
Figure 80: Deploying Member Server Security
When designing your network infrastructure, first make a list of your infrastructure
components that are to be managed with Active Directory and Group Policy.
Include in this list the following servers:
Domain controllers
Member servers
File servers
Print servers
Infrastructure servers
Web servers
Certificate servers
Bastion servers (Internet)
IAS servers
IIS servers
Member Server Baseline Policy

The next step is to create a baseline policy. In short, create a new baseline security
template, and import it into Group Policy against the OU where the member servers are
located in the domain.
The Windows 2003 Security Guide can be downloaded from Microsoft at:
http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-4D89-
B655-521EA6C7B4DB&displaylang=en
The guide provides you with complete hardening details and sample security templates for
testing, modification, and use.
Suggested server roles and accompanying templates are listed in Figure 81.
Security Templates
Server Roles Details
(Enterprise)
Domain controllers Active Directory domain domain controller.inf
controllers
Member servers Member servers that are located in member server baseline.inf
or below the member server OU
File servers Locked-down file servers file server.inf
Print servers Locked-down print servers print server.inf
Infrastructure servers Locked-down DNS, WINS, and infrastructure server.inf
DHCP servers
IAS servers Locked-down IAS servers ias server.inf
Certificate servers Locked-down CA servers ca server.inf
Bastion hosts Locked-down Internet servers bastion server.inf
IIS servers Locked-down IIS servers iis server.inf
Figure 81: Server Roles and Security Templates
OU Infrastructure Example
Figure 82: OU Infrastructure Example
Guidelines for creating OU infrastructure for member servers are as follows:

1. Create an OU called Member Servers.
2. Create child OUs for the member servers within your organization, in this
example: File_Servers, Print_Servers, Web_Servers, etc.
3. Create an OU called Network_Infrastructure.
4. Move all WINS, RIS, and DHCP servers into the Network_Infrastructure OU.
5. Create a global group called Network Infrastructure and add the required
administrative accounts to it.
6. Run the Delegation of Control wizard to give the Network Infrastructure group
full control of the OU.
OU Infrastructure Checklist
Figure 83: OU Infrastructure Checklist
Below are guidelines for creating a secure OU infrastructure for Notes

your domain users and groups using Group Policy security
features:
1. Create an OU infrastructure that mirrors your needs.
2. Move the servers into the OUs.
3. Create Administrative Groups for administration.
4. Add domain accounts into the newly created
Administrative Groups.
5. Delegate administration for each OU to the
appropriate groups.
6. Create GPOs within the OUs.
7. Link each GPO to any additional OUs as required.
8. Import security templates into the appropriate GPOs.
9. Set permissions on each GPO for the required control
or limitation that should be applied to the assigned
OU administrative groups.
10. Add groups to the Restrictive Groups.
11. Test your infrastructure for success or problems.
Domain Security
Three levels of security recommended by

Microsoft are:
z Domain
z Baseline
z Assigned server role
Figure 84: Domain Security
After OUs are used, security can be deployed at several levels within the domain.
Microsoft recommends that three levels be used for applying security to servers within the
domain:
Domain: Common account security requirements, account lockout, and
password policies
Baseline: Common server security applied to all servers within the domain
Assigned server role: Additional security settings for specific server roles
The types of security that can be applied through Active Directory using Group Policy are:
File system permissions
Registry permissions
System services
Auditing and event logs
Account and password policies
User right assignments
Deploying Domain Security

To import a domain policy security template, follow these steps:
1. In Active Directory Users and Computers, right-click the Domain icon at the
top of the tree and select Properties.
2. On the Group Policy tab, click New to add a new GPO.
3. Type Domain Security Policy and press ENTER.
4. Select Domain Security Policy and click Edit.
5. In the Group Policy window, click Computer Configuration\Windows
Settings. Right-click Security Settings and then select Import Policy.
6. In the Import Policy From dialog box, navigate to the directory where the
templates are stored and double-click the template that you want to import.
7. Close the Group Policy that has been modified.
8. Click the checkbox No Override to ensure that this policy is always applied
without modifications.
9. Close the Domain Properties window.
10. Force replication between your domain controllers so that all DCs have the
policy by doing the following:
For Windows 2000 systems, open a command prompt and use the
secedit.exe command-line tool to force the DC to refresh the domain
policy with the command:
secedit /refreshpolicy machine_policy /enforce
For Windows 2003 systems, open a command prompt and use the
gpupdate.exe command-line tool to force the DC to refresh the domain
policy with the command:
gpupdate / force
Final Checks
Verify in the Event Log that the policy downloaded successfully and that the server can
communicate with the other DCs in the domain. The event ID to search for is 1704:
Security policy in Group policy objects has been applied successfully.
By default, security settings are refreshed every 5 minutes on a domain controller, and
every 90 minutes on a workstation.
Make sure that this GPO has the highest priority by being the highest in the list, so that it
is deployed last.
Importing Domain Security

Use the following procedures to import a security template for domain security:
1. Log on to the domain controller with an account that has administrative rights.
2. Copy the desired template into the \%Systemroot%\Security\Templates.
3. Click Start, Programs, Administrative Tools, Domain Security Policy. This
opens the Domain Security Policy console.
4. In the console tree, right-click Security Settings and click Import Policy.
5. Find and select the security configuration template so that it appears in the File
name text box. Check the Clear this database checkbox and click the Open
button.
6. Close the Domain Security Policy.
7. Follow the procedures below to import a security template for domain
controllers.
Domain Controller Security

Use the following procedures to import a security template for domain controllers:
1. Log on to the domain controller with a domain account that has domain
administrative rights.
2. Copy the desired template into the \%Systemroot%\Security\Templates.
3. Click Start, Programs, Administrative Tools, Domain Controller Security
Policy. This opens the Domain Controller Security Policy console.
4. In the console tree, right-click Security Settings.
5. Click Import Policy.
6. Find and select the security configuration template so that it appears in the File
name text box. Check the Clear this database checkbox and click the Open
button.
7. Reboot the domain controller.
Controlling File Security through the ACL
Figure 85: Controlling File Security through the ACL
File systems security applies to all NTFS hard drive volumes, allowing you to centrally
define permissions on domain controllers, member servers, and Windows 2000 and
Windows XP computer systems.
Note
File system policy requires that a drive letter, and if necessary, a folder be used to identify
the volume and location of the file as shown in Figure 85.
Updating Registry Security Using ACLs
You can use ACLs to update registry security in

the following ways:
z Locking down registry permissions so users
cannot change local settings
z Adding user permissions to a key to allow
Windows software written before Windows
2000 to work.
z Adding or modifying permissions that are
required in your environment for older
software applications
Figure 86: Updating Registry Security Using ACLs
Have you ever wanted to control security permissions on the local computer registry of a
domain controller, member server, or user? With a registry policy you can.
One additional option that can be set after security has been modified on a selected
registry key is to select the checkbox Do not allow permissions on this key to be
replaced. This will protect the ACL set on this key from being modified by any other
GPO or process.
Registry settings are not modified by any of the optional security templates. The base
security level on the local registry is established during a clean installation of Windows
2000, Windows 2003, or Windows XP through the deployment of the setup security.inf.
Note
If the registry path is not in the domain controller where you want to push the registry
settings from, you will first have to add the registry path manually to the registry of the local
DC to provide a template to apply security to.
Controlling Network Services with Group Policy

In the system services policy folder you can control the access and startup to the installed
system services.
Defining who can start, stop, pause, or change particular services could provide an
additional level of control for domain controllers and member servers; in fact different
Group Policy settings could be defined on each node through the use of OUs.
Several system services that may merit consideration for additional control are:
Windows Time service: Ensure that clients do not set the incorrect time in
excess of the default 5-minute Kerberos time sync
Automatic Updates: Control access
Help and Support Service: May provide too much information and access to
remote assistance
Remote Registry: Should be disabled as a precaution
Telnet: Local access to a user workstation via Telnet is not required
Note
Another handy setting is to add the Help Desk to the security principals who can control the
print spooler and, therefore, provide assistance when this service needs to be reset.
Public Key Polices
Figure 87: Public Key Policies
Public key policy can be applied to both computer systems and users. Enabling policy
settings through a GPO allows you to specify the use of Microsoft certificate services in
relation to the computer and user components of a PKI implementation.
This policy is only effective if you are using Microsoft certificate services and structure;
otherwise it will not have any value for you at all.
Considering that the Microsoft certificate service is based on RSA security, it is too early
to say they will not succeed.
Per Machine Public Key Policy Notes
The following policies can be implemented on the computer

object:
Encrypted data recovery agents: This setting lets
you specify the users and groups that will be defined
as recovery agents and allowed to decrypt files that
have been encrypted using the encrypted file system.
Automatic certificate request settings: This setting
lets you define the computer systems that will receive
public key certificate from active directory.
Trusted root certification authorities: This setting
allows you to import lists of trusted public key
certificates, certificate authorities, or certificate
revocation lists.
Enterprise trust: This setting allows you to assign a
CTL to computer systems that will be subjected to
this policy. A CTL is a list of root CAs.
Per User Public Key Policy

A public key policy lets you assign a certificate trust list to all
users who are covered by this GPO.
Notes Enforcing an Audit Policy
z Audit policy can be defined at the site, domain,

or OU GPO.
z Administrators can monitor user and system
activity for many security-related activities,
including:
T Account logon
T Account management
T Directory service access
T Object access
z Events that are triggered by the audit are
stored in the Event Viewer security log.
Figure 88: Enforcing an Audit Policy
An audit policy defined at the domain level affects all users,

groups, and computer objects in the domain. An audit policy
assigned to a site or OU affects only the user or computer
accounts within that site or OU. Your audit trail can generate
success events, failure events, or both.
Enabling your company audit policy is a two-step process:
1. The ability to audit is enabled.
2. The audit trail (success or failure) is established
Account Logon Events

After they are enabled, all domain user account logons are tracked. There is not an account
logoff event that is logged. Figure 89 lists some of the event IDs registered in the Security
Event Log for logon events.
Event ID Description
672 An AS ticket was successfully issued and validated.
673 A TGS ticket was granted.
674 A security principal renewed an AS ticket or TGS ticket.
675 Pre-authentication failed with an incorrect password.
678 An account was successfully mapped to a domain account.
681 Logon failure. A domain account logon was attempted.
682 A user has reconnected to a disconnected terminal server
session.
683 A user disconnected a terminal server session without
logging off.
Figure 89: Logon Event IDs
Note
After enabling auditing, make sure that your security log has been sized properly to
accommodate the additional entries.
Account Management
Once enabled, the creation, modification, and deletion of security principals (user
accounts, groups, and computer accounts, including associated settings) are monitored. It
is recommended that both success and failure be enabled to track users who attempt
actions that they are not allowed to perform but still try. Figure 90 below lists some of the
event IDs registered in the Security Event Log for account management.
624 A user account was created.
627 A user password was changed.
628 A user password was set.
630 A user account was deleted.
631 A global group was created.
632 A member was added to a global group.
633 A member was removed from a global group.
634 A global group was deleted.
635 A new local group was created.
636 A member was added to a local group.
637 A member was removed from a local group.
638 A local group was deleted.
639 A local group account was changed.
641 A global group account was changed.
642 A user account was changed.
643 A domain policy was modified.
644 A user account was automatically locked.
645 A computer account was created.
646 A computer account was changed.
647 A computer account was deleted.
649 A local security group with security disabled was changed.
668 A group type was changed.
684 The security descriptor of administrative group members was set.
685 Name of an account was changed.
Figure 90: Account Management Event IDs
Directory Service Access

When a user accesses an Active Directory object that has an SACL added to the audit trail,
an audit entry will be added to the Security Event log. The event ID is 566: A generic
object operation tool place.
Logon Events
Logon events track user logons to all computers in your enterprise. Do not confuse this
setting with the previous Account Logon events which tracked the domain account logon.
Logon events that can be tracked are listed in Figure 91.
528 A user successfully logged on to a computer.
529 Logon failure. A logon attempt was made with an unknown user name or a known user name
with a bad password.
530 Logon failure. A logon attempt was made outside the allowed time.
531 Logon failure. A logon attempt was made using a disabled account.
532 Logon failure. A logon attempt was made using an expired account.
533 Logon failure. A logon attempt was made by a user who is not allowed to log on at the
specified computer.
535 Logon failure. The password for the specified account has expired.
536 Logon failure. The Net Logon service is not active.
538 The logoff process was completed for a user.
539 Logon failure. The account was locked out at the time the logon attempt was made.
540 A user successfully logged on to a network.
545 Main mode authentication failed because of a Kerberos failure or a password that is not valid.
548 Logon failure. The SID from a trusted domain does not match the account domain SID of the
client.
Figure 91: Logon Events
Notes Object Access

The event of a user accessing an object such as a folder, file,
registry key, printer, or any object contained on an NTFS file
system can be monitored if it has a defined SACL added to the
audit trail.
Any security principal (user, computer, or group) can be
monitored. Success creates an audit entry in the Security Event
log every time access is successful; failure also creates an audit
entry indicating an unsuccessful attempt.
Object access and directory service access should be enabled
together as access to most objects starts through accessing
published Active Directory objects. Object access events that can
be tracked are listed in Figure 92.
560 Access was granted to an already existing object.
563 An attempt was made to open an object with the intent to
delete it.
564 A protected object was deleted.
565 Access was granted to an already existing object type.
570 A client attempted to access an object.
Figure 92: Object Access Events
Policy Change Notes
Every incident of change to user rights assignments, audit

policies, and trust policies can be monitored for successful
change and failure to change the rights and policies assigned.
Failure generates an audit entry for every failed change that was
attempted. Policy change events that can be tracked are listed in
Figure 93.
608 A user right was assigned.
609 A user right was removed.
610 A trust relationship with another domain was created.
611 A trust relationship with another domain was removed.
612 An audit policy was changed.
613 An IPSec policy agent started.
618 EDRP changed.
620 A trust relationship with another domain was modified.
621 System access was granted to an account.
622 System access was removed from an account.
Figure 93: Policy Change Events
Notes Privilege Use

This setting allows you to track every instance of a user actually
using their assigned user rights. Both success and failure audits
can be enabled. Privilege use events that are not tracked, even
when enabled, because of excessive logging are:
Bypassing traverse checking
Debugging programs
Creating a token object
Replacing process level token
Generating security audits
Backing up files and directories
Restoring files and directories
Note
Before enabling an audit trail, make sure that your event logs on
all servers are sized accordingly. This should be set at the default
domain GPO so as to apply to all computer systems in the
domain, including clients, member servers, and domain
controllers. Carefully examine size factors and overwrite times.
Restricting Security Group Notes
Membership
Figure 94: Restricting Security Group Membership
Restricted group membership has the following characteristics:

Restricted groups is a component of security policy
that allows you the ability to define certain security
groups that have a locked set of members.
After the group has been added to the restricted
groups folder, no additional members can be added or
removed
You can also mandate that a particular user group is
always a member of another group
If a user account is added to a restricted group by
mistake, or on purpose, the next time the GPO is
processed, the unauthorized user account will be
removed from the group.
Restrictive Groups
The most common use of this feature is ensuring that the Administrators, Enterprise
Admin, and Schema Admin membership list remains static.
The less common, but still useful, method of using this feature is to determine which user
cannot be removed from another group or groups.
Suppose that you want to ensure that the selected Help Desk support members remain a
part of the Help Desk group. Adding the Help Desk support group to restricted groups
accomplishes this purpose.
Restrictive groups are modified automatically only when the compatws.inf or the
secure.inf templates are used; they both prohibit adding users to the Power Users group.
Note
A clean install of Windows 2000, Windows 2003, or Windows XP uses the setup
security.inf, which adds Authenticated Users and the Interactive user account to the Users
local group.
Using Scripts
Windows 2000 and Windows 2003 support five

types of scripts:
z Computer startup scripts
z Computer shutdown scripts
z User logon scripts
z User Policy logoff scripts
z Legacy logon scripts
Figure 95: Using Scripts
Legacy script support was MS-DOS based only; Windows 2000 and Windows 2003 now
support five types of scripts in many formats including .vbs and .js.
Scripts can be manually executed from the GUI or fully automated from a command
window.
Windows Scripting Host is built in to the OS and supports many other 32-bit third-party
languages.
Computer Startup Scripts

GPOs support computer-specific startup and shutdown scripts. When a workstation or
server is located in an OU, it runs the assigned script in the context of the local user
account.
Computer Shutdown Scripts

After the computer or server shuts down, it runs any shutdown scripts that have been
assigned to the GPO.
One handy option with a shutdown script is communication with administrators; for
example, if a server shuts down without warning, the script could send an e-mail
communication to a specific mailbox.
User Startup and Shutdown Scripts

Logon scripts are scripts that apply to a user account that can be contained at the site,
domain, or OU container, or all of these locations.
Processing Order
Since scripts are supported at sites, domains, and OUs, a computer system could have
many scripts to process.
Figure 96 and Figure 97 list the Group Policy options that are available to control the
behavior of scripts.
Policy in Computer
Configuration\Administrative Description
Templates\System\Logon
Run logon scripts synchronously When this option is enabled, the system waits until the script
finishes running before it starts Windows Explorer. The
equivalent option for this is available under the User
Configuration node. The policy setting you specify in the
Computer Configuration node has precedence over that
set in the User Configuration node.
Run startup scripts asynchronously By default, startup scripts run synchronously and hidden,
which means that the user cannot log on until the scripts
complete. In some corporations, the administrator might want
the scripts to run asynchronously since they could take a
long time to complete. This policy allows the administrator to
change the default behavior.
Run startup scripts visible If this option is enabled, startup scripts run in a command
window.
Run shutdown scripts visible If this option is enabled, shutdown scripts run in a command
window.
Maximum wait time for Group Policy This policy setting lets you change the default script timeout
scripts period. (By default, scripts will time out after 600 seconds.)
The range is 0 to 32000 seconds.
Figure 96: Computer Scripting Control
Policy in User
Configuration\Administrative Description
Templates\System\Logon\Logoff
Run logon scripts synchronously When you enable this option, Windows waits for the scripts to
finish running before it starts Windows Explorer.
Note that an equivalent option for this is available under the
Computer Configuration node. The policy setting you specify
in the Computer Configuration node has precedence over
that set in the User Configuration node.
Run legacy logon scripts hidden If this option is enabled, legacy logon scripts will run in
hidden mode.
Run logon scripts visible If this option is enabled, logon scripts run in a command
window.
Run logoff scripts visible If this option is enabled, logoff scripts run in a command
window.
Figure 97: User scripting control
Note
Enabling the setting Disable the Command prompt found in User Configuration\
Administrative Templates\System can stop legacy batch files from executing.
Managing Printers: Printer Pruning
z After printers are published in Active Directory,

users can search for the printers required.
z You can also stop printers from being
published through Group Policy.
Figure 98: Enabling site location
Printer Location Tracking

After a printer is published, additional location information can be entered, making it easy
to locate a printer that is physically closest to you.
First, sites and site location tracking must be properly enabled and completed. When the
user then searches for and locates a suitable printer; right-clicking and selecting Connect
installs the printer on the local machine.
These are the steps to enable printer location tracking:
1. Open the Active Directory Sites and Services console and select the subnet
object for which you wish to enable printer tracking.
2. From the subnets properties, select the Location tab and enter the location
value for this subnet, for example Main Office/2nd Floor.
3. Next, use the Group Policy Editor to enable the pre-populate printer search
location text policy at the domain, site, or OU level.
4. On your print server, open the properties of each printer.
5. On the General tab, fill in the printer location, or click Browse to display the
available locations.
6. Add additional details to the printer location, for example Main Office/2nd
Floor/By Presentation Room 3.
This completes printer location tracking and allows users to find printers closest to them.
When installing printer drivers with the Add Printer Wizard, the wizard will search for a
printer in the Directory, and fill in the location of the printer based on the current location
of the user.
Section Summary Notes
This section completes the design phase of deploying Group

Policy and focuses on security design at the domain and OU. It
also details how to deploy security templates and NTFS security
for files, folders, and registry hives using Group Policy.
Knowledge
Check
Section Review
1. Which three levels of domain security are recommended by Microsoft?
2. Which event ID indicates that security policy has been applied successfully?
3. Can registry policy override attempts to change permissions? If so, how?
4. How do account logon events differ from logon events?
5. List the two key features provided by restrictive groups policy.
6. List the four types of scripts that can be deployed through Group Policy.
ABC Acronyms

AS authentication service
CA certification authority
CTL certificate trust list
EDRP Encrypted Data Recovery Policy
IIS Internet Information Server
IPSec Internet Protocol security
OS operating system
PKI public key infrastructure
RSA Rivest, Shamir, and Adelman
SACL system access control list
TGS ticket-granting service
WINS Windows Internet Naming Service
Explorer Shell Group Policy
Section Topics
Scripts for Clients
Desktop, Start Menu, and Taskbar Control
Control Panel Control
Windows Components
Controlling User Profiles
Folder Redirection
Printer Management and Pruning
Computer Network Settings
N Knowledge
Guide
W E
Section Objectives
S

Specify startup, shutdown, logon, and logoff scripts and settings
Identify the many ways to control the user desktop, Start menu, and taskbar
Restrict the Control Panel
Restrict operations that users can perform in Windows Explorer, My
Computer, and My Network Places
Control what users can do in the Internet Explorer environment
Control what users can do with Terminal Services
Customize processing of user profiles and roaming user profiles
Redirect user folders based on user name and security group membership
Fine-tune network settings
Control printers and printer pruning
Section Overview
Most people are familiar with Group Policy and its predecessor System Policies in
Windows NT, Windows 95, and Windows 98 as a way of locking down the desktop. In
fact, Group Policy is a great tool for controlling the user environment: to add functionality,
to provide consistency within OUs or domains, and to keep users out of utilities and
settings that they do not need.
Scripts for Clients

Startup and Shutdown Scripts
Figure 99: Startup and Shutdown Scripts
A startup script runs when a Windows computer boots, using the Local System security
context. A shutdown script runs when a Windows computer is shut down (Start, Shut
Down), again using the Local System security context.
You can use Group Policy to specify which (if any) startup and shutdown scripts you want
to run. The scripting language can be any language supported by the WSH engine.
Common choices are:
VBScript (suffix .vbs)
JScript (suffix .js)
Batch files (suffix .cmd or .bat)
Startup and shutdown scripts are potentially useful tools for configuring the user
environment. You might use these scripts (as opposed to logon or logoff scripts) where
you need broader security capabilities than might be supplied by the User account type.
Notes Specify one or more scripts to run in the following Group Policy
console location: Computer Configuration, Windows Settings,
Scripts (Startup/Shutdown)
You can specify parameters for your scripts, as well, in the Group
Policy dialog box. The parameters would be the same as what
you would specify in a command window. You may also edit
your scripts from this dialog box.
Logon and Logoff Scripts
z A logon script runs when a user logs on to a

Windows computer, using the User security
context.
z A logoff script runs when the user logs off,
again using the User security context.
Figure 100: Logon and Logoff Scripts
You can use the same script languages for logon and logoff as you do for startup and
shutdown; for example, VBScript, Jscript, and batch files.
Logon scripts have many uses in configuring the user environment. For example, you may
wish to use a logon script to perform one or more of the following tasks:
Map drives (for example, with net use x: \\server\share)
Populate the Printers folder (for example, with
WshNetwork.AddWindowsPrinterConnection)
Set the default printer (for example, with WshNetwork.SetDefaultPrinter)
Specify one or more scripts to run in the following Group Policy console location:
User Configuration, Windows Settings, Scripts (Logon/Logoff)
Note
Script processing is handled by the client-side extension gptext.dll.
Notes Script Control: MMC

All scripts, by default, live in the Sysvol share and are replicated
from domain controller to domain controller by the FRS.
You can control who can designate scripts for policy processing
by controlling the MMC: User Configuration, Administrative
Templates, Windows Components, Microsoft Management
Console, Restricted/Permitted snap-ins, Group Policy,
Scripts (Logon/Logoff), Scripts (Startup/Shutdown)
If you explicitly disable or enable script processing in
the policy setting above, then the setting in User
Configuration, Administrative Templates,
Windows Components, Microsoft Management
Console, Restrict users to the explicitly permitted
list of snap-ins does not matter.
If you do not configure script processing in the policy
setting above, then if you have enabled the policy
User Configuration, Administrative Templates,
Windows Components, Microsoft Management
Console, Restrict users to the explicitly permitted
list of snap-ins, the scripting node will not appear in
the Group Policy console because scripting has not
been explicitly enabled (permitted).
Script Control: System

You can also control certain aspects of how scripts execute in the Administrative
Templates, System, Scripts nodes (see Figure 101) in both Computer Configuration
and User Configuration.
Note
If these settings are configured in both halves of the Group Policy console, then the
computer half takes precedence.
Figure 101: Script Control: System
Synchronous versus asynchronous execution simply means:

Synchronous: Will Windows wait until the script has completed before
moving on to the next step?
Or
Asynchronous: Should Windows go ahead and perform the next step, such as
loading the desktop, before the script has finished executing?
You can also use these policies to control whether the scripts run visible (not the default),
and how long Windows should wait before canceling script execution (the default is 10
minutes).
Desktop, Start Menu, and Taskbar Control

Defining the user desktop, including the Start menu and taskbar, is one of the most
familiar aspects of Group Policy.
Desktop Restrictions
Most of the desktop restrictions are to be found in the User Configuration half:
User Configuration, Administrative Templates, Desktop
Restriction Description
Hide and disable all items on the desktop Removes icons, shortcuts, and other default and user-
defined items from the desktop, including Briefcase,
Recycle Bin, My Computer, and My Network Places
Remove My Documents icon on the desktop Self-explanatory
Remove My Computer icon on the desktop Self-explanatory
Remove Recycle Bin icon from the desktop Self-explanatory
Remove Properties from the My Documents Self-explanatory
context menu
Remove Properties from the My Computer Self-explanatory
context menu
Remove Properties from the Recycle Bin Self-explanatory
context menu
Hide My Network Places icon on desktop Self-explanatory
Hide Internet Explorer icon on desktop Self-explanatory
Do not add shares of recently opened Self-explanatory
documents to My Network Places
Prohibit user from changing My A good idea if you are using folder redirection
Documents path
Prevent adding, dragging, dropping, and Self-explanatory
closing the toolbars of the taskbar
Prohibit adjusting desktop toolbars Self-explanatory
Don't save settings at exit Only affects some changes to the desktop, such as the
position of open windows and the size and position of
the taskbar
Remove the Desktop Cleanup Wizard Denies users access and disables automatic 60-day
runs of the wizard
Active Desktop Various settings under this node, including enabling
and disabling Active Desktop
Active Directory Various settings under this node, including enabling
and disabling the filter bar in Active Directory searches
Figure 102: Desktop Restrictions
Start Menu Restrictions

Some of the myriad Start menu restrictions match up with many of the desktop restric-
tions, which makes sense because several icons may appear in both places by default in
Windows 2000 and Windows XP Professional. This category is important in defining the
computing environment of the user.
Location: User Configuration, Administrative Templates, Start Menu, Taskbar
Remove user's folders from the Start menu Hides all folders on the user-specific (top) section
of the Start menu (other items appear though) to
avoid duplication when folder redirection is used
Remove links and access to Windows Update One of the most popular policies; helps prevent
users from applying patches and updates that the
organization has not tested; blocks user access to
the Windows Update Web site at http://window-
supdate.microsoft.com; also removes the
Windows Update hyperlink from the Start menu
and from the Tools menu in Internet Explorer.
Remove common program groups from Not common as in ordinary, but as in items in
Start menu the All Users profile
Remove My Documents icon from Start Menu Self-explanatory
Remove Documents menu from Start Menu Self-explanatory
Remove programs on Settings menu Prevents Control Panel, Printers, and Network
Connections from running, although users can
still get to certain control panels via context
menus
Remove Network Connections from Start menu Self-explanatory
Remove Favorites menu from Start menu Self-explanatory
Remove Search menu from Start menu Self-explanatory
Remove Help menu from Start menu But users can still run Help various other ways
Remove Run menu from Start menu Self-explanatory
Remove My Pictures icon from Start menu Self-explanatory
Remove My Music icon from Start menu Self-explanatory
Remove My Network Places icon from Self-explanatory
Start Menu
Add Logoff to the Start Menu Note: also removes the user's ability to remove
the entry
Remove Logoff on the Start Menu Similarly, removes the entry and prevents the user
from re-adding it
Remove and prevent access to the Shut Down Removes the Shut Down option from the Start
command menu and disables the Shut Down button on the
Windows Security dialog box; useful for kiosk
situations, for example
Remove drag-and-drop context menus on the Start Prevents users from using drag-and-drop to
menu reorder or remove items on the Start menu;
removes context menus
Do not keep history of recently opened documents Prevents the OS and installed programs from
creating and displaying shortcuts to recently
opened documents, but does not clear all MRU
lists
Clear history of recently opened documents Ensures that the Documents menu on the Start
on exit menu is always empty right after logon
Turn off personalized menus An important restriction (those automatic
disappearing menu items have confused more
than their share of novice users) but does not
affect individual applications
Turn off user tracking Prevents the system from tracking the programs
that users run, the paths that they navigate, and
the documents that they open, for example, to
allow creation of personalized menus
Add Run in Separate Memory Space checkbox Allows users to specify that a 16-bit application
to Run dialog box should run in its VDM
Gray unavailable Windows Installer programs Forces partially-installed applications, such as
Start menu shortcuts those assigned via Group Policy but not yet
installed, to show up in gray; performance issues
with this setting have been observed, so testing is
advisable
Force classic Start menu Displays the classic Start menu in the Windows
2000 style and displays the standard desktop
icons
Remove Balloon Tips on Start menu items Disables the hover messages, not just on the
Start menu but also in the system tray
Remove frequent programs list from the Useful if you want to simplify the rather bloated
Start menu Windows XP-style Start menu
Remove All Programs list from the Start menu Windows XP only
Remove user name from Start menu Self-explanatory
Figure 103: Start Menu Restrictions
Taskbar Restrictions
Technically, the Start menu is part of the taskbar, but the following text covers taskbar
restrictions that do not involve the Start menu directly.
Location: User Configuration, Administrative Templates, Start Menu, Taskbar
Prevent changes to Taskbar and Start Menu Removes the Taskbar & Start Menu item from
settings Settings on the Start menu and prevents the user
from opening Taskbar Properties
Remove access to the context menus for the Hides the menus that appear when you right-click the
Taskbar taskbar and items on the taskbar
Prevent grouping of Taskbar items Disables the consolidation of multiple program
instances into a single taskbar entry with a number (n)
after it
Turn off notification area cleanup Removes the automatic collapsing of inactive system
tray icons
Lock the Taskbar Prevents the user from moving or resizing the taskbar
(auto-hide and other taskbar options are still available)
Remove clock from the system notification That is, the system tray. Seemingly straightforward,
area but watch out, the clock sometimes does not want to
come back if this policy is later reversed.
Hide the notification area Again, what we called the system tray before Windows
XP
Do not display any custom toolbars in the If enabled, the taskbar does not display any custom
taskbar toolbars, and the user cannot add any custom toolbars
to the taskbar; plus, the Toolbars menu and submenu
are removed from the context menu
Figure 104: Taskbar Restrictions
Control Panel Control

Much of the Windows user environment is governed by the Control Panel. Keeping users
away from the Control Panel, or at least from certain parts of it, is a good way to ensure
that there are no problems.
Deciding how much of the Control Panel to restrict is always a balance between what
users legitimately may need to change (for example, on a laptop, networking settings) and
what can create problems if set incorrectly (networking settings again!).
Top-Level Controls
Location: User Configuration, Administrative Templates, Control Panel
Prohibit access to the Control Panel Prevents control.exe from starting; users cannot start
Control Panel or run any Control Panel items. Also
removes Control Panel from the Start menu and
removes the Control Panel folder from Windows
Explorer
Hide specified Control Panel applets To find the file name of a Control Panel item, search
for files with the .cpl file name extension in
%Systemroot%\System32; does not affect the
categories that are displayed in the new Control Panel
Category view in Windows XP
Show only specified Control Panel applets The inverse of the previous setting; which setting you
use depends on whether your organization operates
on a need to know basis or need to withhold
Force Classic Control Panel Style That is, Windows 2000-style, as opposed to the newer
Windows XP-style, which Microsoft says is simpler but
which takes more clicks to get anything done
Figure 105: Top-Level Controls
Add/Remove Programs
Location: User Configuration, Administrative Templates, Control Panel,
Add/Remove Programs
Remove Add/Remove Programs Programs Disables user access to the Add/Remove
Programs wizard, but does not prevent users from
installing applications in other ways
Hide Change or Remove Programs Page Removes the Change or Remove Programs
button from the Add or Remove Programs bar,
so users cannot view or change the attached
page, for example, to uninstall, repair, add, or
remove features of installed programs
Hide Add New Programs Page Removes the Add New Programs button from the
Add or Remove Programs bar, so users cannot
view or change the attached page, for example, to
install programs published or assigned by a
system administrator
Hide Add/Remove Windows Components Page Self-explanatory
Hide the Add a Program from CD-ROM or floppy Removes the specified section from the Add New
disk option Programs page. This prevents users from using
Add or Remove Programs to install programs
from removable media
Hide the Add Programs from Microsoft option Self-explanatory
Hide the Add Programs from Your Network Self-explanatory
option
Go directly to Components Wizard Removes the Set up services section of the Add/
Remove Windows Components page, which
section lists system services that have not been
configured and offers users easy access to config-
uration tools
Remove Support Information Removes links to the Support Info dialog box from
programs on the Change or Remove Programs
page; you may consider this if you want all support
to come from an internal helpdesk, for example
Specify default category for Add New Programs Specifies the category of programs that appears
when users open the Add New Programs page;
only the programs in the category you specify are
displayed when this page opens
Figure 106: Add/Remove Programs
Display Control
Location: User Configuration, Administrative Templates, Control Panel, Display
Remove Display in Control Panel Self-explanatory
Hide Desktop tab Users cannot use Control Panel to change the pattern
and wallpaper on the desktop, nor can they customize
the desktop by changing icons or adding new Web
content
Prevent changing wallpaper Self-explanatory
Hide Appearance and Themes tab Self-explanatory
Hide Settings tab Users cannot change settings such as display size,
color bit depth, refresh rate, etc.
Hide Screen Saver tab Users cannot change the screen saver setting
Screen Saver Enable this and Windows runs the screen saver
specified in the following policy; disable it, and no
screen saver runs
Screen saver executable name The name (including the .scr suffix) of the screen
saver you want to run on the user machine, and which
disables all other user choices
Password protect the screen saver Only applies if you have chosen to specify a particular
screen saver in the preceding policy
Screen saver timeout Length of time before the screen saver kicks in
Desktop Themes Subnode containing options to control the display and
behavior of the Themes tab in Windows XP
Figure 107: Display Control
Printer Control
Location: User Configuration, Administrative Templates, Control Panel, Printers
Browse a common Web site to find printers Adds a Browse button on the Locate Your Printer
page of the Add Printer Wizard, pointing to a Web
page that you build to centralize printer locations
Browse the network to find printers Lets users search for printers; disabling forces users
to specify exact printer name
Default Active Directory path when searching The Active Directory container where user searches
for printers for printers begins
Point and Print restrictions Specifies where users can download printer drivers
automatically: specific servers, or anywhere in the
forest
Prevent addition of printers Restricts users to the environment that you define
Prevent deletion of printers Restricts users to the environment that you define
Figure 108: Printer Control
Regional and Language Options

Location: User Configuration, Administrative Templates, Control Panel, Regional
and Language Options
There is only one setting here, Restrict selection of Windows menus and dialogs
language, which when enabled prevents the user from changing the default language.
Windows Components
Windows Explorer
Figure 109: Windows Explorer
Microsoft has put many desktop restrictions in the nodes you already examined, to be
sure, but many more exist under a sort of umbrella node called Windows Components,
which appears in both the User Configuration and Computer Configuration nodes (see
Figure 109).
Helpful Hint
Exactly how Microsoft decided to put certain settings in Windows Components and others
in, say, Desktop is cloaked in a certain amount of mystery. The My Computer settings in
Windows Components\Windows Explorer, for example, are arguably as much desktop
settings as anything in the Desktop subnode. So, do not to try and make sense of the
organization (or lack thereof). Instead, just remember that Windows
Components\Windows Explorer has a lot of settings that affect the desktop shell.
Location: User Configuration, Administrative Templates, Windows Components,

Windows Explorer
Turn on Classic Shell Disables Active Desktop as well as the ability to set
the shell to open icons with single-clicking
Remove the Folder Options menu item from Useful for restricting the ability of the user to see
the Tools menu hidden and system files, among other things
Remove File menu from Windows Explorer Not as restrictive as you might think, but does make
some file operations less convenient for users
Remove Map Network Drive and Removes the Map Network Drive and Disconnect
Disconnect Network Drive Network Drive commands from the toolbar and Tools
menus in Windows Explorer and My Network
Places and from menus that appear when you right-
click the Windows Explorer or My Network Places
icons; removes the Add Network Place option from
My Network Places; does not prevent users from
connecting to shares from the Run dialog box
Remove Search button from Windows Affects Windows Explorer, My Computer, and My
Explorer Network Places, but not Internet Explorer (for
example)
Remove Windows Explorer's default Self-explanatory
context menu
Hides the Manage item on the Windows An excellent idea if you want to prevent users from
Explorer context menu accessing the Computer Management console
(compmgmt.msc)
Hide these specified drives in My Computer Removes the icons representing selected hard drives
from My Computer and Windows Explorer and
removes the drive letters representing the selected
drives from the standard Open dialog box
Prevent access to drives from My Computer Prevents users from viewing the contents of the
selected drives in My Computer or Windows Explorer;
also prevents them from using the Run dialog box, the
Map Network Drive dialog box, or the dir command to
view the directories on these drives
Remove Hardware tab Removes the Hardware tab from Mouse, Keyboard,
and Sounds and Audio Devices in Control Panel,
and from the Properties dialog box for all local drives,
including hard drives, floppy disk drives, and CD-ROM
drives
Remove DFS tab Removes the tab from Windows Explorer and My
Computer, restricting access to the Distributed file
system
Remove Security tab Removes the tab from files, folders, drives, and
shortcuts, restricting access (for example) to NTFS
access control lists
Remove UI to change menu animation setting Prevents users from accessing the transitional effects
for menus and tool tips
No Computers Near Me in My Network Self-explanatory
Places
No Entire Network in My Network Places Self-explanatory
Maximum number of recent documents Limits the number of documents that will appear in the
Documents MRU list
Do not request alternate credentials This means when installing programs onto a system
where the user is not logged on as the local
administrator
Request credentials for network installations This means when installing programs over the network
Remove CD burning features That is, from Windows Explorer, but not from other
applications that the user may have installed on the
computer
Do not move deleted files to the Recycle Bin Very risky setting but one that some organizations with
high security requirements might use: when you delete
something, and this setting is enabled, there's no
turning back
Display confirmation dialog when deleting Self-explanatory
files
Maximum allowed Recycle Bin size Self-explanatory
Remove Shared Documents from My Self-explanatory
Computer
Turn off caching of thumbnail pictures Another security-related setting; thumbnail caches are
available to other users, even if the pictures that they
cache are not
Common Open File Dialog A subnode that lets you customize a few features of
the standard Open window
Figure 110: Windows Explorer Settings
Internet Explorer
Figure 111: Internet Explorer
The sheer volume of Internet Explorer settings in the Group Policy console is impressive.
The Computer Configuration node contains a few settings dealing with security zones
(see Figure 111) and other per-computer policies.
Computer Configuration Settings

Location: Computer Configuration/Administrative Templates/Windows
Components/ Internet Explorer
Security Zones: Use only machine Not especially obvious, this means that any security zone
settings changes that a user might make would apply to all users of
the computer.
Security Zones: Do not allow users to Prevents users from changing security zone settings and
change policies disables the Custom Level button and security-level slider
on the Security tab in the Internet Options dialog box
Security Zones: Do not allow users to That is, the site list is fixed
add/delete sites
Make proxy settings per-machine (rather That is, users cannot change the proxy settings on a user-
than per-user) by-user basis
Disable Automatic Install of Internet A setting to consider if your organization likes to test
Explorer components software updates before letting users receive them
Disable Periodic Check for Internet A setting to consider if your organization likes to test
Explorer software updates software updates before letting users receive them
Disable software update shell notifica-
tions on program launch
Disable showing the splash screen Self-explanatory
Figure 112: Computer Configuration Settings
User Configuration Settings

The User Configuration node has the bulk of the Internet Explorer settings. They are
shown here in Figure 113 and Figure 114.
Location: User Configuration/Administrative Templates/Windows Components/
Internet Explorer
Figure 113: User Configuration Settings
As you can see, most of the settings immediately under the Internet Explorer node have
to do with disabling various capabilities, such as customizing the search capability,
importing favorites, changing the home page, changing browser cache settings, history
settings, content ratings, and so forth.
Figure 114: User Configuration Settings (cont.)
Pay particular attention to the AutoComplete policies: Disable AutoComplete for forms
and Do not allow AutoComplete to save passwords. Security-conscious shops should be
aware of these settings.
Internet Explorer Subnodes

Internet Control Panel
Figure 115: Internet Control Panel
You will notice several subnodes beneath Internet Explorer. The Internet Control Panel
node allows you to selectively disable individual control panel pages (see Figure 115).
Offline Pages
Figure 116: Offline Pages
The Offline Pages subnode (see Figure 116) allows you to set policies for channels
(formerly known as active channels) and offline pages, including the ability to
download sites at specified schedules for viewing later when (possibly) disconnected from
the Internet.
Browser Menus
Figure 117: Browser Menus
The Browser menus subnode (see Figure 117) lets you disable various commands from
the File, View, Tools, and Help menus within the browser window.
Toolbars
Figure 118: Toolbars
The Toolbars subnode lets you disable reconfiguring of the browser toolbars or specify
just which buttons users can see (see Figure 118).
Persistence Behavior
Figure 119: Persistence Behavior
The Persistence Behavior subnode lets you specify a maximum size for sites using
persistence, broken out by zone.
Administrator Approved Controls
Figure 120: Administrator Approved Controls
Finally, the Administrator Approved Controls subnode (see Figure 120) lets you
designate specific ActiveX controls as administrator-approved for purposes of the Run
ActiveX Controls and Plug-ins area in the definition of your security zones.
IEAK Settings
Figure 121: IEAK Settings
Some years back, Microsoft introduced its Internet Explorer Administration Kit, or
IEAK. The company has folded the IEAK settings into the Group Policy interface but
not into either of the Windows Components nodes. These settings reside under User
Configuration/Windows Settings/Internet Explorer Maintenance. You will notice
some overlap between some of these settings and the ones previously described.
Browser User Interface: Contains settings for title, logo, and toolbar,
including the ability to remove specific toolbar buttons if desired.
Connection: Allows you to prepopulate most of the fields in the Connections
tab of the Internet Explorer control panel.
URLs: Provides a way for you to preselect favorites, links, the search page, the
home page, and the online support URL in the help system.
Security: Lets you predetermine Security Zones and Content Ratings
settings as well as locking down the ability of the user to add trusted sources.
Programs: Lets you prepopulate most of the fields in the Programs tab of the
Internet Explorer control panel, where for example you can specify a preferred
e-mail client, newsreader, etc.
Terminal Services
Figure 122: Terminal Services
The bulk of the Terminal Services policies appear in the Computer Configuration node,
although you can set a few timeouts in the User Configuration node (which will be
overridden if they are also set in the computer half). In addition to the policies shown in
Figure 122, various subnodes provide access to specific restrictions, as follows:
Client/Server data redirection: You can control redirection of COM ports,
LPT ports, drives, etc.
Encryption and Security: You can set the default client encryption level.
Licensing: You can prevent a license upgrade.
Temporary folders: You can turn per-session temp folders off, so that the
Local Settings\Temp folder is always used instead.
Session Directory: You can designate a server to be used as a session logger
for reestablishing user connections.
Sessions: You can set limits for active, idle, and disconnected sessions.
Other Windows Components

The Windows Components nodes under Computer Configuration and User Configuration
include other categories than the three that you just looked at in detail. These other nodes
can also affect the desktop shell of the user, although most pertain to specific applications
or applets. They are, in alphabetical order:
Microsoft Management Console: (User) Here, you can prevent users from
entering Author mode and control the snap-ins that users can access by
creating a restricted and permitted list. This is an important category that is
worth some thought on your part, given the power of the various MMC
snap-ins.
NetMeeting: (Computer and User) By far the bulk of the NetMeeting settings
are in the user half; some of these can limit what users can do during
NetMeeting sessions: send files, receive files, use the chat feature, use the
whiteboard feature, and so forth. There are subnodes for application sharing,
audio/video, and options to control which pages users can access.
Task Scheduler: (Computer and User) There are various settings here, such as
preventing users from creating new tasks, preventing them from deleting
existing tasks, etc. The settings list is the same in both halves; the computer
half takes priority in the event of a conflict.
Windows Installer: (Computer and User) This area has to do with software
installation settings.
Windows Media Player: (Computer and User) Here are a few settings for
controlling when Windows Media Player is allowed to go out to the Internet
(for example, to download a codec), what the user interface looks like, and
how to handle media streamed over the network.
Windows Messenger: (Computer and User) These settings let you disable the
Windows Messenger service entirely or not let the service start automatically,
as it does by default. The settings list is the same in both halves; the computer
half takes priority in the event of a conflict.
Windows Update: (User) The sole entry here is Remove access to use all
Windows Update features.
Notes Controlling User Profiles

Many of the settings, such as Start menu and desktop settings,
become registered in the user-specific part of the registry,
NTUSER.DAT, which, in turn, is part of the user profile.
In some organizations, user profiles are allowed to roam with
the user, that is, follow him or her around the network from a
server share. Particularly in those cases, Group Policy settings for
managing user profiles may become a significant part of the
computing experience of the user. Some of these settings are in
the Computer Configuration half of the Policy console, some in
the User Configuration half.
Disabling Roaming Profiles

Location: Computer Configuration/Administrative
Templates/System/User Profiles
Policy: Only allow local user profiles
Details: If users with roaming profiles log onto machines with
this policy set, their profiles will not download from the server.
Instead the users will receive new profiles that will be stored
locally on the machine, and any changes to those new profiles
will remain local.
Size (Quotas)
Location: User Configuration/Administrative Templates/System/User Profiles
Policy: Limit Profile Size
Details: You can specify a custom message to display to users who have exceeded their
(roaming) profile size allocation what that size is, whether it should include the registry,
whether to notify users who exceed their allocation, and how often to remind users to trim
their profile size (see Figure 123).
Figure 123: Limiting Profile Size
Folders
Figure 124: Folders
Location: User Configuration/Administrative Templates/System/User Profiles

Policy: Exclude directories in roaming profile
Details: By default, certain folders do not roam with the user profile. These are History,
Local Settings, Temp, and Temporary Internet Files. You can add to this list of
excluded folders by specifying the folder paths, relative to the profile root, and separating
each folder path with a semicolon. You may want to do so, for example, to lighten the load
on server disk space and on network traffic.
Slow Links
How roaming profiles behave over slow links (for example, dialup connections) can be
controlled via the following policy settings.
Figure 125: Slow Links
Location: Computer Configuration/Administrative Templates/System/User Profiles
Delete cached copies of roaming profiles You might enable this for security purposes or to
conserve disk space on local drives, but do not enable
it if you plan to use slow link detection.
Do not detect slow network connections This setting tells Windows to treat all connections
equally, effectively turning off the slow-link detection
features and their related policies.
Slow network connection timeout for user This setting lets you specify a connection speed (kbps)
profiles other than the default of 500 to use as a slow or fast
boundary for IP connections, or a server response
time (ms) other than the default of 120 to use as a
slow or fast boundary for non-IP connections (see
Figure 125)
Wait for remote user profile This setting tells Windows to wait for the server-based
copy of the user profile to load, even if the connection
is slow, rather than decide to use the most recently
saved local copy of that user profile.
Prompt user when slow link is detected Enable this if you want users to be able to decide
whether to use a server-based profile or a locally-
cached profile when a slow link is detected.
Timeout for dialog boxes This setting indicates how long Windows waits (the
default is 30 seconds) before making a default choice
after notifying the user of a slow link or unavailable
server.
Figure 126: Policy Settings for Slow Links
Folder Redirection
Figure 127: Folder Redirection
Folder redirection is a desktop configuration tool in which the network administrator

points several special folders that normally live on the hard drive of the user to a network
location instead. This is a behind-the-scenes desktop customization that nevertheless may
have an impact, positive or negative, on how quickly user machines run.
Why should you redirect folders? Two main reasons are:
To increase the security and recoverability of user data (in recognition of the
fact that most users do not regularly back up their data files and most user
machines do not come equipped with tape drives or DVD burners)
To reduce network traffic where roaming user profiles are used, for example,
because My Documents does not have to travel down the wire to the user PC
when the user logs on to a new computer for the first time
Helpful Hint
When redirecting folders, you typically use UNC paths, which may need to be converted via
a migration table if and when you migrate a policy object from one domain to another.
The special folders that you can redirect via Group Policy are all in the user profile under
Documents and Settings, and include the following:
My Documents (including My Pictures)
Desktop
Start Menu (although Microsoft would rather you control this via other
policies)
Application Data
Note
Folder redirection is handled by the client-side extension fdeploy.dll.
The User Configuration/Windows Settings/Folder Redirection node presents a

somewhat different user interface than most other Group Policy settings.
Rather than present a policy in the details pane, you must right-click the folder
that you want to redirect in the console pane, and choose Properties.
Then, you must choose Basic or Advanced from the drop-down list on the
Target tab.
- In the Basic scenario, all users are redirected to the same folder, although
each user will have a subfolder specified by %username%.
- In the Advanced scenario, users are redirected to folders on the basis of
security group membership.
Finally, you may make several configuration choices on the Settings tab (see
Figure 128).
Figure 128: Making Configuration Choices on the Settings Tab
Printer Management and Pruning
Figure 129: Printer Management and Pruning
Most of the system-related printer settings in Group Policy are to be found in Computer
Configuration/Administrative Templates/Printers, although some User Configuration
client-side printer settings exist in the Control Panel.
Pruning
One of the terms that comes up frequently in this list of policies is pruning. The pruning
service on the domain controller prunes (removes) printer objects from Active Directory if
the computer that published them does not respond to contact requests. When the
computer that published the printers restarts, it republishes any deleted printer objects
(assuming that this computer is running Windows 2000 or higher OS).
Note
The idea behind pruning is to make sure that users do not print to a printer associated with
a print server that is unavailable for some reason.
If you notice that printers are being pruned incorrectly, you may want to disallow printer
pruning by disabling the Allow pruning of published printers policy and specifying
Never in the Prune printers that are not automatically republished policy.
Alternately, you could make the pruning service a little more tolerant by using one of the
following methods:
Increasing the number of times that the pruning service tries to contact the
print server before deleting a printer, using the policy Directory pruning retry
Increasing the default 60-minute period for pruning checks using the policy
Directory pruning interval.
Publishing
What is a published printer? It is a printer that has been published in Active Directory,
that is, one that can be searched by its attributes when a user performs an Active Directory
search.
Note that it is possible to install a printer onto a domain controller, and even share it, but
not publish it in the directory. If you would like to publish only those printers that you
explicitly select for publication, you may want to disable the policy Automatically
publish new printers in Active Directory.
By default, any printer that you install on a DC is automatically published in the directory,
a behavior that varies from file sharing, incidentally, in that shared folders are not
automatically published in Active Directory.
Computer Network Settings

DNS Client
Figure 130: DNS Client
In the Computer Configuration half of the policy console, you can preset a number of
values that control the functioning of DNS, including dynamic update, DNS suffixes,
Time-to-Live values, and so forth.
Offline Files
Figure 131: Offline Files
Many of the Offline Files settings are duplicated in both Computer Configuration and
User Configuration. As usual, in the event of a conflict, the Computer Configuration
settings win.
Network Connections
Figure 132: Network Connections
The User Configuration half offers a variety of restrictions to control what users can and
cannot do in the Network and Dial-Up Connections folder.
Group Policy is a superb tool for controlling the user desktop.

Hundreds of settings exist to ensure consistency and, therefore,
reduce training and support costs. Many other settings help keep
users out of areas they do not need, again reducing user
downtime and support expense. Just remember that many Group
Policy settings do not provide ironclad protection. That is, even
though you turn off one way of doing something via Group
Policy, other ways may exist, and those other ways may not be
restricted.
Knowledge
Check
Section Review
1. What is considered best practice for script processing?

a. Asynchronous
b. Synchronous?
2. If you wanted to hide My Network Places from users in a particular OU, what is the
minimum number of Policy settings that you would need to make?
3. Internet Explorer settings exist in three primary locations in the Group Policy console.
Name them.
4. In which half of the policy console (computer configuration or user configuration) would
you expect to find DNS settings? Why?
5. If your organization uses roaming user profiles, what additional advantage would Folder
Redirection have for the My Documents folder, beyond the security of regular backups?
ABC Acronyms
The following acronyms are used in this section
CD compact disc
COM Component Object Model
DVD digital versatile disc
FRS File Replication Service
IEAK Internet Explorer Administration Kit
kbps kilobits per second
MRU most recently used
ms milliseconds
OS operating system
UI user interface
VBScript Visual BASIC Scripting Edition
VDM Virtual DOS Machine
WSH Windows Scripting Host
Group Policy and Remote Access
Section Topics
Remote Access Policy: The Same, Only Different
Creating a Custom Remote Access Policy
N Knowledge
Guide
W E
Section Objectives
S

Describe how remote access policies are similar to, and also different from,
regular Group Policy
Explain the difference between dial-in permissions, remote access policies, and
remote access profiles
Understand the decision tree that Windows follows when granting or denying
remote access
Build your own remote access policy
Fix authentication problems in networks with Windows NT RAS servers as
well as Windows 2000 or Windows 2003
Optimize Group Policy processing over slow WAN or dial-up connections
Section Overview
This section covers two subjects. First, remote access policies, which technically are not
part of the Group Policy mechanism but which share some core features of Group Policy,
and which you are likely to use if your organization supports telecommuting or remote
access for traveling workers. Second, and related, is a discussion of how you can tweak
Group Policy to perform better (that is, faster) over slow links.
Remote Access Policy: The Same, Only Different

Comparing Group Policy and RRAS or IAS Policy
Remote access policies are similar to regular group policies in the following ways:
They help the administrator control what users can do.
They can be managed through the MMC.
Microsoft calls them policies.
It is possible to manage them locally (RRAS) or centrally (IAS, the Microsoft
implementation of RADIUS).
However, remote access policies are different from regular group policies in the
following ways:
You do not manage them through the Group Policy console.
You do not link them to a local system, site, domain, or OU, but rather to
an RRAS or IAS server.
They do not replicate with the Sysvol share in Active Directory.
The bulk of this section covers the fundamentals of remote access policies. The last
section deals with another aspect of remote access: Group Policy processing over
slow links.
Overview of Remote Access Security

As time goes by and Microsoft continues releasing new versions of Windows, the
operating system is moving towards a need-to-know basis, rather than a need-to-
withhold basis. That is, access to network resources tends to be denied unless you
explicitly enable it.
RRAS (Routing and Remote Access Services) is a good example: you must take explicit
steps to allow users to gain access to your remote access server.
User access to an RRAS machine is the result of a fairly complex combination of settings:
The dial-in permissions of a user (set in Active Directory Users and Groups for
a domain environment, or in Local Users and Groups for a standalone server
environment)
Remote access policies that you set up on the specific RRAS server to contain
various conditions for permitting a connection
Remote access profiles that you set up on the specific RRAS server and that
determine the type of access that RRAS grants if a connection is permitted
Dial-In Permissions
Figure 133: Dial-In Permissions
Set dial-in permissions for a user via the Active Directory Users and Computers
administrative tool in a domain environment. The procedure is as follows:
Open the Users node in the tree pane.
Right-click the user in the details pane.
Choose Properties.
Click the Dial-In tab to see the dialog box shown in Figure 133.
What you see in this dialog box depends on whether your Windows network runs in native
mode (all domain controllers run Windows 2000) or mixed mode (one or more domain
controllers run Windows NT Server). In native mode, or on a standalone server, all options
are available; in mixed mode, only the Remote Access Permission and Callback
Options areas are available.
Under Remote Access Permission (Dial-in Or VPN), you can make one of two or three
choices:
Allow access: Means that the user passes the first hurdle, but may face other
hurdles in the form of remote access policy conditions and profile restrictions.
Deny access: Means that the user cannot connect to an RRAS server, no matter
what other conditions might be satisfied in a remote access policy.
Control access through Remote Access Policy: Means that whether the user
passes the first hurdle or not depends on the grant-or-deny permission setting
in a remote access policy. This option is only available for a standalone server
or for a domain server in native mode.
The Callback Options let you add security in that the RRAS server authenticates the user,
hangs up, and then dials the user back at a predetermined phone number. This feature is
handy for employees who telecommute.
Remote Access Policies

Remote access policies are sets of conditions and restrictions on remote access
connections. If a user gets past the hurdle of the account dial-in permissions, the
remote access policies take over in the decision process as to whether, and how, to
allow access to the user.
Remember the following key points:
At least one remote access policy must exist in order for anyone to access the
RRAS computer remotely.
If one or more remote access policies exist, the connection attempt must meet
all of the conditions specified in at least one of those policies, or else Windows
rejects the connection attempt.
If multiple remote access policies exist, Windows chooses the first one in the
list that matches, going from top to bottom.
The last point bears elaborating. For example, if you want to grant access at any time of
the day to everyone except members of the Temps group, who can only log on from 9:00 to
5:00, put the policy restricting the Temps group first and the policy granting access to the
Everyone group second. Otherwise, members of Temps (who are also members of
Everyone) could gain access at any time of day.
Microsoft provides an automatically-installed default remote access policy, whose

properties you can view by right-clicking the policy in the details pane of the RRAS
console Remote Access Policies node. (If you are using IAS instead, then right-click the
policy in the details pane of the IAS console Remote Access Policies node.) As shown in
Figure 134, the name of this policy is Allow access if dial-in permission is enabled.
Figure 134: Remote Access Policies
Near the top of the dialog box, you see a list named Specify the conditions to match. The
default remote access profile has only one condition, a day-and-time condition, that covers
the entire time span of 24 hours a day, 7 days a week. Every attempted RRAS connection
meets that condition. So, this policy applies to everyone who tries to dial up this RRAS
server.
Other conditions that you can set include:
Remote access protocol used by client (PPP, SLIP, and so on)
Caller ID of remote user
Membership in one or more Windows groups (the Windows-Groups
condition)
Below the condition list is an area labeled If a user matches the conditions. Here, you
tell the policy what it should do if all the conditions in the condition list are satisfied. The
default remote access policy says Deny remote access permission, but you must
remember that this denial occurs only if the dial-in permission of the user account is set to
Control access through Remote Access Policy. If the dial-in permission for the user
account is either Allow access or Deny Access, this policy permission is irrelevant.
Microsoft recommends that you delete the default policy, then add custom policies of
your own.
Remote access policies are stored on the local RRAS server (the file is ias.mdb in the
folder c:\Winnt\System32\Ias), not in Active Directory. This makes sense in that some
organizations want to use RRAS but do not use Active Directory. As a result, you can set
different policies on different RRAS computers.
You can set up remote access policies from RRAS or from IAS if you are using Internet
Authentication Server. If you set them up on an IAS server, and point all your RRAS
servers to IAS for authentication, you have to create only one set of remote access
policies.
Remote Access Profiles
Figure 135: Remote Access Profiles
Via the Edit Profile button on the Settings property sheet of the remote access policy, you
can create a set of constraints that determines what sort of access the user experiences,
after RRAS has already decided to permit a connection based on:
Policy conditions
Dial-in permission of the user
For example, you can make settings on the Dial-in Constraints tab (seeFigure 135) that:
Kill a connection after a predefined idle period
Restrict the duration of a session
Restrict access to particular days and times
Permit a connection only if it comes in over a particular media type
On the IP tab, you can set IP packet filters for the connection.
The Multilink tab lets you explicitly allow or disallow multilink for the specific
policy, or use the global default setting of the server. The ability to control the
multilink setting is handy if you want to permit multilink operation for some groups
but not others.
Similarly, the Authentication tab lets you specify which authentication protocols to
use for the policy (but be sure that the global settings of the server also include the
authentication methods that you choose here).
The Encryption tab offers three choices:
No encryption: Means that clients do not have to use any encryption
method in order to connect to the RRAS server.
Basic: Means that RRAS supports 40-bit encryption for IPSec or MPPE.
! Caution
If you use Windows 2000, be careful. The online help is incorrect on this point.
Clients can connect with either encryption protocol.

Strong: Means that RRAS supports 56-bit encryption for IPSec or MPPE.
You can choose any combination depending on the possible encryption types you
want to permit. For example, to require strong authentication for this profile, check
the box for Strong and clear the other two checkboxes.
Note
A remote access client must be using MS-CHAP (version 1 or 2) or EAP/TLS in order

to use data encryption.
How the Three Parts Interact

Here is a summary of how dial-in permissions, remote access policies, and remote access
profiles work together:
Denials win: As with NTFS permissions, explicit denials win. If the dial-in
permission for a users is set to Deny access, the user cannot connect, period,
even if the connection attempt meets the conditions specified in one or more
remote access policies.
The grant/deny feature of policies only works if the account says to use it:
If the dial-in permission setting for a user accounts is either Allow access or
Deny access, it overrides the similar permission setting for the remote access
policy. That is why the default remote access policy can say that it denies
access to everyone, but you can change the dial-in permission for an individual
user to Allow access and the user can gain access.
Therefore, the only time that the permission setting (grant or deny) of the
remote access policy setting means anything is if the dial-in permission for the
user is set to Control access through Remote Access Policy. That setting is
not available in a mixed-mode Windows network.
All the conditions in a remote access policy must be satisfied to grant
access: If multiple conditions exist for the policy, all the conditions must be
satisfied to allow access. Otherwise, we have what is termed an implicit
denial of access.
At least one remote access policy must be satisfied to grant access: If
multiple remote access policies exist for the RRAS or IAS server, then at least
one remote access policy must be satisfied.
For another view of how dial-in permissions, remote access policies, and remote access
profiles work, here is the sequence of events that Windows follows when a user tries to
gain access to an RRAS or IAS server:
1. Are there any remote access policies to process?
If so, go to 2.
If not, access is denied.
2. Does the connection attempt to match the policys conditions?
If so, go to 3.
If not, Windows checks for the next policy in the list, and repeats step 2.
(If no matching policy exists, access is denied.)
3. Is the users property sheet in Active Directory Users and Computers set to
deny access?
If so, access is denied. (You could argue that this should be checked first.)
If not, go to 4.
4. Is the users property sheet in Active Directory Users and Computers set to
grant access?
If so, go to 5.
If not, go to 6.
5. Does the connection attempt match settings for the user object and the remote
access profile?
If so, access is granted.
If not, access is denied. Other matching policies may exist, but Windows will
not try them.
6. If you get here, then the users property sheet is set to Control access through
Remote Access Policy. Is the remote access policy set to Deny remote access
permission?
If so, access is denied.
If not, go to 5.
Considering this process, it is something of a minor miracle that anyone ever connects
at all.
Creating a Custom Remote Access Policy
Figure 136: Creating a Custom Remote Access Policy
The procedure for creating a custom remote access policy is fairly straightforward,
whether you are using the RRAS console or the IAS console. Here are the steps for a
Windows 2000 server (slight variations may exist between RRAS and IAS scenarios):
1. Open the RRAS or IAS management console.
2. Expand the nodes in the tree pane until you see the node labeled Remote
Access Policies.
3. Right-click that node, and choose New Remote Access Policy.
4. Specify a friendly name for the policy, such as Temporary Employees.
5. Click the Add button to add a condition for the policy.
6. Choose an attribute from the list that appears (see Figure 136).
7. Specify details for that attribute; for example, if you choose

Windows-Groups, specify the security group for which you want to define
the condition.
8. Decide whether you want the policy to grant access or deny it.
9. Click the Edit Profile button to make settings for the remote access profile.
10. Click Finish.
RRAS Authentication Problems in Mixed Networks

Authentication of dial-in users can be a problem in a mixed-mode environment. Windows
NT 4.0 servers running RAS but not Active Directory need to read user data from Active
Directory in order to authenticate remote access clients. However, the servers are barred
from doing so, because the Windows NT RAS service has no credentials.
So, if you have some nondomain-controller Windows NT RAS servers and some
Windows 2000 or Windows 2003 RRAS servers on the same network, remote users can
sometimes gain access to the network and sometimes cannot, depending on whether they
dial into a Windows NT machine or a Windows 2000 machine. That is obviously not a
workable situation.
Three solutions exist:
Upgrade the Windows NT server to Windows 2000 Server or Windows 2003
Server.
Use only Windows NT domain controllers for RAS. Domain controllers have
the information needed to authenticate remote access users in the registry.
Loosen permissions for the Everyone group so that any member can read any
property of any user object. The command is:
net localgroup "Pre-Windows 2000 Compatible Access" Everyone /add
If you are setting up a Windows 2000 or Windows 2003 Server just to be a domain
controller, you do not need to run the command at the end of the preceding list. Just run
dcpromo.exe and, when prompted, select Permissions Compatible with Pre-Windows
2000 Server.
Policy Processing over Slow Links

One of the big problems that organizations can encounter when implementing roaming
user profiles is that performance over slow links (such as dial-up modems) can make the
logon process agonizingly slow. If an organization takes full advantage of Group Policy,
the process of applying computer and user policies over slow links can also delay logons.
Building on what it learned with roaming profiles, Microsoft decided to put some features
into place to minimize the performance impact of applying Group Policy over slow
connections. Most of these features live in the MMC under the following nodes as shown
in Figure 137 (Windows 2000 Server):
Computer Configuration/Administrative Templates/System/Group Policy
User Configuration/Administrative Templates/System/Group Policy
Figure 137: Policy Processing over Slow Links
The default behavior is for registry-based policies, security policies, and (in Windows
2003 Server) wireless and software restriction policies to apply over slow connections, but
for other types of policies not to apply over such connections. You have nearly complete
control over how you want to balance speed versus functionality when Windows applies
Group Policy over slow links.
How Slow Is Slow?

However, before we get into the settings that determine what Windows does when it
encounters a slow link, we should understand what slow means in this context.
Microsoft has provided conflicting information on this point.
In the MMC Group Policy console help system, Microsoft states that a slow
link, by default, is one in which a ping to the server takes more than 2 seconds.
In the explanation text for the Group Policy Slow Link Detection policy,
Microsoft states that a slow link, by default, is one in which data transfer is
slower than 500 kbps.
The second bullet seems to be the correct information. If you want slow to mean
something different, you can set threshold values in:
Computer Configuration/Administrative Templates/System/Group Policy/
Group Policy Slow Link Detection
User Configuration/Administrative Templates/System /Group Policy/
Group Policy Slow Link Detection
The thresholds can be different for the two halves of the Group Policy console, although in
practice you will usually make them the same.
Note
The thing to remember here is that Windows determines whether a connection is slow or
not completely independently from the physical connection type. A dial-up link could be
fast and a LAN link could be slow in specific circumstances.
Notes What Can You Control?

Now that we know how slow is slow and can change that
definition if we like, the next question becomes, What aspects of
policy processing can I control if Windows detects a slow link?
Here they are, all under the node Computer Configuration/
Administrative Templates/System/Group Policy:
Internet Explorer maintenance policy processing (on
by default)
Software installation policy processing (off by
default)
Folder redirection policy processing (off by default)
Scripts policy processing (off by default)
(Logon and logoff scripts only; startup and shutdown
scripts are never processed)
IP security policy processing (on by default)
EFS recovery policy processing (on by default)
Disk quota policy processing (off by default)
The technique is first to enable the policy, then either check or Notes
leave unchecked the option that says Allow processing across a
slow network connection, as you see fit.
Figure 138: What Can You Control?
Notice also the Do not apply during periodic background

processing checkbox. Normally, for nondomain-controllers,
Group Policy settings are refreshed every 90 minutes, but if you
check this box, such refresh cycles will not occur for the selected
client-side extension. This, too, can improve the performance of
users on slow-link connections.
Notes Some experimentation is probably in order, to determine which

of the above has the most impact in your computing environment.
In some situations, you may wish to allow a policy
setting to process across a slow network connection
for reasons of consistency, as for example if you
include drive mappings in logon scripts.
In other situations, you may decide that you can forgo
some functionality in order to allow remote users to
log on more rapidly, as for example with software
installation policy processing or folder redirection
policy processing.
Remember, too, that security settings and registry-based policy
(administrative templates) will apply over slow links, and you
cannot change that behavior.
Helpful Hint
The Group Policy Modeling Tool, part of the Group Policy

Management Console (Windows 2003 Server only), is useful for
predicting the effect of slow links on policy processing in a given
environment.
Remote Users and Offline Files and Folders
Figure 139: Remote Users and Offline Files and Folders
Part of the IntelliMirror strategy is to allow users to work on network-based files even
when those users are not connected to the network. That is the idea behind offline files
and folders, an area of special interest to remote and laptop users.
Files and folders that have been set for working offline seem to the user to be
in the same location at all times, whether the user is connected to the network
or not.
If a user has been working offline, the synchronization manager uploads any
modified files to the server when the user reconnects.
Notes Group Policy can be used to control the behavior of the offline
files and folders feature. You will find settings in both the
Computer Configuration node and the User Configuration
node, but many are duplicated (see Figure 139).
The location for this feature is:
Computer Configuration/Administrative Templates/
Network/Offline Files
The settings are described in Figure 140.

Setting Description
Allow or Disallow use of the Offline Files Organizations differ on whether this feature is useful or
feature not, but the consensus seems to be that if users have
their own private folders on the server, you may want
to turn it on.
Prohibit user configuration of Offline Files This means that administrators will set specific files
and folders to be available offline and users cannot
change them.
Synchronize all offline files when logging on The more frequently synchronization occurs, the
slower things get for the user but the less likelihood for
the user to see out-of-date files.
Synchronize all offline files before logging off Same as previous setting.
Synchronize offline files before suspend This setting may be advisable for laptop users running
on battery power.
Default cache size Limits the percentage of the computer disk space that
can be used to store automatically cached offline files
(but has no effect on manually cached offline files);
expressed as a percentage of disk space times 100
(10 percent would be expressed as 1,000).
Remove 'Make Available Offline 'Removes the Make Available Offline option from the
File menu and from all context menus in Windows
Explorer, but does not prevent automatically cached
offline files from being saved to the local disk.
Prevent use of Offline Files folder Disables the View Files button on the Offline Files
tab of the Folder Options control panel.
Files not cached File types (listed by suffix) that Windows will not
cache, even in folders designated for automatic
caching, because they go with other files, as in
database applications.
Administratively assigned offline files Folders is more likely; files or folders that you want to
be available offline for all users.
Turn off reminder balloons These appear in the system tray when a network
connection is lost and notify the user that he or she is
working offline. Enable this policy if you think this
would be potentially distracting or confusing.
Setting Description
At logoff, delete local copy of user's offline Risky, considering that the offline files are not
files synchronized before they are deleted. Take care
before implementing this setting.
Encrypt the Offline Files cache Use this setting to increase security on the
workstation; however, be aware that there is no
mechanism for the user to decrypt the files if this policy
is enabled.
Prohibit 'Make Available Offline' for these files Removes the ability of the user to manually cache files
and folders and folders in the list, but has no effect on automatic
caching.
Configure slow link speed When a connection is considered slow, Offline Files
will not automatically reconnect to a server when the
presence of a server is detected. The value to enter is
bps divided by 100.
Figure 140: Settings for Offline Files
Remote access policies, while technically not part of Group

Policy per se, are important for establishing secure dial-in
channels for users working from home or the road. They can be
complex, involving Active Directory, remote access policies, and
remote access profiles. You can centralize dial-in authentication
with a RADIUS server that acts as an authentication clearing-
house. You can also control how Group Policy behaves over slow
remote links by defining what slow means and by telling
Windows which types of policies it must apply over such links.
Knowledge
Check
Section Review
1. Name two ways in which remote access policies are similar to Group Policy, and two
ways in which they are different.
2. What are the three conditions that must be satisfied for a user to gain access to a dial-in
server running RRAS?
3. In a domain environment, what must be true about the domain for Control access
through Remote Access Policy to be an available choice in Active Directory Users and
Computers?
4. If multiple remote access policies exist, does the order matter?
5. What is the benefit of using Internet Authentication Server?
6. Name two types of policies that will process over a slow link by default.
7. Are WAN links by definition slow in terms of policy processing?
8. Can you set a separate slow link threshold for Offline Files and folders?
ABC Acronyms
bps bits per second

EAP Extensible Authentication Protocol
ID identifier or identification
IPSec IP Security
kbps kilobits per second
MPPE Microsoft Point-to-Point Encryption
MS-CHAP Microsoft Challenge Handshake Authentication Protocol
PPP Point-to-point Protocol
RADIUS Remote Authentication Dial-In User Service
RAS Remote Access Service
RRAS Routing and Remote Access Services
SLIP Serial Line Internet Protocol
TLS Transport Layer Security
Assigning and Publishing Software
Packages
Section Topics
What Is an MSI Package?
MSI Package Architecture
Group Policy as a Software Deployment Method
Assigning Software
Publishing Software to Users
Upgrading Packages
Removing Packages
Using WinInstall to Create MSI Packages
Setting up Distribution Points
SMS and RIS
Using the Software Update Service
Assigning and Publishing Software Packages
N Knowledge
Guide
W E
Section Objectives
S

Describe the basic elements of an MSI package
Explain the difference between assigning software and publishing software
Explain the difference between assigning software to a computer and to a user
Work with WinInstall to build your own MSI package
Explain when you may want to use SMS instead of Group Policy
Describe the Software Update Service
Section Overview
Microsoft has done a nice job extending the Group Policy concept to include software
distribution. Deploying software has become more and more of an administrative chore as
the frequency of new applications, patches, and upgrades has increased. For many organi-
zations, the expense of a more sophisticated (and expensive) program like Systems
Management Server has been the only alternative to a lot of manual work. The software
distribution features of Group Policy strike a balance that will work well for many
organizations.
What Is an MSI Package?

Background of the Problem
In the days of MS-DOS, installing software was simplicity itself. You copied a folder full
of files over onto your hard drive, identified the executable, and typed it at a command
prompt to run your application.
Windows, of course, changed all that, in various ways:
In early versions of Windows, application installs often required modifications
to win.ini, system.ini, and possibly config.sys and autoexec.bat as well (for
example, to modify the path). Some applications required their own fonts, as
well as program icons, to be installed.
In later versions of Windows, application installs have become even more
complex. The registry has largely supplanted win.ini and system.ini, and the
registry cannot be updated by simply copying files.
With the advent of Active Directory, some programs even require that the
Active Directory database structure (the schema) be extended.
So, application developers came up with a multitude of ways to perform installations.
Some used third-party installers, others wrote their own setup programs. The methods for
installing Windows applications were, therefore, wildly inconsistent, creating problems
for users and administrators alike.
Once PC networking caught on, IT managers faced another issue. Application installation
was inherently decentralized: each user had to install his or her own software locally.
Because of the increasing complexity and inconsistency of the application installation
process, users often installed software improperly, with negative results afterwards.
The users were hardly to blame. How are they supposed to correctly answer a question
such as: An application is attempting to install a DLL for which you already have a
newer version on your machine. Would you like to keep your existing version or
overwrite it with the older one? Especially when sometimes the correct answer is to
keep the newer version, and other times the correct answer is to install the older one?
Another category of problems came up with the increasing use of shared DLLs. When it
comes time to remove (or, as the perversely antigrammatical computer industry has come
to say, uninstall) an application, how does one deal with the DLLs and registry entries that
may be shared with other applications? These problems became so severe that at one time
a cottage industry sprang up of uninstallers whose sole purpose was to properly remove
applications that users no longer wanted.
Notes Finally, although hard drives have become dramatically more

reliable than in years past, file corruption can still occur, and
when it does, users are often faced with having to remove and
reinstall a program or patch. A convenient method for repairing
damaged application files would be much less burdensome on
users and support staff.
To summarize:
Windows application installations have become
increasingly complex over the years.
Many different activities must happen correctly
during installation.
Inconsistent methods and procedures unnecessarily
strain user and IT resources.
Depending on users to install their own applications
can create problems.
Proper removal of applications is also more complex
than before, but necessary.
Convenient repair of damaged applications would
save time and money.
Why Installation Routines Matter

Many organizations today create their own workstation builds, applications and all. So
why does it matter whether application installation routines are inconsistent and
problematic? Can the organization IT department not perform the installs correctly and fix
any issues prior to cloning the workstation for general distribution?
Yes, and that is often exactly what they do. However, new applications, and updates or
patches to existing applications, come out more and more frequently. Organizations
typically do not want to create an entirely new workstation build just because one or two
new applications have become desirable in the field or because a few patches or updates
have become available.
So, many organizations still need to have a reliable, consistent, user-friendly way of
distributing applications and updates between workstation builds.
Then again, smaller organizations may never go through the process of building
workstation images. They may use Setup Manager to create installation scripts for the OS
and rely on users to perform their own application installs and updates based on published
procedures. In such cases, the need for solid software distribution methods is even greater.
Elements of a Solution
An ideal software distribution method would exhibit the following features:
Hide the complexity of installation from end users
Correctly perform all the various operations necessary (registry, files, icons,
DLLs, etc.)
Present a consistent user interface for both users and administrators
Offer the ability for installations to be scripted and managed centrally
Provide for the subsequent removal of the application
Provide for convenient repair of damaged installations
These were the goals that Microsoft had in mind when it produced the specification for the
MSI package.
MSI Package Architecture
Figure 141: MSI Package Architecture
The MSI (Microsoft Software Installer) file format is used (and required) by the Windows
Installer service (see Figure 141), a system service that handles the following aspects of
applications and certain Windows components:
Installation (including rollback if aborted)
Modification (including updating)
Repair
Removal
(Version 1.1 of the service, which ships with Windows 2000, deals with 32-bit software,
while version 2 can handle 64-bit software.)
Note that the command-line executable is msiexec.exe. You can invoke the Windows
Installer from the command line to install MSI packages with the /I qualifier, for example:
msiexec /i myapp.exe
Additional information on command-line qualifiers for Windows Installer appears below:
/i: Install
/a: Administrative install
/f: Fix (repair), with the following additional qualifiers:
- p: Reinstalls only if file is missing
- o: Reinstalls if file is missing or if an older version is installed
- e: Reinstalls if file is missing or an equal or older version is installed
- d: Reinstalls if file is missing or a different version is installed
- c: Reinstalls if file is missing or the stored checksum does not match the
calculated value
- a: Forces all files to be reinstalled
- u: Rewrites all required user-specific registry entries
- m: Rewrites all required computer-specific registry entries
- s: Overwrites all existing shortcuts
- v: Runs from source and recaches the local package
/x: Remove (uninstall)
/ju: Advertise the package to the current user
/jm: Advertise the package to the current machine
/p: Apply a patch
Helpful Hint
For complete details on these and other qualifiers, refer to:

http://www.microsoft.com/windowsxp/home/using/productdoc/en/msiexec.asp
Elements of a Package
Possible categories included in MSI packages are:

z Main program files (EXE, DLL, etc.)
z Files that may be shared with other applications from
the same vendor
z Modules (and whether they are required or optional)
z Shortcuts (typically on Start menu)
z Icons
z Fonts
z *.ini files
z Registry additions and changes
z Differences between a fresh install and an upgrade of
an earlier version
z Removal instructions
Figure 142: Elements of a Package
While not all MSI packages contain every category listed in Figure 142, these are the
possibilities.
When you are deploying an MSI-packaged application, the MSI file should reside in a
shared folder on a network server. If the MSI file lives in a nonshared folder, the
deployment will not work, because users will not have access to the source MSI file.
What Is a Transform? Notes
A transform is a modification to an existing MSI package that

you may want to make for your specific situation. For
example, you could use a transform to:
Specify that you want specific features to be always
installed on the local disk of the user.
Add content, such as sample data files or a tutorial
folder, to the file set.
The suffix for transform files is .mst. The MST files must live
in the same folder as the MSI file or files that they modify, and
that folder should be shared on the network.
How do you create a transform? The method varies, but
generally, the software application vendor will provide a
wizard or other tool that allows you to create a transform.
Alternatively, you could use a third-party tool to create a
transform.
After you have created a transform, you can associate it with an application that you are
publishing or assigning by right-clicking the application in the Software Settings node
of the Group Policy console, choosing Properties, and clicking the Modifications tab
(see Figure 143). You can assign more than one transform to a given application
package.
Figure 143: What Is a Transform?
If you need to modify a transform later, remove it from the Modifications tab, then re-add
the modified MST file.
Relationship to Group Policy

So, why all this discussion about MSI packages in a course on Group Policy? Two simple
reasons for this are:
Group Policy is one mechanism for distributing MSI packages in a Windows
network environment. (SMS is another.)
If you go with Group Policy to distribute software, it requires that applications
be packaged in MSI format for distribution, with the one exception of ZAP
files.
Qualifying points need to be made regarding the above:
You could certainly still use the scripting features of Group Policy to deploy
logon scripts that could initiate a software installation that does not use the
MSI package format. That is, if you want to use the full capabilities of the
Software Settings node in the Group Policy MMC console to distribute
software, you must use MSI.
If it is just not feasible to obtain or create an MSI package, you can use the
publish option (but not the assign option) in Group Policy with a ZAP file,
described in Microsoft tech note Q231747. Here are the salient points of using
ZAP files:
- This method allows you to use Group Policy to place an application on the
Add/Remove Programs lists of users.
- It is easier than building an MSI package (a ZAP file is actually a text file
with the .zap suffix).
- It does not provide for installation rollback.
- It does not provide for application repair.
- It will not work with transforms.
- Users may need administrative privileges to perform the installation.
- A ZAP file could be as simple as the following example:
<Application>
FriendlyName = "Microsoft WhizBang 2008"
SetupCommand=""\\server\share\whizbang08\setup.exe""
You can use MSI without using Group Policy. For example, you can use SMS
to distribute MSI packages. You can also use logon scripts, or various third-
party solutions (such as Marimba).
Group Policy as a Software Deployment Method

Group Policy is one way, but by no means the only way, to distribute software to client
PCs in a Microsoft network. Following is a look at the pros and cons of using Group
Policy for this purpose, and the requirements for doing so.
Pros and Cons of Policy-Based Software Deployment

Group Policy-based software deployment has the following advantages:
If you are already using Group Policy for other things, you do not have to learn
a whole new tool.
You can deploy software to machines, or to users, as appropriate.
You can deploy software by site, domain, or OU.
You do not have to write advanced scripts.
You do not have to go out and buy new software for handling deployment.
The disadvantages of Group Policy-based software deployment include the following:
Policy-based deployment cannot be precisely scheduled.
Since it cannot be precisely scheduled, it is possible to encounter network
bandwidth problems during deployment.
You have virtually no reporting.
The lack of reporting results in no inventory control.
Your network may not meet the requirements for distributing software via
Group Policy.
Requirements for Distributing Software via Group Policy

So what do you need to have in place to distribute software via Group Policy?
MSI packages.
Active Directory (obviously, since Group Policy requires Active Directory).
Active Directory clients, that is, workstations running Windows 2000 or
Windows XP. Even though you can retrofit an Active Directory Client package
to Windows 95, Windows 98, and Windows NT workstations, those older
operating systems cannot participate in Group Policy-based software
distribution.
Options for Policy-Based Deployment Notes
If you use Group Policy for software deployment, you have three
main options for a given application:
Assign the application to computers (Computer
Configuration, Software Settings)
Assign the application to users (User Configuration,
Software Settings)
Publish the application to users (User Configuration,
Software Settings)
The difference between assigning and publishing is not immedi-
ately obvious. In Microspeak, assigning generally means that
users are going to get this program, and publishing means that the
program appears on the Add/Remove Programs list so users can
get it if and when they want.
Assigning Software
Assigning software via Group Policy is the best option when you really want users to have
the software, and when you may even want to force it on them, for example as part of a
plan to ensure a minimum level of security or user-interface consistency. Most essential
software (for example, antivirus) would be assigned rather than published.
Assigning software does the following:
The software appears on the Start menu following activation of the policy.
You can specify that the application will be installed automatically, for
example at the next startup (if assigning to computers) or next logon (if
assigning to users).
If a user removes the application via the Add/Remove Programs wizard, the
application will again appear on the Start menu at the next reboot.
If you choose to assign software, you can follow one of three scenarios:
Assign the software to computers: This forces the install at the next reboot
and makes the software available to all users of the PC.
Assign the software to users: This forces the install at the next logon if the
user is in the Active Directory structure (for example, OU) to which the policy
applies.
Assign the software to users, but on demand: Install occurs on a per-user
basis but only when the user selects the program via the Start menu or a
desktop shortcut. Frankly, this is not a whole lot different from publishing.
Assigning Software to Computers

When you assign an application to computers via the Computer Configuration node of
the Group Policy console, you are saying the following:
You want every computer in the scope of the policy (for example, domain) to
receive the application.
You want every user on those computers to receive the application, regardless
of where their user accounts may reside in the directory.
You want the application to install itself onto the computer automatically at the
next restart following activation of the policy.
Figure 144: Assigning Software to Computers
The general procedure for assigning an application to computers is as follows:

1. Put the MSI package into a shared folder on a server, or some other distribution
point. (If you are doing an administrative install, you may first run setup /a and
then specify the location of the distribution point.)
2. Open Active Directory Users and Computers.
3. Right-click the directory object that identifies the scope for the deployment
(for example, domain or OU).
4. Choose Properties, and click the Group Policy tab.
5. If a policy already exists, click Edit; otherwise, create one and then click Edit.
6. Display the Computer Configuration, Software Settings node.
7. Right-click that node and choose New, Package (see Figure 144).
8. Navigate through a network path (that is, go through My Network Places) to
the MSI package location specified in step 1, and choose the MSI package.
9. In the Deploy Software dialog box, choose Assigned (or Advanced published
or assigned if you want to specify a transform in addition to the MSI package).
Figure 145: Deploying Software
10. The entry is created in the console. Right-click it and choose Properties to
configure additional options, for example, on the Deployment tab. (The
checkbox Uninstall this application when it falls out of the scope of
management simply means that if the computer account is moved to an OU
where the policy no longer applies, Windows should uninstall the program
rather than leave it on the user machine.)
Figure 146: Configuring Additional Options
After you have assigned an application to computers, the next time computers under the
scope of this policy restart, the user will see a succession of informational messages, such
as the following, at boot time:
Applying computer settings
Applying software installation settings
Installing managed software name of program
Notes Assigning a large new application for an entire domain can bring
a network to its knees when all those machines boot up on
Monday morning. If you are selecting the automatic installation
option, it is a good idea to leverage the power of Group Policy so
that this does not happen. For example, if you have a number of
OUs defined within your domain, consider creating GPOs for
those OUs and assigning the software one OU at a time. You
could do likewise with sites, depending on their size.
Assigning Software to Users
Note
This variation is only available in Windows 2003 Server. On

Windows 2000 Server, you do not see the Install this application
at logon checkbox on the properties sheet for the policy.
If you want to assign software to a particular group of users, the

software is installed when the user logs on instead of when the
machine boots (as is the case when assigning software to
computers). The advantage of going this route is that you can
deploy applications to only those users who need them if your
organization is one in which multiple people could be using the
same PC. This simplifies the desktop for users who do not need
the applications and it may also reduce the network burden of
deploying software.
The methodology here is quite similar to that in assigning
software to computers, with the exception that in step 6, you
choose User Configuration, Software Settings, and on the
Deployment tab, you select the Install this application at logon
checkbox.
You also have the additional option of clicking the checkbox
titled Do not display this package in the Add/Remove
Programs control panel if you do not want it to show up there.
Assigning Software to Users on Demand
Figure 147: Assigning Software to Users on Demand
Think of this third option, which is the default behavior for assigning applications to users
(and the only way you can assign an application to users in Windows 2000 Server), as the
most polite way of assigning software. This method puts a link on the Start menu or the
desktop (or both).
Important Terms
The act of putting an application shortcut on the Start menu or the desktop, or putting an
entry for it in Add/Remove Programs, is referred to as advertising the application.
When a user chooses a program entry on the Start menu, or double-clicks its icon on the
desktop, the application will install at that time.
Assigning software to users on demand is actually very similar to publishing an
application. About the only significant difference is that the program shows up on the
Start menu, and possibly a desktop shortcut, whereas when you publish an application, it
merely shows up on the Add/Remove Programs list.
This method of software deployment is less likely to overburden your network than
assigning an application to computers, because the user must take an action to initiate the
actual installation and all users are not likely to do so at the same moment.
Notes In Windows 2003 Server, when you assign software in the User
Configuration half of the Group Policy console, you assign it on
demand simply by not checking the Install this application at
logon box.
Publishing Software to Users

Publishing software via Group Policy is the best option when you do want to give users
the choice of whether to install an application or not; for example, if the application is a
more specialized one that would not apply to all users in a domain or OU. It is also the
subtlest way of deploying software in that unless the users visit the Add/Remove
Programs control panel, they may not even know that the application is available for
installation.
You may also want to consider publishing versus assigning when you want to spread
installations out over a longer period of time. Users visit the Add/Remove Programs
control panel less frequently than they use the Start menu, so you are less likely to have a
lot of users flooding the network with installation requests around the same time. (You
could even notify small groups of users on a staggered schedule of the addition to the
Add/Remove Programs list.)
Finally, publishing is easier for users than navigating to a network share and hunting down
an MSI package. The Add/Remove Programs dialog box saves them the effort: the users
do not need to know where the software distribution point is. The software appears on the
Add/Remove Programs list after the first logon following activation of the policy.
Note
Group Policy does not provide the option to publish software to computers, although you
can assign software to computers.
The procedure for publishing is analogous to the procedure for assigning, with the
exception that you would choose Published or Advanced published or assigned.
If you choose the Auto-install this application by file extension activation box, then the
user can also initiate installation by double-clicking a file whose suffix has a file type
association with the advertised application.
If a computer belongs to a domain, but a user usually logs on to that computer as the local
administrator, what type of Group Policy deployment would you choose to ensure that the
user gets an application as soon as possible?
Notes Upgrading Packages
Figure 148: Upgrading Packages
When you deploy a commercial MSI package that is aware of

earlier versions of its product, the package knows to query the
registry of the local computer to learn of the presence of earlier
versions. The package should also include instructions for itself
as to how to proceed if it does find an earlier version already
installed.
You can create your own upgrade behavior, as well, using the
MMC Group Policy console. Right-click the application policy,
choose Properties, then choose the Upgrade tab. Here, you can
specify the upgrader package and the upgradee package. You
can even use this method to change applications from one vendor
to another.
Removing Packages Notes
Remove a package by right-clicking it in the details pane of the

Group Policy console and choosing All Tasks, Remove. When
you do so, you have a decision to make (see Figure 149).
Figure 149: Removing Packages
For licensing reasons, you may wish to uninstall the software

from any user or computer to which it has been installed
previously. That is the first option in the dialog box.
Alternatively, your goal may be simply to ensure that no
additional installations occur, but existing users and computers
that have the software may keep it. That is the second option in
the dialog box.
Notes Using WinInstall to Create MSI

Packages
What if an application that you want to deploy via Group Policy
does not come with an MSI package? Your life gets complicated,
but not impossible. Tools exist to help you roll your own MSI
package, although Microsoft rightly cautions that this procedure
can be time-consuming, expensive, imperfect, and tedious.
Building (Authoring) an MSI Package

When you create an MSI package from scratch, based on setup
logic that you already have available (either because your
organization designed the installation, you got the details from
the application vendor, or you have reverse-engineered the
vendor setup program), you are considered to be building or
authoring the package.
Wise and InstallShield both offer fully-featured tools for creating MSI packages from
scratch. You can also use Microsoft Visual Studio Installer to create MSI packages, or
Veritas Install Exec for MSI. You can tell which tool was used to create a given MSI file
by checking its property sheet and referring to the Origin Application on the Summary
tab (see Figure 150).
Figure 150: Building (Authoring) an MSI Package
Windows 2000 came with a scaled-down version of an application called WinInstall. The
name of the provided product is actually WinInstall LE (the LE stands for Limited
Edition) and the vendor is Veritas (formerly Seagate Software).
With some exceptions and caveats, you can use WinInstall LE to create an MSI package
from a program that did not originally come packaged that way.
WinInstall LE does not run on Windows XP, although the MSI packages it creates can
install on Windows XP client machines.
Install WinInstall LE from the Windows 2000 Professional CD. The MSI file
swiadmle.msi is located in \Valueadd\3rdparty\Mgmt\Winstle.
You must copy the swiadmle.msi file from the CD to the local hard drive of a Windows
2000 Professional PC and then clear its read-only check box in order to install it. This
program will not install from CD.
You can use WinInstall LE to build an MSI file, but before you do so, it may be wise to
open some existing MSI files to get a feel for how they are constructed. The figure below
shows the internal implementation of adminpak.msi, a package that includes various
server administrator tools that can run on a Windows 2000 or Windows XP workstation.
Figure 151: The adminpak.msi File
Repackaging an Application
Figure 152: Repackaging an Application
What if you do not have access to the setup logic of a given application, and you have not
been successful in obtaining it? All is not lost. You may consider using a tool (such as
WinInstall Discover module) that can take a snapshot of a PC just before installing the
application, another snapshot just afterwards, and calculate what changed (the delta,
after the Greek letter used in mathematics to mean a difference or change). The tool can
then figure out what needs to go into the MSI package based on the succession of deltas it
recorded in the file system and registry.
Notes When you produce an MSI file by using a tool to take snapshots,
figure the deltas, and build the MSI package by inference, you
are said to be repackaging the application, as distinct from
authoring or building it. Some of the characteristics of
repackaging are:
Repackaging is less than completely reliable, so set
your expectations accordingly.
Repackaging works better for simpler applications.
You can often improve upon a repackaging session by
manually editing the MSI package, using repackaging
to get you most of the way there.
Improve your odds for success by performing
snapshots on a clean PC with no other applications
on it.
Microsoft will not support any applications that you
repackage.
You cannot use transforms on repackaged
applications.
Setting up Distribution Points

Deciding how and where to implement your software distribution points is a key issue in
deploying software via Group Policy.
Specify a Network Location

You need to specify a network location as opposed to a location on the local file system of
the server. This might seem obvious. However, when you create a new entry in the
Software Settings node of the Group Policy console, it is very easy to simply navigate to
a folder such as c:\Public instead of opening My Network Places, locating the server, and
then opening the Public folder.
Windows is not smart enough to know that c:\Public is the same as, for example,
\\Srvr01\Public, and your policy-based installations will fail because the clients will be
looking for the MSI file on their local C drive instead of on the appropriate server.
The MMC does help you a little by giving you a reminder if you select a path that does not
seem to follow a network route (see Figure 153).
Figure 153: MMC Reminder
If you do make this mistake, despite the warning, you will get a clue on the workstation
when you check the Application log of the event viewer after the next reboot or logon,
depending on whether you are deploying to computers or users (see Figure 154).
Figure 154: Event Properties
Also, make sure that the network path you specify is shared with appropriate share and
NTFS permissions for the intended target community.
Take Advantage of Sites Notes
One of the main constructs in Active Directory is the site, defined

as a region of reasonably fast computer-to-computer connec-
tivity. You can leverage this architecture to increase the
performance of software deployment, and minimize traffic over
WAN links, by creating different GPOs for each site, each GPO
pointing to a distribution point local to that site.
Slow Link Behavior

For performance reasons, the default Group Policy behavior is
not to deploy applications across slow links. If you have ever
tried to install Microsoft Office over a modem line, you will
appreciate the reasoning behind this design decision.
If your organization has significant numbers of users who work
remotely for long periods of time, you may want to look into
SMS, which permits distribution of applications via CD-ROM.
Dfs Shares
Dfs (Distributed File System) is a mechanism for presenting a folder hierarchy in a logical
structure that differs from the underlying physical structure. You can choose to set up Dfs
for structural replication or structural-plus-data replication. Dfs is well suited for read-
only files such as MSI packages.
Under Dfs, you can define a single root share that contains subfolders pointing to shares
on different servers. (As Microsoft puts it, Dfs does for the network what a file system
does for a hard drive.) Folder A can reside on server A, and folder B on server B.
However, with Dfs, you can create a network share that contains both folder A and
folder B. Users do not have to know that the two folders are on different physical
machines.
In an Active Directory environment, the Dfs structure can be created to be Active
Directory-integrated, so that all domain controllers know about the structure. That
increases performance and reliability versus having a single, standalone Dfs server on the
network.
How does this fit in with Group Policy and software deployment? You can tell Dfs that
there is more than one read-only copy of folder A on the network: one on server A, and
also one on server 1. That way, if a user tries to access folder A through Dfs, and server A
is down, Dfs knows to point the user to the replicated read-only copy of folder A on server
1, which is not down. You accomplish this by telling Dfs that a specific target in its
namespace has more than one volume associated with it.
Setting up a Dfs share with multiple targets is one way of creating multiple distribution
points and ensuring that no single server becomes overtaxed by servicing policy-based
installation requests. It also adds a measure of fault-tolerance to your software deployment
architecture. On top of that, it can convey some performance benefits. For example, three
options exist for targets when using Dfs:
Default behavior: Use a server in the same site if possible; otherwise, use a
random server.
Enforced same-site behavior: Use a server in the same site; otherwise, deny
the installation.
Least-cost behavior: Use a server in the same site; otherwise, use the server
whose path has the least cost, as defined in Active Directory Sites and
Services.
Details about Dfs are well documented by Microsoft. For more on Dfs, see Designing
and Deploying File Servers, in the Planning Server Deployments book of the Windows
Server 2003 Resource Kit.
SMS and RIS

Other options for deploying applications include SMS and RIS, addressed here by way of
comparison.
Systems Management Server

Why would you use Microsoft SMS (Systems Management Server) instead of Group
Policy for software distribution? Here are a few of the features that SMS provides but that
Group Policy does not:
A scalable solution for large enterprise
Ability to upgrade the operating system
Scheduling
Reporting
Diagnostics
Inventory management
Support for Windows 95, Windows 98, and Windows NT 4 clients
No need for Active Directory
Coexistence
There is no reason that a given organization cannot use both SMS and Group Policy at the
same time. For example, some parts of an organization may be using Active Directory
while others have not yet migrated to Active Directory. Individual divisions, departments,
or branches may be responsible for their own IT infrastructure and may make different
decisions.
Remote Installation Service

Microsoft RIS (Remote Installation Service) is also available for software deployment. It
is most useful for deploying applications along with an initial operating system image.
The general technique is to create an ideal workstation with the desired operating system
and the main applications you want to deploy, then create an image (using the supplied
riprep tool) and upload that image to a RIS server.
Advantages of this method include:
No additional deployment software is required. RIS comes with Windows
2000 or Windows 2003 Server (although you must install it from the Add/
Remove Windows Components wizard).
Users receive their primary applications at the same time that they receive the
operating system, simplifying the process from their viewpoint.
RIS permits clients to boot over the network, so it can work even if the client
PCs have no previous operating system installed.
Disadvantages include:
RIS requires Active Directory.
RIS servers, and the network segments on which they reside, can become
overburdened if multiple users are deploying RIS images at once.
RIS does not support all common network interface cards.
Using the Software Update Service

The Software Update Service, or SUS, lets organizations distribute Windows patches. It is
not intended for distribution of applications or application updates, nor is it intended for
distribution of service packs.
Why would you use SUS versus, say, the decentralized Windows Update feature that
appears on the Start menu of many Windows client operating systems? Some advantages
of SUS include the following:
You can choose which updates you want to distribute to clients, including
noncritical updates.
You can test the updates before deploying them.
You can distribute the updates from a central location.
You do not need to leave installation decisions to end users.
You can distribute updates to computers that do not connect to the Internet.
Another plus is that SUS does not require Active Directory.
System Requirements and Limitations

Microsoft recommends that you use SUS if your primary software distribution mechanism
is Group Policy. If your primary distribution tool is SMS, then Microsoft suggests that you
do not use SUS but rather the SMS Feature Pack to distribute patches.
You can set up the server component of SUS on the following platforms:
Windows 2000 Server running SP2 or higher (the IIS Lockdown tool 1.0 and
the UrlScan security tool 2.0 must be applied after running SUS installation)
Windows 2003 Server
IIS 5.0 or higher is required
Internet Explorer 5.5 or higher is required
NTFS is required
Additionally, Microsoft recommends that SUS servers be dedicated machines because of
potential conflicts with other applications that interact with IIS. The upside is that one fast
dedicated server can (again, according to Microsoft) handle up to 15,000 clients.
However, a more realistic figure may be 10,000.
Server and Client SUS Components

The server component actually consists of three parts:
Windows Update Synchronization Service, which downloads content to the
servers running SUS. This service also synchronizes data among multiple
servers running SUS and distribution points within the intranet
An IIS Web site that responds to update requests from Automatic Updates
clients
An SUS Administration Web page
The client uses the Automatic Updates feature that you may be familiar with in connection
with the Microsoft Windows Update Web site; the difference here is that you point
Automatic Updates to the IIS site of your SUS server instead of to that public Web site.
Therefore, the client platform must be:
Windows 2000 Professional, Windows 2000 Server, or Windows 2000
Advanced Server running SP2 or higher (you must install an update to
Automatic Updates)
Windows 2000 Professional, Windows 2000 Server, or Windows 2000
Advanced Server running SP3 or higher (no update to Automatic Updates is
required)
Windows XP Professional or Windows XP Home (you must install an update
to Automatic Updates)
Windows XP Professional or Windows XP Home, SP1 or higher (no update to
Automatic Updates is required)
Deploying and Configuring the SUS Server
Server Setup
Figure 155: Server Setup: The SUS Installer with a Client Configuration Reminder
You can download the SUS server software from the following URL:
www.microsoft.com/windows/reskits/webresources
Figure 156: Server Setup: Completion of Installation with a Note on the Administration Page
After the software is downloaded, you will see a new entry in the Administrative Tools
folder, Software Update Services. Click this, and then choose Set Options, to perform
the following configuration tasks:
Make proxy server settings.
Specify the name of the SUS server (either NetBIOS or DNS).
Select the server to receive updates from (for example, the Microsoft public
Windows Update site). One SUS server can point to another SUS server for its
updates.
Choose the folder where you want to save the retrieved updates.
Specify the locales (languages) you want to support (the more you choose, the
more space your SUS server will need).
Decide whether you want to automatically approve for deployment updates to
updates you have already tested (No recommended).
Figure 157: Server Setup: The SUS Administration Screen in a Browser Interface
You can perform certain administrative tasks from any PC with Internet Explorer by
connecting to the following URL:
http://servername/SUSAdmin
where servername is the name of the SUS server.
Notes
In an Active Directory environment, network managers configure

SUS schedules and deployment details via Group Policy. If Active
Directory is not present, you can still use SUS but you have to
configure it via registry edits.
Regarding security, the content deployed to and from an SUS

server is checked for a Microsoft digital signature, but no checks
are performed to be sure (for example) that a given computer has
a bona fide computer account in Active Directory. Remember,
SUS can function in a non-Active Directory environment. Cyclic
redundancy checks are also performed by the Automatic Update
client to verify file integrity.
Security for the administrative Web page can be enhanced in one
of two ways:
Disallowing remote administration
Forcing remote administration to use SSL instead of
plain HTTP
Client Setup
After you have set up the server, you may (depending on the client OS) need to distribute
the update to Automatic Updates. The file of interest is wuau22.msi and it may be
deployed via Group Policy in the usual way (assigned, published, etc.).
Next, you must configure the behavior of the Automatic Updates client. Here is the
procedure for doing so via Group Policy (it is assumed that the ADM template wuau.adm
is present and loaded):
1. Create a new GPO or edit an existing GPO, as desired.
2. Expand Computer Configuration, Administrative Templates, and
Windows Components. Then click Windows Update.
3. On the Windows Update template, click Configure Automatic Updates.
4. Choose one of the following options:
Notify for download and notify for install: This option notifies a
logged-on administrative user prior to the download and prior to the
installation of the updates.
Auto download and notify for install: This option automatically begins
downloading updates and then notifies a logged-on administrative user
prior to installing the updates.
Auto download and schedule the install: Typically, if Automatic
Updates is configured to perform a scheduled installation, the recurring
scheduled installation day and time are also set.
5. The next step is to tell the Windows Update client where to look for its patches.
Click Specify Windows Update Server and type the name of your SUS
server.
You may want additional details about SUS if and when you implement it in your
environment. For example, the configuration of a multi-tiered SUS server hierarchy can
be somewhat complex and beyond the scope of this course. Visit www.microsoft.com and
search SUS for more information about this service.
MSI packages and MST files may be distributed via Group

Policy to sites, domains, and OUs. The two mechanisms are
assigning, which generally indicates a strong organizational
desire for users to get the applications, and publishing, which
indicates a desire for users to have the option to install the
applications. You can create your own MSI packages with the
help of third-party software through a process known as
packaging. You can specify distribution points and enhance
fault-tolerance and performance through the use of Dfs. SMS,
RIS, and SUS are other technologies that you should know about
when crafting a software deployment architecture for your
organization.
Knowledge
Check
Section Review
1. Name three goals of Microsoft MSI architecture.
2. List two scenarios in which Group Policy-based software deployment would not meet the
needs of an organization.
3. What practical issue should you consider before assigning an application to all the
computers in a given domain?
4. How could the Distributed File System improve the performance of a policy-based
deployment architecture?
5. In general, if your organization uses RIS, how would you divide up the labor of software
deployment between RIS and Group Policy? That is, what would you use RIS for, and
what would you use Group Policy for?
6. Can you run SUS on a Windows 2000 Server?
ABC Acronyms
ADM template administrative template

CRC cyclic redundancy check
DLL Dynamic Link Library
HTTP Hypertext Transfer Protocol
IIS Internet Information Server
MST Microsoft Software Transform
OS operating system
SMS Systems Management Server
SP2 Service Pack 2
SSL Secure Sockets Layer
SUS Software Update Service
Creating and Deploying ADM
Templates
Section Topics
Overview of ADM Templates
Standard ADM Templates
Registry Structure Used by ADM Templates
ADM Template Syntax
Creating Custom ADM Templates
Loading Additional ADM Templates
Using the Policy Template Editor
Creating and Deploying ADM Templates
N Knowledge
Guide
W E
Section Objectives
S

Describe the benefits of using ADM templates
List the ADM templates that come with each version of Windows
Explain the value of Office ADM templates
Identify the registry locations that ADM templates affect
List and explain the key words and syntax used in building ADM templates
Build your own ADM template from scratch with Notepad
Experiment with a third-party policy template editor
Load a new ADM template into the Group Policy console
Section Overview
One of the most important functions of Group Policy is to modify the registry, and
registry-based policy is implemented via something called administrative templates.
These templates are really nothing more than specially formatted text files. This section
explains the logic behind administrative templates, when to use them, and even the basics
of how to write them.
Overview of ADM Templates

What Are Administrative Templates Nodes?
In both the Computer Configuration and User Configuration nodes of the Group Policy
console appears the mysterious entry: Administrative Templates. This category has
always confused Group Policy students. A big part of the reason is that many of the
settings that you find under the Administrative Templates nodes have to do with
software settings and windows settings, and yet those two areas have their own separate
nodes in the policy console.
Figure 158: What Are Administrative Templates Nodes?
The answer to this apparent contradiction may help you understand the way the Group
Policy console is organized. In a nutshell:
The Administrative Templates node contains settings that may be
implemented solely through the registry and that are specified by files having
the extension .adm. Microsoft calls these settings registry-based policy.
The other nodes, Software Settings and Windows Settings, contain settings
that are likely to involve files outside the registry (such as scripts, software
packages, etc.) and these settings are not specified by *.adm files.
Notes So do not worry too much if you see settings in different console
nodes that appear to belong together thematically, but do not. The
fact is that, for example, settings related to security appear both
under Administrative Templates and Windows Settings.
Note
The top levels of the Group Policy console are organized

according to whether settings are implemented via *.adm files, not
according to topic.
What's in an ADM File?
Figure 159: What's in an ADM File?
What is included in the ADM files? Put simply, each ADM file is a Unicode text file that
contains the following information:
A list of related Group Policy settings
Where those settings should appear in the MMC
Notes Any options or restrictions that an administrator

can select
Default values for the settings (optional)
Which registry entries are affected when an
administrator enables or disables those settings
An explanation of each setting that the administrator
can read in the console (Windows NT 4-style ADM
files did not include this feature.)
Helpful Hint
The basic concept to remember is that ADM templates are the

"source code" for Group Policy settings.
Note
ADM templates are handled by the client-side extension

userenv.dll.
Why Have ADM Files at All?
ADM files offer benefits for:

z Application users
z Operating system users
z Software developers
Figure 160: Why Have ADM Files at All?
It may seem complicated that Microsoft chose to implement such a big chunk of the
Group Policy console via ADM files. What could they have been thinking? Why not
hardwire all the settings into a monolithic database that would serve as the foundation for
every Group Policy console?
The main reason is extensibility. The Group Policy console is extensible through the
mechanism of ADM files. If your organization buys a new application program for
deployment to your user community, assuming that the application developers saw fit to
create an ADM file for you, you may be able to centrally manage features of that
application within the Group Policy console. That has benefits for:
Application users: For example, say Acme Cognac, Inc. deploys Microsoft
Office 2000. However, a number of users have laptops that still run Office 97.
To ensure compatibility when users exchange documents, Acme installs the
Word 2000 ADM template into the Group Policy console. Now, it is possible to
specify that Word 2000 users will automatically save their documents in Word
97 format, by default.
Operating system users: Of course, the extensibility feature is handy for the
operating system, too. When Windows 2003 Server was released, Microsoft
did not have to redo completely the existing Group Policy structure; instead, it
created some new templates (ADM files) that could feed the old Group Policy
console information about the new settings available in Windows 2003 Server.
Software developers: If your are a software developer, the ADM file
methodology gives you a structured, predefined way of giving your customers
the ability to manage software settings centrally, through a console that they
are already using to manage the Active Directory environment.
Standard ADM Templates

When you first look at the Group Policy console, the Administrative Templates nodes in
both the Computer Configuration and User Configuration halves are already
populated. If that leads you to believe that you get some standard ADM templates installed
as part of the operating system load, you are correct.
Typically, ADM files for local Group Policy reside in the %Systemroot%\Inf folder
(normally, c:\Winnt\Inf or c:\Windows\Inf), and ADM files for network-based Group
Policy reside in the Adm folder within the Group Policy template in the Sysvol share, that
is, %Systemroot%\Sysvol\Domain\Policies\GPO_GUID\Adm (see Figure 161).
Figure 161: Standard ADM Templates
The standard ADM templates vary according to the version of Windows you install.
Windows 2000 Notes
The following standard templates are installed into the Group

Policy console by default.
System.adm: large file (727 KB), many different
settings
Inetres.adm: Internet Explorer settings
The following standard templates are not installed into the
Group Policy console by default:
Common.adm: settings common to Windows NT
and Windows 95 or Windows 98; Poledit style
Conf.adm: Microsoft NetMeeting settings
Inetcorp.adm: IEAK corporate settings
Inetset.adm: Settings for Internet Explorer defaults
that were not included in the IEAK wizard
Windows.adm: Windows 95 policy settings;
Poledit style
Winnt.adm: Windows NT policy settings; Poledit
style
Wmp.adm: Windows Media Player policy settings
If you install Windows 2000 Service Pack 3, you will have the
following ADM files:
Wmplayer.adm: Media Player settings, versions
8 and 9
Wuau.adm: Service Pack 3: Windows Update
Automatic Update
Notes Windows XP
Policy console by default:
System.adm: core settings
Wmplayer.adm: Media Player settings, versions 8
and 9
The following standard templates are not installed into the
console by default:
Conf.adm: NetMeeting settings
If you install Windows XP Service Pack 1, you will have the
following ADM file:
Wuau.adm: Service Pack 1; Windows Update
Automatic Update
Note that Microsoft recommends that all Active Directory
administrators be running Windows XP with the updated
ADM files. If you run Windows XP and administer a GPO that
has an outdated ADM file, your computer will automatically
update the ADM file, or files, of the GPO as long as the new
files are resident in the server. Therefore, if you have Windows
2000 Server, you should manually update the ADM files in the
Windows 2000 Server Inf folder by copying them up from a
Windows XP box and then using the Add/Remove Template
command to remove the old and add the new.
Windows 2003 Notes

Policy console by default:
System.adm: large file (727KB), many different
settings
Conf.adm: NetMeeting settings
The following standard templates are available, but not installed
into the Group Policy console by default:
Common.adm: Settings common to Windows NT
and Windows 95 or Windows 98, Poledit style
Inetcorp.adm: Internet Explorer Administration Kit
corporate settings
Inetset.adm: Settings for Internet Explorer defaults
that were not included in the IEAK wizard
Windows.adm: Windows 95 policy settings, Poledit
style
Winnt.adm: Windows NT policy settings, Poledit
style
Wmp.adm: Windows Media Player policy settings
Wuau.adm: Windows Update Automatic Update
Note
Wuau.adm gets installed automatically if you install Software

Update Service on the machine.
Poledit Templates
The standard ADM files for use with Poledit, the System Policy Editor, in Windows
NT 4 are:
Common.adm: settings common to Windows NT and Windows 95 or
Windows 98
Winnt.adm: Windows NT policy settings
The standard ADM file for use with System Policy Editor in Windows 95 is:
Windows.adm
! Caution
Microsoft does not recommend using Windows NT 4 , Windows 95-, or Windows 98-style
ADM files with Windows 2000, Windows XP, or Windows 2003 Server.
If you do use these older templates, or if you create your own custom ADM files that make
registry settings outside the four approved registry keys for Group Policy, the default
MMC behavior is for them not to appear. You can force them to show up with the
procedures described below.
Windows 2000
1. Select the Administrative Templates node that you wish to modify.
2. Right-click and choose View to display the cascading menu.
3. Clear the Show Policies Only setting by selecting it.
Windows XP
1. Select the Administrative Templates node that you wish to modify.
2. Right-click and choose View to display the cascading menu.
3. Choose Filtering.
4. Clear the Only show policy settings that can be fully managed checkbox.
If you force Windows NT 4-style policies to appear in the console, they will appear in red
icons. Windows 2000 and later Group Policy settings will appear in blue.
You can force the setting with the following policy:

User Configuration/Administrative Templates/System/Group Policy/Enforce Show
Policies Only
Office ADM Templates

Microsoft provides ADM files for its Office products, including Office XP, Office 2000,
and Office 97. If your organization uses one of these versions of Office, you may discover
that using the vendor-supplied ADM files can dramatically extend the usefulness of the
Group Policy console.
For example, the ADM files for Office XP include the following:
Access10.adm
Excel10.adm
Fp10.adm
Gal10.adm
Office10.adm
Outlk10.adm
Ppt10.adm
Pub10.adm
Word10.adm
Here is a sampling of the sorts of policies you could find in these files:
Access
Default database folder
Trust all installed add-ins and templates
Path to shared Workgroup information file for secured MDB files
List of error messages to customize
Disable command bar buttons and menu items (many choices here)
Disable shortcut keys
Do not prompt to convert older databases
Custom Answer Wizard database path
Excel
Startup Task Pane Enable AutoComplete for cell
Show Formula bar in Normal values
View Extend list formats and formulas
Show Status bar in Normal Enable automatic percent entry
View Show Insert Options buttons
Show Formula bar in Full R1C1 reference style
View
Function tooltips
Show Status bar in Full View
Recently used file list
Windows in Taskbar
Zoom on roll with IntelliMouse
Comments
Font
Edit directly in cell
Default file location
Allow cell drag and drop
Save Excel files as (various options)
Alert before overwriting cells
Save AutoRecover info
Move selection after Enter
AutoRecover time
Fixed decimal to 2 places
AutoRecover save location
Cut, copy, and sort objects
with cells Customizable error messages
Disable command bar buttons and
Ask to update automatic
menu items (many choices)
links
Provide feedback with
Animation
Office Notes
Disable VBA for Office applications
Always show full menus
Large icons
Show ScreenTips on toolbars
Menu animations
Smart Tags
Correct TWo INitial Capitals
Correct accidental use of cAPS LOCK key
Update links on save
Target monitor (various sizes)
Make sounds
Display menus and dialog boxes in (language)
Collaboration Settings
Corporate Error Reporting
Do not track document editing time
Do not emulate tabs with spaces when exporting
HTML
Disable web view in the Office file dialogs
Word
Status bar Adjust sentence and word
Horizontal scroll bar spacing automatically
Adjust formatting when pasting
Picture placeholders
from Microsoft Excel
Field shading
Drag-and-drop text editing
Formatting marks (for
Picture editor
example, paragraph marks,
spaces, etc.) When selecting, automatically
select entire word
White space between pages
(Print view only) Background printing
Wrap to window Options for Duplex Printing
Draft font Always create backup copy
Rely on CSS for font Allow fast saves
formatting Save Word files as (many format
Blue background, white text options)
Provide feedback with Check spelling as you type
animation Check grammar as you type
Confirm conversion at Open File Locations (various)
Help for WordPerfect users AutoFormat as you type (various
Navigation keys for suboptions)
WordPerfect users Trust all installed add-ins and
Measurement units templates
Disable features not supported List of error messages to
by specified browsers customize
Disable command bar buttons
and menu items (many)
Registry Structure Used by ADM Templates

Machine vs. User
Administrative template files can apply to the computer-specific portion of the registry or
to the user-specific portion. Specifically:
ADM templates that apply to the Computer Configuration half of the MMC
console affect the HKEY_LOCAL_MACHINE branch of the registry.
ADM templates that apply to the User Configuration half of the MMC
console affect the HKEY_CURRENT_USER branch of the registry.
True Policies vs. Preferences

Windows 2000 and later Group Policy settings live in one of four registry locations:
HKLM\Software\Policies
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies
HKCU\Software\Policies
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies
The first and third locations in this list are preferred, but policy settings that live in any of
the above four locations are said to be true policies.
The older Windows NT 4-style System Policy Editor, and the ADM templates that it used,
would place policy settings in a wide variety of registry locations. This created problems
with security and with tattooing, or the undesired persistence of policy settings.
Sometimes, you may find it necessary to tattoo the registry with a setting that does not
correspond to any of the above four locations.
Settings that live somewhere other than the above four locations are said to be prefer-
ences rather than true policies because it is possible for the user to change them by using
Regedit. On the other hand, if a user changes a true policy with Regedit, it will be changed
back to the original setting at the next policy refresh.
Helpful Hint
You can cause preferences to display in the Group Policy console, as explained in Poledit
Templates.
ADM Template Syntax
The predefined keywords used in ADM files

include:
z CLASS
z CATEGORY
z POLICY
z KEYNAME
z VALUENAME
z PART
z EXPLAIN
z STRINGS
Figure 162: ADM Template Syntax
ADM files use a limited number of predefined keywords for structure and function
(see Figure 162). Following is a summary of these keywords and the syntax that
accompanies them.
Helpful Hint
ADM files are Unicode text files. If you use Notepad, be sure to save the files in
Unicode format, otherwise the double-quotes that show up in your ADM file will
also show up in your MMC.
Also make sure you save your files with the .adm extension (not .adm.txt that
is). You can put the file name in quotation marks to be sure Notepad does not
append the .txt to the file name.
CLASS
The value for the CLASS entry can be either MACHINE or USER, depending on which
half of the policy console the setting should apply to. This value also defines whether the
affected registry entries should appear in HKEY_LOCAL_MACHINE or
HKEY_CURRENT_USER.
Example:
CLASS MACHINE
You can have both CLASS MACHINE and CLASS USER statements in a
single ADM file. The settings that appear underneath each statement will apply
to the specified console node.
(This data type was also used in Windows NT 4 system policy ADM files.)
CATEGORY
The value for the CATEGORY entry is typically a metastring beginning with two
exclamation marks. The metastring refers to an actual string of text that appears later in
the ADM file, under the STRINGS entry.
Helpful Hint
Using metastrings makes it easier to change your strings later on, because the actual
strings are all grouped together in one place. It also makes it easier to translate your
ADM file to a different language. However, they are not mandatory. Wherever you use
metastring notation, you may also use the direct literal string, preferably enclosed by
double quotation marks.
The string is what console users will see under the Administrative Templates node in the
tree pane of the Group Policy console. It acts as a container for individual policy settings.
Example:
CATEGORY !!StartMenu
KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\
Explorer"
POLICY !!NoStartMenuSubFolders
EXPLAIN !!NoStartMenuSubFolders_Help
VALUENAME "NoStartMenuSubFolders"
END POLICY
POLICY !!NoWindowsUpdate
EXPLAIN !!NoWindowsUpdate_Help
VALUENAME "NoWindowsUpdate"
END POLICY
END CATEGORY ; Start Menu
You can have multiple categories in a single ADM file. The settings that appear
underneath each CATEGORY statement will appear inside that category
container.
You can have nested categories as well. For example, Active Desktop is a
subcategory under the Desktop category.
At the end of each CATEGORY section, include an END CATEGORY line.
POLICY
The value for the POLICY entry is a metastring beginning with two exclamation marks.
The metastring refers to an actual string of text that appears later in the ADM file, under
the STRINGS entry.
The string is what console users will see under the Category node under the
Administrative Templates node in the tree pane of the Group Policy console. It
names an individual policy setting.
Underneath the POLICY line typically appears an entry for VALUENAME, although
other entries that can appear include EXPLAIN, KEYNAME, ITEMLIST, and PART.
Example:
END POLICY
At the end of each POLICY section, include an END POLICY line.
KEYNAME
The KEYNAME specifies the precise registry key that contains one or more values to be
modified by the policy. Typically, KEYNAME uses a literal string rather than a
metastring.
Example:
KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\
Explorer"
Note
You do not include the topmost key (HKEY_LOCAL_MACHINE or

HKEY_CURRENT_USER) when specifying the KEYNAME. The CLASS setting tells
Windows which branch you are using.
The KEYNAME stays in effect for subsequent child policies until explicitly
overriden by a separate KEYNAME entry.
VALUENAME
The VALUENAME item inside of a POLICY item is the name of the registry value to be
modified. (The precise location of the value is specified by KEYNAME.) Typically,
VALUENAME uses a literal string rather than a metastring.
Example:
The type of the registry value is presumed to be REG_SZ (single string) unless specified
otherwise, with the NUMERIC designator.
PART
A policy part is a component of a policy in a particular input format. The major parts
include the following:
CHECKBOX
COMBOBOX
DROPDOWNLIST
EDITTEXT
LISTBOX
NUMERIC
Each of these PART types has specific associated keywords that amplify or detail its
function. Here are a few examples:
With CHECKBOX:
Use VALUEON to change the ON entry of the registry value to be other than
1, the default.
Use VALUEOFF to change the OFF entry of the registry value to be other
than 0, the default.
With EDITTEXT:
You can use DEFAULT to specify a string or metastring with which to
prepopulate the edit dialog box, which is helpful to the administrator by
showing an example of correct notation.
You can use MAXLEN to specify the maximum length of the string to be
entered or edited.
With NUMERIC:
Use MIN, MAX, and DEFAULT to specify those three values.
Use REQUIRED to tell the console not to add the policy unless the value is
specified.
Helpful Hint
For details about the keywords associated with all the various PART types in ADM
templates, visit msdn.microsoft.com and specify part types in the search box.
EXPLAIN
New for Windows 2000, the EXPLAIN keyword allows the ADM template author to
define some explanatory help text for the policy setting. It is strongly recommended that
you take advantage of this feature so that other network administrators will know the
following:
Exactly what your policy change does
When to use it
When not to use it
Which other policy settings, if any, are related to and/or interdependent from,
this one
Example:
END POLICY
SUPPORTED
New in Windows XP, the SUPPORTED keyword displays the minimum version of
Windows that the subject policy works under. The SUPPORTED keyword has no
meaning to the Windows 2000 console, therefore it is always surrounded by an
#if...#endif structure limiting its processing to the Windows XP version of the console
(version 4).
Example:
#if version >= 4
SUPPORTED !!Supported_in_Win2000
#endif
STRINGS
Rather than bog down the main body of the ADM file with lengthy strings (the EXPLAIN
strings can run into several paragraphs), the ADM file uses metastrings (with a leading
double exclamation point) to refer to a STRINGS section that you typically find at the end
of an ADM template.
The STRINGS section is really a lookup table that matches up the concise metastrings
with the verbose actual strings. The string name appears, followed by an equals sign, then
the literal string in double quotation marks. (The quotation marks are really only
mandatory if the string contains spaces; however, it is good programming practice to use
them.)
Example:
NoWindowsUpdate_Help="Prevents users from connecting to the Windows
Update Web site.\n\nThis policy blocks user access to the Windows
Update Web site at http://windowsupdate.microsoft.com. Also, the
policy removes the Windows Update hyperlink from the Start Menu and
from the Tools menu in Internet Explorer.\n\nWindows Update, the
online extension of Windows, offers software updates to keep a
user's system up-to-date. The Windows Update Product Catalog
determines any system files, security fixes, and Microsoft updates
that users need and shows the newest versions available for
download.\n\nAlso, see the "Hide the "Add programs from Microsoft"
option" policy."
Notice the use of \n\n in the above example to create a paragraph break.
When you have multiple metastrings, list them in alphabetical order. This is not required,
but is simply good programming practice.
Creating Custom ADM Templates

Now that you know the major data types and sections used in creating custom ADM
templates, you are equipped to write your own. All you need is your favorite text editor
(Notepad works).
Programming Tips
Helpful Hint
Document your custom ADM files. Use the semicolon character (;) at the start of a line to
indicate a comment. Other people are likely to read your files and edit them for their own
purposes. It is good programming practice to make that as convenient as possible.
Prevent Windows NT systems from accidentally loading your Windows 2000, Windows
2003, or Windows XP ADM files by including a section beginning with #if version <= 2 and
ending with #endif that merely displays explanatory text advising the administrator that this
policy file requires Windows 2000 (or another OS). Version 2 signifies the Windows NT
policy editor, version 3 signifies the Windows 2000 console, and version 4 signifies the
Windows XP console.
A Simple Example
Here is an example of a custom ADM template that contains a single policy entry, the
SourcePath value in the registry that indicates where Windows 2000 was originally
installed from. You may want to be able to modify this value from time to time, as for
example if the distribution server that was used to install client operating systems is
renamed. The reason is that Windows 2000 and Windows XP use the SourcePath value
after installation. For example:
You install a device driver that is not contained in driver.cab.
Windows File Protection needs to reinstall an operating system file that is in
neither dllcache nor driver.cab.
The registry value of interest here is:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current-
Version\Setup\SourcePath (REG_SZ). As the value is a string, you need to create an
ADM file that lets the administrator enter whatever path contains the Windows source
path (for example, \\Dist_Srv\Winxp).
Note
Normally, you would not create an ADM file that contains only one entry. This is just an
example.
The first part of the ADM file will refer to the half of the console (and registry) that this
setting applies to, namely, the machine:
CLASS MACHINE
Say we want to add this entry to the System node under Administrative Templates. So,
the category is a metastring referring to the literal string Acme System Settings, as
follows:
CATEGORY !!Administrative
Now we have to give the policy itself a metastring name:
POLICY !!SetupSourcePath
Next, we specify the registry key to be modified, as follows:
KEYNAME "Software\Microsoft\Windows\
currentVersion\Setup"
And then the value to edit:
PART !!SourcePathBox EDITTEXT
VALUENAME "SourcePath"
END PART
In this example, the EDITTEXT indicates that the administrator is to edit a text box,
rather than click a checkbox, for example.
Including the following line provides explanatory text:
EXPLAIN !!SourcePathExplain
Dotting the is and crossing the ts, you end up with the following:
; Filename: SOURCE.ADM
; Example of a simple custom ADM template
; Glenn Weadock, August 2003
CLASS MACHINE
CATEGORY !!Administrative
POLICY !!SetupSourcePath
KEYNAME "Software\Microsoft\Windows\
CurrentVersion\Setup"
PART !!SourcePathBox EDITTEXT
VALUENAME "SourcePath"
END PART
EXPLAIN !!SourcePathExplain
END POLICY
END CATEGORY
[STRINGS]
; This section is typically alphabetized for convenience.
Administrative="Acme System Settings"
SetupSourcePath="Change Setup Source Path"
SourcePathBox="Enter the path to the Windows distribution share:"
SourcePathExplain= "Change this value if you rename the distri-
bution server on the network that contains the \I386
folder.\n\nThis server location must be available in certain
situations, such as when installing a new device driver that is not
contained in DRIVER.CAB, or when Windows File Protection attempts
to restore a file that is not contained in DLLCACHE or DRIVER.CAB."
To view the new setting, you need to turn on the ability of the MMC to view preferences
as opposed to true policies.
Figure 163: Viewing the New Policy Settings
Loading Additional ADM Templates
Figure 164: Loading Additional ADM Templates
The procedure for loading an additional ADM template into the Group Policy console is
as follows:
1. Open the GPO you wish to edit.
2. Right-click the Administrative Templates node in the tree pane (either in
Computer Configuration or in User Configuration. The software vendor
will typically advise as to the correct procedure.)
3. Choose Add/Remove Templates. A list of installed templates appears (see
Figure 164).
4. Click Add.
5. Browse to the template you wish to add, highlight it, and click Open.
6. Click Close in the Add/Remove Templates dialog box.
Notes
Helpful Hint
Remember that if you add a template that contains preferences

rather than true policy settings, you will need to set the MMC to
view those preferences, as the default behavior is to hide them.
Using the Policy Template Editor

If you find yourself doing a fair amount of work with custom ADM files, you may be
interested in a product from www.tools4ever.com called Policy Template Editor. As of
this writing, you may download an evaluation version of this product and experiment
with it at no cost for 30 days. After that, it is $299 (again as of this writing) for a
per-administrator license.
To quote from the Web site, The Policy Template Editor allows the network manager
himself, very simply and with the use of graphical aids, to make new policy template
files or to modify existing ones. The Policy Template Editor then generates the complex
template files.
Figure 165: Using the Policy Template Editor

You can import *.adm files from your software suppliers to
leverage the Group Policy infrastructure and make directory-
based settings for applications. Microsoft supplies ADM files for
recent versions of its Office applications suite. If ADM files for a
particular application do not exist, you can make your own, either
from scratch or with the help of third-party software, such as the
Policy Template Editor. These files can modify the policy
portions of the Registry or Registry settings outside the policy
nodes in which the settings are referred to as preferences.
Knowledge
Check
Section Review
1. List the kinds of information that must be present in an ADM file, at a minimum.
2. What is the procedure for importing a new ADM file so that the settings it contains
become available in the Group Policy console?
3. What ADM files get installed by Service Pack 3 for Windows 2000, and what do they do?
4. What are the possible values for the CLASS entry in an ADM file?
5. Name four different Parts of an ADM file and describe when you would use them.
6. Does the MMC show preferences in its default configuration?
ABC Acronyms
ADM template administrative template

GPO Group Policy Object
IEAK Internet Explorer Administration Kit
KB kilobytes
Software Restriction Policies
Section Topics
What Is a Software Restriction Policy?
How to Create a Software Restriction Policy
Software Restriction Policy Options
Additional Rules to Identify Software
Software Rules Precedence
Creating an Effective Software Restriction Policy
Deployment Summary
N Knowledge
Guide
W E
Section Objectives
S

Define an effective software restriction policy
List the software restriction components
Describe enforcement options that are available
Explain the concept of conditional modes of operation
Deploy additional rules
List the order of precedence of additional rules
Section Overview
This section details the deployment of software restriction policies including the essential
components, rules, and the order of precedence of such policy.
What Is a Software Restriction Policy?
Figure 166: What Is a Software Restriction Policy?
Software restriction policies monitor and control what is called hostile code that is
introduced through e-mail or scripts on, or downloaded from, Web pages that are visited
by the client. It also controls unauthorized software applications that are installed and
downloaded by users. Software policies have the following characteristics:
Software policies specify which programs can or cannot be run.
Software policies can be applied to local machines, sites, domains, or OUs.
Software policies are created using the Group Policy MMC. A properly
deployed software restriction policy defines the rules of your company
regarding which software applications and components that are used on a daily
basis are to be trusted.
Software policies allow you to define what potentially dangerous software

components and executables are to be monitored and controlled.
Software policies that help you protect your clients against the use of unknown
and potentially malicious software applications are a welcome addition to
existing security options.
Many stealth applications are delivered through the mail and across the Internet, resulting
in the need of an extra layer of protection for clients connected to the outside world.
The software restriction policy process can help you control:
The spread of viruses
The ActiveX components that can be downloaded
Execution of only those scripts that have been digitally signed
Execution of approved software applications throughout your corporation
Who Can Use a Software Restriction Policy?

A software restriction policy can be deployed on Windows XP and Windows 2003
operating systems using Group Policy deployed through Active Directory.
Windows 2000 clients can have several minimalist options in the System section of Group
Policy that allow some control of which Windows applications can or cannot be executed
and some administrator controls that can be applied to Microsoft Internet Explorer.
However, a software restriction policy goes much further.
Software Restriction Components

Software restriction policy is defined through two key components:
A defining security level, which lists the authorization level for a particular
software application or software component that a User group uses on a
daily basis.
Custom roles, which further define the maximum authorization level of an
application.
When a user or group runs a software application, these two rules conspire to provide an
effective level of authorization that the selected application is then allowed to execute.
Software Restriction Policy Architecture
Policy is
downloaded by
Group Policy to
machine
Define policy for
domain using
Group Policy editor
System
Policy
Enforced by operating
system when software
is run
Figure 167: Software Restriction Policy Architecture
The software restriction policy uses a default rule, which decides what software applica-
tions can execute.
The default rule can be set to Unrestricted or Disallowed, that is, run or do not run.
There are three main components of a software restriction policy:
First an administrator would create the policy using the Group Policy editor.
The policy could be created at the standard Group Policy divisions; at the site,
domain or organizational unit level.
After the policy has been saved and replicated through Active Directory, it is
applied to the computer systems at the next machine reboot or to the user at the
next logon.
Notes The next time a user starts a program or script, the

operating system compares the request against the
current software restriction policy and allows or
denies the request.
Software restriction policies do not apply to the following code:
System drivers and required kernel mode software
Any program or process runs by the local System
account
Any macros contained inside Office 2000 or Office
XP documents
How to Create a Software Restriction Policy
Figure 168: How to Create a Software Restriction Policy
Following are the guidelines for creating a software restriction policy:

The proper administrative privileges must be granted before you can create a
software restriction policy for a local computer system or a policy based on
Active Directory.
You must be the local administrator of the local computer system or have been
delegated administrative permissions.
You must be a member of the Domain Admins or Enterprise Admins group if
the computer has been joined to an Active Directory domain.
Delegation of specific tasks is performed using the Delegation of Control Wizard as
shown in Figure 168.
Creating Policy for a Local Computer

To create a local software restriction policy for a local computer system:
1. Log on locally as administrator and open the Local Security Policy from the
Administrative Tools menu.
2. Open Computer Settings, Security Settings, Software Restriction Policies.
Creating Policy for a Domain-Based Computer

Windows XP computer systems and Windows 2003 domain controllers or servers that are
members of the domain use the following steps:
1. Log on to the domain as Domain Admin or Enterprise Admin.
2. Open the Active Directory Users and Computer console.
3. Select the OU that holds the workstations or member servers where a policy is
to be applied.
4. From the properties of the OU, select the Group Policy tab.
5. Create a new GPO for the policy to be applied, and open it.
6. Navigate to Computer Settings, Security Settings, Software Restriction
Policies.
Creating Policy for a Site

To create a policy for a Windows 2003 site, follow these steps:
1. Log on to the domain as Domain Admin or Enterprise Admin.
2. Open the Active Directory Sites and Services console.
3. Select the site, and from the properties of the site select the Group Policy tab.
4. Create a new GPO for the policy to be applied, and open it.
5. Navigate to Computer Settings, Security Settings, Software Restriction
Policies.
Software Restriction Policy Options
Figure 169: Software Restriction Policy Options
Software restriction policy options include the following:

Software policy can be applied to the local machine account, or at the site,
domain, or OU level.
There are four enforcement options for software restriction policies:
- DLL checking
- All software files
- All users
- All users except local administrators
The All users except local administrators option can be used only on
machine-level software restriction policies.
Groups can also be used to filter which policies are enforced.
DLL Checking
Most software programs start from an executable file (EXE), followed by loading of
several DLL files.
The default option is to not enforce any restrictions on DLLs, and this makes sense; if the
EXE is disallowed, the DLLs will not load.
Note
Restricting all DLLs for a particular process could involve rerunning the software restriction
policy many times. For example, the launching of Microsoft Excel causes many DLLs to
load, and, therefore, would cause the software restriction policy to run many times as well.
If you are in an environment where known DLLs are targeted with viruses, you can
protect a software program that has not been infected by a virus by enabling a number
of hash rules that identify the executable and all of its linked DLLs. To turn on DLL
checking, select the following option in the Enforcement Properties dialog box, as
shown in Figure 169: All software files except libraries (such as DLL).
Skip Administrators
An administrator may want to disallow the running of programs for most users but allow
local administrators to run all software.
To turn on Skip Administrators, select the following option in the Enforcement
Properties dialog box shown in Figure 169: All users except local administrators.
Selecting Executables to Protect
Figure 170: Selecting Executables to Protect
The Designated File Types Properties dialog box lists the default file types that the
software restriction policy applies.
The designated file types are file types that can be executed by users and the operating
system.
The rules in a software restriction policy apply only to the file types listed in the
Designated File Types Properties dialog box.
If your environment uses a file type that you want to be able to set rules on to control its
execution, add it to the list using the Add button.
Trusted Publishers
Figure 171: Trusted Publishers
The trusted publishers options shown in Figure 171 allow you to configure settings related
to ActiveX controls and certificates.
Figure 172 below shows the trusted publishers options for the use of ActiveX controls and
certificates.
Trusted Publishers Options Applied Policy Setting
Allow domain administrators to make decisions regarding signed Enterprise administrators
active content
Allow local machine administrators to make decisions regarding Local computer administrators
signed active content
Allow any user to make decisions regarding signed active content End users
Ensure that the certificate used by the software publisher has not Publisher
been revoked.
Ensure that the certificate used by the organization is time-stamped Timestamp
Figure 172: Trusted Publisher Options for ActiveX Controls and Certificates
Default Security Levels and Exceptions
Following are default security settings for

software restriction policies:
z By default a software restriction policy is not
enabled.
T Unrestricted
T Disallowed
z Software restriction policies can be either user
or machine policies.
z It is also possible to create policies that apply
to particular users only when they long on to
particular machines using loop back
processing
Figure 173: Default Security Levels and Exceptions
Modes of Operation
The two conditional modes of operation used by software restriction policies are:
Unrestricted: With this defined as the default, all software programs will run
except those that are specifically listed to not run using the Group Policy
setting: Dont run specified Windows Applications found in User
Configuration\Administrative Templates\System.
This feature is available for Windows 2000, Windows 2003, and Windows XP
computer systems
Disallowed: All programs will be blocked from running unless they are on the
list of programs that are allowed to run.
Therefore, if an administrator has a master list of the software that is allowed to
run, then a policy can be applied controlling the execution of trusted
applications.
Notes Machine and User Policy

Machine policies are applied when the computer starts and
will apply regardless of what user logs on to the computer.
User policies are applied when a user logs on and will apply to
that user regardless of what machine the user is logged on to.
The popularity of Microsoft applications, applets, and
communication services results in a very well-known base of
software components that make up the core software
application base of a typical corporate computer system. The
most common components are Microsoft Internet Explorer,
Office, Outlook, Outlook Express, and a core set of DLLs and
Active X components. Since these components exist on most
computer systems that are connected to the Internet, they
make an excellent target.
Without an applied software restriction in place, all programs
run under the effective context of the logged on user. So if
your users have access to source code loaded on a file server,
so does a loaded instant messenger or e-mail program. If
permissions are broad enough, an application can perform its
operation using the privileges of the logged on user quietly
and without being noticed.
Additional Rules to Identify Software
The rules used to identify software and software

components include:
z Hash: A fingerprint of a file
z Certificate: A digital certificate provided by a
manufacture
z Path: The UNC path of where the file is located
z Zone: A defined Internet zone
Figure 174: Additional Rules to Identify Software
Rules are used to identify a list of software applications and their execution status:
whether they can or cannot run. Additional rules can be created to help identify software
and its components.
Each rule is assigned a unique GUID, so every rule will have a different GUID, making it
useful for troubleshooting. The following table details when to use each rule for the most
effective security solutions.
Desired Software Security Use This Rule
Allow or disallow a particular software application. Hash rule: select the hash rule and select the file to
create a hash.
Identify a software application with a generic Path rule using variables:
system path. %ProgramFiles%\Kaza\kaza.exe
Identify a software application installed locally. Registry path rule:
%HKEY_LOCAL_MACHINE\SOFTWARE\
ComputerAssociates\Inoculate\5.0\Path\HOME%
Identify scripts stored at a particular network Path rule:
location. \\Servername\share
Identify scripts stored at multiple network Path rule using wildcards:
locations. \\Servername??\share
Disallow all Visual Basic scripts. Path rule:
*.vbs set to Disallowed
Disallow all Visual Basic scripts with the exception Path rule using wildcards:
of a particular folder location used for login scripts. *.vbs set to Disallowed;
\\LOGON_SRV1\Share\*.vbs set to Unrestricted
Disallow a particular file installed by a known Path rule:
virus. *.exe set to Disallowed
Identify scripts for global use. Certificate rule: all scripts signed by digital certificates
Allow software packages (MSI) to be installed Zone rule: set desired trusted site to unrestricted
from trusted Internet zone types.
Figure 175: Rules for Effective Security
The Hash Rule
Figure 176: The Hash Rule
A hash rule used with a software restriction policy is a cryptographic fingerprint that is a
mathematical calculation of the file contents that uniquely identify a file without regard to
its location or current name. So if a file is moved from a default location, or renamed, it
will not avoid the defined hash rule. A hash rule has the following components:
The MD5 or SHA-1 hash value
The file length
The hash algorithm ID
The following format is used:
[MD5 or SHA-1 hash value]: [file length]: [hash algorithm ID]
MD5 was developed by Professor Ronald L. Rivest of MIT. MD5 accepts a file of any
length and produces a 128-bit message digest of the input file. Two files cannot be passed
through the MD5 algorithm, producing the same message digest.
Notes SHA-1 was developed by NIST, along with the NSA, for use
with the DSS. SHA-1 accepts as input a file of any length and
produces as output a 160-bit message digest of the input.
Note
Each version of a software program needs to be fingerprinted as

each uses a different executable file with its own associated
components.
The Certificate Rule
Figure 177: The Certificate Rule
The certificate rule specifies that the selected software application is protected by a
code-signing, software publisher certificate.
A certificate can be issued from a third-party certificate authority such as RSA, or
VeriSign, from a Microsoft Certificate Authority using a Windows 2000 or Windows 2003
domain controller and the Microsoft Certificate Server service, or it can be a self-signed
certificate.
Software applications, ActiveX controls, and scripts can be signed by a certificate issued
by the software publisher.
A certificate uses multiple hashes contained in the signature of the signed file to verify the
authenticity of the file, regardless of its location and name.
The Path Rule
Figure 178: The Path Rule
Characteristics of path rules are as follows:

The path rule only applies to NTFS volumes.
Path rules apply to folders, files, and registry hives.
Local and UNC paths and environment variables are fully supported.
Using the path rule as shown in Figure 178, the complete path to the executive file or the
folder location to the software application can be specified. If only a folder is contained in
the path rule, the rule will match any program found in the root folder and any subfolder.
This could be handy in protecting multiple versions of the same software application,
which would have the same executive file name but a different storage location.
Environment Variables
Environment variables can also be used in paths. Typing Set at the command prompt lists
the current system and user environment variables in use. Standard environment variables
that can be used include:
COMPUTERNAME
HOMEDRIVE
HOMEPATH
LOGONSERVER
TEMP
TMP
USERDOMAIN
USERNAME
USERPROFILE
WINDIR
Wild Cards
The wild cards ? and * can also be used in path rules. *.vbs could be used to refer to all
Visual Basic scripts. For example:
\\CORP-??\login$ matches \\CORP-01\login$, \\CORP-02\login$
*\Windows matches c:\Windows, e:\Windows, f:\Windows
c:\win* matches c:\winnt, c:\windows, c:\winxp
Registry Path Rules
Figure 179: Registry Path Rules
Most software applications store the path to their installation directories in the local
registry. A path rule can be created that checks these registry keys as shown in Figure 179.
The registry path is used to locate the software application on the local hard drive.
Registry paths are written in the following format and with the following rule: the entire
path must be enclosed in % at the start and end.
%[registry hive]\[registry key name]\[value name]%
To make it easier to cut and paste a registry path into a path rule, use the Copy Key Name
option found on the Edit menu. Registry path statements written to a path rule use either a
text string REG_SZ or REG_EXPAND_SZ. In addition, the full name of the registry
hive must be used, as in HKEY_LOCAL_MACHINE, or HKEY_CURRENT_USER
and not short form names, for example HKLM or HKCU.
When using multiple matching path rules, there is an order of precedence: the path having
the closest or exact path is processed last.
1. Drive:\Folder1\Folder2\FileName.Extension
2. Drive:\Folder1\Folder2\*.Extension
3. *.Extension
4. Drive:\Folder1\Folder2\
5. Drive:\Folder1\
The Internet Zone Rule
Figure 180: The Internet Zone Rule
The zone rule is used to identify Windows Installer MSI packages that are downloaded
from a specified Internet Explorer zone.
Software Rules Precedence
The order in which the software rules are applied is:

1. Hash rule
2. Certificate rule
3. Path rule
4. Internet zone rule
5. Default rule
Figure 181: Software Rules Precedence
Software rules are reviewed and applied in a specific order. A specific rule will win out
over a generic rule.
Following is an example of how the filtering of rules is reviewed and then applied.
Default security level: Unrestricted
Hash rules
Rule 1 Hash of pagefileconfig.vbs Disallowed
Path rules
Rule 2 %WINDIR%\System32\*.vbs Unrestricted
Rule 3 *.vbs Disallowed
Rule 4 %WINDIR% Unrestricted
Figure 182: Filtering of Rules
Process 1
A Visual Basic program attempts to start in the local location:
c:\WINDOWS\SYSTEM32\EventQuery.vbs
This program matches the following rules currently in force:
Rule 2: It is a .vbs file in the System32 folder.
Rule 3: It has a .vbs extension.
Rule 4: It is stored in a subfolder under the Windows root directory.
Outcome
After reviewing the current rules, the most specific match is rule 2. Since rule 2 has a
security level of Unrestricted, the program is allowed to run.
Process 2
A Visual Basic program is being start in the following local location:
c:\WINDOWS\SYSTEM32\pagefileconfig.vbs
This program matches the following rules currently in force:
Rule 1: The hash in the rule matches the hash of the file.
Rule 2: It is a .vbs file in the System32 folder.
Rule 3: It has a .vbs extension.
Rule 4: It is stored in a subfolder under the Windows root directory.
Outcome
After reviewing the current rules, the most specific match is rule 1. Since rule 1 has a
security level of Disallowed, the program is disallowed.
Creating an Effective Software Restriction Policy
Characteristics of an effective software

restriction policy are:
z An effective software restriction policy can be
deployed only after careful planning and
testing.
z The policy is best deployed closest to the
end user.
z The software restriction policy should be
created in a separate GPO.
Figure 183: Creating an Effective Software Restriction Policy
Figure 184 provides a summary of the software restrictions available.

Software Restriction Policy Choices Comments
Local security or GPO If many computer systems require the same settings, use a
GPO.If security is to apply locally due to bandwidth issues
or Active Directory is not used, use the Local Security
Policy MMC.
Machine or user Policy applied to the computer system will apply to any user
that uses the computer.Policy applied to the user can follow
the user wherever they log in on the network.
Defining a default security level If you are lucky enough to know all software that your users
can use, set the default security policy to Disallowed, and
create a policy rule for each software application.
If users can install any software that they want, leave the
default security level to Unrestricted.
Using additional rules Using additional rules requires that you know the
components of your software environment.
Policy options Options are DLL checking, all software files, all users and
all users except local administrators.
Using group filtering Groups can be used to filter how network-based policy is
applied to sites, domains, and OUs.
Linking to a site, domain, or OU OUs, sites, and domains can be linked to an existing
software policy GPO.
Figure 184: Software Restrictions Available
Deployment Summary
After the software restriction policy has been enabled, it has to be monitored and
analyzed for problems; otherwise, inconsistencies may crop up.
Always create a separate GPO for a software restriction policy. Do not add policy
restrictions to the default domain GPO; it would then apply to every computer and user
account in the domain.
If linking is to be used, be aware that a linked policy is read every time the computer
restarts or the user logs in. Link only to root OUs, and preferably, do not link at all
unless you are aware of both the logical and physical design of your Active Directory
hierarchy.
Be aware of the potential for conflicts when using both Group Policy settings and software
restriction policy.
Multiple User or Machine Policies

When two or more policies are created and applicable, the settings are merged and the
GPO with the highest precedence enforces the following values:
Default security level
Designated file types
Skip administrators
DLL checking
Merging Machine and User Policy

A software restriction policy can be set for user scope and machine scope. When merging
user and machine scope, the following processing occurs:
The most restrictive default security level is chosen.
The list of designated file types in the machine policy, if present, is used. If no
machine settings are available, the list of designated file types in the user
policy if present are used.
The Skip Administrators value is always chosen from the machine policy.
If DLL checking is enabled in either policy, then it is enabled.
If there are conflicts between defined user and machine software restriction policies, the
settings are merged, first applying the machine policy setting and then the user settings.
Software restriction policies and the how, why, where, and when
of deployment was discussed in detail.
Knowledge
Check
Section Review
1. What are the three main components of a software restriction policy?
2. Which clients can take advantage of a software restriction policy?
3. What are the four enforcement options that can be deployed?
4. A software restriction policy can apply to __________ and __________.
5. The two conditional modes of operation used by a software restriction policy are:
6. What are the four additional rules used to identify software components?
7. List the order of precedence of software rules:

____ Hash
____ Certificate
____ Internet zone
____ Default
____ Path
ABC Acronyms
DLL dynamic-link library

DSS Digital Signature Standard
GUID globally unique identifier
MD5 Message Digest 5
MIT Massachusetts Institute of Technology
NIST National Institute of Standards and Technology
NSA National Security Agency
RSA Rivest, Shamir, and Adelman
SHA-1 secure hash algorithm 1
Troubleshooting Group Policy
Section Topics
Group Policy Infrastructure Enabling Group Policy
Logging: the userenv.log File
FRS Replication
Tips for Troubleshooting Group
Client-Side Extensions
Policy
GPO Structure
Custom Views of
Group Policy Deployment Order Administration Templates
Using Command-Line Tools Using the Event Logs
Analyzing Policy Deployment Using Gpmonitor
Using the Windows XP Help Why Is My Policy Still Not
and Support Center Working?
N Knowledge
Guide
W E
Section Objectives
S

Describe Active Directory and Sysvol components of Group Policy
Explain the function of client-side extensions
Explain how to use command-line and GUI tools for effective troubleshooting
Describe how versioning works
Section Overview
The internal architecture of the Group Policy components and their operation are detailed
in this section. Numerous command-line and GUI tools are available for troubleshooting
Group Policy and these are discussed in detail.
Group Policy Infrastructure
Group Policy is based on the following

components:
z The Sysvol folder
z GPT Group Policy container
z GPC Group Policy container
z The PDC emulator
Figure 185: Group Policy Infrastructure
Within each Active Directory domain are a number of components that all domain
controllers and computers that are members of the domain use to deploy Group Policy
settings.
Finding out where an unwelcome Group Policy setting came from can be hard if you are
not aware of the tools and utilities available for Windows 2000 and Windows XP
computer systems.
In addition to the tools, it is prudent to have handy, the physical and logical network
diagrams of your Active Network infrastructure.
Many Group Policy troubleshooting tools can be found in the support tools that are
bundled on the Windows 2000, Windows 2003, and Windows XP operating system CD in
the Support\Tools folder. In addition, the Windows 2003 Resource Kit has additional
tools for Group Policy troubleshooting.
The Sysvol Folder
Figure 186: The Sysvol Folder
The Sysvol folder is located on the NTFS file system on every Active Directory domain
controller in %System Root%\ Sysvol.
Administrative templates, security settings, applied scripts, and details on MSI packages
that are to be installed are found here.
Sysvol Details Notes
The domain where the user account is located also contains the
Group Policy settings of the authenticating user. These settings
are stored in a system folder called Sysvol. Most likely there will
be several Sysvol folders because each domain controller that
hosts a domain has a local Sysvol, which in turn is linked to all
other Sysvol folders throughout the domain using the FRS.
The FRS monitors and updates the changes to Group Policy,
startup and shutdown scripts, logon and logoff scripts. If your
Active Directory is made up of multiple sites (subnets), the
location of your Sysvol folders will be separated by WAN links.
If you have multiple sites, and each site contains multiple domain
controllers, your network map can get very complicated and
much more dependent on the replication process.
The PDC Emulator
Figure 187: The PDC Emulator
One domain controller per domain has a domain controller assigned the role of a PDC
(primary domain controller) emulator.
The PDC emulator role is automatically assigned to the first domain controller in an
Active Directory domain and there is, and can be, only one domain controller that has this
role per domain.
When Group Policy settings are first created or modified using the Active Directory Users
and Computers console, the current live Group Policy settings are pulled from the
domain controller in the domain that is the PDC emulator. Many tools and utilities can be
used to find out which domain controller is currently the PDC emulator.
One of the handiest methods to try is using the support tool Netdom with the following
syntax at the command prompt:
c\> netdom query fsmo
Another handy tool is Addiag.exe, (another support tool) which Notes

can tell you if all the domain controllers in the domain know who
the PDC emulator currently is.
Note
The command-line tool Dcgpofix.exe can be used to completely

restore the Default Domain Policy and Default Domain Controllers
OU Policy to their original state. This tool works only in Windows
2003 domains.
FRS Replication
Figure 188: FRS Replication for Sysvol
The process of replication is usually thought to dictate the movement of all changes in
Active Directory.
However the changes to Group Policy are replicated to the other domain controllers within
the domain using the FRS (File Replication Service). The process goes like this:
1. When changes are made to Group Policy, the PDC emulator is located and the
settings are read from its Sysvol folder into cache.
2. After changes have been made, the Group Policy settings are saved back to the
Sysvol folder on the PDC emulator.
3. These changes signal the FRS to replicate the changes.
4. At the allotted replication time (up to 15 minutes), the FRS replicates the
settings to the other domain controllers throughout the domain.
Client-Side Extensions
While the components of each GPO are stored in Active Directory, the actual client
(Windows XP, Windows 2000, or Windows 2003) does the processing of each linked GPO
using what is called client-side extension or, in English, a collection of local DLLs that
have one specific job task: to process all enabled GPOs found on the server at logon or at
a specific processing time.
The available policy settings are grouped into specific categories including administrative
templates, security, folder redirection, wireless, IPSec, EFS, and software installation.
After the client determines what GPOs are to be applied, each GPO is passed to the client
side extensions, a collection of DLLs that actually do the DLL processing.
Registry Client-Side Extensions

Registry client side extensions deal with the Group Policy settings contained in the
Administrative Templates. Take note that some settings are hidden by default; these
hidden settings are defined as true policies. The settings that are available and loaded by
default are called preferences and listed in Figure 189.
GUID Group Policy Component
25537BA6-77A8-11D2-9B6C 0000F8080861 Folder redirection
3610EDA5-77EF-11D2-8DC5-00C04FA31A66 Disk quota
42B5FAAE-6536-11D2-AE5A-0000F87571E3 Scripts
827D319E-6EAC-11D2-A4EA-00C04F79F83A Security
B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A EFS recovery
C6DC5466-785A-11D2-84D0-00C04FB169F7 Application management
A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B Internet Explorer settings
35378EAC-683F-11D2-A89A-00C04FBBCFA2 Registry settings
e437bc1c-aa7d-11d2-a382-00c04f991e27 IP security
Figure 189: Default Client Side Extension
GPO Structure
A GPO (Group Policy object ) is constructed from

two parts:
z The first is the GPT (Group Policy template)
z The second part is called the GPC (Group
Policy container)
Figure 190: GPO Structure
The details of every created GPO are stored in Active Directory in the GPC. The GPC
contains the version number of each GPO, its current status, and the installed components.
The GPT stores the files created by the GPO in the Sysvol folder on the PDC emulator for
each domain.
A portion of the GPO is stored in Active Directory and can be viewed using the Active
Directory Users and Computers console. The GPC Active Directory object is created from
an Active Directory class called the groupPolicyContainer.
Each created GPO creates a separate GPC and corresponding component in Active
Directory. And every GPO created must be stored in a domain. However, every GPO can
also be linked to other objects, specifically OUs and sites, that may be in the same domain
where the GPO was created or linked to objects outside its domain.
The Group Policy Container
Figure 191: The Group Policy Container
The GPC is used by users and computer accounts within the Active Directory database for
processing the GPO policies to be applied.
Each GPO is assigned a unique 128-bit GUID. So you can reference the GUID string in
the Policies folder with the GUID string on each GPO.
ADSI Edit can be used to find out the friendly name (English) of the GPO from its
assigned GUID by opening the CN=Policies folder, referencing the properties of the
selected GPO, and selecting the DisplayName property as shown in Figure 191.
The Group Policy Template

The GPT is used to store computer and user scripts, the GPO template files, and the
registry.pol files.
The GPT and GPC are linked through the same GUID that is assigned to the GPO.
In order for group processing to be properly processed by a computer and user, the
contents of both the GPC and the GPT must be synchronized. The following table
(Figure 192) lists the details of the essential Group Policy components and their
location in Active Directory.
Active Directory Location Contents Active Directory Container
Active Directory Binary and string information GPC
Sysvol\Policies\GUID\User or Policy settings for user and GPT
Machine\registry.pol computer
Sysvol\Policies\GUID\User or Policy related files and data GPT
Machine\Custom
Folder\Custom File(s)
Figure 192: Group Policy Components
GPO Versioning
Following are some guidelines about GPO

versioning:
z Every time a change is made to a GPO, the
version number in an INI file called gpt.ini is
incremented.
z The incrementation of the computer and user
GPO is not what you may expect.
z For computer changes to a GPO, the version
number increments by 1.
z A user change to a GPO increments by 65536.
Figure 193: GPO Versioning
The number displayed on the properties of a GPO is not a version number; it is instead a
revision number listing the number of changes to the user or computer sections.
The version number of the GPO is calculated based on the total user and computer
changes, and it is applied to both the GPC and the GPT.
If the version numbers of the GPT and GPC for a particular GPO are not the same, the
GPO will not be processed until the version numbers match or are in sync. For the GPO to
be in sync, the version numbers of both the GPT and the GPC must be identical on each
domain controller in the domain.
Note
The Replication Monitor can be used to display the sync status of all GPOs using the
context menu option Show Group Policy Object Status.
Notes Processing Details

After the GPOs have been created, the respective site, domain, or
OUs link to the created GPOs using the Active Directory
attribute found on each container object that references the GUID
of each site, domain, or OU.
After a policy has been linked to a site, domain, or OU, the DN of
the policy is entered into the gPLink property on the selected
site, domain, or OU.
A Windows client then uses the GetGPOList API to discover
which GPOs should be processed on the client. The computer
name and IP address are also used to determine the site that the
user is in, determining which GPOs are to be associated with the
computer system. In addition, the domain and OU location of the
computer system is also used to build the master list of which
GPOs to apply.
Next, the version information and other GPO options (disabled,
no override, block policy inheritance) are read to determine
what, if any, processing will take place. The default is that if the
current GPO settings have already been deployed, no
reprocessing will be done unless mandated. The needed client-
side extension DLLs then swing into processing mode and apply
their associated GPO settings.
Group Policy Deployment Order
Figure 194: Local Group Policy
Group Policy is deployed in the following order:

1. If present, local Group Policy settings are deployed first.
2. If present, network settings are deployed next.
3. The network order is site, domain, and organizational units.
4. Groups can be used to filter the deployment of Group Policy.
Notes Local Computer System

Remember that any local Group Policy settings deployed using
the local policy editor gpedit.msc or through the Local Security
Policy console in the Administrative Tool menu will be
deployed first, before any other network-based policy settings.
The local Group Policy choices are pulled from the local
Windows\System32\Group Policy folder.
It may be helpful to remember that the local registry hives, the
logged in user profile (NTUSER.DAT), and the secedit.sdb
security database are where all Group Policy settings are
eventually deployed to, even if the settings are deployed from the
site, domain, or OU.
Using the Local Security Policy console, in the details pane, the
columns Effective Settings and Local Settings indicate where
the setting was applied.
If you, as a client, have read access to the local GPO, the settings
apply to you even if you are the local administrator. Setting the
read access to no access results in the local GPO not being
applied to the local administrator.
Site GPOs
A GPO created within a site will apply to all users and computers
in the site. A site is one or multiple subnets joined together under
an Active Directory site name.
Any Group Policy settings deployed at the Active Directory site
level that are different from any previously applied local Group
Policy will overwrite the previously applied local settings.
For example, if a local setting has been enabled that removes the
Settings tab from the properties of the Display icon in Control
Panel, it will be deployed first.
If the very same setting at the site level GPO is set to Not
Configured, the end result at this point of the deployment cycle
is that the Setting tab is now available.
Domain GPOs Notes
A GPO created at the domain properties is applied to all users

and computers in the domain, and to all users and computers in
all child OUs and the users containers.
If a conflict occurs with a previously applied local or site setting,
the domain settings will overwrite the local and site settings.
Organizational Unit
The OU settings are deployed next, potentially overwriting the
local, site, and domain settings if a conflict occurs with a
previously applied setting.
Child OU
If you use multiple OUs in your Active Directory design, any
Group Policy settings deployed at the top of an OU tree will
flow down through the OU child domains, similar to the
enforcement of permissions on a NTFS partition.
If you have multiple Group Policy settings applied from multiple
sources, you will have an effective Group Policy built from the
multiple GPOs applied to your network.
Note
For Group Policy to operate properly, the three key components

that must be working are Active Directory, DNS, and the FRS.
Each Active Directory client uses the FQDN to attach to the
domain controller and read the GPO.
Group Policy Processing

Group Policy processing follows this sequence:
1. The Active Directory network must be operating properly and the Remote
Procedure Call System and the Multiple Universal Naming Convention
Services must be started.
2. First, the computer policy is applied in synchronized mode.
3. Next, startup computer scripts are applied synchronously, which is the default
mode of application. Each script is fully deployed before the next script is
applied.
4. After CTRL+ALT+DEL is pressed and the user login is validated and
completed, the user profile is loaded.
5. User Group Policy is now applied synchronously by default in the following
order: Windows NT 4.0 system policies, local policy, site, domain, OU, child
OU etc.
6. Logon scripts are run asynchronously.
7. The Windows Explorer shell is started.
Note
In order for Group Policy processing to work, ICMP must be available.
Using Command-Line Tools

Using Gpresult
Figure 195: Using Gpresult
Microsoft supplies several command-line tools that can be used to troubleshoot Group
Policy deployment and the health of the existing GPOs:
Windows 2000 command-line tools are the most limiting.
Windows XP and Windows 2003 have better GUI and command-line tools.
The Resource Kit has additional troubleshooting tools.
The gpresult.exe File

Gpresult is a handy tool for analyzing many facets of Group Policy. Gpresult provides the
following RSoP details:
Operating system version: Windows XP, Windows 2000, or 2003; Server or
Workstation
Build number and current service pack applied
If Terminal Services is installed and the mode of installation
User name and account location in Active Directory
Domain name and type (Windows 2000, Windows 2003, or Windows NT 4.0)
Site name
The type of user profile in effect, local or roaming, and location of profile
Security group membership list
Security privileges of the user executing Gpresult
Computer name and account location in Active Directory (if applicable).
Last time policy was applied and the domain controller from which Group
Policy was pulled
A complete list of applied Group Policy objects and details
Applied registry settings and path locations
Redirected folders
Assigned and published software applications (MSI)
Disk quota information if applicable
IP Security settings
Logon and logoff, startup and shutdown scripts
The syntax for gpresult.exe is shown in Figure 196.
Figure 196: Gpresult Syntax
Helpful Hint
The output from gpresult using the super-verbose option will overload the command
prompt window. Use the redirect (>) option and direct the output to a file.
C:\gpresult /Z > gpsettings.txt
Gpresult can be downloaded from http://www.microsoft.com/windows2000/techinfo/

reskit/tools/existing/gpresult-o.asp
Using Gpotool
Figure 197: Using Gpotool
When your Active Directory domains have more than one domain controller, (and every
domain should have more than one domain controller) the command-line tool Gpotool can
be used to ensure that the contents of all the linked Sysvol folders in the domain contain
valid and up-to-date GPOs.
Version mismatches between the GPT stored in the Sysvol folder and the GPC in Active
Directory can be checked using Gpotool.
If errors occur, check the System and Directory Services event logs on the listed domain
controller showing the problem.
If you wanted to verify if a GPO called Corporate Desktop Settings on a certain domain
called BigDaddy is in sync, type the following at a command prompt window:
Gpotool/gpo:Corporate Desktop Settings/dc:bigdaddy
When using the Gpotool, you can also check these Group Policy components:
Group Policy object consistency: Gpotool checks the GUID of each GPO and
all Sysvol data.
Group Policy object replication: Gpotool checks the times and instances of
when replication has occurred.
Friendly-name searching: Your GPOs can be searched by the given English
name of each GPO.
Selective search: You can specify which domain controllers Gpotool
will query.
Multiple domains: You can check policies in Notes

different domains.
Verbose mode: This mode displays a validation list of
each working GPO and a detailed error report for each
GPO policy that is found to be damaged.
Note
The gpotool.exe can be downloaded from

http://www.microsoft.com/windows2000/techinfo/reskit/tools/
existing/gpotool-o.asp
Using Gpupdate
Figure 198: Using Gpupdate
For Windows 2000 computer systems, a command-line utility secedit.exe was used to
refresh Group Policy settings without rebooting.
For Windows XP and Windows 2003, a new command-line utility, gpupdate.exe is used.
The Gpupdate Syntax

To use Gpudate, exit to a command prompt and execute Gpupdate. The
following syntax can be used:
/target: Computer | User
Use this switch to specify that only the user or computer policy settings are
immediately updated. By default, both user and computer policy settings are
updated.
Use the following switch to reapply all policy settings (by default, only the
policy settings that have been changed are applied):
/force
Use this switch to set the number of seconds to wait for the processing of
policy to finish:
/wait:value
Use this switch to log off from the selected computer after the policy settings
have been updated:
/logoff
Use this switch to restart your computer after the Notes

policy settings have been updated.
/boot
Some policy settings can only process at startup, for
example, computer-based policy settings usually
require a reboot.
Note
The default update cycle for refreshing Group Policy is 90 minutes

on domain members and 5 minutes on domain controllers.
Using ReplMon
Figure 199: GPO Status
Using Replmon, a wide variety of replication details can be gathered.

In addition, the replication status of current GPOs per domain can be monitored.
The Replmon Process

To check the current GPO replication status, follow these steps:
1. Open the Replmon tool from the Support Tools menu.
2. Right-click Add Monitored Server and enter the FQDN of the server.
3. On the View menu, select Options.
4. Next, select the Status Logging tab and under Monitored Servers check GPO
Policy Objects.
5. Click OK. Now, select the Update Manually button and enter 1 for the refresh
monitor cycle.
After 1 minute, and for every minute thereafter, an updated status Notes
on the current GPOs is displayed as shown in Figure 199.
On Windows 2000 and Windows 2003 Server CDs, in the

Support\Tools folder, the support tools can be installed by
clicking the RKSTOOLS.MSI package.
Additional details on the replication status can be found by right-clicking the server icon
and from the context menu, selecting Show Group Policy Replication.
Any differences between the GPC and the GPT will result in different version numbers:
the Version column corresponds to the GPC status, and the SysVol Version represents the
GPT.
Additional DCs can be added to the view of Replmon for comparison purposes.
Figure 200: GPO Version Numbers
Analyzing Policy Deployment

Using RSoP
Figure 201: Using RSoP
With so many Group Policy options available, it can be tedious to determine exactly
which effective Group Policy settings have been applied.
The RSoP (Resultant Set of Policy) tool is installed by adding the MMC snap-in to a new
or existing custom console. The tool can be executed in either of the following two modes:
Planning mode: Running RSoP in logging mode lists all the GPOs that are
currently applied to a computer or user account. Choosing the computer and
user, the tool then calculates the Group Policy settings that are currently
applied and also details which GPO setting is the effective setting.
Logging mode: Running RSop in planning mode allows you to determine the
effect that changing the current Group Policy configuration will have on the
computer or user account. Selecting the user and/or computer, you then can
select a scenario to have the RSoP tool analyze. Moving the user to a different
OU, or adding a security group, the tool then calculates the effective Group
Policy settings that would be applied, based on the selected scenario.
Notes Loading the RSoP Console

Follow these steps to load the RSoP console:
1. From the Start menu, open the Run dialog box, enter
mmc, and click OK.
2. From the File menu, choose Add/Remove Snap-in
and click Add. Scroll down the list and select
Resultant Set of Policy.
The wizard will then allow you to select the user and computer
that you wish to analyze in logging mode. Alternatively, you can
select planning mode and select the user, computer, security
level, and desired placement in the forest.
Using the Windows XP Help and Support Center
Figure 202: Using the Windows XP Help and Support Center
Enabling Group Policy Logging: the userenv.log File
Figure 203: Enabling Group Policy Logging: the userenv.log File
Complete details on the users logon process can be enabled through the local registry
A log file called userenv.log is populated with a detailed verbose log of the login process
To turn on debug logging, modify the registry on the computer on which the logging
occurs.
Use Regedit and add the following registry value at the following location:
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\
CurrentVersion\Winlogon
Value: UserEnvDebugLevel
Value Type: REG_DWORD
The following values can be entered for UserEnvDebugLevel:
NONE 0x00000000
NORMAL 0x00000001
VERBOSE 0x00000002
LOGFILE 0x00010000
DEBUGGER 0x00020000
The above values can be combined; for example you can combine VERBOSE
0x00000002 and LOGFILE 0x00010000 to get 0x00010002. This turns on both
LOGFILE and VERBOSE.
Notes
The default value is NORMAL|LOGFILE (0x00010001). To

disable logging, select NONE (where the value is 0X00000000).
On the next reboot and login, the userenv.log file is written to

%SystemRoot%\Debug\UserMode.
Two essential components to check in the userenv.log file are:
Verify in the userenv.log file that the DN of the
computer or user is being recognized. If Windows
2000 or Windows XP cannot determine the DN, it
will not be able to properly parse Active Directory to
determine which GPOs to apply to the user or
computer.
Determine if any GPOs are being skipped because the
user does not have the proper permissions on the GPO
(the user should have read and apply Group Policy
permissions).
Tips for Troubleshooting Group Policy

1. Use gpresult /z in super-verbose mode to find out which domain controller
was used to pull the GPO from. From the output, search for the line:
Group Policy was applied from servername.domain.com
This will tell you what domain controller served the request from your client
and applied the GPO.
2. Check the policy files: navigate to the Sysvol folder on the domain controller
found in step 1 and verify that the policy is actually stored in the correct Sysvol
location. GPOs are stored with GUIDs, not the user-friendly name that you
created. Using Active Directory Users and Computers to find out the GUID of
the policy from the properties of the GPO. Then compare with the GUID
listing in Sysvol.
3. Remember that Active Directory Users and Computers will be showing you
the Sysvol copies of the PDC emulator.
4. Make sure that your Group Policy files are healthy, using Gpotool. Running
this utility, point to the domain controller discovered in step1; the results
should come back with a status of OK for each GPO found. The following line
in the results should be something like the listing below for each GPO:
Policy {41B2E340-016D-11D2-945F-00C04FB984F9}
Policy OK
5. Check replication details.Using Regedit, navigate to
HKLM\System\CurrentControlSet\Services\
NTDS \Diagnostics\Replication Events. The value will be 0; change it to 1 to
start populating the basic information on replication events in your event
viewer Directory Services log. Then open up the Active Directory Sites and
Services MMC, select each connection object, and from the context menu
choose Replicate Now. Then check the event log for further details.
6. Check the FRS operation. Using the command-line utility Ntfrsutil and check
for any errors pertaining to your domain controller using the following syntax:
ntfrsutil.exe ds servername
Use command-line tools to refresh your policies when needed. Windows 2000
uses the Secedit tool to refresh machine and user policies. Windows XP and
above use Gpupdate to perform Group Policy refresh operations.
7. Monitor group policies deployed over slow WAN links. The order of settings
that are applied is not equal for every component.
Registry and security settings are always applied. Notes

Administrative templates are always applied.
Application deployment, scripts, folder
redirection, and disk quotas are not applied by
default over slow links.
Note
The last policy that runs always wins. Policies are cumulative, and
the last one that runs will win. Remember that policies are
refreshed, by default, every 5 minutes for domain controllers and
every 90 minutes for workstations. These intervals are config-
urable via Group Policy itself.
Custom Views of Administration Templates
Figure 204: Filtering Applied Policy Settings
Both the Computer and User Administrative Templates have a hidden feature that allows
you to quickly see what is configured.
Other areas of the GPO Template cannot be shown in this method.
This feature is available for Windows 2000, Windows 2003, and Windows XP Profes-
sional clients.
Windows 2003 and Windows XP have the excellent Resultant Set of Policy and Help and
Support Center tools to show what Group Policy settings have been enabled. However, the
filtering feature shown in Figure 204 can be useful when using Active Directory Users and
Computers and Active Directory Sites and Services to troubleshoot current policy settings.
Enabling the Administrative Tools Filter Notes
Follow these steps to enable the administrative tools filter:

1. Invoke this filter by right-clicking either the user
or the computer Administrative Templates
folder.
2. From the context menu, select View and then
Filtering.
3. Check Only show configured policy settings.
Using the Event Logs
Figure 205: Setting Verbose Event Logging
All GPO events are logged to the Application event log in a minimum amount of detail. To
get verbose results for troubleshooting, the registry must be edited. Once edited, the
Application log will provide additional details about which GPO is being applied.
Verbose GPO Logging

To enable verbose logging of GPOs, a registry key must be added to the following
location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\Diagnostics
Under the Diagnostics subkey, add a REG_DWORD value named
RunDiagnosticsLoggingGlobal and assign it a value of 1.
After a reboot, the diagnostic logging will be enabled. Every major step in processing
GPOs triggers an event log entry.
Many Group Policy error codes have not been well documented. However, a handy
Microsoft Excel spreadsheet listing the Group Policy error codes can be downloaded
from: www.microsoft.com/windows2000/techinfo/reskit/ErrorandEventMessages/
default.asp
Using Gpmonitor
Figure 206: Using Gpmonitor
Notes Why Is My Policy Still Not Working?

If your policy is still not working, check the following:
The GPO is not linked to the site, domain, or OU
where the user is a member.
Settings were not enabled in the correct GPO.
Computer settings overwrite user settings.
Replication has not yet occurred through Active
Directory.
Group Policy refresh has not occurred at the
client PC.
DNS has a problem.
The client or the client computer was moved into
a different site, domain, or OU.
Security group filtering has been enabled.
This section discussed how to troubleshoot all aspects of Group

Policy deployment for Windows 2000, Windows 2003, and
Windows XP clients. It also included many tips and tricks to
quickly solve problems when they arise.
Knowledge
Check
Section Review
1. What are the two parts that create a GPO?
2. What INI file stores the version number?
3. A computer change to a GPO increments by _____.
4. A user change to a GPO increments by ______.
5. Which support tool shows the current version numbers?
6. Which local security tool shows both local and effective settings applied?
7. Which syntax used with Gpresult shows the most detail possible?
8. Which tool shows the status and health of each GPO?
ABC Acronyms
ADSI Active Directory Service Interfaces

API application programming interface
CD compact disc
CSE client-side extension
DLL dynamic-link library
DN distinguished name
FQDN fully qualified domain name
FRS File Replication Service
GPC Group Policy container
GPT Group Policy template
ICMP Internet Control Message Protocol
INI initialization
IPSec IP Security
MSI Microsoft Windows Installer
PDC primary domain controller
RSOP Resultant Set of Policy
Using the Group Policy
Management Console
Section Topics
What Is the GPMC?
Installing the GPMC
Backing Up and Restoring GPOs
Importing GPOs
Copying GPOs
Searching for Existing GPOs
Integration of RSoP Functionality
WMI Filters
Using the Group Policy Management Console
N Knowledge
Guide
W E
Section Objectives
S

Describe the needs filled by the GPMC
Install the GPMC successfully and understand installation requirements
Configure the GPMC user interface
Back up GPOs
Restore and import GPOs
Copy GPOs, both intra-domain and inter-domain
Understand migration tables
Search for GPOs using various criteria
Use the GPMC to accomplish RSoP analyses
View and print GPO settings and RSOP data
Create and apply a WMI filter
Section Overview
This section covers a downloadable console from Microsoft that was released after
Windows 2003 Server went to market. The Group Policy Management Console is
intended as a one-stop shop for Group Policy administration, and may be the most
useful tool a Group Policy administrator can have.
What Is the GPMC?

The GPMC (Group Policy Management Console) is a centralized administration console
where you can perform most common Group Policy operations without having to bounce
around between separate windows in separate Active Directory utilities. The GPMC also
offers several capabilities that you cannot find elsewhere.
The Problem
Think about the various actions you occasionally need to perform with Group Policy and
the tools that you need to carry them out:
Action Tool
Create or modify site-based policy Active Directory Sites and Services
Create or modify domain-based policy Active Directory Users and Computers
Create or modify OU-based policy Active Directory Users and Computers
Create or modify local policy Local Group Policy
Predict policy effects Resultant Set of Policy
Report policy effects Resultant Set of Policy
Print GPO settings Resultant Set of Policy
Perform security group filtering DACL editor for the specific GPO
Delegate Group Policy links Delegation of Control wizard
Figure 207: Actions and Tools Used with Group Policy
Consider that you must generally navigate several menus, submenus, property sheets, and
dialog boxes in any of the above tools and you begin to appreciate that working with
Group Policy is something of a chore.
The GPMC Solution

The Group Policy Management Console, released in April 2003 as a separate download
(not part of the Windows 2003 Server distribution), lets you perform all the activities in
the Figure 207 from a single console, gpmc.msc. (Although the GPMC does not actually
have GPO editing capability, it does have the ability to launch the Group Policy console
from its user interface.)
Additionally, think about the things you might like to do with Group Policy but cannot
perform easily with Windows 2000 or Windows 2003 Server as they ship:
Back up policy objects (and restore them if you are unlucky)
Import settings from one policy object as the basis for creating a new object
View all the links for a specific policy object
Script certain administrative activities
The GPMC allows you to perform these functions as well.
What the GPMC Is Not

The GPMC does not replace the Group Policy console (which, in Windows 2003 Server,
now goes by the name Group Policy Object Editor). In fact, when you are working in the
GPMC and you select a setting to change, GPMC invokes the Group Policy console for
that purpose. For example, choose a GPO from the Group Policy Objects node, right-
click, and select Edit.
Note also that the GPMC is not intended to be a replacement for Active Directory Users
and Computers. You still need Active Directory Users and Computers for chores such as
creating, editing, and deleting users, groups, OUs, and computers.
Finally, the GPMC is not a perfect solution for all networks because it does not run on
Windows 2000 Professional or Windows 2000 Server (or any earlier version of Windows).
Installing the GPMC
Figure 208: Installing the GPMC
The Group Policy Management Console is a free download from Microsoft. As of this
writing, you can obtain the installation package at the following URL:
www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=F39E9D60-
7E41-4947-82F5-3330F37ADFEB
Alternatively, you may open www.microsoft.com and search for GPMC to get there.
Installation Requirements
The GPMC requires either Windows 2003 Server (member server or domain controller) or
Windows XP Professional to run.
GPMC does not run on a Windows 2000 Professional or Windows 2000 Server
machine of any kind, even though GPMC can administer a Windows 2000
network.
GPMC does not run on any 64-bit version of Windows.
Other features of GPMC include:
Licensing: You do not need a separate software license to run GPMC, and at
this writing, you can run it on as many computers as you like, so long as you
have at least one Windows 2003 Server license. It is not clear what your
permitted uses are if your network has only Windows 2000 Servers.
Domain member: The computer on which you run GPMC must be a member
of a domain in the forest that you wish to administer, or a domain that has a
trust with that forest. That is, you cannot run GPMC on a computer that
belongs to a workgroup.
Domain controllers: In order to support the signed-and-encrypted LDAP
communications that GPMC uses, GPMC requires that any Windows 2000
Server domain controllers be running SP2 or higher, and that any Windows
2000 Server domain controllers in a separate forest to which you connect be
running SP3 or higher.
Notes for XP: If you want to run the console on Windows XP, you need to
fulfill additional requirements:
- You must have SP1.
- You must have the Microsoft .NET Framework.
- GPMC requires hotfix Q326469 (which updates gpedit.dll to version
5.1.2600.1186), but the GPMC installer will offer to install this for you if
you do not already have it.
Running the Console

After installation, you can run the console by any of the following methods:
Choose Run from the Start menu, and type gpmc.msc.
Choose Administrative Tools from the Start menu (or All Programs), and
select Group Policy Management.
Run mmc.exe and create your own custom console, adding the Group Policy
Management snap-in.
Go to the Group Policy tab in Active Directory Users and Computers or
Active Directory Sites and Services, and click Open.
That last bullet is worthy of comment. The old method of getting to the Group Policy
editor via the Group Policy tab of Active Directory Users and Computers (and, for site
policies, Active Directory Sites and Services) is now disabled. You will see the message in
the Figure 209.
Microsoft apparently figures that you would have no reason to use the old interface now
that you have the new one.
Figure 209: Group Policy Tab of Active Directory Users and Computers
Configuring the Console
Figure 210: Configuring the Console
The first time you open the GPMC after installing it, you will see a top-level node
corresponding to the forest that your computer account resides in. Under the forest node
will appear the following subnodes:
Domains
Sites
Group Policy Results
Group Policy Modeling (Windows 2003 Server only)
Right-click the Domains node, choose Show Domains, and select the domain or domains
that you wish to view by checking the appropriate boxes. You can show multiple domains
in the console pane at the same time, although their DNS structure will not affect their
placement in the console.
You can connect to a different forest, if desired, by right-clicking the top node (Group
Policy Management) and choosing Add Forest. However, the forest you add must be
trusted by the forest you are already in.
As usual with MMCs, the Action menu mirrors the context menu for each node. The
contents of the details pane change depending on what is selected in the console pane. And
you can expand nodes by clicking the plus (+) sign next to them (whether anything is there
or not).
Version 1.0 Syndrome

Version 1.0 of anything is likely to have its problems, and the GPMC is no exception.
Following is an explanation of a couple of glitches that people have experienced while
using this new console. Check the release notes for your version of the GPMC for
additional details.
No Access to Active Directory Tools

The GPMC may lock out access to Active Directory tools from other computers. Assume
that Administrator Bob is logged on to a PC and running the GPMC. Administrator Ray,
on a separate workstation, trying to connect to the network with one of the adminpak
administration tools (such as Active Directory Users and Computers), will see his system
hang for several minutes. As soon as Bob closes the GPMC, Ray can gain access.
There is no easy solution to this situation. Mitigation steps include limiting the number of
persons with administrative access to the domain and having them keep each other
informed when they plan to perform policy-related maintenance.
Inconsistent Permissions between Active Directory and Sysvol

The GPMC may complain about inconsistent permissions between Active Directory and
Sysvol.
Figure 211: Inconsistent Permissions Message
This problem crops up when you are administering a Windows 2000 Server that is acting
as a domain controller. Due to a bug in the dcpromo code, the Sysvol component of
Group Policy objects is flagged to inherit permissions, triggering the warning message.
Microsoft advises that if you see this, you should let the GPMC fix the problem, at which
time it will remove the inheritance flag and you will not see the error message again.
Backing Up and Restoring GPOs

Backing Up
Domain A
Live GPO
Backup
Restore
Copy
(creates new GPO)
Folder
Domain B
Import
Live GPO
Figure 212: Backing Up
Considering the importance of Group Policy objects, having backups is highly desirable.
Yes, the GPOs do exist in Active Directory and the Sysvol shares, so if you have multiple
domain controllers, you already have redundancy. What you do not have, without the
GPMC, is a convenient way of restoring individual GPOs and importing GPO settings into
other GPOs, both of which are capabilities that are enabled by the GPMC backup facility.
Backing up refers to the process of copying the contents of a live GPO into any
specified folder location on the PC or network where you have write
permissions (see Figure 212).
You can back up multiple policy objects to the same folder.
You can back up multiple versions of the same policy object to the same folder.
Backed-up GPOs may be restored or imported.
The GPMC includes a user interface for managing backed-up policy objects
(right-click the Group Policy Objects node and choose Manage Backups).
Backing Up a GPO on the Console
Figure 213: Backing Up a GPO on the Console
The procedure for backing up a GPO in the console is straightforward:

1. Navigate to the domain of interest in the console pane.
2. Expand the Group Policy Objects node.
3. Right-click the policy object you want to back up, and choose Back Up.
4. Select a target folder to which you have write access. You can browse to this
location, and you can also create a new folder if necessary.
5. Create a description for the backup. This description will appear later when
you are managing your backups from within the GPMC.
6. Click the Back Up button.
7. When the backup is complete, click OK.
Notes Alternative Backup Method
Figure 214: Alternative Backup Method
An alternative method is available if you wish to back up all

the GPOs in a given domain. In place of step 3, in the
procedure given previously, right-click the Group Policy
Objects node itself, and choose Back Up All. The rest of the
procedure is the same.
Managing the Backups Notes
You can manage the backups that you have created by right-
clicking the Group Policy Objects node and choosing Manage
Backups. In the dialog box that then appears, you will see the
following information:
Backup location
List of backed up GPOs, including domain, name,
timestamp, description, and GPO ID
A checkbox to Show only the latest version of
each GPO
A Restore button, which restores the selected GPO to
its original domain
A Delete button
A View Settings button, which generates an HTML
report listing the settings in the selected GPO (a
convenient feature)
A Close button
Restoring
Domain A
Backup
Live GPO
Restore
Copy
(creates new GPO)
Folder
Domain B
Import
Live GPO
Figure 215: Restoring
When you are restoring backed up files, keep in mind the following:
Restoring refers to the process of putting a backed-up GPO back into its
original location (that is, domain) with all its original settings intact (including
security settings).
Even if you are restoring a deleted GPO, it will have the same GUID it had
originally.
You cannot restore a GPO to a domain other than the one from which it was
backed up.
You would generally restore a GPO when you have deleted it and want it back, or when
you have modified it (either its contents or its ACL) and want to return it to some prior
condition; in these aspects, restoring a GPO is much the same as restoring a file or folder.
Procedure for Restoring GPOs

The procedure for restoring a GPO varies depending on whether the GPO exists or has
been deleted.
If the GPO still exists, and you just want to return it to some prior state, right-
click the GPO in the Group Policy Objects container and choose Restore
from Backup. Follow the wizard.
- To restore a GPO with this procedure, you must have the following permis-
sions on it: edit settings, delete, and modify security.
If the GPO has been deleted, right-click the Group Policy Objects container
itself, choose Manage Backups, find the backed-up GPO, select it, and click
the Restore button.
- You must have the right to create GPOs to restore with this procedure.
Caveats of Restoring
If you restore a deleted GPO, the links it had are not automatically restored.
You have to restore them manually.
If you restore a deleted GPO that includes software deployment settings, and
those settings included the option to uninstall when the application falls
outside the scope of management, users may see those assigned or published
applications uninstall and then reinstall, after the restoration of the GPO. This
is because Windows thinks the applications are new because they get a new
deployment object GUID after the restore (even though the GUID of the actual
GPO remains the same as it was).
If you rename a domain, you cannot restore a GPO that was backed up before
the rename operation.
Notes Importing GPOs
Domain A
Backup
Live GPO
Restore
Copy
(creates new GPO)
Folder
Domain B
Live GPO
Import
Figure 216: Importing GPOs
Importing a GPO transfers the settings in a backed-up GPO to an

existing and active GPO. Importing never creates a new GPO.
There is no export command for GPOs. Backing up a GPO is
the functional equivalent of exporting it.
Reasons for Importing GPOs Notes
Why would you want to import a GPO rather than simply

restore it?
You do not want to create a new GPO, but instead,
you want to augment the settings contained in an
existing GPO without changing any of the security
settings (ACEs) of that existing GPO.
You want to migrate a GPO from one domain to
another, but you do not have connectivity and trust
relationships between the domains. To elaborate:
- If you did have connectivity with trusts, you
would simply perform a copy operation (drag-
and-drop) instead of a back-up-and-restore cycle.
- The restore operation always restores a GPO to
the domain from which it was backed up, so it
cannot be used to migrate a GPO from one domain
to another.
Procedure for Importing GPOs

To import a backed-up GPO, right-click an existing GPO (in
the Group Policy Objects node of the console) and choose
Import. Then specify the backed-up GPO whose settings you
would like to import. You also have the opportunity to specify
a migration table.
Copying GPOs
Domain A
Backup
Live GPO
Restore
Copy
(creates new GPO)
Folder
Domain B
Import
Live GPO
Figure 217: Copying GPOs
You can use the GPMC to copy and paste GPOs, either via the context menu of the GPO
or by dragging and dropping. How is this different from importing GPOs?
A copy operation always creates a new GPO at the destination location; an
import operation never does.
A copy operation always starts with an active GPO; an import operation starts
with a backed-up GPO.
Requirements
In order to copy a GPO from one location to another, the source and target locations must
have physical connectivity as well as a trust relationship. If you are copying a GPO from
one domain to another within the same forest, then this is usually not a problem. However,
if you are copying a GPO from one domain to another in a different forest, then you must
either have a forest trust in place (Windows 2003 Server only), or you must perform a
backup-and-import operation rather than a copy operation.
Migration Tables
Active Directory was not created with the idea in mind that administrators would be
copying a lot of objects between domains. Rather, the idea is that if a domain needs
something, it should generally find it within the domain.
Therefore, it is no great surprise that copying a GPO from one domain to another is not
normally a simple matter of dragging-and-dropping. You might get away with that if all
you have in a particular GPO is Administrative Templates settings, that is, registry-based
policies, but if your GPO goes further afield than that, you could have some migration
conflicts to consider.
SID Conflicts
For one thing, GPOs tend to contain domain-specific SIDs. For example, user rights (part
of the Security Settings node of a Group Policy Object) typically include references to
domain groups, such as Backup Operators.
The SID for the Backup Operators group in Domain A is not the same as the SID for the
Backup Operators group in Domain B. This is a problem, so you would need, in this case,
the ability to map the migration of SIDs. There may also be explicit, user-specific access
controls set forth in the origin domain; these, too, would need to map over to different
SIDs in the destination domain.
The types of policies that could include SID information, and therefore possibly need
remapping, include the following:
File system permissions (NTFS)
Folder redirection
Software settings (specifically, ACLs on software deployment objects)
User rights assignments
UNC Conflicts
Another potential migration problem arises from the fact that some GPOs contain settings
that reference specific network paths, using UNC notation. For example, an assigned
application may specify a distribution point within the domain; in fact, it is likely to do so.
When that policy moves to a new domain, the distribution point may no longer be
available due to permissions issues. Even if it is available, there may be performance
problems associated with the cross-domain traffic, and administration problems as well
(Your domains distribution point is too slow, Is not, Is too).
The types of policies that could include UNC information, and therefore possibly need
remapping, include the following:
Folder redirection
Software settings
Logon, logoff, startup, and shutdown scripts
Building a Migration Table

The solution to this problem is to build a migration table for security principals and UNC
paths that need to be translated from one domain to the other. This migration table will
have the old setting on the left and the new setting on the right.
After that is done, you can specify the migration table during the GPO copy operation, and
it will act much like a global search-and-replace facility for all occurrences of the
specified SIDs and paths.
You build migration tables with the mtedit.exe program found in the GPMC folder under
%programfiles% on the system where you installed the GPMC. You can either run the
tool directly, or invoke it from within the GPMC by right-clicking the Domains node and
choosing Open Migration Table Editor. (You can also right-click the Group Policy
Objects node to get to this menu choice.) The XML data files associated with mtedit.exe
have the extension .migtable.
Sample Migration Table
Figure 218: Sample Migration Table
The sample migration table included by Microsoft with the GPMC appears in Figure 218
and illustrates many of the possible combinations of format for each of the three columns.
Note especially the <Map by Relative name> entry in the Destination Name column.
This is shorthand for replace the original domain name with the destination domain
name, but keep everything else the same. That is, testdomain1\Group02 would become
testdomain2\Group02.
Note also the <Same As Source> entry in the Destination Name column. This is
shorthand for dont change a thing, in fact, this entry doesnt even need to be here except
perhaps to clarify that we know this entry doesnt need to change.
Note
You can use migration tables when copying and when importing.
Searching for Existing GPOs
Figure 219: Searching for Existing GPOs
In a large Active Directory environment, you may find it convenient to be able to search
for GPOs by several different criteria. The GPMC has a fairly advanced search facility to
satisfy this need. You can activate the search feature on a per-domain or per-forest basis,
as follows:
Right-click a specific domain and choose Search.
Right-click a specific forest and choose Search.
You can specify a specific condition to search by, or, to create a more complex and precise
search, you can create a list of conditions. For example, in Figure 219, the first search
criterion (already defined) is User Configuration Contains Software Installation, and
the next search criterion (about to be added with the click of the Add button) is GPO
Links Exist in corphq.i-sw.com.
When creating a search criterion, specify a search item, a condition, and a value.
The Search Item specifies what kind of item you are looking for; for example,
a GPO name, a user configuration setting, or a GPO GUID.
The Condition is really more correctly referred to as an operator and relates
the search item to the value. Example conditions are Contains, Exist in, Has
This Explicit Permission, Is, Is Not, and so on. The available conditions
depend on what you choose for your search item.
The Value is the syntactical object of the operator, specifying the precise
details of what your search is to find. It might be a specific domain or OU
name, a particular kind of policy setting, or a certain security permission.
Here is a list of choices you can select from the Search Item drop-down list:
GPO Name: You can specify the exact name, or a substring.
GPO Link: You can specify links that exist, or do not exist, in specific
domains or sites. This setting is useful for finding GPOs with cross-domain
links, as well as GPOs with no links at all.
Security Group: You can specify to search for GPOs where security groups
have or do not have apply, edit, and read permissions, either explicitly or
effectively.
Linked WMI Filter: You specify the name of the filter.
User Configuration: You can specify to search for GPOs where the User
Configuration half of the policy object contains, or does not contain, Folder
Redirection, IE Branding, Registry, Scripts, or Software Installation
settings.
Computer Configuration: You can specify to search for GPOs where the
Computer Configuration half of the policy object contains, or does not
contain, EFS Recovery, IP Security, Disk Quota, QoS Packet Scheduler,
Registry, Scripts, Security, Software Installation, or Wireless Group Policy
settings.
GPO GUID: You specify the globally unique identifier for the GPO.
Notes
! Caution
The search facility has a known bug in that it can return false
positives when settings in the following categories are made, then
later removed:
EFS
Folder Redirection
IE Maintenance
Security Settings
Software Installation
Therefore, do not regard this search feature as an

authoritative list.
Integration of RSoP Functionality Notes
Group Policy can be deployed via the RSoP snap-in to the

MMC (rsop.msc). RSoP is helpful when planning and
testing Group Policy, and when troubleshooting it, by tracing
the application of policy links for a specified user and a
specified computer and identifying effective settings and
winning policy objects.
In the spirit of making the Group Policy Management Console a
one-stop shop for Group Policy management, Microsoft has
integrated RSoP functionality into the GPMC (although they did
change the nomenclature when doing so).
Specifically, this integration means that:
RSoP logging mode in the RSoP console becomes
Group Policy Results in the GPMC.
RSoP planning mode in the RSoP console becomes
Group Policy Modeling in the GPMC.
Especially when one considers the HTML reporting capabilities
of the GPMC, it is hard to see why anybody would continue to
use rsop.msc if they have access to GPMC. In fact, Microsoft
recommends that you abandon the older utility.
Group Policy Results
Figure 220: Group Policy Results
Group Policy Results in the GPMC corresponds to RSoP logging mode and presents
real information reflecting actual policy applications. It is available in Active Directory
forests running either Windows 2000 Server or Windows 2003 Server.
To instigate a modeling run, right-click the Group Policy Results node in the console
pane of the GPMC window and choose Group Policy Results Wizard.
The wizard prompts you to make the following choices:
Specify which computer you want to process: the local computer or a different
computer that you specify.
Display policy settings for the user object only, not the computer object. (This
is a checkbox.)
Specify which user account you want to process: the current logged-on user or
a different user that you specify. (You are limited to users who have logged on
to your PC and whose accounts you have read access for.)
When the run is complete, the details pane of the GPMC fills up Notes
with three tabs:
Summary: An HTML report of the GPO list, security
group memberships, and WMI filters
Settings: An HTML report of the policy settings that
would be applied in the scenario
Events: A pull of policy-related events from the event
log of the target computer and a useful
troubleshooting resource
These three tabs correlate with a new subnode in the console
pane under the Group Policy Results node. These subnodes will
continue to accumulate with every new run of the wizard. By
right-clicking the subnode corresponding to a specific modeling
session, you can:
Save the results to disk
Run the query again
Run a new query with this one as a template
Choose Advanced View to invoke the RSoP console
and view precedence information that does not appear
in the HTML Settings report. (The latter reports only
the winning GPO.)
Group Policy Modeling

Group Policy Modeling in the GPMC corresponds to RSoP planning mode, meaning that
it permits you to perform a simulation before actually applying policies. It requires that at
least one domain controller in the Active Directory forest is running Windows 2003
Server; if that is not the case, the node does not appear in the GPMC console.
To instigate a modeling run, you could right-click the Group Policy Objects node in the
console pane of the GPMC window and choose Group Policy Modeling Wizard.
However, you will probably find it more convenient to right-click the specific domain or
OU node, which preloads the wizard with the appropriate data.
The various selections that you can make in a modeling run include the following:
User container
Computer container
Slow network simulation (yes/no)
Loopback mode (no/merge/replace)
Site name
User security groups
Computer security groups
WMI filters for users
WMI filters for computers
When the run is complete, the details pane of the GPMC fills up with three tabs:
Summary: An HTML report of the GPO list, security group memberships, and
WMI filters
Settings: An HTML report of the policy settings that would be applied in the
scenario
Query: A listing of the selections you made when running the wizard
These three tabs correlate with a new subnode in the console pane under the Group Policy
Modeling node. These subnodes continue to accumulate with every new run of the wizard.
By right-clicking the subnode corresponding to a specific modeling session, you can:
Save the results to disk.
Run the query again.
Run a new query with this one as a template.
Choose Advanced View to invoke the RSoP console and view precedence
information that does not appear in the HTML Settings report.
Report GPO Settings and RSoP Data

Group Policy does not have good reporting capabilities about software setup. For GPO
reporting, the Group Policy MMC console offers only the bare-bones Export List feature,
which is wholly inadequate for serious use. Additionally, users have to have GPO write
permissions to even open the console and gain this rudimentary reporting capability.
Redirecting command-line output from tools like Gpresult is barely better. The hue and
cry that arose from system administrators all over the world about the limited reporting
capabilities of Group Policy is one reason the GPMC exists.
Note
Even though they are not always complete, the GPMC finally provides the ability to
generate HTML-format reports that you can save and print.
Any user with read access to a given GPO can open GPMC and view or report its settings,
which is a boon to IT support personnel and OU administrators.
You even have a modicum of control over what appears on the report, via the Show and
Hide links at each section header. You can also click Show All at the top of the report to
fully expand all sections.
The GPMC allows you to report on the settings contained in any
particular GPO.
- Right-click on an entry under Group Policy Objects, and choose Save
Report to create an HTML file with the settings (see Figure 221). The
report contains the full contents of the Settings tab, plus information from
the Scope, Details, and Delegation tabs.
- Right-click anywhere in the Settings tab and choose Print to print the
report as it appears on the screen.
The GPMC also allows you to report on the results of an RSoP session (that is,
Group Policy Results or Group Policy Modeling).
- Right-click a saved session under Group Policy Results or Group Policy
Modeling and choose Save Report to create an HTML file with the
settings.
- Right-click anywhere in the Settings tab and choose Print to print the
report as it appears on the screen.
Figure 221: Creating an HTML File for Reporting
Here are a few tips and problems for GPMC reporting:

To view the HTML reports that the GPMC saves, you must use Internet
Explorer 6 or Netscape 7.
To use the show/hide capability, you must use Internet Explorer 6.
The reported data for IPSec and Wireless settings is incomplete.
The reported data for Internet Explorer Security Zones and Privacy settings is
incomplete (customized Java settings do not appear).
The reported data for Internet Explorer Content Ratings is incomplete
(settings details do not appear).
WMI Filters
Although we have the ability to filter the application of Group Policy objects by
modifying the ACLs for the policy links (security group filtering), it might be nice to
control policy application based on specific attributes of an individual client computer.
That is what WMI filtering is all about.
WMI stands for Windows Management Instrumentation, and it provides a mechanism to
glean various details of a computers configuration through a programmatic interface. In
many respects, WMI is similar to SNMP.
WMI runs on Windows 2000, Windows XP, and Windows 2003 platforms. Figure 222
shows some of the data that WMI manages, in this case on a Windows 2000 Professional
machine. You can access this data by choosing Properties for the WMI Control object in
the Computer Management console.
Figure 222: WMI Control Properties
A WMI filter is a collection of one or more queries (really conditions) written in WQL. A
query might specify, for example, that a computer be running at least a Pentium III
processor, or have a minimum OS version number. When you build a WMI filter and
apply it to a GPO, the GPO will apply only if the queries in the filter are all satisfied.
So, for example, you could create a GPO that would apply only to computers with at least
a Pentium III CPU. That sort of capability could come in handy, for example, when you
are thinking of deploying a processor-intensive application.
Restrictions
WMI filtering has a raft of conditions associated with it, making it unsuitable at present
for deployment in mixed-mode networks. Here is what you should know:
Only Windows XP Professional clients support WMI filters. Windows 2000
Professional clients (and earlier) will ignore them and will always apply
policies just as if the WMI filter did not exist.
Only Windows 2003 Server networks and Windows 2000 Server networks that
have been prepped for Windows 2003 Server via the adprep /domainprep
command on the Windows 2003 Server CD support WMI filters.
WMI filters are domain-local in scope. That is, you cannot link a WMI filter to
a GPO in a different domain.
Any given GPO may have only one associated WMI filter. (That is not too
much of a restriction when you consider that a filter may have a long list of
queries contained within it.)
If these restrictions do not rule out WMI filters for your network environment, then you
need to know how to implement them. Doing so comprises two steps:
Creating the filter
Linking the filter to a GPO
Creating WMI Filters

Create a new WMI filter by right-clicking the WMI Filters node in the GPMC and
choosing New. Name the filter, provide a description, and create your queries.
WQL is similar to SQL, so if you are familiar with SQL, all you need are the specifics for the
WMI data classes.
One good way to get familiar with the WMI classes is to use the graphical tool
wbemtest.exe, which you can run from a command prompt (see Figure 223).
Figure 223: Using the wbemtest.exe Tool
Note the namespace, which you need to specify via the Open Namespace button if it is
anything other than root\cimv2.
If you click the Enum Classes button, then choose Recursive and click OK, you will see
a dialog box like the one shown in Figure 224.
Figure 224: Using the wbemtest.exe Tool (cont.)
Then, if you double-click the item and choose the Instances button, you can see the
instances of objects of that class on the machine. For example, you would learn that the
Name property of the Win32_BIOS class on this machine is PhoenixBIOS 4.0 Release
6.0.3. Another way to express this is:
Win32_BIOS.Name = "PhoenixBIOS 4.0 Release 6.0.3"
You can continue to explore the wbemtest.exe utility until you become familiar with the
wide range of classes and properties available. Then, read the examples of WQL provided
in the GPMC help system. You may also get some good information on WMI scripting at
the following URL:
www.microsoft.com/technet/treeview/default.asp?url=/technet/scriptcenter/scrguide/
sas_wmi_overview.asp
Linking a WMI Filter to a GPO Notes
After you have built a WMI filter, you need to link it to a GPO
for it to become useful. In the GPMC, this is as simple as
dragging the WMI filter object onto the GPO of interest. Other
ways to accomplish the same thing include:
Pulling down the WMI filtering menu on a GPO
Scope tab in the GPMC.
Right-clicking GPOs that use this WMI filter on the
General tab of the filter in the GPMC.

You will use the GPMC as your cockpit for Group Policy
administration. After you gain familiarity with it, you will
perform fewer policy-related operations in Active Directory
Users and Computers, Active Directory Sites and Services, and
Resultant Set of Policy. GPMC lets you back up, restore, import,
and copy GPOs, and even specify how migration of domain-
specific settings should be performed. You can locate a given
GPO based on a wide variety of attributes. You can do almost
everything you can do in the Resultant Set of Policy console and
you can finally print some rudimentary reports. Finally, the
GPMC provides a window into the future with WMI filtering,
which may eventually give you fine-grained control over whether
specific policies should apply on clients with particular attributes.
Knowledge
Check
Section Review
1. What operating systems can support the GPMC?
2. What type of software license do you need to use the GPMC in your network?
3. Name the four major nodes that appear under the forest icon in the console.
4. What is the difference between an import operation and a restore operation?
5. What two types of data do migration tables handle?
6. Is the GPO search facility of the GPMC completely accurate?
7. What is the new name for RSoP planning mode in GPMC?
8. How do you print a report listing all the settings in a GPO?
9. What is the tool that you can use to learn about WMI classes and properties?
ABC Acronyms
ACE access control entry

CPU central processing unit
ID identification or identifier
IE Microsoft Internet Explorer
LDAP Lightweight Directory Access Protocol
OS operating system
QoS Quality of Service
RSoP Resultant Set of Policy
SNMP Simple Network Management Protocol
SP1 Service Pack 1
SP2 Service Pack 2
SP3 Service Pack 3
SQL Structured Query Language

WMI Windows Management Instrumentation
WQL WMI Query Language

M6345C 002

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

M6345C 002

Diunggah oleh

Hak Cipta:

Format Tersedia

Deploying Group Policy

for Windows 2000, 2003,

9000 Regency Parkway

Certification and Career Paths

Deploying Group Policy for Windows 2000, 2003, and XP Clients v

After completing this course, you will be able to:

vi Deploying Group Policy for Windows 2000, 2003, and XP Clients

Font Item or task Example

ALL CAPS Key names CTRL+ALT+DELETE (Press the

Courier New bold Code or commands not in text <h1>Global Knowledge</h1>

3 Testing and Piloting Group Policy

4 Deploying Security Templates

5 Network Security Using Group Policy

6 Explorer Shell Group Policy

7 Group Policy and Remote Access

8 Assigning and Publishing Software Packages

12 Using the Group Policy Management Console

After completing this section, you will be able to:

The Philosophy of IntelliMirror

Think of Group Policy and Active Directory as the tactical

Active Directory Framework

Figure 1: Active Directory Framework

The main components of Active Directory are:

Create a new domain by promoting a Windows 2000 or 2003 Server computer to be a

Active Directory Users and Computers

Figure 2: Creating an OU in the Active Directory Users and Computers Console

Slow WAN link

Software Packages and the Windows Installer

Figure 4: Software Settings Node of Group Policy

Figure 5: Folder Redirection

Folders that can be redirected include: Notes

Offline Files and Folders

Roaming User Profiles

Figure 6: Roaming User Profiles

Distributed File Shares

Server East Server West

Remote Installation Services

You cannot use RIS to upgrade an operating system.

Notes Versions of Group Policy

Windows 2000 Interface

Figure 8: Windows 2000 Interface

Windows XP and Windows 2003 Interface

Figure 9: Windows XP and Windows 2003 Interface

Figure 10: Compatibility Information

Another user interface is the Group Policy Management Console.

Which Clients and Servers Can Deploy Notes

Group Policy Architecture

The Secedit Database

Local Group Policy

Figure 11: Local Group Policy

Every Windows 2000 Professional or Windows XP Professional computer has a local

Network Group Policy (Domain, OU, Site)

Group Policy Deployment

Figure 12: No Override

Block Policy Inheritance

Figure 13: Block Policy Inheritance

Linking Group Policy

Disabling Group Policy

A container can be a domain, OU, or site.

Using Multiple Policies

Filtering with Security Groups

Figure 14: Filtering with Security Groups

Delegation of Group Policy