© 2004 Mustan Bharmal. All Rights Reserved.

Table of Contents

1. INTRODUCTION................................................................................................................. .......................2
2. HOW TO USE THIS DESIGN METHODOLOGY................................................................................. ..................3
2.1. DESIGN METHODOLOGY OBJECTIVES..................................................................................................... ....3
2.2. DESIGN METHODOLOGY SCOPE............................................................................................ ...................4
2.3. BACKGROUND INFORMATION........................................................................................... .........................4
2.4. HOW TO USE THIS DESIGN METHODOLOGY....................................................................... .......................16

Page 1 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

1. Introduction
This design methodology began life as simple handbook for a specific audience, me! I needed
it so that I could access and employ a consistent method to approach and execute Active
Directory design projects, as a Lead Consultant within a leading IT consultancy firm.

As a MCT trainer in a previous life, I understood and acknowledged that there was a
significant gap between knowledge and design. I would often ponder for hours on how to
approach a design, and I would download and scour hundreds of whitepapers and articles for
the elusive “best practice” approaches.

However, all of the information I read on Microsoft Windows 2000 and Windows Server 2003
Active Directory was all about the technology, and nothing on how to design the technology
for implementation and management.

So, rather than continue as “one of the flock”, I thought I would develop my own set of
approaches and hence I began this design methodology. I started work on this design
methodology over 18 months ago, in calendar quarter 4 of 2002, when Windows Server 2003
was known as “Windows.Net Server”, and was in Beta / RC stage.

I missed several personal deadlines, namely the release to manufacturer of Windows Server
2003, due to my professional work commitments. This hence meant I could only work on this
design methodology during my evenings and weekends, and in airport lounges, on trains, on
train platforms, and so on.

However, here it is! I hope that it is as useful to you as it is to me, as I personally use it for
every professional engagement I undertake, which has anything to do with Active Directory,
from design and quality review / assurance, to responding to invitations to tender, and so on.

Please ensure that you read and understand the first chapter before the use of this design
methodology, as it not the usual “read me first” section, but contains very important
information.

Page 2 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

2. How to Use this Design Methodology

Prior to the use of this design methodology, it is imperative that the reader understand the
following concepts and prerequisites to its use:

1. The objectives of this design methodology

2. The scope of this design methodology

3. Background information on the design methodology

4. How to use this design methodology

This chapter provides the reader with the above information.

2.1. Design Methodology Objectives

It is possible to interpret the objectives of this design methodology from the following two
perspectives:

1. The perspective of the reader and user of this design methodology, and

2. The perspective of the author of this design methodology

From the perspective of the reader and user of this design methodology, the objective of this
design methodology is to assist administrators and / or IT consultants for an organisation, in
the generation of a verifiable and justifiable design for an entire Windows Server 2003 Active
Directory infrastructure.

This design methodology achieves this objective via the provision of detailed methods and
approaches to execute specific analysis and design activities associated with Windows Server
2003 Active Directory.

It is possible for consultants to use the approaches contained within this design methodology
for Windows Server 2003 Active Directory in the following contexts:

• During pre-sales engagements, such as meetings, workshops, responding to invitations to

tender for Active Directory design work, and so on.

• During post-sales engagements, to assist in the generation of a design for a Windows

Server 2003 Active Directory infrastructure

From the perspective of the author of this design methodology, the primary objectives for this
design methodology are as follows:

• To bridge the gap between knowledge and design

• To provide a standard and consistent approach towards the design of a Windows Server
2003 Active Directory infrastructure

Almost all authoritative sources of information on Windows Server 2003 Active Directory, even
from Microsoft, have one thing in common. They all provide facts about the technology and
features within Windows Server 2003 Active Directory.

These sources of information will all tell you what to do to implement the feature, how to
configure the feature, how to troubleshoot the feature, and so on. However, there is very little,
if any, information on how to generate a design for the implementation of the feature.

Hence, consider this design methodology as the bridge between knowledge and design. This
objective naturally implies the following:

• This book is not a technical reference manual for Windows Server 2003 Active Directory

Page 3 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

• The use of this book and design methodology requires compliance with the prerequisite of
a sound level of knowledge of Windows Server 2003 Active Directory concepts. See the
background information section of the introduction for details of reader prerequisites.

2.2. Design Methodology Scope

When generating a design for an Active Directory infrastructure, it is possible to create the
following three types of designs, as a reflection of their function:

1. A design for implementation of an Active Directory infrastructure

2. A design for deployment of an Active Directory infrastructure (to cover the proof-of-
concept, pilot, and deployment phases of a project)

3. A design for management of an Active Directory infrastructure

Although these three components represent the entire scope of this design methodology, this
book will assist an organisation in the generation of only the first component, which is the
design for implementation of an Active Directory infrastructure. A subsequent volume is in
consideration for development, to assist an organisation in the generation of the other two
design components.

This design methodology strongly recommends that a design for post-implementation

management compliment a design for implementation of an Active Directory infrastructure.

A design for implementation is a design for an Active Directory infrastructure with enough
information to implement it into the production or other environment(s) for an organisation,
and execute a migration to the new Windows Server 2003 Active Directory infrastructure.

A design for deployment of an Active Directory infrastructure provides all the information
necessary to execute the proof-of-concept, pilot, and deployment phases of an Active
Directory project.

A design for management is a design for an Active Directory infrastructure to support the
execution of all post-implementation management tasks and operations, such as the
execution of the following examples of management tasks:

• Execution of backup and restore tasks for the Active Directory

• Execution of disaster recovery for the Active Directory

• Execution of routine object and resource management tasks

• Procedures for the design and implementation of modifications to the Active Directory
infrastructure

