Contents
Overview 1
Identifying Business Needs 2
Designing the Initial Active Directory
Domain 3
Planning for Security Groups 4
Discussion: Designing Security Groups 9
Planning for OUs 11
Lab A: Designing a Group and
Organizational Unit Strategy 15
Review 22

Module 6: Designing an
Active Directory Domain


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 6: Designing an Active Directory Domain iii


Instructor Notes
This module explains how administrative tasks can be simplified according to
the ways objects are organized in the directory. It also explains how to plan the
organization of objects by using organizational units (OUs). The module
explores the relationship of an organization’s administrative model to the
organization of objects in a domain.
At the end of this module, students will be able to:
!
Identify business needs that determine domain and OU design.
!
Design the initial Active Directory
™
domain.
!
Plan security groups to support control of objects within OUs.

!
Plan a hierarchical OU structure within a domain.

Lab A, Designing a Group and Organizational Unit Strategy, is a scenario
based planning lab which reinforces the methods discussed in the module for
documenting existing administrative organization, planning, and designing an
OU structure that meets the business needs of an organization.
Students will work as a group through two scenarios, one for designing a single
domain, and one for granting access to security groups. The students will be
given information about the company’s current administrative structure. They
will create an OU structure to support the desired model by using Visio.
Materials and Preparation
This section provides you with the materials and preparation needed to teach
this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft
®
PowerPoint
®
file 1561b_06.ppt
!
Visio 2000

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!

Complete the lab.

Presentation:
45 Minutes

Lab:
75 Minutes
iv Module 6: Designing an Active Directory Domain


Instructor Setup for a Lab
This section provides setup instructions required to prepare the instructor
computer or classroom configuration for a lab.
Lab A: Designing a Group and Organizational Unit
Strategy
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\Lab6
directory is shared
and accessible from the student computers.
This planning lab describes the administrative and Group Policy needs of a
large organization. Students will design an OU structure based on their
knowledge of using OUs to delegate administration and assign Group Policy.
Students will work in pairs and will save their design to the share on the
instructor computer. Drawings should be saved to this share using a team name
or a name that does not personally identify the individuals.
Ensure that there is time at the end of the lab to display some student designs
and discuss them. Allow the students to make their arguments and discuss
among themselves. There may be variations in how the lab is answered and you
should be open to them.

The solutions share on the instructor computer includes a drawing of an optimal
answer.

Module Strategy
Use the following strategy to present this module:
!
Identifying Business Needs
This module describes the design of groups and OUs within a domain
structure. Explain the importance of gathering information about the
administrative model of an organization.
!
Designing the Initial Active Directory Domain
This section encourages organizations to use a single domain model with
multiple domain controllers to provide for fault tolerance. Stress the impact
of naming the first domain and the undesirable results of changing the name
at a later time.
!
Planning for Security Groups
Explain the role of security groups in Active Directory. Describe the three
security groups (universal, global and domain local) and explain which
group to use for a given scenario. Finally describe how nested groups can be
used to reduce administrative overhead.
!
Discussion: Designing Security Groups
Discuss designing security groups with the class.
!
Planning for OUs
Explain to students that there should be a model to provide a logical pattern
for the way that OUs are designed in a domain. Stress that the OU structural
design should be based on the administrative model of an organization.

Module 6: Designing an Active Directory Domain v


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 6: Designing an Active Directory Domain 1


Overview
!
Identifying Business Needs
!
Designing the Initial Active Directory Domain
!
Planning for Security Groups
!

Planning for OUs


The ongoing administrative tasks of an organization can be simplified by
initially planning how to organize objects in the domain. Within an Active
Directory domain, you can create a hierarchical structure of administrative
units, or organizational units (OUs), and then group objects into these units.
Understanding domains and organizational units, and how you can control
objects within each, will help you to plan a structure that fits into your
administrative model.
At the end of this module, you will be able to:
!
Identify business needs that determine domain and OU design.
!
Design the initial Active Directory domain.
!
Plan security groups to support control of objects within OUs.
!
Plan a hierarchical OU structure within a domain.

Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
how to design a domain
structure.
2 Module 6: Designing an Active Directory Domain



