Tài liệu Module 5: Designing Active Directory to Support Group Policy docx

Contents
Overview 1
Identifying Business Needs 2
Applying Group Policy in Active Directory 4
Planning for Group Policy 10
Lab A: Designing Group Policy and a
Supporting Active Directory Structure 21
Review 32

Module 5: Designing
Active Directory to
Support Group Policy


Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Windows, Windows NT, Active Directory, BackOffice, PowerPoint, Visual Basic, and
Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the
U.S.A. and/or other countries.

The names of companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or event, unless
otherwise noted.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Project Lead: Andy Sweet (S&T OnSite)
Instructional Designers: Andy Sweet (S&T OnSite), Ravi Acharya (NIIT), Sid Benavente,
Richard Rose, Kathleen Norton
Instructional Design Consultants: Paul Howard, Susan Greenberg
Program Managers: Lorrin Smith-Bates (Volt), Megan Camp (Independent Contractor)
Technical Contributors: Angie Fultz, Lyle Curry, Brian Komar (3947018 Manitoba, Inc.), Jim
Clark (Infotec Commercial Systems), Bill Wade (Excell Data Corporation), David Stern, Steve
Tate, Greg Bulette (Independent Contractor), Kathleen Cole (S&T OnSite)
Graphic Artist: Kirsten Larson (S&T OnSite)
Editing Manager: Lynette Skinner
Editor: Jeffrey Gilbert (Wasser)
Copy Editor: Patti Neff (S&T Consulting)
Online Program Manager: Debbi Conger
Online Publications Manager: Arlo Emerson (Aditi)
Online Support: Eric Brandt (S&T Consulting)
Multimedia Development: Kelly Renner (Entex)
Testing Leads: Sid Benavente, Keith Cotton

Testing Developer: Greg Stemp (S&T OnSite)
Compact Disc and Lab Testing: Testing Testing 123
Production Support: Ed Casper (S&T Consulting)
Manufacturing Manager: Rick Terek (S&T OnSite)
Manufacturing Support: Laura King (S&T OnSite)
Lead Product Manager, Development Services: Bo Galford
Lead Product Managers: Dean Murray, Ken Rosen
Group Product Manager: Robert Stewart

Module 5: Designing Active Directory to Support Group Policy iii


Instructor Notes
This module begins by providing techniques for identifying the Group Policy
needs of an organization. The module then offers strategies for applying Group
Policy at different levels to Active Directory
™
objects. Finally, the module
provides guidelines for creating and documenting a Group Policy plan for an
organization, and creating the necessary structure to support the Group Policy.
At the end of this module, students will be able to:
!
Identify administrative needs that can be addressed through Group Policies.
!
Determine the appropriate site, domain, or organizational unit (OU) level at
which to apply a Group Policy.
!
Design a Group Policy plan based on the administrative needs of an
organization and design an Active Directory structure to support the plan.

Lab A, Designing Group Policy and a Supporting Active Directory Structure,
begins with hands-on exercises in which the student will be given a Group
Policy plan for an organization. The students will run a script that creates an
OU structure for the lab, and then implement the Group Policy plan. Finally, the
students will log on as various users and use the GPResults.exe tool to test the
Group Policies that were implemented in the previous exercise.
In the planning exercises, students are provided with criteria, including an
existing OU design, to support an administrative plan. Students will work in
pairs to create a Group Policy design for the OU structure. They will then
redesign the OU structure to better facilitate Group Policy design. Student
volunteers will present and defend their designs to the class. As you lead the
discussion, reinforce best practices and map design decisions back to business
needs.
Materials and Preparation
This section provides you with the required materials and preparation tasks that
are needed to teach this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft
®
PowerPoint
®
file 1561b_03.ppt
!
Visio 2000

Preparation Tasks
To prepare for this module, you should:
!

Read all of the materials for this module.
!
Complete the lab.
!
Read the following technical white paper located on the Trainer Materials
compact disc:
• Introduction to Windows 2000 Group Policy