It is important to note that the scope of this design methodology is restricted to Windows
Server 2003 Active Directory. It is not the intention of this design methodology to support the
design and implementation of Windows 2000 Active Directory, as it is possible to identify a
significant number of feature differences between these versions of Active Directory.

2.3. Background Information

This section provides the following information about the design methodology:

• What is meant by “design” and a “design methodology”

• Details of the structure and contents of the design methodology

• Details of the terminology presented and discussed within this design methodology

• Details of the prerequisites to the use of the design methodology

Page 4 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

2.3.1. What is meant by “Design” and a “Design Methodology”

Before attempting to understand the structure and contents of this design methodology, it is
necessary to understand what design is, and hence what a design methodology is.

There are many different interpretations and understandings of the term “design”. The
dictionary definitions of the word “design”, as a verb, are:

• A transitive and intransitive verb to make a detailed plan of the form or structure of
something, emphasizing features such as its appearance, convenience, and efficient
functioning

• A transitive and intransitive verb to plan and make something in a skilful or artistic way

• A transitive verb to intend something for a particular purpose

• A transitive verb to contrive, devise, or plan something

From the perspective of the use of this word in the sentence “design a Windows Server 2003
Active Directory infrastructure”, it has very different interpretations.

This author hence regards “design” as “the execution of activities to determine, plan, and
create a logical solution, which is viable, justifiable, and auditable, and which addresses
specific variables to support a specific set of functions”. When attempting to understand this
definition, consider the following:

• Active Directory is a pre-designed software solution. An organisation does not have to

design the code to create Active Directory, as Microsoft has already done this. Hence, it is
possible to perform a very quick and simple installation of a working Active Directory
infrastructure without any code design. It is also possible to implement an Active Directory
infrastructure without any “design”. Although this installation will hence be a working
solution of an Active Directory, it is possible to guarantee that this solution will not support
all of the business and technical requirements for the intended organisation.

• A default installation of Windows Server 2003 Active Directory will not support all of the
requirements because there was no design involved, to address and support variables. A
Windows Server 2003 Active Directory design variable is a logical or configuration option
with one or more of the following (example) profiles:

♦ To address the design variable, it is necessary to address the option with a value, as
the software does not provide a default value. For example, when executing Active
Directory Installation Wizard, it is necessary to address the variable “domain name”
with a DNS and NetBIOS domain name for a required domain.

♦ To address the design variable, it is necessary to address the option via the selection of
a value from two or more potential values provided or supported by the software /
solution concept. For example, when determining the design requirements for Group
Policy Objects, it is necessary to select for a required policy, a value for (for example)
“enabled” or “disabled”.

• Before addressing a variable, it is necessary to acknowledge the variables that require

addressing and understand the impact of addressing the variables. Following identification
of the variables that require addressing, and to address a specific variable, it is necessary
to make a decision as to the required value(s) for the required variable. To make such a
decision, it is first necessary to gather all necessary to understand all configuration and
value options for the variables.

• Hence, to address Windows Server 2003 Active Directory “design” variables, it is

necessary to execute the following (very high-level and simplistically presented) steps:

Page 5 of 22 Last printed 28/5/2004 11:48 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Step 1 is to understand the components / features / concepts of Active Directory that

require design

♦ Step 2 is to understand the variables associated with the identified components /

features / concepts of Active Directory

♦ Step 3 is to determine the variables, associated with the identified components /

features / concepts of Active Directory, required by the organisation

♦ Step 4 is to understand the possible values for the required variables

♦ Step 5 is to determine the required value(s) for the variables required by an

organisation

• In order to determine which variables an organisation requires (step 3), for the identified
components / features / concepts of Active Directory, and determine the required value(s)
for the required variables (step 5), it is necessary to execute an analysis to determine the
business and technical requirements that the required variables and their value(s) are to
support. This design methodology refers to the execution of these steps as the
“determination of the design requirements” for a required components / feature / concept
of Active Directory.

• However, simply executing the above steps does not generate a “design” for a Windows
Server 2003 Active Directory infrastructure. A design decision is a value for a variable that
is justifiable and auditable.

• In order to justify a selected value or values for a variable, it is necessary to demonstrate

that it complies with specific business and technical requirements and objectives for the
Active Directory component / feature / concept the value for the variable is to address and
support. In order to demonstrate this compliance, the author has deemed that it is
necessary for an organisation to define criteria. The dictionary definition of a “criterion” (the
singular of criteria), as a noun, is “an accepted standard used in making decisions or
judgments about something”. Hence, if an organisation defines their criteria, as an
accepted standard that a value for a variable is required to meet, and the value complies
with the defined criteria, then the organisation must accept the value, and hence it is
feasible to state that this value is a “justified” value.

• In order to audit a design decision, it is necessary to demonstrate all of the following steps:

♦ The steps taken to determine the variables that require addressing because they are
applicable to an organisation

♦ The steps taken to determine the potential values available for the variables that
require addressing

♦ The steps taken to select one or more values for a variable that requires addressing

♦ The steps taken to define the criteria to qualify and justify the selected value(s) for the
variables that require addressing

♦ The steps taken to evaluate the selected values against the defined criteria to justify the
selection of those values

• Once all of the above steps are demonstrated, and repeatable, the end solution is an
auditable design decision. Note the key use of the word “repeatable”. In order to audit a
design decision, the auditor must have sufficient information to be able to repeat
(independently and actually or logically) all of the steps taken to select a justified value for
a variable. The combination of an analysis report and design document must hence
provide all of this required information.

Page 6 of 22 Last printed 28/5/2004 11:48 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• As it is possible to note from the above, there is a lot more involved in the generation of a
design for a single component or feature of Active Directory than simply selecting a value
for an appropriate variable.

• Hence, when generating a “design” for an Active Directory infrastructure, it is necessary to