Identifying Business Needs
Before Designing a Domain, You Should:
!
Identify Administrative Strategy
!
Identify Security Needs
!
Plan for Growth and Flexibility


The administrative structure of an organization will determine the domain
design. When designing a domain, you should always begin by assuming that a
single domain can accommodate your organization’s administrative model.
Unless there is an important business reason, such as the need for distinct
domain-level policies, one domain should suffice for most organizations.
Within a domain, your OU design should reflect the organization’s
administrative hierarchy of authority. Prior to designing the domain, you should
do the following:
Identify Administrative Strategy
The administrative structure in your organization and the associated plan for
delegation of administrative authority together will form the basis for the
organization of the domain. Determine if you will use a locational,
organizational, functional, or a hybrid structure for your hierarchy design. You
must create the plan for delegation of administrative authority prior to creating
the domain and OU structure.
Identify Security Needs
You will need to identify different levels of security that are needed within
different areas of the organization. Your OU design will reflect these differing
security needs. You can also use security groups to grant groups or individuals

access to particular resources. Begin by identifying the groups that require
access, the location of the resources to be accessed, and any other restrictions,
such as organizational rules that may prohibit access by certain departments.
Plan for Growth and Flexibility Within the Organization
Make sure the domain name and OU structure you choose will accommodate
possible growth, acquisitions, or reorganizations.
Slide Objective
To show that the
administrative structure and
security needs of an
organization should
determine domain and OU
design.
Lead-in
When preparing a domain
design, carefully consider
the administrative structure
and the authority of
delegation of the business
or organization.
Key Points
The administrative model of
a business should
determine the domain
design, rather than the
actual organizational
structure of the business.

For more information about
the reasons why a business

or organization could require
multiple domains, direct
students to module 7,
“Designing an Multiple-
Domain Structure” in course
1561B, Designing a
Microsoft Windows 2000
Directory Services
Infrastructure.
Module 6: Designing an Active Directory Domain 3


Designing the Initial Active Directory Domain
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
First Domain
First Domain
nwtraders.msft
Active Directory
Active Directory



The first domain created in Active Directory is the root domain of the entire
forest. The first domain is also referred to as the forest root. The forest root
contains the configuration and schema information for the forest. The life of a
domain should range from three to five years. To ensure the longevity of your
domain structure, include your organization's growth projections and
reorganization plans in the Active Directory design.
Naming the Domain
Transitive trusts are established between the forest root and root domains of
other domains in the forest, and therefore, it is important to plan easy-to-use
and descriptive name for the forest root. The name of the first domain cannot be
altered once it is created.
The domain name should broadly identify your organization, because if you
create additional domains in the future, any child domains created from the root
domain will derive their names from the initial root domain. For example, if
you create a root domain named contoso.msft and add a domain under the root
domain named Marketing, the new domain will be named
marketing.contoso.msft.

Remember that the OU structure should reflect the administrative
structure and not the organizational structure of the organization because the
organizational chart will be of no use to the administrators who will be using
the OU structure.

Slide Objective
To illustrate the design of a
domain structure in Active
Directory.
Lead-in

The domain is the core
administrative unit in Active
Directory.
Key Points
The first domain is the root
of the forest. Choose a
name that is permanent
enough to reflect the
organization adequately and
flexible enough to be
included in the names of
possible child domains.
Choose the administrative
strategy to use prior to
creating the first domain.
Note
4 Module 6: Designing an Active Directory Domain


#
##
#

Planning for Security Groups
!
Deciding Which Security Group to Use
!
Planning for Nested Groups
!
Design Guidelines

!
Discussion: Designing Security Groups


Security groups organize individual user or computer objects for security
purposes. The scope of a group dictates who can belong to the group and what
permissions that group can be assigned. When designing your OU structure,
you will need to consider placement of resources within the OU and the
creation and placement of security groups to grant access to these resources.