Presentation:
45 Minutes

Lab:
105 Minutes
iv Module 5: Designing Active Directory to Support Group Policy


Instructor Setup for a Lab
This section provides setup instructions that are required to prepare the
instructor computer or classroom configuration for a lab.
Lab A: Designing Group Policy and a Supporting Active
Directory Structure
Ensure that the GPResults.exe tool runs from the command prompt of all
student computers and the instructor computer.
Ensure that Visio 2000 Enterprise Edition is installed on the instructor
computer and all student computers and that the Active Directory template is
operational. Also ensure that the \\London\Solutions\Lab5
directory is shared
and accessible from the student computers.
Exercise 1 is a hands-on exercise where the students will follow procedures to
implement the Group Policy plan set forth in the exercise scenario. The

instructions are step-by-step but the students must first select the Group Policy
object (GPO) they wish to modify after they decide which GPOs require which
policy settings.
In Exercise 2 the students will log on to their computers as various users to
ensure that the settings from the previous exercise have been properly
implemented. The students may also use the GPResults tool from the command
prompt to verify that the proper settings have been made. When the students
test for the Training1 user, they will not be able to test whether the settings tab
is available. This is because the Control Panel is disabled and therefore all of
the individual control panels are disabled.
Exercise 3 is a planning exercise where the students are given a scenario and a
set of Group Policy requirements. The scenario includes an existing OU
structure that the students are required to use when planning GPOs. The
students should not create any extra OUs but should use filtering, block
inheritance, and loopback to meet the requirements. Through this exercise the
students will see that creating new OUs will make GPO creation easier.
Exercise 4 is also a planning exercise where the students will add OUs to the
existing OU design to better facilitate GPO design. The students will then plan
OUs to minimize Group Policy filtering.
Module 5: Designing Active Directory to Support Group Policy v


Module Strategy
Use the following strategy to present this module:
!
Identifying Business Needs
Begin the module by emphasizing the importance of determining levels of
management required by different areas in an organization prior to
designing the Active Directory structure. Describe the tasks in an
organization that can be performed by using Group Policy.

!
Applying Group Policy in Active Directory
Explain the advantages and disadvantages of applying GPOs to site,
domain, and OU containers. Discuss the general guidelines to consider
when applying Group Policy to Active Directory.
!
Planning for Group Policy
Explain that a Group Policy plan must be based on the administrative needs
of an organization, and then describe how to design an Active Directory
structure to support the plan. Explain the importance of filtering,
inheritance, and blocking of GPOs. Discuss how Group Policy performance
can be optimized. Finally, explain guidelines for creating, testing and
documenting a Group Policy plan for an organization.

Customization Information
This section identifies the lab setup requirements for a module and the
configuration changes that occur on student computers during the labs. This
information is provided to assist you in replicating or customizing Microsoft
Official Curriculum (MOC) courseware.
The lab in this module requires students to use Visio 2000 to document their
designs. Visio 2000 is demonstrated in course 1561B, module 3, Designing
Active Directory to Delegate Administrative Authority. If Visio has not been
previously demonstrated to students, refer to module 3 for instructions on
demonstrating Visio 2000.
The lab in this module includes a script to be run at the beginning and end of
the lab, creating and returning the computer to the default configuration for the
course. As a result, there are no lab setup requirements or configuration changes
that affect replication or customization.

Module 5: Designing Active Directory to Support Group Policy 1

Overview
!
Identifying Business Needs
!
Applying Group Policy in Active Directory
!
Planning for Group Policy


Group Policy is used in Microsoft
®
Windows
®
2000 Active Directory
™
to
administer many aspects of client computer configuration, from installing
software to managing the user environment. The Group Policy object (GPO) is
used to apply Group Policy to users and computers in the Active Directory
directory service at the site, domain, and organizational unit (OU) level.
How an organization will use Group Policy depends on the level of client
management desired. The plan for using Group Policy will impact the creation
of lower-level OUs in the design of the Active Directory structure.
At the end of this module you will be able to:
!
Identify administrative needs that can be managed through Group Policy.
!
Determine the appropriate site, domain, or OU level at which to apply a