execute “analysis” and “design” activities. The analysis activities will assist in the
determination of the required variables and values for these variables. The “design”
activities will perform (for example) the following:

♦ The collation of all identified design requirements (as required values for required
variables) into a single solution

♦ The documentation of the steps taken to determine the design requirements, and
generate the required justifiable and auditable design

• This design methodology suggest that the results of all analysis tasks require collation into
an “analysis report”, which details (for example) the following:

♦ The concepts / components of Active Directory that were explored during the analysis
workshop

♦ The business and technical requirements and objectives that will influence and guide
the selection of the required components, variables of that component, and value(s) for
the selected variables

♦ The concepts / components that the organisation requires for design and
implementation, as they comply with the defined business and technical requirements
and objectives

♦ The variables associated with the required concepts / components of Active Directory

♦ The variables that require addressing to generate a design for implementation, as they
comply with the defined business and technical requirements and objectives

♦ The potential values for the required variable that require selection

♦ The required values to support the defined business and technical requirements and
objectives

♦ The criteria to qualify the required components, variables, and values

♦ The results of the evaluation of the required components, variables, and values against
the defined criteria

• The justification for the generation of an analysis report is that the report details all design
requirements. These requirements require validation by the organisation prior to
generation of the design. Where an organisation does not validate the requirements, and a
design generated against invalid requirements, then the design is invalid. This will hence
require the execution of redesign activities, which are associated with cost and time
overheads.

• To summarise:

♦ “Design” is execution of “analysis” and “design” activities

♦ The results of analysis activities require documentation within an “analysis report”

♦ Design decisions must be justifiable via demonstrated compliance with business and
technical criteria

Page 7 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

♦ Design decisions must be auditable via detailed documentation (in a “design

document”) of all steps and considerations used to reach the required design decisions

So what does this “design methodology” do? This design methodology provides guidance to
the reader in the following areas (note that this list is not exhaustive):

• Identification of the Active Directory concepts, components, and features that require
design

• Background information about the Active Directory concepts, components, and features
that require design

• Provision of detailed methodical approaches on how to execute the required analysis and
design activities, and the expected results of these activities

• A breakdown of the components that require design into processes, and components
within a process

• Illustration of the dependencies between each component of a “process”

• Identification of the variables associated with an Active Directory concept, component, and
feature that require addressing

• Identification of the potential values associated with the identified variables

• Information (as “considerations”) to assist an organisation in the selection of the required

components, variables, and values for the variables

2.3.2. Design Methodology Anatomy

This design methodology is comprised of “plans”, “processes”, “components”, and “factors”. A

“plan” is a logical collection of related Active Directory design “processes”. A “process” is a
discrete series and collection of analysis and design activities that generate a discrete set of
design deliverables. “Components” are modular sections of a process that an organisation
may execute discretely to other components, although it is necessary to observe and respect
any present inter-component dependencies. “Factors” are the smallest executable elements
of a process and component (see the section “process anatomy and terminology”, for details
of “factors” and types of factors within a process). Each component within a process may
have differing types of factors that require execution. The following diagram illustrates the
relationships between the elements of this design methodology:

Plan (within Design Methodology)

Process (logically aligned Process (logically aligned
to a plan) to a plan)
Component (within a Component (within a
process) process)

Execute Execute Execute

B1 B1 A1

Component (within a Component (within a

process) process)

Execute Execute Execute

A1 D1 D1

FACTORS © 2004 MUSTANSHI R BHAR MAL

Figure 1.1: Anatomy of this Design Methodology

Page 8 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

For example, a “Forest Plan” is a logical collection of all design “processes” related to a
Windows Server 2003 Active Directory forest, such as design activities to determine the
number of domains required within a forest, and so on.

The Forest Plan “process” to “determine the number of domains required” is a discrete set of
analysis and design activities that generate the deliverables of (for example) the number of
domains required, and the justifications (as criteria) to qualify the required number of
domains, and so on.

The “process” to “determine the number of domains required” is comprised of the following
three “components”:

• Determination of the viability of a multiple domain infrastructure within the forest for the
organisation

• Determination of the requirement to use a dedicated (placeholder) forest root domain or a

non-dedicated (and hence dual-function) domain to act as the forest root domain

• The determination of the number of domains required within the forest

This book represents each “plan” as a “section”, and each “process” as a “chapter”.

This design methodology is comprised of five plans and thirty-eight actual processes. Note
that the five “introduction” chapters to each plan, and the Migration Plan process
“understanding supported migration paths” are not strictly “design” processes, as they do not
have any associated deliverables.

Note that this design methodology categorises some processes as mandatory (require
execution by all organisations wishing to design a Windows Server 2003 Active Directory
infrastructure) and some processes as optional.

This design methodology is comprised of the following five plans:

1. Organisation-Wide Active Directory Plan

2. Forest Plan

3. Site Plan

4. Domain Plan

5. Migration Plan

The following sections discuss the objectives of each plan, and the processes logically
aligned to each plan.

2.3.2.1. Organisation-Wide Active Directory Plan

The objective of the organisation-wide Active Directory plan is to generate a design for all
aspects and components of a Windows Server 2003 Active Directory infrastructure that
require design at the organisation-wide level. Hence, this plan is comprised of the following
five design processes:

1. Execution of an analysis to determine the number of forests required (this is a mandatory

process)

2. Determination of the logical and physical boundaries and contents of each required forest
within the organisation (this is a mandatory process)

3. Generation of a design for one or more federated forest infrastructures (this is an optional
process)

Page 9 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

4. Generation of a design for a DNS infrastructure (this is a mandatory process)

5. Generation of the design for object naming models (this is a mandatory process)

2.3.2.2. Forest Plan

It is necessary to generate a forest plan for each production forest required by an