Slide Objective
To identify how security
groups are used to support
OU designs.
Lead-in
Security groups allow you to
set permissions.
Module 6: Designing an Active Directory Domain 5


Deciding Which Security Group to Use
Domain Local Group
Domain Local Group
Domain Local Group
!
Members from any domain in the forest
!
Use for access to resources in one domain
!
Members from any domain in the forest

!
Use for access to resources in one domain
Global Group
Global Group
Global Group
!
Members from own domain only
!
Use for access to resources in any domain
!
Members from own domain only
!
Use for access to resources in any domain
Universal Group
Universal Group
Universal Group
!
Members from any domain in the forest
!
Use for access to resources in any domain
!
Members from any domain in the forest
!
Use for access to resources in any domain


Windows 2000 uses the following types of security groups:
!
Universal groups are used to group users and grant permissions across an
entire forest.

!
Global groups organize domain user objects across domains.
!
Domain local groups grant permissions to users to gain access to network
resources, such as folders, files, or printers in a single domain.

You use security groups to secure resources. Security groups allow you to
assign the same permissions to large numbers of users in one operation,
ensuring consistent permissions across all members of a group. An important
part of planning resource and administrative security is deciding when to use
each type of security group.
Planning for Universal Groups
Universal groups can contain members from any domain in the forest and can
be used in a discretionary access control list (DACL) or system access control
list (SACL) on any object in the forest. When creating and updating universal
groups in your organization, consider the following:
!
Design universal groups with memberships that will remain static over time.
Keep group modification to a minimum, because when you update the
membership of a universal group, the complete membership of that
universal group is replicated to all of the global catalog servers in the forest.
This replication can create a significant amount of traffic on the network.
!
Avoid adding individual users to universal groups, as they reduce the need
for membership changes.
Slide Objective
To explain how to plan for
security groups.
Lead-in
Security groups are the

single most important
method of securing
resources.
Key Points
Security groups are the
units for assigning and
maintaining permissions.
In order to take advantage
of all groups available in
Windows 2000, you should
set the domain to native
mode.
Choosing the appropriate
group scope is critical to
efficient management and
replication.
Delivery Tip
Review the types of groups
shown on the slide. Ask the
students where each group
type can be used, and who
can be a member of each
type. Draw examples of
possible members on the
whiteboard.
6 Module 6: Designing an Active Directory Domain


!
Create universal groups within other universal groups when possible to

reduce the number of members in each group. Adding groups to existing
groups of the same type is called nesting.
!
Keep the total number of objects within a universal group small to help
reduce replication traffic.

Universal security groups are only available in native mode. Domains
are created in mixed mode by default to permit compatibility with backup
domain controllers (BDCs) in Microsoft Windows NT 4.0. In an
environment without BDCs, there is no need to remain in mixed mode. To
use full functionality with groups, ensure that the domain is in native mode.


Planning for Global Groups
Global groups contain user objects from the same domain. When planning for
global groups, consider the following:
!
Unlike universal groups, replication of global group membership is within a
domain and not throughout the forest. Only the group name is replicated to
the global catalog servers, not the group membership. Therefore, inter-
domain replication traffic is less.
!
Global groups appear in the global catalog, which stores a full replica of
every object in that server domain, and partial attributes of all objects in
other domains. All other users and members from trusted domains can view
and access global groups for assignment to either domain local or universal
groups for security purposes.
!
Global groups can only contain other global groups or individual users from
the domain in which they exist.

!
Consider having small group sizes. Having a larger number of small-sized
groups is preferable to having a small number of large-sized groups; it will
aid in easier membership management. Consider breaking large global
groups into smaller global groups, and then nesting the global groups as
needed.

Nesting of global groups is available only when a domain has been
converted to native mode.


