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

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.

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.

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
!


Identifying Business Needs
Before Designing a Domain, You Should:
!
Identify Administrative Strategy
!
Identify Security Needs
!
Plan for Growth and FlexibilityThe 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

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

!
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 domainWindows 2000 uses the following types of security groups:
!
Universal groups are used to group users and grant permissions across an
entire forest.

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

!
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


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

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.
Discussion: Designing Security Groups
chicago.nwtraders.msft
paris.nwtraders.msft
Employee
Database
Benefits
Database
Employee
Database
HR Users
HR UsersClass 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
#
##
#

Planning for OUs
!
Planning Upper-Level OU Strategies
!
Planning Lower-Level OU Strategies
!
Design GuidelinesPlan 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.

HR
Japan
Japan
Sales
Sales
HR
HR
China
China
IT
IT
HR
HR
Mexico
MexicoWhen 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:

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

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


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

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

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

• 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