organisation. The objective of the forest plan is to generate a design for all aspects and
components of a Windows Server 2003 Active Directory infrastructure that require design at
the forest level. Hence, this plan is comprised of the following nine design processes:

1. Determination of the number of domains required within the forest (this is a mandatory
process)

2. Determination of the structure and relationships of multiple domains (this is a mandatory

process)

3. Determination of the boundaries and contents of each required domain (this is a

mandatory process)

4. Generation of a design for short-cut trust relationships (this is an optional process)

5. Determination of the size of the Active Directory database for the forest (this is a
mandatory process)

6. Generation of a design for the forest root domain (this is a mandatory process)

7. Generation of a design for custom application directory partitions (ADPs) (this is an

optional process)

8. Generation of a design for directory quotas (this is an optional process)

9. Selection and raising of the forest functional level (this is a mandatory process)

2.3.2.3. Site Plan

It is necessary to generate a Site plan for each production forest required by an organisation,
regardless of the physical distribution of the domain controllers within the forest. The objective
of the Site plan is to generate a design for all aspects and components of a Windows Server
2003 Active Directory infrastructure that require design at the Site level. Hence, this plan is
comprised of the following eleven design processes:

1. Execution of a detailed analysis of the current and proposed network infrastructure for the
organisation (this is a mandatory process)

2. Determination of the number of Sites required within the forest (this is a mandatory
process)

3. Generation of a design for domain controllers and Global Catalog servers (this is a
mandatory process)

4. Generation of a design for preferred bridgehead servers (this is an optional process)

5. Generation of design for mapping of TCP/IP subnets to Sites (this is a mandatory

process)

6. Determination of the requirements for multiple Site Link objects (this is a mandatory
process)

7. Generation of the design for a Site Link topology (this is a mandatory process)

8. Generation of a design for Site Link Bridge objects (this is an optional process)

Page 10 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

9. Generation of a design for the configuration of Site Link objects (this is a mandatory
process)

10. Generation of a design for custom connection objects (this is an optional process)

11. Generation of a design for replication topologies for custom ADPs (this is an optional
process)

2.3.2.4. Domain Plan

It is necessary to generate a domain plan for each production domain required by an

organisation. The objective of the domain plan is to generate a design for all aspects and
components of a Windows Server 2003 Active Directory infrastructure that require design at
the domain level. Hence, this plan is comprised of the following nine design processes:

1. Partitioning of a domain for object and resource management (this is a mandatory

process)

2. Design of an object and resource management infrastructure (ORMI) (this is a mandatory

process)

3. Generation of the design for a GPO infrastructure (this is a mandatory process)

4. Generation of the design for a delegation of control (DOC) infrastructure (this is a

mandatory process)

5. Generation of a design for a security group infrastructure (this is a mandatory process)

6. Generation of a design for an Organizational Unit (OU) infrastructure (this is a mandatory

process)

7. Generation of a design for domain controllers within the domain (this is a mandatory
process)

8. Generation of a design for external trust relationships (this is an optional process)

9. Raising the domain functional level (this is a mandatory process)

2.3.2.5. Migration Plan

It is necessary to generate a migration plan for the migration of each existing (legacy and
Windows Server 2003) and discrete directory service infrastructure within the organisation to
the target Windows Server 2003 Active Directory infrastructure. The objective of the migration
plan is to generate a design for all aspects and components of a Windows Server 2003 Active
Directory infrastructure that require design to execute a migration. Hence, this plan is
comprised of the following five design processes:

1. Execution of a detailed analysis of an existing legacy directory service infrastructure (this

is a mandatory process)

2. Understanding supported migration paths (this is a mandatory process)

3. Determination of the required migration strategy (this is a mandatory process)

4. Generation of a design for each required migration path (this is a mandatory process)

5. Generation of a design for a migration schedule and communications plan (this is a

mandatory process)

Page 11 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

2.3.3. Process Anatomy and Terminology

A few concepts and terms used within this design methodology may be new to many readers.
This section hence provides an explanation for the anatomy of a design methodology
process, and an explanation of the following terms and concepts:

• An explanation of “null hypotheses”

• The definition of “organisation”

• The differences between “determination” and “identification”

To simplify the use of this design methodology, and the execution of the processes within this
design methodology, almost all processes are comprised of the same following sections:

• Process Objectives

• Process Scope

• Background Information

• Process Approach

• Process Components

• Process Deliverables

• Inter-Component Dependencies

• Process to <name_of_process>

• Process Considerations

The “process objectives” section outlines the objectives of the process, in one or two short
paragraphs. This is to provide the reader with a quick understanding of the process.

The “process scope” section outlines the scope of, for example, an Active Directory
infrastructure, or the organisation, which the process will address.

The “background information” section provides high-level and pertinent information about the
Active Directory concepts the process addresses. Note that it is not the intention of this
section to replace or compensate for any lack of knowledge of the Active Directory concept
the process addresses.

The “process approach” section details the steps this design methodology proposes for the
execution of the analysis and design activities within the process. This section will also state
the null hypothesis or hypotheses for the process (see later for details of null hypotheses).

The “process components” section details the components of the process, to reflect the
process objectives and approach, which the reader may discretely (logically) execute.

The “process deliverables” section provides simple bullet point deliverables for a process, to
provide the reader with the expected results from the execution of the process.

The “inter-component dependencies” section, represented as a diagram, shows the logical

relationships and dependencies between the components of the process. An inter-component
dependency is occurs when the output of one component will influence the execution of
another, and hence may be one of the required inputs for a dependent component. The
arrows depict the direction of the dependency, where the arrow points to the dependent
component. The objective of this section is to assist the reader in understanding the
relationships and eventual order for execution of the process components, to reflect their

Page 12 of 22 Last printed 28/5/2004 11:48 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