Group Policy.
!
Design a Group Policy plan based on the administrative needs of an
organization and design an Active Directory structure to support the plan.

Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about using Group Policy
within Active Directory and
designing Active Directory to
support Group Policy.
2 Module 5: Designing Active Directory to Support Group Policy


Identifying Business Needs
!
Group Policy Is Applied:
#
Frequently in Highly Managed IT Networks
#
Infrequently in Minimally Managed IT Networks
!
Group Policy Is Used to:
#
Enforce Security
#

Create Common Configurations
#
Simplify Computer Build Process
#
Limit Distribution of Applications


When determining how Group Policy will be implemented in an organization,
begin by identifying which areas of the organization require a high level of
management and which areas require less management. Next, determine the
ways in which GPOs will be used to fulfill management needs.
Level of Management
The extent of Group Policy use to manage client computers is determined by
the level of service the Information Technology (IT) department will provide to
the user. Because network administration can be delegated, you can use
different levels of IT management in different areas of the organization. The
two types of management environments are as follows:
!
Highly Managed. In highly managed environments the administrators of the
domain or OU will use Group Policy to configure user and computer
environments. Such Group Policy settings might include software
distribution and maintenance, desktop security, offline folders management,
and logon, logoff, startup, and shutdown scripts.
!
Minimally Managed. Environments that do not require a great deal of
management will, to varying degrees, perform their own troubleshooting,
install their own software, and may even replace their own hardware.
Administrators in this type of environment use Group Policy sparingly.

Slide Objective

To identify the levels of
management required in an
organization and how Group
Policy supports these levels.
Lead-in
Group Policy will be used
more frequently in
organizations that highly
manage computer and user
environments.
Module 5: Designing Active Directory to Support Group Policy 3


Group Policy Objectives
To determine the business reasons for using Group Policy, you need to know
the functions Group Policy can perform. You can use Group Policy to perform
the following tasks:
!
Enforce common security standards. GPOs can be used to set consistent
security parameters for all computers of a particular class. For example, it is
recommended that domain controllers all have common security parameters
restricting who can log on to the computer locally, and who can gain access
to the domain controller remotely. Security policy is most commonly
applied to domains, domain controllers, and servers.
!
Enforce computer and user configuration. Groups of computers and users
will likely require common configurations. For example, while some users
may log on at several workstations as a part of their job functions, they may
still require a common configuration at each workstation.
!

Simplify the process for configuring computers. Group Policy can distribute
applications, which can simplify computer configuration. Group Policy
allows the administrator to send, or push a set of applications to a
workstation or user with minimum effort. This process of distributing
applications is especially useful in highly managed environments where the
IT department is responsible for distributing and managing all applications
in the enterprise.
!
Limit distribution of applications. Group Policy can simplify enforcing the
legal compliance of computers and users by allowing the network
administrator to restrict the distribution of applications for which there is a
limited number of licenses.

4 Module 5: Designing Active Directory to Support Group Policy


$
$$
$

Applying Group Policy in Active Directory
!
Applying Group Policy at the Site Level
!
Applying Group Policy at the Domain Level
!
Applying Group Policy at the OU Level
!
Design Guidelines

GPOs can be created for sites, domains, and OUs. Applying GPOs at any of
these three levels has advantages and disadvantages that can affect the scope of
the GPO and how inheritance is passed between containers. For example,
applying a GPO at the site or domain level affects more objects than applying a
GPO an OU level. However, applying GPOs at the site or domain level offers
less control over each individual object than does applying GPOs at the OU
level.
Slide Objective
To identify the levels at
which Group Policy can be
applied.
Lead-in
The site, domain, or OU
level at which you apply
Group Policy will affect
which sets of users and
computers are affected.
Module 5: Designing Active Directory to Support Group Policy 5