Planning for Domain Local Groups
Domain local group memberships are valid only in the domain where they are
defined and are not replicated to the global catalog. You can use domain local
groups to combine individual users and global groups from your domain, other
trusted domains, and universal groups.
When planning for domain local groups, consider the following:
!
Domain local groups are replicated throughout a domain. Therefore, you
will want to keep membership size small and take advantage of nested
groups.
!
Permissions should be assigned to domain local groups.
!
Domain local groups can contain members from any domain, but can only
be referenced in DACLs or SACLs from within the same domain.
Note
Note
Module 6: Designing an Active Directory Domain 7



Planning for Nested Groups
!
When Nesting, You Should:
$
Minimize Levels of Nesting
$
Document Group Membership
Worldwide
Managers
Group
Worldwide
Managers
Group
Northeast Managers
Mid-Atlantic Managers
Southwest Managers


Nesting can reduce the number of times permissions need to be assigned. You
can create a hierarchy of nested groups that will meet the requirements of the
organization. Nesting groups in a multiple domain environment can reduce
network traffic between domains and simplify administration.
For example, global regional groups can contain managers specific to each
region. Then all of the regional groups can be added to a Worldwide Managers
global group. In places where all managers have identical access needs,
permissions need to be assigned only once to the Worldwide Managers group.
Guidelines for nesting groups include:
!
Minimize levels of nesting to simplify permissions tracking. One level of

nesting is most effective because it reduces the number of permission
assignments and therefore makes it easier to track permissions.
!
Document group membership to track permission assignments. For
example, a temporary employees group can be created within a group for a
particular project. However, if the project group is then added to a group
that has access to the organization's confidential information, the temporary
employees would have access to that confidential information as well. By
documenting group memberships, undesired effects of nesting can be
revealed and prevented.

The nesting of groups is only supported when a domain is in native
mode.


Slide Objective
To illustrate how new
groups are nested within
existing groups.
Lead-in
Nesting of security groups
reduces the number of times
permissions need to be
applied.
Key Points
Nesting is used to create
groups within groups, which
allows for fewer members in
each group, and fewer
groups on which to assign

permissions.
Note
8 Module 6: Designing an Active Directory Domain


Design Guidelines
Payroll Clerks
Human Resources
C
h
a
n
g
e
HR Clerks
Benefits
HR Managers
HR Admins
Full Control
!
Add Users to Global
Groups
!
Add Global Groups to
Domain Local Groups
!
Assign Permissions to
Domain Local Groups



When designing security groups, remember the following:
!
Add user accounts to global groups rather than universal or local domain
groups. Try to create a global group within each domain for each job
description. Create further groupings by nesting the global groups within
other global groups. These groupings will minimize the replication time,
because only the base global group memberships should change on a regular
basis.
!
Add global groups to universal groups. Because universal group
membership is replicated to all global catalog servers every time a member
changes, try to keep the universal group membership static. Instead of
creating redundant universal groups, use nesting whenever possible.
!
Add global and universal groups to domain local groups as needed. Usually,
you only need to add global groups to the domain local groups. Placing
global groups into a universal group and then adding the universal group to
a domain local group is possible. However, creating a universal group solely
for this purpose is not recommended, because the security needs of each
global group may change.
!
Grant rights and assign permissions to domain local groups, instead of
global or universal groups, for greater flexibility and less complex
administration.
!
Delegate the authority to manage group memberships. This allows the
resource owners to manage access to their resource in the domain local
groups, and assistant administrators to manage the membership of global
groups. However, only Enterprise Admins can manage the membership of
universal groups.

Slide Objective
To identify guidelines for
designing security groups.
Lead-in
When designing security
groups, try the AGDLP
model.
Delivery Tip
Use the whiteboard and
repeat the AGDLP model by
placing user accounts into
global groups and global
groups into Domain local
groups, and then granting
resource permissions to the
domain local groups.

For more information on the
AGDLP model, refer to
module 6, Administering
Active Directory, from
prerequisite course 1560B,
Updating Support Skills from
Microsoft Windows NT 4.0
to Microsoft Windows 2000.

Remember to delegate the
ability to manage group
memberships.
Module 6: Designing an Active Directory Domain 9