dependencies. This information is invaluable to coordinate the execution of components of a

process by different persons within an Active Directory project, delegated one or more
components.

The “process to <name_of_process>” section, represented as a simple flow diagram, is a

“process map” that explains to the reader how to execute the process. Execution of the
process requires the execution of “factors” within the “process considerations” section (see
later for details). A “factor” is the smallest executable component of this design methodology.

This design methodology has identified three types of “factors”, which are “background”
factors, “analysis” factors, and “design factors”. “Background” factors are information-only
factors, and do not require the reader to perform any analysis or design activities after reading
the factor. “Analysis” factors guide the reader in the execution of analysis tasks to determine
design requirements, and so on. “Design” factors guide the reader in the execution of design
tasks to generate the required designs, based upon the determine design requirements from
relevant analysis factors.

To facilitate the use of the “process maps”, each of these factors is colour and letter coded, as
follows:

• This design methodology has assigned “background factors” with the label “Factor B<n>:”
within the “process considerations” sections, where <n> is a number from one onwards.
Note that the factor numbering is unique to each process and each type of factor. Within
the “process maps”, background factors are depicted as follows:

Execute
B1

• This design methodology has assigned “analysis factors” with the label “Factor A<n>:”
within the “process considerations” sections, where <n> is a number from one onwards for
each process. Within the “process maps”, analysis factors are depicted as follows (in this
diagram, this “process map” instruction requires the reader to sequentially execute three
analysis factors, numbered A1 to A3):

Execute
A1 – A3

• This design methodology has assigned “design factors” with the label “Factor D<n>:”
within the “process considerations” sections, where <n> is a number from one onwards for
each process. Within the “process maps”, design factors are depicted as follows:

Execute
D1

Note that the factors, within the process considerations section of a process, require
execution in the order listed. Note that the “process maps” only direct the readers to execute
different factors based upon major design decisions. The onus is with the readers to evaluate
the “criteria for execution” (see later) for each factor, to determine compliance and hence the
requirement to skip or execute the factor.

The “process considerations” section is the heart of each process. This section details the
following:

• The considerations a reader must understand to execute a process

• The design or analysis activities the reader must execute to complete a process

Page 13 of 22 Last printed 28/5/2004 11:48 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

As discussed above, this design methodology has categorised the contents of the process
considerations section into discrete executable sub-components, called “factors”. Each factor
has the following anatomy:

• A factor heading, as “Factor <B / A / D><n>: <objective of factor>”

• A sub-factor heading for the criteria for the execution of the factor, as “Criteria for
Execution: Explore the considerations for the execution of this factor where an
organisation <criteria>”. The onus is with the reader to ensure compliance with these
criteria prior to execution of the factor. Some factors have specific criteria, whilst others are
very general, and merely reflect the objectives of the factor. It is important to read these
very carefully.

• A sub-factor heading for the considerations of the factor, as “Factor Considerations:

Consider the following information where it is possible to identify compliance with the
above criteria within an organisation:”

• The actual considerations for the factor

• The summary (for analysis and design factors only) of tasks that require execution,
typically as “Using the above information, execute the following:”

This design methodology introduces the use of “null hypotheses” into design activities and
processes. Not all of the processes within this design methodology support null hypothesis,
but most do.

Scientific and mathematical communities frequently use “null hypotheses” to guide the
development of an approach and hence assist in execution of analysis activities. Statistically,
it is simpler and feasible to disprove something, rather than prove something. Hence,
scientists devise a null hypothesis as something to work against, to attempt to disprove the
hypothesis. Successfully disproving a hypothesis hence directly proves, or provides the
opportunity to prove, the opposite of the hypothesis, and hence the stated hypothesis is a
“null” hypothesis.

It is possible to identify a multitude of interpretations to the term “null hypothesis”. In order to

understand a new concept, sometimes it is easier to understand it if it is presented from more
than one perspective. Hence, the author has provided the following collection of definitions of
the term “null hypothesis”:

• “A null hypothesis is a hypothesis that has been suggested because it is believed to be

true or because it is to be used as a starting point for scientific argument”

• “A null hypothesis is a statistical hypothesis that states that there are no differences
between observed and expected data”

• “A null hypothesis is a formal statement that there is no difference or no relationship

between variables. Researchers then use the results of statistical test to reject or disprove
the null hypothesis.”

• “A null hypothesis is, in terms of probability, the hypothesis of what most likely is occurring
in a situation; the goal of subsequent experiments is then to try to disprove the null
hypothesis.”

• “A null hypothesis is the statement being tested in a hypothesis test. It usually represents
the status quo and it is not rejected unless there is convincing sample evidence that it is
false.”

So how do null hypotheses relate to Active Directory and this design methodology?

This design methodology’s guiding design principal is “keep it simple”. This hence implies a
minimalist design for all components of an Active Directory infrastructure, such as the number

Page 14 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

of forests, number of Sites, number of domains within a forest, number of OUs, number of
Site Link objects, and so on.

This design methodology hence translates this guiding design principal into null hypotheses,
where appropriate, which perform the following:

• A null hypothesis reflects a feasible and viable pre-process execution design decision by
this design methodology, such as “one forest is all that is required”, or “one Site will
support all Active Directory replication requirements”.

• A null hypothesis reflects a starting point for execution of analysis to disprove this null
hypothesis via justifiable and qualified business and technical objectives and
requirements.

For example, this design methodology requires all organisations to start with one forest, and
hence states the null hypothesis “A single forest for an organisation can adequately meet all
the Active Directory-related requirements for the organisation without the requirement to
create a multiple forest infrastructure”.