Applying Group Policy at the Site Level
!
Single Site GPOs
Affect All Domains
Within the Site
!
Site Level GPOs Can
Cross Domain
Boundaries

Site
Domains


GPOs can be applied on a site, or a collection of subnets, on a network. GPOs
applied at the site level are enforced on all computers and users physically
located at that site. A policy set at the site level will not affect mobile users
from that site if they access the network from another site.
Apply a GPO at the site level only when the policy setting is needed at that
specific site. Site-specific GPOs can be used to manage traffic over slow
network links. For example, to prevent software installation over slow network
links, you may decide that you only want packages to be delivered within a
single site. You would then publish the software using a GPO for the site so that
installations would only occur to the computers within the site.
Single Site
In an environment containing a single site and a single domain, applying a GPO
at the site level has the same effect as applying a GPO at the domain level. To
simplify administration in this example, apply GPOs only at the domain level
and not at the site level. In a single site with multiple domains, all domains will
be affected by the site GPO.
Multiple Sites
Group Policy applied at the site level in a multiple-site structure can cross
domain boundaries and be applied to computers and users in multiple domains.
Therefore, you must be a member of the Enterprise Admins group to apply
Group Policy at the site level.
Slide Objective
To show how applying
Group Policy at the site level
affects users and
computers.

Lead-in
Applying a GPO at the site
level will affect users and
computers within the
physical definition of that
site.
6 Module 5: Designing Active Directory to Support Group Policy


Applying Group Policy at the Domain Level
!
In Single Domain, GPOs
Affect Entire Domain and
Cannot Be Delegated
!
In Multiple Domains, Domain
Level GPOs Do Not Affect
Other Domains Unless Linked
Parent
Domain
Child
Domain
Single Domain Multiple Domains


GPOs set at the domain level are applied to all computers and users within the
domain.
Single Domain
You can create all of your GPOs at the domain level to eliminate the potential
conflicts that can occur when GPOs also exist at the site or OU level. However,

if you apply GPOs at the domain level only, you will not be able to delegate
administration to other department administrators within the organization. All
GPOs will need to be administrated at the domain level.
Multiple Domains
GPOs created in a parent domain cannot create conflicts with GPOs in a child
domain. Domains define an administrative boundary in Active Directory and
are administered independently of each other. As a result, Group Policy created
at the domain level only affects users and computers in that particular domain.
You can apply Group Policy settings from one domain to users and computers
in a second domain by linking the existing GPO to the second domain.
However, this method creates additional network traffic. To avoid creating
additional traffic, you can create a new GPO within the second domain that
contains the same Group Policy settings as the GPO in the first domain. GPOs
cannot be copied.
Slide Objective
To show how applying
Group Policy at the domain
level affects users and
computers.
Lead-in
Applying Group Policy at the
domain level will affect all
users and computers within
that domain.
Module 5: Designing Active Directory to Support Group Policy 7


Group Policy Settings Commonly Set at the Domain
Level
Group Policy can be set at either the OU level or at the domain level. However,

even if Group Policy is set at the OU level, there are some Group Policy
settings that are usually set at the domain level.
The following table describes the Group Policy typically set at the domain
level.
Target Level for
the GPO
Objective of the
Group Policy

Group Policy Settings

Domains
Security Password, Account, Kerberos Policy,
Public Key Trust List
Domain Controllers
Security User Rights, File/Registry Discretionary
Access Control Lists (DACLs),
Audit/Event log, Local Policies
Domain Controllers
Applications Assign or Publish Administrative Tools
Domain
Controllers
User Environment Disable standard user settings


Domain Controller settings would normally be applied in an OU
containing all of the domain controllers.

Note
8 Module 5: Designing Active Directory to Support Group Policy

Applying Group Policy at the OU Level
!
At OU Level, GPOs
Are Inherited from
Parent to Child OU
Same Group Policy
Inherited from GPO of
Parent OU
GPO Linked to
Parent OUs
OU Specifically Created
for Group Policy
OU
OU
OU
OU
OU
OU
OU
OU