Discussion: Designing Security Groups
chicago.nwtraders.msft
paris.nwtraders.msft
Employee
Database
Benefits
Database
Employee
Database
HR Users
HR Users


Class Discussion
Northwind Traders uses two domains: one for all resources in their Chicago
office and another for all resources in their Paris operation. The human
resources organization in each location maintains separate databases for
employee information. HR users in each domain should have change
permissions to the employee database in their own domain, and all HR users in
both domains should have read permissions on both employee databases. All
HR users in both domains should have change permissions to the benefits
database in Chicago.
1. How will you use security groups to grant the HR users in each domain
access to the employee databases in their respective domains?
Add Chicago HR users to a Chicago HR Users global group, and add
Paris HR users to a Paris HR Users global group. Add the Chicago
global group to a Chicago domain local group, and add the Paris global
group to a Paris domain local group. Grant change permissions for the

employee databases to each domain local group.
_____________________________________________________________
_____________________________________________________________
Slide Objective
To provide a scenario for
discussion of security group
design.
Lead-in
Here’s a scenario where we
can practice designing
security groups.
10 Module 6: Designing an Active Directory Domain


2. How will you use security groups to grant all HR users in each domain read-
only access to both the Paris and Chicago employee databases?
Add the Paris global group to a Chicago domain local group that has
read-only permission to the Chicago employee database. Add the
Chicago global group to a Paris domain local group that has read-only
permission to the Paris employee database.
_____________________________________________________________
_____________________________________________________________
3. How will you use security groups to grant all HR users in both domains
change permission to the benefits database?
Add the Paris global group and the Chicago global group to a universal
group. Add the universal group to a domain local group in the Chicago
domain that has change permission to the benefits database.
_____________________________________________________________
_____________________________________________________________
Module 6: Designing an Active Directory Domain 11



#
##
#

Planning for OUs
!
Planning Upper-Level OU Strategies
!
Planning Lower-Level OU Strategies
!
Design Guidelines


Plan your OU structure around your network administration model. The OU
structure is useful only to administrators. A well-designed OU structure
comprised of upper- and lower-level OUs will allow administrators to delegate
authority and apply Group Policy. Your OU structure should also accommodate
future reorganizations so that minimum object movement would be required.
Slide Objective
To explain strategies
involved in planning an OU
hierarchy.
Lead-in
There are different
strategies for OU hierarchy
design, depending on the
level and depth of an OU
plan.

12 Module 6: Designing an Active Directory Domain


Planning Upper-Level OU Strategies
nwtraders.msft
Root
Domain
Root
Domain
First
Level
Second
Level
Third
Level
North
North
America
America
Asia
Asia
Sales
Sales
HR
HR
Canada
Canada
Mfg
Mfg
HR

HR
Japan
Japan
Sales
Sales
HR
HR
China
China
IT
IT
HR
HR
Mexico
Mexico


When you design an OU structure, it should reflect your Active Directory
administrative model. An administrative model defines who in your
organization is responsible for managing specific users and resources across the
organization’s network, and the level of control each administrator maintains.
Upper Levels of OUs
Do not try to copy the organizational chart when you design the OU structure,
because the purpose is to make administration easier, which might not be
achieved by using political divisions in the OU structure. You do not need to
organize the OU hierarchy for ease-of-client access. Instead, create a hierarchy
that mirrors the administrative and security needs of the business. Use names in
the hierarchy that are meaningful to the administrative staff. You should also
keep the design simple to minimize the need for constant management. When
designing upper-level OUs, remember the following:

!
Base the first level OUs on a static aspect of the organization. This will help
prevent the need to restructure your first level OUs due to company
reorganization. For example, you might choose to have different OUs for
separate countries to allow for differences in administrative policies,
because geographies are much less likely to change than divisions of an
organization.
!
Consider making first-level OUs standard throughout an organization.
Although OU structures may be unique to each domain, you should consider
having a standard first level in the OU structure. You may have a standard
first level regardless of whether it is required or not. For example, you could
create first-level OUs for groups, printers, and applications within each
domain. OUs do not have replication or costs and this first-level structure
will keep administration for the domains consistent throughout the forest.
This provides consistency for organization-wide support.