Once this hypothesis is stated, it is then necessary to execute analysis activities to prove why
one forest is unable to support all Active Directory-related requirements for the organisation. If
it is not possible to disprove this null hypothesis, then the hypothesis stands, and the
organisation will only require one forest. However, if it is possible to disprove the null
hypothesis, using the approach provided by this design methodology within the process, then
(in this example) the number of forests required is justifiable.

This design methodology frequently uses the term “organisation”, and it is even a name
component for one of the five plans. The term “organisation”, as used within this design
methodology, implies the logical entity that will eventually own, manage, or be responsible for
the designed and implemented Windows Server 2003 Active Directory infrastructure.

This design methodology frequently employs the terms “determination” or “determine”, and
“identification” or “identify”. It is important to understand the subtle differences between these
terms, which are as follows:

• “Determine” / “determination” implies the reader is required to execute (proactively)

analysis tasks to find out something not easily apparent or known.

• “Identify” / “identification” implies that the reader is required to execute analysis tasks to
acknowledge something that may be apparent or already known.

2.3.4. Prerequisites for Use of Design Methodology

Although each process within this design methodology includes a “background information”
section and “background factors” (see later for details of “factors”), the scope and objective of
this design methodology requires the exclusion of comprehensive and technical background
information.

The author has deemed it unnecessary to include this information, as there is a plethora of
such information readily available, and to include it in this design methodology would cloud its
objective.

Hence, this design methodology requires compliance with the following strict prerequisites to
the use of this design methodology:

• The reader and user of this design methodology must have a working knowledge of Active
Directory concepts, for Windows 2000 or Windows Server 2003 Active Directory

• The reader and use of this design methodology must have access to reference manuals,
help files, whitepapers, and so on, and the actual operating system, during the use of this
design methodology

Page 15 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

To provide a rough guideline as to the level of knowledge required from the reader and user of
this design methodology, the author advises that the readers and users have an MCSE
certification in Windows 2000, or preferably in Windows Server 2003, with a strong
understanding of Active Directory and DNS concepts.

The following represent the target audience for this design methodology:

• IT consultants and architects required to work with and design Windows Server 2003
Active Directory solutions

• IT administrators within an organisation required to design Windows Server 2003 Active

Directory solutions, either alone, or in conjunction with external IT consultants and
architects

• All organisations intending to design and implement a Windows Server 2003 Active
Directory infrastructure to support a hundred or a few hundred thousand users

• IT students wishing to learn how to design a Windows Server 2003 Active Directory
infrastructure

2.4. How to Use this Design Methodology

To guide the reader in how to use this design methodology, this section answers and
discusses the following four questions:

1. What are the guiding design principals for this design methodology?

2. What are the foundations for the approaches within this design methodology?

3. Is it necessary to read and execute all plan, processes, components, and factors?

4. What is the required order for execution of the plans, processes, components, and
factors?

2.4.1. Guiding Design Principals for this Design Methodology

This design methodology is a reflection of the following three basic design principals:

1. “Keep it simple, and justify everything”

2. “Put aside all preconceptions”

3. “Be methodical and be consistent”

As discussed earlier, there is one primary and highly influential design principal for this design
methodology, which is to “keep it simple”. This design principal is pervasive throughout the
majority of processes within this design methodology. The statements of null hypotheses,
within the process approaches, reflect and reinforce this principal.

This design principal requires the reader to adopt a minimalist and conservative approach,
and only consider the design of an Active Directory component, or the selection of a variable
and value for that variable, where it is possible to justify these requirements. Justification of
these requirements is via compliance with defined business and technical criteria.

Hence, if, for example, an organisation is unable to identify any business or technical
requirements, reflected as criteria, for the design and configuration of a new Active Directory
feature, such as “Universal Group Caching”, then the design and implementation of this
feature is not justified. If the design and implementation of a feature is not justified, then it
serves not function within the Active Directory infrastructure, and hence is a superfluous
design component. If it is a superfluous design component, then it is a “bad” design.

Page 16 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

Hence, when executing a plan, process, component, or factor within this design methodology,
it is important to put aside all preconceptions about design requirements, which do not reflect
actual business or technical requirements. Do not fall into the common “trap” of spending time
(and hence money) on detailed analysis and design activities for a design component that is
not justifiable and hence not required, simply because it is “new” or “easy” to implement. This
may sound obvious, but it is, unfortunately, a very common practice due, predominantly, to
ignorance or a lack of consideration for the consequences (such as administrative and
financial overheads) associated with the designed and implemented feature.

This design methodology first requires the reader to put aside all preconceptions for design
requirements, based upon (for example) an existing (legacy) directory service infrastructure,
or “gut feelings”, before executing any of the processes within this design methodology. The
design of a Windows Server 2003 Active Directory infrastructure must reflect current and
future business and technical requirements. The design foundations for any legacy directory
infrastructures within an organisation reflect business and technical requirements determined
at the time of its design, and may be unable to support new requirements. This may also be a
factor in the business case to migrate to Windows Server 2003 Active Directory.

Hence, do not think, for example, that because an organisation has five Windows NT 4.0 or
five Windows 2000 domains currently, that they need five Windows Server 2003 Active
Directory domains, or the organisation only needs one Windows Server 2003 Active Directory
forest without considering all of the factors influential in the design of a multiple forest
infrastructure. For example, many organisations may need a minimum of two forests, where
one is the primary “production” forest, and the other is a parallel “test” forest. Just because
one is a “test” forest, does not preclude it from design and implementation, or justification from
design and implementation, especially where it is to represent a core component of a formal
change control infrastructure.

The design principal for this design methodology is to design the new Windows Server 2003
Active Directory infrastructure irrespective of preconceptions and the design for any existing
directory infrastructures, and only respective of current and future business and technical
requirements. Once the design for the new Windows Server 2003 Active Directory
infrastructure is in completed, it is then possible to determine, for example, how the
organisation is to migrate from the legacy directory infrastructure.