Applying Group Policy at the OU level allows you to tightly control the
application of Group Policy to specific users and computers. For example, you
can create OUs to group together subsets of users with common needs, and then
apply a GPO appropriate to their needs to the OU. Creating GPOs for OUs
gives the network administrator precise control over applying Group Policy
settings, because it eliminates the need to filter Group Policy settings. However,

it also means that there are more GPOs to manage. Also, conflicts between
GPOs can occur because OUs can be nested, and because Group Policy is
inherited from parent OU to child OU. Careful planning of OUs and GPOs can
reduce conflicts caused by inheritance.
When you delegate, or decentralize, OU administration, you also delegate the
administration of GPOs that are assigned to the OU. If you want to retain
centralized administration of GPOs, do not delegate administrative control of
OUs.
Group Policy Commonly Set at the OU Level
You set Group Policy at the OU level for the computers and users contained
within a specific OU. The following table shows the typical areas and
objectives for Group Policy settings at the OU level.

Target Level
Objective of the
Group Policy

Group Policy Settings

Workstations Security User Rights, File/Registry DACLs (access
control lists), Audit/Event log, Local Settings
Workstations Applications Mandatory Core applications
Users Security EFS policy
Users Applications Publish optional applications and components
Users User Environment Logon Scripts, Folder redirection, Desktop
lockdown.
Slide Objective
To show how applying
Group Policy at the OU level
affects users and

computers.
Lead-in
Applying Group Policy at the
OU level allows the architect
to have control over which
users and computers are
affected by the GPO.
Module 5: Designing Active Directory to Support Group Policy 9


Design Guidelines
!
Create As Few GPOs As Possible
!
Map Each GPO to a Single Site, Domain, or OU
Container
!
Avoid Linking GPOs Between Domains
!
Minimize the Number of GPOs Applied to a User or
Computer


The following are general guidelines for applying Group Policy to Active
Directory objects to support the Group Policy needs of your organization.
!
Create a domain or OU design that will allow the fewest GPOs possible.
The more GPOs you have associated with any object, the more network
traffic will be generated and the longer it will take for users to log on to the
network. Create lower-level OUs based on the need for GPOs.

!
Map each GPO to only one site, domain, or OU container. This strategy will
reduce confusion over inheritance rules and aid in troubleshooting conflict
problems.
!
Avoid linking GPOs between domains to reduce users' logon time.
!
Minimize the number of GPOs that are applied to a user or computer. It is
better to include many policy settings in a single GPO than to create many
GPOs. One GPO with one hundred Group Policy settings processes faster
than one hundred GPOs with only one Group Policy setting each.

Slide Objective
To describe design
guidelines for applying
GPOs.
Lead-in
Keep your GPO design as
simple as possible to keep
logon time to a minimum.
10 Module 5: Designing Active Directory to Support Group Policy


$
$$
$

Planning for Group Policy
!
Designing Group Policy to Meet Administrative Needs

!
Prioritizing Application of Group Policy Objects
!
Filtering Group Policy Objects
!
Group Policy Inheritance and Blocking
!
Optimizing Group Policy Performance
!
Testing and Documenting the Group Policy Plan
!
Design Guidelines


You can configure Group Policy settings in conjunction with Active Directory
in your organization to define client standards for an entire organization, or
specifically for members of a single workgroup, job function, or location. An
effective Group Policy plan accommodates the needs of the organization and
the organization’s administration model. Use filtering to refine the application
of Group Policy to particular subsets of users and computers within a given
group. You can also block inheritance to prevent Group Policy from being
applied to particular subsets of users and computers.
Slide Objective
To identify the steps
involved in planning Group
Policy.
Lead-in
Once you have determined
where you will apply Group
Policy, there are additional

methods you can use to
configure Group Policy.
Module 5: Designing Active Directory to Support Group Policy 11


