Introduction to Windows Server 2003 Active Directory Design Methodology

© 2004 Mustan Bharmal. All Rights Reserved.

Table of Contents

1. INTRODUCTION................................................................................................................................. 22. HOW TO USE THIS DESIGN METHODOLOGY.......................................................................................32.1. DESIGN METHODOLOGY OBJECTIVES.............................................................................................32.2. DESIGN METHODOLOGY SCOPE.....................................................................................................42.3. BACKGROUND INFORMATION..........................................................................................................42.4. HOW TO USE THIS DESIGN METHODOLOGY..................................................................................16

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


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



2. How to Use this Design MethodologyPrior 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 ObjectivesIt 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



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



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:

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.

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

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)

FACTORS

Process (logically aligned to a plan)

Component (within a process)


ExecuteB1

ExecuteA1

ExecuteD1

© 2 0 0 4 M U S T A N S H I R B H A R M A L




ExecuteD1

ExecuteB1

ExecuteA1

Figure 1.1: Anatomy of this Design Methodology

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)

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)

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)

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

ExecuteB1

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

ExecuteA1 – 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:

ExecuteD1

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

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

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

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.

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

Process “A”

Process “B”

Process “C”

“Source Dependent” process (for processes

“B” and “C”)

Dependent process (on process “A”) and “Source Dependent”

process (for process “C”)

Dependent process (on processes “A” and “B”)


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.

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

to a plan)



ExecuteB1

ExecuteA1

ExecuteD1




ExecuteD1

ExecuteB1

ExecuteA1




ExecuteB1

ExecuteA1

ExecuteD1




ExecuteB1

ExecuteA1

ExecuteD1




ExecuteD1

ExecuteB1

ExecuteA1


ExecuteB1

ExecuteA1

ExecuteD1

1

2

3

4

5

LEGEND:

2

3

4

5

1 Inter-Plan Dependency

Inter-Process Dependency

Inter-Plan Process Dependency

Inter-Component Dependency

Inter-Factor Dependency

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:

Windows Server 2003 Active Directory Design Methodology - Inter-Plan Dependencies

Organisation-Wide Active

Directory Plan

Site Plan

Forest Plan Domain Plan

Migration Plan


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 Dependent

ProcessDependent

Process

Plan for Source

Dependent Process

Source Dependent Process or Processes

Nature of Dependency

Organisation-Wide Active Directory Plan

Design of DNS infrastructure

Forest Plan Determination of the number of domains required

Will influence the design of the DNS namespace infrastructure

Site Plan Design of replication topologies for ADPs

Forest Plan Design of ADPs within a forest

Require design of ADPs to be completed prior to generation of design for replication topology

Forest Plan Selection and raising of the forest functional level

Domain Plan Raising the functional level for this domain

Knowledge of the required domain functional levels is necessary prior to execution of any processes to raise the functional level for the corresponding forest

Organisation-Wide Active Directory Plan

Design of object naming models

Migration Plan Analysis of legacy domain infrastructure(s)

The results of the analysis of existing legacy domain 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.


Introduction to Windows Server 2003 Active Directory Design Methodology

Documents