Slide Objective
To show examples of upper-
level OU designs.
Lead-in
When designing the OU
hierarchy, consider your
administrative model.
Key Points
Do not copy the
organizational chart when
designing the OU structure.
Instead, create a hierarchy
that reflects the

administrative and security
needs of the business.

Choose your administrative
strategy first, making certain
the upper levels are fairly
static. Remind students that
users can query Active
Directory by using
Lightweight Directory
Access Protocol (LDAP).
Module 6: Designing an Active Directory Domain 13


Planning Lower-Level OU Strategies
nwtraders.msft
Root
Domain
Root
Domain
First
Level
Second
Level
Third
Level
North
North
America
America

Asia
Asia
Sales
Sales
HR
HR
Canada
Canada
Mfg
Mfg
HR
HR
Japan
Japan
Sales
Sales
HR
HR
China
China
IT
IT
HR
HR
Mexico
Mexico


Lower-level OUs should represent more detailed levels of administrative
authority within your organization. Create lower-level OUs to delegate

authority over objects to specific groups of users, and to accommodate Group
Policy needs. For example, you could create an OU to include users who need a
certain application, and then create a Group Policy for that particular OU.
You can design a hierarchical OU structure in which new lower-level OUs are
created, or nested, within existing OUs. This will prevent readjustment of your
administration model, and is similar to the nesting that can be done with groups.
When planning lower-level OUs, consider the following:
!
OUs can be administrated independently; however, when you create an OU
within an existing OU, it inherits the properties of the OU in which it is
created by default.
!
Only nest OUs as needed to provide a clear and accurate representation of
the organization’s administrative model. OUs nested too deeply can be more
confusing than beneficial.
!
Group Policy is applied to objects in OUs from the domain root. An OU
nested within another OU may have multiple levels of Group Policy to be
applied. The response time depends upon the number of policies that need to
be applied, and the size of those policies.
!
An OU cannot contain objects from another domain.


If Group Policy must travel over slow links in a wide area network
(WAN) to be applied to computer or user objects, performance may be
impacted if the Group Policy objects (GPOs) are stored in deeply nested OUs.

Slide Objective
To explain how to determine

appropriate OU levels.
Lead-in
Create lower level OUs to
support the Group Policy
and security needs of your
organization.
Key Points
Create enough levels to
support the administrative
structure and Group Policy.
Remember, Group Policy is
applied from the top level
down during the initial logon
of a client.
Note
14 Module 6: Designing an Active Directory Domain


Design Guidelines
!
When Designing the OU Structure:
$
Choose Stable Upper-Level OU Names That are
Meaningful to Administrators
$
Create Lower-Level OUs to Support Group Policy
$
Test the OU Structure and Make Changes Based On
Evaluation



Choose Stable Upper-Level OU Names
Choose the upper-level OU design strategy based on a stable aspect of the
organization, such as location. When naming OUs, remember that users do not
see the OU structure, so choose names that are meaningful to administrators.
Create Lower-Level OUs to Support Group Policy
Design lower levels of your OU structure to reflect your organization’s
administrative structure. Designing lower-level OUs to support your Group
Policy plan can optimize Group Policy implementation.
Test the OU Structure
When you have completed your OU design, develop administrative scenarios to
test your proposed OU design. These scenarios can be written or performed in a
lab. You should test your OU structure against the existing administrative
model of your business or organization. Based on your evaluations, make any
necessary changes to your OU design so that it supports all administrative needs
of your organization.
Slide Objective
To identify guidelines for
creating an OU hierarchy.
Lead-in
Follow these guidelines
when designing the OU
hierarchy.
Key Points
Choose the design strategy
first, and then create OUs to
support it.

Test the structure, making
adjustments to the design

as needed.
Module 6: Designing an Active Directory Domain 15


Lab A: Designing a Group and Organizational Unit
Strategy