Designing Group Policy to Meet Administrative Needs
Strategy
Strategy
Strategy
Delegate the Right to Create New GPOs
Throughout Active Directory
Delegate the Right to Create New GPOs
Throughout Active Directory
Delegate the Right to Modify an Existing GPO
Delegate the Right to Modify an Existing GPO
Delegate the Right to Link GPOs to a Site,
Domain, or OU
Delegate the Right to Link GPOs to a Site,
Domain, or OU


There are various levels of administration for GPOs, including who can create
them, who can link them, and who can modify them. The following table lists
the administrative roles with regard to GPOs and the individuals who are
assigned the task.
Administrative
Role

Assigned to

Comments

Creating Members of GPO Creator –
Owner Group
Whoever creates the Group
Policy object owns it.
Modifying Users listed in GPO ACLs that
set who can administer Group
Policy objects
Because user rights can be
granted to specific users, it is
possible to delegate very
precise control over Group
Policy settings.
Linking Users listed in Active Directory
container ACLs that set who
can link GPOs to objects in
Active Directory
An IT group may create a
standard set of GPOs that can
be linked by lower level Group
Policy administrators.

Slide Objective
To describe the
administrative roles
regarding Group Policy.
Lead-in
Group Policy can be
administrated by creating,

modifying, or linking GPOs.
12 Module 5: Designing Active Directory to Support Group Policy


Prioritizing Application of Group Policy Objects
!
GPOs Are Processed in Order of Priority
!
Loopback Applies Group Policy to a Specific Computer


An object that has multiple GPOs assigned to it will process them in order of
priority. You can set the order in which GPOs are applied. For example, if a
GPO that restricts access is applied to an OU containing some users that need
access, you can prioritize the application of that GPO to occur after another
GPO that secures access to the necessary users. When several GPOs are applied
on the same object, some GPOs may contradict others. Remember that the last
GPO applied to an object will determine which Group Policy is applied (if there
are Group Policy settings that conflict with one another).
Loopback is a feature that allows administrators to override existing Group
Policy on a particular computer. Override user-based Group Policy with
computer-based Group Policy using loopback only when you want the
computer environment to be the same no matter which user logs on.
Slide Objective
To describe the importance
of the order in which GPOs
are applied.
Lead-in
You can prioritize the order
in which GPOs are applied

to ensure that a desired
GPO is not contradicted by
another GPO.
Module 5: Designing Active Directory to Support Group Policy 13


Filtering Group Policy Objects
Roanoke OU
__Apply Group Policy to
Roanoke Admins
__Apply Group Policy to
Roanoke Admins
Users
Roanoke Admins
D
E
N
Y
Filtering Prevents
Group Policy from
Being Applied


Filtering is used to exempt objects from Group Policy. For example, you will
want to exempt the group that administers who is responsible for a particular
OU from a Group Policy that prevents the users in the OU from editing the
registry on their workstations.
Using Security Groups to Filter GPOs
Consider creating another OU if you find that you must link multiple GPOs to a
single OU. A filter will affect all of the settings stored in a GPO. You cannot

filter certain settings from the GPO to apply or not apply to a group.
If you must use groups within an OU to achieve the desired filtering result,
consider creating another OU.

Group Policy settings for folder redirection or software installation are
not vulnerable to prioritization conflicts. In both cases, you can use ACLs to
refine how a GPO is applied.

Apply GPOs at a level where they affect the greatest number of computers and
users without creating the need for Group Policy filtering.
Slide Objective
To describe how filtering
GPOs will prevent their
being applied to certain
groups of users.
Lead-in
Filtering is used to exempt
objects from Group Policy.
Key Points
Group Policy cannot be
applied to groups, but can
be denied to specific
groups.
Note
14 Module 5: Designing Active Directory to Support Group Policy


Group Policy Inheritance and Blocking
When Blocked, GPO
Does Not Apply to

Child OU
GPO Linked to
Parent OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
Inheritance Blocked
OU