The final design principal, to be methodical and consistent, is pervasive throughout this
design methodology, and is probably the most noticeable. Each approach at the process and
individual factor level reflects this design principal, and requires the reader to execute the
approaches in a methodical and consistent manner.

Hence, when executing the processes within this design methodology, the reader will notice
attempts to slow things down. It is human nature to jump steps and jump to conclusions
based upon half the facts. However, generation of a design for a Windows Server 2003 Active
Directory infrastructure, which may ultimately represent and support an entire organisation
and continuity of the organisation, requires the use of a consistent, calculated, and methodical
approach. There is no room for mistakes in these types of projects, and hence this design
methodology requires the methodical execution of one small step at a time.

Although this may seem frustrating to the reader at times, this design methodology makes no
apologies, as it is imperative to the successful generation of a viable and justifiable design for
a Windows Server 2003 Active Directory infrastructure, which is the primary design objective
for most organisations.

2.4.2. Foundations for Design Methodology Approaches

It is possible to identify a significant number of variables associated with the generation of a

design for a Windows Server 2003 Active Directory infrastructure. It is also possible to identify
a significant number of approaches to execute analysis and design activities.

Page 17 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

However, during the design of this design methodology, the author has attempted to ensure
that the foundations for all approaches within this design methodology are “logic reinforced
and supported by experience”.

Please note that the onus is with the reader to independently evaluate and qualify all
approaches within this design methodology, and not blindly follow them. This is because
every organisation is unique, and hence every organisation has unique business and
technical requirements and objectives. Although the approaches within this design
methodology are designed using logic and experience as their foundations, it is technically not
possible to cater for all unique objectives and requirements, within all organisations.

2.4.3. Is It Necessary To Execute All Plans, Processes, Components, and Factors?

The simple answer to this question is no. Every organisation is unique, and hence every set of
business and technical requirements, and current and proposed production environments are
unique. As mentioned in the target audience section, this design methodology is required to
support organisations of all sizes and complexities. Hence, the majority of considerations may
or may not apply to an organisation for a reader.

Requirements to execute a plan, process, component, or factor, are dependent upon the
following:

• The compliance of an organisation with the prerequisites for the execution of a plan,
process, component, or factor

• The dependencies between plans, processes, components, and factors

Hence, to support the reader in determining the requirements to execute plans, processes,
components, and factors, this design methodology provides the following forms of guidance:

• The plans, processes, components, and factors all define criteria for execution. Hence,
only where the reader and organisation can identify compliance with the defined criteria is
it necessary to execute the plan, process, component, or factor.

• This design methodology provides information about the following dependencies:

♦ Inter-plan dependencies between plans within this design methodology

♦ Inter-plan dependencies between processes within the plans

♦ Intra-plan dependencies between processes within a plan

♦ Inter-component dependencies between components within a process

♦ Inter-factor dependencies between factors within a process

A later section in this chapter discusses these dependencies, in relation to the required order
for execution of the plans, processes, components, and factors.

It is important to note that the time it takes to execute most processes is simply a reflection of
the time it takes to read most of the factors within the process. Some factors within a process
are background factors, and hence just require reading and acknowledgement, or even
presentation and discussion during analysis workshops. Some analysis factors are very short
and it is possible to execute these factors within a few minutes, whilst other factors are
extremely long and complex and may take a few hours or more to execute.

As discussed in the earlier section, “design methodology anatomy”, although most processes
require mandatory execution, others are optional. The migration plan, which represents a
significant portion of this book, only requires execution where an organisation wishes to
design a migration from a legacy Windows-based domain infrastructure to the new Windows
Server 2003 Active Directory infrastructure, or the consolidation of two or more parallel

Page 18 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

Windows Server 2003 Active Directory infrastructures. Hence, where an organisation is to

design and implement a pristine Windows Server 2003 Active Directory infrastructure, with no
migration requirements, then this will significantly reduce the volume of analysis and design
activities.

Omission of optional processes may reduce the amount of work that requires execution. It is
even possible to execute these optional processes as post-implementation analysis and
design tasks, such as the design of custom ADPs, short-cut trust relationships, or directory
quotas.

2.4.4. What is the Required Order for Execution of Plans, Processes, Components, and
Factors?

The required order for execution of the plans, processes, components, and factors is a direct
reflection of the dependencies between them. Hence, before it is possible to explain the
required order for execution of the elements of this design methodology, it is necessary to
ensure the reader understands dependencies.

A dependency is a relationship between, for example, two or more components within a

process, where one or more components are dependent upon one or more other
components. Dependencies are a reflection of the ability to execute a dependent plan,
process, component, or factor.

For example, it may not be possible to execute a process within a plan, as it is dependent
upon the completion and results of another process within the same plan, or another plan.
Hence, only following completion of the all or specific activities within the “source dependent”
plan, process, component, or factor, it is possible to execute a dependent plan, process,
component, or factor.

Within the following example diagram, process “A” is the “source dependent” process for
processes “B” and “C”. Process “B” is the dependent process on process “A”, and the “source
dependent” process for process “C”. Process “C” is the dependent process on processes “A”
and “B”.

“Source Dependent” Dependent process (on process

process (for processes “A”) and “Source Dependent”
“B” and “C”) process (for process “C”)

Process “B”

Process “A”
Dependent process (on
processes “A” and “B”)
Process “C”
© 2004 MUSTANSHI R BHAR MAL

Figure 1.2: Example Illustration of Dependencies

Hence, to determine the required order for execution of these processes, it is necessary to
employ the following logic:

• It is not possible to execute processes “B” or “C” until the results of process “A” are
available, as they represent an input or an influential factor in the execution of its
dependent processes