Objectives
After completing this lab, you will be able to:
!
Design the initial Active Directory domain.
!
Design security groups to support control of objects within OUs.
!
Design a hierarchical OU structure within a domain.

Prerequisites
Before working on this lab, you must have:
!
Knowledge about nesting of security groups.
!
Knowledge about Group Policy.

Estimated time to complete this lab: 75 minutes
Slide Objective
To introduce the lab.
Lead-in
In this lab, you will create
the structure of a single

domain based on
organizational, Group
Policy, and security group
requirements.
Explain the lab objectives.
16 Module 6: Designing an Active Directory Domain


Exercise 1
Designing a Single Domain
You have 45 minutes to complete exercise 1. In this exercise you will work in
pairs to create the structure of a single domain based on the administrative and
Group Policy needs of an organization.
Scenario
Quality Computer Manufacturing Company is an international manufacturer of
server and workstation computers. They have four main locations across the
world in Chicago, Buenos Aires, Frankfurt, and Tokyo. They have 84
distribution centers worldwide.
The corporate headquarters is located in Chicago. Each location has a human
resources, sales, marketing, manufacturing, and distribution function.
Headquarters for North America are at Chicago, South & Central America at
Buenos Aires, Europe & Africa at Frankfurt and Asia & Oceania at Tokyo.
Research and Development takes place at Frankfurt and Tokyo.
Criteria
!
The IT group of each region administers user accounts, enforces network
security, handles desktop configuration, and manages servers.
!
Some corporate office administrators have administrative authority over the
entire network in order to solve problems and audit company-wide security.

!
The Research and Development (R&D) department has its own IT group
that administers user accounts, enforces network security, and manages
servers in a highly secure environment.
!
The IT group of each region administers user accounts for human resources
(HR); however, each HR department administers access to their own
servers.
!
The worldwide sales organization has a large number of mobile users who
must access the network over dial-up connections.
!
Mobile users must access updated network information and have it available
offline.
!
Some distribution locations in each region must access the network by slow
WAN links.
!
The entire company uses the same e-mail and word processing application.
!
Each regional sales organization uses its own lead tracking software.
!
Helpdesk users in each location can reset passwords.

Module 6: Designing an Active Directory Domain 17


Design Decisions
Based on the criteria given above:
1. Create an OU structure for Quality Computer Manufacturing that supports

the administration and Group Policy indicated in the scenario. Use Visio to
document the domain. Save your completed drawing in the
\\london\solutions\lab6 share using a team name as the file name.
qualitycomputer.msft
Beunos AiresChicago Frankfurt Tokyo R&D
BA_Mobile BA_SalesC_Mobile C_Sales T_Mobile T_SalesF_Mobile F_SalesC_HR BA_HR F_HR T_HR

2. Use the table below to document each OU in your design and the reason for
creating it. Also, indicate which computer and user accounts will be created
in each OU. Be sure that you have covered each criteria from the scenario.
Created this OU For this reason Place these users and computers in it

Chicago Allows for delegation of administration
to Chicago IT group.
User and Computer accounts for
Chicago location, except HR servers,
mobile computers, and sales users.
Buenos Aires Allows for delegation of administration
to Buenos Aires IT group.
User and Computer accounts for
Buenos Aires location, except HR
servers, mobile computers, and sales
users.
Frankfurt Allows for delegation of administration
to Frankfurt IT group.
User and Computer accounts for
Frankfurt location, except HR servers,
mobile computers, and sales users.
Tokyo Allows for delegation of administration
to Tokyo IT group.

User and Computer accounts for
Tokyo location, except HR servers,
mobile computers, and sales users.
R&D Allows for delegation of administration
to the R&D IT group.
User and Computer accounts for R&D
groups.
C_HR Allows for delegation of administration
of server resources to the Chicago HR
group.
Chicago HR servers.
BA_HR Allows for delegation of administration
of server resources to the Buenos Aires
HR group.
Buenos Aires HR servers.
F_HR Allows for delegation of administration
of server resources to the Frankfurt
HR group.
Frankfurt HR servers.
T_HR Allows for delegation of administration
of server resources to the Tokyo HR
group.
Tokyo HR servers.
18 Module 6: Designing an Active Directory Domain