Group Policy Inheritance and Blocking
Within a domain, GPOs are inherited from one Active Directory container to
another, so that in the Active Directory structure, any Group Policy applied to a
parent container will also be applied to child containers.
Any GPO created at the domain level will be passed down through inheritance
to all objects within the domain. Any GPO applied to a parent OU will be
applied to all of its child OUs.
Blocking
You can block the inheritance of Group Policy. At the OU level, use the Block
Policy Inheritance setting in the GPO to prevent the OU from inheriting Group
Policy settings from a parent container. However, if the GPO of the parent
container has the No Override (enforce) option set, the Block Policy Inheritance
setting will have no effect. Use Block Policy Inheritance and the No Override
settings sparingly as these settings make the troubleshooting of GPOs difficult

and time consuming.
When users log on, any local Group Policy settings, or settings applied to an
individual workstation, are processed first, with non-local or Group Policy
settings for Active Directory objects processed last. This means that Group
Policy settings based in Active Directory will have precedence over any local
Group Policy settings. However, local Group Policy objects cannot be blocked.
Therefore, local Group Policy objects are always applied.
Slide Objective
To illustrate how blocking is
used to prevent inheritance
of Group Policy.
Lead-in
Group Policy is inherited
from parent containers to
child containers, but
inheritance can be blocked.
Module 5: Designing Active Directory to Support Group Policy 15


Optimizing Group Policy Performance
!
Optimize Group Policy Performance Over Slow
Connections by Adjusting:
#
Slow Link Processing
#
Periodic Refresh Processing
#
Client Side Extensions

To optimize performance over a network, many Group Policy settings can be
configured to run only when there is an adequate network connection. The
speed of the link can be set by the administrator to best use the available
bandwidth and ensure that Group Policy settings don’t consume bandwidth
required by other processes and applications.
Processing Group Policy over Slow Links
Users logging on to the network from portable computers and branch locations
may encounter slow links. To prepare for these encounters, Group Policy
settings can be set to process only when there is an adequate network
connection.
The following table shows the default Group Policy settings for allowing
processing over slow links, and whether the Group Policy setting can be
changed for particular types of Group Policy when a slow link is detected.
Type of Group Policy Default Changeable?

Security Settings ON NO
Administrative Templates ON NO
Software Installation and Maintenance OFF YES
Logon/Logoff and Startup/Shutdown
Scripts
OFF YES
Folder redirection OFF YES
Internet Explorer Maintenance OFF YES

To view a list of all of the Group Policy settings for which you can change slow
link behavior, open Computer Configuration\Administrative
Templates\System\Group Policy in any GPO.
Slide Objective
To describe the factors that

can optimize Group Policy
performance.
Lead-in
You can configure Group
Policy settings to optimize
the application of Group
Policy on the network.
16 Module 5: Designing Active Directory to Support Group Policy


Setting the Group Policy Periodic Refresh Rate
By default, Group Policy settings are refreshed every 90 minutes with a 30
minute randomized offset, which is a random time added to the refresh interval
to avoid peak loads on the network. This added time ensures that users who log
on at the same time will not congest the network with Group Policy refreshes
90 minutes after they log on. Therefore, Group Policy refreshes may occur from
90 to 120 minutes apart.
You can control the frequency of Group Policy refresh intervals. The refresh
interval could be shortened for a test environment, for example, or lengthened
to lessen the impact of Group Policy refreshes on network bandwidth. The
Group Policy refresh interval for domain controllers can be set separately from
all other computers. Setting the domain controller to update more frequently
ensures that changes are replicated to other domain controllers in a timely
manner.
GPOs are applied or refreshed when users log on, but only if a setting has
changed, in which case all GPOs are refreshed to ensure correct priority of
inheritance.
Client-side Extensions
Client-side extensions are Group Policy components that implement Group
Policy on a client computer. Some extensions, such as software installation and