• It is not possible to execute process “C” until the results of process “A” and process “B” are
available, as they both represent an input or an influential factor in the execution of this
dependent process

• Hence, it is necessary to execute process “A” first, then process “B”, and then process “C”.
This order of execution respects the observed dependencies.

Page 19 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

As mentioned earlier, it is possible to identify the following five types of dependencies within
this design methodology:

• Inter-plan dependencies between plans within this design methodology

• Inter-plan dependencies between processes within the plans

• Intra-plan dependencies between processes within a plan, also referred to as “inter-

process dependencies”

• Inter-component dependencies between components within a process

• Inter-factor dependencies between factors within a process

The following diagram illustrates these dependencies:

Plan (within Design Methodology) Plan (within Design Methodology)

Process (logically aligned Process (logically aligned Process (logically aligned Process (logically aligned
to a plan) to a plan) to a plan) to a plan)
Component (within a Component (within a Component (within a Component (within a
process) process) process) process)

Execute Execute Execute Execute Execute Execute

B1 B1 A1 B1 B1 A1
2
4
Component (within a Component (within a Component (within a Component (within a
process) process) process) process)

Execute Execute Execute Execute Execute Execute

A1 D1 D1 A1 D1 D1

3
LEGEND: Process (logically aligned Process (logically aligned
to a plan) to a plan)
1 Inter-Plan Dependency Component (within a
Execute
process)
B1
2 Inter-Plan Process Dependency Execute
B1 5
Execute
3 Inter-Process Dependency
A1
Component (within a
process)
4 Inter-Component Dependency Execute Execute Execute
A1 D1 D1
5 Inter-Factor Dependency
© 2 00 4 MUS T AN SH I R BHAR MAL

Figure 1.3: Illustration of Types of Dependencies within Design Methodology

2.4.4.1. Inter-Plan Dependencies between Plans within Design Methodology

It is very important to note that the logical grouping of processes into plans, and the order of
presentation of these plans within this book, does not strictly reflect the required order of
execution of the processes.

The following diagram illustrates the high-level inter-plan dependencies between the five
plans within this design methodology:

Page 20 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

Windows Server 2003 Active Directory Design

Methodology - Inter-Plan Dependencies
Migration
Plan

Organisation
-Wide Active
Forest Plan Domain Plan
Directory
Plan

Site Plan
© 2 0 0 4 MU ST ANS HI R BH ARMAL

Figure 1.4: Inter-Plan Dependencies between Plans within Design Methodology

The dependencies between these plans are a reflection of a logical flow for execution of these
plans, and the inter-plan dependencies of the majority of processes within each plan.

The above dependencies hence support the execution of the processes within plans in the
following order:

1. Organisation-Wide Active Directory Plan processes

2. Forest Plan processes

3. Site Plan processes

4. Domain Plan processes

5. Migration Plan processes

The order of presentation of these plans and their processes within this book reflects this
sequence. However, it is important to note that, in addition to the inter-plan dependencies
above, it is also possible to identify specific intra- and inter-plan dependencies between the
processes.

2.4.4.2. Inter-Plan Process Dependencies

It is important to respect the inter-plan dependencies, as these will dictate the order for
execution of the processes. The following table illustrates a few examples of significant inter-
plan dependencies between processes:

Plan for Source

Plan for
Dependent Source Dependent
Dependent Nature of Dependency
Process Dependent Process or
Process
Process Processes
Organisation- Design of DNS Forest Plan Determination Will influence the design of
Wide Active infrastructure of the number of the DNS namespace
Directory Plan domains infrastructure
required
Site Plan Design of Forest Plan Design of ADPs Require design of ADPs to
replication within a forest be completed prior to
topologies for generation of design for
ADPs replication topology

Page 21 of 22 Last printed 28/5/2004 11:48 a5/p5

 © 2004 Mustan Bharmal. All Rights Reserved.

Plan for Source

Plan for
Dependent Source Dependent
Dependent Nature of Dependency
Process Dependent Process or
Process
Process Processes
Forest Plan Selection and Domain Plan Raising the Knowledge of the required
raising of the functional level domain functional levels is
forest for this domain necessary prior to execution
functional level of any processes to raise the
functional level for the
corresponding forest
Organisation- Design of Migration Plan Analysis of The results of the analysis of
Wide Active object naming legacy domain existing legacy domain
Directory Plan models infrastructure(s) infrastructure(s) will influence
the requirements to redesign
existing object-naming
models

Table 1.1: Inter-Plan Dependencies between Processes within Design Methodology

The above inter-plan dependencies, between processes within different plans, are logical
dependencies. For example, it is not possible to design a replication topology for custom
ADPs where the requirements for the design of custom ADPs is not completed or initiated.

2.4.4.3. Inter-Process Dependencies within a Plan

The “introduction to <name_of_plan>” chapter, such as “Introduction to Organisation-Wide

Active Directory Plan”, illustrates the inter-process dependencies for the plan.

These hence guide the reader in the order for execution of the processes logically aligned to
each plan. Note that each process within a plan begins with a statement indicating the
requirements to execute that process.

2.4.4.4. Inter-Component Dependencies

Within each plan, the “inter-component dependencies” section of the “introduction to

<name_of_plan>” chapter for the plan, illustrates the intra-plan process dependencies, as
each process is a component of the plan.

These hence guide the reader as the logical order for execution of the components of a
process.

2.4.4.5. Inter-Factor Dependencies

Within each process, the “process map” (within the header “Process to <name_of_process>”)
reflects the inter-factor dependencies within the process. As mentioned earlier, the decision
points within these “process maps” reflect major factor execution decisions, and not the
“criteria for execution” of individual factors, and hence the onus is with the reader to ensure
compliance with the “criteria for execution” of each factor.

Page 22 of 22 Last printed 28/5/2004 11:48 a5/p5