(continued)
Created
this OU


For this reason

Place these users and computers in it

C_Mobile Applies Group Policy to mobile users. Chicago based mobile computers.
BA_Mobile Applies Group Policy to mobile users. Buenos Aires based mobile computers.
F_Mobile Applies Group Policy to mobile users. Frankfurt based mobile computers.
T_Mobile Applies Group Policy to mobile users. Tokyo based mobile computers.
C_Sales Assigns sales tracking tool through GPO. Chicago sales users.
BA_Sales Assigns sales tracking tool through GPO. Buenos Aires sales users.
F_Sales Assigns sales tracking tool through GPO. Frankfurt sales users.
T_Sales Assigns sales tracking tool through GPO. Tokyo sales users.

The drawing solution for question 1 and table solution for question 2
show the best OU structure and rational for this exercise. The following
are some alternate possibilities:
• It is possible to create just the first level of OUs and not create the
second level. In this case, Group Policy would be applied at the first
level of regional OUs with extensive filtering. By creating the second
layer of OUs, you reduce the need to filter Group Policy.
• Two more OUs could be created under the R&D OU to further
delegate administration in the department to local administrators in
Frankfurt and Tokyo. However, the criteria only states that R&D as
a whole has separate security needs.
3. Based on the administrative and Group Policy needs of the organization, list
in the following table the necessary security groups. Also, indicate what
type of group each one is and in which container each should be created.
Group Type Container

Chicago IT Global Chicago OU

Buenos Aires IT Global Buenos Aires OU
Frankfurt IT Global Frankfurt OU
Tokyo IT Global Tokyo OU
R & D IT Global R&D OU
Chicago HR Admin Global Chicago OU
Buenos Aires HR Admin Global Buenos Aires OU
Frankfurt HR Admin Global Frankfurt OU
Tokyo HR Admin Global Tokyo OU
Network Security Group Global Domain

Note:
• There is no need for Universal groups because there is only one
domain.
• Domain local groups will grant access to resources, so they are not
needed here.
• If students have chosen a broader OU structure, extensive filtering
will necessitate extra groups.

Module 6: Designing an Active Directory Domain 19


Exercise 2
Designing Groups to Grant Access
You have 30 minutes to complete exercise 2. In this exercise, you will design
security groups to grant access to network resources.
Criteria
• The Tokyo Human Resources department should have its own IT
group to manage all HR resources, including servers.
• Users company-wide must have access to information on the servers in
the Tokyo HR group.

• The following table identifies the resources managed by the benefits
department, within HR, the users that require access to these resources,
and the level of access they need.

Share Users Access

Benefits information Tokyo HR Server Administrators Full control
Benefits information Tokyo Benefit Specialists Change
Benefits information All Tokyo Employees Read
Benefits information Tokyo HR Managers Change
Benefits information All HR Mangers company wide Read
Benefits forms Tokyo HR Server Administrators Full control
Benefits forms Tokyo Benefit Specialists Change
Benefits forms All Tokyo Employees Read
Benefits forms Tokyo HR Managers Change
Benefits forms All HR Mangers company wide Read
Benefits forms Tokyo copy center Read
Vendor contracts Tokyo HR Server Administrators Full control
Vendor contracts Tokyo Benefit Specialists Change
Vendor contracts Tokyo HR Managers Change
Vendor contracts All HR Mangers company wide Read
401K elections Tokyo HR Server Administrators Full control
401K elections Tokyo 401K Administrators Change
401K elections Tokyo HR Managers Read
401K elections Tokyo Payroll Clerks Read
Medical elections Tokyo HR Server Administrators Full control
Medical elections Tokyo Benefits Specialists Change
Medical elections Tokyo HR Managers Read
Medical elections Tokyo Payroll Clerks Read