maintenance, can result in high network traffic and slow performance. You can
change the behavior of client-side extensions with two settings: one that sets a
minimum connection speed below which the extension will not run, and one
that sets the extension to run no matter how slow the connection.
Module 5: Designing Active Directory to Support Group Policy 17


Testing and Documenting the Group Policy Plan
!
When Testing Group Policy:
#
Use an Off-Line Test Environment
#
Test During Off-Peak Hours if Testing Environment Is
Not Available
!
When Documenting Group Policy:
#
List Name of GPO
#
List Site, Domain, or OU Where Applied
#
List Individual Settings
#
List Special Settings


When planning to implement Group Policy, it is important that you test and
document your Group Policy plan.
Testing Group Policy Settings

Test the results of GPOs in a wide variety of situations. Many medium and
large organizations create a miniature version of the production environment to
use as a test bed. In small organizations without the resources to create a test
bed, it is recommended that you implement Group Policy in the production
environment at off-peak times, and have a solid regression strategy in place to
rectify any unwanted results. Strategies for testing include:
!
Logging on as representative users at representative workstations to verify
that the expected Group Policy settings have been applied and that
inheritance conflicts do not occur.
!
Testing mobile users by logging on in all possible variations to ensure that
Group Policy settings are applied consistently in all situations.
!
Testing portable computers by connecting them to the network from various
sites where users are likely to log on.

Use the GPResult.exe command-line utility from the Windows 2000 Server
Resource Kit to check Group Policy settings in effect on that particular
computer and on the user who is logged on to the computer.
Slide Objective
To describe key points of
testing and documenting
Group Policy
implementation.
Lead-in
You must test your Group
Policy plan prior to
implementation to ensure
that it performs as intended.

Documentation will assist
you in troubleshooting.
Delivery Tip
Demonstrate the
GPResult.exe utility for the
students, and tell them they
will use it in the lab for this
module.
18 Module 5: Designing Active Directory to Support Group Policy


Document the Group Policy Plan
Always keep a detailed list of all of the GPOs deployed in an organization so
that you can locate and resolve Group Policy conflicts. It is also a good idea to
keep a printed copy of this information. One way to track GPOs is to create a
simple database that stores information such as:
!
The name of the GPO.
!
The site, domain, or OU where the GPO was applied.
!
The individual Group Policy settings in the GPO.
!
Any special settings applied to the GPO, such as No Override (enforce).

Each time that you create a GPO, add the relevant information about the GPO
to the database. If there is a Group Policy conflict, you can quickly search the
database to locate the problem. For example, if the Run command is removed
from a user’s Start menu, even though you specifically disabled that Group
Policy setting for the Users OU, you can search the database for all Group

Policy settings that affect the Run command to find the source of the effective
policy.
Module 5: Designing Active Directory to Support Group Policy 19


Design Guidelines
!
Disable Unused Parts of a GPO
!
Reduce Need for Filtering By Creating Additional OUs
!
Use the Block Policy Inheritance and No Override
Features Sparingly


When planning Group Policy, remember the following:
!
Disable the unused portions of a GPO to improve performance and decrease
bandwidth demands. Disable the User Configuration or Computer
Configuration settings of a GPO if none of these settings are configured.
Disabling the unused settings also reduces logon time.
!
You can exempt a group of users in an OU from a GPO by filtering based
on security group membership. The need for filtering GPOs can be reduced
by creating additional OUs, thereby isolating the users or computers that
require certain policy settings.
!
Implement straightforward policies to make troubleshooting Group Policy
easier. For example, minimize Block Policy Inheritance, No Override, and
Filtering so it is easier to locate the source of a particular setting.

One of the ways that Group Policy affects a workstation is by modifying
the registry of a workstation, using a policy template file. A number of template
files are included with Windows 2000 allowing you to use Group Policy to
change the registry and therefore the user environment. You can create your
own Group Policy template files.

Slide Objective
To describe design
guidelines for planning
Group Policy and GPOs.
Lead-in
Remember the following
guidelines when planning
Group Policy.
Note