Migration to AD 2003

© 2004 Mustan Bharmal. All Rights Reserved.

Table of Contents1. INTRODUCTION TO THE MIGRATION PLAN ............................................................................................. .......... 2 1.1. MIGRATION PLAN OBJECTIVES .................................................................................................... ............. 2 1.2. MIGRATION PLAN SCOPE ....................................................................................................................... . 2 1.3. BACKGROUND INFORMATION ........................................................................................... ......................... 3 1.4. MIGRATION PLAN APPROACH ............................................................................................................ ....... 5 1.5. MIGRATION PLAN PROCESSES ................................................................................................ ................. 6 1.6. DELIVERABLES OF MIGRATION PLAN PROCESSES .................................................................. ....................... 6 1.7. INTER-PROCESS DEPENDENCIES ...................................................................................... ........................ 7 1.8. PROCESS TO CREATE THE MIGRATION PLAN ............................................................................... ................ 8 2. ANALYSIS OF LEGACY DOMAIN INFRASTRUCTURE(S) .......................................................................... .............. 9 2.1. PROCESS OBJECTIVES .................................................................................................................. ......... 9 2.2. PROCESS SCOPE ......................................................................................................... ........................ 9 2.3. BACKGROUND INFORMATION ........................................................................................... ......................... 9 2.4. PROCESS APPROACH ........................................................................................................................... .. 9 2.5. PROCESS COMPONENTS .................................................................................................................. ..... 10 2.6. DELIVERABLES OF PROCESS COMPONENTS ..................................................................................... .......... 10 2.7. INTER-COMPONENT DEPENDENCIES ........................................................................................................ . 10 2.8. PROCESS TO ANALYSE LEGACY DOMAIN INFRASTRUCTURE(S) .................................................................. ...... 11 2.9. PROCESS CONSIDERATIONS ........................................................................................................... ........ 11 3. UNDERSTANDING SUPPORTED MIGRATION PATHS ............................................................................. ............. 35 3.1. BACKGROUND INFORMATION ........................................................................................ .......................... 35 3.2. PROCESS OBJECTIVES ................................................................................................................ ......... 35 3.3. PROCESS COMPONENTS .................................................................................................................. ..... 36 3.4. PROCESS TO UNDERSTAND SUPPORTED MIGRATION PATHS .......................................................... ................ 36 3.5. PROCESS CONSIDERATIONS .................................................................................................................. . 36 4. DETERMINATION OF REQUIRED MIGRATION STRATEGY .................................................................... ................ 71 4.1. PROCESS OBJECTIVES ................................................................................................................ ......... 71 4.2. PROCESS SCOPE ...................................................................................................... ......................... 71 4.3. BACKGROUND INFORMATION ........................................................................................ .......................... 71 4.4. PROCESS APPROACH ........................................................................................................................ ... 75 4.5. PROCESS COMPONENTS .................................................................................................................. ..... 78 4.6. DELIVERABLES OF PROCESS COMPONENTS ..................................................................................... .......... 78 4.7. INTER-COMPONENT DEPENDENCIES ........................................................................................................ . 79 4.8. PROCESS TO DETERMINE THE REQUIRED MIGRATION STRATEGY ........................................................ ............ 79 4.9. PROCESS CONSIDERATIONS .................................................................................................................. . 79 5. DESIGN OF THE REQUIRED MIGRATION PATH(S) ............................................................... .......................... 112 5.1. PROCESS OBJECTIVES ...................................................................................................... ................. 112 5.2. PROCESS SCOPE .......................................................................................................................... .... 112 5.3. BACKGROUND INFORMATION ............................................................................................................ ..... 112 5.4. PROCESS APPROACH ............................................................................................................... .......... 118 5.5. PROCESS COMPONENTS ........................................................................................................ ............. 119 5.6. DELIVERABLES OF PROCESS COMPONENTS ........................................................................... .................. 119 5.7. INTER-COMPONENT DEPENDENCIES ............................................................................................... ........ 119 5.8. PROCESSES TO DESIGN THE REQUIRED MIGRATION PATH(S) ...................................................... ................ 120 5.9. PROCESS CONSIDERATIONS ................................................................................................................ . 121 6. DESIGN OF MIGRATION SCHEDULE AND COMMUNICATIONS PLAN ............................................. ....................... 435 6.1. PROCESS OBJECTIVES .............................................................................................................. ......... 435 6.2. BACKGROUND INFORMATION ...................................................................................... .......................... 435 6.3. PROCESS APPROACH ...................................................................................................................... ... 435 6.4. PROCESS COMPONENTS ................................................................................................................ ..... 436 6.5. DELIVERABLES OF PROCESS COMPONENTS ................................................................................... .......... 436 6.6. INTER-COMPONENT DEPENDENCIES ...................................................................................................... . 436 6.7. PROCESS TO DESIGN THE MIGRATION SCHEDULE AND COMMUNICATIONS PLAN ............................. .................. 436 6.8. PROCESS CONSIDERATIONS ................................................................................................................ . 436

of 446 Last printed 27/7/2004 10:54 a7/p7


1. Introduction to the Migration Plan

Execute the processes within this Migration Plan only where it is possible to identify compliance with the following basic criteria:

• It is possible to identify the presence of one or more legacy Windows NT 4.0 or Windows 2000 directory service infrastructures within the logical boundaries of this organisation, and

• There is a requirement to design and execute the migration of one or more of these legacy domain infrastructures to the new Windows Server 2003 Active Directory infrastructure for the organisation.

Where it is not possible to identify compliance with the above criteria, then there is no requirement to generate a Migration Plan.

Where it is possible to identify the requirement to generate a Migration Plan, then note that this design methodology stipulates that a single “Migration Plan” will support the execution of all migration tasks. This will hence include all migration tasks to migrate from each existing in-scope legacy Windows NT 4.0 domain and Windows 2000 Active Directory infrastructure to the new Windows Server 2003 infrastructure for this organisation.

1.1. Migration Plan Objectives

The objectives of the “Migration Plan” are to assist an organisation in the generation of a design for a plan that will support only those components of this project associated with the migration from one or more Windows domain infrastructures to a new Windows Server 2003 Active Directory infrastructure.

1.2. Migration Plan Scope

As only one migration plan is required for the entire project, the scope of this migration plan includes the following:

• The migration requirements for all existing Windows-based domain infrastructures within the organisation that fall within the scope of this migration plan (the Migration Plan process “analysis of legacy domain infrastructures” will define the migration scope)

• All Windows Server 2003 domains and forests within the Windows Server 2003 Active Directory infrastructure for the organisation that have domain creation dependencies upon the migration of the legacy domains and domain infrastructures.

As there is a plethora of excellent information available on the migration to Windows Server 2003 Active Directory from legacy Windows domain infrastructures, this design methodology will assist an organisation in the design of a migration plan with only a limited technical perspective. The technical scope, as a strict reflection of the domain or directory service perspective, hence stipulates that the following aspects of a migration from one or more legacy domain infrastructures be inside and outside of the scope of this migration plan:

1.2.1. In-Scope Components

Only the following components and aspects of a migration from one or more legacy domain infrastructures are within the scope of the Migration Plan:

• The design of a migration plan to migrate from the following legacy domain infrastructures to the new Windows Server 2003 Active Directory infrastructure:

♦ From Windows NT 4.0 domain infrastructures (single domains, single master domain models, multiple master domain models)

♦ From Windows 2000 directory service infrastructures (single domains, multiple domain trees, multiple forests)



• The migration of directory service components of each in-scope legacy domain infrastructure, and not the migration of other components listed below as out of scope.

• The execution of inter-forest or intra-forest migration exercises to consolidate superfluous Windows Server 2003 domains / forests into one or a fewer number of Windows Server 2003 domains / trees / forests within the organisation where:

♦ The in-place upgrade of one or more legacy Windows NT 4.0 and / or Windows 2000 domain infrastructures generated the superfluous Windows Server 2003 domains / trees / forests, or

♦ The execution of consolidation exercises legacy Windows NT 4.0 and / or Windows 2000 domain infrastructures generated the superfluous Windows Server 2003 domains / trees / forests.

1.2.2. Out-of-Scope Components

This design methodology does not provide support for any other components and aspects typically associated with a migration from one or more legacy domain infrastructures to a Windows Server 2003 Active Directory infrastructure that do not comply with the above in-scope criteria. This hence includes, for example, the following components as been outside of the scope of this migration plan:

• The migration of member servers and clients operating legacy Windows operating systems (Windows 2000 or earlier)

• The migration of applications, services, resources on member servers and clients within each in-scope legacy domain infrastructure

• The migration of other directory service infrastructures within an organisation to the new proposed Windows Server 2003 Active Directory infrastructure, such as legacy Microsoft Exchange 5.5 infrastructures

• The migration of infrastructure services (DNS, WINS, DHCP, and so on) operating within the legacy domain infrastructures (note that the design of a migration from a legacy / existing DNS infrastructure is supported by the Organisation-Wide Active Directory Plan process “design of a DNS infrastructure”)

• The execution of gap analysis for legacy domain controller server hardware (this is supported by the Domain Plan process “design for domain controllers”)

• The requirements to migrate from the following third party network operating system infrastructures:

♦ Novell NetWare platforms

♦ Unix and Linux platforms

♦ Apple Macintosh platforms

♦ IBM OS/2 platform

• The deployment of all “non-migration dependent” aspects and components of the new designed Windows Server 2003 Active Directory infrastructure

1.3. Background Information

Presented within the following three sections are the background information considerations for this Migration Plan:

1. Understanding the migration plan prerequisites



2. Understanding the migration plan concepts and terminology

1.3.1. Understanding the Migration Plan Prerequisites

This design methodology stipulates that it is necessary to have a full understanding of the target Windows Server 2003 Active Directory infrastructure for all potential legacy domain infrastructures prior to the design of their migration plan.

Hence, the prerequisites to the execution of the processes within this Migration Plan are completion of the following design plans:

• Completion of the Organisation-Wide Active Directory Plan for the target Windows Server 2003 Active Directory infrastructure

• Completion of the Forest and Site Plan for each target Windows Server 2003 Active Directory forest

• Completion of the Domain Plan(s) for each required target Windows Server 2003 domain

1.3.2. Understanding the Migration Plan Concepts and Terminology

This design methodology will discuss and present considerations to support the following concepts and terminology associated with the migration of legacy domain infrastructures to a Windows Server 2003 Active Directory infrastructure:

• The concept of phases within a migration project

• The concept of migration plans, paths, and schedules

Prior to understanding the concepts listed above, it is important to understand the following terminology used within this Migration Plan:

• The term “legacy” refers to all previous versions of software (operating systems, programs and so on) from the same independent software vendor (ISV). For example, Windows NT 4.0 is the preceding (and hence legacy) version of operating system to Windows 2000, which in turn is the preceding version of operating system to Windows Server 2003.

• The term “third party” refers to all versions of software (operating system, programs, and so on) from ISVs other than Microsoft, such as Novell, Sun, Apple, and so on.

• For this migration plan, this design methodology implies that the term “migration” to refer to the “movement of directory service objects and data” from one or more legacy domain infrastructures to a new Windows Server 2003 Active Directory infrastructure. Based upon any of the methods this design methodology will provide considerations for, to assist an organisation in the design for the migration of the directory objects and data, it is possible to execute the movement of directory objects and data via:

♦ The in place upgrade of a legacy domain infrastructure, or

♦ The inter-forest migration of directory objects and data from one or more legacy domain infrastructures to a Windows Server 2003 Active Directory infrastructure

♦ The intra-forest moving of directory objects and data from one or more Windows 2000 domains to other Windows 2000 domains in the same forest, or Windows Server 2003 domains to other Windows Server 2003 domains in the same forest

♦ The export and import of directory data, such as policies, registry settings, and so on

See the step “supported migration paths” within the process “Understanding supported migration paths” for details of the definition of the term “migration”, with respect to migration paths supported by this design methodology.



This design methodology recognises the following phases and associated high-level activities within any migration project:

• Pre-migration phase, with which the following activities are associated:

♦ The execution of detailed analyses to identify the legacy domain infrastructures that will provide the scope for this migration plan

♦ The determination of the business and technical goals and drivers for the migration from each in-scope legacy domain infrastructure to the new Windows Server 2003 Active Directory infrastructure

♦ The determination of the design requirements for the plan to support the migration of each in-scope legacy domain infrastructure

♦ The design of the migration plan for the organisation

♦ The testing of all custom design concepts in the migration plan within a proof-of-concept laboratory environment

♦ The execution of all pre-migration tasks and activities to prepare the pilot and production environments for execution of the migration phase

• Migration phase, with which the following activities are associated:

♦ The pilot execution of design migration plans to effect the migration of one or more legacy domain infrastructures to the new pilot production Windows Server 2003 Active Directory infrastructure

♦ The execution of ongoing management tasks to support both legacy and new pilot production environments for the duration of the migration phase. Note that this phase may last from a few days to many months, depending upon the size and complexity of the source and target environments.

• Post-migration phase, with which the following activities are associated:

♦ The execution of all remaining migration tasks

♦ The execution of all post-migration tasks and activities to, for example, decommission redundant legacy domain infrastructures, and so on

A migration plan consists of the following five primary components:

1. A migration path for each in-scope legacy domain infrastructure, to support its migration from its current state to the new Windows Server 2003 Active Directory infrastructure

2. A coexistence plan to support coexistence during the migration phase

3. A contingency plan to support the rollback of a failed migration

4. A migration schedule to co-ordinate the execution of all identified migration paths during the migration phase

5. A migration communications plan to support the distribution of information about the migration project to appropriate users within the organisation.

1.4. Migration Plan Approach

The primary intentions of the approach proposed by this design methodology within this Migration Plan are to ensure the entire migration process will succeed with minimal risk to business continuity and project timescales and overheads. The migration plan approach must



hence consider and acknowledge all aspects of a migration, from one or more legacy domain infrastructures to a new Windows Server 2003 Active Directory infrastructure, which can influence the success of this requirement.

It may be possible for an organisation to identify the requirements to migrate from one or from more than one legacy Windows NT 4.0 and / or Windows 2000 domain infrastructures. The design of a single Migration Plan must hence support all migration requirements from each legacy Windows-based directory service infrastructure to the new Windows Server 2003 Active Directory infrastructure.

Hence, this design methodology proposes the following approach for the generation of the Migration Plan:

1. Execute an analysis of legacy infrastructures to determine the following:

a. The number of legacy domain infrastructures currently operating within the logical boundaries of the organisation

b. The identification of the migration scope for this migration plan

2. Understand all of the migration paths supported by this design methodology

3. Determine the required strategy for the migration of each legacy domain infrastructure to the new Windows Server 2003 Active Directory infrastructure

4. Determine the business and technical drivers and goals for the migration of each in-scope legacy infrastructure to the new Windows Server 2003 Active Directory infrastructure.

5. Select a migration path for each in-scope legacy domain infrastructure, that complies with the migration strategy and goals

6. Determine the design requirements for each required migration path, and generate the appropriate design

7. Determine the design requirements for the migration schedule and communications plan, and generate the appropriate design

1.5. Migration Plan Processes

Based upon the defined objectives and approach, this migration plan is composed of the following five processes:

• Execution of analyses on existing legacy domain infrastructures

• Understanding supported migration paths

• Determination of the migration strategy and goals, and selection of migration path(s)

• Design for each required migration path

• Design of the migration schedule and communications plan

1.6. Deliverables of Migration Plan Processes

The migration plan processes will have the following deliverables:

• Identification of the number of legacy domain infrastructures currently operating within the logical boundaries of the organisation

• Determination of the in-scope legacy domain infrastructures that require migration to the new Windows Server 2003 Active Directory infrastructure



• An understanding of all migration paths supported by this design methodology

• Determination of the required strategy for the migration of the legacy domain infrastructures to the new Windows Server 2003 Active Directory infrastructure

• Determination of the business and technical drivers and goals for the migration from each legacy domain infrastructure

• Selection of the required migration path for each in-scope legacy domain

• Determination of the design requirements for each required migration path

• Generation of the design for each required migration path

• Determination of the design requirements for the migration schedule and communications plan

• Generation of the design for the migration schedule and communications plan

1.7. Inter-Process Dependencies

Each process within the Migration Plan will have the following inter-process dependencies:

Migration Plan – Inter-Process Dependencies for Migration Plan

START

Determination of required migration

strategy, goals, and path(s)

Analysis of legacy domain infrastructure(s)

Understanding supported migration

paths

Design of required migration path(s)

Design of migration schedule &

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

The following diagram illustrates how each of these five processes within the migration plan depends and builds upon the results of the previous process:

DETERMINATION OF MIGRATION STRATEGY

UNDERSTANDING SUPPORTED MIGRATION PATHS

DESIGN OF REQUIRED MIGRATION PATH(S)

DESIGN OF MIGRATION SCHEDULE & COMMUNICATIONS PLAN

ANALYSIS OF LEGACY DOMAIN INFRASTRUCTURES

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

Figure 40.1: Migration Plan Process Dependencies



1.8. Process to Create the Migration Plan

Migration Plan – Process to Create the Migration Plan

ENDExecute process

“design of migration schedule &

communications plan”

Execute process “design of required migration path(s)”

START

Execute process “analysis of legacy

domain infrastructure(s)”

Execute process “Understanding

supported migration paths”

Execute process “determination of

required migration strategy, goals, and

path(s)”




2. Analysis of Legacy Domain Infrastructure(s)

The first stage in any migration plan is to identify and analyse the legacy domain infrastructure(s) that require migration to the new Windows Server 2003 Active Directory infrastructure, and determine the scope of the migration plan.

2.1. Process Objectives

The objectives of this process are to assist the organisation in the execution of the following analysis tasks:

• Identification of all existing legacy domain infrastructures within the logical boundaries of the organisation

• Identification of the legacy domain infrastructures that require inclusion within the scope of this migration plan

• Execution of a detailed analysis into each in-scope domain infrastructure

2.2. Process Scope

The following define the scope for this process:

• The logical boundaries for the organisation

• The presence and absence of legacy Windows NT 4.0 and Windows 2000 directory service infrastructures within the logical boundaries of the organisation

• The identity, current, and future function(s) of each identified in-scope legacy domain infrastructures


The results from the execution of this process are prerequisites to the initiation and completion of the remaining processes within this Migration Plan.

Within most organisations that currently support legacy Windows domain infrastructures, it may be possible to identify multiple instances of these infrastructures. For example, where an organisation has grown via mergers and acquisitions, or supports numerous autonomous divisions, it may be possible to identify multiple instances of Windows NT 4.0 and / or Windows 2000 directory service infrastructures across the entire organisation.

Note within this process that all references to “legacy infrastructure” or “legacy domain infrastructure” denote Windows NT 4.0 and / or Windows 2000 directory service infrastructures only.

2.4. Process Approach

To reflect the defined objectives for this process, this design methodology proposes the following approach towards the execution of this process:

1. Determine the presence of all existing production (and not test) Windows NT 4.0 and / or Windows 2000 directory service infrastructures within the logical boundaries of the organisation.

2. Where it possible to identify the presence of multiple legacy infrastructures and where an organisation is unsure which legacy infrastructures require migration, execute the following:

a. Determine the criteria to support the selection of legacy infrastructure(s) that require migration



b. Evaluate all identified legacy infrastructure(s) against the defined criteria to identify the in-scope legacy infrastructures for the migration plan

3. Execute a detailed analysis against each in-scope domain to identify the following information:

a. The details of the logical and physical design for each in-scope domain

b. The details of replication topology for each in-scope domain

c. The details of the primary directory service query profiles

d. The configuration details for each domain controller within each in-scope domain

e. The total (current) numbers of directory objects within each in-scope domain

f. The details of the current object and resource management infrastructures within each in-scope domain

g. The details of the current disaster recovery infrastructure for each in-scope domain

h. The details of the current backup and restore infrastructure for each in-scope domain

i. The details of the current security policies and operations for each in-scope domain

j. The details of any formal and / or informal directory service change control infrastructures for each in-scope domain

2.5. Process Components

Based upon the above approach, this process is composed of the following components:

• Identification of existing legacy infrastructures operating within the production environment for the organisation that require migration to the new Windows Server 2003 Active Directory infrastructure

• Determination of the migration scope for the migration plan

• Execution of a detailed analysis against each in-scope legacy domain

2.6. Deliverables of Process Components

This process will have the following deliverables:

• The identification of the presence of all existing legacy domain infrastructure operating on the production environment for the organisation

• The identification of the scope of the migration plan, representing all legacy infrastructures that require migration to the new Windows Server 2003 Active Directory infrastructure

• A detailed analysis of each in-scope legacy domain

2.7. Inter-Component Dependencies

Each component within this process will have the following inter-component dependencies:



Migration Plan – Inter-Component Dependencies for Process to Analyse Legacy Domain Infrastructure(s)

START

Identification of the existing legacy

infrastructures that require migration

Determination of the scope of the migration

plan

Execution of a detailed analysis of each in-

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

2.8. Process to Analyse Legacy Domain Infrastructure(s)

Migration Plan – Process to Analyse Legacy Domain Infrastructure(s)

STARTExecute

B1

Execute

A3

Does the organisation know

exactly which legacy infrastructures

require migration?

YES

YESExecute

A1 – A2

Execute

B2

Execute

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

END

2.9. Process Considerations

Consider the following information when executing this process to analyse existing legacy domain infrastructures.

Presented within the following three sections are the considerations for this process:

1. Considerations for the identification of existing legacy domain infrastructures that require migration

2. Considerations for the determination of the scope of the migration plan

3. Considerations for the execution of a detailed analysis of each in-scope domain

2.9.1. Identification of Existing Legacy Domain Infrastructure(s) that Require Migration

Consider the following when generating an audit of all existing legacy domain infrastructures within the organisation to identify the migration candidates:

• Factor A1: Defining the search scope for legacy infrastructures

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Is unsure of the number of legacy domain infrastructures that operate within the organisation and require migration, and

Wishes to define the search scope for legacy domain infrastructures

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

Within most small to medium sized organisations, it is very simple to identify one or more legacy domain infrastructures that operate within the boundaries of the organisation. However, in most medium to large size organisations, it may be harder to ascertain the exact number and details of the legacy domain infrastructures currently operating within their production environment, especially where the organisation complies with one or more of the following criteria:



The organisation employs a decentralised administration model

The organisation has no strict policies on the implementation and operation of Windows domain infrastructures on the production environment

The organisation has grown significantly in a few years via mergers and acquisitions

The organisation supports mergers and acquisitions, temporarily or permanently, as autonomous divisions within the organisation

Where it is possible to identify compliance with one or more of the above criteria, then it is necessary to establish the boundaries and scope for the investigation.

When attempting to define the search scope, consider the following:

The nature and function of the organisation may influence the number of legacy Windows domain infrastructures operating within the production environment, which require migration. For example, within a large ISV that does not implement any strict policies to control the implementation of legacy Windows domain infrastructures, it may be possible to identify many hundreds or even thousands of legacy Windows domains. This is because, for example, the software developers may establish their own independent “production” domains to generate secure development environments, and so on. Although, in this example, the majority of these domains may be outside of the scope of the migration plan, it is necessary to identify all existing domains, prior to determination of the scope.

This design methodology proposes the following approach to define the search scope for legacy domain infrastructures within the organisation:

Identify all divisional structures operating within the logical boundaries of the organisation that currently or will require representation within the new Windows Server 2003 Active Directory infrastructure.

Define the logical boundaries of each in-scope divisional structure as components of the search scope for legacy domain infrastructures.

Use the above information and approach to define and document the search scope for legacy domain infrastructures within the organisation that may require migration to the new Windows Server 2003 Active Directory infrastructure.

• Factor A2: Identification of legacy domain infrastructures


Is unsure of the number of legacy domain infrastructures that operate within the organisation and require migration to the new Windows Server 2003 Active Directory infrastructure

Has defined the search scope for legacy domain infrastructures, and

Wishes to identify all legacy domain infrastructures that may require migration to the new Windows Server 2003 Active Directory infrastructure for the organisation


When executing an analysis to identify the legacy domain infrastructures that require migration to the new Windows Server 2003 Active Directory infrastructure, this design methodology proposes the following approach:



Execute an analysis to identify all legacy domain infrastructures operating within the defined search scope and on the production environment. Initially class all identifiable legacy (Windows NT 4.0 and Windows 2000) domain infrastructures operating on the production environment as potential candidates for migration (via removal and consolidation) to the new Windows Server 2003 Active Directory infrastructure(s).

Define criteria to qualify and substantiate appeals and requirements to exclude any identified legacy domain infrastructures from migration. Note that the onus is with the organisation to define these criteria. However, this design methodology provides the following example criteria to justify the retention and exclusion from migration of a legacy domain infrastructure:

The identified legacy domain infrastructure is classable as a “production” domain, not simply because it resides on the production network, but because it supports business processes. The removal of this legacy domain infrastructure may hence compromise business continuity, as the new Windows Server 2003 Active Directory infrastructure cannot support the current dependent business processes.

The legacy domain infrastructure employs the (currently) supported Windows 2000 operating system and does not rely upon the Windows NT 4.0 operating system, as Microsoft no longer supports this legacy operating system (at the time of publication of this methodology).

The legacy domain infrastructure will continue to reside within the scope of support of the centralised IT department for the organisation, where applicable.

The legacy domain infrastructure does not support any requirements for migration, such as representing a source for objects that require retention and use within the new Windows Server 2003 Active Directory infrastructure. For example, it is possible to exclude this domain from migration without compromising business continuity as:

• The legacy domain infrastructure can be simply decommissioned without migration, and

• Users and computers assigned new accounts, group memberships, permissions, and so on.

The retention of the legacy domain infrastructure, in its current or proposed state, will not impede or detrimentally influence the design, implementation, and operation of the new Windows Server 2003 Active Directory infrastructure.

Evaluate all identified legacy domain infrastructures against the defined exclusion criteria and generate a list of potential candidate infrastructures for migration to the new Windows Server 2003 Active Directory infrastructure.

Using the above information and approach, execute the following:

Identify all legacy domain infrastructures residing within the search scope on the production environment for the organisation

Define and document the criteria to qualify and substantiate appeals to retain identified legacy domain infrastructures

Determine and document the list of legacy domain infrastructures that potentially require migration to the new Windows Server 2003 Active Directory infrastructure



2.9.2. Determination of the Migration Scope

Consider the following when determining the migration scope for each identified in-scope legacy domain infrastructure:

• Factor B1: Understanding the components of the migration scope


Has identified one or more legacy domain infrastructures that qualify for migration to the new Windows Server 2003 Active Directory infrastructure, and

Wishes to understand the components of the migration scope that will require determination


It is important to note that when determining the migration scope for this migration plan, it is necessary to define the scope from the following two aspects:

Identification of the legacy domain(s) that require migration to a new Windows Server 2003 Active Directory infrastructure

Identification of the new proposed Windows Server 2003 domains that require exclusion from the migration scope for this migration plan

The migration scope for this migration plan hence defines the following:

The domains within the migration scope, represented by:

The source legacy Windows NT 4.0 domains that require migration to the new Windows Server 2003 Active Directory infrastructure

The source legacy Windows 2000 domains that require migration to the new Windows Server 2003 Active Directory infrastructure

The new target Windows Server 2003 domain(s) to receive directory objects and / or directory data from one or more legacy Windows NT 4.0 and / or Windows 2000 domains

The domains outside of the migration scope, represented by:

The existing legacy Windows NT 4.0 domains that do not require migration to the new Windows Server 2003 Active Directory infrastructure

The existing legacy Windows 2000 domains that do not require migration to the new Windows Server 2003 Active Directory infrastructure

The new target Windows Server 2003 domains not to receive any directory objects and data from any existing legacy Windows NT 4.0 and / or Windows 2000 domain (such as dedicated placeholder domains for Windows Server 2003 Active Directory forests, or test domains within a parallel test forest, and so on)

Note that the migration scope must contain, as a minimum, the following domains:

One or more legacy Windows NT 4.0 and / or Windows 2000 domains

One or more target Windows Server 2003 domains



Without the presence of a source or target domain, then is not possible and there is hence no migration plan.

The following diagram illustrates the domain components of the migration scope:

OUTSIDE of MIGRATION SCOPE

INSIDE OF MIGRATION

SCOPE

Windows NT 4.0Domain

NT4 PDCNT4 BDC

Windows 2000Domain

W2K DC

Windows Server 2003 Domain

W2K3 DC

Windows 2000Domain

W2K DC W2K DC


NT4 PDCNT4 BDC


W2K3 DC

OUTSIDE of MIGRATION SCOPE


Figure 41.1: Example of Components of a Migration Scope

Where an organisation has only a single legacy domain infrastructure, then this single domain may represent the “source domain” scope element of the migration plan.

However, where an organisation has identified the presence of multiple legacy domains, then it is necessary to identify those domains that require inclusion within the scope of this migration plan, and those that require exclusion.

The migration scope defines all of the components, contents, and aspects of a legacy domain infrastructure that will require inclusion, and hence consideration, in the migration plan and hence migration to the new Windows Server 2003 Active Directory infrastructure.

Note that it is not necessary, at this stage in the migration plan, to determine a detailed understanding of the scope for this migration plan. The analysis to determine the design requirements for each required migration path will determine the directory clean up tasks for each in-scope domain, and hence the detailed migration scope.

Hence, at this stage, it is only necessary to determine the following high-level components of the scope for this migration plan:

Where an organisation has identified one or more existing Windows NT 4.0 domain infrastructures, then it is necessary to identify entire legacy Windows NT 4.0 domains

Where an organisation has one identified one or more existing Windows 2000 Active Directory infrastructures, then it is necessary to identify, where appropriate, the following:

Entire legacy Windows 2000 Active Directory domains as been within the scope of the migration plan

Entire trees of Windows 2000 Active Directory domains as been within the scope of the migration plan



Entire Windows 2000 Active Directory forests as been within the scope of the migration plan

Where an organisation has identified the requirement for the design of one or more target Windows Server 2003 domains, then it is necessary to identify, where appropriate, the following:

Entire Windows Server 2003 domains as been within the scope of the migration plan

Entire trees of Windows Server 2003 domains as been within the scope of the migration plan

Entire Windows Server 2003 Active Directory forests as been within the scope of the migration plan

• Factor A3: Determination of the scope for the migration plan


Has identified one or more legacy domain infrastructures that qualify for migration to the new Windows Server 2003 Active Directory infrastructure, and

Has identified one or more target Windows Server 2003 domains that qualify to receive directory objects and / or data from one or more legacy domains, and

Wishes to determine the scope for the migration plan, as Windows NT 4.0, Windows 2000, and Windows Server 2003 domains, where appropriate


Inclusion of a legacy Windows NT 4.0 and / or Windows 2000 domain and new target Windows Server 2003 domain within the scope of the migration plan will hence demand the execution of the following:

Selection of a migration path for the legacy domain, to support its direct or indirect migration to a target Windows Server 2003 domain

Design of the selected migration path for the legacy domain

Inclusion of the legacy domain within the scope of the migration schedule and communications plan

Execution of the migration tasks for the legacy domain, using the designed migration path

The selection of a legacy domain for inclusion within the scope of the migration plan hence generates a significant number of dependent activities, which require time and resources to execute. The criteria for the inclusion of a legacy domain within the scope of this migration plan must hence reflect these adjunct requirements.

This design methodology proposes the following approach to define the high-level scope for this migration plan:

Define the criteria for the inclusion of an identified existing legacy Windows NT 4.0 and / or Windows 2000 domain within the scope of this migration plan



Evaluate each identified legacy Windows NT 4.0 and / or Windows 2000 domain against the defined criteria and identify the in-scope source domains for this migration plan

Define the criteria for the inclusion of required Windows Server 2003 domains within the scope of this migration plan

Evaluate each required Windows Server 2003 domain against the defined criteria and identify the in-scope target domains for this migration plan.

When determining the criteria for the inclusion of legacy Windows NT 4.0 and Windows 2000 domain(s) within the scope of this migration plan, consider the following:

The criteria must exclude, for example, the following types of legacy domains:

All legacy domains that do not contain any directory objects and data necessary within the new Windows Server 2003 Active Directory infrastructure

All legacy domains that will not serve any viable function, in their current or upgraded state, in the new Windows Server 2003 Active Directory infrastructure

The criteria must include all legacy domains that directly or indirectly support mission critical business processes and applications. The exclusion of these domains from the scope of migration may result in a significant disruption to business continuity.

It is important not to immediately discount existing legacy domains designed to operate as “test” domains, as they may have a viable role within the new Windows Server 2003 Active Directory infrastructure. For example, an organisation has designed and deployed a test domain infrastructure, which exactly duplicates their production environment, to represent an integral component of a formal change control infrastructure. The migration to Windows Server 2003 Active Directory does not negate the requirement for the use of a parallel test domain infrastructure and the change control infrastructure, and hence this test domain infrastructure is within the scope of this migration plan.

When determining the criteria for the inclusion of one or more new target Windows Server 2003 domains within the scope of this migration plan, consider the following:

The criteria must exclude, for example, the following types of target Windows Server 2003 domains:

All new domains that do not require any directory objects and data currently present within one or more legacy Windows NT 4.0 and / or Windows 2000 domain infrastructures

All new domains that will not provide any production services in the new Windows Server 2003 Active Directory infrastructure, such as test domains in a parallel test forest, and so on

The criteria must include all new domains that will directly, or indirectly, support mission critical business processes and applications via the use of directory objects and data currently present within the legacy domain infrastructure. The exclusion of these target Windows Server 2003 domains from the scope of migration may result in a significant disruption to business continuity.

Using the above approach and information, execute the following:

Define and document the criteria for the inclusion of legacy Windows NT 4.0 and / or Windows 2000 domains within the scope of this migration plan



Evaluate all identified legacy domains against the defined criteria and identify the source legacy domains within the scope of this migration plan

Define and document the criteria for the inclusion of new target Windows Server 2003 domains within the scope of this migration plan

Evaluate all required Windows Server 2003 domains against the defined criteria and identify the target domains within the scope of this migration plan

2.9.3. Execution of Detailed Analysis of Each In-Scope Source Domain Infrastructure

Consider the following information when executing a detailed analysis of each legacy source domain and domain infrastructure within the scope of this migration plan:

• Factor B2: Understanding the scope for the detailed analysis


Has identified one or more legacy Windows NT 4.0 and / or Windows 2000 domains for inclusion within the scope of this migration plan, and

Wishes to understand the scope for detailed analysis against each in-scope legacy domain


It is necessary to execute a detailed analysis of each identified legacy domain, within the scope of this migration plan, as the results of this analysis will directly influence the execution of the following processes and tasks within this migration plan:

Determination of the migration strategy

Determination of the migration goals

Selection of the migration path(s)

Design of the required migration path(s)

Design of the migration schedule

Design of the migration communications plan

This design methodology proposes that the detailed analysis for each in-scope domain will determine, where appropriate to each type of in-scope legacy domain, the following information:

The current logical and physical design for each in-scope legacy domain

The replication topology for each in-scope legacy domain

The primary directory service query profiles for each in-scope legacy domain

Configuration details for each domain controller within each in-scope domain

The directory objects within each in-scope domain

The current object and resource management infrastructures within each in-scope domain



The current disaster recovery infrastructure for each in-scope domain

The details of the current backup and restore infrastructure for each in-scope domain

The details of the current security policies and operations for each in-scope domain

The details of any existing formal and / or informal change control infrastructures for each in-scope domain

• Factor A4: Determination of the details of the current logical and physical design for each in-scope legacy domain


Has identified one or more legacy Windows NT 4.0 and / or Windows 2000 domains within the scope of this migration plan, and

Wishes to execute a detailed analysis to determine the details of the current logical and physical design for each in-scope legacy domain


Selection of the migration path for an in-scope legacy domain is dependent upon a number of factors, including the details of the current logical and physical design for the domain.

When determining the details of the logical and physical design of an in-scope legacy domain, consider the following:

This design methodology proposes that the following aspects of the logical design for a legacy domain require detailed analysis:

Determination of the high-level function(s) of the domain, such as a Windows NT 4.0 account or resource domain, or a test domain, and so on.

Determination of the relationship(s) (if any) with other legacy in-scope domains via trusts (internal (between Windows 2000 domains in an existing forest) and external trust relationships)

The mode (for Windows 2000 domains) of the domain (mixed or native mode)

The architecture of the network protocol(s) (such as TCP/IP) that support the domain, its domain controllers, member computers, and so on

The infrastructure services to support name resolution within the domain (such as DNS and WINS)

This design methodology proposes that the following aspects of the physical design for a legacy domain require detailed analysis:

Determination of the number of domain controllers within each domain, and the role(s) of each domain controller, such as:

• In Windows NT 4.0 domains: PDC and BDCs

• In Windows 2000 domains: FSMO role holders, directory replication bridgehead servers for inter-Site replication, and Global Catalog servers



Determination of the physical locations where the domain is represented within the boundaries of the organisation

The physical network infrastructure that supports the domain, its domain controllers, and member computers


Determine and document the listed logical design aspects for each in-scope legacy domain

Determine and document the listed physical design aspects for each in-scope legacy domain

• Factor A5: Determination of the details of the replication topology for each in-scope legacy domain


Has identified one or more legacy Windows NT 4.0 and / or Windows 2000 domains within the scope of this migration plan where two or more domain controllers for that domain are located in different physical locations within the organisation

Can identify the presence of a directory replication topology between domain controllers within these domains, and

Wishes to execute a detailed analysis to determine the details of the replication topology for each in-scope legacy domain


It is important to understand the current replication topology for each in-scope legacy domain distributed and represented across multiple physical locations, connected by WAN links. This information is critical to the determination of the migration strategy and goals, and the selection and design of the migration path for the domain.

Understanding the current replication topology will assist in the identification of replication requirements that require maintenance during the migration and coexistence phases of this project.

When determining the design details of the current replication topology for a legacy Windows NT 4.0 domain, consider the following:

There are very few parameters available to configure and control replication between Windows NT 4.0 domain controllers across WAN links. The parameters that require analysis are:

The “ReplicationGovernor” parameter

The “Pulse” parameter

The “PulseMaximum” parameter

The “ReplicationGovernor” parameter defines both the size of the data transferred on each call to the primary domain controller (PDC) and the frequency of those calls. Adjusting the ReplicationGovernor parameter works in two ways:

It reduces the size of the buffer used on each call from the BDC to the PDC, ensuring that a single call does not occupy the WAN link for too long, and



It causes NetLogon essentially to "sleep" between calls, allowing other applications to access the WAN link between calls to the PDC

Configuration and use of the “ReplicationGovernor” parameter on remote BDCs requires the execution of the following on the BDC:

Creation of the REG_DWORD registry value “ReplicationGovernor” within the “HKML\\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters” registry key

Population of this “ReplicationGovernor” value with an integer number between nought and one hundred (the default is 100). This value defines a percentage for both the amount of data transferred on each call to the PDC and the frequency of those calls

When determining the details of the “ReplicationGovernor”, consider the following:

As this replication configuration parameter requires manual generation and configuration on each BDC, it is necessary to inspect the registry on each remote BDC for a legacy domain, and record the value for this parameter.

Depending upon the nature and bandwidth statistics of a WAN link, some organisations design processes to vary the value for the “ReplicationGovernor” parameter according to a fixed schedule. This is possible via the scheduled execution of a batch file (using, for example, Regini.exe) that modifies this registry value and its data. It is hence necessary to identify the presence of any such batch files and their execution schedules.

The PDC of a domain employs the “Pulse” parameter to control the frequency of transmissions of the “pulse” to BDCs. BDCs receive a “pulse” notification from a PDC informing them of the requirements to replicate with the PDC. A BDC that is up to date with directory changes will not receive a pulse notification from the PDC. Increasing the Pulse parameter on the PDC reduces the number of replications between the PDC and the BDCs, and hence slower propagation of changes in the SAM to the BDCs.

Configuration and use of the “Pulse” parameter on the PDC requires the execution of the following on the PDC for the domain:

Creation of the REG_DWORD registry value “Pulse” within the “HKML\\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters” registry key

Population of this “Pulse” value with an integer number between 60 and 172,800 representing the pulse interval in seconds (the default is 300 seconds, which is 5 minutes).

The value of the “Pulse” parameter is typically set to greater than one hour (3600 seconds).

The “PulseMaximum” parameter defines the maximum pulse frequency, in seconds. Every BDC will receive at least one mandatory pulse, at this defined frequency, regardless of whether the SAM database on that BDC is up to date with the PDC. Increasing the “PulseMaximum” parameter hence reduces the minimum frequency with which a PDC will send a pulse to its BDCs.

Configuration of the “PulseMaximum” parameter on the PDC requires the execution of the following on the PDC for the domain:

Creation of the REG_DWORD registry value “PulseMaximum” within the “HKML\\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters” registry key



Population of this “Pulse” value with an integer number between 60 and 86,400 representing the minimum pulse interval in seconds (the default is 7,200 seconds, which is 2 hours).

When analysing Windows NT 4.0 replication between domain controllers, it is also important to determine the details for the LAN Manager Replication Service (LMRepl). In most domains, the PDC is the export server, exporting files within its NETLOGON share to the NETLOGON share on the BDCs for the domain. Most Windows NT 4.0 domains use this share and replication service to replicate logon scripts for users to all BDCs within the domain, and hence providing a single point of management (on the PDC) for these files and scripts. It is also common practice to use the LAN Manager Replication Service to replicate entire directories between the export server (typically the PDC) and BDCs and even to member servers in the domain. Windows Server 2003 domain controllers cannot support BDCs using the LAN Manager Replication Service, as it uses the File Replication Service (FRS) and the SYSVOL volume. Hence, there is a requirement to maintain and possibly relocate this “LMRepl” service (depending upon the selected migration path) during the migration and coexistence phases of this project.

Using the Server Manager tool, select the PDC for the domain, open the Directory Replication dialog box and document the following details for this service:

The export path(s) (if not the default “%systemroot”\System32\Repl\Export”)

The list of target BDCs (and even member servers) for the replication

The logon script path (if not the default “%systemroot”\System32\Repl\Import\Scripts”)

It is important to gather the following details of the WAN infrastructure that connect all remote BDCs for a domain with the PDC:

The type(s) of WAN links currently in use (dial up ISDN, ADSL, Frame Relay, ATM, and so on)

The levels of guaranteed bandwidth within these link by the service provider(s), and burst handling capacities, and so on

The SLAs provided for the these links by the service provider(s)

The topology for the WAN infrastructure, detailing the assigned cost values for links, metrics, redundancy pathways, and so on

A graph illustrating the pattern and fluctuations in levels of available bandwidth within these network links during a typical working week (midnight Monday to midnight Saturday)

When determining the design details of the current replication topology for a legacy Windows 2000 domain, consider the following:

Replication between Windows 2000 domain controllers is considerably more configurable than between Windows NT 4.0 domain controllers. As the concepts and configuration parameters for inter-domain controller replication in Windows 2000 and Windows Server 2003 are very similar, there is no requirement to reiterate this information here. Refer to the “Site Plan” for more details of the replication parameters between Windows 2000 domain controllers.

Prior to the migration of a legacy Windows 2000 domain, it is import to analyse and document all details of the FRS within each domain. FRS, unlike the LMRepl service in Windows NT 4.0, only supports replication between domain controllers, and not with member servers, as only domain controllers host the SYSVOL volume.



Prior to determination of the details of a Windows 2000 FRS implementation, consider the following:

Unlike the LMRepl service, the FRS:

• Provides a configurable schedule for inter-Site replication of the SYSVOL volume and Distributed File System (DFS) content

• Is a multi-threaded and multi-master service, allowing updates to the contents of the SYSVOL volume at all domain controllers

• Is Site aware (although the concepts of Sites is not found in Windows NT 4.0)

• Will automatically replicate all attributes of files and folders in the SYSVOL volumes, including ACLs and their ACEs

Note that, unlike inter-Site replication of the Active Directory, there is no compression of the data within the SYSVOL volume prior to transmission between Sites. Hence, most organisations may limit the volume of data held within the SYSVOL volumes, to control the impact on the network for inter-Site replication. FRS will use the automatically generated connection objects, and their schedules, for intra-Site and inter-Sire replication between domain controllers.

Within the Active Directory Users and Computers MMC snap-in, it is possible to configure the following properties of the FRS:

• A directory filter to exclude the replication of directories via the FRS

• A file filter to exclude the replication of files via the FRS

• A schedule for the replication of the domain system volume on the DFS root, which has a default schedule set as Sunday through Saturday from 12 AM to 12 AM. Note that this schedule governs inter-Site replication between servers or domain controllers and intra-Site replication for DFS replica sets. Intra-Site replication for SYSVOL occurs automatically.

The following configuration parameters for the FRS must be determined:

• The location and contents of the SYSVOL volume on all domain controllers within a legacy Windows 2000 domain

• Any modifications to the default location for the FRS log files. There may be a requirement to distribute disk activity on the domain controllers, and hence place the FRS log files on a separate partition, spindle, or under the control of another disk controller / channel. To determine the location of the FRS log files on the local disk storage, inspect the registry value “Debug Log File”, as a file path, in the registry key “HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters”.

• Any requirements to disable logging of the FRS service to, for example, reduce disk activity. To determine whether logging of the FRS service is disabled, inspect the registry value “Debug Disable”, as a data value of 1, in the registry key “HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters”.

• Any modifications to the default size of the staging directory. The staging space limit governs the maximum amount of disk space that FRS can use to hold staging files. Upon reaching this limit, inbound replication pauses until it is possible to recover space by replicating one or more staging files to all



outbound partners. To identify any modifications to the default size of the staging directory, inspect the registry value “Staging Space Limit in KB”, in the registry key “HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters”.

It is important to gather the following details of the WAN infrastructure that connect all remote domain controllers for a Windows 2000 domain with each other:

The type(s) of WAN links currently in use (dial up ISDN, ADSL, Frame Relay, ATM, and so on)

The levels of guaranteed bandwidth within these link by the service provider(s), and burst handling capacities, and so on

The SLAs provided for the these links by the service provider(s)

The topology for the WAN infrastructure, detailing the assigned cost values for links, metrics, redundancy pathways, and so on

A graph illustrating the pattern and fluctuations in levels of available bandwidth within these network links during a typical working week (midnight Monday to midnight Saturday)


Determine and document the directory and file replication topology and configuration parameters for each in-scope Windows NT 4.0 domain

Determine and document the directory and file replication topology and configuration parameters for each in-scope Windows 2000 domain

• Factor A6: Determination of the details of the primary directory service query profiles for each in-scope legacy domain



Wishes to execute a detailed analysis to determine the details of the primary directory service query profiles for each in-scope legacy domain


“Directory service query profiles” refers to the applications and process, currently operating within the legacy domain environment, which generate queries against the existing domain directory service. The objectives of the queries are to retrieve directory data from a legacy Windows NT 4.0 and / or Windows 2000 domain infrastructure.

This design methodology requires the identification of only the primary query profiles, distinguished from all other applications and processes that generate directory service queries by the following example criteria (note that the onus is with the organisation to define their own criteria for the identification of the primary directory service query profiles):

The applications or processes are mission critical to the organisation, and hence the organisation has a very low tolerance for any disruption to their normal operation.



The applications or processes typically (currently and historically) generate the most frequent directory service queries that request the highest volume of directory data.

When determining the details of all directory service query profiles, retrieve the following information:

Determine and document the source of the directory service queries to the legacy Windows NT 4.0 SAM database and / or Windows 2000 domain (as applications, processes, batch files, scripts, and so on)

Determine and document the nature and content of the directory service information required by the application or process

Determine and document the mode of access employed by the application or process to retrieve the required information from a domain controller in a legacy domain, identifying, for example, the protocols, such as LDAP, the tools, and APIs used and targeted.

Determine and document the volume of directory service data requested, and the frequency of generation of the queries by the applications or processes

Determine and document the logical and physical location of the source of the directory service queries

Determine and document the current and proposed requirements to route directory service queries across WAN links within the organisation

Determine and document the target domain controller(s) for the queries generated by the applications or processes, and any particular functions or roles necessary for the target domain controllers, such as GC servers, or bridgehead servers, and so on.

Determine and document the level of tolerance the organisation has to any disruption in the generation and retrieval of the directory data by these applications, processes, scripts, and so on.

Determine and document the potential impact of the domain migration, to a Windows Server 2003 Active Directory infrastructure, on the continuity of these applications, processes, scripts, and so on

Determine and document any requirements to decommission, upgrade, or replace the current applications, processes, scripts that generate directory service queries. Where it is possible to identify any plans to upgrade or replace a current application or process, then determine the changes, if any, on the generation and retrieval of directory service data by these applications or processes.

• Factor A7: Determination of the configuration details for each domain controller within each in-scope legacy domain



Wishes to execute a detailed analysis to determine the configuration details for each domain controller within each in-scope legacy domain




Prior to the execution of any migration activities against an in-scope legacy Windows NT 4.0 and / or Windows 2000 domain, it is imperative to document all of the configuration details for each existing domain controller within the domain.

This is necessary regardless of the specific inclusion or exclusion of actual existing domain controllers within the scope of migration, as this information is essential to the design and execution of a disaster recovery plan.

This design methodology requires the retrieval of the following configuration information from each existing domain controller within each in-scope legacy Windows NT 4.0 and / or Windows 2000 domain:

Determine and document the total number of existing domain controllers within each in-scope legacy Windows NT 4.0 and / or Windows 2000 domain

Determine and document the following hardware configuration details for each identified existing domain controller:

The server model and OEM

The server BIOS version

The details of the following server hardware components:

• CPU (version, type, specifications, numbers)

• RAM (type, amount, specifications)

• Hard disks (type, number, size, free disk space, speed, configuration, partitions, file system, distribution on RAID array card channels, and so on)

• Network Interface Cards (NICs) (type, number, teaming configuration (for performance or redundancy), and so on)

• RAID array cards (type, number of channels, model, firmware version, and so on)

• Other server extensions, such as “remote lights out boards”, and so on

The feasibility for upgrades to the above hardware components on the existing domain controllers

Determine and document the following operating system configuration details for each identified existing domain controller:

The version of operating system (such as Windows NT 4.0 Server Standard or Enterprise edition, Windows 2000 Server Standard or Advanced edition, secure edition (SE) versions of operating system (for government and military organisations), and so on)

The current service pack version, and Microsoft-supplied post service pack host fixes and patches

Any custom operating system configurations and patches from Microsoft, third party ISVs, or in-house developers

The presence of two or more hardware startup profiles on the domain controllers, and the configuration of the profiles



The details of the services running on the domain controller, identifying service accounts used to start services, the startup profiles of services, association of services with hardware profiles, and so on

The file shares available and advertised on the domain controllers, the function and content of each identified file share, and the permissions assigned to each identified share

The distribution of the following elements of the operating system and directory service on the hard disks for the domain controller:

• The operating system and pagefile

• The SAM database / NTDS database, and log files

• The NETLOGON / SYSVOL volumes

The presence and configuration details of any infrastructure services hosted by the domain controllers, such as WINS, DNS, DHCP, and so on

The details of all other applications hosted by the domain controllers, such as SQL Server, Exchange Server, and so on

The details of all other functions and roles hosted by the domain controllers, such as file and print servers, intranet web servers, database servers, messaging servers, Global Catalog servers, bridgehead replication servers, FSMO-role holders, and so on.

• Factor A8: Determination of the details of directory objects within each in-scope legacy domain



Wishes to execute a detailed analysis to determine the details of the directory objects within each in-scope legacy domain


The determination of the details of the directory objects within a legacy Windows NT 4.0 and / or Windows 2000 domain is essential to the design and execution of this migration plan.

The following table lists the types of directory objects (where appropriate to the version of legacy domain) that require inclusion within the scope of analysis:

Directory ObjectsFound in

Windows NT 4.0 domains

Found in Windows

2000 domains

User account objects

InetOrgPerson account objects 1

Computer account objects

Security Group objects



Directory ObjectsFound in

Windows NT 4.0 domains

Found in Windows

2000 domains

Distribution Group objects

Contact objects

Organizational Unit (OU) objects

Print queue objects

Shared folder objects

ForeignSecurityPrincipal objects (in the “CN=ForeignSecurityPrincipals,DC=<domain_name>” container)

Active Directory Group policies and Group Policy Objects (GPOs)

Custom System objects (objects within the “CN=system,DC=<domain_name>” container)

Custom objects within the Configuration partition (in the “CN=Configuration,DC=<domain_name>” container) such as DFS domain root (Active Directory integrated) objects, and so on.

Custom Site objects (objects within the “CN=Sites,CN=Configuration,DC=<domain_name>” container) such as Active Directory Sites, Site Link objects, Site Link Bridge objects, custom connection objects, TCP/IP subnets, and so on.

Custom extensions to the Active Directory Schema (new object classes / attributes)

Table 41.1: Directory Objects for Inclusion within the Scope of Analysis

1Following the extension to the Schema for a Windows 2000 forest to add the inetOrgPerson object class, via use of the Microsoft “Windows 2000 inetOrgPerson Kit”

This design methodology requires the retrieval of the following information about the directory objects within each in-scope legacy domain:

Determine and document the total numbers of the identified object types within each in-scope domain

Determine and document the logical and physical distribution of the objects within the legacy domain and the organisation, where appropriate to the objects types

Determine and document the high-level function(s) and description of the objects within the legacy domain

It is important to note that all directory objects require analysis, regardless of their individual inclusion or exclusion from the migration scope for the legacy domain.

• Factor A9: Determination of the details of the current object and resource management infrastructures within each in-scope legacy domain





Wishes to execute a detailed analysis to determine the details of the current object and resource management infrastructures within each in-scope legacy domain


Prior to the migration of each legacy Windows NT 4.0 and / or Windows 2000 domain, it is necessary to understand and document the components of the object and resource management infrastructures within the domains.

For legacy Windows NT 4.0 domains, an object and resource management infrastructure is comprised of the following components:

The user, computer, and custom security group objects that require management within the legacy domain

The strategy and process to manage user profiles and home folders

A security group infrastructure

The resources that require access control, and the permissions assigned to security principals

The Windows NT 4.0 system policies used to manage users and computers within the domain

For legacy Windows 2000 domains, an object and resource management infrastructure is comprised of the following components:

The Active Directory objects that require management within the legacy domain

The strategy and process to manage user profiles and home folders

A Group Policy Object (GPO) infrastructure

A Delegation of Control (DOC) infrastructure

A security group infrastructure

An Organizational Unit (OU) infrastructure

The resources that require access control, and the permissions assigned to security principals

When determining the details of each identified object and resource management infrastructure within a legacy Windows NT 4.0 and / or Windows 2000 domain, consider the following:

It is necessary to identify the administration model for the legacy domain, and categorise the model as one of the following:

Logically centralised, physically centralised (one administration team for the domain, with all administration executed from one geographical location for the organisation)

Logically centralised, physically distributed (one administration team for the domain, with administration executed from two or more geographical locations for the organisation)



Logically decentralised, physically centralised (two or more administration teams for the domain, with all administration executed from two or more geographical locations for the organisation)

Logically decentralised, physically decentralised (two or more administration teams for the domain, will administration executed from two or more geographical locations for the organisation)

Determine and document the details of each identifiable component of the object and resource management infrastructure for each legacy domain, and identify the current strategies employed for object and resource management.

Identify and document all aspects of the current object and resource management infrastructure deemed unsatisfactory by the organisation, based upon, for example, functionality, manageability, financial and administrative overheads, and so on.

• Factor A10: Determination of the details of any current disaster recovery infrastructure for each in-scope legacy domain



Wishes to execute a detailed analysis to determine the details of any current disaster recovery infrastructure for each in-scope legacy domain


The presence of a disaster recovery infrastructure for a legacy domain will represent a significant influence in the selection of a migration path, and design of a disaster recovery plan for the migration.

This design methodology regards a good disaster recovery infrastructure as typically comprising, at a minimum, all of the following components:

One or more nominated physical locations for the disaster recovery (DR) of a production domain (which may single-function locations dedicated to disaster recovery, or multi-function locations)

A documented and tested disaster recovery procedure, supporting the following:

The criteria for the execution of the DR procedure

A DR procedure for recovery of hardware failure

A DR procedure for recovery of operating system failure

A DR procedure for recovery of application or service failure

A schedule for the execution of DR drills to ensure all administration personnel are aware of the procedures and their specific duties, commensurate to their roles within the IT administration team

One or more spare “standby” servers or server hardware components in each nominated DR location

A scripted installation for a standard server build, or an image of a standard server build in each nominated DR location



Access to all relevant components of a domain backup infrastructure from each nominated DR location

Access to all updated design documentation of the legacy domain and its domain controllers from each nominated DR location

Most organisations do not invest in an internal disaster recovery infrastructure and are thus unable to identify all of the above components for a “DR infrastructure”. However, a few organisations will be able to identify at least two or more of the above components.

Where it is possible to identify a DR infrastructure, comprising of all or most of the above components, then execute an analysis of this infrastructure to determine and document the following:

The number of single-function (dedicated to DR) and multi-function physical locations for each in-scope legacy production domain, which represent “DR locations”

The details of the DR infrastructure within each nominated location (such as Windows NT 4.0 BDCs or additional Windows 2000 domain controllers, and so on)

The number of times in the last 12 months the organisation has had to execute a full or partial DR for a production (legacy) domain

• Factor A11: Determination of the details of the current backup and restore infrastructure for each in-scope legacy domain



Wishes to execute a detailed analysis to determine the details of the current backup and restore infrastructure for each in-scope legacy domain


The majority of organisations running production Windows NT 4.0 and / or Windows 2000 domains have invested in a backup and restore infrastructure for the domains.

Determination of the details of the supporting backup and recovery infrastructure for a legacy domain is crucial to the design and execution of a disaster recovery procedure for a domain migration.

This design methodology regards a good backup and restore infrastructure as typically comprising, at a minimum, all of the following components:

A network tape juke box library (that automatically changes and labels tapes), or another form of reliable data storage infrastructure, such as a SAN solution

A suitable third party backup application from a trusted ISV

A dedicated backup network infrastructure, using a dedicated LAN / WAN, or fibre channel

A documented and tested backup procedure and schedule for execution of the backups



A documented, tested, and regularly executed procedure for the monitoring and management of the backup infrastructure

A documented procedure for the escalation of backup and recovery issues within the IT administration team

An offsite media storage location for each geographical location where a domain is represented by domain controllers, and an infrastructure to transport the media to the remote location on a daily or other regular basis

A document and tested recovery procedure, and a schedule to regularly test the backup media and backups

Where it is possible to identify a backup and recovery infrastructure, comprising of all or most of the above components, then execute an analysis of this infrastructure to determine and document the following:

The backup schedule(s) for the domain controllers, identifying the backup windows for each domain controller

The typical volume of data backed up on each domain controller, and the type of backup performed (normal, copy, incremental, or differential) at each scheduled execution

The details of the backup infrastructure (backup software used (ISV and version of software), media used to store backup, use of a SAN solution, documented procedures for backup and recovery, and so on)

The identification of all dependent processes and infrastructure components for the successful scheduled execution of the backup processes, such as:

The requirements for the manual changing and labelling of backup tapes

The requirements for the manual packing and transportation of the previous nights back up tapes to a remote physical location, and so on

The details of all instances of failures in any component of the current backup infrastructure within the last 12 months, such as the failure of IT administrators to notice a backup was not completing, or the failure for a backup to initiate, and so on.

• Factor A12: Determination of the details of the current security policies and operations for each in-scope legacy domain



Wishes to execute a detailed analysis to determine the details of the current security policies and operations for each in-scope legacy domain


Within most organisations contemplating the migration from one or more legacy domains to a new Windows Server 2003 Active Directory infrastructure, maintenance of security operations is a key component of their migration strategy and goal. Hence, knowledge of the details of the security infrastructure is essential for compliance with the migration strategy and goals.



This design methodology regards a good security and operations infrastructure as comprising, at a minimum, all of the following components:

Documented baseline security standards and levels for all domain controllers and member servers within a legacy domain, and a procedure for security hardening each new server introduced to the domain

Documented procedures for the maintenance of the required security standards levels on all domain controllers and member servers within a legacy domain, such as the procedures to deploy and check security hot fixes for the operating system and applications, updates for antivirus software, and so on.

Documented procedures for the execution of all steps to handle a security breach to the domain and organisation, ranging from identification and stabilisation of a breach, through to containment and rectification.

A detailed design and implementation to ensure the physical security of the servers, such as access control to the server rooms, and so on

A detailed design and implementation to ensure the network security of the servers, such as the use of network encryption protocols, restrictions on access to the corporate network infrastructure, and so on

Within most medium to large sized organisations, a dedicated administration team manages security, and it is typically possible to identify significant investments into these infrastructures.

Where it possible to identify a security and operations infrastructure for a legacy Windows NT 4.0 and / or Windows 2000 domain, then execute an analysis to determine and document the following:

The details of the security operations and strategy for each in-scope legacy domain

The details of each security breach to each legacy production domain within the last 12 months, and the lessons learned from management of the breach.

Identify all potential areas for improvement in the current operation, reliability, and execution of the security and operations infrastructure.

• Factor A13: Determination of the details of any existing formal and / or informal change control infrastructures for each in-scope legacy domain



Wishes to execute a detailed analysis to determine the details of any existing formal and / or informal change control infrastructures for each in-scope legacy domain


Change control infrastructures within an organisation, for directory service operations, provide stability assurance for the production domain(s). A change control infrastructure is essential for the execution of a few pre-migration tasks, such as implementation of a freeze on change control (see later), and to control the migration process itself.

This design methodology regards a good change control infrastructure as comprising, at a minimum, all of the following components:



A test domain infrastructure, which duplicates the production domain infrastructure, in an isolated laboratory environment, to support the testing and evaluation of all submitted directory service change requests

The presence of a solution to ensure the automated or manual synchronisation of all in-scope elements of the production domain with the corresponding elements in the parallel test domain, such as a directory integration solution, employing a metadirectory product, to synchronise the directories

A documented procedure and supporting infrastructure for the:

Generation and submission of directory service change requests

Evaluation and testing of submitted directory service change requests

Approval and implementation of submitted directory service change requests, or

Rejection of submitted directory service change requests

Most organisations employ an informal or formal change control for directory service operations. Where it is possible to identify such an infrastructure supporting a legacy in-scope domain, then execute an analysis to determine and document the following:

Determine the nature of the change control infrastructure, as been formal or informal. An informal change control infrastructure is not supported by documented procedures, and supporting infrastructure, such as an intranet web site as the portal to submit change requests, and so on.

Determine the details of the process or solution employed by the organisation to ensure the synchronisation of specific or all elements of the production domain with a parallel test domain.

Identify any issues, associated with the use of the formal or informal change control infrastructure within the organisation, raised within the previous 12 months.



3. Understanding Supported Migration Paths

As the intention of this migration plan is to support all potential migration goals and requirements, to take one or more Windows NT 4.0 and / or Windows 2000 domains to a new Windows Server 2003 Active Directory infrastructure, it is necessary for this plan to support multiple migration paths.

This process details all of the migration paths that this design methodology supports via the provision of considerations and approaches for design.


Prior to understanding the migration paths supported by this design methodology, it is necessary to understand the following concepts:

• Definition of “support” for a migration path by this design methodology

• Concept of a migration path

• Definition of the term “migration”

• Migration methods supported by this design methodology

This design methodology employs the term “support” (for a migration path) as it encompasses the following:

• Identification of “recommended” migration paths

• Provision of all considerations and steps to design the “recommended” migration paths (support for the migration path)

A migration path is, essentially, a process to execute a migration from a legacy domain to a Windows Server 2003 domain / domain infrastructure. This design methodology hence translates the term “migration”, for the purposes of this migration plan, to imply the logical movement of directory objects and data from a legacy domain infrastructure to a Windows Server 2003 domain infrastructure, via any of the supported methods to execute the migration.

Supported methods to execute the migration include:

• An in-place upgrade of a legacy domain

• The cloning or duplication of directory objects and data from a legacy domain to a new parallel Windows Server 2003 domain, or

• The moving of directory objects between domains in the same Active Directory forest

Note it is possible to recreate manually all existing directory objects and data, currently residing within a legacy domain, within a new parallel Windows Server 2003 domain. This “method” is not supported by this design methodology as it is only applicable a minority of organisations. For the majority of organisations, this “method” is inefficient and may generate significant errors in “migration”.


The objectives of this process are hence to assist an organisation in understanding all of the migration paths supported by this design methodology, to migrate one or more legacy Windows NT 4.0 and / or Windows 2000 domains to a Windows Server 2003 Active Directory infrastructure.




This process is composed of the following components:

• A presentation of the migration paths supported by this design methodology

• A presentation of the features and scenarios for use of each supported migration path

• A presentation of the supported upgrade paths for legacy Windows NT 4.0 and Windows 2000 Server operating systems to Windows Server 2003

3.4. Process to Understand Supported Migration Paths

Migration Plan – Process to Understand Supported Migration Paths

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

ENDExecute

B1 – B13


Consider the following information when executing this process to understand the migration paths supported by this design methodology, and the operating system upgrades paths supported by Microsoft.

Presented within the following three sections are the considerations for this process:

1. Supported migration paths

2. Understanding the features of each supported migration path

3. Understanding the supported upgrade paths for legacy Windows Server operating systems

3.5.1. Supported Migration Paths

Consider the following information to understand the differences between each proposed and supported migration path to migrate Windows NT 4.0 and Windows 2000 domains to the new Windows Server 2003 Active Directory infrastructure:

• Factor B1: Understanding the different supported paths for the migration of Windows NT 4.0 and Windows 2000 domain infrastructures to Windows Server 2003 Active Directory

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the objectives of this step to identify the different available migration path options to migrate a legacy Windows NT 4.0 and / or Windows 2000 domain infrastructure to a Windows Server 2003 Active Directory infrastructure.


The objective of this step is to provide the foundation for the execution of the remaining steps within this process. This step will only provide a high-level overview of the following:

The components of a migration path

The different migration paths currently available and supported by this design methodology



The execution of the later step, “determination of the required migration strategy”, will provide the details for each of the migration paths supported by this design methodology.

This later step will use the defined migration goals (identified during the next step) to decide and select the most appropriate migration paths to support the migration of each in-scope legacy domain and domain infrastructure.

• Factor B2: Understanding the migration path concepts

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concepts of migration paths to migrate a Windows NT 4.0 or Windows 2000 domain infrastructure to a Windows Server 2003 Active Directory infrastructure.


When attempting to understand the different migration paths available, it is important to understand the following concepts of migration paths:

A migration path is composed of two components:

The first component of a migration path is the actual path or route itself that will provide the process to migrate the contents of one or more legacy domains / domain infrastructures to one or more target Windows Server 2003 domains / OU infrastructures. Each supported migration path may identify mandatory and optional pre-migration, migration, and post-migration tasks.

Migration applications, application suites, tools, and other utilities, which will support the execution of all or some of the mandatory and / or optional tasks defined by a migration path, represent the second component of a migration path. Note that the selected migration path will determine whether this component is optional or mandatory.

Each supported migration path has a defined scope and objective. It is very important to understand the scope and objectives of a migration path, as they will dictate the scope and objectives of the pre-migration, migration, and (most importantly) the post-migration tasks.

When attempting to understand the concepts of the scope and objectives of a migration path, consider the following:

As it is possible to assign the term “migration” several different meanings, and confuse migration with deployment, this design methodology provides the following definition of the term “migration”, from the perspective of a migration path:

“The actual or logical transition (via upgrade, moving, or cloning methods) of specific aspects and components of one Windows-based domain to another Windows-based domain via the execution of:

• The minimum pre-migration tasks necessary to support and achieve the domain migration / transition AND prepare for the subsequent execution of a deployment plan, and

• The minimum and specific “migration” and “post-migration” tasks mandatory to ONLY support domain migration / transition”

Please note the following about this definition:



Any activities that do support this definition, are not mandatory to achieve “migration”, and do not directly support “migration” are not “migration activities”, but “deployment activities”. For example, the in-place upgrade of a PDC, and subsequent execution of the Active Directory Installation Wizard on the upgraded Windows Server 2003 server, will create a new Windows Server 2003 domain. This is migration. The subsequent upgrade of existing BDCs in the original domain, or the addition of new Windows Server 2003 domain controllers to the new domain is not mandatory to achieve or support “migration”, and hence these are “deployment activities”, which are within the scope of a Deployment Plan.

However, it is important to note that a deployment plan requires execution immediately after migration. Hence, it would be irresponsible for this design methodology not to guide an organisation in the preparation for deployment (where necessary) and migration during design of the migration plan. The pre-migration tasks for each supported migration path hence provide guidance on the design of processes to prepare a source and target domain for migration and deployment, where appropriate, but only from the directory service perspective.

The selected migration path(s) themselves will dictate what domain aspects and components are specifically “transitioned” between domains, and how the “migration” or “transition” occurs (see later for details), and hence define the scope of “migration”.

All migration paths have a defined list of supported deliverables, and it is possible to execute each migration path independently of other migration paths to achieve just the defined deliverables.

An organisation may select multiple migration paths to support the migration of multiple domains. Each required instance of a migration path exists to support a source domain and not the target domain. For example, an organisation identifies the requirement for the design and execution of inter-forest migration path “D” to clone directory objects from a source Windows 2000 domain.

However, there is a requirement to distribute the directory objects across three target Windows Server 2003 domains. Because there is only one source domain, there is a requirement to design one instance of this migration path.

All migration paths, which support a migration from a Windows NT 4.0 and / or Windows 2000 domain to a Windows Server 2003 Active Directory infrastructure, have a foundation based upon one of the following three approaches towards a migration:

A domain upgrade approach

An inter-forest domain migration and consolidation approach, or

An intra-forest migration approach (see below for details of these three foundation approaches for all migration paths)

Some migration paths are modular and it is hence possible to conglomerate two or more migration paths into one large extended migration path. Using this approach, the output (deliverables) for one migration path may represent the input for another migration path, and hence it is possible to chain the execution of multiple paths to achieve the desired results.

For example, it is possible to execute a migration path to perform upgrades of legacy domains followed by the consolidation of the upgraded domains to, for example, a single Windows Server 2003 domain.

Some migration paths include migration tasks only indirectly related to the actual migration, but represent an essential step in the migration path. For example, the pre-



migration tasks to consolidate multiple account or resource Windows NT 4.0 domains, and so on.

Each migration path supported by this design methodology has one or more prerequisites that require compliance prior to design and execution of the path. The later step within this process, to assist an organisation in the selection of the required migration path(s), will provide details of these prerequisites.

• Factor B3: Understanding the different migration paths available

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the different migration paths available for the migration of legacy Windows NT 4.0 and Windows 2000 domains to Windows Server 2003 domains and OU infrastructures.


This design methodology identifies and supports the following three types of migration paths to take a legacy Windows NT 4.0 or Windows 2000 domain and / or its contents to a Windows Server 2003 domain:

“Simple” migration paths, which are defined processes with specific pre-migration, migration, and post-migration tasks. It is possible to execute a “simple” migration task independently of all optional and extended migration paths to achieve a “migration” from a Windows NT 4.0 or Windows 2000 domain to a Windows Server 2003 domain.

“Optional” (domain consolidation) paths, which cannot achieve an “actual” migration independently of a “simple” migration path

“Extended” migration paths, which represent combinations of “simple” and “optional” domain consolidation paths supported by this design methodology

Each “simple” and “extended” migration path supports differences to other “simple” and “extended” paths, ranging from major to minor differences. As it is possible to collate “simple” and “optional” migration paths into “extended” migration paths, it is necessary to provide support for referencing each path.

This design methodology hence assigns a generic tag to each supported “simple”, “optional”, and “extended” migration path, using the notation “Path <letter>”, such as “Path A”. This design methodology will use these notations, for reference to the migration paths, extensively throughout the remaining processes for this migration plan.

Note that the migration paths described below, to support the migration from a legacy Windows 2000 domain, apply whether the Windows 2000 domain is in “Mixed” or “Native” mode, and hence whether it supports Windows NT 4.0 domain controllers or not, respectively.

However, it is important to note that it is possible to design differing pre-migration, migration, and post-migration tasks depending upon whether a Windows 2000 domain is in “Mixed” or “Native” mode. Some migration paths depend upon the source and target domains operating at the minimum level of “Windows 2000 Native”.

This design methodology identifies and supports the following thirteen migration paths, comprised of four “simple”, four “optional”, and five “extended” migration paths:

“Simple” Migration Paths:

In-Place Domain Upgrade: “Path A”



• Objectives of Path “A”: To effect the migration of a legacy Windows NT 4.0 domain to a Windows Server 2003 domain via the execution of the following (high-level) steps:

♦ Execution of an in-place upgrade of the Primary Domain Controller (PDC) for the Windows NT 4.0 domain to Windows Server 2003, followed immediately by

♦ Execution of the Active Directory Installation Wizard to upgrade the Security Accounts Manager (SAM) database to become an Active Directory database (note that this new Windows Server 2003 domain may reside within a new or existing, planned or unplanned, Active Directory forest)

• Scope of Path “A”: The scope of this path is restricted to the design and execution of the following activities:

♦ Preparation of the Windows NT 4.0 domain and PDC for the execution of the in-place upgrade of the PDC

♦ Execution of the in-place upgrade of the PDC

• Out of Scope of Path “A”: The scope of this path explicitly excludes the design and execution of the following activities, which are not mandatory to achieve “migration” and which hence reside within the scope of a Deployment Plan:

♦ Execution of the in-place upgrade of existing BDCs, where required, to become additional Windows Server 2003 domain controllers in the new domain.

♦ Addition of new Windows NT 4.0 (BDCs), Windows 2000, or Windows Server 2003 domain controllers to the new domain, where required

♦ Deployment of all remaining aspects and components of the new Windows Server 2003 Active Directory infrastructure for the organisation

In-Place Domain Upgrade: “Path B”

• Objectives of Path “B”: To effect the migration of a legacy Windows 2000 domain to a new Windows Server 2003 domain via execution of either of the following (high-level) steps:

♦ Execution of an in-place upgrade of the domain controllers within a legacy Windows 2000 domain to become Windows Server 2003 domain controllers (note that this new Windows Server 2003 domain may reside within a new or existing, planned or unplanned, Active Directory forest), or

♦ Introduction of a new additional Windows Server 2003 domain controller into an existing Windows 2000 domain and forest

• Scope of Path “B”: The scope of this path is restricted to the design and execution of the following activities:

♦ Preparation of an existing Windows 2000 domain and domain controller for the execution of migration path “B”

♦ Execution of an in-place upgrade of an existing Windows 2000 domain controller, or



♦ Execution of the Active Directory Installation Wizard on a new Windows Server 2003 member or standalone server to generate an additional Windows Server 2003 domain controller for an existing Windows 2000 domain

• Out of Scope of Path “B”: The scope of this path explicitly excludes the design and execution of the following activities, which are not mandatory to achieve “migration” and which hence reside within the scope of a Deployment Plan:

♦ Execution of the in-place upgrade of existing Windows 2000 domain controllers, where required, to become additional Windows Server 2003 domain controllers in the new domain.

♦ Addition of new Windows 2000 or Windows Server 2003 domain controllers to the new domain, where required


Inter-Forest Domain Consolidation: “Path C”

• Objectives of Path “C”: To effect the migration of a legacy Windows NT 4.0 domain to a Windows Server 2003 domain via the execution of the following (high-level) steps:

♦ Use of specific migration tools to clone directory objects and data from the Windows NT 4.0 SAM database into an existing new, planned or unplanned, parallel Windows Server 2003 domain

♦ Decommissioning of the source Windows NT 4.0 domain following completion of the directory cloning activities

• Scope of Path “C”: The scope of this path is restricted to the design and execution of the following activities:

♦ Preparation of an existing Windows NT 4.0 domain for the execution of migration path “C”

♦ Execution of migration activities to clone directory objects and data from the source Windows NT 4.0 domain to a target Windows Server 2003 domain

♦ Execution of post-migration activities to decommission a source Windows NT 4.0 domain, following completion of all migration activities

• Out of Scope of Path “C”: The scope of this path explicitly excludes the design and execution of the following activities, which are not mandatory to achieve “migration” and which hence reside within the scope of a Deployment Plan:



Inter-Forest Domain Consolidation: “Path D”



• Objectives of Path “D”: To effect the migration of a legacy Windows 2000 domain to a Windows Server 2003 domain via the execution of the following (high-level) steps:

♦ Use of specific migration tools to clone directory objects and data from the Windows 2000 Active Directory into an existing new, planned or unplanned, parallel Windows Server 2003 domain

♦ Decommissioning of the source Windows 2000 domain following completion of the directory cloning activities

• Scope of Path “D”: The scope of this path is restricted to the design and execution of the following activities:

♦ Preparation of an existing Windows 2000 domain for the execution of migration path “D”

♦ Execution of migration activities to clone directory objects and data from the source Windows 2000 domain to a target Windows Server 2003 domain

♦ Execution of post-migration activities to decommission a source Windows 2000 domain, following completion of all migration activities

• Out of Scope of Path “D”: The scope of this path explicitly excludes the design and execution of the following activities, which are not mandatory to achieve “migration” and which hence reside within the scope of a Deployment Plan:



“Optional” (Domain Consolidation) Paths:

Intra-Forest Domain Consolidation: “Path E”

• Objectives of Path “E”: To effect the intra-forest domain consolidation of a Windows Server 2003 domain to another Windows Server 2003 domain via the execution of the following (high-level) steps:

♦ Use of specific migration tools to move directory objects and data from the Active Directory database of one or more existing (planned or unplanned) Windows Server 2003 domains into an existing new, planned or unplanned, parallel Windows Server 2003 domain in the same forest.

♦ Decommissioning of the source Windows Server 2003 domain following completion of the directory migration activities

• Scope of Path “E”: The scope of this path is restricted to the design and execution of the following activities:

♦ Preparation of an existing Windows Server 2003 domain for the execution of migration path “E”

♦ Execution of migration activities to move directory objects and data from the source Windows Server 2003 domain to a target Windows Server 2003 domain



♦ Execution of post-migration activities to decommission a source Windows Server 2003 domain and / or tree(s), following completion of all migration activities

• Out of Scope of Path “E”: The scope of this path explicitly excludes the design and execution of the following activities, which are not mandatory to achieve “migration” and which hence reside within the scope of a Deployment Plan:


♦ Deployment of all remaining aspects and components of the new Windows Server 2003 Active Directory infrastructure for the organisation, where applicable

Inter-Forest Domain Consolidation: “Path F”

• Objectives of Path “F”: To effect the inter-forest domain consolidation of a Windows Server 2003 domain to another Windows Server 2003 domain via the execution of the following (high-level) steps:

♦ Use of specific migration tools to clone directory objects and data from the Active Directory database of one or more existing (planned or unplanned) Windows Server 2003 domains to one or more new planned Windows Server 2003 domains in a different forest

♦ Decommissioning of the source Windows Server 2003 domain and / or tree(s) / forest(s) following completion of the directory cloning activities

• Scope of Path “F”: The scope of this path is restricted to the design and execution of the following activities:

♦ Preparation of an existing Windows Server 2003 domain for the execution of migration path “F”

♦ Execution of migration activities to clone directory objects and data from the source Windows Server 2003 domain to a target Windows Server 2003 domain

♦ Execution of post-migration activities to decommission a source Windows Server 2003 domain and / or tree(s) / forest(s), following completion of all migration activities

• Out of Scope of Path “F”: The scope of this path explicitly excludes the design and execution of the following activities, which are not mandatory to achieve “migration” and which hence reside within the scope of a Deployment Plan:


♦ Deployment of all remaining aspects and components of the new Windows Server 2003 Active Directory infrastructure for the organisation, where applicable

Intra-Forest Domain Consolidation: “Path G”



• Objectives of Path “G”: To effect the intra-forest domain consolidation of a Windows 2000 domain to another Windows 2000 domain via the execution of the following (high-level) steps:

♦ Use of specific migration tools to move directory objects and data from the Active Directory database of one or more existing (planned or unplanned) Windows 2000 domains into an existing new, planned or unplanned, parallel Windows 2000 domain in the same forest.

♦ Decommissioning of the source Windows 2000 domain and / or tree(s) following completion of the directory migration activities

• Scope of Path “G”: The scope of this path is restricted to the design and execution of the following activities:

♦ Preparation of an existing Windows 2000 domain for the execution of migration path “G”

♦ Execution of migration activities to move directory objects and data from the source Windows 2000 domain to a target Windows 2000 domain

♦ Execution of post-migration activities to decommission a source Windows 2000 domain, following completion of all migration activities

• Out of Scope of Path “G”: The scope of this path explicitly excludes the design and execution of the following activities, which are not mandatory to achieve “migration” and which hence reside within the scope of a Deployment Plan:

♦ Addition of new Windows 2000 domain controllers to the new domain, where required

♦ Execution of any migration activities to transition the consolidated Windows 2000 domain to a Windows Server 2003 domain, via an upgrade, clone, or move

Inter-Forest Domain Consolidation: “Path H”

• Objectives of Path “H”: To effect the inter-forest domain consolidation of a Windows 2000 domain to another Windows 2000 domain via the execution of the following (high-level) steps:

♦ Use of specific migration tools to clone directory objects and data from the Active Directory database of one or more existing (planned or unplanned) Windows 2000 domains to one or more new planned Windows 2000 domains in a different forest

♦ Decommissioning of the source Windows 2000 domain and / or tree(s) / forest(s) following completion of the directory cloning activities

• Scope of Path “H”: The scope of this path is restricted to the design and execution of the following activities:

♦ Preparation of an existing Windows 2000 domain for the execution of migration path “H”

♦ Execution of migration activities to clone directory objects and data from the source Windows 2000 domain to a target Windows 2000 domain



♦ Execution of post-migration activities to decommission a source Windows 2000 domain and / or tree(s) / forest(s), following completion of all migration activities

• Out of Scope of Path “H”: The scope of this path explicitly excludes the design and execution of the following activities, which are not mandatory to achieve “migration” and which hence reside within the scope of a Deployment Plan:

♦ Addition of new Windows 2000 domain controllers to the new domain, where required

♦ Execution of any migration activities to transition the consolidated Windows 2000 domain to a Windows Server 2003 domain, via an upgrade, clone, or move

“Extended” Migration Paths:

Domain Consolidation & In-Place Upgrade: “Path I” is an extended migration path executing paths “G” or “H” and then “B”.

In-Place Upgrade & Domain Consolidation: “Path J” is the in-place upgrade of a legacy Windows NT 4.0 domain (path “A”) followed by the consolidation of the resulting Windows Server 2003 domain to another Windows Server 2003 domain in the same forest (path “E”) or to another forest (path “F”)

In-Place Upgrade and Domain Consolidation: “Path K” is the in-place upgrade of an “adprep” prepared legacy Windows 2000 domain (path “B”) followed by the consolidation of the resulting Windows Server 2003 domain to another Windows Server 2003 domain in the same forest (path “E”) or to another forest (path “F”)

Double Step Domain Consolidation: “Path L” is the migration of a legacy Windows NT 4.0 domain (path “C”) followed by the consolidation of the resulting Windows Server 2003 domain to another Windows Server 2003 domain in the same forest (path “E”) or to another forest (path “F”)

Double Step Domain Consolidation: “Path M” is the migration of a legacy Windows 2000 domain (path “D”) followed by the consolidation of the resulting Windows Server 2003 domain to another Windows Server 2003 domain in the same forest (path “E”) or to another forest (path “F”)

It is possible to deduce the following summary from the above list of four “simple” and five “extended” migration paths:

Paths A, “C”, J, and L support the migration from Windows NT 4.0 to Windows Server 2003

Paths “B”, “D”, I, K, and M support the migration from Windows 2000 to Windows Server 2003

The following table summarises the supported simple and optional migration paths:

Type of Path Path Category Source Domain Target Domain

IN-PLACE UPGRADE

A SIMPLE Windows NT 4.0 Windows Server 2003

B SIMPLE Windows 2000 Windows Server 2003



DOMAIN CLONING / MIGRATION

C SIMPLE Windows NT 4.0 Windows Server 2003

D SIMPLE Windows 2000 Windows Server 2003

E OPTIONAL Windows Server 2003 Windows Server 2003

F OPTIONAL Windows Server 2003 Windows Server 2003

G OPTIONAL Windows 2000 Windows 2000

H OPTIONAL Windows 2000 Windows 2000

Table 42.1: Summary of Supported “Simple” & “Optional” Migration Paths

The following diagram illustrates the assignment of these thirteen migration paths, by this design methodology, to one or two of the domain migration categories “migration domain upgrade”, “migration domain consolidation”, or “pre or post migration domain consolidation”:

Migration Plan – Migration Paths Mapped to Migration Activities

A

B

C

D

HGE F

I

LJ

KM

MigrationDomain Upgrade

Pre or Post Migration Domain

Consolidation

Migration Domain

Consolidation

I = “Extended” Migration Path

H = “Optional” Migration Path

A = “Simple” Migration Path


Figure 42.1: Mapping of Simple, Optional, and Extended Migration Paths to Migration Activities

Note that this design methodology does not support any inefficient, illogical, or overly complicated “extended” migration paths, as described in the following examples:

Extended path “H” or “G” “D” is not supported as:

This path involves the pre-migration consolidation of two or more existing Windows 2000 domains (intra-forest or inter-forest consolidation) followed by migration of the consolidated domain to a new parallel Windows Server 2003 domain.

It is simpler to execute path “D” for the existing Windows 2000 domains, and not consolidate the existing Windows 2000 domains prior to migration.

Extended path “H” or “G” “B” “E” or “F” is not supported as:

This path involves the consolidation of multiple legacy Windows 2000 domains (paths “G” or “H”), followed by the in-place upgrade of the consolidated Windows 2000 domain (path “B”), and finally followed by the consolidation of the resultant Windows Server 2003 domain(s) (paths “E” or “F”).



It is simpler to migrate directly from multiple legacy Windows 2000 domains to one or more Windows Server 2003 domains without prior consolidation or in-place upgrades.

Extended path “H” or “G” “D” “E” or “F” is not supported as:

This path involves consolidation of multiple legacy Windows 2000 domains (paths “G” or “H”), followed by the migration of the directory objects and data from the consolidated Windows 2000 domain to a Windows Server 2003 domain (path “D”), and finally followed by the consolidation of the resultant Windows Server 2003 domain(s) (paths “E” or “F”).

It is simpler to migrate directly from multiple legacy Windows 2000 domains to one or more Windows Server 2003 domains without perform three domain consolidation exercises.

The consolidation of multiple existing Windows NT 4.0 domains to a single or fewer Windows 2000 domains, via migration of directory objects and data, followed by the upgrade / migration of the remaining Windows 2000 domain(s).

The consolidation of multiple existing Windows 2000 or Windows NT 4.0 domains via a directory integration solution such as MIIS 2003 Enterprise Edition, prior to in-place upgrade or migration to a Windows Server 2003 Active Directory infrastructure.

The following diagram illustrates the four “simple” (“A” to “D”) and four “optional” (“E” to “H”) migration paths described above and supported by this design methodology. Note that this diagram does not depict the “extended” migration paths, to prevent complication of this diagram. Please bookmark this diagram for reference throughout the remainder of the Migration Plan.




W2K3 DCNT4 BDC


Migration Plan – “Simple” and “Optional” Migration Paths to Windows Server 2003 Active Directory Supported by this Design Methodology

LEGEND:

“W2K3" = Windows Server 2003

BA


W2K3 DC


W2K3 DC

B


NT4 PDCNT4 BDC

“NT4" = Windows NT 4.0

“W2K" = Windows 2000

“DC" = Domain Controller

F

H

Windows 2000Domain

W2K DC W2K DC

G

Windows 2000Domain

W2K DC W2K DC

“adprep” prepared domain and forest

EXISTING FOREST

Windows 2000Domain

W2K DC W2K DC

EXISTING FOREST


W2K3 DC W2K DC

NEW orEXISTINGFOREST

W2K3 DC W2K3 DC

E


W2K3 DC


E


W2K3 DC


EF


W2K3 DCNT4 BDC


E

BA C D

New W2K3

DC

F

A = “Simple” Migration Path H = “Optional”

Migration Path

PR

E “A

CT

UA

L” M

IGR

AT

ION

DO

MA

IN C

ON

SO

LID

AT

ION

“AC

TU

AL

” MIG

RA

TIO

N F

RO

M L

EG

AC

Y T

O N

EW

PO

ST

“AC

TU

AL

” MIG

RA

TIO

ND

OM

AIN

CO

NS

OL

IDA

TIO

N

Windows Server 2003 CD-ROM


Figure 42.2: Illustration of Supported Simple & Optional Migration Paths

3.5.2. Understanding the Features of the Supported Migration Paths

Consider the following when it is necessary to understand the features associated with each migration path supported by this design methodology:

• Factor B4: Understanding the features of the simple migration path “A” (in-place upgrade of a Windows NT 4.0 domain to create a Windows Server 2003 domain)



♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the features associated with the simple migration path “A”.


The only strict prerequisite for the selection of path “A” is that the organisation has one or more existing Windows NT 4.0 domains that contain directory objects (such as user accounts, computer accounts, group objects) and directory data (such as object attribute values) that require migration to the new Windows Server 2003 Active Directory infrastructure

The execution of path “A”, to generate a new Windows Server 2003 domain from an existing Windows NT 4.0 domain, involves the upgrade of a Windows NT 4.0 server, operating as the Primary Domain Controller (PDC) for an existing Windows NT 4.0 domain, to a Windows Server 2003 domain controller.

The in-place upgrade of a legacy Windows NT 4.0 domain to Windows Server 2003 retains and upgrades a number of aspects and contents of the domain, such as:

The directory objects and their attribute data, such as user, computer, and group account objects, and so on.

Any existing user account, audit, and password policies

Any existing external trust relationships

The actual execution of an in-place upgrade of a Windows NT 4.0 server with Windows Server 2003 performs the following actions:

Rolls back any hotfixes, service packs, and Microsoft Internet Explorer upgrades to their base versions

Reapplies the default permissions

Refreshes the registry and restores the default registry values

Re-registers all Component Object Model (COM) components and Window File Protection (WFP) files

Enumerates all Plug and Play devices and the Hardware Abstraction Layer (HAL)

It is important to note that the execution of an in-place upgrade does not perform the following actions:

Change any installed components and software

Change the registry settings generated by third-party applications and services

This design methodology proposes the following approaches towards the execution of the simple migration path “A”:

Approach 1: Upgrade an existing production PDC to become a Windows Server 2003 domain controller for a new domain. Then, support or upgrade existing BDCs (where appropriate) to become additional Windows Server 2003 domain controllers in the same domain.

Approach 2: Promote a production BDC to the PDC role and upgrade this production BDC to become a Windows Server 2003 domain controller for a new



domain. Then support or upgrade existing BDCs (where appropriate) to become additional Windows Server 2003 domain controllers in the same domain.

Approach 3: Build a new BDC for an existing Windows NT 4.0 domain using new server hardware (that matches the hardware specifications for the Windows Server 2003 domain controllers). Then, promote this new BDC to become the PDC (and hence demote current PDC to BDC), take new PDC off the production network, and promote previous PDC back to been the production PDC for the existing Windows NT 4.0 domain. Then, upgrade the PDC (currently off the production network and running on new server hardware) to become a Windows Server 2003 domain controller for a new domain. Then build new Windows Server 2003 domain controllers on new server hardware, and (optionally) decommission upgraded PDC (after transfer FSMO roles and so on) and rebuild as new additional domain controller in the new Windows Server 2003 domain.

Please note the following about these identified approaches for migration path “A”:

This design methodology acknowledges that, due to the age of the majority of Windows NT 4.0 domain infrastructures within most organisations, approaches 1 and 2 (using existing server hardware) is unfeasible due to the low hardware specifications of the existing domain controllers.

It is hence possible to execute “Approach 2” using new server hardware, which makes it the same as “Approach 3”, but with the difference that the BDC is not removed from the production network, and legacy domain controllers are supported.

The objective for identifying “Approach 3” is to perform a migration of all legacy directory objects and data, but not the legacy domain controllers, and so “Approach 3” is similar to migration path “C”, but as an in-place upgrade.

The following section details the prerequisites for each of these approaches, the advantages, and disadvantages associated with each approach and example scenarios for the use of each approach:

Approach 1 has the following prerequisites:

Either the server hardware specifications of the production PDC match the defined hardware specifications for Windows Server 2003 domain controllers in the target Windows Server 2003 domain, or

It is possible to upgrade the server hardware for the production PDC to match the defined hardware specifications for Windows Server 2003 domain controllers in the target Windows Server 2003 domain

The organisation cannot afford to procure new server hardware within the timeframes of this migration project, and hence must reuse / upgrade and reuse all existing legacy hardware platforms.

The OEM for the existing server platform (running the production PDC) and all relevant hardware components provides support for Windows Server 2003 Standard or Enterprise Edition (drivers, utilities, and so on)

It is possible execute significant operations on the PDC (such as rebuilding the operating system to comply with in-place upgrade prerequisites) without generation of disruptions to business continuity. See factor A18 within the Migration Plan process, “Design of Required Migration Paths”, for more details.

Approach 1 is associated with the following advantages:

The upgrade of a production PDC to become a Windows Server 2003 domain controller in a new domain automatically changes the domain membership for all



member computers and the BDCs for the Windows NT 4.0 domain. This approach preserves all existing domain settings in the new Windows Server 2003 domain.

This approach is quick and the least costly where it is possible to attain compliance with the approach prerequisites.

Approach 1 is associated with the following disadvantages:

This approach has a high-risk profile, as it is intrusive and potentially destructive to a production environment. If the upgrade of an existing production PDC fails, then this may influence business continuity until it is possible to promote an existing BDC to take over the role of PDC for the domain, or rebuild and restore the PDC.

This approach is associated with the execution of extensive pre-migration tasks, such as directory clean up tasks, server upgrades, and so on.

This approach generates a dependency on the new Windows Server 2003 domain to support legacy Windows NT 4.0 domain controllers (BDCs) until it is possible to upgrade or decommission them. This hence restricts the functional domain level for the new Windows Server 2003 domain to either “Windows Server 2003 Interim” or “Windows 2000 Mixed”.

Based upon the above information, it is possible to identify the following example scenarios that may support approach 1 for migration path “A” for an existing Windows NT 4.0 domain where:

The domain is supported by a PDC operating on server hardware that matches or exceeds the hardware specifications for the Windows Server 2003 domain controllers, and

The SAM database for the Windows NT 4.0 domain is relatively clean (few redundant objects that require removal or consolidation prior to migration), and

There is a requirement to continue support for one or more legacy line of business applications or other processes that rely upon the presence of Windows NT 4.0 domain controllers. Following upgrade of the applications, or re-design of the processes dependent upon the Windows NT 4.0 domain controllers, it is possible to remove or upgrade the domain controllers.

The organisation cannot afford new server hardware and must reuse / upgrade and reuse all existing servers.

There is an immediate requirement to upgrade this domain to become a Windows Server 2003 domain in an existing forest or new forest, to provide new required functionality, and

Although the Windows NT 4.0 domain is one or more of other similar legacy domains that do not match the design for the new Windows Server 2003 Active Directory infrastructure, the in-place upgrade via migration path “A” is just the first step in the migration plan. This domain will ultimately require consolidation to a single or fewer new Windows Server 2003 domains.

There is a requirement to preserve all existing user account passwords, via an in-place upgrade. (This requirement is also applicable to approach 2 and 3 for migration path “A”)




The server hardware specifications of the production PDC do not match the defined hardware specifications for Windows Server 2003 domain controllers in the target Windows Server 2003 domain, and

It is unfeasible to upgrade the server hardware for the production PDC, and

It is possible to identify an existing Backup Domain Controller (BDC) that either matches the hardware specifications for the Windows Server 2003 domain controllers or it is feasible to upgrade the server hardware on the BDC. If it is possible to use a BDC (either in its current or upgraded state), then it is necessary to switch its role to become the BDC for the existing domain, thus demoting the current PDC to become a BDC, prior to the in-place upgrade. It is necessary to execute an in-place upgrade to create a new Windows Server 2003 domain on the PDC for an existing domain, and not a BDC.

The organisation cannot afford to procure new server hardware within the timeframes of this migration project, and hence must reuse / upgrade and reuse all existing legacy hardware platforms.

The OEM for the existing server platform (running the production BDC) and all relevant hardware components provides support for Windows Server 2003 Standard or Enterprise Edition (drivers, utilities, and so on)

It is possible execute significant operations on the BDC (such as rebuilding the operating system to comply with in-place upgrade prerequisites) without generation of disruptions to business continuity. See factor A18 within the Migration Plan process, “Design of Required Migration Paths”, for more details.

Approach 2 is associated with the same advantages and disadvantages as approach 1.

Based upon the above information, it is possible to identify the same example scenarios that may support approach 2 for migration path “A”, as for approach 1.


The organisation can afford two or more new servers to become the domain controllers for the new Windows Server 2003 domain

The OEM for the new servers continues to provide support for Windows NT 4.0 via the provision of Windows NT 4.0 drivers for the new server hardware and hardware components, such as RAID array controllers, and so on

There is a requirement to reduce the risk to production domain controllers for an existing domain, and

There is a requirement to preserve directory data and settings using a quick and simple method rather than a complex migration process

There are no requirements to preserve support for legacy Windows NT 4.0 domain controllers (BDCs)


This approach is associated with minimal risk to the production environment, as a failed upgrade of the offline copy PDC does not influence the operation of the production environment, and hence business continuity.

This approach is simpler to design and execute that a complex migration process.



This approach negates the requirement to support legacy BDCs and hence supports an earlier rise in the functional level of the new Windows Server 2003 domain.


It may be possible to identify requirements for the execution of extensive pre-migration tasks, such as directory clean up tasks

It may be possible to identify requirements for the execution of extensive post-migration tasks, such as the rebuilding of the first upgraded PDC. This is because most organisations prefer a clean installation for a production domain controller, rather than an upgraded operating system.

Based upon the above information, it is possible to identify the following example scenarios that may support approach 3 for migration path “A”:

An organisation wishes to minimise the risk of an in-place upgrade to their production domain controllers, but still wish to preserve directory objects and data, without their complex re-creation via migration exercises.

An organisation wishes to preserve directory objects and data, and reach higher functional domain levels earlier by negating the requirement to support legacy BDCs.

• Factor B5: Understanding the features of the simple migration path “B” (in-place upgrade of a Windows 2000 domain to create a Windows Server 2003 domain)

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the features of the simple migration path “B”.


The following represent the strict prerequisites for the selection of path “B”:

The organisation has one or more existing Windows 2000 domains that contain directory objects (such as user accounts, computer accounts, group objects) and directory data (such as object attribute values) that require migration to the new Windows Server 2003 Active Directory infrastructure

The source Windows 2000 domain and forest has been prepared for Windows Server 2003 Active Directory via execution of the “adprep” switches “/Forestprep” and “/Domainprep”, prior to the execution of path “B”.

It is possible to identify the following approaches towards the execution of the simple migration path “B”:

Approach 1: Upgrade an existing production Windows 2000 domain controller to become a Windows Server 2003 domain controller for that domain, and hence create a Windows Server 2003 domain. Then, support or upgrade existing Windows 2000 domain controllers (where appropriate) to become additional Windows Server 2003 domain controllers in the same domain.

Approach 2: Build a new Windows Server 2003 server, and execute the Active Directory Installation Wizard on this server to make it a new domain controller within the existing Windows 2000 domain, and hence create a Windows Server 2003 domain.



The following section details the prerequisites for each of these approaches, the advantages, and disadvantages associated with each approach and example scenarios for the use of each approach:


Either the server hardware specifications of a production Windows 2000 domain controller match the defined hardware specifications for Windows Server 2003 domain controllers in the target Windows Server 2003 domain, or

It is possible to upgrade the server hardware for a production Windows 2000 domain controller to match the defined hardware specifications for Windows Server 2003 domain controllers in the target Windows Server 2003 domain


The upgrade of a production Windows 2000 domain controller to become a Windows Server 2003 domain controller in a new domain preserves all existing Windows 2000 domain settings in the new Windows Server 2003 domain.

This approach is quick and the least costly where it is possible to attain compliance with the approach prerequisites.


This approach has a high-risk profile, as it is intrusive and potentially destructive to a production environment. If the upgrade of an existing Windows 2000 domain controller fails, then this may influence business continuity unless there are additional domain controllers for the domain, or it is possible to rebuild and restore the Windows 2000 domain controller.

This approach is associated with the execution of extensive pre-migration tasks, such as directory clean up tasks, server upgrades, and so on.

This approach generates a dependency on the new Windows Server 2003 domain to support legacy Windows 2000 domain controllers until it is possible to upgrade or decommission them. This hence restricts the functional domain level for the new Windows Server 2003 domain to either “Windows 2000 Mixed” or “Windows 2000 Native”.

Based upon the above information, it is possible to identify the following example scenarios that may support approach 1 for migration path “B”:

It is possible to identify an existing Windows 2000 domain where:

• The domain is supported by Windows 2000 domain controllers operating on server hardware that matches or exceeds the hardware specifications for the Windows Server 2003 domain controllers, and

• The Active Directory database for the Windows 2000 domain is relatively clean (few redundant objects that require removal or consolidation prior to migration), and

• There is a requirement to continue support for one or more legacy line of business applications or other processes that rely upon the presence of Windows 2000 domain controllers. Following upgrade of the applications, or re-design of the processes dependent upon the Windows 2000 domain controllers, it is possible to remove or upgrade the domain controllers.

It is possible to identify an existing Windows 2000 domain where:



• There is an immediate requirement to upgrade this domain to become a Windows Server 2003 domain in an existing forest, to provide new required Windows Server 2003 functionality, and

• Although the Windows 2000 domain is one or more of other similar legacy domains that do not match the design for the new Windows Server 2003 Active Directory infrastructure, the in-place upgrade via migration path “B” is just the first step in the migration plan. This domain will ultimately require consolidation to a single or fewer new Windows Server 2003 domains.


The organisation can afford one or more new servers to become the domain controllers for the new Windows Server 2003 domain, and

There is a requirement to preserve directory data and settings using a quick and simple method rather than a complex migration process.


This approach is associated with minimal risk to the production environment, as a failed installation of Active Directory on a new Windows Server 2003 server, to make an additional domain controller, does not influence the operation of the production environment, and hence business continuity.

This approach is simpler to design and execute that a complex migration process.

This approach permits the generation of clean and not upgraded domain controllers.


There is a requirement to purchase new server hardware for each new additional Windows Server 2003 domain controller for an existing Windows 2000 domain.

This process still generates a dependency upon the Windows Server 2003 domain to support legacy Windows 2000 domain controllers until it is possible to upgrade or remove them.

Based upon the above information, it is possible to identify the following example scenarios that may support approach 2 for migration path “B”:

An organisation wishes to minimise the risk of an in-place upgrade to their production domain controllers, but still wish to preserve directory objects and data, without their complex re-creation via migration exercises.

An organisation wishes to upgrade a Windows 2000 domain using clean installed domain controllers, rather than upgraded domain controllers.

An organisation employs line of business applications that are Active Directory-enabled, and require the support of customised Schema extensions. There is a requirement to preserve continuity of these applications during the migration process, and hence the requirement for the use of migration path “B” to retain the Schema extensions via an in-place upgrade of a legacy domain.

• Factor B6: Understanding the features of the simple migration path “C” (migration of directory objects and data from a legacy Windows NT 4.0 domain to a Windows Server 2003 domain)



♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the features of the simple migration path “C”.


The following represent the strict prerequisites for the selection of path “C”:

The organisation has one or more existing Windows NT 4.0 domains that contain directory objects (such as user accounts, computer accounts, group objects) and directory data (such as object attribute values) that require migration to the new Windows Server 2003 Active Directory infrastructure

The organisation has two or more new servers to create and support each new target Windows Server 2003 domain for the source Windows NT 4.0 domain(s)

The target Windows Server 2003 domain(s) must operate at either the “Windows 2000 Native” or “Windows Server 2003” domain functional level, and hence not be required to support Windows NT 4.0 domain controllers.

The process to execute migration path “C” involves the use of one or more migration tools capable of migration directory objects and data from a source Windows NT 4.0 domain to a Windows Server 2003 domain. This path involves the implementation of the target Windows Server 2003 domain(s) into the production environment for an organisation, and operation of these Windows Server 2003 domains in parallel to existing legacy domain infrastructures. Following the migration of all required directory objects and data, and where the legacy Windows NT 4.0 domain infrastructures are no longer required, it is then possible to decommission these legacy domain infrastructures.

Execution of migration path “C” is associated with the following advantages:

The migration of directory objects and data from one or more source Windows NT 4.0 domains is not intrusive or potentially destructive to the legacy production environment. This hence reduces the level of risk associated with the migration project.

The execution of migration path “C” permits the possible attainment of the desired design for the final target Windows Server 2003 Active Directory infrastructure in one or two migration steps.

Execution of migration path “C” is associated with the following disadvantages:

The migration, via migration, of directory objects and data to another parallel Windows Server 2003 domain prevents the continued support for legacy Windows NT 4.0 domain controllers in the target domain. Hence, where there is a requirement to retain Windows NT 4.0 domain controller to support legacy applications or processes, then there may be a requirement to extend the interim phase for the migration, where both the legacy Windows NT 4.0 and Windows Server 2003 domains operate in parallel.

This migration path is more complex, and hence the design of this process is more time consuming and demanding.

Based upon the above information, it is possible to identify the following example scenarios that may support the selection of migration path “C”:

It is possible to identify one or more existing Windows NT 4.0 domains where:



The Windows NT 4.0 domain controllers for the domain operate on server hardware that does not match the hardware specifications for the Windows Server 2003 domain controllers, and:

• The existing server platforms are unfeasible to upgrade, but

• The organisation can afford new server hardware

The Windows NT 4.0 domain(s) do not match the design for the Windows Server 2003 Active Directory infrastructure, and execution of an in-place upgrade followed by domain consolidation is not feasible.

An organisation can identify the requirements to employ new advanced features of Windows Server 2003, but:

• Retain the current legacy production environment for as long as possible, and

• Minimise risk of compromises to business continuity dependent upon the current production environment

Due to a large number of potentially redundant directory objects within the domain, it is unfeasible to perform an in-place upgrade, as this would take all directory objects into the new Active Directory. It is necessary, instead, to execute a selective clone of directory objects and data using migration path “C”. (See later for the execution of the pre-migration directory clean up tasks)

• Factor B7: Understanding the features of the simple migration path “D” (migration of directory objects and data from a Windows 2000 domain to a Windows Server 2003 domain)

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the features of the simple migration path “D”.


The following represent the strict prerequisites for the selection of path “D”:


The organisation has two or more new servers to create and support each new target Windows Server 2003 domain for the source Windows 2000 domain(s)


The process to execute migration path “D” involves the use of one or more migration tools capable of migration directory objects and data from a source Windows 2000 domain to a Windows Server 2003 domain. This path involves the implementation of the target Windows Server 2003 domain(s) into the production environment for an organisation, and operation of these Windows Server 2003 domains in parallel to existing legacy domain infrastructures. Following the migration of all required directory objects and data, and where the legacy Windows 2000 domain infrastructures are no longer required, it is then possible to decommission these legacy domain infrastructures.



Execution of migration path “D” is associated with the following advantages:

The migration of directory objects and data from one or more source Windows 2000 domains is not intrusive or potentially destructive to the legacy production environment. This hence reduces the level of risk associated with the migration project.

The migration of a legacy Windows 2000 domain to a new Windows Server 2003 domain in a new forest supports the generation of a new default Schema, that does not inherit any intentional or accidental and unwanted Schema extensions in the legacy forest.

The execution of migration path “D” permits the possible attainment of the desired design for the final target Windows Server 2003 Active Directory infrastructure in one or two migration steps.

There is no requirement to prepare one or more source Windows 2000 forests and domains using the “adprep” utility, which can generate significant replication waves due to the associated Schema extensions.

Execution of migration path “D” is associated with the following disadvantages:

The migration, via migration, of directory objects and data to another parallel Windows Server 2003 domain requires the implementation of two or more new Windows Server 2003 domain controllers for each new target Windows Server 2003 domain. This path is hence associated with significant financial and administrative overheads.

Where the source Windows 2000 domain is still operating in Windows 2000 Mixed Mode (and hence supporting legacy Windows NT 4.0 BDCs), then unless it is possible to upgrade or decommission these legacy Windows NT 4.0 domain controllers, there is a requirement to extend the interim migration phase.

This migration path is more complex, and hence the design of this process is more time consuming and demanding.

Based upon the above information, this design methodology presents the following example scenarios that may support the selection of migration path “D”. Migration path “D” may be suitable if it is possible to identify one or more existing Windows 2000 domains where:

The Windows 2000 domain controllers for the domain operate on server hardware that does not match the hardware specifications for the Windows Server 2003 domain controllers, and:

The server platforms are unfeasible to upgrade, but

The organisation can afford new server hardware

The Windows 2000 domain(s) do not match the design for the Windows Server 2003 Active Directory infrastructure, and execution of an in-place upgrade followed by domain consolidation is not feasible.

An organisation can identify the requirements to:

Employ new advanced features of Windows Server 2003, but

Retain the current legacy production environment for as long as possible, and

Minimise risk of compromises to business continuity dependent upon the current production environment



An organisation has one or more Windows 2000 forests, owned and managed by various autonomous and non-autonomous divisions within the organisation. Within all or some of these forests, there have been a significant number of Schema customisations to support Active Directory-enabled applications and processes. However, prior to migration, it is possible to identify that some of these applications or processes are now redundant and hence their Schema extensions are not required. The organisation has hence no requirement to retain the Schema extensions within the Windows 2000 forests, and hence wishes to avoid an in-place upgrade, which would preserve the extensions. It is possible to attain compliance with this requirement via the design and use of migration path “D”. Migration path “D” supports the selective migration of directory objects and data from domains within the forest, followed by the ultimate decommissioning of the legacy forest(s).

• Factor B8: Understanding the features of the extended migration path “I” (execution of optional migration paths “G” or “H” followed by the execution of simple migration path “B”)

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the features of the extended migration path “I”.


The following represent the strict prerequisites for the selection of path “I”:

The organisation has two or more existing Windows 2000 domains that contain directory objects (such as user accounts, computer accounts, group objects) and directory data (such as object attribute values) that require migration to the new Windows Server 2003 Active Directory infrastructure

To support execution of path “G” or “H” prior to path “B”, there is a requirement for compliance with the following criteria:

It is possible to identify one or more existing or new (planned or unplanned) target Windows 2000 domains for source Windows 2000 domains in path “G” or “H”, and

Each target Windows 2000 domain is currently operating in (or can be raised to) Windows 2000 Native mode (and hence no support for legacy Windows NT 4.0 domain controllers)

To support execution of path “B” (after “G” or “H”), the source Windows 2000 domain for path “B” requires preparation for an upgrade to Windows Server 2003 Active Directory via execution of the “adprep” switches “/Forestprep” and “/Domainprep”.

The process to execute the extended migration path “I” employs the following two key stages:

Stage 1 (paths “G” and / or “H”) is executed as a “pre-migration” task, and involves the use of one or more migration tools capable of migration directory objects and data from a source Windows 2000 domain to another Windows 2000 domain, either in the same forest (path “H”) or in another forest (path “G”). This stage hence relies upon the presence of one or more target Windows 2000 domains operating in “Windows 2000 Native” mode.

Stage 2 (path “B”) is executed as a “migration task” and involves the execution of approach 1 or 2 for path “B”, as discussed earlier.

Execution of extended migration path “I” is associated with the following advantages, with respect to execution of paths “G” or “H” (see earlier for advantages associated with execution of path “B”):



The execution of extended path “I” permits decommissioning and streamlining of multiple existing Windows 2000 domains prior to migration to Windows Server 2003. This process hence permits domain restructuring prior to migration to attain, where possible, the required forest and domain design for the new Windows Server 2003 Active Directory infrastructure.

The execution of extended path “I” results in the decommissioning of superfluous Windows 2000 domains prior to migration. This hence potentially makes more server hardware (from domain controllers in decommissioned Windows 2000 domains) available for other requirements.

The execution of extended path “I” reduces administrative overheads prior to the migration, as there are fewer Windows 2000 domains that require routine administration just prior to migration, and (possibly) during migration and after migration. This hence potentially frees up administrative personnel to focus on the migration tasks.

The execution of extended path “I” reduces the migration workload, as execution of paths “G” or “H” reduce the total number of Windows 2000 domains that require migration using path “B”.

Execution of extended migration path “I” is associated with the following disadvantages, with respect to execution of paths “G” or “H” (see earlier for advantages associated with execution of path “B”):

A prerequisite to the use of migration tools that clone directory objects and data between domains (and hence support path “G” or “H”) is that the target Windows 2000 domain operates in “Windows 2000 Native” mode, which hence implies no support for legacy Windows NT 4.0 domain controllers. Where an organisation currently employs line of business applications that rely upon the presence of Windows NT 4.0 domain controllers, then it is not possible to decommission these source domains using paths “G” or “H”.

The execution of extended path “I” is a complex undertaking that requires a methodical approach due to the involvement of the production environment in each stage. This approach is hence associated with a phased approach with multiple steps, and not a single large step for each stage. Due to the complexity of this path, the design of the migration process for this extended path is hence more demanding and time consuming.

The phased approach towards the execution of extended path “I”, as a two-stage migration path, implies a longer duration for the migration project, as it is necessary to execute pre-migration, migration, and post-migration activities for both stages.

Based upon the above information, this design methodology presents the following example scenarios that may support the selection of extended migration path “I”. Extended migration path “I” may be suitable if it is possible to identify the following scenarios:

An organisation wishes to migrate their entire current Windows 2000 domain infrastructure to a new Windows Server 2003 Active Directory infrastructure, and where:

It is possible to identify, within the current Windows 2000 Active Directory infrastructure, one or more of the following points:

• The current Windows 2000 Active Directory infrastructure currently supports multiple forests and domains, where the functions of the forests and domains vary from primary account forests / domains, to application and resource forests / domains, and parallel test forests / domains, and so on.



• The current Windows 2000 Active Directory infrastructure is comprised of multiple discrete forests and domains due to the unplanned and / or “organic” growth of the organisation via (for example) mergers and acquisitions.

The design for the target Windows Server 2003 Active Directory infrastructure has the following characteristics:

• The organisation has identified the requirement to use the migration project as an opportunity to restructure the entire existing Windows 2000 Active Directory infrastructure to a new uniform and planned Windows Server 2003 Active Directory infrastructure.

• The design of the new Windows Server 2003 Active Directory infrastructure supports the consolidation of each existing domain or forest, where appropriate, to a fewer number of domains or forests.

There is a requirement to execute the migration project over an extended period, to respect the envisaged complexity of the migration process.

An organisation currently supports multiple autonomous divisions, each with their own Windows 2000 Active Directory forest and domain infrastructure, and each tasked with migration to the new organisation-wide Windows Server 2003 Active Directory infrastructure. To coordinate all migration process, the organisation has decided to separate the migration project into the following two stages:

Stage 1 will permit each autonomous division to execute migration path “H” or “G” (as appropriate to their source Windows 2000 domains / forests), where the target Windows 2000 domain is, for example, a new or existing domain the parent organisation will upgrade to the new Windows Server 2003 Active Directory infrastructure.

Stage 2 will permit, for example, the parent organisation to execute simple migration path “B” to upgrade the consolidated Windows 2000 domains / forests to generate the new Windows Server 2003 Active Directory infrastructure.

• Factor B9: Understanding the features of the extended migration path “J” (execution of simple migration path “A” followed by the execution of optional migration paths “E” or “F”)

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the features of the extended migration path “J”.


The strict prerequisites for the selection of path “J” are:

The organisation has one or more existing Windows NT 4.0 domains that contain directory objects (such as user accounts, computer accounts, group objects) and directory data (such as object attribute values) that require migration to the new Windows Server 2003 Active Directory infrastructure

To support execution of path “E” or “F” after path A, there is a requirement for compliance with the following criteria:

It is possible to identify one or more existing or new (planned or unplanned) target Windows Server 2003 domains for the source (upgraded) Windows Server 2003 domains in path “E” or “F”, and

Each target Windows Server 2003 domain is currently operating in (or can be raised to) either “Windows 2000 Native” (and hence no support for legacy



Windows NT 4.0 domain controllers) or “Windows Server 2003” domain functional level.

The process to execute the extended migration path “J” employs the following two key stages:

Stage 1 (path “A”) is executed as a “migration task” and involves the execution of approach 1, 2, or 3 for path A, as discussed earlier.

Stage 2 (paths “E” or “F”) is executed as a “post-migration task” and involves the use of one or more migration tools capable of migration directory objects and data from a source Windows Server 2003 domain to another Windows Server 2003 domain, either in the same forest (path “E”) or in another forest (path “F”). This stage hence relies upon the presence of one or more target Windows Server 2003 domains operating in either “Windows 2000 Native” or “Windows Server 2003” domain functional levels.

Execution of extended migration path “J” is associated with the following advantages, with respect to execution of paths “E” or “F” (see earlier for advantages associated with execution of path “A”):

The execution of extended path “J” permits the rapid upgrade of two or more existing Windows NT 4.0 domains to Windows Server 2003 domains. As a domain restructuring exercise in stage 2 follows stage 1 of this extended migration path, execution of stage 1 hence does not require compliance by the source Windows NT 4.0 domains with the design of the target Windows Server 2003 Active Directory infrastructure.

The rapid upgrade of existing Windows NT 4.0 domains to Windows Server 2003 domains permits the selection of one or four Windows Server 2003 domain functional levels, depending upon the requirements to support existing legacy Windows NT 4.0 domain controllers (BDCs) and / or Windows 2000 domain controllers. However, regardless of the domain functional level selected, all base Windows Server 2003 Active Directory features, common to all functional levels, will become immediately available for use, such as directory quotas and application directory partitions (ADPs).

As it is possible to execute stage 1 rapidly, without consideration for matching the design of the new target Windows Server 2003 domain infrastructure, it is possible to devote more time and resources towards the design of the migration processes to support the more complex second stage of this extended migration path.

Execution of extended migration path “J” is associated with the following disadvantages, with respect to execution of paths “E” or “F” (see earlier for advantages associated with execution of path “A”):

A prerequisite to the use of migration tools that clone directory objects and data between domains (and hence support path “E” or “F”) is that the target Windows Server 2003 domain operates in either “Windows 2000 Native” or “Windows Server 2003” domain functional level. This hence implies no support for legacy Windows NT 4.0 domain controllers and / or Windows 2000 domain controllers, respectively. Where an organisation currently employs line of business applications that rely upon the presence of Windows NT 4.0 and / or Windows 2000 domain controllers, then it may not be possible to decommission these source domains using paths “E” or “F”.

The execution of extended path “J” is a complex undertaking that requires a methodical approach due to the involvement of the production environment in each stage. This approach is hence associated with a phased approach with multiple steps, and not a single large step for each stage. Due to the complexity of this path, the design of the migration process for this extended path is hence more demanding and time consuming.



Based upon the above information, this design methodology presents the following example scenarios that may support the selection of extended migration path “J”. Extended migration path “J” may be suitable if it is possible to identify the following scenarios:

An organisation wishes to migrate their entire current Windows NT 4.0 domain infrastructure to a new Windows Server 2003 Active Directory infrastructure, and where:

It is possible to identify, within the current Windows NT 4.0 domain infrastructure, one or more of the following points:

• The current Windows NT 4.0 domain infrastructure currently supports multiple domains, where the functions of the domains vary from primary account domains, to application and resource domains, and parallel test domains, and so on.

• The current Windows NT 4.0 domain infrastructure is comprised of multiple discrete domains due to the unplanned and / or “organic” growth of the organisation via (for example) mergers and acquisitions.

The design for the target Windows Server 2003 Active Directory infrastructure has the following characteristics:

• The organisation has identified the requirement to use the migration project as an opportunity to restructure the entire existing Windows NT 4.0 domain infrastructure to a new uniform and planned Windows Server 2003 Active Directory infrastructure.

• The design of the new Windows Server 2003 Active Directory infrastructure supports the consolidation of the existing Windows NT 4.0 domain(s), where appropriate, to a fewer number of domains.

Due to political and cultural differences, or financial and administrative overheads within an organisation, it may not be feasible to coordinate a single step migration of all existing Windows NT 4.0 domains to the new target Windows Server 2003 Active Directory infrastructure. Hence, for example, there is a requirement to permit and support multiple independent migrations, using migration path “A”. Following completion of migration path “A” for each existing Windows NT 4.0 domain, it may be possible for the parent organisation to coordinate the restructuring and consolidation of the upgraded Windows Server 2003 domains to the final new target Windows Server 2003 Active Directory infrastructure.

• Factor B10: Understanding the features of the extended migration path “K” (execution of simple migration path “B” followed by the execution of optional migration paths “E” or “F”)

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the features of the extended migration path “K”.


The strict prerequisites for the selection of path “K” are:




To support execution of path “B” (before “E” or “F”), the source Windows 2000 domain for path “B” requires preparation for an upgrade to Windows Server 2003 Active Directory via execution of the “adprep” switches “/Forestprep” and “/Domainprep”.

To support execution of path “E” or “F” after path “B”, there is a requirement for compliance with the following criteria:

It is possible to identify one or more existing or new (planned or unplanned) target Windows Server 2003 domains for source (upgraded) Windows Server 2003 domains in path “E” or “F”, and

Each target Windows Server 2003 domain is currently operating in (or can be raised to) either “Windows 2000 Native” (and hence no support for legacy Windows NT 4.0 domain controllers) or “Windows Server 2003” domain functional level (and hence no support for legacy Windows NT 4.0 and Windows 2000 domain controllers)

The process to execute the extended migration path “K” employs the following two key stages:

Stage 1 (path “B”) is executed as a “migration task” and involves the execution of approach 1 or 2 for path “B”, as discussed earlier.

Stage 2 (paths “E” or “F”) is executed as a “post-migration task” and involves the use of one or more migration tools capable of migration directory objects and data from a source (upgraded from Windows NT 4.0) Windows Server 2003 domain to another Windows Server 2003 domain, either in the same forest (path “E”) or in another forest (path “F”). This stage hence relies upon the presence of one or more target Windows Server 2003 domains operating in either “Windows 2000 Native” or “Windows Server 2003” domain functional levels.

Execution of extended migration path “K” is associated with the following advantages, with respect to the combined execution of paths “B” and “E” or “F” (see earlier for advantages associated with execution of only path “B”):

The execution of extended path “K” permits the rapid upgrade of two or more existing Windows 2000 domains to Windows Server 2003 domains. As a domain restructuring exercise in stage 2 follows stage 1 of this extended migration path, execution of stage 1 hence does not require compliance by the source Windows 2000 domains with the design of the target Windows Server 2003 Active Directory infrastructure.

The rapid upgrade of existing Windows 2000 domains to Windows Server 2003 domains permits the selection of one or three Windows Server 2003 domain functional levels, depending upon the requirements to support existing legacy Windows NT 4.0 domain controllers (BDCs) and / or Windows 2000 domain controllers. However, regardless of the domain functional level selected, all base Windows Server 2003 Active Directory features, common to all functional levels, will become immediately available for use, such as directory quotas and application directory partitions (ADPs).

As it is possible to execute stage 1 rapidly, without consideration for matching the design of the new target Windows Server 2003 domain infrastructure, it is possible to devote more time and resources towards the design of the migration processes to support the more complex second stage of this extended migration path.

Execution of extended migration path “K” is associated with the following disadvantages, with respect to combined execution of paths “B” and “E” or “F” (see earlier for advantages associated with execution of only path “B”):




The execution of extended path “K” is a complex undertaking that requires a methodical approach due to the involvement of the production environment in each stage. This approach is hence associated with a phased approach with multiple steps, and not a single large step for each stage. Due to the complexity of this path, the design of the migration process for this extended path is hence more demanding and time consuming.

Based upon the above information, this design methodology presents the following example scenarios that may support the selection of extended migration path “K”. Extended migration path “K” may be suitable if it is possible to identify the following scenarios:

An organisation wishes to restructure and migrate their entire current Windows 2000 Active Directory infrastructure to a new Windows Server 2003 Active Directory infrastructure, and:

Can identify potential hurdles in the migration process that will delay the upgrade / consolidation of existing Windows 2000 domains, such as:

• Requirements to upgrade applications and business processes to operate within a new Windows Server 2003 Active Directory environment

• Constraints on immediate migration due to requirements to comply with, for example, budgetary constraints, logistical, and third party influences, parallel projects, and so on within autonomous divisions that own existing Windows 2000 forests and / or domains

Can hence identify the requirements to support a long phased approach where:

• A number of Windows 2000 domains may be directly (in a single step) migrated to a new target Windows Server 2003 domain (via path “B” or “D”), and

• A number of Windows 2000 domains will require an initial upgrade (via path “B”) followed by consolidation to a new Windows Server 2003 domain (via path “E” or “F”)

• Factor B11: Understanding the features of the extended migration path “L” (execution of simple migration path “C” followed by the execution of optional migration paths “E” or “F”)

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the features of the extended migration path “L”.


The strict prerequisites for the selection of path “L” are:

The organisation has one or more existing Windows NT 4.0 domains that contain directory objects (such as user accounts, computer accounts, group objects) and



directory data (such as object attribute values) that require migration to the new Windows Server 2003 Active Directory infrastructure

To support execution of path “C” (before “E” or “F”), there is a requirement for compliance with the following criteria:

The organisation has two or more new servers to create and support each new target Windows Server 2003 domain for the source Windows NT 4.0 domain(s)


To support execution of path “E” or “F” after path “C”, there is a requirement for compliance with the following criteria:



The process to execute the extended migration path “L” employs the following two key stages:

Stage 1 (path “C”) is executed as a “migration task” and involves the migration of directory objects and data from SAM databases within Windows NT 4.0 domains to one or more new Windows Server 2003 domains, as discussed earlier.

Stage 2 (paths “E” or “F”) is executed as a “post-migration task”. Stage 2 involves the use of one or more migration tools capable of migration directory objects and data from a source (migrated from one or more Windows NT 4.0 domains) Windows Server 2003 domain to another Windows Server 2003 domain, either in the same forest (path “E”) or in another forest (path “F”). This stage hence relies upon the presence of one or more target Windows Server 2003 domains operating in either “Windows 2000 Native” or “Windows Server 2003” domain functional levels.

Execution of extended migration path “L” is associated with the following advantages, with respect to the combined execution of paths “C” and “E” or “F” (see earlier for advantages associated with execution of only path “C”):

Because extended path “L” is a migration path involving a double step domain consolidation, it permits organisations to develop a flexible approach towards the design and execution of the migration project.

Extended migration path “L” is a low risk approach towards migration from a Windows NT 4.0 domain infrastructure as neither stage (path “C” or paths “E” / “F”) influences the production environments.

The execution of extended path “L” permits an organisation to assign each source Windows NT 4.0 domain a discrete migration schedule, which permits execution of its migration processes (in line with extended migration path “L”) independently of the migration requirements or status of other parallel Windows NT 4.0 domains.

Execution of extended migration path “L” is associated with the following disadvantages, with respect to combined execution of paths “C” and “E” or “F” (see earlier for advantages associated with execution of only path “C”):




The execution of extended path “L” is a complex undertaking that requires a methodical approach due to the involvement of the production environment in each stage. This approach is hence associated with a phased approach with multiple steps, and not a single large step for each stage. Due to the complexity of this path, the design of the migration process for this extended path is hence more demanding and time consuming.

Based upon the above information, this design methodology presents the following example scenarios that may support the selection of extended migration path “L”. Extended migration path “L” may be suitable if it is possible to identify the following scenarios:

An organisation supports several large autonomous divisions, distributed across multiple geographical locations. Each autonomous division receives instructions to merge / consolidate their existing Windows NT 4.0 domain infrastructure(s) into the new Windows Server 2003 Active Directory infrastructure for the parent organisation, as part of a new initiative to centralise all IT administration. The parent organisation supports the following aspects for the migration project:

The completion of each stage in the migration process must not impede or influence business continuity in any autonomous division

The migration from each Windows NT 4.0 domain infrastructure to the new Windows Server 2003 Active Directory infrastructure for the parent organisation will require discrete scheduling, management, and execution. The parent organisation acknowledges that the period between completion of path “C” and commencement of paths “E” or “F” may be from a few weeks to even a few months. Hence, there is a requirement for an interim period of stability (completion of path “C”) between each stage in this extended path.

• Factor B12: Understanding the features of the extended migration path “M” (execution of the simple migration path “D” followed by the execution of the optional migration paths “E” or “F”)

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the features of the extended migration path “M”.


The strict prerequisites for the selection of path “M” are:


To support execution of path “D” (before “E” or “F”), there is a requirement for compliance with the following criteria:



The organisation has two or more new servers to create and support each new target Windows Server 2003 domain for the source Windows 2000 domain(s)


To support execution of path “E” or “F” after path “D”, there is a requirement for compliance with the following criteria:



The process to execute the extended migration path “M” employs the following two key stages:

Stage 1 (path “D”) is executed as a “migration task” and involves the migration of directory objects and data from one or more existing Windows 2000 domains to one or more new Windows Server 2003 domains, as discussed earlier.

Stage 2 (paths “E” or “F”) is executed as a “post-migration task”. Stage 2 involves the use of one or more migration tools capable of migration directory objects and data from a source (migrated from one or more Windows 2000 domains) Windows Server 2003 domain to another Windows Server 2003 domain, either in the same forest (path “E”) or in another forest (path “F”). This stage hence relies upon the presence of one or more target Windows Server 2003 domains operating in either “Windows 2000 Native” or “Windows Server 2003” domain functional levels.

Execution of extended migration path “M” is associated with the following advantages, with respect to the combined execution of paths “D” and “E” or “F” (see earlier for advantages associated with execution of only path “D”):

Because extended path “M” is a migration path involving a double step domain consolidation, it permits organisations to develop a flexible approach towards the design and execution of the migration project.

Extended migration path “M” is a low risk approach towards migration from a Windows NT 4.0 domain infrastructure as neither stage (path “D” or paths “E” / “F”) influences the production environments.

The execution of extended path “M” permits an organisation to assign each source Windows 2000 domain a discrete migration schedule, which permits execution of its migration processes (in line with extended migration path “M”) independently of the migration requirements or status of other parallel Windows 2000 domains.

Execution of extended migration path “M” is associated with the following disadvantages, with respect to combined execution of paths “D” and “E” or “F” (see earlier for advantages associated with execution of only path “D”):

A prerequisite to the use of migration tools that clone directory objects and data between domains (and hence support path “E” or “F”) is that the target Windows Server 2003 domain operates in either “Windows 2000 Native” or “Windows Server 2003” domain functional level. This hence implies no support for legacy Windows NT 4.0 domain controllers and / or Windows 2000 domain controllers, respectively.



Where an organisation currently employs line of business applications that rely upon the presence of Windows NT 4.0 and / or Windows 2000 domain controllers, then it may not be possible to decommission these source domains using paths “E” or “F”.

The execution of extended path “M” is a complex undertaking that requires a methodical approach due to the involvement of the production environment in each stage. This approach is hence associated with a phased approach with multiple steps, and not a single large step for each stage. Due to the complexity of this path, the design of the migration process for this extended path is hence more demanding and time consuming.

Based upon the above information, this design methodology presents the following example scenarios that may support the selection of extended migration path “M”. Extended migration path “M” may be suitable if it is possible to identify the following scenarios:

An organisation supports several large autonomous divisions, distributed across multiple geographical locations. Each autonomous division receives instructions to merge / consolidate their existing Windows 2000 Active Directory infrastructure(s) into the new Windows Server 2003 Active Directory infrastructure for the parent organisation, as part of a new initiative to centralise all IT administration. The parent organisation supports the following aspects for the migration project:

The completion of each stage in the migration process must not impede or influence business continuity in any autonomous division

The migration from each Windows 2000 domain infrastructure to the new Windows Server 2003 Active Directory infrastructure for the parent organisation will require discrete scheduling, management, and execution. The parent organisation acknowledges that the period between completion of path “D” and commencement of paths “E” or “F” may be from a few weeks to even a few months. Hence, there is a requirement for an interim period of stability (completion of path “D”) between each stage in this extended path.

3.5.3. Operating System Upgrade Paths

Consider the following when it is necessary to understand the supported upgrade paths for legacy Windows Server operating systems to versions of the Windows Server 2003 operating system:

• Factor B13: Supported upgrade paths for legacy operating systems to Windows Server 2003

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the supported paths to upgrade the legacy operating system (Windows NT 4.0 or Windows 2000) for simple migration paths “A” and “B”, respectively.


The upgrade of a legacy Windows Server operating system must follow specific upgrade paths. This design methodology is only concerned with the in-place upgrade of domain controllers running Windows NT 4.0 or Windows 2000 Server (Standard or Advanced Server) operating system, and not with:

Earlier legacy Windows server operating systems (such as Windows NT 3.51) or

Different legacy Windows Server operating systems (such as Windows 2000 Datacenter Server), or



Different target Windows Server 2003 operating systems such as “Windows Server 2003 Datacenter Server” or “Windows Server 2003 Web Edition”

The following table details the specific allowed migration paths for the in-place upgrade of a legacy operating system to Windows Server 2003 operating system and versions of this operating system:

Legacy Windows Operating System Supported version(s) of Windows Server 2003 operating system for in-place upgrade

Windows NT 4.0 Server (SP5 or SP6a) Windows Server 2003 Standard or Enterprise Edition

Windows NT 4.0 Enterprise Edition (SP5 or SP6a)

Windows Server 2003 Enterprise Edition

Windows NT 4.0 Terminal Server Edition (SP5 or SP6a)

Windows Server 2003 Standard or Enterprise Edition

Windows 2000 Server Windows Server 2003 Standard or Enterprise Edition

Windows 2000 Advanced Server Windows Server 2003 Enterprise Edition

Table 42.2: Supported Operating System Upgrade Paths to Windows Server 2003

From the above table, it is hence possible to note the following:

Any legacy version of Windows NT 4.0 Server or Windows 2000 Server can be upgraded to Windows Server 2003 Enterprise Edition

Only legacy operating system running the standard version of the operating system can be upgraded to Windows Server 2003 Standard Edition

The version of the current operating system on the legacy domain controllers may influence the migration strategy for this project (see later for details).

Note that the execution of the above migration paths assumes that the server hardware platforms for the legacy servers are compliant with the identified minimum hardware specifications for the new Windows Server 2003 domain controllers (see Domain Plan for more details).



4. Determination of Required Migration Strategy

The selection and design of the required migration path(s) depends upon identification of the migration strategy and goals, which will also guide the design and execution of the migration plan.

This process will assist an organisation in the determination of their required migration strategy and complimentary business and technical migration goals for this migration plan, and hence the required migration path(s) for each legacy domain.


The objectives of this process, to determine the required migration strategy for this migration plan, are to:

• Determine the required migration goals for this migration project

• Determine the required approach to support the migration of the legacy domain infrastructure(s) to the new Windows Server 2003 Active Directory infrastructure

• Select an appropriate migration path for each legacy domain

• Determine the domain creation dependencies

4.2. Process Scope

All legacy Windows NT 4.0 and / or Windows 2000 domains identified as been within the scope of this migration plan define the scope of this process.

Note that the following aspects of this migration plan influence and define the scope for the migration strategy:

• The requirements to retain, migrate, and re-use directory objects and data, currently held within legacy domain infrastructures, in the new Windows Server 2003 Active Directory infrastructure

• The requirements to support business continuity during and after the migration and coexistence phases


Prior to the execution of this process, it is important to understand the following concepts and terminology employed by this design methodology for the determination of the required migration strategy and paths (all words and phrases in inverted commas refer to concepts with definitions provided below):

• The term “legacy domain” refers to any existing Windows NT 4.0 or Windows 2000 domain.

• The term “source” domain represents the source for directory objects and data, for migration to a “target” Windows Server 2003 or (interim) Windows 2000 domain.

• The term “target” domain refers to a Windows Server 2003 or (interim) Windows 2000 domain, which may either exist in parallel to an existing “legacy domain”, or be created from the in-place upgrade of a “legacy domain”.

• The relationship between “source” and “target” domains varies depending upon the migration paths that “link” the domains, and the migration goals. For example:

♦ A single “source” domain for a migration path may be the “source” domain for:



One “target” domain, and hence all directory objects and data is migrated from the “source” domain to the “target” domain, or

Multiple “target” domains, and hence the directory objects and data migrated from one “source” domain is distributed (as per the required migration approach and strategy) across two or more “target” domains

♦ And likewise, a single “target” domain for a migration path may be the “target” domain for:

One “source” domain, or

Multiple “source” domains, and hence the target component for a domain consolidation exercise

• The term “migration strategy” refers to the approach the organisation wishes to employ to perform the migration from their legacy Windows NT 4.0 and / or Windows 2000 domain infrastructure(s) to the new Windows Server 2003 Active Directory infrastructure. The deliverables for the migration strategy are:

♦ Identification of the required migration approach to migrate the entire legacy domain infrastructure(s), and

♦ Identification of the subsequent domain creation dependencies

• The components and activities that comprise the migration strategy are (see later for details):

♦ The execution of a design gap analysis

♦ The determination of the “migration goals”

♦ The identification of “migration issues”

♦ The determination of the required “migration approach”

♦ The determination of the “domain creation dependencies”

• The term “migration approach”, as a deliverable of the migration strategy, refers to the strategy to migrate one or more legacy domains to one or more Windows Server 2003 domains. Note that there is a single migration approach for a migration plan, as it encompasses the required approach for the migration of all existing in-scope legacy domains to the new Windows Server 2003 Active Directory infrastructure. The completed design for the Windows Server 2003 Active Directory infrastructure has identified the number of forests and domains required. It is now the responsibility of the migration strategy to map the legacy domain infrastructure to the new target domain infrastructure and identify, regardless of the numbers of legacy and new domains, whether there is a requirement for the:

♦ One-to-one mapping of entire legacy domains (including all directory objects and data within each domain) to entire new Windows Server 2003 domains, or

♦ A mapping of one-to-many or many-to-one legacy domains (as entire domains, and hence all directory objects and data within each domain) to new Windows Server 2003 domains, or

♦ A mapping of many-to-many legacy to new Windows Server 2003 domains (as the granular migration of specific directory objects and data from one or many legacy domains to one or many new Windows Server 2003 domains)



• The migration strategy, reflected in the defined migration approach, hence defines the migration paths that require selection, and will influence the domain creation dependencies. The business and technical migration goals will influence the required migration approach.

• The selected “migration approach” is supported by either or all of the following three “migration methods” supported by this design methodology:

♦ “In-place upgrade” of a legacy domain, via the execution of a single step process to perform an in-place upgrade of the legacy domain. This hence upgrades a Windows NT 4.0 and / or Windows 2000 domain into a Windows Server 2003 domain. The simple migration paths “A” and “B” support the “upgrade” migration method.

♦ “Migration” of a legacy domain, via the execution of a two-step process to:

Identify a target Windows Server 2003 domain for a source legacy domain, via either the creation of a new and pristine domain, or use of an existing parallel domain (created, for example, via the upgrade of another legacy domain)

Clone selected directory objects and data from the source legacy domain to the new target Windows Server 2003 domain. The simple migration paths “C” and “D” support the “migration” migration method.

♦ “Moving” of objects between domains in the same Active Directory Forest, using the intra-forest migration paths “E” or “G”

• The term “migration” refers to the execution of a “migration method” to perform an upgrade of a legacy domain, or the migration of directory objects and data from a legacy domain.

• The term “migration goals” refer to the business and technical goals that will dictate and define the selection of the required approach, and hence the selection of the required migration path(s). Determination of the migration goals depends and builds upon an understanding of the following:

♦ The design status of the existing legacy domain infrastructure

♦ The design requirements for the new Windows Server 2003 Active Directory infrastructure

♦ The business drivers and requirements for the migration project

♦ The technical drivers and requirements for the migration project

• Note that the defined migration goals provide the foundation for the execution of an analysis into the results of the design gap analysis, to identify all potential “migration issues” associated with the migration (upgrade or migration) of a legacy domain.

• The term “migration issues” refer to all potential problems strictly associated with a legacy domain and its “domain components”, identified via analysis of the results of the design gap analysis (see later for details), which will preclude the use of the “default migration path”. For example, an organisation may identify a single Windows 2000 domain in a single forest, which requires migration to a single Windows Server 2003 Active Directory forest and domain. This identified “similarity” (see later for definition of similarities and differences) indicates the “default migration path” of an “upgrade”. However, a technical migration goal has identified that the new Windows Server 2003 Active Directory forest is to have a “clean” Schema, and not “inherit” any legacy Schemas from legacy forests. The results of the design gap analysis identify that the legacy Windows 2000 forest has custom Schema extensions no longer required, and hence this represents a “migration issue”, as an “upgrade” of the legacy Windows 2000 domain and forest would retain these custom



Schema extensions. It is thus necessary to change the “default migration path” from an “upgrade” to a “clone”, to respect the defined migration goals.

• The term “default migration path” refers to the migration paths dictated by a null hypothesis not yet disproved. Where the first null hypothesis for this process (see “Process Approach” section for details) is still in effect for a legacy domain, then the in-place migration paths (“A” or “B”, as appropriate to the version of the legacy domain) represent the “default migration path” for that legacy domain. However, where it is possible to disprove the first null hypothesis for a legacy domain, then the second null hypothesis is in effect for that legacy domain. If it is not possible to disprove the second null hypothesis for this legacy domain, then the domain migration paths (“C” or “D”, as appropriate to the version of the legacy domain) represents the “default migration path”. Note that this design methodology does not assign a “default migration path” to a legacy domain where it is possible to disprove both the first and second null hypothesis, and instead the organisation is required to select, design, and execute one of the extended migration paths for that legacy domain.

• The term “domain components” refer to a domain itself, and all contents and metadata aspects of the domain, including, for example, the following:

♦ The domain controllers within the domain, and all metadata aspects of these domain controllers, such as their operating system version, server hardware platform, hardware specifications, their logical and physical location and distribution within the organisation, and so on

♦ The directory objects and data within a domain

♦ The replication topology for the domain / domain infrastructure, and so on

• The term “domain creation dependencies” refers to the presence of dependencies upon the creation of the new Windows Server 2003 domains (via the in-place upgrade of existing legacy domains, or the creation of pristine new Windows Server 2003 domains to support migration from legacy domains). For example, as it is necessary to create the forest root domain first, where it is possible to identify the requirement to create this root domain via the in-place upgrade of an existing legacy domain, then the upgrade of this legacy domain generates a dependency upon all other domain migrations associated with the same target forest. The identified domain creation dependencies will influence the design for:

♦ Specific migration paths, and

♦ The migration schedule and communications plan

• The term “domain mapping” refers to the mapping of a “legacy domain”, and either all of its directory objects and data, or just specific directory objects and data, to a “target” Windows Server 2003 domain. This design methodology supports four categories for the mapping of legacy domains to Windows Server 2003 domains, with each category only supporting, by design, specific migration paths, which reflect the approach for this process. See below for details of the approach, and see within this process the step “determination of the required migration approach”, for details of the supported migration paths for each category. The four categories for mapping of legacy domains to Windows Server 2003 domains are:

♦ The one-to-one mapping of an entire legacy domain with an entire target Windows Server 2003 domain

♦ The one-to-many mapping of a single legacy domain to two or more target Windows Server 2003 domains

♦ The many-to-one mapping of two or more legacy domains to one target Windows Server 2003 domain



♦ The many-to-many mapping of two or more legacy domains to two or more target Windows Server 2003 domains


As stated in the “Process Objectives” section of this process, the objective of the migration strategy is to determine the required approach for the migration of the entire legacy domain infrastructure to the new Windows Server 2003 Active Directory infrastructure.

The determination of this required approach is dependent upon the identification of any potential migration issues associated with the migration of a legacy domain, that in turn reflect defined migration goals for this project.

The determination of the migration goals rely upon the identification of the design differences and similarities between the legacy and new (Windows Server 2003 Active Directory) domain infrastructures, and the business and technical goals and drivers for this project. In order to determine the design differences and similarities between the legacy and new domain infrastructures, it is necessary to execute a design gap analysis.

When executing this process to determine the migration strategy for this project, the recommended approach is to “keep it simple”, with respect to the migration strategy requirements, the required migration goals, and the selection of the migration path(s).

It is very important to understand that the selection of the appropriate migration path for one or more legacy domains can influence the success of the entire migration project. It is hence imperative that an organisation takes a careful and considered approach towards the selection of a migration path, and not make any hasty and unconsidered selections. The selected migration paths must reflect all migration requirements, goals, and support the resolution of all migration issues associated with each legacy domain.

The process “understanding supported migration paths” identified three types of migration paths, as “simple”, “optional”, and “extended”, where “extended” migration paths represent combinations of simple and optional migration paths. However, it is very important to note that this design methodology recognises that only the “simple” migration paths represent a “migration”, as these paths perform the actual migration of legacy directory data and objects from a legacy domain to a Windows Server 2003 domain. The optional migration paths only perform pre-migration or post-migration domain consolidation, and are hence not “true” or “actual” migration paths.

This design methodology hence recommends execution of the following approach to determine the required migration paths:

• Use the simple in-place upgrade migration paths (“A” and / or “B”) for all legacy domains, unless it is possible to identify that the use of a simple in-place upgrade paths do not support the following:

♦ Meet all of the migration requirements and goals, and / or

♦ Resolve all migration issues, or

♦ Support all migration requirements and goals, and resolve all migration issues alone, or without the use of a supplementary optional migration path (“E”, “F”, “G”, “H”)

• Where it is not possible to use in-place upgrade migration paths, alone or without the supplementation optional migration paths, then evaluate the requirements for use of the simple domain migration paths (“C” and / or “D”). The stipulation of this step supports the fact that it is still simpler to execute a simple domain migration path than an extended migration path that incorporates a simple in-place upgrade path.

• Where it is possible for the simple domain migration paths to support all migration requirements, goals, and resolve all migration issues, then use these paths.



• However, where it is not possible to use the simple domain migration paths alone, or without the use of a supplementary optional migration path (“E”, “F”, “G”, “H”), then determine the requirements for the use of any of the optional (as extended) migration paths. This hence includes either the use of an in-place upgrade (“A” and / or “B”) or domain migration path (“C” and / or “D”).

To reflect this focus on the “simple” migration paths (represented by migration paths “A”, “B”, “C”, and “D”) as the actual migration paths, and to support the recommendations outlined above for the execution of this process, this design methodology states the following two null hypotheses for this process:

1. The first null hypothesis for this process states:

“The design and execution of an in-place upgrade, supported by the simple migration paths “A” and “B”, will support (alone) all migration requirements for all legacy Windows NT 4.0 and / or Windows 2000 domains within an organisation. It is hence not necessary to design and execute any domain migrations, supported by either of the other two simple migration paths (“C” and “D”), or the additional use of other optional (domain consolidation) migration paths (“E”, “F”, “G”, and “H”), as extended migration paths”, were appropriate to the version of a legacy domain.

2. The second null hypothesis for this process states:

“Where it is possible to disprove the first null hypothesis, and hence prove the unsuitability of an in-place upgrade migration path (using migration paths “A” or “B”), then the alternative domain migration paths (using the simple migration paths “C” and “D”) will support (alone) all migration requirements for these legacy domain. It is hence not necessary to design and execute any additional other domain migration paths, represented by the extended migration paths”.

It is very important to note the words “alone” and “additional” in the above null hypotheses, as these words support the potential selection, design, and execution of extended migration paths. For example, if the current “default migration paths” cannot alone support all of the migration requirements and goals, and resolve all migration issues, then it may be necessary for the selection, design, and execution of an additional optional migration path, represented as an extended migration path. Hence, disproving a null hypothesis does not automatically preclude the use of the associated default migration paths, but just in their sole capacity to support all of the migration requirements and goals, and resolve all issues associated with the migration of legacy domains.

The following flow diagram illustrates the logic behind these two null hypotheses:

“Default Migration Path” “Default Migration Path”

It is possible to

disprove the first null

hypothesis?

Use “simple domain cloning” approach

Legacy Windows NT 4.0 and / or Windows

2000 domain

First Null Hypothesis

In-place upgrade (paths “A” and / or “B”)

Legacy Windows NT 4.0 and / or Windows

2000 domain

Use “in-place upgrade” approach

NO

YES

It is possible to

disprove the second null hypothesis?

NO

Select an extended migration path for

design and execution, for one or more legacy

domains

YES

Second Null Hypothesis

Domain cloning (paths “C” and / or “D”)

For one or more legacy Windows NT 4.0 / Windows 2000

domains


domains


domains


domains




Figure 43.1: Flow Diagram to Illustrate Null Hypotheses for Determination of Required Migration Strategy

After stating these null hypotheses, it is necessary to conduct an analysis to disprove the first null hypothesis and hence determine the requirements for either:

• The design and execution of any of the domain migration paths, represented by the other simple migration paths “C” and “D”, or

• The design and execution of an extended migration path using an in-place upgrade approach

Where it is possible to disprove the first null hypothesis, then the second null hypothesis for this process takes effect and it hence necessary to disprove this hypothesis. Disproving the second null hypothesis will hence identify the requirements for either:

• The selection, design, and execution of any of the other domain migration paths, represented by the extended migration paths, using a domain migration method, or

• The design and execution of an extended migration path using an in-place upgrade approach

This approach, to initially recommend the use of in-place upgrade migration paths (“A” and / or “B”) for all existing legacy domains, reflects the simplicity of these migration paths in comparison to the complexity associated with the design and execution of the migration paths (“C” and / or “D”). This approach hence permits the careful evaluation and identification of justifiable requirements to employ a more complex migration solution than the current “default migration path”, as a simple domain migration (using paths “C” or “D”), and then an even more complex migration solution, as any of the extended migration paths.

However, the in-place upgrade migration paths may not be appropriate for some or all of the existing legacy domains, based upon identified and defined business and technical requirements. The migration goals hence represent the foundation for the migration strategy, and a reflection of the results of the design gap analysis. Thus, identification of one or more migration requirements (based upon one or more migration goals and issues), which migration paths “A” or “B” cannot support, hence justifies the selection of an alternative, more complex, migration path (“C” or “D”, as appropriate to the version of legacy domain), or ultimately the extended migration paths, as appropriate.

To reflect the requirements to disprove these null hypotheses, and to respect the above chain of dependent activities within this process, this design methodology proposes the following approach for the execution of this process:

1. Execute a design gap analysis between the required design for the target Windows Server 2003 Active Directory infrastructure, and the design of the existing legacy domain infrastructure(s) to determine all design similarities and differences

2. Determine the business and technical migration goals for this project

3. Analyse the results of the design gap analysis and evaluate against the defined migration goals to identify all migration issues

4. Determine the required approach for the migration of the legacy domains and domain infrastructure(s), and select the required migration path for each in-scope legacy domain

5. Determine the domain creation dependencies

The following diagram illustrates how each of these steps in the above approach for the execution of this process depends and builds upon the results of the other components:



DETERMINATION OF MIGRATION STRATEGY

ANALYSIS OF LEGACY DOMAIN INFRASTRUCTURES

Current design of legacy Windows NT 4.0 domain infrastructure(s)

Current design of legacy Windows 2000 Active Directory infrastructure(s)

EXECUTION OF DESIGN GAP ANALYSIS

IDENTIFICATION OF MIGRATION ISSUES

DESIGN OF REQUIRED MIGRATION PATH(S)

DETERMINATION OF MIGRATION GOALS

IDENTIFICATION OF DOMAIN CREATION DEPENDENCIES

DETERMINATION OF REQUIRED MIGRATION APPROACH

DESIGN OF MIGRATION SCHEDULE

DESIGN OF MIGRATION COMMUNICATIONS PLAN

PROCESS COMPONENTS

PROCESS


Figure 43.2: Illustration of Dependencies between Components of Migration Plan


Based upon the above approach, this process is composed of the following five components:

• Execution of a design gap analysis

• Determination of the migration goals

• Identification of migration issues

• Determination of required migration approach and selection of migration paths

• Identification of domain creation dependencies



• The execution of a design gap analysis to identify the design differences between the existing legacy domain infrastructure(s) and the new proposed Windows Server 2003 Active Directory infrastructure

• The results of the design gap analysis, identifying the design similarities and differences between the legacy and new domain infrastructures

• The defined migration goals for this migration project, based upon the business and technical goals and drivers for this project, and the results of the design gap analysis

• The identified migration issues associated with one or more legacy domains, as a reflection of the defined migration goals for this project

• The required migration approach for the migration of the in-scope legacy domain(s) to the new Windows Server 2003 Active Directory infrastructure

• The selected migration path(s) to migrate all in-scope legacy domains to the new Windows Server 2003 Active Directory infrastructure

• The identified domain creation dependencies





Migration Plan – Inter-Component Dependencies for Determination of Required Migration Strategy

START Execution of Design Gap Analysis

Identification of Migration Issues

Determination of Migration Goals

Determination of Required Migration

Approach

Determination of Domain Creation

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

4.8. Process to Determine the Required Migration Strategy

Migration Plan – Process to Determine the Required Migration Strategy


STARTExecute

B1

Execute

A1

END

Execute

B2

Does the organisation

have one or more legacy Windows

NT 4.0 domains?

NO

YESExecute

A2

Does the organisation

have one or more legacy Windows

2000 domains?

Execute

A3YES

Execute

A4NO

Execute

A5 – A8

Execute

B3

Execute

A9

Execute

B4

Execute

A10

Execute

B5

Execute

A11


Consider the following information when executing this process to determine the migration strategy for this migration plan.

Presented within the following five sections are the considerations for this process:

1. Considerations for the execution of the design gap analysis

2. Considerations for the determination of the migration goals for this migration project

3. Considerations for the identification of migration issues in legacy domains

4. Considerations for the determination of the required migration approach

5. Considerations for the determination of the domain creation dependencies

4.9.1. Execution of Design Gap Analysis

Consider the following information when executing a gap analysis between the design of the existing legacy domains and domain controllers, and the target Windows Server 2003 Active Directory infrastructures:

• Factor B1: Understanding the objectives of the design gap analysis

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the requirements for the execution of a design gap analysis.




So far, at this stage in the project, it is possible to identify the following information:

The design for the new Windows Server 2003 Active Directory infrastructure

The identification of the legacy Windows NT 4.0 and / or Windows 2000 domains within the scope of this migration plan

The objective of the migration strategy is to take the existing legacy domain environment and migrate it to the new designed Windows Server 2003 Active Directory environment. To determine the most appropriate approach, or set of approaches to perform this migration, it is hence necessary to:

Understand the design requirements of the new Windows Server 2003 Active Directory environment

Understand the current design aspects of the legacy domain environment(s)

Understand the differences and similarities between the designs for these two logical domain environments

The objectives of the design gap analysis are to hence:

Analyse and summarise the design of the legacy domain infrastructure(s)

Analyse and summarise the design of the target Windows Server 2003 Active Directory infrastructure

Perform a gap analysis against the design summaries to identify all design similarities and differences between the legacy and target infrastructures that will:

Influence the determination of the migration goals, and hence selection of the appropriate migration path(s)

Influence the design for coexistence between the legacy and new domain infrastructures during the migration phase for this project

When executing steps below to generate the design summaries for the legacy and new domain infrastructures, it is hence important to gather all pertinent information that will also influence the design for coexistence.

Note that the process “design of the required migration path(s)” (see later) will also incorporate the process and considerations for the design of the coexistence phase of the migration project.

• Factor A1: Summarise design of target Windows Server 2003 Active Directory infrastructure

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation is required to generate a summary of the design for the target Windows Server 2003 Active Directory infrastructure.


When generating a summary of the design for the new proposed Windows Server 2003 Active Directory infrastructure, this design methodology recommends the inclusion of only pertinent design aspects of the new domain infrastructure that will influence the determination of the migration strategy.



This design methodology provides the following examples of the required information:

The number of Windows Server 2003 Active Directory forests required, and the required relationships between the forests (federated forest infrastructures)

The number of domains required within each required Windows Server 2003 Active Directory forest

The design requirements for the Active Directory Schema for each required Windows Server 2003 forest

The structure and relationships between multiple domains within each required forest (where appropriate)

The domain design requirements, identifying the directory objects and data each new domain is expected to host and support

The number of Windows Server 2003 domain controllers required for each domain, and the following information about these domain controllers:

The required geographical distribution of these domain controllers within the organisation

The minimum hardware specifications for these Windows Server 2003 domain controllers, detailing:

• CPU numbers, type, and specifications

• RAM amount, type, and specifications

• HDD numbers, type, capacities, and specifications

• NIC numbers, type, and specifications

The following details of the Site infrastructure for each identified forest:

The number of Sites required

The Site Link topology

The WAN link requirements to support the replication topology for each required forest, such as:

• The required WAN link type (ADSL, Frame Relay, ATM, Fibre, and so on)

• The SLA requirements for the WAN links by the service provider(s)

• The minimum predicted available bandwidth requirements for all WAN links to connect all required domain controllers within each forest and supporting Site infrastructure

The following design details for the DNS infrastructure supporting the Windows Server 2003 Active Directory infrastructure:

The number of DNS servers required, and their required geographical distribution within the organisation

The high-level details of the design illustrating how the DNS infrastructure will support existing and future DNS clients



Note that the above list is not exhaustive, and that is not necessary to include excessive details in the summary that will not influence the determination of the migration strategy.

Using the above information, generate a summary of the design for the new Windows Server 2003 Active Directory infrastructure, and document in tabular format.

• Factor A2: Summarise design of source Windows NT 4.0 domain infrastructure(s)


Has identified one or more existing Windows NT 4.0 domain infrastructure(s) within the scope of this migration plan, and

Is required to generate a summary of the design for the source legacy Windows NT 4.0 domain infrastructure(s)


Although the onus is with the organisation to generate the summary of the current design for a legacy Windows NT 4.0 domain infrastructure, this design methodology provides the following guidance for design aspects that require analysis and summarisation:

The number of existing Windows NT 4.0 domains, and the high-level function / role of the domains, such as account or resource domains, and so on

The contents of each domain, identifying the directory objects (users, computers, groups, and so on) and data (user account policies, trust relationships, audit policies, and so on) the domain currently supports and are within the scope of migration

The trust relationships between multiple existing Windows NT 4.0 domains

The number of Windows NT 4.0 domain controllers present within each existing Windows NT 4.0 domain, and the following information about these domain controllers:

The current geographical distribution of these domain controllers within the organisation

The existing hardware specifications for these Windows NT 4.0 domain controllers, detailing:



• HDD numbers, type, capacities, free disk space, and specifications


• Feasibility for upgrades to the CPU, RAM, HDD, and NIC where appropriate

The details of the network links, between each geographical location where a Windows NT 4.0 domain is represented by a BDC, that support the replication topology for each domain, identifying the following:



The current type(s) of WAN links that connect remote locations where BDCs for a Windows NT 4.0 domain currently reside

The details of the WAN topology that connects all remote locations

The details of the SLAs provided for the WAN links by the service provider(s)

The current levels of available bandwidth within the WAN links, within a typical working week (midnight Monday to midnight Saturday)

The following design details for the WINS infrastructure supporting name resolution for the existing Windows NT 4.0 domain infrastructure:

The number of WINS servers required, and their required geographical distribution within the organisation

The high-level details of the design illustrating how the WINS infrastructure supports existing WINS clients

As for the Windows Server 2003 Active Directory infrastructure, note that the above list is not exhaustive, and that is not necessary to include excessive details in the summary that will not influence the determination of the migration strategy.

Using the above information, generate a summary of the design for the existing Windows NT 4.0 domain infrastructure, and document in tabular format.

• Factor A3: Summarise design of source Windows 2000 domain infrastructure(s)


Has identified one or more existing Windows 2000 domain infrastructure(s) within the scope of this migration plan, and

Is required to generate a summary of the design for the source legacy Windows 2000 domain infrastructure(s)


Although the onus is with the organisation to generate the summary of the current design for a legacy Windows 2000 domain infrastructure, this design methodology provides the following guidance for design aspects that require analysis and summarisation:

The number of existing Windows 2000 Active Directory forests, and the presence of any trust relationships between the forests

The details of any custom modifications to the Active Directory Schema for each existing Windows 2000 forest

The number of domains present within each Windows 2000 Active Directory forest

The contents of each domain, identifying the directory objects (users, computers, groups, OUs, GPOs, and so on) and data (trust relationships, application data, and so on) the domain currently supports and is within the scope of migration.

The structure and relationships between multiple domains within each identified forest



The number of Windows 2000 domain controllers present for each domain, and the following information about these domain controllers:

The current geographical distribution of these domain controllers within the organisation

The existing hardware specifications for these Windows 2000 domain controllers, detailing:



• HDD numbers, type, capacities, free disk space, and specifications


• Feasibility for upgrades to the CPU, RAM, HDD, and NIC where appropriate

The details of the current Site infrastructure for each identified forest, identifying the following:

The number of Sites present

The Site Link topology

The following details of the current WAN link infrastructure required to support the replication topology for each required forest, such as:

• The current type(s) of WAN links that connect remote locations where domain controllers for a Windows 2000 domain currently reside

• The details of the WAN topology that connects all remote locations

• The details of the SLAs provided for the WAN links by the service provider(s)

• The current levels of available bandwidth within the WAN links, within a typical working week (midnight Monday to midnight Saturday)

The following design details for the current DNS infrastructure supporting the Windows 2000 Active Directory infrastructure:

The number of DNS servers present, and their geographical distribution within the organisation

The high-level details of the design illustrating how the DNS infrastructure will support existing and future DNS clients

As for the Windows Server 2003 Active Directory infrastructure, note that the above list is not exhaustive, and that is not necessary to include excessive details in the summary that will not influence the determination of the migration strategy.

Using the above information, generate a summary of the design for the existing Windows 2000 Active Directory infrastructure, and document in tabular format.

• Factor A4: Execution of design gap analysis between existing and proposed domain infrastructures




Has generated a summary of the following:

The proposed design for the new Windows Server 2003 Active Directory infrastructure

The design for the existing Windows NT 4.0 domain infrastructure(s) (where appropriate) and / or

The design for the existing Windows 2000 domain infrastructure(s) (where appropriate) and

Wishes to execute the design gap analysis to identify the any design similarities and differences between the legacy and new domain environments


Following the generation of the design summaries for the source and target domain infrastructures, it is possible to execute an analysis against them to identify any design similarities and differences between the legacy and new domain environments.

When executing the design gap analysis between the source and target domain infrastructures, consider the following:

The objective of the design gap analysis is to identify the following:

All similarities between the existing and proposed domain infrastructures

All differences between the existing and proposed domain infrastructures

Following completion of this gap analysis, it is necessary to pass the results to the next steps within this process, to determine the migration goals for this migration plan.

Based upon the example design aspects provided by this design methodology, which an organisation may wish to consider for analysis and summarisation, the design gap analysis may be required to identify and summarise the following information, where applicable:

The differences between the numbers of forests required for the Windows Server 2003 Active Directory infrastructure and the numbers of existing Windows 2000 forests, where appropriate, to identify:

• The number and identity of superfluous forests that require decommissioning following completion of all migration and coexistence activities, or

• The number of new forests required to support the design for Windows Server 2003 Active Directory infrastructure

The differences between the Active Directory Schema requirements for each new Windows Server 2003 Active Directory forest, and the legacy Windows 2000 forest(s), to identify:

• The presence of any custom modifications (addition of object classes and attributes / modification of attributes for existing object classes and attributes)

• The requirements to retain and reuse any existing custom Schema modifications in the legacy Windows 2000 forest(s)

• The requirements to not reuse any existing custom Schema modifications in the legacy Windows 2000 forest(s)



• The requirements to add new Schema modifications to one or more new Windows Server 2003 forests, where not currently present or supported in existing Windows 2000 forests

The differences between the numbers of domains required for the Windows Server 2003 Active Directory infrastructure and the numbers of existing Windows NT 4.0 and / or Windows 2000 domains, to identify:

• The number and identity of superfluous domains that require decommissioning following completion of all migration and coexistence activities, or

• The number of new domains required to support the design for Windows Server 2003 Active Directory infrastructure

The differences between the domain contents required / expected for each Windows Server 2003 domain and the current contents of each existing and in-scope legacy Windows NT 4.0 and / or Windows 2000 domain, identifying:

• The differences and similarities for specific directory objects

• The differences and similarities for specific directory data

The differences between the numbers of domain controllers required for each Windows Server 2003 domain and the numbers of existing Windows NT 4.0 and Windows 2000 domain controllers, to identify:

• The number and identity of superfluous domain controllers that potentially require decommissioning (as domain controllers) following completion of all migration and coexistence activities, or

• The number of new domain controllers required to support the design for Windows Server 2003 Active Directory infrastructure

The differences between the required geographical distribution of the Windows Server 2003 domain controllers within the organisation, and the geographical distribution of the existing legacy Windows NT 4.0 and / or Windows 2000 domain controllers, to identify:

• The number and identity of geographical locations where domain controllers are no longer required (due to closure of remote location; significant upgrades of WAN links, and so on), and hence superfluous domain controllers that require decommissioning (as domain controllers) following the completion of all migration and coexistence activities, or

• The number and identity of new geographical locations where there is a requirement to implement new Windows Server 2003 domain controllers to support the design for Windows Server 2003 Active Directory infrastructure

The differences between the hardware specifications for the Windows Server 2003 domain controllers and the existing Windows NT 4.0 and / or Windows 2000 domain controllers, to identify:

• The number and identity of existing domain controllers that fail to comply with the minimum hardware specifications for the new Windows Server 2003 domain controllers, and are not feasible for hardware upgrades, and hence require decommissioning following the completion of all migration and coexistence activities, or



• The number and identity of existing domain controllers that fail to comply with the minimum hardware specifications for the new Windows Server 2003 domain controllers, but are feasible to upgrade, and hence can be reused as Windows Server 2003 domain controllers during the execution of the pre-migration activities for their existing domain, or

• The number and identity of existing domain controllers that comply with, or even exceed, the minimum hardware specifications for the new Windows Server 2003 domain controllers, and hence can be reused as Windows Server 2003 domain controllers during the execution of the pre-migration activities for their existing domain

The differences between the replication topology requirements for the new Windows Server 2003 Active Directory infrastructure and the existing network and replication topology supporting the legacy Windows NT 4.0 and / or Windows 2000 domain infrastructures, to identify:

• The number and identity of the network links that fail to comply with the required type(s) of links and SLAs for the links, to support the replication topology for the new Windows Server 2003 Active Directory infrastructure, and hence require replacement / negotiation with service provider(s), and so on prior to reuse.

• The number and identity of the network links that comply with the required type(s) of links and SLAs for the links, to support the replication topology for the new Windows Server 2003 Active Directory infrastructure, and hence can be considered for reuse

• The number and identity of the superfluous network links that fail to support the design for the replication topology for each required Windows Server 2003 Active Directory forest, and hence require decommissioning.

• The number and identity of the network links required to support the design for the replication topology for each required Windows Server 2003 Active Directory forest, but require an upgrade (to comply with the minimum bandwidth requirements for the link) prior to reuse.

• The number and identity of the network links required to support the design for the replication topology for each required Windows Server 2003 Active Directory forest, which comply with the minimum bandwidth requirements for the link, and hence qualify for reuse.

The differences between the proposed name resolution infrastructure (using DNS) to support the Windows Server 2003 Active Directory infrastructure, and the existing WINS (for Windows NT 4.0) and / or DNS infrastructures, to identify:

• The number and identity of existing WINS servers potentially replaceable with DNS servers, subject to compliance with minimum hardware specification and geographical distribution requirements for the DNS servers.

• The number and identity of existing WINS servers no longer required and do not qualify for reuse as DNS servers, due to failure to comply with the minimum hardware specification and geographical distribution requirements for the DNS servers.

• The requirements for the coexistence of existing WINS and DNS servers during the migration and coexistence phases of this project

As per the approach proposed by this design methodology, it is first necessary to collate all design summaries into a table, to support the analysis.



The following table contains examples of identified design similarities and differences for an organisation with existing Windows NT 4.0 and Windows 2000 domains infrastructures and a completed design for a target Windows Server 2003 Active Directory infrastructure:

Aspect of Legacy Domain Infrastructure

Design of aspect in Windows Server 2003 Active Directory infrastructure

Design of aspect in Windows NT 4.0 domain infrastructure

Is domain aspect similar?

Design of aspect in Windows 2000 Active Directory infrastructure

Is domain aspect similar?

Summary

Number of forests One forest N/A N/A Two forests There is a requirement to decommission one forest

Number of domains One domain Two domains Three domains There is a requirement to decommission four extra domains

Total number of domain controllers

Eight domain controllers

Fourteen domain controllers Six domain controllers There is a potential* requirement to

decommission twelve extra domain controllers.

Geographic distribution of domain controllers

Two domain controllers in HQ and one domain controller in each of six (generic) remote office locations (locations 1, 2, 3, 4, 5, and 6)

Four domain controllers in HQ and ten domain controllers in ten remote office locations (locations 1 through to ten)

Two domain controllers in HQ and one domain controller in four remote office locations (locations 2, 4, 6, and 8)

There is a requirement to decommission two extra domain controllers in HQ, and one extra domain controller in locations 2, 4, 6, and 8.

Hardware specifications for domain controllers

All domain controllers are to have dual CPU (Pentium IV Xeon 3GHz; 512Kb L2 cache); 2Gb RAM; 7 x 36GB (RAID 1+ 0 x 2, RAID 5 x 1); 2 x Ethernet 100Mbps teamed NICs

Two domain controllers with dual CPU (Pentium III Xeon 550MHz); 512Mb RAM; 2 x 18Gb RAID 1, 1 x NIC (10/100 Ethernet); 12 domain controllers with one CPU (Pentium II Xeon 450MHz, 128Mb RAM, 2 x 9GB HDD, 1 x NIC (10/100 Ethernet)

Two domain controllers with dual CPU (Pentium III Xeon 1GHz, 512Kb L2 cache); 1GB RAM; 6 x 18GB HDD (3 x RAID 1); 2 x 100Mbps Ethernet team NICs);Four domain controllers with dual CPU (Pentium III Xeon 800MHz; 256Kb L2 cache); 1GB RAM, 6 x 18Gb HDD (6 x 18GB HDD (3 x RAID 1); 2 x 100Mbps Ethernet team NICs)

None of the existing legacy domain controllers matches or exceeds the minimum hardware specifications for the new Windows Server 2003 domain controllers, and hence it is not possible to reuse these domain controllers as production Windows Server 2003 domain controllers.

Levels of available bandwidth in WAN links

All WAN links are required to provide a minimum of 256Kbps of available bandwidth during a typical working week

All current WAN links that support replication between Windows NT 4.0 BDCs and the PDC for each domain have a minimum of 400Kbps available bandwidth during a typical working week

All current WAN links that support replication between Windows 2000 domain controllers have a minimum of 512Kbps available bandwidth during a typical working week

All existing WAN links exceed the minimum levels of available bandwidth to support distributed replication of the Windows Server 2003 Active Directory infrastructure

And so on…

Table 43.1: Examples of Domain Design Similarities and Differences

*Requirement for decommissioning excess number of domain controllers is only a potential requirement until the evaluation of server hardware differences is completed.

Using the above information, execute the design gap analysis and identify the differences and similarities between the current design for the legacy domain infrastructure(s) and the design for the new Windows Server 2003 Active Directory infrastructure.

4.9.2. Determination of the Migration Goals

Consider the following when determining the migration goals to support the migration strategy for this project:

• Factor B2: Understanding migration goals and the requirements for their determination

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concept of migration goals, and the requirements for their determination.




Consider migration goals as the primary drivers for the design and execution of the entire migration project. They influence and define the following aspects of a migration project:

The determination of the migration strategy for the selection of the required migration approach

The selection of the appropriate migration path(s) for each in-scope legacy domain

The design of the pre-migration, migration, and post-migration tasks for specific migration paths

The design of the migration schedule for this migration project

The design of the migration communications plan for this migration project

A migration goal is any business or technical requirement, consideration, or deliverable that will influence the design and execution of the migration project. Hence, prior to the analysis, design, and execution of any of the above components of the migration plan, it is important to identify and define all of the appropriate business and technical requirements.

It is possible to partition migration goals into the two broad categories, business migration goals, and technical migration goals. This design methodology proposes the following approach towards the determination of the business and technical migration goals for this migration project:

Determine the business and technical migration goals for the determination of the migration strategy for this project, and the selection of the migration path(s)

Determine the business and technical migration goals for the design of the migration path(s)

Determine the business and technical migration goals for the design of the migration schedule for this project

Determine the business and technical migration goals for the design of the migration communications plan for this project

• Factor A5: Determination of migration goals to influence the determination of the migration strategy and selection of the migration paths

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the business and technical migration goals that will influence the:

Determination of the migration strategy for this migration project, and

Selection of the appropriate migration path(s) for the legacy domains


The migration goals, which will influence the determination of the migration strategy and selection of the migration path(s), must reflect the requirements for the migration of both individual legacy domains and the entire legacy domain infrastructure(s) to the new Windows Server 2003 Active Directory infrastructure.



The migration requirements reflect all the events, risks, and opportunities related to the migration that the organisation wishes to seek and avoid. For example, an organisation may wish to seek opportunities to reduce financial overheads associated with the migration of a legacy domain, and avoid specific types of risks to the production environment from the execution of a migration.

The first null hypothesis for this process states that the design and execution of the in-place upgrade simple migration paths “A” and “B”, for the migration of all existing legacy domains, will support all business and technical requirements for this migration project. If it is not possible to identify any contradictory business and technical requirements, which predispose the selection of any of the other simple and optional migration paths, then only migration paths “A” or “B” are required, as appropriate, for all existing legacy domains.

The objectives of this step are hence to identify all business and technical migration goals and requirements that may influence:

The opportunity to disprove the first null hypothesis, and hence require an organisation to consider the alternative simple migration paths “C” and “D”, from the subsequently activated second null hypothesis, and

The opportunity to disprove the second null hypothesis and hence require an organisation to consider the alternative extended migration paths for legacy domains

This design methodology hence proposes the following approach to support these objectives:

Analyse the results of the design gap analysis for each in-scope legacy domain, and identify all similarities and differences between the design aspects of the entire legacy domain infrastructure(s) and the target Windows Server 2003 Active Directory infrastructure.

Use the results of the design gap analysis to identify all of the key business requirements that may be influenced by the execution of any of the migration paths this design methodology supports for the following example categories (note that the onus is with the organisation to define their own categories for business migration goals):

Compliance with requirements to preserve business continuity

Compliance with financial budgets for the migration project

Compliance with current administrative overheads

Compliance with migration project timescales

Compliance with requirements to maintain the profile of the project

Compliance with timescales and dependencies on and from other parallel projects

Define the criteria to measure compliance with each defined business migration goal

Use the results of the design gap analysis to identify all of the key technical requirements that may be influenced by the execution of any of the migration paths this design methodology supports for the following example categories (the onus is with the organisation to define their own categories for technical migration goals):

Compliance with requirements to preserve existing directory objects and data



Compliance with requirements for the implementation of a pristine Windows Server 2003 Active Directory infrastructure

Compliance with the design requirements of the new Windows Server 2003 Active Directory infrastructure

Define the criteria to measure compliance with each defined technical migration goal

When determining the business and technical migration goals to influence the determination of the migration strategy and selection of the migration path(s), consider the following:

This design methodology provides the following examples of business migration goals based upon the example categories illustrated above:

Compliance with requirements to preserve business continuity:

• The migration project must not, in any way, disrupt the continuity of existing production domain environment

• The migration project must preserve the presence and operation of legacy domain controllers (Windows NT 4.0 and / or Windows 2000) where business critical applications, processes, services depend upon these domain controllers, and hence will influence business continuity

• The migration project must prevent any reduction in focus on the maintenance and support of the existing domain infrastructure by domain administrators during the migration phase, via their excessive involvement in complex migration activities

• The migration project must reduce the mean time between failures where possible, via a phased approach, and a simple and effective roll back and recovery process

• The migration path must use third party proprietary tools to execute the migration tasks (where required by a migration path), to:

♦ Reduce the risks associated with the execution of all relevant migration activities

♦ Simplify the migration process

♦ Reduce administrative overheads and training

♦ Support a phased and controlled migration approach

• The migration project must not compromise the security integrity of any aspect of the current production environment

Compliance with financial budgets for the migration project:

• The migration project must reuse existing server hardware where possible, as this project cannot afford new server hardware unless explicitly required

• The migration project must use free supported (by Microsoft) migration tools (such as ADMT, ClonePrincipal, and so on) where a migration path requires the tools, and not invest in costly third-party tools and associated licenses, and so on.



• The migration project must be completed prior to the end of the current financial year / budget deadline, and the next financial year budget will not support the migration

Compliance with current administrative overheads:

• The migration project must respect the current limitations and deficits in resource skills and experience

• The migration project must respect the current and predicted resource availability and utilisation levels, and hence not adopt a long and complex approach, that will demand skilled resources for long periods.

Compliance with migration project timescales

• All migration and coexistence activities for the migration project must start by the defined and set date

• All migration and coexistence activities for the migration project must be completed by the defined set date

• The migration project must not adopt a migration path that requires a significant time to initiate, execute, and complete.

Compliance with requirements to maintain the profile of the project within the organisation:

• The migration project must support the attainment of multiple defined quick wins, to maintain the profile of the project within the organisation, via the demonstration of positive advances in the migration.

• The migration project must not disrupt user productivity and business continuity

Compliance with timescales and dependencies on and from other parallel projects:

• The migration project must be completed by a set date to respect a dependency it generates on the initiation / continuation of other parallel projects, such as the:

♦ Design and deployment of a new standard client computer build, using Windows XP Professional SP2

♦ Design and deployment of a new Exchange Server 2003 infrastructure

• The migration project must not prevent or delay the execution of any component of other equal priority parallel projects within the organisation

This design methodology provides the following examples of technical migration goals based upon the example categories illustrated above:

Compliance with requirements to preserve existing directory objects and data:

• The migration project must not disrupt user productivity, or raise the level of support required following completion of the migration activities.

• The migration project must not break or disrupt any business and application processes currently dependent upon features of the legacy domain infrastructure



• The migration project must not involve the extensive manual recreation of directory objects and data

Compliance with requirements to implement a pristine Windows Server 2003 Active Directory infrastructure:

• The migration project must not inherit any legacy directory objects and data which:

♦ Requires extensive time-consuming pre-migration directory clean up tasks to remove redundant and unwanted objects and data

♦ Cannot be removed from the legacy domain infrastructure, such as custom modifications to the Active Directory Schema in a legacy Windows 2000 forest

• The new Windows Server 2003 Active Directory infrastructure must not be required to support legacy domain controllers, as there is a requirement to utilise one or more new Active Directory features associated with the “Windows 2000 Native” and / or “Windows Server 2003” domain / forest functional level

Compliance with the design requirements of the new Windows Server 2003 Active Directory infrastructure:

• The migration project must ensure compliance with all of the design requirements and specifications associated with the new Windows Server 2003 Active Directory infrastructure. For example, all domain controllers must comply with the minimum hardware specifications for the new Windows Server 2003 domain controllers, and not operate on legacy servers that do not comply with these specifications.


Analyse the results of the design gap analysis to identify all design similarities and differences between the legacy and new domain infrastructures

Define and document the categories to support the identification of business migration goals

Determine and document the required business migration goals for this migration project, and the criteria to measure compliance with each defined goal

Define and document the categories to support the identification of technical migration goals

Determine and document the required technical migration goals for this migration project, and the criteria to measure compliance with each defined goal

• Factor A6: Determination of migration goals to influence the design and execution of the migration paths

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the business and technical migration goals that will influence the design and execution of the migration paths.


The design and execution of the migration paths must comply with the migration goals defined within this step of this process. Since, at this stage in the project, the actual



migration paths are undetermined, it is necessary to define only high-level business and technical goals, and not specific goals and requirements.

It is important to note that the majority of earlier defined business and technical goals to influence the determination of the migration strategy and selection of the migration path, will also influence the design of selected migration paths. However, it is possible to define additional requirements, specific to the design and execution of the pre-migration, migration, and post-migration activities associated with specific migration paths.

Use the same approach outlined above to determine the business and technical goals to influence the design and execution of the migration paths, using the following examples provided by this design methodology for guidance:

The design and execution of the pre-migration directory clean up tasks must include precautions and processes to prevent the deletion of any directory objects and data from the existing directory service infrastructure that will disrupt continuity of the production environment.

The design for the migration path must include a design for a contingency plan for each required migration path. The design for the contingency plan must include the following minimum components:

The process to take a snapshot of the existing production environment, collecting all necessary information required to restore the production environment to its current state

The criteria for the execution of the contingency plan

The process to completely restore an existing production environment in the event of compliance with the criteria for the execution of the contingency plan

The pre-migration tasks must include the design for the execution of the contingency plan to perform, for example, backups of domain controllers, documentation of all existing configurations, and so on.

The design for the migration path must include a design for a coexistence plan, to permit parallel interoperation of both legacy and new domain infrastructures during the length of migration project.

It must be possible to remove completely all traces of any pilot Windows Server 2003 Active Directory environment(s), generated during the migration phase, where necessary.

The execution of the migration path must not disrupt user productivity, or raise the level of support required following completion of the migration activities. The following additional example requirements support this technical goal:

There is a requirement for the migration to preserve the user passwords, but not compromise the design for the password policy / policies in the new Windows Server 2003 Active Directory infrastructure.

There is a requirement to preserve the names for the user and computer accounts, but not compromise the design for the object naming models in the new Windows Server 2003 Active Directory infrastructure.

There is a requirement to preserve appropriate elements of the existing domain infrastructure for as long as possible, to support the execution of a quick and simple contingency plan.



The migration path must support the consolidation of multiple existing security groups within a legacy domain to a fewer number of groups in a target Windows Server 2003 domain.

Using the above information, execute the following:

Determine and document the business and technical goals to influence the design and execution of all migration activities for this project

Define and document the criteria for compliance with each defined business and technical migration goal

• Factor A7: Determination of migration goals to influence the design and execution of the migration schedule

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the business and technical migration goals that will influence the design and execution of the migration schedule.


The migration schedule is essential to the coordination of all migration activities. The schedule will hence generate an impact on the following aspects of the migration project:

The utilisation and availability of resources within the organisation to assist / execute the migration tasks

The schedule for the realisation of dependencies generated by the migration project on other parallel projects and other business processes and events

The design of the migration schedule must hence ensure compliance with defined business and technical goals. Use the same approach outlined above to determine the business and technical goals to influence the design of the migration schedule, using the following examples provided by this design methodology for guidance:

The design of the migration schedule must ensure that migration activities will potentially not disrupt key business dates, such as the end of a calendar month, the end of a financial / calendar quarter, the end of a financial year, and so on.

The design of the migration schedule must respect the predicted availability and utilisation of resources essential to the supervision and execution of the migration activities. For example, it may be possible to identify the assignment of these resources to other parallel projects or activities, or absent on predicted annual / maternity / paternity / sick leave, and so on.


Determine and document the business and technical goals that will influence the design of the migration schedule for this project


• Factor A8: Determination of migration goals to influence the design and execution of the migration communications plan

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the business and technical migration goals that will influence the design and execution of the migration communications plan.




The migration communications plan is probably one of the most essential components of the migration plan. Its objective is to ensure that all users within the organisation, directly or indirectly, affected by the migration are aware of the migration project, and its potential impact on their productivity. Awareness of the objectives, status, and schedule of the migration project by affected users can influence the perceived success of the project.

The design of the migration communications plan must hence ensure compliance with defined business and technical goals. Use the same approach outlined above to determine the business and technical goals to influence the design of the migration communications plan, using the following examples provided by this design methodology for guidance:

The migration communications plan must deliver communications about the project from just prior to the start of any pilot phase activities, and continue through the migration and coexistence phase of the project, with regular updates.

The migration communications plan must support different levels of communications and content to support defined types / categories of target users. For example:

Detailed information for project stakeholders, but summarised information for non-stakeholders

Technical information for IT department users, or non-technical information for non-IT department users, and so on


Determine and document the business and technical goals that will influence the design of the migration communications plan for this project


4.9.3. Identification of Migration Issues

Consider the following when identifying any issues associated with the migration of the in-scope legacy Windows NT 4.0 and / or Windows 2000 domains:

• Factor B3: Understanding migration issues

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concept of migration issues, prior to their identification for this migration project.


As described in the “Background Information” section of this process, this design methodology defines a “migration issue” as anything that will preclude the selection, design, and execution of the current “default migration path”.

The current “default migration path” refers to either migration paths “A” or “B”, as appropriate, for the legacy domain based upon the recommended approach by this design methodology to perform (see “Process Approach” for details). This current “default migration path” remains in effect for all in-scope legacy domains, until it is possible to disprove the first null hypothesis for a legacy domain, in which case the “default migration path” changes from an in-place upgrade to a domain migration path.



For example, it is possible for an organisation to identify four in-scope legacy Windows NT 4.0 domains, and the requirement for the implementation of four Windows Server 2003 domains. The current “default migration path” is path “A” for each legacy domain, which will take precedence unless it is possible to identify any “migration issues” that prevent the use of this path and hence disprove the first null hypothesis, based upon defined business and technical migration goals.

Note that even where an organisation has four legacy Windows NT 4.0 domains, and the requirement for the implementation of only one Windows Server 2003 domain, then the “default migration path” for each legacy domain is still path “A”, regardless of the mismatch in the number of source and target domains. The fact that there is a mismatch and the resultant upgrades will generate more Windows Server 2003 domains than required hence identifies a “migration issue”.

Migration issues hence reflect a combination of the following:

Fundamental design differences identified from the design gap analysis

The defined business and technical migration goals that will influence the determination of the migration strategy and selection of the migration path(s)

Identified migration issues will directly influence the following:

Determination of the required migration approach for the migration strategy

Selection of the required migration paths for each in-scope legacy domain

Design of the migration path and coexistence strategy for the migration phase

• Factor A9: Identification of migration issues

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to identify all migration issues associated with the migration of each in-scope legacy domain to Windows Server 2003 Active Directory.


When identifying the migration issues associated with each in-scope legacy domain, consider the following:

This design methodology proposes the following approach to identify all migration issues:

Analyse the results of the design gap analysis to identify all primary design differences between the legacy domain infrastructure(s) and the new Windows Server 2003 Active Directory infrastructure

Analyse the defined business and technical migration goals that will influence the determination of the migration approach and selection of the required migration path(s), to identify all pertinent goals that will assist in the identification of migration issues

Assign each in-scope legacy domain the in-place upgrade migration path “A” or “B” (as appropriate to the version of legacy domain)

Evaluate the results of the design gap analysis and the defined business and technical migration goals and identify all migration issues that will prevent the use of the in-place upgrade migration paths “A” and / or “B”, as appropriate to the version of legacy domain.



Using this approach complies with the requirement to disprove the first null hypothesis stated in the “process approach” section of this process. Only where it is possible to identify “migration issues” associated with the migration of a legacy domain, using migration path “A” and / or “B”, is there hence a justifiable requirement to adopt an alternative migration path (“C” or “D”).

When evaluating the results of the design gap analysis and the defined business and technical migration goals to identify migration issues, this design methodology provides the following simple examples:

It is possible to identify a migration issue where a design difference between the current legacy and new Windows Server 2003 Active Directory infrastructure precludes the use of migration path “A” or “B”, such as:

The organisation has a larger number of source legacy domains than target new Windows Server 2003 domains. Note that this does not total preclude the design and execution of migration path “A” and / or “B”, as they are still applicable to one or more of the existing legacy domains. However, it is a “migration issue” that the migration approach is required to consider and resolve.

The design for the standard Windows Server 2003 domain controllers for all new Windows Server 2003 domains has defined minimum hardware specifications for the server hardware. Analysis of the results of the design gap analysis identifies that none of the legacy domain controllers meet, or feasibly meet via appropriate hardware upgrades, these minimum hardware specifications. This is a migration issue as it will preclude the execution of two of the three possible methods within migration path “A”, and one of the two possible methods within migration path “B” (see the process “understanding supported migration paths” for more details). Although migration paths “A” and “B” still support one other method each that would counter this design difference, it is necessary to identify this design difference as a migration issue for the migration approach to consider and resolve.

It is possible to identify a migration issue where a business and / or technical migration goal stipulates a requirement that migration path “A” or “B” cannot support, such as:

A legacy Windows 2000 forest that requires migration to a new Windows Server 2003 Active Directory forest has extensive customisations to the Active Directory Schema. A predefined technical migration goal states the requirement for the generation of a pristine Windows Server 2003 Active Directory forest, which does not inherit any legacy directory objects and data that any pre-migration directory clean up tasks cannot remove. Customisations to a Windows 2000 Active Directory Schema are permanent and execution of migration path “B” will retain these customisations. Note that this does not exclude the design and execution of migration path “B” for any of the Windows 2000 domains within this forest, as there are workarounds to this issue. However, it is still necessary to identify this scenario as a migration issue for the migration approach to consider and resolve. For example, it is possible to perform an in-place upgrade of a Windows 2000 domain within this forest, via one of the supported methods within migration path “B”, and then execute an optional migration path such as “E” or “F”, where appropriate.

A business goal is to prevent disruption to current production services dependent upon the legacy domain infrastructure. Where an organisation is running Exchange 5.5 on a Windows NT 4.0 domain controller (or Exchange 2000 on a Windows 2000 domain controller), it is not possible to upgrade these domain controllers, via an in-place upgrade, to Windows Server 2003 as there is no support for Exchange 5.5 or Exchange 2000. Windows Server 2003 also does not support:



• Site Server 3.0 (SP4 and below)

• Systems Management Server 2.0 (SP2 and below)

• Proxy Server 1.0 and 2.0

Using the above examples, execute the following:

Collect and analyse the results of the design gap analysis and the defined business and technical migration goals, appropriate to the execution of this step, to identify (respectively):

All design differences between the legacy and new Windows Server 2003 domain infrastructures, and

The migration goals that will assist in the identification of migration issues

Assign each in-scope legacy domain the migration path “A” or “B” as appropriate to the version of the domain.

Identify and record all migration issues (in a tabular format for submission to the next step to determine the required migration approach) that will influence the requirements for any deviations in the required migration approach and selection of migration paths.

4.9.4. Determination of the Required Migration Approach

Consider the following information when determining the required migration approach to migrate the entire legacy domain infrastructure to the new Windows Server 2003 Active Directory infrastructure for the organisation:

• Factor B4: Understanding the concept of the migration approach


Has executed the design gap analysis, defined their business and technical migration goals, and has identified all migration issues associated with the migration of the in-scope legacy domain infrastructure to the new Windows Server 2003 Active Directory infrastructure, and

Wishes to understand the concept of the migration approach, as a core component of the migration strategy


As described in the “Background Information” section of this process, this design methodology defines a “migration approach” as a reflection of the migration requirements and strategy of an organisation.

These migration requirements, presented as an approach, define how the organisation wishes to execute the migration of one or more legacy Windows NT 4.0 and / or Windows 2000 domains to the new Windows Server 2003 Active Directory infrastructure.

The objectives of the migration approach are to:

Determine the requirements to map domains, directory objects, and directory data within the legacy domain infrastructure(s) to the new Windows Server 2003 domain



infrastructure. The deliverable for this step is the identification of the requirement for one or more of the following mappings:

A one-to-one mapping of entire existing legacy domains (including all directory objects and data within each domain) to entire new Windows Server 2003 domains

A mapping of one-to-many or many-to-one legacy domains to new Windows Server 2003 domains

A many-to-many mapping of existing legacy to new Windows Server 2003 domains (as a more granular mapping of specific directory objects and data from one or many legacy domains to one or many new Windows Server 2003 domains)

Determine the required approach to migrate each legacy domain and all in-scope legacy directory objects and data to the new Windows Server 2003 Active Directory infrastructure, based upon the requirements for the mapping of legacy domains.

There are multiple approaches supported by this design methodology to migrate legacy domains, their directory objects, and directory data to a Windows Server 2003 domain. The following influence the selection of the required approach:

The results of the design gap analysis

The predefined business and technical migration goals

The identified migration issues associated with the migration of each in-scope legacy domain, using the current “default migration path”

Note that the “default migration path” is first associated with the first null hypothesis, until disproved, and represented as an in-place upgrade using paths “A” or “B”. Where it is possible to disprove the first null hypothesis for this process, then the “default migration path” is associated with the second null hypothesis, and represented as a domain migration method using paths “C” or “D”, until it is possible to disprove this hypothesis as well.

This step within this process will assist an organisation in the determination of the single migration approach for this migration plan, which provides the foundation for the selection of the required migration path(s) for each in-scope legacy domain.

• Factor A10: Determination of the required migration approach for this migration plan

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the required migration approach for the migration of the entire legacy domain infrastructure(s) to the new Windows Server 2003 Active Directory infrastructure.


This design methodology proposes the following approach towards the determination of the migration approach for this migration plan:

Determine the requirements to map legacy domains and their domain contents (directory objects and data) to new Windows Server 2003 domains via analysis of the just the results of the design gap analysis, and not the identified migration issues and the predefined business and technical migration goals. Categorise the requirements to map the legacy domain(s) / legacy directory objects / legacy directory data to new Windows Server 2003 domains as one of the following mapping:



Mapping of an entire legacy domain (entire domain and all directory objects and data in the legacy domain) to an entire target Windows Server 2003 domain, which implies (as per this design methodology) the following:

• A strict migration of an entire legacy domain to become a new Windows Server 2003 domain via an in-place upgrade (paths “A” or “B”, as appropriate to the version of the legacy domain)

• The exclusion of any simple and optional migration paths that use migration, as these paths cannot migrate an entire legacy domain (all directory objects and data), but only selected directory objects and data.

Mapping of an entire legacy domain to two or more target Windows Server 2003 domains, which implies (as per this design methodology) the following:

• The partitioning of only the directory objects and data that may be migrated, amongst multiple target Windows Server 2003 domains

• The exclusion of the optional migration paths “G” and “H”, as these support only a “many-to-one” domain mapping

• The continued inclusion of migration paths “A” and “B”, via the design and execution of the extended migration paths “J” or “K”, respectively

Mapping of many legacy domains to one target Windows Server 2003 domain, which implies (as per this design methodology) the following:

• The consolidation of multiple legacy domains to a single target Windows Server 2003 domain

• Support for the design and execution of any of the simple, optional, and hence extended, migration paths

Mapping of the contents of many legacy domains to many target Windows Server 2003 domains, which implies (as per this design methodology) support for the design and execution of any of the simple, optional, and hence extended, migration paths

Once the required legacy domain / legacy directory object / legacy directory data to Windows Server 2003 domain mappings are determined, understand the simple, and optional (as extended) migration paths this design methodology supports for each domain-mapping category.

Then, using the results of the design gap analysis, the predefined business and technical migration goals, and the identified migration issues, define the required migration approach for each legacy domain, and the entire legacy domain infrastructure. Assign each legacy domain one of the following migration approaches supported by this design methodology:

The in-place upgrade of a legacy Windows NT 4.0 or Windows 2000 domain to a Windows Server 2003 domain

The clone of a legacy Windows NT 4.0 or Windows 2000 domain to a Windows Server 2003 domain

The inter-forest consolidation of multiple Windows 2000 domains followed by an in-place upgrade or clone of the consolidated Windows 2000 domain to a Windows Server 2003 domain



The intra-forest consolidation of multiple Windows 2000 domains followed by an in-place upgrade or clone of the consolidated Windows 2000 domain to a Windows Server 2003 domain

The in-place upgrade of a legacy Windows NT 4.0 or Windows 2000 domain to a Windows Server 2003 domain, followed by an inter-forest consolidation of the upgraded Windows Server 2003 domain with another Windows Server 2003 domain

The in-place upgrade of a legacy Windows NT 4.0 or Windows 2000 domain to a Windows Server 2003 domain, followed by an intra-forest consolidation of the upgraded Windows Server 2003 domain with another Windows Server 2003 domain

The clone of a legacy Windows NT 4.0 or Windows 2000 domain to a Windows Server 2003 domain, followed by an inter-forest consolidation of the migrated Windows Server 2003 domain with another Windows Server 2003 domain

The clone of a legacy Windows NT 4.0 or Windows 2000 domain to a Windows Server 2003 domain, followed by an intra-forest consolidation of the migrated Windows Server 2003 domain with another Windows Server 2003 domain

Summarise all identified migration requirements for each individual legacy domain, and hence define:

The migration paths for the legacy domains to support the migration requirements, goals, and resolve all migration issues

The overall migration approach for this migration plan

When determining the requirements to map legacy domains, legacy directory objects, and legacy directory data to new Windows Server 2003 domains, consider the following:

The results of the design gap analysis will identify the following:

The current contents (directory objects and data) of each in-scope legacy domain within the scope of migration (note that a legacy domain may be within the scope of migration, but this does not necessarily apply to all of the directory objects and data supported by the domain)

The required / expected contents (directory objects and data) of each new Windows Server 2003 domain

All of the similarities and differences in the presence and requirements for directory objects and data between legacy and new Windows Server 2003 Active Directory domains.

The objectives of this step are to identify the following:

The specific legacy directory objects and data that require migration from a legacy domain environment to a new Windows Server 2003 domain environment

The mapping of source domain to target domain for each identified directory object and datum

Note that when analysing the results of the design gap analysis, it is only necessary to focus on the legacy directory objects and data that requires migration from their legacy Windows NT 4.0 and / or Windows 2000 domain. Do not focus on any gaps between the existing directory object and data estate in the legacy domains and the expected content of the Windows Server 2003 domain(s), where the gap represents



new Windows Server 2003 domain directory objects and data, such as Windows Server 2003 Active Directory GPOs, OUs, and so on. This gap requires addressing via a “deployment plan” to create these objects and data following creation of the target Windows Server 2003 domain.

Remember, when assigning a category for mapping of a legacy domain to a new Windows Server 2003 domain, it is just a reflection of the directory object and data migration requirements, from the perspective of the design of the target Windows Server 2003 Active Directory infrastructure. It is not, at this stage, a reflection of the business and technical migration goals for this migration plan.

For example, an organisation has a single legacy Windows 2000 domain, named “W2K”, which supports ten user accounts and ten computer accounts. The design for the Windows Server 2003 Active Directory infrastructure requires a single forest with a single domain. This single domain requires the ten user accounts and ten computer accounts from the legacy “W2K" domain. This design similarity, identified via the design gap analysis, will hence require the assignment of a one-to-one domain-mapping category for this domain.

This design methodology has defined the specific implications associated with this category, and accordingly has only assigned support for migration via the in-place upgrade paths “A” or “B”, as appropriate. This is a reflection of the first null hypothesis for this process. However, following the assignment of the appropriate category for domain mapping, this step will analyse the predefined migration goals and identified migration issues to determine the actual migration approach, which supports these requirements.

Hence, in this example, although there is a one-to-one domain mapping, the organisation may have identified business and technical goals, and subsequently identified migration issues that preclude the use of the in-place upgrade path “B” for this legacy domain.

For example, the organisation may have defined a technical migration that stipulates the requirement to prevent the inheritance of any legacy data that pre-migration directory clean up tasks cannot remove, such as customisations to the Active Directory Schema. This requirement may hence favour the use of a migration approach (using migration path “D”), which still respects the requirements for a one-to-one domain mapping, but without the migration of un-required directory objects and data.

To reflect the objectives of this step, this design methodology proposes the following approach towards the determination of the requirements to map legacy domains, objects, and data to Windows Server 2003 domains:

Analyse the results of the design gap analysis to identify:

• The directory objects and directory data within each legacy domain that requires migration to the Windows Server 2003 Active Directory infrastructure

• The target Windows Server 2003 domain for each in-scope directory object and data

Summarise the migration requirements for the legacy directory objects and data in a spreadsheet. Then abstract the results to the legacy and Windows Server 2003 domain level.

Then, from the perspective of each in-scope legacy domain, assign one of the following mapping categories to each legacy domain:

• The requirement for a one-to-one domain mapping, where one legacy domain maps entirely to one target Windows Server 2003 domain



• The requirement for a one-to-many domain mapping, where one legacy domain maps to two or more Windows Server 2003 domains (and hence the legacy directory objects and data in the single legacy domain require partitioning amongst multiple target Windows Server 2003 domains)

Then, from the perspective of each required target Windows Server 2003 domain, assign one of the following categories to each Windows Server 2003 domain:

• The requirement for a one-to-one domain mapping of legacy domain to target Windows Server 2003 domain

• The requirement for a many-to-one domain mapping, where legacy directory objects and data from many legacy domains require migration (as consolidation of domains) to one target Windows Server 2003 domain

Then for all remaining domain mapping requirements that do not conform to any of the above categories, assign the many-to-many domain mapping, where legacy directory objects and data from many legacy domains will require migration to two or more target Windows Server 2003 domains.

When identifying all of the simple and optional migration paths that support the assigned domain mapping categories, consider the following:

The migration paths assigned to each category for mapping of legacy domains to Windows Server 2003 domains reflect both the null hypotheses for this process, and the most logical alternative paths.

The following table details the migration paths that support each assigned domain mapping category for the legacy domains, and their directory objects and data, as per this design methodology (see the notes at the foot of this table for details):

Domain Mapping Category (legacy-to-new)

Migration Paths That Support Domain Mapping Categories

A B C D E F G H

One-to-one (as entire domains and contents)

1

1

1

1

1

1

One-to-many 2

2

3

3

Many-to-one 2

2

Many-to-many 2

2

Table 43.2: Table of Supported Migration Paths against Domain Mapping Categories

The following notes support the above table:

• 1 This design methodology assigns the default migration paths “A” and “B” to

all one-to-one domain mappings, until it is possible to disprove the first null hypothesis. This hence excludes the design and execution of any of the optional migration paths because these paths support partitioning of the domain before or after a migration using a simple migration path, and hence break any one-to-one domain mappings.

• 2 The simple migration paths “A” and “B” are supported via the execution of

the extended migration paths, that ultimately generate the required mapping



of legacy domain, legacy directory objects, and legacy directory data to target Windows Server 2003 domains.

• 3 The one-to-many domain-mapping category excludes the design and

execution of the optional migration paths “G” and “H”, as these migration paths only support the many-to-one domain mappings.

When determining the required migration approach for the in-scope legacy domains, consider the following:

The migration approach is required to define the migration requirements for the legacy domains, individually or collectively, to take them to the new Windows Server 2003 Active Directory infrastructure. The only two methods this design methodology supports, for the migration of legacy directory objects and data to a Windows Server 2003 domain are:

An in-place upgrade of the legacy domain, or

The migration of directory objects and data from legacy domains to Windows Server 2003 domains

The execution of these migration methods, singularly or in a number of combinations, will support all identified requirements for the migration of legacy directory objects and data to the new Windows Server 2003 Active Directory infrastructure.

It is the objective of this migration approach to hence determine the required migration method or combinations of methods that will:

Support all identified migration requirements for legacy directory objects and data

Support all predefined business and technical migration goals

Support all identified migration issues that are associated with each legacy domain, where applicable

The objectives of this step are to

Disprove the first null hypothesis for this process, which states that the current “default migration paths” (“A” and “B”) support (alone) all migration requirements, and it is hence not necessary to design and execute any of the other simple or additional optional (as extended) migration paths. The predefined business and technical migration goals, and the identified migration issues, will assist in the identification of the opportunities to disprove this first null hypothesis and hence activate the second null hypothesis.

Disprove the second null hypothesis (where required)

Select an extended migration path (where required)

This design methodology hence proposes the following approach for the execution of this step:

Analyse the results of the domain-mapping step and understand all of the migration paths supported by each category of domain mapping (in addition to the two current “default” migration paths “A” and “B” for all categories).

Analyse the migration goals and issues to identify any migration requirements that the current “default migration paths” contradict and /or cannot support alone, in order to ensure compliance with these predefined migration goals and issues.



Where it is not possible to identify any such requirements that disprove the first null hypothesis for a legacy domain, then it is necessary to consider use of the “default migration paths” (“A” or “B”), as appropriate to the version of the legacy domain.

However, where it is possible to identify one or more such requirements for a legacy domain, then this disproves the first null hypothesis for this process, and activates the second null hypothesis. Note that activation of the second null hypothesis occurs regardless of whether the “default migration path” for the first null hypothesis cannot support migration requirements entirely or alone (thus hence requires supplementation with an optional migration path). The second null hypothesis for this process hence requires that the simple migration paths “C” or “D” are now the “default migration paths” for these legacy domains. It is now necessary to select, design, and execute migration path “C” or “D”, as appropriate, unless it is possible to disprove this second null hypothesis as well. Disproving the second null hypothesis opens that migration path selection to extended migration paths, which supports both simple migration paths.

Analyse the migration requirements, goals, and issues again to identify any opportunities to disprove the second null hypothesis.

Where it is not possible to identify any such requirements that disprove the second null hypothesis for a legacy domain, then it is necessary to consider use of the new “default migration paths” (“C” or “D”), as appropriate to the version of the legacy domain.

However, where it is possible to identify one or more such requirements for a legacy domain, then this disproves the second null hypothesis for this process. As the migration of a legacy domain to a Windows Server 2003 domain must use either the in-place upgrade or domain migration method, disproving the first, and now the second null hypothesis has not eliminated these paths. The selection of the required extended migration path for a legacy domain must hence include one any of the supported simple migration paths.

When identifying any migration requirements to disprove the first null hypothesis and hence prove that the default migration paths “A” or “B” cannot support (alone) all migration requirements for one or more legacy domains, consider the following:

When analysing the migration goals and issues that will influence the determination of the migration strategy, and disprove the first null hypothesis, identify all goals and issues that, for example:

• Contradict the capability of the default migration paths to:

♦ Preserve all legacy data and objects

♦ Simplify the design and execution of the migration plan

♦ Decrease the time required to execute the migration plan

♦ Potentially increase risk to the production environment, depending upon the selected approach within migration paths “A” and “B”

♦ Support all of the identified migration goals, and resolve all migration issues alone, without the use of any of the supplementary optional (represented as extended) migration paths.

For example, an organisation has five legacy Windows 2000 forests, each supporting one domain, and there is a requirement to implement



one Windows Server 2003 forest and domain. The organisation has identified the following migration goals and requirements:

♦ All legacy Windows 2000 domains contain directory objects and data that require migration, but only one legacy Windows 2000 forest supports all of the requirements for an in-place upgrade (due to the presence of an untouched and clean Active Directory Schema).

♦ A business migration goal to complete all migrations as soon as possible to support budget and resource availability and hence a requirement not to perform excessive post-migration tasks

The execution of migration path “B” may not support all of these requirements and goals, and hence there may be a requirement to combine migration path “B” with migration path “H” (to perform pre-migration inter-forest domain consolidation). The combination of migration paths “H” and “B” is the extended migration path “I”.

• Contradict the scope and deliverables of the default migration paths (to migrate all existing directory objects and data, after execution of the suitable pre-migration directory clean up tasks)

• Contradict the prerequisites and dependencies of the default migration paths, such as the hardware requirements, extensive pre-migration directory clean up tasks, and so on.

It is important to prioritise the migration requirements, goals, and issues that the default migration paths cannot support and / or contradict. For example, a technical migration goal that stipulates the requirement not to migrate any legacy directory objects and data that the pre-migration directory clean up tasks cannot remove, takes precedence over an identified migration issue on the hardware specification of a legacy Windows NT 4.0 domain controller to support one of the three possible approaches for migration path “A”. This is because migration path “A” supports two alternative approaches, which may preclude the identified migration issue, but the migration path cannot support the technical migration goal not to inherit legacy directory objects and data that clean up tasks cannot remove.

Where it is possible to identify one or more requirements to disprove the first null hypothesis, then consider the following when determining the migration requirements that may disprove the second null hypothesis:

The opportunity to disprove the first null hypothesis for a legacy domain assigns that legacy domain to the scope of the second null hypothesis for this process. The second null hypothesis for this process states that the simple migration paths “C” and “D” will support all migration requirements for that legacy domain. An organisation must now perform an analysis to identify any migration requirements, goals, and issues that may disprove the second null hypothesis. If it is possible to disprove the second null hypothesis, then there is a requirement for the selection, design, and execution of an extended migration path.

This design methodology recommends execution of the same approach, used to disprove the first null hypothesis, now to disprove the second null hypothesis. If it is not possible to disprove the second null hypothesis for a legacy domain, then that domain requires migration using a domain migration method, represented by migration paths “C” or “D”, as appropriate to the version of the legacy domain.

This hence involves the execution of an analysis of the migration goals and issues to identify any migration requirements that the current “default migration



paths” (not “C” or “D”) cannot support and / or contradict, in order to ensure compliance with these predefined migration goals and issues.

Where it is possible to identify the opportunity to disprove the second null hypothesis, this hence implies that it is then necessary to identify the requirements for the use of an extended migration path. As discussed in the “Process Approach” section, the selection of the extended migration path can include any of the supported simple migration paths, from “A”, “B”, “C”, and “D”.

When determining the required extended migration path, consult all predefined migration requirements and goals, and the migration issues associated with a legacy domain.

Using the above information and approaches, execute the following:

Determine and document the domain mapping requirements for each legacy domain and their directory objects and data

Determine and document the required migration approach for each legacy domain, and illustrate the requirements diagrammatically.

Where there is a requirement to select migration paths “A” or “B”, then identify and document the required approach within these paths, for each appropriate legacy domain.

4.9.5. Determination of the Domain Creation Dependencies

Consider the following information when determining the domain creation dependencies generated by the required migration approach for this project:

• Factor B5: Understanding domain creation dependencies


Has identified the required migration approach for each in-scope legacy domain, and

Wishes to understand the concept of domain creation dependencies


It is important to note that this design methodology infers the term “domain creation”, within the context of this process and migration plan, to imply the following:

The creation of a Windows Server 2003 domain, via the in-place upgrade of a legacy Windows NT 4.0 and / or Windows 2000 domain, and / or

The implementation of a pristine Windows Server 2003 domain to provide the target for the migration of directory objects and data from a source legacy domain

Where an organisation has two or more legacy domains and the requirements for two or more new Windows Server 2003 domains, then the required migration approaches for these domains will determine the domain creation dependencies.

This design methodology recognises the following two domain creation dependencies:

The requirement to create the forest root domain first, for each required Windows Server 2003 forest, before the creation of any other required Windows Server 2003 domains within each forest.



The requirement to create a target Windows Server 2003 domain, which is not the forest root domain, but is the target for the migration of directory objects and data from one or more legacy domains.

The following represent the deliverables of this step:

The identity of the Windows Server 2003 domains that require creation as the forest root domain for each required forest

The identity of the forest root domains that require creation via an in-place upgrade or to receive migrated directory objects and data from one or more legacy domains

The identity of the Windows Server 2003 domains that require creation within each required forest:

Via an in-place upgrade of a legacy domain, or

As a pristine domain implementation to receive migrated directory objects and data from one or more legacy domains

Note that the determined domain creation dependencies will directly influence the design of the migration schedule.

• Factor A11: Determination of the domain creation dependencies for this migration plan



Prior to the determination of the domain creation dependencies for this migration plan, it is necessary to understand the following:

All of the options available for the creation of the forest root domain, and other Windows Server 2003 domains within each required forest, and

The types of domain creation dependencies recognised by this design methodology

When attempt to understand the options available for the creation of Windows Server 2003 domains, consider the following:

This design methodology recognises the following options for the creation of the forest root domain for each required Windows Server 2003 forest, or normal Windows Server 2003 domains within a forest:

Create the domain as a pristine domain and not populate it with directory objects and data from any existing legacy domains

Create the domain via the in-place upgrade of one legacy domain

Create the domain as a pristine domain to support the migration of directory objects and data from one or more legacy domains

Create the domain via the in-place upgrade of one legacy domain, and use this upgraded domain to support the subsequent migration of directory objects and data from one or more other existing in-scope legacy domains

This design methodology recognises the following three domain creation dependencies that require identification for this migration plan:



The requirement to create the forest root domain for a Windows Server 2003 forest creates a dependency on the creation of every other domain that forest is required to support

The requirement to clone directory objects and data from one or more legacy domains to a target Windows Server 2003 domain creates a dependency on the presence of that domain

The requirement to consolidate multiple legacy domains into one or fewer Windows Server 2003 domains and the requirement to create one or more of the Windows Server 2003 domain(s) via an in-place upgrade of one other the legacy domains creates a dependency. The migration of directory objects and data from the remaining legacy domains can only occur following completion of the in-place upgrades to create the necessary target Windows Server 2003 domain(s).

When attempting to understand the types of domain creation dependencies recognised by this design methodology, consider the following:

The options outlined above for the creation of domains represent the “primary” domain creation dependencies. These “primary” dependencies take top priority, as it is not possible to alter these dependencies.

However, it is possible to identify another category of domain creation dependencies that reflect business, technical, and logistical requirements for their creation. Note that it is possible to alter these dependencies, and are hence categorised by this design methodology as “secondary” domain creation dependencies.

When determining the domain creation dependencies for this migration plan, consider the following:

This design methodology proposes the following approach to determine the domain creation dependencies:

Execute an analysis of the design summary for the Windows Server 2003 Active Directory infrastructure and migration approach requirements for the migration strategy to identify the “primary” domain creation requirements and dependencies.

Execute an analysis to identify all “secondary” domain creation requirements and dependencies

Evaluate all identified dependencies on the creation of the new domains within the Windows Server 2003 Active Directory infrastructure, and design the required sequence for their creation.

Pass the results of this step to the process to design the migration schedule for this migration plan.

When determining the “secondary” domain creation requirements and dependencies, consider the following:

Where an organisation has multiple legacy domains that require migration to create or populate new Windows Server 2003 domains, it may be possible to identify multiple business, technical, and logistical requirements that will influence the domain creation dependencies.

This design methodology provides the following examples of the factors that require consideration, as potential “secondary” domain creation dependencies:

• Pre-identified business migration goals to reduce risk to the production environment may hence preclude the simultaneous in-place upgrade of



multiple legacy domains that are mission-critical to the organisation. Upgrading, for example, three Windows NT 4.0 account domains simultaneously increases the risk to generate significant disruptions to the continuity of the organisation. It may hence be possible to identify the requirement to intersperse the upgrades of the account domains with a resource domain. Business migration goals to, for example, reduce the mean time between failures, may also dictate this approach, and hence identify this “secondary” domain creation dependency.

• Other business requirements and goals that may influence the domain creation dependencies include, for example, the pending cessation of support for the server hardware platform for legacy domain controllers in specific legacy domains. Also, legacy domains supporting domain controllers experiencing significant hardware issues, and hence maintenance overheads, may move up in the priority list for migration, especially where the migration is associated with new server hardware.

• As domain migration projects may generate minor or major disruptions to the productivity of the user population within the organisation, and where the organisation is planning a parallel computer refresh project for the users, consider executing the migration of the account domains as soon as possible. User migrated to a new domain, and concurrently supplied with new computers / computer builds, provides the users with benefit associated with a potentially disruptive project. This may hence maintain the profile of the migration project and hence a reflection of the success of the project.

• A logistical requirement to influence the domain creation dependencies includes, for example, the current geographical distribution of resources (human and computer) across the organisation. An organisation with multiple legacy domains to upgrade may wish to perform the first few in close physical proximity to the headquarters of the organisation, where the majority of administrators of a logically centralised, but physically distributed, IT department reside. Once the required migration paths for a “few” domains have been successfully executed, and the process refined to eliminate all issues, it reduces the risk in submission of the process to less skilled remote administrators, for execution against a local domain. An organisation may also wish to execute a required migration path against a domain where its domain controllers are in closer proximity than for another in-scope legacy domain.

• Technical requirements and goals that may influence the domain creation dependencies include, for example, the requirements for the migration of application servers in legacy domains to the Windows Server 2003 Active Directory infrastructure. For example, an organisation with an Exchange 5.5 infrastructure is planning a concurrent Exchange migration project, and the upgraded version, Exchange 2000 or Exchange Server 2003 requires an Active Directory infrastructure. Hence, these domains may require a higher priority in the list of domains to be migrated, especially where the parallel project has a higher priority for completion.



5. Design of the Required Migration Path(s)

This process requires execution by the owner(s) of the target Windows Server 2003 domain(s) and the owner(s) of the existing in-scope legacy domain infrastructures within the scope of this migration plan.


The objectives of this process are to assist an organisation in the generation of a design for the following:

• Each required migration path, identified by the migration strategy for this migration plan

• A single coexistence plan to support coexistence between the legacy and Windows Server 2003 domain infrastructures during the migration phase of this project

• A single contingency plan to support the rollback or recovery from a failed migration associated with each required migration path

5.2. Process Scope

The following define the scope for this process:

• The number of simple and extended migration paths identified to support the migration of all in-scope legacy domains and domain infrastructures within the organisation

• The number of legacy domains that require migration to the new Windows Server 2003 Active Directory infrastructure


Prior to determination of the design requirements for this migration plan, it is necessary to understand the following concepts and terms discussed within this process:

1. The components of a migration plan, which include a design for one or more migration paths, and a single coexistence plan and contingency plan to support all required migration paths.

2. The concepts of closed and open sets for intra-forest migration paths

3. The concepts behind the project and migration terms employed within this process

5.3.1. Components of a Migration Plan

The scope of the design for a simple or extended migration path is not limited to the design of the specific migration activities necessary to execute the migration path. Instead, this design methodology states that the design of each required simple and extended migration path is comprised of three components, which are all dependent upon each other. The three components of a design for a migration path are:

• The requirements and design for the execution of the actual migration activities associated with each required simple and extended migration path

• The requirements and design to support coexistence between the legacy domain and Windows Server 2003 domain infrastructures during the migration project

• The requirements and design for a migration contingency plan

The following diagram illustrates the dependencies between these components and the influence of each component on the generation of the design for other components:



MIGRATION

COEXISTENCECONTINGENCY

Strong Influence on Design

Mild Influence on Design


Figure 44.1: Relationships, Dependencies, and Design Influences between the Migration Path and the Coexistence and Contingency Plans

• The design and execution of the migration activities for a migration path must reflect and support all requirements for the development and execution of a contingency and coexistence plan.

• The design for the coexistence plan must collectively reflect and support the design and execution of all activities within specific migration paths, and provide support for the execution of the contingency plan, when required.

• The design for the contingency plan must collectively reflect and support all elements and requirements of each required migration path, and the requirements to maintain business continuity, as defined by the coexistence plan.

Note that this process requires that the design of each required migration path supports and depends upon one contingency plan and one coexistence plan (where appropriate). Hence where, for example, the migration strategy for this migration plan identifies the requirement for the design and execution of two extended migration paths for two legacy domains, then this process to design the migration path will have the following deliverables:

• Two designs for the execution of the migration of the legacy domain infrastructure to the new Windows Server 2003 domain infrastructure (one design for each of the two required extended migration paths)

• One design for a contingency plan to support both required migration paths

• One design for a coexistence plan to support both required migration paths (where appropriate)

Note that not all supported migration paths require support via a coexistence plan. Consult the step within the process, “determination of the design requirements for the coexistence plan”, for details.

5.3.2. Concepts of Closed and Open Sets for Intra-Forest Migration Paths

The intra-forest migration paths “E” and “G” must address the migration of closed and open sets between domains within the same forest.

The concepts of closed and open sets has a significant influence on the design for the pre-migration, migration, and post-migration tasks for the intra-forest migration paths “E” and “G”.

The following facts are pertinent to understanding the concepts of closed and open sets:

• The term “set” refers to the logical relationships between objects or between resources and objects within a source domain, and the influence of these relationships on the migration of the objects and resources to a target domain.



• A “closed set” is a normal and unbroken relationship between objects or between resources and objects in a source domain, which resides entirely within the logical boundary of the source domain. An “open set” is a broken closed set, where the previous relationships between objects and between resources and objects do not exist in their earlier entirety because the set now spans the boundaries of two or more domains, and not the single domain as before. Hence, it is only possible to create an “open set” by breaking a previously “closed set” via the incomplete migration of a closed set between domains. Note that it is, however, possible to “heal” an open set and recreate the previous closed set, now in the target domain. To “heal” a broken closed set, it is necessary to execute a subsequent migration of all objects previously omitted from the initial migration that created the open set, and thus completing the closed set.

• Within a source domain, it is possible to identify the following two types of closed sets (which this design methodology has labelled as “user” and “resource” closed sets for ease of reference):

♦ A closed “user” set represents the relationships between user account objects, Global security group objects, and all other members of the Global security group objects

♦ A closed “resource” set represents the relationships between resources on servers, local security group objects assigned permissions to these resources on these servers hosting the resources, and the members of the local security group objects.

• The following information is pertinent to understanding closed “user” sets:

♦ The relationships between user accounts, Global group objects, and all other members of the Global group objects define and represent the boundary for a closed “user” set. In a small source domain, it may be possible to identify a few complete closed “user” sets, but in larger domains, this may become difficult to identify. The following diagram illustrates an example of a simple closed “user” set is a source domain where:

Four user account objects are each members of four Global security groups, and

The Global security group objects contain no other members, and

The four users are not members of any other Global security groups within the domain

Simple closed “user”

set

Global security group objects



Figure 44.2: Example of Simple Closed “User” Set

♦ However, as can be seen from the above example, it is not easily possible to identify such “user” closed sets within most organisations. A typical source Windows 2000 or Windows Server 2003 domain may contain many hundreds to even thousands of Global security groups, each with tens to thousands of member user accounts, and with each user account a member of tens to hundreds of Global security groups.

♦ In the above example, the incomplete migration of the “user” closed set, from a source domain to a target domain, will break the relationships between these objects, and hence create an open “user” set. For example, the migration of only three of the Global



security group accounts and all of the user accounts to the target domain, thus leaving behind one Global security group account, will create an open “user” set. A broken closed set in this example results in the migrated users no longer inheriting permissions and rights assigned to the un-migrated Global security group. Breaking a closed set may hence disrupt business continuity.

♦ Note that although the concepts of closed and open sets also apply to the inter-forest migration paths, this design methodology does not consider them as influential in the design of the inter-forest migration paths. The following facts explain this lack for support for closed and open sets as influential factors in the design of inter-forest migration paths:

It is possible to migrate closed “user” and “resource” sets between forests

It is possible to break closed “user” and “resource” sets via the execution of an incomplete migration of a closed set between forests

It is possible to automatically “heal” a closed “user” set via the completion of all migration tasks, for previously omitted objects, between the forests

It is not possible to preserve (manually or automatically) a closed “user” set that is theoretically broken via the execution of an incomplete migration of a closed “user” set between forests, or the conversion of Global and Domain Local security groups into Universal security groups. However, an intra-forest migration path can preserve closed “user” sets theoretically broken via the execution of an incomplete migration of a closed “user” set within a forest. This is a very important distinction to understand between intra-forest and inter-forest migration paths. The basis for this preservation of a closed “user” set is the use of Universal security groups, which can hold members from any domain, and are applicable in any domain in the forest. This hence supports the spanning of a closed set across the boundaries of two or more domains, but still within the boundary of a forest.

♦ When ADMT version 2.0 detects the incomplete migration of a closed “user” set due to the exclusion of a Global security group in the source domain, it can convert that Global security group into a Universal security group, and hence preserve the closed “user” set across multiple domain boundaries within a forest. There are, however, many prerequisites and considerations for the use of this feature, which a later factor in this step of this process will discuss in detail.

♦ Note that the automatic conversion of un-migrated Global group objects in the source domain into Universal security group objects, to preserve closed sets across domain boundaries, requires both the source and target domains to operate at the “Windows 2000 Native” domain mode or “Windows Server 2003” functional level as appropriate. Where this is not true, then ADMT version 2.0 is unable to automatically convert the source Global security groups into Universal security group objects, and instead, it will execute the following steps:

ADMT will create a copy of the source Global security group in the target domain, and

Add all migrated security principals to this copy of the original un-migrated Global security group.

♦ However, note that ADMT will not run a security translation in the source domain, to assign these copies of the un-migrated Global group objects the same permissions and rights assigned to the original groups. It is hence necessary to:

Create a SID mapping file (see later for details on how to create a SID mapping file) that maps the SID of the original (un-migrated) Global security group objects to the SID for the new copies of these Global group objects in the target domain



Run the Security Translation Wizard, providing the SID mapping file, against all servers still in the source domain, to perform an “add” security translation on all resources in the source domain to which the un-migrated Global groups receive permissions.

♦ The objectives of the design for the intra-forest migration paths are hence to preserve, where possible, closed sets during migration, and hence preserve business continuity. This is possible via the design of the pre-migration, migration, and post-migration tasks for the intra-forest migration paths “E” and “G”.

• The following information is pertinent to understanding closed “resource” sets:

♦ The relationships between resources, Domain Local security group objects, and all other members of the Domain Local security group objects define and represent the boundary for a closed “resource” set. In a small source domain, it may be possible to identify a few complete closed “resource” sets, but in larger domains, this may become difficult to identify. The following diagram illustrates an example of a simple closed “resource” set is a source domain where:

Four member servers in a source domain support file share resources

Each member server has one local security group object

Permissions are assigned on the file share resources on the respective member server to the single local security group (in the local SAM database of a member computer)

Two Domain Local security group objects are each members of the one local security group on each member server

The two Domain Local security groups are not members of any other local security groups on any other member server in the source domain

The local security groups do not have any other domain members other than the two Domain Local security groups

RWD

FC

RW

R

Domain Local groups

Local security groups

Local SAM database on member servers holding local security groups

Member servers with file share resources

Membership of domain local groups to local security groups

Permissions assigned to local security groups on file share resources

Simple closed “resource” set


Figure 44.3: Example of Simple Closed “Resource” Set

♦ The execution of a migration of member computers preserves their SAM databases and hence the relationships between local resources and local security groups as a natural closed set. However, the migration of member computers to a target domain without the domain local groups can break the closed “resource” set.

♦ To preserve the closed set during the intra-forest migration of the member computers, it is necessary to convert the Domain Local security groups into Universal security



groups. ADMT version 2.0 does not perform this conversion, and it is hence necessary to perform this conversion manually.

5.3.3. Project and Migration Terms employed within this Process

This design methodology will mention, refer to, and discuss several project and migration terms within this process. It is hence important to understand the following terms:

• Project stages or phases, such as proof-of-concept (POC), pilot, and deployment, and

• Migration terms, such as pre-migration, migration, post-migration, migration phase, and coexistence phase

Most projects to design and deploy a Windows Server 2003 Active Directory infrastructure will be supported by a project approach and supporting methodology, such as the PRINCE 2 methodology (Projects In Controlled Environments), and as such will have defined phases for the project. A typical project methodology partitions a project into the following seven stages or phases:

• Project Initiation Stage, when an organisation initiates a project via execution of a project definition workshop and generation of a project initiation document (PID)

• Analysis Stage, during which all design requirements are identified and documented in analysis reports

• Design Stage, during which the actual designs are generated against the determined design requirements

• Proof-of-Concept Stage, during which custom design aspects of the completed designs are tested in a network-isolated laboratory environment designed to emulate, as closely as possible, the intended production environment

• Pilot Stage, during which the tested and verified designs are implemented into a percentage (typically between 10% to 15%) of the production environment

• Deployment Stage, during which the remainder of the design is implemented into the remainder of the production environment

• Closeout Stage, during which all project activities are formally closed

This design methodology will discuss several migration terms within this process, defined below:

• The “Migration Phase” refers to the phase during a project during which one or more migration activities are currently under execution.

• “Migration activities” only represent those activities executed during the pre-migration, migration, and post-migration phases.

• The “Pre-Migration” phase refers to the phase that supports migration activities dedicated to preparation for the execution of a migration path, such as preparation of a source and target domain environment.

• The “Migration” phase refers to the phase that supports migration activities dedicated to the execution of all simple migration paths, to perform the “actual” migrations.

• The “Post-Migration” phase refers to the phase that supports migration activities dedicated to the completion of all tasks associated with each required migration path.



• The “Coexistence” phase refers to the phase when both legacy and new domain environments are concurrently in operation within the production environment, and influencing business continuity.

It is important to note that the coexistence phase applies to all migration paths, including the in-place upgrade path “A”. The execution of approaches 1 or 2 for migration path “A” effectively “removes” the legacy domain, and hence it is not logically possible to identify the concurrent presence of both legacy and domain environments within the production environment. However, within most executions of migration path “A”, it will be possible to identify “remnants” of the legacy Windows NT 4.0 domain infrastructure still in operation on the production environment.

Coexistence will apply to these scenarios where the organisation deems the existence of these “remnants” of the legacy domain infrastructure as temporary aspects of the legacy domain and not a permanent feature of the new Windows Server 2003 Active Directory infrastructure.

For example, the presence of BDCs, Windows NT 4.0 servers operating services that require null sessions with domain controllers for authentication, such as Windows NT 4.0 RAS, and so on. Where there is a requirement for the temporary support of these “remnant” aspects of the legacy Windows NT 4.0 domain, then the coexistence plan must facilitate the generation of the necessary to design aspects of the Windows Server 2003 domain and domain controllers to permit temporary support.

The following diagram illustrates an example of the mapping of the migration phase and activities with the project phases / stages. Note that pre-migration activities do not necessary depend upon the Proof-of-Concept stage, but there is typically a requirement for their concurrent execution during this stage of a project. For example, execution of directory clean up activities in a source domain for migration path “C” or “D”, and so on.

PILOT DEPLOYMENTPOC

COEXISTENCE PHASE

MIGRATION PHASE

PRE-MIGRATIONMIGRATION

POST-MIGRATION


Figure 44.4: Relationships between Migration and Project Phases


To reflect and support the objectives of this process, this design methodology proposes the following approach for the execution of this process:

1. Execute an analysis to determine the design requirements for each required migration path

2. Execute an analysis to determine the design requirements for the coexistence plan

3. Execute an analysis to determine the design requirements for the contingency plan

4. Generate the design for each required migration path

5. Generate the design for the migration checklists summarising all migration, coexistence, and contingency tasks that require execution for each required migration path




Based upon the above approach, this process is composed of the following five components:

• Determination of the design requirements for each required migration path

• Determination of the design requirements for a coexistence plan

• Determination of the design requirements for a contingency plan

• Design for each required migration path

• Design for the migration checklists



• The determination of the following design requirements for each required migration path:

♦ The determination of the design requirements for all pre-migration tasks

♦ The determination of the design requirements for all migration tasks

♦ The determination of the design requirements for all post-migration tasks

• The determination of the design requirements for a coexistence plan to support all required migration paths, and the execution of the contingency plan, when required

• The determination of the design requirements for a contingency plan to support all required migration paths, and all coexistence requirements

• Generation of the design for each required migration path

• Generation of the design for the migration checklists


To support the execution of this process, and to reflect the approach outlined above, each component within this process will have the following inter-component dependencies:

Migration Plan – Inter-Component Dependencies for Process to Design Required Migration Paths

STARTDetermination of the

design requirements for the migration paths

Determination of the design requirements for

the coexistence plan

Generation of the design for the migration

checklists

Generation of the design for each

required migration path


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



5.8. Processes to Design the Required Migration Path(s)

Migration Plan – Process to Design Required Migration Paths

STARTExecute

B1 – B5

Execute

A1 – A6

YES

NOExecuted all factors

for all required migration paths?

Execute

B6 – B7

Select a migration path and execute

appropriate factors

ENDExecute

B13 – B14


PATH

H

Execute

A20

Execute

A23

Execute

B8

Execute

A26 – A27

Execute

A29

Execute

B9

Execute

A32

Execute

B10

Execute

A34

Execute

B12

Execute

A41

Execute

B11

PATH

G

Execute

A21

Execute

A23

Execute

B8

Execute

A26 – A27

Execute

A29

Execute

B9

Execute

A33

Execute

B10

Execute

A35

Execute

B12

Execute

A42

Execute

B11

PATH

F

Execute

A20

Execute

A24

Execute

B8

Execute

A26 – A28

Execute

A30

Execute

B9

Execute

A32

Execute

B10

Execute

A34

Execute

B11

Execute

B12

Execute

A41

PATH

E

Execute

A21

Execute

A24

Execute

B8

Execute

A26 – A28

Execute

A30

Execute

B9

Execute

A33

Execute

B10

Execute

A35

Execute

B11

Execute

B12

Execute

A42

PATH

D

Execute

A20

Execute

A23

Execute

B8

Execute

A26 – A28

Execute

A30

Execute

B9

Execute

A32

Execute

B10

Execute

A34

Execute

B11

PATH

C

Execute

D1

Execute

A20

Execute

A22

Execute

B8

Execute

A26 – A28

Execute

A30

Execute

B9

Execute

A32

Execute

B10

Execute

A34

Execute

A37

Execute

B12

Execute

A41

Execute

B11

PATH

B

Execute

A8 – A17

Execute

A19

Execute

B9

Execute

B10

Execute

A38

Execute

B11

Execute

B12

Execute

A40

PATH

A

Execute

A7

Execute

A18

Execute

A25

Execute

B9

Execute

A31

Execute

B10

Execute

B11

Execute

A36 – A37

Execute

B12

Execute

A39




Consider the following information when executing this process to design the required migration paths, the coexistence plan, and the contingency plan.

Presented within the following five sections are the considerations for this process:

1. Considerations for the determination of the design requirements for each required migration plan

2. Considerations for the determination of the design requirements for the coexistence plan

3. Considerations for the determination of the design requirements for the contingency plan

4. Considerations for the generation of the design for each required migration path

5. Considerations for the generation of the design for the migration checklists

5.9.1. Determination of the Design Requirements for Each Required Migration Path

Consider the following information when determining the design requirements for each required migration path.

Presented within the following four sections are the considerations for the execution of this step within this process:

1. Understanding the components of a design for a migration path

2. Determination of the requirements for the design of pre-migration tasks to support each required migration path

3. Determination of the requirements for the design of migration tasks to support each required migration path

4. Determination of the requirements for the design of post-migration tasks to support each required migration path

5.9.1.1. Understanding the Components of a Design for a Migration Path

Consider the following to understand the components of a design for a migration path:

• Factor B1: Understanding the components of a design for a migration path

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the components of a design for a migration path, prior to commencing any activities to determine the design requirements.


This design methodology requires that each design for any of the supported migration paths include the following components:

A design for the migration path, detailing the source and target domains, scope, order of execution, and so on (Note that the process “determination of the required migration strategy” provides this information, and hence it is not necessary for this step to determine and design this component).

A design for the execution of all pre-migration activities

A design for the execution of all migration activities



A design for the execution of all post-migration activities

The design for the pre-migration, migration, and post-migration tasks, and the design for the appropriate checklists, must all support the following three aspects of a migration path:

The (pre-migration, migration, and post-migration) tasks to execute a migration path

The (pre-migration, migration, and post-migration) tasks to execute the appropriate elements of a coexistence plan

The (pre-migration, migration, and post-migration) tasks to execute the appropriate elements of a contingency plan

It is important to note that the determination of the pre-migration, migration, and post-migration design requirements for the coexistence and contingency plans rely upon the pre-identified design requirements for these plans. It is thus not possible to determine the migration tasks to support these plans until the design requirements for these plans are also determined. This design methodology hence requires the execution of the steps to determine the specific migration tasks necessary to support the execution of the coexistence and contingency plans during the steps to determine the design requirements for these plans.

The following diagram illustrates the distribution of these analysis tasks within this process to design the required migration paths:

Determination of the design requirements for the pre-migration tasks

to execute the coexistence plan

Determination of the design requirements for the migration tasks to

execute the coexistence plan

Determination of the design requirements for the post-migration tasks

to execute the coexistence plan







Determination of the design requirements for the pre-migration tasks

to execute the contingency plan

Determination of the design requirements for the migration tasks to

execute the contingency plan

Determination of the design requirements for the post-migration tasks

to execute the contingency plan


the contingency plan


the contingency plan

Determination of the design requirements for the pre-migration tasks to execute a migration

path

Determination of the design requirements for the migration tasks to execute a migration

path

Determination of the design requirements for the post-migration tasks to execute a migration

path


the migration path

Determination of the design requirements for each required migration

path


the migration path

From Process “Determination of

Required Migration Strategy”

First Three (Analysis) Sections of Process “Design of the Required Migration Path(s)”


Figure 44.5: Distribution of Analysis Tasks within Process to Design Required Migration Paths

5.9.1.2. Determination of the Design Requirements for the Pre-Migration Tasks

Consider the following information when determining the design requirements for the pre-migration tasks to support each required migration path.



Presented within the following four sections are the considerations for the execution of this step within this process:

1. Understanding the pre-migration tasks that require determination and design

2. Determination of the design requirements for common pre-migration tasks to prepare a source domain for migration

3. Determination of the design requirements for specific pre-migration tasks to prepare a source domain for migration

4. Determination of the design requirements for specific pre-migration tasks to prepare a target domain for migration

5.9.1.2.1. Understanding Pre-Migration Tasks

Consider the following to understand the common and specific pre-migration tasks that required determination for design:

• Factor B2: Understanding pre-migration tasks and the proposed approach for their determination for design and execution

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the requirements to define pre-migration tasks, and the approach proposed by this design methodology for their determination.


The objectives for the execution of this step within this process are to determine the pre-migration tasks necessary for the design and execution of each required “simple” and “optional” migration path.

Note that it is only necessary to determine the pre-migration tasks for the “simple” and “optional” migration paths because the pre-migration tasks for “optional” migration paths are common to all “extended” migration paths that employ them. The next step in this process will generate the design for the execution of the identified pre-migration tasks, based upon the results of this analysis.

The pre-migration tasks represent all of the tasks necessary to prepare a legacy and target domain environment for the execution of the migration tasks. Execution of the migration tasks associated with a specific migration path depends upon the completed execution of all associated pre-migration tasks.

Hence, to support the execution of any of the required simple or optional migration paths, it is necessary to design requirements for the execution of the following specific pre-migration tasks:

Preparation of one or more source legacy Windows NT 4.0 / Windows 2000 domains and their domain controllers for migration

Preparation of one or more target Windows Server 2003 / (interim) Windows 2000 domains and their domain controllers for migration

Preparation of the supporting network and directory service infrastructure necessary for any migration tool(s) required to execute a migration path

This design methodology hence proposes the following approach to determine the pre-migration tasks for each required simple and optional migration path:



Determine the design requirements for execution of the pre-migration tasks common to all simple and / or optional migration paths, to prepare a source domain for migration

Determine the design requirements for execution of pre-migration tasks for specific migration paths to:

Prepare a source domain and their domain controllers for migration

Prepare a target domain and their domain controllers for migration

This design methodology proposes that the pre-migration tasks (common to all simple and optional migration paths) to prepare a source domain for migration are restricted to directory clean up tasks, to remove redundant in-scope directory objects and data.

This design methodology proposes that the pre-migration tasks (for each simple and optional migration path) to prepare a source domain for migration include the following example tasks (see later for details):

Directory clean up tasks to remove redundant in-scope directory objects and data

Design of a change control freeze on directory service operations

Tasks to prepare legacy Windows NT 4.0 and Windows 2000 domains and domain controllers for in-place upgrades

Tasks to prepare the supporting network infrastructure for execution of all pre-migration, migration, and post-migration activities

Tasks to prepare the security principals within the source and target domains for execution of the migration paths

This design methodology proposes that the specific pre-migration tasks (for each simple and optional migration path) to prepare a target domain for migration include the following:

Identification of directory clean up tasks to remove redundant directory objects and data, where applicable

Tasks to prepare the target domain for migration

Tasks to build the target domain(s), domain controllers, and name resolution infrastructure (for paths “C”, “D”, “E”, “F”, “G”, and “H”)

• Factor B3: Understanding the approach for the execution of pre-migration tasks

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the recommended approach for the execution of the pre-migration tasks for each required migration path.


The pre-migration tasks to clean up the source (and target) domain infrastructures require execution twice. This is because although an organisation working through this process in the first instance will identify a number of “redundant” directory objects and data, the actual execution of the pre-migration tasks must only occur immediately prior to the execution of the migration tasks.

Hence, all “redundant” directory objects and data identified during the first instance of this investigation will require re-execution immediately prior to migration, because:



There will inevitably be a delay between the first execution of this analysis to identify “redundant” directory objects and data, and the actual execution of the migration tasks.

Where this delay is longer than a week or so, then it is inevitable that there will be some changes to the “redundancy” status of previously identified directory objects and data, and this may hence invalidate a small percentage of the results from the first analysis. Hence, immediately prior to migration, it is necessary to revalidate the results of the first analysis to identify and rectify any changes.

This design methodology recommends that each instance of execution of these tasks have the following profile:

The first execution of these tasks has the following profile:

It is necessary to first execute these tasks now (during the analysis or discovery phase of the project)

The results of the first execution will be, for example (with respect to directory clean up tasks):

• Identification of the directory objects and data that can be immediately categorised as “actually” redundant (see later for definition of this category), following execution of an analysis against the directory objects and data.

• Identification of the criteria for the inclusion and exclusion of directory objects and data from the scope of pre-migration directory clean up tasks, for those objects that can be immediately categorised as “potentially” redundant (see later for definition of this category), following execution of an analysis against the directory objects and data.

The second execution of these tasks has the following profile:

It is necessary to execute these tasks again just prior to execution of the migration tasks for a legacy domain

The results of the second execution will be, for example (with respect to directory clean up tasks):

• Re-evaluation of all previously identified “potentially” redundant directory objects and data against the defined criteria for the inclusion of objects and data into the pre-migration directory clean up tasks. If an organisation has designed and implemented a freeze on directory service change control following completion of the first execution of these tasks, this simplifies the second execution of these tasks. To execute the second instance of this task, perform a gap analysis between the results of the first execution and the change log maintained during the freeze.

• Identification of the opportunity to execute the actions associated with the “potentially” redundant directory objects and data

In some organisations, where the percentage of “normal” changes to directory objects and data (that may alter their “redundancy” status) is quite high, and there are a correspondingly large number of existing objects and data, the number of changes in a short period may be substantial.

To retain the validity of these pre-migration directory clean up analysis (which resource and time intensive activities), this design methodology proposes the design of a freeze to a directory service change control infrastructure. See the step “determination of the design requirements for the coexistence plan” for details.



Note that the directory objects and data categorised as “actually” redundant will not experience, by definition, any change in their redundancy status, and are hence outside of the scope of the freeze on change control (see later for details).

However, directory objects and data categorised as “potentially” redundant may experience, by definition, a change in their redundancy status, and are hence within the scope of the freeze on change control for a legacy domain.

5.9.1.2.2. Determination of the Common Pre-Migration Tasks to Prepare a Source Domain

Consider the following when determining the pre-migration tasks, common to all simple and optional migration paths, to prepare a source legacy (Windows NT 4.0 or Windows 2000) domain for migration:

• Factor B4: Understanding the requirements for directory clean up tasks, and the components and scope of directory clean up tasks

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to:

Understand the requirements for the execution of directory clean up tasks, and

Understand the components and scope of directory clean up tasks common to all simple and optional migration paths, for execution as pre-migration tasks


This design methodology recommends the execution of detailed analyses to identify the scope of directory clean up tasks required for legacy domain infrastructures prior to their migration to the new Windows Server 2003 Active Directory infrastructure.

Directory clean up involves the execution of tasks to remove all redundant and superfluous directory objects and directory data from a source domain prior to its migration. The execution of pre-migration directory clean up tasks hence:

Prevent the generation of complications during and after the migration from the presence of, for example, duplicate objects

Reduces the risk level associated with the execution of a migration path

Reduces the migration workload and scope

It is necessary to design and execute pre-migration directory clean up tasks where it is possible to identify compliance with the following criteria:

A legacy domain has many (for example, more than fifty to one hundred) directory objects, and

The organisation has not identified redundancy criteria for directory objects and data, and

The organisation does not currently execute any routine processes to maintain the integrity of the legacy domain infrastructure, via the removal of all directory objects and data that meet redundancy criteria

This design methodology proposes the following aspects of a legacy domain infrastructure to reside within the scope of “directory clean up tasks”:



All potentially redundant directory objects (such as user and computer account objects), within each in-scope legacy domain infrastructure, which may require removal as pre-migration tasks

All potentially redundant directory data (such as object attribute data, application data (such as DNS zone data) and so on), within each in-scope legacy domain infrastructure, which may require removal as pre-migration tasks

This design methodology proposes the following approach for the determination of the directory clean up tasks for a legacy domain prior to migration:

Understand the directory objects and directory data that typically reside within a source legacy (Windows NT 4.0 or Windows 2000) domain and may require inclusion within the scope of directory clean up tasks.

Define the criteria for the inclusion and exclusion of directory objects and directory data from the scope of the directory clean up tasks

Select a legacy in-scope domain that requires migration and execute an analysis against that domain to identify the directory objects and directory data that will reside within the scope of the directory clean up tasks

Evaluate the identified directory objects and directory data against the defined inclusion and exclusion criteria to determine the scope of directory clean up tasks

Note that the approaches proposed by this design methodology, for the determination of the inclusion and exclusion criteria, is detailed and comprehensive for each in-scope class and type of directory object and data.

This is necessary to reflect the potential unacceptable consequences commonly noted from the accidental or intentional deletion of directory objects and data prior to consideration of the impact of such actions. In most cases, especially for security principal objects, the deletion of such objects in not functionally reversible, and hence compounding the unacceptable consequences.

This design methodology hence strongly recommends the methodical execution of all steps within the following processes.

• Factor B5: Understanding the scope of directory clean up tasks

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the scope of directory clean up tasks, represented by directory objects and directory data, common to all simple and optional migration paths.


This design methodology proposes that the directory objects, listed in table 44.1, and found within most Windows NT 4.0 and / or Windows 2000 domains, are potentially within the scope of the pre-migration directory clean up tasks for all supported simple or optional migration paths:

Potentially Redundant Directory ObjectsFound in Windows

NT 4.0 domainsFound in Windows

2000 domains


InetOrgPerson account objects 1




Potentially Redundant Directory ObjectsFound in Windows

NT 4.0 domainsFound in Windows

2000 domains

Security Group objects

Distribution Group objects

Table 44.1: Types of Potentially Redundant Directory Objects Found in Windows NT 4.0 and Windows 2000 Domains

1Following the extension to the Schema for a Windows 2000 forest to add the inetOrgPerson object class, via use of the Microsoft “Windows 2000 inetOrgPerson Kit”.

It is only necessary to consider directory data (not explicitly associated with the above objects) as been within the scope of pre-migration directory clean up tasks where the selected migration path for a legacy domain is simple paths “A” or “B” (for Windows NT 4.0 or Windows 2000 domains respectively). This is because only these paths retain directory data (not explicitly associated with the above objects) currently within the legacy domain during their execution to upgrade a legacy domain.

Note that directory data explicitly associated with the above directory objects include, for example, the attributes and their values for all user, inetOrgPerson, computer, and group account objects.

• Factor A1: Determination of the inclusion and exclusion criteria for the scope of the directory clean up tasks

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the criteria for the inclusion and exclusion of directory objects and directory data from the scope of directory clean up tasks.


This design methodology proposes the following approach for the determination of the inclusion and exclusion criteria:

Determine the inclusion and exclusion criteria common for all potentially in-scope directory objects and directory data

Then determine the inclusion and exclusion criteria for specific types of potentially in-scope directory objects and directory data

When determining the common criteria for the inclusion and exclusion of directory objects and directory data from the scope of directory clean up tasks (and hence the removal or retention of directory objects and data, respectively), consider the following:

It is important to ensure the defined criteria do not support the removal of directory objects or data essential to the operation of the legacy domain prior to the execution of any other pre-migration or migration tasks, and during an interim migration phase. The criteria must hence be specific and not vague or open to misinterpretation, as the personnel responsible for the definition of the criteria, and the evaluation of potential directory objects and data against the defined criteria may not be the same. For example, in some organisations, different departments are responsible for the authorisation of directory object and data deletion and the actual execution of deletion activities against existing directory objects and data.

Consider both the current and future requirements for directory objects and data when defining their inclusion or exclusion criteria. A domain migration from a Windows NT 4.0 domain infrastructure to a Windows Server 2003 Active Directory



infrastructure can radically change domain operations, and hence change directory object and data requirements.

It is important to consider the design for components of the target Windows Server 2003 Active Directory infrastructure (such as the ORMI partition(s) within a domain) prior to definition of the inclusion and exclusion criteria. For example, the design for the ORMI of a target domain may automatically exclude the requirements to retain existing OU infrastructures and GPOs within a legacy Windows 2000 domain, and security group objects within Windows 2000 and Windows NT 4.0 domains. Hence, where a directory object is currently valid and active within a legacy domain, following migration, these objects are no longer required.

The selected migration path may require or negate the requirements for extensive directory clean up tasks. For example, an in-place upgrade (simple migration paths “A” or “B”) of a legacy domain will take all existing directory objects into the target Windows Server 2003 domain, and hence potentially redundant objects. However, as a directory migration exercise (using simple migration paths “C” or “D”) permits the selective migration of directory objects, there is a requirement for only a narrow scope for directory clean up tasks.

For some directory objects and data, it may be difficult to ascertain the requirements to include or exclude them from directory clean up tasks. In these scenarios, it is necessary to develop custom approaches to determine this information (see later for details).

This design methodology proposes the following examples of common criteria for the inclusion / exclusion of all types of directory objects and data from directory clean up tasks:

“Exclude all directory objects (from the scope of directory clean up tasks) that comply with all of the following criteria:

• It is possible to easily verify that the directory object is known to be active and in use

• It is possible to identify one or more future requirements for the use of a directory object

• The directory object is supported in the target Windows Server 2003 Active Directory infrastructure”

“Include all directory objects (within the scope of directory clean up tasks) that comply with all of the following criteria:

• The directory objects are custom objects and not generated by default within the legacy domain infrastructure

• The removal of the custom directory objects will not disrupt any business or technical processes or continuity

• The custom directory objects are not supported in the target Windows Server 2003 Active Directory infrastructure”

When determining the inclusion and exclusion criteria for all specific types of directory objects and directory data, consider the following:

For some directory object types, it may be difficult to ascertain their potential for inclusion within the scope of pre-migration directory clean up tasks. For example, visual inspection of a list of user account objects may not permit the intuitive identification of potentially redundant or superfluous objects. Some user and computer account objects may be immediately identifiable as candidates for the



directory clean up tasks where it is possible to note, for example, the words “test” or “temp” in the name of the objects.

The selected migration path for a legacy domain may negate or require the execution of extensive directory data clean up. For example, using migration tools to perform a selective migration of directory objects and data from a legacy Windows 2000 domain will negate the requirement to clean up directory data within the domain and configuration partitions.


Determine and document the inclusion and exclusion criteria common for all potentially in-scope directory objects and directory data

Determine and document the inclusion and exclusion criteria for specific types of potentially in-scope directory objects and directory data

• Factor A2: Determination of the user and inetOrgPerson objects that require inclusion within the scope of pre-migration directory clean up tasks

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the user and inetOrgPerson objects that require inclusion within the scope of the pre-migration directory clean up tasks for a legacy domain.


Prior to determination of the inclusion and exclusion criteria for user and inetOrgPerson (where present) account objects from the scope of directory clean up tasks, consider the following:

The identification of user and inetOrgPerson account objects that require inclusion within the scope of directory clean up tasks is focused around the following metadata aspects of these objects:

The status (active or disabled) of the user account objects

The types and identifiable past, current, and future function(s) of the user account objects

The identifiable and intuitive redundancy of the user account objects

The identifiable indirect redundancy of the user account object due, for example, to the direct redundancy of the assignee user, application, resource, or service

The approach this design methodology proposes (see below), to support the identification of the user and inetOrgPerson objects that require inclusion within the scope of the directory clean up tasks, requires execution twice. The first execution of the approach below is now, during the analysis and design phase, and the second execution is during the pre-migration tasks for a legacy domain, just prior to actual migration. This two-step approach is necessary as the time between execution of the analysis and design phases and the actual pre-migration tasks may be a few weeks to even months, and hence many more user account objects may become potential candidates for directory clean up tasks during this period. The results of the first execution of the approach below will hence identify the current scope of the directory clean up tasks based upon the status of the Windows NT 4.0 SAM database or Windows 2000 Active Directory domain partition during the analysis and design phase for the migration plan. The second execution of the approach below will generate the final list of objects that require directory clean up.



The objectives for the proposed approach are to:

Identify all user account objects potentially within the scope of directory clean up tasks, and then

Assign the identified user account objects to one of the following categories:

• “Actually redundant” user account objects. These are user account objects, identified by the approach below as currently redundant, and that serve no current or future function. The deletion or disabling of these objects will not generate any unacceptable consequences.

• “Potentially redundant” user account objects. These are user account objects, identified by the approach below as potentially redundant, as they serve a current function in the legacy domain but not in the target Windows Server 2003 domain. The deletion or disabling of these objects will generate unacceptable consequences.

All “actually redundant” and “potentially redundant” user account objects are within the scope of the pre-migration directory clean up tasks. However, the differentiators between these two categories are:

The assurance that the identified redundancy status (as “actually” or “potentially”) of the directory objects and data will either:

• Not change for objects categorised as “actually” redundant, and hence require their exclusion from the freeze on change control for a legacy domain, or

• Change for objects categorised as “potentially” redundant, and hence require their inclusion within the freeze on change control for a legacy domain

The acceptability (by the organisation) of the consequences that may arise from their deletion, and

When, within this project, it is possible to disable the user account objects, prior to their deletion during execution of the pre-migration tasks.

This design methodology proposes the following approach towards the identification of the inclusion and exclusion criteria for existing user and / or inetOrgPerson (in the appropriately extended Schema for legacy Windows 2000 domains) account objects from the scope of directory clean up tasks:

Identify all existing user account objects and determine the types of user account objects that reside within the Windows NT 4.0 SAM database or the Windows 2000 Active Directory domain partition

Identify all user account objects from this list that can be potentially included into the scope of directory clean up tasks, based upon:

• One or more metadata aspects of the user account objects that intuitively places the objects outside of the migration scope for the domain, and hence within the scope of the pre-migration directory clean up tasks

• The current status (active / disabled) of the user account objects

• Compliance with redundancy criteria for user account objects

Determine the acceptable and unacceptable consequences from the intentional or accidental deletion of an existing user account object



Then, for each identified user account object, determine the consequences that may arise from the deletion of the identified user account object and determine whether the consequences are acceptable or unacceptable.

Define the criteria for the categorisation of all identified user account objects (which are potentially within the scope of directory clean up tasks) into the two categories:

• "Actually redundant"

• "Potentially redundant"

Evaluate the results of the above analysis against the defined criteria for categorisation of the user account objects and assign the appropriate category to the user account objects.

When determining the types of identified user account objects that reside within the Windows NT 4.0 SAM database or the Windows 2000 Active Directory domain partition, consider the following:

This design methodology identifies two broad categories for “types” of user account objects. These are “normal” and “resource” user accounts.

A “normal” user account object is one assigned to normal users for their sole use. The “normal” user account object has the following typical usage profile:

It is assigned to a user to permit the following:

• Their authentication against the legacy domain infrastructure

• Their authorisation for access to resources and services controlled by the domain infrastructure

• The assignment of rights to perform specific functions within the domain infrastructure

• The assignment of GPOs (in a legacy Windows 2000 domain)

It is typically only authorised by the administrators of the issuing domain for use by the single assignee user.

When the assignee user leaves the organisation, the user account is typically disabled, but not deleted until it is possible to attain and identify compliance with specific deletion criteria.

A “resource” user account object is one assigned to an application, resource, or service for the sole or shared use of the assignee(s). The “resource” user account object has the following typical usage profile:

It is assigned to an application, resource (such as a resource mailbox), or a service to permit the following:

• The authentication of the application, resource, or service against the legacy domain infrastructure

• The assignment of authority to access resources and services within the domain infrastructure





It is typically only authorised by the administrators of the issuing domain for use by a single assignee application, resource, or service. However, it is sometimes possible to identify multiple assignees for a single “resource” user account object.

Using the above information, conduct an analysis against the Windows NT 4.0 SAM database or Windows 2000 Active Directory domain partition of a legacy domain, and identify all instances of “normal” and “resource” user account objects.

When determining the function(s) of the identified existing user account objects, consider the following:

It is possible to determine the function of a user account object either directly or indirectly. A direct deduction of the function of a user account object is possible where the object itself has a function in addition or regardless of the function(s) of an assigned user, application, resource, or service. For example, a test user account has a function as a vehicle to support the execution of tests. Its existence and use is not a reflection of the function of the user of the test user account. An indirect deduction of the function of a user account object is possible from the function(s) of the assigned user, application, resource, or service within the organisation.

The role(s) of users within an organisation can dictate the importance of their assigned user accounts. For example, a “knowledge worker”, who exclusively relies upon a computer to perform their role within the organisation, will depend heavily upon a user account object. However, a factory floor worker or security guard, who only occasionally uses their assigned user accounts to, for example, check e-mails once a day will still be able to perform their role without the user account.

It is important to ascertain the role of applications, resources, and services assigned user account objects within the organisation. Where, for example, an application assigned a user account is critical to the mission and continuity of the organisation, then the integrity and preservation of this user account is key to the organisation.

When determining the criteria for the exclusion of user account objects from the scope of migration, based upon their metadata, consider the following:

It is possible to exclude user account objects from the scope of migration based upon their metadata, such as the direct or indirect function(s) of the user account objects (see later), the type of user account objects, or even the logical location (within the legacy domain infrastructure) of the user account objects.

For some user account objects, it is intuitively possible to deduce their redundancy status without the requirements for extensive analysis or research. For example, temporary or test user accounts identifiable via the words “temp” or “test” within the name and / or description attribute fields, or user accounts currently disabled. However, for the majority of user account objects, it may be difficult to ascertain their redundancy status without extensive analysis and research.

When determining the criteria to permit the intuitive deduction of the potential redundancy status of user account objects, based upon one or more metadata aspects of the objects, this design methodology proposes the following example criteria:

The user account object is identifiable, via visible metadata aspects only (such as the name, description, group membership, and so on) as been associated with a non-essential function pre-excluded from the scope of migration. For example:



• A user account object is readily identifiable as assigned to an application, and

• That application is outside of the scope of migration because the organisation has identified that the application is exclusively reliant upon a Windows NT 4.0 domain infrastructure and hence unable to operate within the target Windows Server 2003 Active Directory infrastructure.

The direct or indirect function of the user account object has excluded it from the scope of migration, and it is hence possible to consider the user account as been potentially redundant.

The assignees of some user account objects have very specific functions that are not portable from the legacy domain to the new Windows Server 2003 Active Directory infrastructure. It is hence possible to exclude these user account objects from the scope of migration, and hence possibly include them into the scope of directory clean up tasks, although not by default.

Certain user account objects, such as those created as test or temporary user accounts, are by direct function, excluded from the scope of migration, unless it is possible to identify explicit requirements to retain and hence include them within the migration scope.

Certain user accounts created within “resource” Windows NT 4.0 domains are excluded from migration, but the user accounts created within “account” Windows NT 4.0 domains are included within the migration scope.

User account objects that reside within the local SAM database of member servers may require exclusion from the migration scope.

When determining the influence that the current status of the identified existing user account objects has on their redundancy potential, consider the following:

A user account object may be active or disabled. An assigned user, application, resource, or service typically cannot use a disabled user account object until reactivation of the account. Hence, if it is possible to identify that the function of a disabled user account is exclusively to support a service, then that service either may no longer be required, or is in a state of suspension and pending future reactivation, then include that user account within the scope of directory clean up tasks.

Note that the “disabled” status of a user account does not necessarily imply that the user account is redundant. It is possible for a user account to reside in a disabled state to support multiple reasons such as:

• The domain administrators have assigned a user account object specific permissions and rights, to only occasionally access resources or execute specific domain operations. At all other times, when the account is not required, it requires retention in the disabled state.

• The user account object is a special system or vendor user account, and hence does not require manual management. For example, the “krbtgt” (the Key Distribution Center Service Account in Windows 2000 / 2003 Active Directory domains) is always disabled, or the “Guest” account, which is disabled by default.

• The user assignee for a user account object has left the organisation, or does not require the user account any more, and the account is disabled but not deleted. The domain administrators retain the user account in the disabled state to permit future activation of the account when required, and access resources to which the user account received access permissions. Only when



it is possible to attain compliance with the criteria for the deletion of the user account objects will the domain administrators delete the currently disabled user account.

When determining the criteria for the identification of redundant user account objects, consider the following:

It is possible to determine the redundancy of existing user account objects via, for example, the following:

The lack of use of the user account object based upon the last time the user account was used to logon to the domain by the assignee(s) of the account.

The presence of one or more inactive duplicates of an active user account object

The association of the user account object with a function outside of the migration scope for the legacy domain

To determine whether a user account object is redundant due to lack of use is rather difficult to ascertain in legacy Windows NT 4.0 or Windows 2000 domain infrastructures. For example:

In a Windows NT 4.0 domain environment, it is possible to retrieve the “last logon” timestamp for a user account from the PDC or BDC for the domain. However, this attribute and its value is unique to each Windows NT 4.0 domain controller queried, as it represents the last time the user was authenticated by only that domain controller. Hence, to retrieve a valid interpretation for this value, it is necessary to query all domain controllers that support the domain.

In a Windows 2000 Active Directory environment, each user account object has a “lastLogon” attribute. However, as for the Windows NT 4.0 domain controllers, there is no replication of this attribute to all the other domain controllers within the domain, and it is hence necessary to extract this information from each domain controller.

This design methodology proposes the following approach to determine the last logon period for a user account within a Windows NT 4.0 and / or Windows 2000 domain:

Define an appropriate duration criterion to support determination of the redundancy potential for a user account, based upon the period between the uses of a user account object. This value could be a few weeks to a few months or more. Compliance with this criterion suggests that the user account object is active and hence, based upon this factor, is not potentially redundant. For example, where an organisation defines a duration criterion of six months, and it is possible to identify a last logged on date and time for a user account of five months from this date, then it is necessary to consider this account as an active account.

Extract user logon information from each domain controller within the domain using the Windows resource kit utility “usrstat.exe”, outputting the data to a comma separated value (*.csv) file. This tool will extract the user name against last logon date and time, and will identify those accounts that have never been used to logon to the domain. Collate the results from each domain controller into a single spreadsheet, and evaluate against the defined duration criterion.

Identify all user account objects that have a last logged on time greater that the current date minus the defined duration criterion. These user account objects are hence potentially redundant.



Note that this procedure requires re-execution as a pre-migration task for the domain.

When determining the presence of potentially redundant duplicates of active user account objects, consider the following:

The duplication of a user account object may be based upon a duplication of one or more of the following metadata aspects of the objects:

• The direct or indirect function(s) and scope of the user account objects

• The assignee(s) (users, applications, resources, or services) of the user account objects

• One or more attributes of the user account objects

Note that it may be possible to find two or more user account objects that share one or more metadata aspects, but both of the objects are inactive, or neither is inactive.

This design methodology proposes the following approach to determine the presence of duplicate, and hence potentially redundant, user account objects:

Define the criteria for identification of duplicity amongst user account objects, based upon one or more of the metadata aspects of the objects. For example:

• “All user account objects with exactly the same assignee”

• “All user account objects with the same direct or indirect function based upon the data within their “description” attribute”

Extract a list of the user account objects from the legacy domain. Evaluate all extracted user accounts against the defined criteria and identify the potential duplicate account objects.

When determining the acceptable and unacceptable consequences of accidental or intentional deletion of the identified existing user account objects, consider the following:

The intentional or accidental deletion of a user account object can have consequences ranging from none to dire. This design methodology proposes that it is safer to consider the consequences for the deletion of any existing user account object as potentially dire, unless it is possible to prove otherwise. This is a safer approach, as it forces a considered and methodical approach to user account deletion.

The function(s) of the assignee(s) to a user account object dictate the potential consequences that may arise from the intentional or accidental deletion of a user account object. These can hence range from, for example:

The absence of any noticeable issues post-deletion of the user account objects, to

The inability of a user to perform their expected and required duties, to

The complete failure of an application or service, resulting in a breach of the SLA for the associated business process / application, and hence significant disruption to business continuity

There are numerous potential consequences associated with the intentional or accidental deletion of a user account object. For example:



Every user account object, as a security principal, receives a unique Security Identifier (SID) at the time of creation, which forms the foundation for authentication and authorisation. The accidental deletion and immediate recreation of a user account object, even with the same user name and other attribute data, will not recreate the same original user account, as it now has a new SID, which may not grant access to the same resources as the original account.

Applications, resources, and services assigned to the user account object may cease to function due to the loss of their security context. In these scenarios, where the deleted user account only provided an authentication function, and not authorisation, it is simpler to recreate an accidental user account object and re-associate it with the appropriate application, resource, or service.

The deletion of a user account object assigned to a service, which plays a critical role in the continuity of a mission critical business process, may generate a significant interruption to business continuity.

Although the onus is with the organisation when determining what they consider to be an “acceptable consequence” (based upon the function(s) of the assignee(s)), this design methodology proposes the following examples of criteria:

The noticeable consequences from the deletion of a user account object are of low priority as it is easily and completely possible to reverse the situation without any short, medium, or long-term issues.

The consequences of the deletion of a user account object are negligible, as they do not disrupt the continuity of any key business or technical processes.

Although the onus is with the organisation when determining what they consider to be an “unacceptable consequence” (based upon the function(s) of the assignee(s)), this design methodology proposes the following examples of criteria:

The noticeable consequences from the deletion of a user account object are of high priority as it is not easily and completely possible to reverse the situation without any short, medium, or long-term issues.

The consequences of the deletion of a user account object are significant, as they disrupt the continuity of one or more key business or technical processes.

When determining the criteria for the categorisation of user account objects into the “actually redundant” and “potentially redundant” categories, consider the following:

Although the onus is with the organisation to define the criteria for categorisation of the user account objects, this design methodology provides the following example criteria:

Categorise a user account as “actually redundant” where, for example, it is possible to identify compliance with the following criteria:

• It is possible to intuitively identify that the user account is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the user account object with the defined criteria for redundancy

• It is possible to identify compliance of the user account object with the criteria for acceptable consequences from the deletion / disabling of the user account object



Categorise a user account as “potentially redundant” where, for example, it is possible to identify compliance with the following criteria:

• It is possible to intuitively identify that the user account is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the user account object with the defined criteria for redundancy

• It is possible to identify compliance of the user account object with the criteria for unacceptable consequences from the deletion / disabling of the user account object

For all user account objects that unequivocally comply with the criteria for categorisation as “actually redundant”, define the following as the pre-migration directory clean up tasks for these user account objects:

Addition of the user account objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

The requirement to disable the user account objects

Optionally, for Windows 2000 domains, the requirement to move the disabled user account objects to a custom OU to differentiate them from active user account objects

For all user account objects that unequivocally comply with the criteria for categorisation as “potentially redundant”, define the following as the pre-migration directory clean up tasks for these user account objects:

Addition of the user account objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Modification of the description field to add text that denotes the user account objects as “potentially redundant” objects, but with no requirements to disable or move the user account objects


Determine and document the types of user and inetOrgPerson account objects that reside within the Windows NT 4.0 SAM database or the Windows 2000 Active Directory domain partition of the legacy domain

Determine and document the function(s) of the identified user account objects, and types of user account objects

Determine and document the criteria for the inclusion of user account objects from the scope of pre-migration directory clean up tasks based upon their metadata

Determine and document the criteria for the identification of redundant user account objects

Determine and document the acceptable and unacceptable consequences of the intentional or accidental deletion of a user account object

Determine and document the criteria for the categorisation of user account objects into the “actually redundant” and the “potentially redundant” categories



Evaluate all identified user account objects against the defined criteria, define, and document the pre-migration directory clean up tasks appropriate to their subsequent categorisation.

• Factor A3: Determination of the computer account objects that require inclusion within the scope of pre-migration directory clean up tasks

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to identify the computer account objects that require inclusion within the scope of the pre-migration directory clean up tasks for a legacy domain.


Prior to determination of the inclusion and exclusion criteria for computer account objects from the scope of pre-migration directory clean up tasks, consider the following:

Within most typical domains, it is possible to identify a greater percentage of redundant computer account objects, in comparison to active objects than for user or group accounts. This is because most organisations add and remove computer account objects from a directory service more frequently than user account objects.

The identification of computer account objects that require inclusion within the scope of pre-migration directory clean up tasks is focussed around the following metadata aspects of these objects:

The status (active or disabled) of the computer account objects

The types and past, current, and future function(s) of the computer account object

The identifiable and intuitive redundancy of the computer account objects

The identifiable indirect redundancy of the computer account objects due, for example, to the direct redundancy of the assignee server or client computer

The approach this design methodology proposes (see below), to support the identification of the computer account objects that require inclusion within the scope of the pre-migration directory clean up tasks, require execution twice. The first execution of this approach below is now, during the analysis and design phase, and the second execution is during the pre-migration tasks for a legacy domain, just prior to actual migration. This two-step approach is necessary as the time between execution of the analysis and design phases and the actual pre-migration tasks may be a few weeks to even months, and hence many more computer account objects may become potential candidates for directory clean up tasks during this period. The results of the first execution of the approach below will hence identify the current scope of the directory clean up tasks based upon the status of the Windows NT 4.0 SAM database or Windows 2000 Active Directory domain partition during the analysis and design phase for the migration plan. The second execution of the approach below will generate the final list of objects that require directory clean up.


Identify all computer account objects potentially within the scope of directory clean up tasks, and then

Assign the identified computer account objects to one of the following categories:

• “Actually redundant” computer account objects. These are objects, identified by the approach below as currently redundant, and that serve no current or



future function. The deletion or disabling of these objects will not generate any unacceptable consequences.

• “Potentially redundant” computer account objects. These are objects, identified by the approach below as potentially redundant, as they serve a current function in the legacy domain but not in the target Windows Server 2003 domain. The deletion or disabling of these objects will generate unacceptable consequences.

All “actually redundant” and “potentially redundant” computer account objects are within the scope of the pre-migration directory clean up tasks. However, the differentiators between these two categories are:





When, within this project, it is possible to disable the computer account objects, prior to their deletion during execution of the pre-migration tasks.

This design methodology proposes the following approach towards the identification of the inclusion and exclusion criteria for existing computer account objects from the scope of directory clean up tasks:

Identify all existing computer account objects and determine the types of computer account objects that reside within the Windows NT 4.0 SAM database or the Windows 2000 Active Directory domain partition

Identify all computer account objects from this list that can be potentially included into the scope of directory clean up tasks, based upon:

One or more metadata aspects of the computer account objects that intuitively places the objects outside of the migration scope for the domain, and hence within the scope of the pre-migration directory clean up tasks

The current status (active / disabled) of the computer account objects

Compliance with redundancy criteria for computer account objects

Determine the acceptable and unacceptable consequences from the intentional or accidental deletion of an existing computer account object

Then, for each identified computer account object, determine the consequences that may arise from the deletion of the identified computer account object and determine whether the consequences are acceptable or unacceptable.

Define the criteria for the categorisation of all identified computer account objects (which are potentially within the scope of directory clean up tasks) into the two categories:

"Actually redundant"



"Potentially redundant"

Evaluate the results of the above analysis against the defined criteria for categorisation of the computer account objects and assign the appropriate category to the computer account objects.

When determining the types of identified computer account objects that reside within the Windows NT 4.0 SAM database or the Windows 2000 Active Directory domain partition, consider the following:

This design methodology identifies two broad categories for “types” of computer account objects. These are computer accounts for “client” and “server” computers. All computer account objects are security principals and it is hence possible to assign rights and permissions to these objects.

A “client” computer account object is one assigned to a single client computer (desktop or laptop computer operating Windows NT 4.0 or later) and for the sole use of that computer. The “client” computer account object has the following typical usage profile:

It is assigned to a client computer to permit the following:

• Authentication of the computer against the legacy domain infrastructure

• Authorisation for access to resources and services controlled by the domain infrastructure



It is typically only authorised by the administrators of the issuing domain for use by the single assignee client computer.

Following the replacement and / or decommissioning of a client computer device, the computer account is typically disabled, but not deleted until it is possible to attain and identify compliance with specific deletion criteria.

A “server” computer account object is one assigned to a member server within the domain, for the sole use of the assignee server. The “server” computer account object has the following typical usage profile:

It is assigned to a member server computer to permit the following:

• The authentication of the member server against the legacy domain infrastructure

• The assignment of authority to access resources and services within the domain infrastructure



It is only authorised by the administrators of the issuing domain for use by a single assignee member server.



Using the above information, execute an analysis against the Windows NT 4.0 SAM database or Windows 2000 Active Directory domain partition of a legacy domain, and identify all instances of “client” and “server” computer account objects.

When determining the function(s) of the identified existing computer account objects, consider the following:

It is possible to determine the function of a computer account object either directly or indirectly. A direct deduction of the function of a computer account object is possible where the object itself has a function in addition or regardless of the function(s) of an assigned client or server computer. For example, a test computer account has a function as a vehicle to support the execution of tests, such as resultant set of policy planning, and so on. Its existence and use is not a reflection of the function of the client or server computer of the test computer account. An indirect deduction of the function of a computer account object is possible from the function(s) of the assigned client or server computer within the organisation.

The role(s) of the client and server computers within an organisation can dictate the importance of their assigned computer accounts. Where, for example, a server computer assigned a computer account is critical to the mission and continuity of the organisation, then the integrity and preservation of this computer account is key to the organisation.

When determining the criteria for the exclusion of computer account objects from the scope of migration, based upon their metadata, consider the following:

It is possible to exclude computer account objects from the scope of migration based upon their metadata, such as the direct or indirect function(s) of the computer account objects (see later), the type of computer account objects, or even the logical location (within the legacy domain infrastructure) of the computer account objects.

For some computer account objects, it is intuitively possible to deduce their redundancy status without the requirements for extensive analysis or research. For example, temporary or test computer accounts identifiable via the words “temp” or “test” within the name and / or description attribute fields, or computer accounts currently disabled. However, for the majority of computer account objects, it may be difficult to ascertain their redundancy status without extensive analysis and research.

When determining the criteria to permit the intuitive deduction of the potential redundancy status of computer account objects, based upon one or more metadata aspects of the objects, this design methodology proposes the following example criteria:

The computer account object is identifiable, via visible metadata aspects only (such as the name, description, group membership, and so on) as been associated with a non-essential function pre-excluded from the scope of migration. For example:

• A computer account object is readily identifiable as assigned to an server, and

• That server is outside of the scope of migration because the organisation has identified that the server hosts an application that is exclusively reliant upon a Windows NT 4.0 domain infrastructure and hence unable to operate within the target Windows Server 2003 Active Directory infrastructure.

The direct or indirect function of the computer account object has excluded it from the scope of migration, and it is hence possible to consider the computer account as been potentially redundant.



The assignees of some computer account objects have very specific functions that are not portable from the legacy domain to the new Windows Server 2003 Active Directory infrastructure. It is hence possible to exclude these computer account objects from the scope of migration, and hence possibly include them into the scope of directory clean up tasks, although not by default.

Certain computer account objects, such as those created as test or temporary computer accounts, are by direct function, excluded from the scope of migration, unless it is possible to identify explicit requirements to retain and hence include them within the migration scope.

There may be the requirement to exclude certain computer accounts created within “resource” Windows NT 4.0 domains from migration, but include the computer accounts created within “account” Windows NT 4.0 domains within the migration scope.

When determining the influence that the current status of the identified existing computer account objects has on their redundancy potential, consider the following:

A computer account object may be active or disabled. An assigned client or server computer cannot use a disabled computer account object until reactivation of the account. Hence, if it is possible to identify that the function of a disabled computer account is exclusively to support a server, then that server either may no longer be required, or is in a state of suspension and pending future reactivation, then include that computer account within the scope of directory clean up tasks.

Note that the “disabled” status of a computer account does not necessarily imply that the computer account is redundant. It is possible for a computer account to reside in a disabled state to support multiple reasons such as:

• The domain administrators have assigned a computer account object specific permissions and rights, to only occasionally access resources or execute specific domain operations. At all other times, when the account is not required, it requires retention in the disabled state.

• A user assigned a client computer has left the organisation, or does not require their computer any more, and hence, the associated computer account is disabled but not deleted. The domain administrators retain the computer account in the disabled state to permit future activation of the account when required, and access resources to which the computer account received access permissions. Only when it is possible to attain compliance with the criteria for the deletion of the computer account objects will the domain administrators delete the currently disabled computer account.

When determining the criteria for the identification of redundant computer account objects, consider the following:

It is possible to determine the redundancy of existing computer account objects via, for example, the following:

The lack of use of the computer account object based upon the last time an assigned client or server computer used the computer account.

The presence of one or more inactive duplicates of an active computer account object

The association of the computer account object with a function outside of the migration scope for the legacy domain



To determine whether a computer account object is redundant due to lack of use is rather difficult to ascertain in legacy Windows NT 4.0 or Windows 2000 domain infrastructures. However, identification of the continued presence of an assigned client or server computer may provide an indication of the redundancy status of a computer account object. Refer to the Microsoft Knowledge Base article KB197478, for details of a process for the identification and removal of inactive machine accounts within a Windows NT 4.0 domain environment.

When determining the presence of potentially redundant duplicates of active computer account objects, consider the following:

The duplication of a computer account object may be based upon a duplication of one or more of the following metadata aspects of the objects:

• The direct or indirect function(s) and scope of the computer account objects

• The assignee(client or server computer) of the computer account objects

• One or more attributes of the computer account objects

Note that it may be possible to find two or more computer account objects that share one or more metadata aspects, but both of the objects are inactive, or neither is inactive.

This design methodology proposes the following approach to determine the presence of duplicate, and hence potentially redundant, computer account objects:

Define the criteria for identification of duplicity amongst computer account objects, based upon one or more of the metadata aspects of the objects. For example:

• “All computer account objects with exactly the same assignee”

• “All computer account objects with the same direct or indirect function based upon the data within their “description” attribute”

Extract a list of the computer account objects from the legacy domain. Evaluate all extracted computer accounts against the defined criteria and identify the potential duplicate account objects.

When determining the acceptable and unacceptable consequences of accidental or intentional deletion of the identified existing computer account objects, consider the following:

The intentional or accidental deletion of a computer account object can have consequences ranging from none to dire. This design methodology proposes that it is safer to consider the consequences for the deletion of any existing computer account object as potentially dire, unless it is possible to prove otherwise. This is a safer approach, as it forces a considered and methodical approach to computer account deletion.

The function(s) of the assignee(s) to a computer account object dictate the potential consequences that may arise from the intentional or accidental deletion of a computer account object. These can hence range from, for example:

The absence of any noticeable issues post-deletion of the computer account objects, to

The inability of a user, application, resource, or server (operating and dependent upon a client / server computer and its account object) to perform their expected and required duties, to



The complete failure of an application or service, resulting in a breach of the SLA for the associated business process / application, and hence significant disruption to business continuity

There are numerous potential consequences associated with the intentional or accidental deletion of a computer account object. For example:

Every computer account object, as a security principal, receives a unique Security Identifier (SID) at the time of creation, which forms the foundation for authentication and authorisation. The accidental deletion and immediate recreation of a computer account object, with the same user name and other attribute data, will not recreate the same original computer account, as it now has a new SID, which may not grant access to the same resources as the original account.

Client and server computers, and the applications, resources, and services operational on the client / server computer) assigned to the computer account object may cease to function due to the loss of their security context.

The deletion of a computer account object assigned to a server hosting a service that plays a critical role in the continuity of a mission critical business process, may generate a significant interruption to business continuity.

Although the onus is with the organisation when determining what they consider to be an “acceptable consequence” (based upon the function(s) of the assignee(s)), this design methodology proposes the following examples of criteria:

The noticeable consequences from the deletion of a computer account object are of low priority as it is easily and completely possible to reverse the situation without any short, medium, or long-term issues.

The consequences of the deletion of a computer account object are negligible, as they do not disrupt the continuity of any key business or technical processes.

Although the onus is with the organisation when determining what they consider to be an “unacceptable consequence” (based upon the function(s) of the assignee(s)), this design methodology proposes the following examples of criteria:

The noticeable consequences from the deletion of a computer account object are of high priority as it is not easily and completely possible to reverse the situation without any short, medium, or long-term issues.

The consequences of the deletion of a computer account object are significant, as they disrupt the continuity of one or more key business or technical processes.

When determining the criteria for the categorisation of computer account objects into the “actually redundant” and “potentially redundant” categories, consider the following:

Although the onus is with the organisation to define the criteria for categorisation of the computer account objects, this design methodology provides the following example criteria:

Categorise a computer account as “actually redundant” where, for example, it is possible to identify compliance with the following criteria:

• It is possible to intuitively identify that the computer account is a candidate for directory clean up based upon one or more of its metadata aspects, or its status



• It is possible to identify compliance of the computer account object with the defined criteria for redundancy

• It is possible to identify compliance of the computer account object with the criteria for acceptable consequences from the deletion / disabling of the computer account object

Categorise a computer account as “potentially redundant” where, for example, it is possible to identify compliance with the following criteria:

• It is possible to intuitively identify that the computer account is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the computer account object with the defined criteria for redundancy

• It is possible to identify compliance of the computer account object with the criteria for unacceptable consequences from the deletion / disabling of the computer account object

For all computer account objects that unequivocally comply with the criteria for categorisation as “actually redundant”, define the following as the pre-migration directory clean up tasks for these computer account objects:

Addition of the computer account objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Requirement to disable the computer account objects

Optionally, for Windows 2000 domains, move the disabled computer account objects to a custom OU to differentiate them from active computer account objects

For all computer account objects that unequivocally comply with the criteria for categorisation as “potentially redundant”, define the following as the pre-migration directory clean up tasks for these computer account objects:

Addition of the computer account objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Modification of the description field to add text that denotes the computer account objects as “potentially redundant” objects, but with no requirements to disable or move the computer account objects


Determine and document the types of computer account objects that reside within the Windows NT 4.0 SAM database or the Windows 2000 Active Directory domain partition of the legacy domain

Determine and document the function(s) of the identified computer account objects, and types of computer account objects

Determine and document the criteria for the inclusion of computer account objects from the scope of pre-migration directory clean up tasks based upon their metadata

Determine and document the criteria for the identification of redundant computer account objects



Determine and document the acceptable and unacceptable consequences of the intentional or accidental deletion of a computer account object

Determine and document the criteria for the categorisation of computer account objects into the “actually redundant” and the “potentially redundant” categories

Evaluate all identified computer account objects against the defined criteria, define, and document the pre-migration directory clean up tasks appropriate to their subsequent categorisation.

• Factor A4: Determination of the security group objects that require inclusion within the scope of pre-migration directory clean up tasks

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the security group objects that require inclusion within the scope of pre-migration directory clean up tasks for a legacy domain.


Prior to determination of the inclusion and exclusion criteria for security group objects from the scope of pre-migration directory clean up tasks for a legacy domain, consider the following:

Within most organisations, it is possible to identify a larger percentage of redundant security group objects than user or computer account objects, due primarily to their diverse functions and roles within a legacy domain.

The functionality of a security group is based entirely upon the following two factors:

The membership of the security group, and / or

The rights, permissions, and (where appropriate) policies applied to the security group

Note that it is not possible, within a Windows NT 4.0 or Windows 2000 domain, to “disable” security group objects, unlike user or computer account objects. However, based upon the factors that define the functionality of the security group, it is possible to hence “functionally disable” security group objects via:

Removal of all rights, permissions, and (where appropriate) policies applied to the security group, or

Removal and lockdown of the membership of the security group

The identification of security group objects that require inclusion within the scope of pre-migration directory clean up tasks is focussed around the following metadata aspects of these objects:

The owners, functions and roles of the security groups within the domain

The member security principals (user and computer account objects, and other security groups) of the security groups

The logical locations of the security groups within the legacy domain infrastructure(s)

The identifiable and intuitive redundancy of the security group objects



The identifiable and indirect redundancy of the security group objects due, for example, to the direct redundancy of the function, role, and membership of the security groups.

As for the approaches to support the identification of the user, inetOrgPerson, and computer account objects that require inclusion within the scope of the directory clean up tasks, the proposed approach for security groups also requires execution twice.


Identify all security group objects potentially within the scope of directory clean up tasks, and then

Assign the identified security group objects to one of the following categories:

• “Actually redundant” security group objects. These are objects, identified by the approach below as currently redundant, and that serve no current or future function. The deletion or “functional disabling” of these objects will not generate any unacceptable consequences.

• “Potentially redundant” security group objects. These are objects, identified by the approach below as potentially redundant, as they serve a current function in the legacy domain but not in the target Windows Server 2003 domain. The deletion or “functional disabling” of these objects will generate unacceptable consequences.

All “actually redundant” and “potentially redundant” security group objects are within the scope of the pre-migration directory clean up tasks. However, the differentiators between these two categories are:




The acceptability (by the organisation) of the consequences that may arise from their deletion or “functional disabling”, and

When, within this project, it is possible to “functionally disable” the security group objects, prior to their deletion during execution of the pre-migration tasks.

This design methodology proposes the following approach towards the identification of the inclusion and exclusion criteria for existing security group objects from the scope of directory clean up tasks:

Identify all existing security group objects and determine the types of security group objects that reside within the Windows NT 4.0 SAM database or the Windows 2000 Active Directory domain partition.

Identify all security group objects from this list that can be potentially included into the scope of directory clean up tasks, based upon:

One or more metadata aspects of the security group objects that intuitively places the objects outside of the migration scope for the domain, and hence within the scope of the pre-migration directory clean up tasks



The current status of the security group objects

Compliance with redundancy criteria for security group objects

Define the criteria for the categorisation of all identified security group objects (which are potentially within the scope of directory clean up tasks) into the two categories:



Evaluate the results of the above analysis against the defined criteria for categorisation of the security group objects and assign the appropriate category to the security group objects.

When determining the types of identified security group objects that reside within the Windows NT 4.0 SAM database or the Windows 2000 Active Directory domain partition, consider the following:

This design methodology identifies the following four categories for “types” of security group objects, as a reflection of their scope of application and their host legacy domain:

“Local” security groups (within legacy Windows NT 4.0 domains)

“Domain Local” security groups (within legacy Windows 2000 domains)

“Global” security groups (within legacy Windows NT 4.0 and Windows 2000 domains)

“Universal” security groups (within legacy Windows 2000 Native mode domains)

A Windows NT 4.0 “local” security group object has the following typical usage profile:

It is generated within a Windows NT 4.0 domain to support the following:

• The collation of member security principals from within the same domain or trusted external domains

• The collective assignment of permissions, rights, and Windows NT 4.0 system policies to the members of the security group

A Windows 2000 “domain local” security group has the following typical usage profile:

It is generated within a Windows 2000 domain to support the following:

• The collation of member security principals from within the same domain, same forest, or trusted external domains

• The collective assignment of permissions, rights, and GPOs to the members of the security group

A “global” security group has the following typical usage profile:

It is generated within a Windows NT 4.0 domain to collate member security principals (from within the same domain as the Global security group) to support the following:



• Assignment of permissions, rights, and Windows NT 4.0 policies to the collated members (this is not a recommended practice), or

• Transport of the member security principals across one or more trust relationships to external trusting domains and target local (assuming target is Windows NT 4.0 domain) security groups

It is generated within a Windows 2000 domain to collate member security principals (from within the same domain as the Global security group) to support the following:

• Assignment of permissions, rights, and GPOs to the collated members (this is not a recommended practice)

• Transport of the member security principals across one or more trust relationships to other domains in the same forest or external trusting domains, and their target Domain Local security groups (assuming trusted external domain is a Windows 2000 domain).

A Windows 2000 “Universal” security group has the following typical usage profile:

It is generated within a Windows 2000 native mode domain to collate member security principals (from within the same domain as the universal security group, or any other domain in the same forest) to support the following:

• Assignment of permissions, rights, and GPOs to the collated members

• Transport of the member security principals across one or more trust relationships to other domains in the same forest or external trusting domains, and their target Domain Local security groups (assuming trusted external domain is a Windows 2000 domain).

Using the above information, conduct an analysis against the Windows NT 4.0 SAM database or Windows 2000 Active Directory domain partition of a legacy domain, and identify all instances of each of the above four “types” of security group objects.

When determining the function(s) of the identified existing security group objects, consider the following:

As stated earlier, it is possible to define the function of any security group by:

The membership of the security group, and / or

The rights, permissions, and (where appropriate) policies applied to the security group

A security group object hence does not have an identifiable function on its own, discrete to its members or the rights, permissions, policies, and so on assigned to the security group object.

Because of the roles security groups hold to support, for example, the execution of domain operations and processes, the determination of the function(s) of a security group is a critical prerequisite exercise to their evaluation for redundancy.

When determining the functions of a security group, identify the following information:

The membership of the security group, and, where possible, the function(s) the members of the security group have in common to hence warrant their membership to the group. This information will hence define the function of the group.



The use(s) of the security group as a vehicle for the assignment of permissions, rights, policies, and so on. For example, where it is possible to identify a security group used exclusively to target the implementation of GPOs within a Windows 2000 domain, this hence clearly defines the function of the group.

When determining the criteria for the exclusion of security group objects from the scope of migration, based upon their metadata, consider the following:

It is possible to exclude security group objects from the scope of migration based upon their metadata, such as the identified function(s) of the security group objects, the type of security group objects, or even the logical location (within the legacy domain infrastructure) of the security group objects.

For some security group objects, it is intuitively possible to deduce their redundancy status without the requirements for extensive analysis or research. For example, temporary or test security groups identifiable via the words “temp” or “test” within the name and / or description attribute fields, or security groups currently “functionally disabled”. However, for the majority of security group objects, it may be difficult to ascertain their redundancy status without extensive analysis and research.

When determining the criteria to permit the intuitive deduction of the potential redundancy status of security group objects, based upon one or more metadata aspects of the objects, this design methodology proposes the following example criteria:

The security group object is identifiable, via visible metadata aspects only (such as the type of group, name, description, group membership, and so on) as been associated with a function pre-excluded from the scope of migration. For example, it is possible to identify one or more security groups generated to exclusively support and control access to resources associated with a project within the organisation. After completion of the project, there was a failure to delete all strictly associated security groups.

The current function of the security group object has excluded it from the scope of migration, and it is hence possible to consider the security group as been potentially redundant. For example, the exclusive functions of one or more security groups are to support the assignment of Windows NT 4.0 system policies to users and computers within the domain. As Windows Server 2003 domains do not support Windows NT 4.0 system policies, and where it is possible for the organisation to identify the requirement to re-evaluate their approach and design for object management using GPOs instead, then the associated security groups are potentially redundant.

The design for a security group infrastructure (as a component of an ORMI within a target Windows Server 2003 domain) precludes the use and hence migration of specific types of existing security groups.

It is possible to identify one or more security groups where all of the member security principals are on the lists “actually redundant” or “potentially redundant” directory objects and hence within the scope of pre-migration directory clean up tasks.

It is possible to identify one or more security group objects, generated to exclusively support and control access to resources within the organisation. However, upon execution of an analysis into the resources supported by the security groups, it is possible to note that the resources no longer exist, or require differing access control requirements, not supported by the currently assigned security group object(s). These security groups are hence potentially redundant objects.



Certain security group objects, such as those created as test or temporary security groups, are by direct function, excluded from the scope of migration, unless it is possible to identify explicit requirements to retain and hence include them within the migration scope.

Certain security groups created within “resource” Windows NT 4.0 domains are excluded from migration, but the security groups created within “account” Windows NT 4.0 domains are included within the migration scope.

Security group objects that reside within the local SAM database of member servers may require exclusion from the migration scope.

When determining the influence that the current status of the identified existing security group objects has on their redundancy potential, consider the following:

A security group object may be active or “functionally disabled”. A “functionally disabled” security group either has:

• No members, or

• No active members (all user and computer account objects, as members of the group, are disabled), and / or

• No assigned rights, permissions, policies, and so on

Note that in a legacy Windows 2000 domain, it is possible to use one of the following other methods to “disable” a domain or local security group:

• Impose a functional restriction on the security group via the assignment of a GPO employing the “Restricted Groups” feature, to hence restrict the membership of the group to (for example) no members.

• Change the type of the group from been a security group to become a distribution group. A distribution group is no longer a security principal, and hence has no assigned rights, permissions, policies, and so on.

Note that the “functionally disabled” or “functionally restricted” status of a security group does not necessarily imply that the security group is redundant. It is possible for a security group to reside in this unique disabled state to support multiple reasons such as:

• The domain administrators have assigned a security group object specific permissions and rights, to only occasionally support access to resources or execute specific domain operations. At all other times, when the group is not required, it may fall, for example, within the scope of a GPO that restricts the membership of the group, effectively removing all members. It is possible to support any requirements to use the group, via population with active security principals, until the next (for example) scheduled refresh of the appropriate GPO to restore the group to its default status of “functionally disabled”.

• The security group object is a special vendor security group to support a specific application. Where the application is either not currently in use, or pending upgrades, and so on, then there is a requirement to hold the group in the “functionally disabled” state.

When determining the criteria for the identification of redundant security group objects, consider the following:

It is possible to determine the redundancy of existing security group objects via, for example, the following:



• The lack of use of the security group object based upon the last time there was a requirement to use a security group to support domain-related activities of one or more of the member security principals.

• The association of the security group object with a function outside of the migration scope for the legacy domain

• The presence of one or more active or inactive duplicates of an active security group object, and hence the opportunity for security group consolidation

To determine whether a security group object is redundant due to lack of use is rather difficult to ascertain in legacy Windows NT 4.0 or Windows 2000 domain infrastructures. Unlike the “lastLogon” attribute for Windows 2000 user account objects, there are no such attributes for Windows NT 4.0 or Windows 2000 security group objects.

The design for the security group component of the ORMI within the target Windows Server 2003 domain for a legacy domain will influence the potential redundancy of existing security group objects. If the methodology, approach, and use of group design models within the current legacy domain do not match the target Windows Server 2003 domain, then this may automatically make all current security groups redundant, due to a function mismatch.

When determining the presence and design requirements for the management of potentially redundant duplicate instances of active security group objects, consider the following:

It is important to identify and manage duplicate instances of security groups within an organisation as this may hence:

Reduce the overall workload associated with the migration scope

Increase efficiency in security group management

Increase efficiency in the associated management of objects and resources using security groups

This design methodology proposes the following approach towards the identification and management of duplicate security group objects:

Determine the presence and details of duplicate security groups within a legacy domain via the definition of criteria for their identification

Following the identification of multiple “duplicate” instances of a security group (based upon their function(s), role(s), owner(s), members, and so on), it is necessary to execute the following steps to develop an action plan:

• Select, from the two or more duplicate security groups a single “primary” security group, to which there are one or more duplicate “secondary” security groups. This hence requires the definition of criteria for the selection of the “primary” security group.

• For each collection of duplicate security groups, it is necessary to define criteria for the selection of one of the following two options as action plans to deal with duplicate instances of security groups:

♦ Option 1 is to delete all identified duplicate “secondary” groups, and retain the identified “primary” security group



♦ Option 2 is to consolidate all identified duplicate “secondary” groups within the identified “primary” security group, and then delete the identified duplicate “secondary” groups

♦ Following the selection of the appropriate action plan for each collection of duplicate security groups, it is necessary to determine the design requirements for the execution of the required option.

When determining the criteria for the identification of duplicate instances of a security group object, consider the following:

It is possible to identify two or more duplicate instances of a security group object based upon the duplication of one or more of the following metadata aspects of the objects:

• The role(s), function(s), and scope of the security group objects

• The member security principals of the security group objects

• One or more attributes or other metadata aspects of the security group objects, such as the name, description, logical location of the security group objects within the legacy domain infrastructure, and so on.

Note that it is not possible to use any single matching metadata aspect of a security group to identify its status as a duplicate instance of another existing security group. It is necessary instead to employ a combination of metadata aspects for security groups to determine the presence of duplicate instances of the groups. The criteria for the identification of duplicate instances of active security groups must hence reflect this requirement to employ combinations of metadata aspects for security groups.

Although the onus is with the organisation to define the criteria for the identification of duplicate instances of security groups, this design methodology proposes the following example criteria:

• It is possible to identify two or more existing security groups with the following matching metadata aspects:

♦ The “type” and “scope” of security group, such as both / all are “Global” security groups, and

♦ The list of member security principals, such as the user and computer account objects, and other security group objects

• It is possible to identify two or more existing security groups with the following matching metadata aspects:

♦ The function(s) of the security groups, as a reflection of the rights AND permissions assigned to the security groups, and

♦ The names of the security groups, and

♦ The logical location of the security group within a legacy domain (such as a custom OU within a legacy Windows 2000 domain)

Note that when determining the criteria for the identification of duplicate instances of active security groups, and evaluating potential groups against these criteria, it is necessary to ensure complete compliance with all defined and required criteria. For example, out of five potential duplicate instances of security groups, although all five groups collectively match all defined criteria, only four



groups exactly match one criterion, and three groups exactly match the other criterion. This level of compliance with the defined criteria is unacceptable for classification of the identified security groups as duplicate instances of each other. In this example, it is hence necessary for all five instances of security groups, individually, to support an exact match with each defined criterion.

Following the identification of two or more collections of duplicate instances of existing security groups, consider the following when determining the criteria for the selection of the “primary” security group object within each identified collection of duplicate instances:

It is necessary to identify a single “primary” security group object within each collection of duplicate instances. This is because the objective of this step, and the result of either of the only two logical options to manage this scenario, is to eliminate all duplicate instances of security groups, during execution of the pre-migration directory clean up tasks. The remaining security groups, after completion of the directory clean up tasks, are hence the selected “primary” security group objects.

This design methodology proposes the following examples of aspects of security groups, as the basis for criteria to support the selection of the “primary” security group from a collection of duplicate instances:

• The date and time of creation of the security groups within the collection of duplicate instances, where, for example, the earliest created group is a potential candidate for nomination as the “primary” security group

• The potential consequences from the deletion of the security groups, based upon, for example, the influence of the security group on business continuity, and so on (see later for details on the determination of the acceptable and unacceptable consequences from the deletion of security groups). A security group with unacceptable consequences rated the highest priority is a suitable candidate for selection as the “primary” security group.

• The power and influence associated with the owner(s) of the security groups, where it is possible to identify two or more owners for the identified collection of duplicate instances. For example, the owner(s) able to exert the greatest influence on the retention of their security groups may hence influence the selection of a “primary” security group from the collection of duplicate instances.

• The security group with the highest usage profile based upon, for example, the largest number of assigned rights, permissions, policies and so on, is a potential candidate for nomination as the “primary” security group within a collection of duplicate instances. Note that this criterion relates also to the criterion identifying the priority of unacceptable potential consequences from the deletion of a security group object.

• The security group with the most in common with all other duplicate instances is a potential candidate for nomination as the “primary” security group within a collection of duplicate instances.

When determining the criteria for the selection of option 1 or 2 to manage the duplicate instances of security groups, consider the following:

The selection of option 1 results in the deletion of all duplicate instances of a selected “primary” security group, without retention or re-use of the function(s), role(s), memberships, or other metadata aspects of the “secondary” security groups. This outright deletion can hence have significant consequences, and



thus the criterion to support the selection of this option is required to reflect the significance of these consequences.

Hence, when determining the acceptable and unacceptable consequences of accidental or intentional deletion of any identified existing security group objects, or “secondary” duplicate instances of security groups, consider the following:

• The intentional or accidental deletion of a security group object can have consequences ranging from none to dire. This design methodology proposes that it is safer to consider the consequences for the deletion of any existing security group object as potentially dire, unless it is possible to prove otherwise. This is a safer approach, as it forces a considered and methodical approach to security group deletion.

• The current and proposed function(s) of the security group object dictate the potential consequences that may arise from the intentional or accidental deletion of a security group object. These can hence range from, for example:

♦ The absence of any noticeable issues post-deletion of the security group objects, to

♦ The inability of a member user or computer to perform their expected and required duties, to

♦ The complete failure of an application or service, resulting in a breach of the SLA for the associated business process / application, and hence significant disruption to business continuity

• There are numerous potential consequences associated with the intentional or accidental deletion of a security group object. For example:

♦ Every security group object, as a security principal, receives a unique Security Identifier (SID) at the time of creation, which forms the foundation for authentication and authorisation. The accidental deletion and immediate recreation of a security group object, even with the same group name and other attribute data, will not recreate the same original security group, as it now has a new SID, which may not grant access to the same resources as the original group object.

♦ The accidental or intentional deletion of a security group may result in the loss of a security context the group provided to member users and computers. Their loss or degradation of security context could impair their ability to execute all functions and tasks dependent upon the security context provided by the deleted security group. For example, a security group within a legacy Windows 2000 domain supports the targeting of a GPO that delivers a critical software application to a selected group of users, represented as members of the security group. The configuration of the software package in the GPO requires removal of the software from the target computers following the removal of the target security principals from the scope of management of the GPO. Deletion of the security group will hence result in the loss of its associated security context, and hence the removal of the critical software package from the user’s computers.

• Although the onus is with the organisation when determining what they consider to be an “acceptable consequence” (based upon the function(s) of the assignee(s)), this design methodology proposes the following examples of criteria:



♦ The noticeable consequences from the deletion of a security group object are of low priority as it is easily and completely possible to reverse the situation without any short, medium, or long-term issues.

♦ The consequences of the deletion of a security group object are negligible, as they do not disrupt the continuity of any key business or technical processes.

• Although the onus is with the organisation when determining what they consider to be an “unacceptable consequence” (based upon the function(s) of the assignee(s)), this design methodology proposes the following examples of criteria:

♦ The noticeable consequences from the deletion of a security group object are of high priority as it is not easily and completely possible to reverse the situation without any short, medium, or long-term issues.

♦ The consequences of the deletion of a security group object are significant, as they disrupt the continuity of one or more key business or technical processes.

Although the onus is with the organisation to define the criteria for the selection of option 1, this design methodology proposes the following examples of selection criteria:

• Select option 1, for the outright deletion of all duplicate “secondary” instances of a “primary” security group where it is possible to attain compliance with the following criteria:

♦ The deletion of all identified “secondary” duplicate instances of a “primary” security group is associated only with predefined acceptable consequences, and

♦ There is no identified requirement to retain and re-use any of the rights, permissions, policies, group memberships, and so on, associated with the “secondary” groups on the selected “primary” security group.

♦ Every identified duplicate “secondary” group is an exact match, in all relevant metadata aspects of the groups, to the selected “primary” security group, and hence consolidation of the groups is not required.

• Select option 1 where it is possible to attain compliance with the following criteria:

♦ The identified “secondary” duplicate security groups are independently identified as potentially redundant from earlier analysis and based upon their metadata aspects, and / or

♦ The consolidation of the function(s) of the identified “secondary” security groups (represented as the consolidation of the assigned rights, permissions, and policies on all “secondary” groups to the selected “primary” group) would violate the required function(s) of the selected “primary” group. For example, it could result in the loss or generation of an unwanted security context for the member security principals of the “primary” security group.

♦ The consolidation of one or more aspects of the identified “secondary” security groups with the “primary” security group would result in the unacceptable loss of control over management of security group membership by the owner(s) of the “duplicate” security groups. In this



scenario, the owner(s) of the “secondary” security groups may opt to delete their groups, and generate new unique groups, rather than relinquish control over group membership, group application, and so on, to the owner(s) of a primary security group.

The selection of option 2, to consolidate one or more metadata aspects of identified “secondary” groups with the selected “primary” group, prior to deletion of the “secondary” groups, requires careful consideration. The consolidation of security groups is fraught with potentially unacceptable consequences that require identification and consideration prior to selection of this option, and hence require reflection in the selection criteria for option 2.

When determining the criteria for the selection of option 2, to consolidate and then delete “secondary” duplicate groups, consider the following:

• The basis for the identification of the duplicity of two or more security groups is essential to the definition of the selection criteria for option 2 and to the determination of the design requirements for execution of option 2.

• The consolidation of one or more “secondary” duplicate groups with a “primary” security group has the potential to generate the following examples of consequences:

♦ The consolidated “primary” security group provides its member security principals with a more expansive security context, which may exceed their stated requirements, and thus generate a potential security breach. It is possible to identify this example consequence where the criteria to determine the presence of duplicate security groups is based upon matching role(s) or other metadata aspects of the security groups, that excluded the lists of member security principals, or the assigned rights, permissions, and policies.

♦ The consolidated “primary” security group is under new ownership and hence management. The entry criteria to the security group may hence no longer support the addition of security principals that may have complied with the entry criteria for the pre-consolidation “secondary” groups, and may even require the removal of current members from the group.

♦ A consolidated “primary” security group, via new ownership and management, is required to comply with differing retirement policies, and hence may have a shorter lifespan than the pre-consolidation “secondary” groups.

• Although the onus is with the organisation to define the criteria for the selection of option 2, this design methodology proposes the following examples of criteria to support the selection of option 2:

♦ Select option 2, to consolidate one or more “secondary” security groups with a selected “primary” security group prior to deletion of the “secondary” groups, where it is possible to attain compliance with the following (non-specific) criteria:

It is not possible to identify any unacceptable consequences from the consolidation of one or more “secondary” security groups with a selected “primary” group, and

It is possible to identify one or more acceptable consequences from the consolidation



♦ Select option 2 where it is possible to attain compliance with the following (specific) criteria:

It is possible to identify one or more metadata aspects of the “secondary” security groups required by the selected “primary” security group, and

Failure to consolidate one or more of the metadata aspects of the “secondary” security groups with the selected “primary” security group may result in the loss of business continuity or other unacceptable consequence, due to the loss of functionality.

• Following the identification of the criteria to select option 2, it is necessary to determine which metadata aspects of the “secondary” security groups require consolidation with a selected “primary” security group. It is hence necessary to define the criteria for the selection of the consolidation metadata aspect.

• This design methodology supports the consolidation of the following metadata aspects of the “secondary” security groups with the selected “primary” security group:

♦ The assigned rights, permissions (ACLs, DACLs, and SACLs), and policies, where appropriate

♦ The lists of member security principals

♦ The name(s), description, notes for the security groups

♦ The logical location(s) of the security groups within the legacy domain infrastructure

Following the identification of the required option(s) to handle duplicate instances of security groups, the next step is to determine the design requirements for the execution of the required option(s). Consider the following information when determining the design requirements for the execution of option 1 and / or option 2:

The execution of option 1 requires the following approach:

• Identification of all “secondary” duplicate instances of a “primary” security group

• Deletion of all “secondary” security group objects

When determining the design requirements for the first step in this approach to execute option 1, consider the following:

• The design requirements for the execution of this first step depend upon the numbers of “primary” security groups, and their respective “secondary” security groups, and organisation identifies within a legacy domain. Where an organisation identifies only a few (for example, less than twenty or thirty collections of duplicate groups), then it may be feasible to selectively delete the respective “secondary” security groups manually. However, where there are more than a few collections and instances of duplicate security groups identified, or even many hundreds or thousands, it is necessary to design and employ an automated process to delete the unwanted duplicate “secondary” security groups.

• Consider the use of the following command line tools and commands to extract the lists of domain security groups:



♦ Use “net group” to extract a list of the Global (in Windows NT 4.0 and Windows 2000 domains) and Universal (in Windows 2000 native mode domains) security groups, and output this list to a text file, using the following example command: “net group >C:\temp\groups.txt”.

♦ Use “net localgroup” to extract a list of the Local or Domain Local (in Windows NT 4.0 or Windows 2000 domains respectively) security groups, and output this list to a text file, using the following example command: “net localgroup >C:\temp\localgroups.txt”.

When determining the design requirements for the execution of the second step, to delete all “secondary” security groups, consider the following:

• Following the extraction of the list of groups, it is necessary to either:

♦ Delete from the list all required (non-redundant) security groups, and this retain the “secondary” groups that require deletion, or

♦ Differentiate the “primary” security groups from the “secondary” groups via, for example, a description entry or name change, or

♦ Differentiate the “secondary” security groups from the “primary” groups via, for example, a description entry or name change.

• Consider the use of the “net group” and “net localgroup” command line tools and commands, with the “/delete” switch to delete the appropriate “secondary” groups. It is possible to incorporate these commands into a batch file or script to simply processing.


• Identification of all “secondary” duplicate instances of a “primary” security group

• Selection and design of a method to consolidate the required metadata aspects of each “secondary” security group with the selected “primary” security group for a collection of duplicate groups

• Deletion of all “secondary” security group objects

Employ the same process and approach to execute the first step in this approach for option 2, via the use of the “net group” and “net localgroup” command line tools and commands.

When determining the design requirements for the execution of the second step in option 2 above, to consolidate one or more metadata aspects of the “secondary” security groups with the selected “primary” security group, consider the following:

• This design methodology supports the use of the Windows NT 4.0 / Windows 2000 resource kit tool “Group Copy” (grpcpy.exe) to consolidate the memberships of “secondary” security groups. Group Copy is a GUI based tool that can copy members from one group to another group in the same domain, or even a different trusting domain.

• This design methodology supports the use of the Windows NT 4.0 / Windows 2000 resource kit tool “subinacl.exe” to copy the following types of permission metadata aspects of “duplicate” secondary security groups with a selected “primary” security group:



♦ The permission access control entries (PACEs)

♦ The permission (or discretionary) access control lists (ACLs or DACLs), and

♦ The system access control entries and lists (SACEs and SACLs) (to support access by the system for auditing)

• Note that although subinacl is a highly versatile tool, it is also very powerful, and hence demands a thorough understanding and respect for of its capabilities and functions prior to use.

• As mentioned earlier, and important to re-iterate here, when consolidating logical location(s) for “secondary” security groups with a target “primary” security group within, for example, a legacy Windows 2000 domain, consider the potential impact associated with the loss or gain in functionality of the moved security groups / members of the groups. For example, where there are three OUs (OU1, OU2, and OU3), and the selected “primary” group logically resides within OU3, with one “secondary” security group in OU1 and another in OU2. Consolidation of these “secondary” groups from OU1 and OU2 to the “primary” group in OU3, via moving members in these groups, may mean that the members will lose permissions / policies assigned to the groups inherited by OU1 and OU2, but gain new permissions / policies assigned to the “primary” group inherited by OU3. This action may result in either acceptable or unacceptable consequences, which thus require evaluation and investigation prior to execution.

• When determining the requirements for the consolidation of the names of “duplicate” secondary groups within a selected “primary” group, consider the following:

♦ The consolidation of multiple names for “secondary” security groups to generate a new name for a “primary” security group requires observance and compliance with any existing or proposed object-naming model for security group objects. For example, within a legacy domain, the current / proposed object-naming model supports the use of a multiple component name for security groups, and each component reflects a metadata aspect of the security group. Where a component of the name reflects the function of the group, as an abbreviated description, then it may be necessary to consolidate the function(s) of each group (primary and secondary) within the collection of duplicate groups to generate a description for the final function(s) of the “primary” group.

♦ Following the determination of the final name(s) for the “primary” security groups, it is possible to automate their renaming to reflect the new metadata aspects of these groups, where appropriate.

Employ the same process and approach to execute the third step in this approach for option 2, via the use of the “/delete” switch with the “net group” and “net localgroup” command line tools and commands.

When determining the criteria for the categorisation of security group objects into the “actually redundant” and “potentially redundant” categories, consider the following:

Although the onus is with the organisation to define the criteria for categorisation of the security group objects, this design methodology provides the following example criteria:

Categorise a security group as “actually redundant” where, for example, it is possible to identify compliance with the following criteria:



• It is possible to intuitively identify that the security group is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the security group object with the defined criteria for redundancy (such as lack of use, exclusion from the migration scope, or status as a duplicate “secondary” security group object to a “primary” security group object)

• It is possible to identify compliance of the security group object with the criteria for acceptable consequences from the deletion / disabling of the security group object

Categorise a security group as “potentially redundant” where, for example, it is possible to identify compliance with the following criteria:

• It is possible to intuitively identify that the security group is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the security group object with the defined criteria for redundancy (such as lack of use, exclusion from the migration scope, or status as a duplicate “secondary” security group object to a “primary” security group object)

• It is possible to identify compliance of the security group object with the criteria for unacceptable consequences from the deletion / disabling of the security group object

For all security group objects that unequivocally comply with the criteria for categorisation as “actually redundant”, define the following as the pre-migration directory clean up tasks for these security group objects:

Addition of the security group objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Requirement to functionally disable the security group objects

Optionally, for Windows 2000 domains, move the functionally disabled security group objects to a custom OU to differentiate them from active security group objects

For all security group objects that unequivocally comply with the criteria for categorisation as “potentially redundant”, define the following as the pre-migration directory clean up tasks for these security group objects:

Addition of the security group objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Modification of the description field to add text that denotes the security group objects as “potentially redundant” objects, but with no requirements to functionally disable or move the security group objects


Determine and document the types of security group objects that reside within the Windows NT 4.0 SAM database or the Windows 2000 Active Directory domain partition of the legacy domain

Determine and document the function(s) of the identified security group objects, and types of security group objects



Determine and document the criteria for the inclusion of security group objects from the scope of pre-migration directory clean up tasks based upon their metadata

Determine and document the criteria for the identification of redundant security group objects

Determine and document the required approach towards the identification and management of duplicate security group objects

Determine and document the criteria for the categorisation of security group objects into the “actually redundant” and the “potentially redundant” categories

Evaluate all identified security group objects against the defined criteria, define, and document the pre-migration directory clean up tasks appropriate to their subsequent categorisation.

• Factor A5: Determination of the distribution group objects that require inclusion within the scope of pre-migration directory clean up tasks


Has identified the requirement for the migration of one or more legacy Windows 2000 domains

Has identified the presence of a few hundred or more distribution group objects within the domain partition of one or more legacy in-scope Windows 2000 domains, and

Wishes to determine the distribution group objects that require inclusion within the scope of pre-migration directory clean up tasks


Prior to determination of the inclusion and exclusion criteria for distribution group objects from the scope of pre-migration directory clean up tasks for a legacy Windows 2000 domain, consider the following:

The threshold stated for the number of distribution group objects within the criteria for the application of this factor reflects the fact that the execution of this process is only useful in organisations with a significant population of these objects.

Within most Windows 2000 domains, especially where the domain supports an Exchange 2000 or Exchange Server 2003 infrastructure, it is possible to identify a larger percentage of redundant distribution group objects than user or computer account objects. This may be due, for example, to the extensive employment of distribution groups to support only temporary e-mail distribution requirements.

Unlike security groups, the functionality of Windows 2000 distribution groups is a reflection of only the membership of the distribution group. This is because distribution groups are not security principals, and hence it is not possible to assign rights or permissions to distribution groups, or employ them as vehicles for the targeting of GPOs.

The sole function of distribution groups is to support and simplify the targeting of e-mails to all of the members of the targeted distribution groups. They cannot support or control access to resources, or pass inherited / assigned permissions to their members, unless the host Windows 2000 domain is operating in native mode and a Domain Administrator converts a distribution group to become a security group.



Any security principal and non-security principal (such as a contact object or other distribution group) can become a member of a distribution group. However, as the function of such objects is to support the distribution of e-mails to members of the groups, there is no requirement to support computer objects or other objects to which it is not possible to assign an e-mail address.

Note that it is not possible, within a Windows 2000 domain, to “disable” distribution group objects, unlike user or computer account objects. However, based upon the factor that defines the functionality of the distribution group, it is possible to hence “functionally disable” distribution group objects via the removal and lockdown of the membership of the distribution group

The identification of distribution group objects that require inclusion within the scope of pre-migration directory clean up tasks is focussed around the following metadata aspects of these objects:

The owner(s) of the distribution groups within the domain

The e-mail address / mailbox enabled members of the distribution groups

The logical locations of the distribution groups within the legacy domain infrastructure(s)

The identifiable and intuitive redundancy of the distribution group objects

The identifiable and indirect redundancy of the distribution group objects due, for example, to the direct redundancy of the function, role, and membership of the distribution groups.

As for the approaches to support the identification of the user, inetOrgPerson, and computer account objects that require inclusion within the scope of the directory clean up tasks, the proposed approach for distribution groups also requires execution twice.


Identify all distribution group objects potentially within the scope of directory clean up tasks, and then

Assign the identified distribution group objects to one of the following categories:

• “Actually redundant” distribution group objects. These are objects, identified by the approach below as currently redundant, and that serve no current or future function. The deletion or “functional disabling” of these objects will not generate any unacceptable consequences.

• “Potentially redundant” distribution group objects. These are objects, identified by the approach below as potentially redundant, as they serve a current function in the legacy domain but not in the target Windows Server 2003 domain. The deletion or “functional disabling” of these objects will generate unacceptable consequences.

All “actually redundant” and “potentially redundant” distribution group objects are within the scope of the pre-migration directory clean up tasks. However, the differentiators between these two categories are:






The acceptability (by the organisation) of the consequences that may arise from their deletion or “functional disabling”, and

When, within this project, it is possible to “functionally disable” the distribution group objects, prior to their deletion during execution of the pre-migration tasks.

This design methodology proposes the following approach towards the identification of the inclusion and exclusion criteria for existing distribution group objects from the scope of directory clean up tasks:

Identify all existing distribution group objects and determine the types of distribution group objects that reside within a Windows 2000 Active Directory domain partition.

Identify all distribution group objects from this list that can be potentially included into the scope of directory clean up tasks, based upon:

One or more metadata aspects of the distribution group objects that intuitively places the objects outside of the migration scope for the domain, and hence within the scope of the pre-migration directory clean up tasks

The current status of the distribution group objects

Compliance with redundancy criteria for distribution group objects

Define the criteria for the categorisation of all identified distribution group objects (which are potentially within the scope of directory clean up tasks) into the two categories:



Evaluate the results of the above analysis against the defined criteria for categorisation of the distribution group objects and assign the appropriate category to the distribution group objects.

When determining the types of identified distribution group objects that reside within a Windows 2000 Active Directory domain partition, consider the following:

This design methodology identifies the following three categories for “types” of distribution group objects, as a reflection of their scope of application:

“Domain Local” distribution groups

“Global” distribution groups

“Universal” distribution groups

Using the above information, conduct an analysis against a Windows 2000 Active Directory domain partition of a legacy domain, and identify all instances of each of the above three “types” of distribution group objects.

When determining the function(s) of the identified existing distribution group objects, consider the following:



As stated earlier, it is only possible to define the function of any distribution group by the membership of the distribution group. A distribution group object hence does not have an identifiable function on its own, discrete to its members

Because of the roles distribution groups hold to support the distribution of e-mails to members of the groups, the determination of the function(s) of a distribution group is an essential prerequisite exercise to their evaluation for redundancy.

When determining the functions of a distribution group, identify the membership of the distribution group, and, where possible, the function(s) the members of the distribution group have in common to hence warrant their membership to the group. This information will hence define the function of the group. For example, where the members of a distribution group represent an entire department, then the function of the group is to support the distribution of all e-mails to all members of that department.

When determining the criteria for the exclusion of distribution group objects from the scope of migration, based upon their metadata, consider the following:

It is possible to exclude distribution group objects from the scope of migration based upon their metadata, such as the identified function(s) of the distribution group objects, the type of distribution group objects, or even the logical location (within the legacy domain infrastructure) of the distribution group objects.

For some distribution group objects, it is intuitively possible to deduce their redundancy status without the requirements for extensive analysis or research. For example, temporary or test distribution groups identifiable via the words “temp” or “test” within the name and / or description attribute fields, or distribution groups currently “functionally disabled”. However, for the majority of distribution group objects, it may be difficult to ascertain their redundancy status without extensive analysis and research.

When determining the criteria to permit the intuitive deduction of the potential redundancy status of distribution group objects, based upon one or more metadata aspects of the objects, this design methodology proposes the following example criteria:

The distribution group object is identifiable, via visible metadata aspects only (such as the type of group, name, description, group membership, and so on) as been associated with a function pre-excluded from the scope of migration. For example, it is possible to identify one or more distribution groups generated exclusively to support the distribution of e-mails associated with a project within the organisation. After completion of the project, there was a failure to delete all strictly associated distribution groups.

It is possible to identify one or more distribution groups where all of the member security principals are on the lists “actually redundant” or “potentially redundant” directory objects and hence within the scope of pre-migration directory clean up tasks.

Certain distribution group objects, such as those created as test or temporary distribution groups, are by direct function, excluded from the scope of migration, unless it is possible to identify explicit requirements to retain and hence include them within the migration scope.

When determining the influence that the current status of the identified existing distribution group objects has on their redundancy potential, consider the following:

A distribution group object may be active or “functionally disabled”. A “functionally disabled” distribution group either has:



• No members, or

• No active members (all members of the group are either disabled or categorised as “actually” redundant)

Note that in a legacy Windows 2000 domain, it is possible to impose a functional restriction on the distribution group via the assignment of a GPO employing the “Restricted Groups” feature, to hence restrict the membership of the group to (for example) no members.

Note that the “functionally disabled” or “functionally restricted” status of a distribution group does not necessarily imply that the distribution group is redundant. It is possible for a distribution group to reside in this unique disabled state to support multiple reasons such as:

• The project a distribution group is to support is in a state of suspense

• The departments distribution groups currently support are subject to pending reorganisation and restructuring exercises, and organisation does not know at this stage whether the groups will become redundant.

When determining the criteria for the identification of redundant distribution group objects, consider the following:

It is possible to determine the redundancy of existing distribution group objects via, for example, the following:

The lack of use of the distribution group object based upon the last time there was a requirement to use a distribution group to distribute e-mails to the members of the group.

The association of the distribution group object with a function outside of the migration scope for the legacy domain.

The presence of one or more active or inactive duplicates of active distribution group objects, and hence the opportunity for distribution group consolidation.

To determine whether a distribution group object is redundant due to lack of use is rather difficult to ascertain in legacy Windows 2000 domain infrastructures. Unlike the “lastLogon” attribute for Windows 2000 user account objects, there are no such attributes for Windows 2000 distribution group objects.

When determining the presence and design requirements for the management of potentially redundant distribution group objects, based upon duplicate instances of the groups, consider the following:

It is important to identify and manage duplicate instances of distribution groups within an organisation as this may hence:

Reduce the overall workload associated with the migration scope

Increase efficiency in distribution group management

This design methodology proposes the following approach towards the identification and management of duplicate distribution group objects:

Determine the presence and details of duplicate distribution groups within a legacy Windows 2000 domain via the definition of criteria for their identification



Following the identification of multiple “duplicate” instances of a distribution group (based upon their members), it is necessary to execute the following steps to develop an action plan:

• Select, from the two or more duplicate distribution groups a single “primary” distribution group, to which there are one or more duplicate “secondary” distribution groups. This hence requires the definition of criteria for the selection of the “primary” distribution group.

• For each collection of duplicate distribution groups, it is necessary to define criteria for the selection of one of the following two options as action plans to deal with duplicate instances of distribution groups:

♦ Option 1 is to delete all identified duplicate “secondary” groups, and retain the identified “primary” distribution group

♦ Option 2 is to consolidate all identified duplicate “secondary” groups within the identified “primary” distribution group, and then delete the identified duplicate “secondary” groups

• Following the selection of the appropriate action plan for each collection of duplicate distribution groups, it is necessary to determine the design requirements for the execution of the required option.

When determining the criteria for the identification of duplicate instances of a distribution group object, consider the following:

It is possible to identify two or more duplicate instances of a distribution group object based upon the duplication of one or more of the following metadata aspects of the objects:

• The membership lists of the distribution group objects

• One or more attributes or other metadata aspects of the distribution group objects, such as the name, description, logical location of the distribution group objects within the legacy domain infrastructure, and so on.

• The logical function of the distribution groups, regardless of the member of the groups

Note that, unlike security groups, it is possible to use only use a matching membership list of a distribution group to identify its status as a duplicate instance of another existing distribution group. However, it is not possible to rely exclusively upon other matching metadata aspects of distribution groups, such as their name, description, logical location, and so on, to identify their status as duplicate instances of another existing distribution group. The criteria for the identification of duplicate instances of active distribution groups must hence reflect this requirement to employ either just the membership list, or combinations of other metadata aspects for distribution groups.

Although the onus is with the organisation to define the criteria for the identification of duplicate instances of distribution groups, this design methodology proposes the following example criteria:

• It is possible to identify two or more existing distribution groups with the following matching metadata aspects:

♦ The membership lists of each distribution group are exactly the same, and

♦ The descriptions of the groups are exactly or very similar



• It is possible to identify two or more existing distribution groups with the following matching metadata aspects:

♦ The functions or roles of two or more distribution groups either match or are closely related, such as the requirement to support a project, application, or service, and

♦ The logical locations of the distribution groups within a legacy domain (such as a custom OU within a legacy Windows 2000 domain) match, and

Note that when determining the criteria for the identification of duplicate instances of active distribution groups, and evaluating potential groups against these criteria, it is necessary to ensure complete compliance with (at a minimum) the group membership criterion. If the other metadata aspects of multiple distribution groups do not match, then it may still be feasible to regard the distribution groups as potential duplicates of each other, based upon matching membership lists alone.

Following the identification of two or more collections of duplicate instances of existing distribution groups, consider the following when determining the criteria for the selection of the “primary” distribution group object within each identified collection of duplicate instances:

It is necessary to identify a single “primary” distribution group object within each collection of duplicate instances. This is because the objective of this step, and the result of either of the only two logical options to manage this scenario, is to eliminate all duplicate instances of distribution groups, during execution of the pre-migration directory clean up tasks. The remaining distribution groups, after completion of the directory clean up tasks, are hence the selected “primary” distribution group objects.

This design methodology proposes the following examples of aspects of distribution groups, as the basis for criteria to support the selection of the “primary” distribution group from a collection of duplicate instances:

• The date and time of creation of the distribution groups within the collection of duplicate instances, where, for example, the earliest created group is a potential candidate for nomination as the “primary” distribution group

• The potential consequences from the deletion of the distribution groups, based upon, for example, the influence of the distribution group on business continuity, and so on (see later for details on the determination of the acceptable and unacceptable consequences from the deletion of distribution groups). A distribution group with unacceptable consequences rated the highest priority is a suitable candidate for selection as the “primary” distribution group.

• The power and influence associated with the owner(s) of the distribution groups, where it is possible to identify two or more owners for the identified collection of duplicate instances. For example, the owner(s) able to exert the greatest influence on the retention of their distribution groups may hence influence the selection of a “primary” distribution group from the collection of duplicate instances.

• The distribution group with the highest usage profile based upon, for example, the most commonly used and known group based upon its name, is a potential candidate for nomination as the “primary” distribution group within a collection of duplicate instances. Note that this criterion relates also to the criterion identifying the priority of unacceptable potential consequences from the deletion of a distribution group object.



• The distribution group with the most in common with all other duplicate instances is a potential candidate for nomination as the “primary” distribution group within a collection of duplicate instances.

When determining the criteria for the selection of option 1 or 2 to manage the duplicate instances of distribution groups, consider the following:

The selection of option 1 results in the deletion of all duplicate instances of a selected “primary” distribution group, without retention or re-use of the memberships, or other metadata aspects of the “secondary” distribution groups. This outright deletion can hence have significant consequences, and thus the criterion to support the selection of this option is required to reflect the significance of these consequences.

Hence, when determining the acceptable and unacceptable consequences of accidental or intentional deletion of any identified existing distribution group objects, or “secondary” duplicate instances of distribution groups, consider the following:

• The intentional or accidental deletion of a distribution group object can have consequences ranging from none to dire. This design methodology proposes that it is safer to consider the consequences for the deletion of any existing distribution group object as potentially dire, unless it is possible to prove otherwise. This is a safer approach, as it forces a considered and methodical approach to distribution group deletion.

• The current and proposed function(s) of the distribution group object dictate the potential consequences that may arise from the intentional or accidental deletion of a distribution group object. These can hence range from, for example:

♦ The absence of any noticeable issues post-deletion of the distribution group objects, to

♦ The failure to receive important communications, via e-mails, by the members of a deleted distribution group and hence, potentially the inability of the members to perform their expected and required duties, to

♦ Generation of a breach in the OLA or SLA for a service or application dependent upon a deleted distribution group, where, for example, the application or service depend upon the use of the distribution group to notify administrators of, for example, a failure in a component of the application or service. This associated breach of the SLA for the associated business process / application may hence generate a significant disruption to business continuity

• Although the onus is with the organisation when determining what they consider to be an “acceptable consequence” (based upon the function(s) of the assignee(s)), this design methodology proposes the following examples of criteria:

♦ The noticeable consequences from the deletion of a distribution group object are of low priority as it is easily and completely possible to reverse the situation without any short, medium, or long-term issues.

♦ The consequences of the deletion of a distribution group object are negligible, as they do not disrupt the continuity of any key business or technical processes.



• Although the onus is with the organisation when determining what they consider to be an “unacceptable consequence” (based upon the function(s) of the assignee(s)), this design methodology proposes the following examples of criteria:

♦ The noticeable consequences from the deletion of a distribution group object are of high priority as it is not easily and completely possible to reverse the situation without any short, medium, or long-term issues.

♦ The consequences of the deletion of a distribution group object are significant, as they disrupt the continuity of one or more key business or technical processes.

Although the onus is with the organisation to define the criteria for the selection of option 1, this design methodology proposes the following examples of selection criteria:

• Select option 1, for the outright deletion of all duplicate “secondary” instances of a “primary” distribution group where it is possible to attain compliance with the following criteria:

♦ The deletion of all identified “secondary” duplicate instances of a “primary” distribution group is associated only with predefined acceptable consequences, and

♦ There is no identified requirement to retain and re-use any of the transferable metadata aspects associated with the “secondary” groups on the selected “primary” distribution group.

♦ Every identified duplicate “secondary” group is an exact match, in all relevant metadata aspects of the groups, to the selected “primary” distribution group, and hence consolidation of the groups is not required.

• Select option 1 where it is possible to attain compliance with the following criteria:

♦ The identified “secondary” duplicate distribution groups are independently identified as potentially redundant from earlier analysis and based upon their metadata aspects, and / or

♦ The consolidation of the function(s) of the identified “secondary” distribution groups (represented as the consolidation of the membership list on all “secondary” groups to the selected “primary” group) would violate the required function(s) of the selected “primary” group. For example, it could result in the loss or generation of unwanted distribution topologies for e-mails to the members of the “primary” distribution group.

♦ The consolidation of one or more aspects of the identified “secondary” distribution groups with the “primary” distribution group would result in the unacceptable loss of control over management of distribution group membership by the owner(s) of the “duplicate” distribution groups. In this scenario, the owner(s) of the “secondary” distribution groups may opt to delete their groups, and generate new unique groups, rather than relinquish control over group membership, group application, and so on, to the owner(s) of a primary distribution group.

The selection of option 2, to consolidate one or more metadata aspects of identified “secondary” groups with the selected “primary” group, prior to deletion of the “secondary” groups, requires careful consideration. The consolidation of distribution groups is fraught with potentially unacceptable consequences that



require identification and consideration prior to selection of this option, and hence require reflection in the selection criteria for option 2.

When determining the criteria for the selection of option 2, to consolidate and then delete “secondary” duplicate groups, consider the following:

• The basis for the identification of the duplicity of two or more distribution groups is essential to the definition of the selection criteria for option 2 and to the determination of the design requirements for execution of option 2.

• The consolidation of one or more “secondary” duplicate groups with a “primary” distribution group has the potential to generate the following examples of consequences:

♦ The consolidation of one or more “secondary” distribution groups with a “primary” group may violate the function(s) or role(s) of the “secondary” and “primary” group. For example, it may be logically possible to identify multiple duplicate distribution groups based upon their relationship via a common project, application, and so on, but it is not possible to consolidate these groups without violation or confusion of their discrete functions.

♦ The consolidated “primary” distribution group is under new ownership and hence management. The entry criteria to the distribution group may hence no longer support the addition of members that may have complied with the entry criteria for the pre-consolidation “secondary” groups, and may even require the removal of current members from the group.

♦ A consolidated “primary” distribution group, via new ownership and management, is required to comply with differing retirement policies, and hence may have a shorter lifespan than the pre-consolidation “secondary” groups.

• Although the onus is with the organisation to define the criteria for the selection of option 2, this design methodology proposes the following examples of criteria to support the selection of option 2:

♦ Select option 2, to consolidate one or more “secondary” distribution groups with a selected “primary” distribution group prior to deletion of the “secondary” groups, where it is possible to attain compliance with the following (non-specific) criteria:

It is not possible to identify any unacceptable consequences from the consolidation of one or more “secondary” distribution groups with a selected “primary” group, and

It is possible to identify one or more acceptable consequences from the consolidation

♦ Select option 2 where it is possible to attain compliance with the following (specific) criteria:

It is possible to identify one or more metadata aspects of the “secondary” distribution groups required by the selected “primary” distribution group, and

Failure to consolidate one or more of the metadata aspects of the “secondary” distribution groups with the selected “primary” distribution group may result in the loss of business continuity or other unacceptable consequence, due to the loss of functionality.



• Following the identification of the criteria to select option 2, it is necessary to determine which metadata aspects of the “secondary” distribution groups require consolidation with a selected “primary” distribution group. It is hence necessary to define the criteria for the selection of the consolidation metadata aspect.

• This design methodology supports the consolidation of the following metadata aspects of the “secondary” distribution groups with the selected “primary” distribution group:

♦ The lists of members of each distribution group

♦ The name(s), description, notes for the distribution groups

♦ The logical location(s) of the distribution groups within the legacy domain infrastructure

Following the identification of the required option(s) to handle duplicate instances of distribution groups, the next step is to determine the design requirements for the execution of the required option(s). Consider the following information when determining the design requirements for the execution of option 1 and / or option 2:


• Identification of all “secondary” duplicate instances of a “primary” distribution group

• Deletion of all “secondary” distribution group objects

When determining the design requirements for the first step in this approach to execute option 1, consider the following:

• The design requirements for the execution of this first step depend upon the numbers of “primary” distribution groups, and their respective “secondary” distribution groups, and organisation identifies within a legacy domain. Where an organisation identifies only a few (for example, less than twenty or thirty collections of duplicate groups), then it may be feasible to selectively delete the respective “secondary” distribution groups manually. However, where there are more than a few collections and instances of duplicate distribution groups identified, or even many hundreds or thousands, it is necessary to design and employ an automated process to delete the unwanted duplicate “secondary” distribution groups.

• Consider the use of the following command line tool and commands to extract the lists of domain distribution groups:

♦ Use the “LDIFDE.exe” tool to perform an ldap query against a Windows 2000 domain partition to extract a list of distribution groups. The following is an example of an LDIFDE query to extract a list of all security groups within a specific OU in a Windows 2000 domain:

ldifde -d "OU=DLGroups,OU=Natsum Gardens,OU=Autonomous Divisions,DC=Natsum,DC=com" -r "(objectClass=group)" -f "C:\temp\DLgroups.ldf"

♦ This query will generate, within the “DLgroups.ldf” file a list of all distribution groups within the “DLgroups” OU.

• Following extraction of the list of groups, and where the list may contain security group objects as well, it is necessary to filter out the security group



entries. This is possible using the value for the “groupType” attribute, which has the following values for distribution groups:

♦ All domain local distribution groups have a “groupType” value of 4

♦ All global distribution groups have a “groupType” value of 2

♦ All universal distribution groups have a “groupType” value of 8

When determining the design requirements for the execution of the second step, to delete all “secondary” distribution groups, consider the following:

• Following the extraction of the list of groups, it is necessary to either:

♦ Delete from the list all required (non-redundant) distribution groups, and this retain the “secondary” groups that require deletion, or

♦ Differentiate the “primary” distribution groups from the “secondary” groups via, for example, a description entry or name change, or

♦ Differentiate the “secondary” distribution groups from the “primary” groups via, for example, a description entry or name change.

• Following identification of the required approach from the above options, it is possible to delete the required duplicate “secondary” groups via:

♦ Modification of the ldif format output file to remove all entries to be retained, and modification of the “changeType:” value to “delete” (and not the default of “add”)

♦ Execution of the ldifde.exe command to delete the distribution groups in the Windows 2000 domain using the modified ldif format file as the input. For example, using the command: ldifde -i -f "c:\temp\dlgroups.ldf" –k


• Identification of all “secondary” duplicate instances of a “primary” distribution group

• Selection and design of a method to consolidate the required metadata aspects of each “secondary” distribution group with the selected “primary” distribution group for a collection of duplicate groups

• Deletion of all “secondary” distribution group objects

Employ the same process and approach to execute the first step in this approach for option 2, via the use of the “ldifde.exe” command line tool and commands.

When determining the design requirements for the execution of the second step in option 2 above, to consolidate one or more metadata aspects of the “secondary” distribution groups with the selected “primary” distribution group, consider the following:

• This design methodology supports the use of the Windows 2000 resource kit tool “Group Copy” (grpcpy.exe) to consolidate the memberships of “secondary” distribution groups. Group Copy is a GUI based tool that can copy members from one group to another group in the same domain, or even a different trusting domain.



• As for security group objects, when determining the requirements for the consolidation of the names of “duplicate” secondary groups within a selected “primary” group, consider the following:

♦ The consolidation of multiple names for “secondary” distribution groups to generate a new name for a “primary” distribution group requires observance and compliance with any existing or proposed object-naming model for distribution group objects. For example, within a legacy domain, the current / proposed object-naming model supports the use of a multiple component name for distribution groups, and each component reflects a metadata aspect of the distribution group. Where a component of the name reflects the function of the group, as an abbreviated description, then it may be necessary to consolidate the function(s) of each group (primary and secondary) within the collection of duplicate groups to generate a description for the final function(s) of the “primary” group.

♦ Following the determination of the final name(s) for the “primary” distribution groups, it is possible to automate their renaming to reflect the new metadata aspects of these groups, where appropriate.

Employ the same process and approach to execute the third step in this approach for option 2, via the use of the “changeType: delete” value in the input file for the “ldifde.exe” command line tool.

When determining the criteria for the categorisation of distribution group objects into the “actually redundant” and “potentially redundant” categories, consider the following:

Although the onus is with the organisation to define the criteria for categorisation of the distribution group objects, this design methodology provides the following example criteria:

Categorise a distribution group as “actually redundant” where, for example, it is possible to identify compliance with the following criteria:

• It is possible to intuitively identify that the distribution group is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the distribution group object with the defined criteria for redundancy (such as lack of use, exclusion from the migration scope, or status as a duplicate “secondary” distribution group object to a “primary” distribution group object)

• It is possible to identify compliance of the distribution group object with the criteria for acceptable consequences from the deletion / disabling of the distribution group object

Categorise a distribution group as “potentially redundant” where, for example, it is possible to identify compliance with the following criteria:

• It is possible to intuitively identify that the distribution group is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the distribution group object with the defined criteria for redundancy (such as lack of use, exclusion from the migration scope, or status as a duplicate “secondary” distribution group object to a “primary” distribution group object)



• It is possible to identify compliance of the distribution group object with the criteria for unacceptable consequences from the deletion / disabling of the distribution group object

For all distribution group objects that unequivocally comply with the criteria for categorisation as “actually redundant”, define the following as the pre-migration directory clean up tasks for these distribution group objects:

Addition of the distribution group objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Requirement to functionally disable the distribution group objects

Optionally, move the functionally disabled distribution group objects to a custom OU to differentiate them from active distribution group objects

For all distribution group objects that unequivocally comply with the criteria for categorisation as “potentially redundant”, define the following as the pre-migration directory clean up tasks for these distribution group objects:

Addition of the distribution group objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Modification of the description field to add text that denotes the distribution group objects as “potentially redundant” objects, but with no requirements to functionally disable or move the distribution group objects


Determine and document the types of distribution group objects that reside within the Windows 2000 Active Directory domain partition of the legacy domain

Determine and document the function(s) of the identified distribution group objects, and types of distribution group objects

Determine and document the criteria for the inclusion of distribution group objects from the scope of pre-migration directory clean up tasks based upon their metadata

Determine and document the criteria for the identification of redundant distribution group objects

Determine and document the required approach towards the identification and management of duplicate distribution group objects

Determine and document the criteria for the categorisation of distribution group objects into the “actually redundant” and the “potentially redundant” categories

Evaluate all identified distribution group objects against the defined criteria, define, and document the pre-migration directory clean up tasks appropriate to their subsequent categorisation.

• Factor A6: Determination of design requirements for a directory change control freeze

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the design of a change control freeze on all non-essential directory operations within a legacy domain.




Prior to determination of the design requirements for a change control freeze on all non-essential directory operations, consider the following:

The function of a directory change control infrastructure (see the Active Directory Management Plan for more details) is to track and manage all proposed changes to the directory infrastructure

The function of a freeze on a directory change control infrastructure is to impose significant restrictions on the proposed directory changes that the change control infrastructure will process

As the “pre-migration” tasks require execution twice (first execution now (during analysis phase) and second execution actually during the pre-migration phase), it is necessary to design and impose a freeze on the change control infrastructure for a legacy domain. It is necessary to implement the freeze on change control for a legacy domain for only a fixed duration represented by start and end points:

The start point represented by the completion of all analysis tasks to determine the design requirements for the execution of the actually pre-migration tasks, and

The end point represented by the completion of all designed pre-migration tasks

The objectives for the design and implementation of the freeze on change control are:

To impose restrictions on the directory changes that may occur between the first and second execution of the “pre-migration” tasks. This will hence reduce the workload for the second execution of the “pre-migration” tasks.

To identify those directory change requests that fall within and outside of the scope of the freeze on the current directory change control infrastructure

To identify and manage all change requests targeted for directory objects and data previously categorised as “actually” or “potentially” redundant

The imposition of a freeze on all non-essential directory change requests is a significant undertaking in the majority of organisations, and hence requires careful approach and consideration. The approach proposed by this design methodology, detailed below, hence reflects this requirement.

This design methodology proposes the following approach towards the determination of the requirements for the design, implementation, and execution of a freeze on a change control infrastructure for a legacy domain directory:

Identify and analyse any existing directory change control infrastructure(s) for a legacy domain

Where a legacy domain is not within the scope of any existing change control infrastructure, then determine the design requirements for a temporary change control process, to support the freeze on directory operations

Determine the criteria for the:

Inclusion of proposed directory change requests within the scope of the change control freeze

Exclusion of proposed directory change requests (such as emergency requests) within the scope of the change control freeze

Determine the requirements for the design of a process to initiate the freeze on directory change requests



Determine the requirements for the design of the process to evaluate all new directory change control requests following the initiation of the freeze for scope compliance

Determine the criteria for the termination of an implemented change control freeze on directory operations for a legacy domain

Determine the requirements for the design of the process to terminate the change control freeze

When identifying the presence of one or more existing change control infrastructures, consider the following:

This design methodology proposes the following approach towards the identification of a formal or informal change control infrastructure within an organisation:

Define the criteria for the identification of a formal and an informal change control infrastructure for directory changes to a legacy domain

Execute an analysis to determine all processes currently used by the organisation to design and implement a change to directory objects and data within a legacy domain

Evaluate all identified processes against the defined criteria and categorise the processes as a formal or informal change control infrastructure

Although the onus is with the organisation to define their criteria for the identification of a formal or informal change control infrastructure, this design methodology proposes the following example criteria:

A “formal” directory change control infrastructure is one which has the following characteristics:

• It is possible to identify a structured approach towards the execution of all typical steps in a change control process, such as the reception, evaluation, testing, approval, and implementation of proposed changes to directory objects, data, and directory configuration

• The structured approach is supported by documented details of the scope of the infrastructure, processes, forms (to generate and submit a directory change request), a test laboratory environment that duplicates a production domain infrastructure, a change request board, and so on

• The formal change control infrastructure is rigidly followed for ALL in-scope directory change request proposals, without any exceptions

An “informal” directory change control infrastructure is one which has the following characteristics:

• It is possible to identify a structured approach towards the evaluation and approval of a change request, and possible all or more of the other typical components of a change control infrastructure, such as the reception and testing of proposed changes.

• There is no documentation for the structured approach, or details to support the generation and submission of a directory change request.

• There is no rigid compliance with the informal change control infrastructure for all in-scope change request proposals, and it is possible to identify numerous exceptions.



Note that most organisations typically do not employ any formal or even informal directory change control processes or infrastructures. Within these organisations, there is hence the requirement to design and implement a temporary change control infrastructure to support the freeze on directory operations.

When executing a subsequent analysis of one or more identified formal or informal change control infrastructures, consider the following:

To support the generation of a design for the freeze on an existing change control infrastructure, this design methodology proposes that it is necessary to gather the following pertinent information about the current infrastructure:

The details of the current criteria to define the scope of the relevant change control infrastructure

Details of the current criteria to prioritise received directory change requests as low, medium, and high (or suitable other, such as numeric) priorities

The details of the current criteria for the acceptance and rejection of change requests

When determining the current criteria employed to define the scope of the relevant change control infrastructure, consider the following:

The scope of a change control infrastructure is defined by the following:

• The list of directory objects within and outside of the scope of processing by the change control infrastructure

• The changes to the in-scope directory objects that are inside or outside of the scope of processing by the change control infrastructure

• The list of other changes to the supported legacy domain within the scope of the change control infrastructure

The form(s) provided by the change control infrastructure to support the generation of a change request may define these criteria, to prevent the submission of out-of-scope change requests.

When determining the details of the current criteria to prioritise submitted change requests, consider the following:

Within medium to large organisations that may receive, for example, many tens or more of in-scope directory change requests each working day, essential components of the supporting change control infrastructure are criteria for the prioritisation of change requests. Prioritisation of a change request will influence the order and time of execution of each supported step within the change control infrastructure.

The change control infrastructure must typically support the assignment of a priority to a submitted change request based entirely upon information provided within the change request form.

It is necessary to determine the criteria for the prioritisation of submitted change requests, as a significant aspect of the design of a freeze on an existing change control infrastructure is the redesign / re-definition of these priorities (see later for details).

The scale defined by these criteria may be based upon the following examples of facts provided within the form typically accompanying a change request:



• The target object / configuration / function of the change request

• The potential / predicted impact of the change request on one or more users, departments, divisions, and so on

• The capability of the change, based upon its target and nature, to influence continuity of operations by users, computers, processes, services, and so on within the potential scope of impact of the change

• The predicted time required to evaluate, test, approve / reject, and implement the change

• The predicted impact on continuity from delays in processing and implementation of the proposed change (this factor will probably have the highest influence on the prioritisation of submitted change requests), and so on

The format of the priorities assigned to submitted change requests may vary with each identified change control infrastructure, such as:

• Assignment of a low, medium, or high priority

• Assignment of a numeric priority from 1 to 10, where one is the lowest priority rating, and so on

Each employed category for a priority is typically associated with, for example, an SLA for processing the change request from time of acknowledged receipt. For example:

• The assignment of a “low” priority to a submitted change request will result in the completion of the change request (assuming approval on first submission) within 48 hours

• The assignment of a “medium” priority to a submitted change request will result in the completion of the change request (assuming approval on first submission) within 24 hours

• The assignment of a “high” priority to a submitted change request will result in the completion of the change request (assuming approval on first submission) within 2 hours

When determining details of the current criteria for the acceptance and rejection of change requests, consider the following:

• Change control boards do not automatically approve all submitted change requests. Instead, change control infrastructures require the board to evaluate each request against defined criteria to determine the requirement to approve or deny the request.

• The following are examples of the criteria typically employed to determine the requirement to approve or deny a change request:

♦ Deny the change request where the proposed change fails to comply with the design direction and strategy for the domain infrastructure

♦ Approve the change request where the proposed change demonstrates the potential to realise a disruption in business continuity from a failure to implement the change



Where it is not possible to identify any formal or informal change control infrastructures, to support domain and directory changes, this design methodology recommends the design of a temporary change control infrastructure to support the proposed freeze.

Note that as this design methodology proposes (see later) the design of a permanent and complete change control infrastructure, as a component process within the “Active Directory Management Plan”, there is only a requirement to design a very basic temporary change control infrastructure for a legacy domain / domain infrastructure.

The proposed components for a temporary “mini” change control infrastructure are:

The list of members on the change control board, responsible for the reception, evaluation, and approval or denial of submitted directory change requests.

The criteria to define the scope of the temporary change control infrastructure

The process and infrastructure to support the generation and submission of change requests compliance with the criteria that define the scope of the change control infrastructure

The criteria to perform the initial evaluation of completed and submitted change requests

The process and infrastructure to support the reception and initial evaluation of submitted change requests against the defined criteria

The process and infrastructure to support the testing of change requests

The criteria to support the approval or denial of submitted change requests

The process to evaluate all submitted, evaluated, and tested change requests against the approval criteria, and recording of all completed evaluations and decisions

The process to implement the change requests within the production domain infrastructure

When identifying the members to form the change control board, consider the following:

The members should, ideally, be those personnel within an organisation that represent the IT department, and the department heads for each business division represented and supported by the directory / domain infrastructure.

As directory change requests may influence the continuity of a user, or entire division or department, they require representation within the change control board.

The members of the board ideally should not comprise personnel who will actually submit, test, and implement the majority of change requests. This recommendation reflects the fact that these personnel may not be able to provide an objective evaluation of submitted change requests, as they may have a stake in their approval.

When determining the criteria to define the scope of the temporary change control infrastructure, consider the following:

The objectives of this step, and the criteria to define the scope of the temporary change control infrastructure are to control the following:



• Identification of the directory objects, the aspects of directory objects, and domain configurations that the temporary change control infrastructure will control and support via processes to evaluate, test, and approve.

• Identification of the directory objects, the aspects of the directory objects, and domain configurations that the temporary change control infrastructure will not control and support. It is hence possible to design and implement these changes without involvement and use of the temporary change control infrastructure.

The criteria to define the scope of the temporary change control infrastructure must support the proposed freeze on the temporary change control infrastructure. The criteria is hence required identify all potential change requests for directory objects and data that would generate the following examples of changes to the current identified redundancy status of the directory object:

• Change the current status of a directory object from non-redundant (and hence active object) to become an “actually” or “potentially” redundant object

• Change the current status of a directory object from “actually” redundant to become a “potential” or even non-redundant object

• Change the current status of a directory object from “potentially” redundant to become an “actually” or even non-redundant object

When determining the design requirements for the process and infrastructure to generate and submit the requests, consider the following:

The process and infrastructure to support the generation and submission of directory change requests is required to provide, at a minimum, the following:

• A form to control the content and minimum level of information provided for each submitted change request

• An infrastructure component, such as an intranet web site within an online form or an electronic form and a change control mailbox and so on, to support generation / reception of a change request

The form should provide, for example, the following information:

• An overview of the entire change control process, and the scope of the change control infrastructure

• A request for details of the person / department submitting the change

• A request for the high-level business / technical case and drivers for the proposed change

• The minimum (mandatory) and optional information to be supplied about the proposed change request, such as:

♦ The function, nature, and scope of the change

♦ The predicted impact of the change, identifying the departments / divisions that may be influenced by the change

♦ The proposed tests and test criteria for the submitted change request

♦ The resource requirements to test, evaluate, and implement the proposed change



♦ The proposed date(s) and time(s) for implementation of the change (such as a weekend or Bank Holiday, and so on)

The infrastructure component of the change control infrastructure is required to have the following features:

• It should be accessible by all personnel authorised to generate and submit change requests

• It should be accessible by all members of the change control board or authorised personnel dedicated to the reception of change requests

• It should, ideally, be the single point of reference for status updates on submitted change requests where this component is an intranet web site

When determining the criteria to perform the initial evaluation on submitted change requests, consider the following:

The function of this step is to filter out all out of scope and unacceptable change request submissions.

The criteria should hence support the identification of submitted change requests as been outside of the scope of the change control infrastructure

The criteria for identification of “unacceptable” change request submissions may include, for example, the following:

• The change request is a duplicate of another change request currently been processed

• The change request is a contradiction of another change request currently been processed

When determining the design requirements for the process to execute the initial reception and evaluation of submitted change requests, consider the following:

The process to receive submitted change requests is required to detail the following information:

• The identity / identities of the personnel assigned the task to receive and process submitted change requests

• The process and infrastructure to support the generation of an acknowledgement of receipt of a submitted change request

The process to evaluate the submitted change requests is required to detail the following information:

• The process to evaluate the submitted change requests against the defined initial evaluation criteria

• The process and infrastructure to support the generation of a notification, to the submitter of a change request, that the request fails to comply with the initial evaluation criteria, and:

♦ The requirement to revise and resubmit the change request, or

♦ The requirement to cancel the change request



When determining the design requirements for the process and infrastructure to support the testing of submitted change requests, consider the following:

The infrastructure to support the testing of submitted change requests is required to have the following components and features:

• An exact duplication of the target production environment, to support configuration and, where required, performance testing.

• Infrastructure components to support the reestablishment of the test environment, such as imaging software

• A test laboratory log book to record all changes made to the laboratory environment

The process to support the testing of submitted change requests is required to detail the following information:

• The required steps to prepare the test environment for implementation of the proposed change request. For example, the execution of a backup or imaging of all relevant servers, prior to modification of the test environment to run the tests. This hence supports the reestablishment of the test environment following a failed series of tests.

• The process to evaluate the results of the tests against the predefined test criteria supplied in the change request submission

When determining the criteria for the final approval or denial of a submitted change request, these criteria must reflect, for example, the following:

The criteria must reflect the results of the tests executed within the test laboratory environment

The criteria must reflect the financial and administrative overheads associated with the design and implementation of the proposed change request

The criteria must reflect the impact and risk assessment of the proposed change on the continuity of the users, departments, infrastructure components, and so on within the scope of influence of the proposed change.

When determining the design requirements for the process to execute the final evaluation and hence approval or denial of a submitted change request, consider the following information:

The process is required to support the generation of a definite approval or denial

The process must generate justifications for the final decision to approve or deny the submitted change request

When determining the design requirements for the process to implement the proposed change request, consider the following:

The process must respect and acknowledge all identified potential risks to the continuity of the users, departments, and divisions influenced by the change

The process must have a schedule for implementation that does not conflict with other parallel implementation processes to the production environment

Following the identification of an existing formal / informal change control infrastructure, or the determination of the design requirements for a temporary change control



infrastructure, it is necessary to determine the design requirements for the freeze on directory change requests.

When determining the criteria for the inclusion and exclusion all new submitted directory change requests within the scope of the change control freeze, consider the following:

The criteria to define the scope of the freeze on the change control infrastructure must reflect the following requirements:

The requirement to reduce or prevent the implementation of directory changes that may significantly alter the determined scope of the pre-migration directory clean up tasks

The requirement to permit the differentiation between non-urgent and urgent directory change requests, using criteria such as:

• Non-urgent directory change requests are those that may be implemented post-migration, and the delay does not generate any unacceptable consequences

• Urgent directory change requests are those that require implementation prior to the execution of pre-migration tasks, and any delays in implementation will generated unacceptable consequences

There is hence a requirement to define criteria for categorisation of all new change requests as “non-urgent” and “urgent”.

There is a requirement to maintain a balance between business continuity and preservation of directory status quo, with respect to the scope of the pre-migration directory clean up tasks.

When determining the design requirements for the process to initiate the freeze on directory change requests, consider the following:

The process to initiate the freeze must be gradual, and not sudden. There must be adequate time for personnel authorised to submit directory change requests to evaluate all pending submissions, and it may be necessary to issue a communication to all affected departments and divisions.

The process must communicate to all affected users, departments, and divisions the following information:

• The scope of the freeze on directory change requests

• The details of the modifications (where appropriate) to the current change control process and infrastructure

• The start date and proposed end date for the freeze on directory change requests

• A frequently asked questions (FAQ) sheet about the function and purpose of the freeze on directory change requests

The process must evaluate, respect and either permit, freeze, or forbid the completion of currently processed change requests, and include the generation of adequate communications to the personnel that submitted the requests.

The process must detail the schedule and sequence for implementation of the freeze, to identify, for example, what change requests are frozen, and in which order, and so on.



When determining the design requirements for the modifications to the current change control infrastructure to support the freeze, consider the following:

It is possible to identify the requirement to modify the following components of an existing formal / informal change control infrastructure:

• The scope of the change control infrastructure (see above)

• The process and infrastructure to support the generation and submission of new directory change requests, such as:

♦ Changes to the form(s) to reflect the new scope, process, and possible SLAs for completion of evaluations for in-scope change requests

♦ Changes to the infrastructure components of the change control infrastructure, such as the web pages or mailboxes, and so on.

• The criteria and process to perform the initial evaluation of new submitted change requests, such as:

♦ Generation of a sub-process to queue all submitted change requests that, prior to implementation of the freeze, complied with the initial evaluation criteria. These submitted change requests hence require processing post-termination of the freeze.

♦ Generation of a process to notify submitters of change requests of the freeze on their submissions.

It is important to ensure that all modifications to the current change control infrastructure to support the freeze must not radically alter the function and vision of the change control infrastructure.

When determining the design requirements for the process to terminate the freeze on an existing change control infrastructure, consider the following:

The process to terminate the freeze must identify all pending and frozen directory change requests, and assign them a priority for execution

The process must consider the impact on the test and production environments from the processing of a large number of queued change requests.


Define and document the criteria for identification of a formal and informal directory change control infrastructure

Analyse all current processes to design and implement changes to the legacy domain infrastructure and evaluate processes against defined criteria

Determine and document the presence of one or more change control infrastructure that support and control directory change requests for a legacy in-scope domain

Analyse each identified change control infrastructure to determine and document the following information:

The details of the current criteria to define the scope of the relevant change control infrastructure

Details of the current criteria to prioritise received directory change requests as low, medium, and high (or suitable other, such as numeric) priorities



The details of the current criteria for the acceptance and rejection of change requests

Determine and document the requirements for the design of a temporary change control infrastructure, where required, to support the proposed freeze

Determine and document the requirements for the design of the process to initiate the freeze on directory change requests

Determine and document the requirements for the design of modifications to processes and infrastructure components of an existing change control infrastructure to support the proposed freeze

Determine and document the requirements for the design of the process to conduct and terminate the freeze on directory change requests

5.9.1.2.3. Determination of the Specific Pre-Migration Tasks to Prepare a Source Domain

Consider the following when determining the design requirements for the pre-migration tasks, for specific simple and optional migration paths, to prepare one or more source legacy (Windows NT 4.0 or Windows 2000) and new (Windows Server 2003) domains for migration:

• Factor B6: Understanding the pre-migration tasks, to prepare a source domain, specific to migration paths

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the pre-migration tasks necessary to prepare one or more source domains for execution of specific simple and optional migration paths.


Due to the presence of fundamental differences between the simple and optional migration paths, each path will have slightly different pre-migration tasks to prepare a source domain, additional to the common pre-migration tasks defined earlier.

For example, performing an in-place upgrade on a legacy Windows 2000 domain (simple migration path “B”) will retain significantly more directory data than execution of simple migration path “D”.

Hence, simple migration path “B” is associated with more comprehensive pre-migration directory clean up tasks than simple migration path “D”.

The objective of this step is to determine the design requirements for the pre-migration tasks necessary to prepare one or more source Windows NT 4.0, Windows 2000, and Windows Server 2003 domains for migration using one or more of any of the supported simple and optional migration paths.

This design methodology hence proposes execution of the following approach to support this objective:

Determination of the design requirements for the pre-migration tasks to execute directory clean up tasks, specific to each simple and optional migration path, to prepare a source legacy domain for migration

Determination of the design requirements for pre-migration tasks to prepare one or more legacy Windows NT 4.0 domains for execution of an in-place upgrade using simple migration path “A”



Determination of the design requirements for pre-migration tasks to prepare one or more legacy Windows 2000 domains for execution of an in-place upgrade using simple migration path “B”

Determination of the requirements for the use of SIDHistory for the inter-forest migration paths (“C”, “D”, “F”, and “H”), or an alternative

Determination of the requirements for the preservation of closed “user” and “resource” sets using the optional intra-forest migration paths “E” and / or “G”

Determination of the design requirements for pre-migration tasks to prepare one or more legacy source legacy Windows NT 4.0 domain for a domain migration using simple migration path “C”

Determination of the design requirements for pre-migration tasks to prepare one or more legacy source legacy Windows 2000 domain for domain migration using:

Simple migration path “D”, or

Optional migration path “G” (for a Windows 2000 intra-forest domain consolidation migration), or

Optional migration path “H” (for a Windows 2000 inter-forest domain consolidation migration)

Determination of the design requirements for pre-migration tasks to prepare one or more legacy source Windows Server 2003 domain for domain migration using:

Optional migration path “E” (for a Windows Server 2003 intra-forest domain consolidation migration), and / or

Optional migration path “F” (for a Windows Server 2003 inter-forest domain consolidation migration)

• Factor B7: Understanding the scope of directory clean up tasks

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the scope of directory clean up tasks, represented by directory objects and directory data, specific to each simple and optional migration path.


This design methodology proposes that the directory objects, listed in the following table and found within most Windows 2000 domains, potentially require inclusion within the scope of the pre-migration directory clean up tasks for the migration path “B” (in-place upgrade of a legacy Windows 2000 domain):

Potentially Redundant Directory ObjectsFound in Windows NT 4.0

Found in Windows 2000

Print queue objects

Shared folder objects

Contact objects

Organizational Unit (OU) objects

ForeignSecurityPrincipal objects (in the “CN=ForeignSecurityPrincipals,DC=<domain_name>” container)



Potentially Redundant Directory ObjectsFound in Windows NT 4.0


Custom System objects (objects within the “CN=system,DC=<domain_name>” container)

Custom Site objects (objects within the “CN=Sites,CN=Configuration,DC=<domain_name>” container) such as Active Directory Sites, Site Link objects, Site Link Bridge objects, custom connection objects, TCP/IP subnets, and so on.

Custom extensions to the Active Directory Schema (new object classes / attributes, and so on)

Distributed Link Tracking (DLT) objects

Table 44.2: Directory Objects within the Scope of Directory Clean up Tasks for Migration Path “B”

Note that the above objects are within the scope of the directory clean up tasks for migration path “B” because these objects are retained within a legacy Windows 2000 domain, following the in-place upgrade of a Windows 2000 domain controller or the introduction of a new Windows Server 2003 domain controller.

Note that these directory objects are outside of the scope for the following other migration paths:

Migration path “C” (migration of objects from legacy Windows NT 4.0 domain to a Windows Server 2003 domain) because these objects are not found in a Windows NT 4.0 domain and cannot be migrated from one domain to another

Migration path “D” (migration of objects from legacy Windows 2000 domain to a Windows Server 2003 domain) because these objects cannot be migrated from a Windows 2000 domain to a Windows Server 2003 domain

Note that there are omissions of directory objects from table 44.2, as this design methodology considers the following directory objects as been outside of the scope of pre-migration directory clean up tasks for migration path “B”:

Custom Windows 2000 GPOs are outside of the scope of pre-migration directory clean up tasks for migration path “B”. Although execution of this migration path does retain these objects, they require clean up (as a functional replacement with the design for the new Windows Server 2003 GPO infrastructure) during the post-migration phase. The step “determination of the design requirements for post-migration tasks” discusses the clean up and replacement of Windows 2000 custom GPOs.

Custom objects within the Configuration partition (in the “CN=Configuration,DC=<domain_name>” container). The step “determination of the design requirements for post-migration tasks” discusses the clean up and replacement of custom objects within the Configuration partition.

This design methodology proposes that the following directory data, listed in the following table and typically found within Windows NT 4.0 and / or Windows 2000 domains, potentially require inclusion within the scope of the pre-migration directory clean up tasks for migration paths “A” and “B” (in-place upgrades of legacy domains):



Potentially Redundant Directory DataFound in Windows NT 4.0


Windows NT 4.0 system policies

Security Audit policies 2

Security principal rights assignments 2

User account password & account lockout policies 3

External trust relationships

Application data from Active Directory aware applications (for example, Active Directory integrated DNS zone data)

Table 44.3: Directory Data within the Scope of Directory Clean Up Tasks for Migration Paths “A” and “B”

2It is necessary, in Windows 2000 Active Directory domains, to apply security audit policies and assign rights to security principals using a GPO. These policies hence technically exist as GPOs, and hence directory objects.

3It is necessary, in Windows 2000 Active Directory domains, to apply user account password and account lockout policies using a GPO implemented at the root of a domain. These policies hence technically exist as GPOs, and hence directory objects.

Note that the clean up of the above directory “data” is outside of the scope of the directory clean up tasks for the simple migration paths “C”, “D”, “E”, and “F” (migration of objects from legacy domain / interim Windows Server 2003 domain to final Windows Server 2003 domain). This is because these migration paths cannot execute a migration of this “data” from one domain to another, and hence there is no requirement to remove redundant instances of these data types.

Note that there may be a “functional” clone / translation of some directory data (such as Windows NT 4.0 system policies functionally translated to Windows Server 2003 Active Directory GPO policies), but there is no direct reuse or migration of any existing directory data.

• Factor A7: Determination of the directory data that requires inclusion within the scope of pre-migration directory clean up tasks for migration path “A”


Has identified the requirement for the migration of one or more legacy Windows NT 4.0 domains using simple migration path “A”, and

Wishes to determine the directory data that requires inclusion within the scope of pre-migration directory clean up tasks for migration path “A”.


Prior to the execution of an in-place upgrade, using migration path “A”, it may be necessary to remove:

Redundant directory data, or

Directory data that may conflict with the design for the upgraded Windows Server 2003 domain and Active Directory infrastructure



Although a Windows NT 4.0 domain infrastructure only holds a small number of types of directory data, this design methodology will only focus on the directory clean up of the following types of directory data:


Audit policy data and assignments of rights to security principals

User account lockout and password policy data

An in-place upgrade of a Windows NT 4.0 domain to become a Windows Server 2003 domain preserves all of the above types of directory data. The upgrade ports the audit policies, user rights assignments, user account lockout, and user password policies to the following GPOs respectively:

The Default Domain Controllers Policy (auditing policies and user rights assignments)

The Default Domain Policy (password and account lockout policies)

Use the same approach outlined above, for the clean up of external trust relationships for migration path “B”, to identify and document redundant external trust relationships in each in-scope legacy Windows NT 4.0 domain associated with migration path “A”.

As the upgrade preserves all existing Windows NT 4.0 policy and rights data after the upgrade, it is easily possible to rectify any redundant data or data that conflicts with the design requirements for the target Windows Server 2003 domain after the upgrade.

However, where there is a requirement to clean up this data, identify and document the specific new requirements for these data, and execute as pre-migration directory clean up tasks.

• Factor A8: Determination of the print queue objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”


Has identified the requirement for the migration of one or more legacy Windows 2000 domains using the simple migration path “B”

Has identified the presence of more than a few hundred print queue objects published within the domain partition of one or more legacy in-scope Windows 2000 domains, and

Wishes to determine the print queue objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”


Prior to determination of the inclusion and exclusion criteria for print queue objects from the scope of pre-migration directory clean up tasks for migration path “B”, consider the following:

The identification of print queue objects that fall within the scope of pre-migration directory clean up tasks is a significantly simpler process than for user, computer, or group objects. This is because:

There are typically fewer print queue objects within an Active Directory domain than user, computer, or group objects.



Not all organisations actively design, populate, and support the use of print queue objects to facilitate their location and use by end users. However, most Windows 2000 domains support print queues by default and not by design. This is due to the default and automatic publication of print queue objects within an Active Directory partition, for all shared print queues on a Windows 2000 or later member print server. However, by default, the Active Directory represents these print queue objects as leaf objects of the computer account for the member Windows 2000 or later print server and hence, to see these objects it is necessary to configure the MMC snap in (Active Directory Users and Computers) to view objects as containers. Thus, unless there is a specific requirement, for example, to collate all published print queue objects into a custom OU, some organisations are actually unaware of the existence of these objects within the domain.

The threshold stated for the number of print queue objects within the criteria for the application of this factor reflects the fact that the execution of this process is only useful in organisations with a significant population of published print queue objects.

The number of print devices within an organisation does not reflect the number of existing print queue objects, and the number of these objects published to the Active Directory. A print device can support many different print queue objects, each differing in one aspect or another, such as the drivers to support the operating system of the clients, the print preferences and parameters, the entries within the access control list, and so on.

Within Windows 2000 domains where an organisation designs and encourages the use of print queue objects, the execution of this process can have a significant impact on the productivity of end users reliant upon the presence of these objects to support:

The location of a suitable print queue for a print device that supports specific requirements, such as features (double-sided, colour, stapling, and so on) and location of the print device, and so on

Connection to the print device on the print server, via download of the required print queue to the client computer

The identification of print queue objects that require inclusion within the scope of pre-migration directory clean up tasks is focussed around the following metadata aspects of these objects:

The owner(s) of the print queue objects

The metadata for the target print device for a print queue object

The current and proposed clients supported by each print queue object

The logical location(s) of the print queue objects within the Windows 2000 domain partition

The identifiable and intuitive redundancy of the print queue objects

The identifiable and indirect redundancy of the print queue objects due, for example, to the direct redundancy of one or more metadata aspects of the object.

The objectives of this process are to:

Identify the print queue objects potentially within the scope of directory clean up tasks, and then



Assign the identified print queue objects to one or the following categories:

• “Actually redundant” print queue objects. These are objects, identified by the approach below as currently redundant, and that serve no current or future function. The deletion or removal of these objects will not generate any unacceptable consequences.

• “Potentially redundant” print queue objects. These are objects, identified by the approach below, as potentially redundant, as they serve a current function in the legacy domain, but not in the target Windows Server 2003 domain. The deletion or removal of these objects will generate unacceptable consequences.

All “actually redundant” and “potentially redundant” print queue objects are within the scope of the pre-migration directory clean up tasks. However, the differentiators between these two categories are:


When, within this project, it is possible to remove the print queue objects from the domain, prior to their deletion during execution of the pre-migration tasks.

This design methodology proposes the following approach towards the identification of the inclusion and exclusion criteria for existing print queue objects from the scope of directory clean up tasks:

Identify all existing print queue objects currently published within the Windows 2000 Active Directory domain partition of a legacy domain

Identify all print queue objects within this list that can be potentially included within the scope of directory clean up tasks, based upon:

• One or more metadata aspects of the print queue objects that intuitively places the objects outside of the migration scope for the domain, and hence within the scope

• The current status of the print queue objects

• Compliance with redundancy criteria for print queue objects

Define the criteria for the categorisation of all identified print queue objects (which are potentially within the scope of directory clean up tasks) into the two categories:



Evaluate the results of the above analysis against the defined criteria for categorisation of the print queue objects and assign the appropriate category to the print queue objects.

When determining the types of identified print queue objects that reside within a Windows 2000 Active Directory domain partition, consider the following:

This design methodology identifies the following two categories for “types” of print queue objects, as a reflection of the operating system of the supporting Windows print server:

“Windows NT 4.0” print queue objects (print queues supported by a Windows NT 4.0 print server, and manually published to the Active Directory)



“Windows 2000 and Windows Server 2003” print queue objects (print queues supported by a Windows 2000 or Windows Server 2003 print server, and either automatically (for member print servers) or manually published to the Active Directory)

The basis for the categorisation of print queue objects, to reflect the operating system of the print server that supports the print queues, is:

Print queue objects from a Windows NT 4.0 print server, manually created and published in the Active Directory, have a greater probability of redundancy than those supported on a Windows 2000 or Windows Server 2003 print server.

The print devices attached to legacy Windows NT 4.0 print servers are associated with a greater probability of redundancy (as they may be older models of print devices), and hence the redundancy of their associated print queues.

Using the above information, conduct an analysis against a Windows 2000 Active Directory domain partition of a legacy domain, and identify all instances of each of the above two “types” of print queue objects.

All print queue objects published to the Active Directory domain partition of a legacy Windows 2000 domain have a single shared function, which is to support the location of a print queue on a print server.

Although this function is associated with several metadata aspects of the objects, such as the location of the print device referred to by a print queue object, this function alone cannot influence the redundancy status of a print queue object. Hence, there is no requirement to determine and document the function of each identified print queue object.

When determining the criteria for the exclusion of print queue objects from the scope of migration, based upon their metadata, consider the following:

It is possible to exclude print queue objects from the scope of migration based upon their metadata, such as the type of print queue objects, the logical location (within the legacy domain infrastructure) of the print queue objects, the physical metadata aspects of the print devices the print queue objects target, and so on.

For some print queue objects, it is intuitively possible to deduce their redundancy status without the requirements for extensive analysis or research. For example, temporary or test print queues identifiable via the words “temp” or “test” within the name and / or description attribute fields. However, for the majority of print queue objects, it may be difficult to ascertain their redundancy status without extensive analysis and research.

When identifying redundant print queue objects, consider the following:

A print queue object, published in the Active Directory, is a representation of an existing print queue on a print server. Hence, if it is possible to determine that a print queue is redundant, then the print queue object that targets the print queue is also redundant. The redundancy status of a print queue on a print server is hence influenced by the following:

A feature and / or metadata aspect of the print queue itself

A metadata aspect of the print device targeted by a print queue

The presence of duplicate instances of a print queue, for the same print device, on a print server



The following diagram illustrates this relationship between print queue objects and all other associated components, such as the actual print queues, print servers, print devices, Active Directory, and print clients:

Client

PrintServer

PrintDevice

Natsum.com.

Documentto print


Print Queue

Print QueuePrint Queue Object

Figure 44.6: Illustration of Relationships between Print Devices and Print Queue Objects in Active Directory

When identifying redundant print queues based upon their features and metadata aspects, consider the following:

This design methodology proposes the following approach, to determine the criteria to permit the intuitive redundancy status of a print queue (and hence the associated print queue object), based upon a feature or metadata aspect of the print queue itself:

• Select a print device with one or more print queues published to the Active Directory as print queue objects

• For each print queue associated with a print device, conduct an analysis to identify the unique feature(s) or metadata aspects of a print queue that distinguish it from the other print queues for that device

• Determine the criteria to identify the redundancy status of a print queue based upon its feature(s) and metadata aspect(s)

• Evaluate all unique features and metadata aspects against the defined criteria and identify the print queues that comply with the criteria for redundancy

As stated earlier, a print device may support multiple print queues, and hence each queue must have one or more unique features associated with it, to distinguish it from the other queues for a print device. The following are examples of the features of a print queue that may permit distinction from other print queues:

• The name of the print queue, and any comments associated with the queue, such as the owner, target print device, supported department, and so on

• The default printing preferences associated with the print queue

• The share name of the print queue

• The drivers supplied by the print queue, and hence the supported client operating systems

• The port used by the print queue on the print server, and port configuration

• The membership of the print queue to a printer pool



• The availability of the print device, as dictated by the print queue

• The priority rating for printing of documents submitted to this print queue against documents submitted to other print queues for the same print device

• The spool configuration details; use of print processors, and separator pages

• The access control list for the print queue, to control the use of the queue and hence the target print device

• The advanced print device settings supported by the print queue

When determining the criteria for identification of redundant print queues, based upon their features and metadata, this design methodology proposes the following example criteria:

• The print queue object is identifiable, via visible metadata aspects only as been associated with a function pre-excluded from the scope of migration. For example, it is possible to identify one or more print queues generated exclusively to support:

♦ A project team for a project within the organisation, and after completion of the project, there was a failure to delete all strictly associated print queues.

♦ One or more directory-enabled applications configured to generate large reports each night. However, it is now possible to identify that the application is no longer required and is hence outside of the scope of migration, and will not require the print queue after completion of the migration project.

• It is possible to identify one or more print queues where all of the security principals on the access control list are “actually redundant” or “potentially redundant” directory objects and hence within the scope of pre-migration directory clean up tasks.

• Certain print queue objects, such as those created as test or temporary print queues, are by direct function, excluded from the scope of migration, unless it is possible to identify explicit requirements to retain and hence include them within the migration scope.

• The new target Windows Server 2003 domain infrastructure is associated with a design for a new print management infrastructure, which excludes the use of published print queue objects. For example, the organisation wishes to use the Internet Printing Protocol (IPP) and an intranet website to support the new print infrastructure. This hence makes all currently published print queue objects redundant and hence included within the scope of directory clean up tasks for migration path “B”.

When identifying redundant print queues based upon the features and metadata aspects of the target print device, consider the following:

If it is possible to identify the redundancy of the print device a print queue targets, then accordingly all associated print queues and print queue objects are hence redundant. This design methodology proposes the following approach to determine the redundancy of a print device:

• Define the criteria for the redundancy of a print device

• Select a print device and evaluate it against the defined criteria



When defining the criteria to determine the redundancy of a print device, consider the following:

• It is possible to classify a print device as redundant where, for example:

♦ The manufacturer no longer provides support for the print device, and

♦ The manufacturer hence no longer develops drivers for newer operating systems, and

♦ There is a requirement to design and deploy a new version of an operating system to all current and new client computers of the print infrastructure, and there are no print drivers available for the new operating system.

• It is also possible to identify one or more print devices as redundant where, for example, it is possible to identify compliance with the following:

♦ The department that owns the print devices is subject to a restructuring exercise prior to migration, and will hence merge with another department or with division within the organisation, or gain autonomous status as a spin-off of the parent organisation.

♦ The entire current print infrastructure is subject to a complete hardware and software refresh that will replace a number of existing old print devices, print servers, and so on.

It is possible to determine the redundancy of existing print queue objects via, for example, the presence of one or more active or inactive duplicates of active print queue objects, and hence the opportunity for print queue consolidation. Emulate the same process illustrated earlier to identify and manage duplicate distribution group objects, to identify and manage duplicate instances of print queue objects.

When determining the criteria for the categorisation of print queue objects into the “actually redundant” and “potentially redundant” categories, consider the following:

Although the onus is with the organisation to define the criteria for categorisation of the print queue objects, this design methodology provides the following example criteria:

Categorise a print queue as “actually redundant” where, for example, it is possible to identify compliance with the following criteria:

• It is possible to intuitively identify that the print queue is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the print queue object with the defined criteria for redundancy (such as exclusion from the migration scope, or status as a duplicate “secondary” print queue object to a “primary” print queue object)

• It is possible to identify compliance of the print queue object with the criteria for acceptable consequences from the deletion / disabling of the print queue object

Categorise a print queue as “potentially redundant” where, for example, it is possible to identify compliance with the following criteria:



• It is possible to intuitively identify that the print queue is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the print queue object with the defined criteria for redundancy (such as lack of use, exclusion from the migration scope, or status as a duplicate “secondary” print queue object to a “primary” print queue object)

• It is possible to identify compliance of the print queue object with the criteria for unacceptable consequences from the deletion / disabling of the print queue object

For all print queue objects that unequivocally comply with the criteria for categorisation as “actually redundant”, define the following as the pre-migration directory clean up tasks for these print queue objects:

Addition of the print queue objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Requirement to “functionally disable” the print queue objects by removing them from the Active Directory (which does not delete the actual print queues, but just their avatar objects)

Optionally, move the actually redundant print queue objects to a custom OU to differentiate them from other active print queue objects

For all print queue objects that unequivocally comply with the criteria for categorisation as “potentially redundant”, define the following as the pre-migration directory clean up tasks for these print queue objects:

Addition of the print queue objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Modification of the description field to add text that denotes the print queue objects as “potentially redundant” objects, but with no requirements to functionally disable or move the print queue objects


Identify and document all print queue objects published to the Windows 2000 Active Directory domain partition

Determine and document the types of print queue objects that reside within the Windows 2000 Active Directory domain partition of the legacy domain

Determine and document the criteria for the inclusion of print queue objects from the scope of pre-migration directory clean up tasks based upon their metadata

Determine and document the criteria for the identification of redundant print queue objects

Determine and document the required approach towards the identification and management of duplicate print queue objects

Determine and document the criteria for the categorisation of print queue objects into the “actually redundant” and the “potentially redundant” categories

Evaluate all identified print queue objects against the defined criteria and define the pre-migration directory clean up tasks appropriate to their subsequent categorisation.



• Factor A9: Determination of the shared folder objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”


Has identified the requirement for the migration of one or more legacy Windows 2000 domains using the simple migration path “B”

Has identified the presence of more than a few hundred shared folder objects within the domain partition of one or more legacy in-scope Windows 2000 domains, and

Wishes to determine the shared folder objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”


Prior to determination of the inclusion and exclusion criteria for shared folder objects from the scope of pre-migration directory clean up tasks for migration path “B”, consider the following:

The identification of shared folder objects that fall within the scope of pre-migration directory clean up tasks is a significantly simpler process than for user, computer, or group objects. This is because:

There are typically fewer shared folder objects within an Active Directory domain than user, computer, or group objects.

Not all organisations actively design, populate, and support the use of shared folder objects to facilitate their location and use by end users. Note that unlike print queue objects that represent print queues on Windows 2000 or later member servers, there is no automatic publication of shared folders to the Active Directory. This is regardless of the operating system or domain membership of the server that hosts the shared folders.

The threshold stated for the number of shared folder objects within the criteria for the application of this factor reflects the fact that the execution of this process is only useful in organisations with a significant population of published shared folder objects.

Shared folder objects, unlike other Active Directory objects, are the most likely objects to gain a redundancy status. For example, in Windows 2000 domains, where users are delegated the permission to create, manage, and delete shared folder objects, it is typically possible to identify a large percentage of these shared folder objects as redundant objects.

The number of shares within an organisation does not reflect the number of existing shared folder objects, and the number of these objects published to the Active Directory. A shared folder can support a number of many different shared folder objects, each differing in one aspect or another, such as the name, keywords associated with the target share, description of the object, the owner (managed by) of the shared folder object, the entries within the access control list, and so on.

Within Windows 2000 domains where an organisation designs and encourages the use of published shared folder objects, the execution of this process can have a significant impact on the productivity of end users reliant upon the presence of these objects to support:

The location of a suitable shared folder based upon a query using keywords



Connection to the file share on the file server, via the shared folder object

The identification of shared folder objects that require inclusion within the scope of pre-migration directory clean up tasks is focussed around the following metadata aspects of these objects:

The owner(s) of the shared folder objects

The metadata for the target file share for a shared folder object

The logical location(s) of the shared folder objects within the Windows 2000 domain partition

The identifiable and intuitive redundancy of the shared folder objects

The identifiable and indirect redundancy of the shared folder objects due, for example, to the direct redundancy of one or more metadata aspects of the object.


Identify the shared folder objects potentially within the scope of directory clean up tasks, and then

Assign the identified shared folder objects to one or the following categories:

• “Actually redundant” shared folder objects. These are objects, identified by the approach below as currently redundant, and that serve no current or future function. The deletion or removal of these objects will not generate any unacceptable consequences.

• “Potentially redundant” shared folder objects. These are objects, identified by the approach below, as potentially redundant, as they serve a current function in the legacy domain, but not in the target Windows Server 2003 domain. The deletion or removal of these objects will generate unacceptable consequences.

All “actually redundant” and “potentially redundant” shared folder objects are within the scope of the pre-migration directory clean up tasks. However, the differentiators between these two categories are:


When, within this project, it is possible to remove the shared folder objects from the domain, prior to their deletion during execution of the pre-migration tasks.

This design methodology proposes the following approach towards the identification of the inclusion and exclusion criteria for existing shared folder objects from the scope of directory clean up tasks:

Identify all existing shared folder objects currently published within the Windows 2000 Active Directory domain partition of a legacy domain

Identify all shared folder objects within this list that can be potentially included within the scope of directory clean up tasks, based upon:

One or more metadata aspects of the shared folder objects that intuitively places the objects outside of the migration scope for the domain, and hence within the scope



Compliance with redundancy criteria for shared folder objects

Define the criteria for the categorisation of all identified shared folder objects (which are potentially within the scope of directory clean up tasks) into the two categories:



Evaluate the results of the above analysis against the defined criteria for categorisation of the shared folder objects and assign the appropriate category to the shared folder objects.

As for print queue objects, all shared folder objects published to the Active Directory domain partition of a legacy Windows 2000 domain have a single function, which is to support the location of a shared folder on a file server. Hence, there is no requirement to determine and document the function of each identified shared folder object.

When determining the criteria for the exclusion of shared folder objects from the scope of migration, based upon their metadata, consider the following:

It is possible to exclude shared folder objects from the scope of migration based upon their metadata, such as the logical location (within the legacy domain infrastructure) of the shared folder objects, the owner(s) of the objects, the logical metadata aspects of the file shares the shared folder objects target, and so on.

For some shared folder objects, it is intuitively possible to deduce their redundancy status without the requirements for extensive analysis or research. For example, temporary or test shared folders identifiable via the words “temp” or “test” within the name and / or description attribute fields. However, for the majority of shared folder objects, it may be difficult to ascertain their redundancy status without extensive analysis and research.

When identifying redundant shared folder objects, consider the following:

A shared folder object, published in the Active Directory, is a representation of an existing shared folder on a file server. Hence, if it is possible to determine that a shared folder is redundant, then the shared folder object that targets the shared folder is also redundant. The redundancy status of a shared folder on a file server is hence influenced by the following:

A feature and / or metadata aspect of the shared folder itself

A metadata aspect of the file share targeted by a shared folder

The presence of duplicate instances of a shared folder, for the same file share, on a file server

The following diagram illustrates this relationship between shared folder objects and all other associated components, such as the actual shared folders, file servers, Active Directory, and clients:



Client

Natsum.com.

Shared Folder Object

Access SharedFolder

FileServer

SharedFolder

SharedFolder


Figure 44.7: Illustration of Relationships between Shared Folders and Shared Folder Objects in Active Directory

When identifying redundant shared folders based upon their features and metadata aspects, consider the following:

This design methodology proposes the following approach, to determine the criteria to permit the intuitive redundancy status of a shared folder (and hence the associated shared folder object), based upon a feature or metadata aspect of the shared folder itself:

• Select a file server with one or more shared folders published to the Active Directory

• Determine the criteria to identify the redundancy status of a shared folder based upon its feature(s) and metadata aspect(s)

• Evaluate all identified shared folders against the defined criteria to isolate those that comply with the criteria for redundancy

When determining the criteria for identification of redundant shared folders, based upon their features and metadata, this design methodology proposes the following example criteria:

• The shared folder, and hence its avatar Active Directory object, is identifiable, via visible metadata aspects only as been associated with a function pre-excluded from the scope of migration. For example, it is possible to identify one or more shared folders generated exclusively to support a project team for a project within the organisation. However, following the completion of the project, there was a failure to delete all strictly associated shared folders.

• Certain shared folders (and hence their avatar Active Directory objects), such as those created as test or temporary shared folders, are by direct function, excluded from the scope of migration, unless it is possible to identify explicit requirements to retain and hence include them within the migration scope.

• The new target Windows Server 2003 domain infrastructure is associated with a design for a new file and share management infrastructure, which excludes the use of published file share objects. For example, a fully automated document imaging and management system will now support all shared folder access by clients. This hence makes all currently published shared folder objects redundant and hence included within the scope of directory clean up tasks for migration path “B”.

It is possible to determine the redundancy of existing shared folder objects via, for example, the presence of one or more active or inactive duplicates of active shared folder objects, and hence the opportunity for shared folder object consolidation. Emulate the same process illustrated earlier to identify and manage duplicate



distribution group objects, to identify and manage duplicate instances of shared folder objects.

When determining the criteria for the categorisation of shared folder objects into the “actually redundant” and “potentially redundant” categories, consider the following:

Although the onus is with the organisation to define the criteria for categorisation of the shared folder objects, this design methodology provides the following example criteria:

Categorise a shared folder as “actually redundant” where, for example, it is possible to identify compliance with the following criteria:

• It is possible to intuitively identify that the shared folder is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the shared folder object with the defined criteria for redundancy (such as exclusion from the migration scope, or status as a duplicate “secondary” shared folder object to a “primary” shared folder object)

• It is possible to identify compliance of the shared folder object with the criteria for acceptable consequences from the deletion / disabling of the shared folder object

Categorise a shared folder as “potentially redundant” where, for example, it is possible to identify compliance with the following criteria:


• It is possible to identify compliance of the shared folder object with the defined criteria for redundancy (such as lack of use, exclusion from the migration scope, or status as a duplicate “secondary” shared folder object to a “primary” shared folder object)

• It is possible to identify compliance of the shared folder object with the criteria for unacceptable consequences from the deletion / disabling of the shared folder object

For all shared folder objects that unequivocally comply with the criteria for categorisation as “actually redundant”, define the following as the pre-migration directory clean up tasks for these shared folder objects:

Addition of the shared folder objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Requirement to “functionally disable” the shared folder objects by removing them from the Active Directory (which does not delete the actual shared folders, but just their avatar objects)

Optionally, move the actually redundant shared folder objects to a custom OU to differentiate them from other active shared folder objects

For all shared folder objects that unequivocally comply with the criteria for categorisation as “potentially redundant”, define the following as the pre-migration directory clean up tasks for these shared folder objects:



Addition of the shared folder objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Modification of the description field to add text that denotes the shared folder objects as “potentially redundant” objects, but with no requirements to functionally disable or move the shared folder objects


Identify and document all shared folder objects published to the Windows 2000 Active Directory domain partition

Determine and document the criteria for the inclusion of shared folder objects from the scope of pre-migration directory clean up tasks based upon their metadata

Determine and document the criteria for the identification of redundant shared folder objects

Determine and document the required approach towards the identification and management of duplicate shared folder objects

Determine and document the criteria for the categorisation of shared folder objects into the “actually redundant” and the “potentially redundant” categories

Evaluate all identified shared folder objects against the defined criteria and define the pre-migration directory clean up tasks appropriate to their subsequent categorisation.

• Factor A10: Determination of the contact objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”


Has identified the requirement for the migration of one or more legacy Windows 2000 domains using simple migration path “B”

Has identified the presence of a significant number of contact objects (for example, a few hundred or more) within the domain partition of one or more legacy in-scope Windows 2000 domains, and

Wishes to determine the contact objects that require inclusion within the scope of pre-migration directory clean up tasks


Prior to determination of the inclusion and exclusion criteria for contact objects from the scope of pre-migration directory clean up tasks for migration path “B”, consider the following:

The identification of contact objects that fall within the scope of pre-migration directory clean up tasks is a significantly simpler process than for user, computer, or group objects. This is because:

There are typically fewer contact objects within an Active Directory domain than user, computer, or group objects.

An organisation may populate a Windows 2000 Active Directory domain partition with contact objects typically to support the population of the Global Address List for an Exchange 2000 infrastructure with e-mail addresses for external users.



However, not all organisations actively design, populate, and support the use of contact objects to facilitate the location of the e-mail addresses for users foreign to the organisation.

The threshold stated for the number of contact objects within the criteria for the application of this factor reflects the fact that the execution of this process is only useful in organisations with a significant population of published contact objects.

Contact objects, unlike other Active Directory objects, are the most likely objects to gain a redundancy status, as they represent a fluctuating population of users within an organisation, and not full or part-time employees of the organisation.

Note that the number of foreign users within an organisation does not reflect the number of existing contact objects present within the Active Directory. Most organisations that employ contact objects have defined formal or informal criteria for the generation of such objects. For example, the foreign user will be working within the organisation for a significant period, such as more than a few months, and employees of the organisation will require access to their e-mail addresses on a regular basis.

The identification of contact objects that require inclusion within the scope of pre-migration directory clean up tasks is focussed around the following metadata aspects of these objects:

The target foreign users represented by the contact objects

The length of the contract of employment within the organisation of the foreign users

The identifiable and intuitive redundancy of the contact objects

The identifiable and indirect redundancy of the contact objects due, for example, to the direct redundancy of one or more metadata aspects of the object.


Identify the contact objects potentially within the scope of directory clean up tasks, and then

Assign the identified contact objects to one or the following categories:

• “Actually redundant” contact objects. These are objects, identified by the approach below as currently redundant, and that serve no current or future function. The deletion or removal of these objects will not generate any unacceptable consequences.

• “Potentially redundant” contact objects. These are objects, identified by the approach below, as potentially redundant, as they serve a current function in the legacy domain, but not in the target Windows Server 2003 domain. The deletion or removal of these objects will generate unacceptable consequences.

All “actually redundant” and “potentially redundant” contact objects are within the scope of the pre-migration directory clean up tasks. However, the differentiators between these two categories are:


When, within this project, it is possible to remove the contact objects from the domain, prior to their deletion during execution of the pre-migration tasks.



This design methodology proposes the following approach towards the identification of the inclusion and exclusion criteria for existing contact objects from the scope of directory clean up tasks:

Identify all existing contact objects currently present within the Windows 2000 Active Directory domain partition of a legacy domain

Identify all contact objects within this list that can be potentially included within the scope of directory clean up tasks, based upon:

One or more metadata aspects of the contact objects that intuitively places the objects outside of the migration scope for the domain, and hence within the scope

Compliance with redundancy criteria for contact objects

Define the criteria for the categorisation of all identified contact objects (which are potentially within the scope of directory clean up tasks) into the two categories:



Evaluate the results of the above analysis against the defined criteria for categorisation of the contact objects and assign the appropriate category to the contact objects.

As for print queue objects, all contact objects published to the Active Directory domain partition of a legacy Windows 2000 domain have a single function, which is to support the location of communications metadata for a foreign user, such as their e-mail address, telephone number, and so on. Hence, there is no requirement to determine and document the function of each identified contact object.

When determining the criteria for the exclusion of contact objects from the scope of migration, based upon their metadata, consider the following:

It is possible to exclude contact objects from the scope of migration based upon their metadata, such as the logical location (within the legacy domain infrastructure) of the contact objects, the owner(s) of the objects, the logical metadata aspects of the foreign users the contact objects represent, and so on.

For some contact objects, it is intuitively possible to deduce their redundancy status without the requirements for extensive analysis or research. For example, temporary or test contacts identifiable via the words “temp” or “test” within the name and / or description attribute fields. However, for the majority of contact objects, it may be difficult to ascertain their redundancy status without extensive analysis and research.

When identifying redundant contact objects, consider the following:

A contact object, created in the Active Directory, is a representation of a foreign user within the organisation. Hence, if it is possible to determine that a foreign user is redundant (no longer working in the organisation) then the contact object that represents the foreign user is also redundant. The termination date for the contact of employment of a foreign user within the organisation influences the redundancy status of the corresponding contact object. Note that it is typically not a simple procedure to retrieve this information within the majority of organisations.

The following diagram illustrates this relationship between contact objects and all other associated components, such as the actual foreign users, the Active Directory, and the non-foreign users within the organisation:



Natsum.com.

ForeignUser

User

ContactObject

External E-mail


Figure 44.8: Illustration of Relationships between Foreign Users and Contact Objects in Active Directory

When identifying redundant contacts based upon their features and metadata aspects, consider the following:

Because contact objects represent foreign users within the organisation, the sensitive nature of this step to identify their continued presence or absence from the organisation requires a slightly different approach. This design methodology proposes the following approach, to determine the criteria to permit the intuitive redundancy status of a foreign user (and hence the associated contact object):

• Export from the Active Directory domain partition a list of the contact objects.

• Select a department within the organisation that currently employs foreign users, represented within the Active Directory as contact objects, and send the list of contact objects to the department head. Request that they indicate on the list which foreign users are:

♦ No longer employed by the organisation, and hence their existing contact objects can be categorised as “actually” redundant, or

♦ Due to leave between now and the execution of the migration path for that domain, and hence their existing contact objects can be categorised as “potentially” redundant.

For all contact objects that unequivocally comply with the criteria for categorisation as “actually redundant”, define the following as the pre-migration directory clean up tasks for these contact objects:

Addition of the contact objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Requirement to “functionally disable” the contact objects by removing them from the Active Directory, or

Optionally, move the actually redundant contact objects to a custom OU to differentiate them from other active contact objects

For all contact objects that unequivocally comply with the criteria for categorisation as “potentially redundant”, define the following as the pre-migration directory clean up tasks for these contact objects:

Addition of the contact objects to the list of directory objects within the scope of the pre-migration directory clean up tasks

Modification of the description field to add text that denotes the contact objects as “potentially redundant” objects, but with no requirements to functionally disable or move the contact objects




Identify and document all contact objects published to the Windows 2000 Active Directory domain partition

Determine and document the criteria for the inclusion of contact objects from the scope of pre-migration directory clean up tasks based upon their metadata

Determine and document the criteria for the identification of redundant contact objects

Determine and document the required approach towards the identification and management of duplicate contact objects

Determine and document the criteria for the categorisation of contact objects into the “actually redundant” and the “potentially redundant” categories

Evaluate all identified contact objects against the defined criteria and define the pre-migration directory clean up tasks appropriate to their subsequent categorisation.

• Factor A11: Determination of the custom Organizational Unit (OU) objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”



Has identified the presence of custom OU objects within the domain partition of one or more legacy in-scope Windows 2000 domains, and

Wishes to determine the custom OU objects that require inclusion within the scope of pre-migration directory clean up tasks


Prior to determination of the inclusion and exclusion criteria for custom OUs from the scope of pre-migration directory clean up tasks for migration path “B”, consider the following:

The identification of custom OUs that fall within the scope of pre-migration directory clean up tasks is a significantly simpler process than for user, computer, or group objects. This is because:

There are typically fewer custom OUs within an Active Directory domain than user, computer, or group objects.

Although the contents of OUs may change on a frequent basis (hourly, daily, weekly, or monthly), the number and structure of custom OUs within a domain will change very rarely (monthly, quarterly, or annually).

Within Windows 2000 domains where an organisation designs and actively uses custom OUs, the execution of this process can have a significant impact on the productivity of end users reliant upon the presence of these objects to support:

The implementation of delegation of control permissions to delegate administrators, who in turn may manage aspects of the users



The implementation of GPOs targeted to the contents of the OU / OU hierarchy within the OU infrastructure

The collation of Active Directory objects into discrete containers

The identification of custom OUs that require inclusion within the scope of pre-migration directory clean up tasks is focussed around the following metadata aspects of these objects:

The owner(s) of the custom OUs

The current and proposed contents of a custom OU

The logical location(s) of the custom OUs within the Windows 2000 domain partition

The identifiable and intuitive redundancy of the custom OUs

The identifiable and indirect redundancy of the custom OUs due, for example, to the direct redundancy of one or more metadata aspects of the object


Identify the custom OUs potentially within the scope of directory clean up tasks, and then

Assign the identified custom OUs to one or the following categories:

• “Actually redundant” custom OUs, which are objects, identified by the approach below as currently redundant, and that serve no current or future function. The deletion or removal of these objects will not generate any unacceptable consequences.

• “Potentially redundant” custom OUs, which are objects, identified by the approach below, as potentially redundant, as they serve a current function in the legacy domain, but not in the target Windows Server 2003 domain. The deletion or removal of these objects will generate unacceptable consequences.

All “actually redundant” and “potentially redundant” custom OUs are within the scope of the pre-migration directory clean up tasks. However, the differentiators between these two categories are:


When, within this project, it is possible to remove the custom OUs from the domain, prior to their deletion during execution of the pre-migration tasks.

This design methodology proposes the following approach towards the identification of the inclusion and exclusion criteria for existing custom OUs from the scope of directory clean up tasks:

Identify all existing custom OUs currently present within the Windows 2000 Active Directory domain partition of a legacy domain

Then identify all custom OUs within this list that can be potentially included within the scope of directory clean up tasks, based upon:



One or more metadata aspects of the custom OUs that intuitively places the objects outside of the migration scope for the domain, and hence within the scope

Compliance with redundancy criteria for custom OUs

The define the criteria for the categorisation of all identified custom OUs (which are potentially within the scope of directory clean up tasks) into the two categories:



Then, finally evaluate the results of the above analysis against the defined criteria for categorisation of the custom OUs and assign the appropriate category to the custom OUs.

Unlike print queue objects, custom OUs can serve many functions within a domain, and prior to the identification of their redundancy, it is necessary to identify and document their current function(s) within the domain. For example, a custom OU may collate Active Directory objects for the following reasons:

To hide them from the view of un-trusted remote administrators

To support the implementation of GPOs and / or delegation of control permissions, and so on

When determining the criteria for the exclusion of custom OUs from the scope of migration, based upon their metadata, consider the following:

It is possible to exclude custom OUs from the scope of migration based upon their metadata, such as the logical location (within the legacy domain infrastructure) of the custom OUs, the owner(s) of the objects, the logical metadata aspects of the file shares the custom OUs target, and so on.

For some custom OUs, it is intuitively possible to deduce their redundancy status without the requirements for extensive analysis or research. For example, temporary or test shared folders identifiable via the words “temp” or “test” within the name and / or description attribute fields. However, for the majority of custom OUs, it may be difficult to ascertain their redundancy status without extensive analysis and research.

When identifying redundant custom OUs, consider the following:

Although it is very simple to move existing custom OUs within a Windows 2000 domain to match, for example, a new OU infrastructure design for a Windows Server 2003 domain, this design methodology does not recommend this approach to create the new required OU infrastructure. This is because the retention of explicit permissions on existing OUs to support, for example, delegation of control, may not match the required permissions within the new DOC infrastructure for the upgraded Windows Server 2003 domain. In addition, due to the creation and linking of GPOs to OUs, there may be a requirement to remove these objects prior to the upgrade. Where an organisation is willing to remove all explicitly assigned permissions and GPOs (implemented and linked GPOs) manually, then this may be acceptable. However, the creation of completely new OU infrastructure(s) in the upgraded Windows Server 2003 domain is a better approach, followed by the moving of the required objects into the appropriate OUs from the existing OUs.

It is hence necessary to execute the following approach to identify redundant custom OUs:



Analyse the results of the design gap analysis (executed within the earlier process “determination of the required migration strategy”) to identify:

• All of the OUs currently existing within the legacy Windows 2000 domain(s)

• The OUs required by the target Windows Server 2003 domains (use the results of the domain mapping exercise to identify the target Windows Server 2003 domain for each legacy Windows 2000 domain to be upgraded using the in-place upgrade migration path “B”)

• The details of the required DOC and GPO infrastructure for the new Windows Server 2003 domain

Evaluate all existing OUs against the design requirements for the new OU infrastructure(s) within the Windows Server 2003 domain

Identify the OUs that will require extensive directory clean up to remove explicitly assigned permissions and implemented GPOs, and so on

Note that it is possible to determine the redundancy of existing custom OUs via, for example, the presence of one or more active or inactive duplicates of active custom OUs, and hence the opportunity for custom OU consolidation. Emulate the same process illustrated earlier to identify and manage duplicate distribution group objects, to identify and manage duplicate instances of custom OUs.

When determining the criteria for the categorisation of custom OUs into the “actually redundant” and “potentially redundant” categories, consider the following:

Although the onus is with the organisation to define the criteria for categorisation of the custom OUs, this design methodology provides the following example criteria:

Categorise an OU as “actually redundant” where, for example, it is possible to identify compliance with the following criteria:


• It is possible to identify compliance of the custom OU with the defined criteria for redundancy (such as exclusion from the migration scope, or status as a duplicate “secondary” custom OU to a “primary” custom OU)

• It is possible to identify compliance of the custom OU with the criteria for acceptable consequences from the deletion / disabling of the custom OU

Categorise an OU as “potentially redundant” where, for example, it is possible to identify compliance with the following criteria:

• It is possible to intuitively identify that the OU is a candidate for directory clean up based upon one or more of its metadata aspects, or its status

• It is possible to identify compliance of the custom OU with the defined criteria for redundancy (such as lack of use, exclusion from the migration scope, or status as a duplicate “secondary” custom OU to a “primary” custom OU)

• It is possible to identify compliance of the custom OU with the criteria for unacceptable consequences from the deletion / disabling of the custom OU

For all custom OUs that unequivocally comply with the criteria for categorisation as “actually redundant”, define the following as the pre-migration directory clean up tasks for these custom OUs:



Addition of the custom OUs to the list of directory objects within the scope of the pre-migration directory clean up tasks

Requirement to “functionally disable” the custom OUs by removing them from the Active Directory

Optionally, move the actually redundant custom OUs to a custom OU within the domain to differentiate them from other active custom OUs

For all custom OUs that unequivocally comply with the criteria for categorisation as “potentially redundant”, define the following as the pre-migration directory clean up tasks for these custom OUs:

Addition of the custom OUs to the list of directory objects within the scope of the pre-migration directory clean up tasks

Modification of the description field to add text that denotes the custom OUs as “potentially redundant” objects, but with no requirements to functionally disable the custom OUs


Identify and document all custom OUs within the Windows 2000 Active Directory domain partition

Determine and document the criteria for the inclusion of custom OUs from the scope of pre-migration directory clean up tasks based upon their metadata

Determine and document the criteria for the identification of redundant custom OUs

Determine and document the required approach towards the identification and management of duplicate custom OUs

Determine and document the criteria for the categorisation of custom OUs into the “actually redundant” and the “potentially redundant” categories

Evaluate all identified custom OUs against the defined criteria and define the pre-migration directory clean up tasks appropriate to their subsequent categorisation.

• Factor A12: Determination of the foreignsecurityprincipal objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”



Has identified the presence of one or more external trust relationships between a legacy Windows 2000 domain and external Windows domain or Kerberos V5 realm

Has identified the presence of a significant number of foreignsecurityprincipal objects (more than a few hundred) within the legacy domain partition, and the requirements to retire one or more external trust relationships after the upgrade to Windows Server 2003, and

Wishes to determine the foreignsecurityprincipal objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”.




Windows 2000 creates a “foreignsecurityprincipal” object to represent each user and security group, from an external domain, added to security groups within the Windows 2000 domain across an external trust relationship. This placeholder object represents the external users and groups, but does not display details of these objects.

Prior to the execution of the process to identify redundant foreignsecurityprincipal objects, consider the following:

Some organisations consider it necessary to remove these objects prior to the execution of migration path “B”, as these objects are not automatically removed from the domain, even after:

Removal of the external user or group from the security group(s) in the Windows 2000 domain, and hence removing all reason for existence of these placeholder objects.

Removal of the external trust relationship across which these objects arrived, and hence removing the vehicle to support their presence.

The foreignsecurityprincipal placeholder objects, which reside in the “CN=ForeignSecurityPrincipals,DC=<domain_name>” container, do not indicate the source trust relationship, or the display name of the referenced foreign security principal. This may hence hinder the process to identify redundant instances of these objects.

This design methodology proposes the following approach to identify the redundant foreignsecurityprincipal objects within a legacy Windows 2000 domain:

Examine the external trust relationships between a legacy Windows 2000 domain and external domains

Use both of the following two methods to extract information about the foreignsecurityprincipal objects within a legacy Windows 2000 domain:

Use the “Active Directory Users and Computers” MMC snap-in to navigate to the “ForeignSecurityPrincipals” container, and then export the list of objects in this container to a comma separated values (CSV) file

Then use the LDIFDE command line tool to extract a list of foreignsecurityprincipal objects and the attribute “memberOf” using the following example command “ldifde -d "CN=ForeignSecurityPrincipals,DC=<domain_name>,DC=<domain_name_suffix>" -l memberOf -n -f foreign.ldf”

Analyse the exports to identify the following:

The foreignsecurityprincipal objects that require automatic exclusion from the scope of directory clean up tasks. These objects are those with the “Readable Name” (from the MMC export) starting with “NT AUTHORITY\”, such as “NT AUTHORITY\SYSTEM”, “NT AUTHORITY\NETWORK SERVICE”, “NT AUTHORITY\Authenticated Users”, and so on.

The foreignsecurityprincipal objects no longer members of any security groups within the Windows 2000 domain, due to the absence of the “memberOf” attribute and values (from the LDIFDE export). Categorise these objects as “actually” redundant objects.

The foreignsecurityprincipal objects that do not comply with the above two criteria. From this list of objects, it is necessary to identify the following:



• The active foreignsecurityprincipal objects that hence require exclusion from the scope of directory clean up tasks, and

• The foreignsecurityprincipal objects that will be categorised as “potentially” redundant once the trust relationships that provide the vehicle for their presence becomes redundant.

Using the above information and approach, identify and document all “actually” and “potentially” redundant foreignsecurityprincipal objects, and action as appropriate.

• Factor A13: Determination of the custom system objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”



Has identified the presence of custom system objects, within the System container of a Windows 2000 domain partition, created by Active Directory-integrated applications, and

Wishes to determine the custom system objects within this container that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”.


The function of the System container of a Windows 2000 domain partition is to hold operational information unique to each domain. This will hence include the following types of containers, information, and objects:

The default local security policy (within the “Default Domain Policy” container)

File link tracking objects (within the “FileLinks” container)

NetMeeting meeting objects (within the “Meetings” container)

IP Security policies (within the “IP Security” container)

Windows Sockets registration and resolution (RnR) objects (within the “WinsockServices” container)

RPC name service (RpcNs) connection points (within the “RpcServices” container)

Microsoft DNS zone data (for Active Directory-integrated zones) (in the “MicrosoftDNS” container)

Distributed File System roots (within the “Dfs-Configuration” container)

RAS and IAS Sever Access Check objects (within the “RAS and IAS Server Access Check” container)

Custom service-related System objects associated with Active Directory-integrated products from third party vendors. Vendors are encouraged to create a vendor-specific container, as a child of the System container, to store configuration information for Active Directory-integrated applications.



When determining the custom System container objects that require inclusion within the scope of directory clean up tasks, consider the following:

The objects within the System container for a Windows 2000 domain partition are essential to the normal and continued operation of the applications and services they support. It is hence important to qualify, very thoroughly, all objects identified for removal, to ensure that the accidental or intentional deletion of these objects does not generate unacceptable consequences. The accidental deletion of an object within the System container, or sub-containers, may disrupt the continuity of the Active Directory domain, and hence all dependencies of the domain.

The System container holds objects created both by default, during the creation of the Active Directory domain, and objects created manually or automatically by applications and services, after implementation of the domain. All default objects are automatically outside of the scope of the directory clean up tasks for migration path “B”, as their removal will disrupt the operation of the domain.

The objects within the System container can store the following four types of service information:

Client binding information, which is the service name and connection methods used by the clients of a service to access the service

Administrative binding information, which is the service name and connection methods used by administrative programs to connect to a service for administrative operations (note that a single binding can support both client and administrative functions)

Persistent configuration data for the represented service, which is stored in Active Directory to utilise the security and replication capabilities of Active Directory

Other service-specific data, such as vendor-specific data, extensions to the Active Directory schema and object classes, and so on.

When investigating containers and objects within the System container to identify objects for inclusion within the scope of directory clean up tasks, consider the following:

The majority of objects created inside the System container and sub-containers are outside of the scope of directory clean up tasks. This is because Active Directory automatically removes these objects from the System container following removal of the corresponding services or targets for the objects.

The scope of directory clean up tasks for the custom objects within the System container is hence limited to those objects generated by Active Directory-integrated applications. Hence, to identify these custom System objects that require removal, identify all current applications and services that own / created the objects, and evaluate their redundancy status. Where such applications exist, determine the requirements for their retention following completion of all migration activities.

See factor A16 for details of identification and removal of Distributed Link Tracking (DLT) objects within a Windows 2000 domain partition. DLT objects reside within the “ObjectMoveTable” and “VolumeTable” containers of the “FileLinks” container. The “FileLinks” container resides within the System container of a domain.

Where it is not possible to identify any requirements to retain such applications, and hence their corresponding custom System container objects, then categorise these objects as “potentially” redundant.



Categorise custom System container objects as “actually” redundant where it is possible to identify the following:

• One or more Active Directory-integrated applications generated one or more custom System container objects and / or containers

• These applications are no longer in use, but the containers and custom System objects are still present within the System container for a legacy Windows 2000 domain

Using the above information and approach, execute an analysis to identify and document all custom System container objects that require categorisation as “actually” and “potentially” redundant, and action as appropriate.

• Factor A14: Determination of the custom Site objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”



Has identified the presence of one or more Site infrastructures within the organisation, within which it is possible to identify current or future changes to reflect a migration to the Windows Server 2003 Active Directory infrastructure, and

Wishes to determine the custom Site objects that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”.


Where an organisation has one or more forests, geographically distributed across two or more physical locations, linked by WAN links, then each forest will require a Site infrastructure to support distributed replication between remote domain controllers.

An in-place upgrade of a Windows 2000 domain using migration path “B” will retain all custom Site objects within the Configuration partition of an Active Directory forest. Hence, changes to the Site infrastructure that result in the creation redundant objects (Sites, Site Links, Site Link Bridges, custom connection objects, TCP/IP subnet-to-Site mapping objects, and so on) will propagate these redundant objects to the Windows Server 2003 Active Directory infrastructure.

Prior to the determination of the custom Site objects that require inclusion within the scope of the pre-migration directory clean up tasks for migration path “B”, consider the following:

The term “Site objects” refers to all objects associated within a Site infrastructure for an Active Directory forest, such as Site objects themselves, Site Link objects, Site Link Bridge objects, custom connection objects, TCP/IP subnet-to-Site mapping objects, and so on.

Only “custom” Site objects are within the scope of the directory clean up tasks, as these objects represent all manually created or modified Site infrastructure objects. All automatically generated and unmodified Site objects, such as connection objects, are outside of the scope of the directory clean up tasks.

This design methodology provides the following examples of changes to the Site infrastructure for a legacy Windows 2000 forest that may generate redundant Site objects:



The design of the new Windows Server 2003 Active Directory infrastructure, which will result in a consolidation in the number of existing Sites due to a reduction in the number of Windows Server 2003 domains required.

An organisation is concurrently planning a migration and upgrade from an Exchange 2000 infrastructure to an Exchange Server 2003 infrastructure. The new Exchange Server 2003 infrastructure will result in the physical and geographical consolidation of servers, to support upgrades in WAN link capacities to remote locations. The removal of remote Exchange Servers and the increase in WAN link bandwidths no longer support the requirements for local domain controllers in remote locations. This hence reduces the number of Sites required to support the new Windows Server 2003 forest.

An organisation is currently performing a concurrent re-architecture of the TCP/IP network protocol. Hence, all existing TCP/IP subnet-to-Site mapping objects using the old TCP/IP architecture will become redundant.

An organisation is concurrently planning a migration of their existing WAN infrastructure to a new service provider. The migration will result in the generation of a different network topology that will support the upgraded Windows Server 2003 forest. Hence, existing Site Link, Site Link Bridge, and custom connection objects may become redundant.

When determining the presence of redundant custom Site objects for inclusion within the scope of directory clean up tasks for migration path “B”, consider the following:

This design methodology proposes the following approach towards the identification of redundant Site objects:

• Analyse the design summary for the new Windows Server 2003 Active Directory infrastructure and understand the design requirements for the Site infrastructure.

• Analyse the results of the design gap analysis between the legacy Windows 2000 forest infrastructure and the new Windows Server 2003 infrastructure to identify the Site-specific design similarities and differences

• Identify all currently redundant Site objects via execution of the following steps:

♦ Retrieve and analyse the original design for the Site infrastructure for each existing Windows 2000 forest.

♦ Then, perform an investigation to identify all previous (from time of implementation of Windows 2000 infrastructure to present) changes to the organisation and Active Directory forest infrastructure that has resulted in a modifications to the Site infrastructure for each existing forest.

♦ Then execute a gap analysis to identify all Site changes not reflected in the existing Site infrastructure(s). For example, the original Site infrastructure design for a Windows 2000 forest within an organisation required three Sites, and corresponding Site Links, to represent three physical locations and WAN links respectively. One year after implementation of this infrastructure, the organisation added three new physical locations, removed one existing physical location, and changed four WAN links. However, upon examination of the existing Site infrastructure, it is possible to identify six Site objects and not five, as there was a failure to delete the Site object from the Active Directory that previously represented the now removed physical location. In addition,



although the Site administrator created new Site Link objects to reflect modifications to the WAN link infrastructure, there was a failure to delete the old Site Link objects.

♦ Where it is possible to identify such objects, which are immediately redundant, categorise these objects as “actually” redundant, as they no longer serve any function in supporting the distributed replication of the Active Directory forest.

• Identify all potential Site object redundancies via execution of the following steps:

♦ Use the results of the design gap analysis to identify all currently valid Site objects that are not required by the corresponding Windows Server 2003 Active Directory forest, following completion of all migration activities.

♦ Perform an investigation to identify all potential changes within the organisation, such as closure of remote locations, upgrades, and modifications to WAN links, plans to redesign the TCP/IP infrastructure, which will influence the redundancy status of existing Site objects. The requirements to execute such changes must occur within the timeframe for this migration project.

♦ Where it is possible to identify any such changes, determine the Site object(s) affected by the change, and categorise the objects as “potentially” redundant.

Using the above information and approach, execute an analysis to identify and document all “actual” and “potentially” redundant custom Site objects.

• Factor A15: Determination of the custom extensions to the Active Directory Schema that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”



Has identified the presence of custom extensions and modifications to the Active Directory Schema, and

Wishes to determine the Active Directory Schema modifications that require inclusion within the scope of pre-migration directory clean up tasks for migration path “B”.


It is possible to modify the Active Directory Schema to support:

Specific business and operational requirements

Specific Active Directory-integrated applications, such as Exchange 2000 or later

Prior to determination of the scope of the Schema directory clean up tasks, consider the following:

The following modifications and customisations to the Active Directory Schema potentially fall within the scope of the directory clean up tasks for migration path “B”:



The creation of new custom object classes and attributes, such as the InetOrgPerson object class and attributes, or object classes and attributes to support Exchange 2000, and so on.

Modification of the properties / attributes of the Schema object class objects

Modification of the properties / attributes of the Schema attribute objects

The modifications possible to an existing (default) Schema object class include:

Modification of the description of the object class

Addition of new “Auxiliary Classes” to the object class

Addition of new “Possible Superior” classes to the object class

Addition of new Optional attributes

Modification of the access control list and entries

Enable the display of objects the class represents whilst browsing

The modifications possible to an existing (default) Schema attribute include:

Modification of the description of the object attribute

Enable the display of objects the class represents whilst browsing

Enable the indexing of attributes in the Active Directory

Replication of the attribute to the Global Catalog

Although it is possible to add new object classes and attributes to the Active Directory Schema for Windows 2000 forests, it is not possible to delete these objects. Active Directory does allow, however, the deactivation of all custom created object classes and attributes, which will prevent the use of the custom object classes / attributes.

Hence, the scope of the directory clean up tasks for the Active Directory Schema of a legacy Windows 2000 forest is limited to the following actions, where appropriate:

Deactivation of custom object classes and attributes

Removal of any additions of Auxiliary and Possible Superior classes to default object classes

Removal of any additions of new Optional attributes to default object classes

Disabling of the requirement to display the objects an object class represents whilst browsing, for default object classes and attributes

Reversal of the requirements to index default attributes in the Active Directory

Reversal of the requirements to replicate default attributes to the Global Catalog

Modifications to object classes and attributes

It is important to be aware of the implications of executed directory clean up tasks on the Active Directory Schema of an existing production Windows 2000 forest. In addition to the fact that all changes to the Schema require replication to all of the Global Catalog Servers within the forest, the modifications may impact dependents



of the Active Directory forest, such as applications, users, processes, services, and so on. It is hence necessary to ensure the thorough evaluation of all proposed directory clean up tasks against a production Active Directory Schema.

The objectives of this step within this process are to:

Identify all customisations to the default Windows 2000 Active Directory Schema

Evaluate all customisations to the Active Directory Schema object classes and attributes to identify unwanted and reversible changes, and requirements for further modifications

Reverse the unwanted customisations, and execute the additional modifications, where appropriate

To support the objectives for this step, this design methodology proposes the following approach to identify the requirements for the execution of any of the above Schema clean up tasks:

To identify all customisations to the default Windows 2000 Active Directory Schema, it is necessary to execute the following steps:

• Gain access to a pristine Active Directory Schema which is not customised, and export the Active Directory schema using the LDIFDE command line tool and the following example command: “ldifde -f schema1.ldf -d "CN=Schema,CN=Configuration,DC=<domain_name>,DC=<domain_name_suffix" -o *”. Note that name assigned to the target output file of “Schema1.ldf”.

• Then perform the same tasks against the existing customised production Active Directory Schema (for each in-scope forest), but rename the output file to, for example, “Schema2.ldf”.

• Run the Windows 2000 Support Tool “Windiff.exe” and run a comparison between “Schema1.ldf” and “Schema2.ldf”. This tool will identify all differences between these two files, and hence highlight the modifications. Ignore the USN differences, and focus on the changes in the attributes for the Active Directory Schema object class and attribute objects. Note that this method will not detail any modifications to the access control lists for object classes and attributes.

Following the identification of all customisations, determine which Schema customisations require retention, and which require reversal or further modification, to comply with the design requirements for the Windows Server 2003 Active Directory infrastructure. Note that there may be a concurrent requirement to modify any associated display specifiers for customised / new Schema object classes and attributes.

The execution of the pre-migration tasks for migration path “B” involves the extension of the Active Directory Schema for Windows 2000 to create a Windows Server 2003 Active Directory Schema. Where an organisation has extended the Windows 2000 Active Directory Schema with an installation of Exchange 2000, the execution of the “Adprep / forestprep” Schema extension will “mangle” certain attributes. See the Microsoft Knowledge Base article KB314649 for details on how to prepare the Windows 2000 Active Directory Schema for execution of the Adprep Schema extension.

Using the above information and approach, execute an analysis to identify and document all requirements for the clean up of each relevant Windows 2000 Active Directory Schema, as part of the pre-migration directory clean up tasks for migration path “B”.



• Factor A16: Determination of the requirements for the removal of Distributed Link Tracking (DLT) objects as part of the pre-migration directory clean up tasks for migration path “B”


Has identified the requirement for the migration of one or more legacy Windows 2000 domains using simple migration path “B”, and

Wishes to determine the requirements for the removal of Distributed Link Tracking (DLT) objects as part of the pre-migration directory clean up tasks for migration path “B”.


The objective of the Distributed Link Tracking (DLT) service, which has a server and client component, is to track links to files on NTFS-formatted partitions. Windows uses the DLT client to find a file if, after a link is made to that file on an NTFS volume (such as a shortcut or OLE link) it is moved to another volume on the same computer, moved to another computer, or moved in other similar scenarios.

The DLT server service only runs on Windows 2000 or later domain controllers, and stores information in Active Directory, from which it provides services to help the DLT client instances. The DLT clients prompt the DLT server service to refresh the links every 30 days, and the server service will initiate a scavenging function every 90 days to remove objects not referenced for 90 or more days.

Because the DLT stores link information in the Active Directory domain partition of a Windows 2000 domain, as “linkTrackVolEntry” objects, these objects replicate to all domain controllers within a domain. DLT objects reside within the “ObjectMoveTable” and “VolumeTable” containers of the “FileLinks” container. The “FileLinks” container resides within the System container of a domain. The “ObjectMoveTable” stores information about linked files moved within the domain, and the “VolumeTable” stores information about each NTFS volume in the domain.

Although the DLT objects individually occupy very little space within the Active Directory, collectively they can represent a significant amount of data. The Microsoft Knowledge Base article “KB312403” provides an example where the “FileLinks” container in a fictitious organisation contained over 700,000 DLT objects, collectively representing a few GB of space in the Active Directory ntds.dit database.

Microsoft recommends, in the above mentioned Knowledge Base article, disabling the DLT server service on Windows 2000 domain controllers (it is disabled by default on Windows Server 2003 domain controllers), and removing the DLT objects using the Visual Basic script referenced in the article.

To determine the requirements for the removal of DLT objects, this design methodology recommends execution of the following approach:

Determine the current and future requirements for Windows 2000 and Windows XP Professional clients to use the DLT service. If there is a requirement for the continued use of this service, then:

Determine the number of DLT objects currently present within each Windows 2000 domain that requires a domain upgrade using migration path “B”. To determine the number of DLT objects, examine the contents of the “ObjectMoveTable” and “VolumeTable” containers of the “FileLinks” container. A significant number of objects may be between a few thousand to tens or even hundreds of thousands of objects. Where it is possible to identify a significant number of objects, determine the impact of the presence of these objects on the



execution of the migration path “B”. For example, an in-place upgrade is associated with the following free disk space requirements:

• A minimum of 2 GB free space on the boot partition of the Windows 2000 domain controllers

• A minimum of 15-20% of the current size of the ntds.dit database as free disk space on the partitions that hold the ntds.dit and log files

The removal of, for example, a few hundred thousand DLT objects can significantly reduce the size of an Active Directory database by between a few hundred MB to even one or two GB of disk space. Hence, if disk space on the partitions that hold the ntds.dit and log files is insufficient to support an in-place upgrade, consider the removal of these objects. See below for the approach for the removal of these objects.

Where it is not possible to identify a significant number of DLT objects, then their removal will not vastly reduce, if at all, the size of the Active Directory database. In this scenario, this design methodology recommends the retention of these objects, where it is possible to identify a justified requirement for their use by Windows 2000 and Windows XP Professional clients, and they will not detrimentally influence the in-place upgrade process.

Where it is not possible to identify any justifiable requirements for the continued use of these DLT objects, and / or the number of these objects will detrimentally influence the in-place upgrade process (due to consumption of space in the ntds.dit database), then consider and execute the following:

It is important to note that the deletion of a large volume of DLT objects will not immediately reduce the size of the Active Directory database. In fact, the deletion of the DLT objects tombstones the objects via the removal of two attributes (dscorepropagationdata and objectcategory), which although saves 34 bytes per object, other processes associated with the deletion of the objects increases the size of the objects by 200 bytes. Thus, it may be possible to notice a corresponding increase in the size of the NTDS database after deletion, depending upon the number of DLT objects deleted. A tombstoned object will continue to reside within the Active Directory database for 60 days, after which the garbage collection process will remove the objects. Only then is it possible to perform an offline compaction of the NTDS database, on each domain controller in the domain, to reduce the size of the database. Hence, it is imperative that if there is a requirement for the execution of this process, to remove DLT objects prior to migration and reduce the size of the NTDS database, this process is executed a minimum of two months prior to execution of the migration activities, where possible. Failure to wait 60 days for the removal of these objects will:

• Not permit the execution of the offline defragmentation of the ntds.dit database to reduce its size

• Block replication due to the absence of a version store.

Hence, determine the most opportune time to execute the deletion of the DLT objects. Note that it is only necessary to execute the process detailed in the Microsoft Knowledge Base articles below once per in-scope Windows 2000 domain, and on only one domain controller within each domain. The execution of this process on a Windows 2000 domain controller will replicate the deletions (as tombstones) to all other domain controllers within the domain.

Retrieve the Microsoft Knowledge Base article “KB315229” for instructions on the creation of a script file to purge DLT objects



Retrieve the Microsoft Knowledge Base article “KB312403” for instructions on the execution of:

• The preparatory tasks to disable the DLT service on all domain controllers within the domain

• The generated script to purge DLT objects

Note that following the completion of the in-place upgrade of a Windows 2000 domain, the upgrade disables the DLT service by default on all Windows Server 2003 domain controllers.

If there is a continued requirement to use the DLT service, then it is necessary to use the “System Services” feature of a Windows Server 2003 Active Directory Group Policy to enable the DLT server service on the Windows Server 2003 domain controllers.

Using the above information, execute an analysis to identify and document the requirements to disable the DLT service, and execute any directory clean up tasks to remove DLT related objects.

• Factor A17: Determination of the directory data that requires inclusion within the scope of pre-migration directory clean up tasks for migration path “B”



Wishes to determine the directory data that requires inclusion within the scope of pre-migration directory clean up tasks for migration path “B”.


Prior to the execution of an in-place upgrade, using migration path “B”, it may be necessary to remove:

Redundant directory data, or

Directory data that may conflict with the design for the upgraded Windows Server 2003 domain and Active Directory infrastructure

Although a Windows 2000 forest and domain infrastructure may hold a significant number of types of directory data, this design methodology will focus on the clean upon of only four specific types.

The types of directory data a legacy Windows 2000 domain may hold, for which this design methodology provides consideration for inclusion within the scope of directory clean up tasks, are hence:


Application and service data from directory-enabled applications and services, such as Windows 2000 DNS server operating on Windows 2000 domain controllers, Public Key Service data, from an internal Windows 2000 Certificate Authority, Microsoft Exchange 2000, and so on

Permissions assigned on directory objects to local and non-local security principals (where “local” is defined by all security principals within the boundary of a legacy Windows 2000 domain)



“Residues” of incorrectly removed domain controllers

This design methodology proposes the following approaches to identify redundant and / or conflicting directory data within a legacy Windows 2000 domain:

To identify redundant / design conflicting external trust relationships, execute the following steps:

Analyse the design summary for the new Windows Server 2003 domain and understand the design requirements for external trust relationships

Analyse the design summary for the legacy Windows 2000 domain and identify all existing external trust relationships

Perform a gap analysis between the two design summaries to identify all design similarities and differences between the external trust relationship requirements for the legacy Windows 2000 and Windows Server 2003 domains. The presence of design differences in trust relationship requirements indicate that access to or from the external domain(s) are no longer required. It is hence necessary to execute an analysis to determine the following:

• Determine the continued presence of the external domain(s) to which the external trust relationship(s) reference.

• Determine the nature and function of the external trust relationship(s), for example:

♦ Bi-directional trust relationships to support unlimited access, by security principals in each domain, to resources in each domain

♦ A mono-directional trust relationship (from the trusted legacy Windows 2000 domain towards the external trusting domain) to permit security principals within the Windows 2000 domain to access resources in the external domain

• Determine the required or proposed date(s) for termination of the existing external trust relationships

• Determine the requirements for the termination of the existing trust relationships as pre-migration, migration, or post-migration tasks

• Determine the details of the potential impact associated with the termination of each existing trust relationship as a pre-migration, migration, or post-migration task

To identify redundant / design conflicting application and service directory data within an in-scope legacy Windows 2000 domain, execute the following steps:

Analyse the design summary for the new Windows Server 2003 domain and understand all design requirements for the use of ADPs and other application data storage requirements

Analyse the design summary for the legacy Windows 2000 domain and identify all current requirements for the storage of application data (configuration and operational data) within the Active Directory

Perform a gap analysis between the two design summaries to identify all design similarities and differences between the storage requirements for application data within the legacy Windows 2000 and Windows Server 2003 domains. The presence of design differences in storage requirements for application data may indicate one or more of the following requirements and situations:



• The requirement to migrate current application data, associated with a Microsoft or third party Active Directory-integrated application, from the domain partition of the Windows 2000 domain to a dedicated application directory partition (ADP) in the new Windows Server 2003 forest.

• The requirement to remove an application from the current production environment, and all associated configuration and /or operational data currently stored within the domain partition of a Windows 2000 domain.

Following the identification of design differences in storage requirements for application data in Active Directory, it is necessary to execute an analysis to determine the following:

• Determine the continued presence of the application(s) / service(s) responsible for the configuration and / or operational data within the Active Directory. Note that configuration data for an application refers to all data that describes the configuration of an application, whilst operational data refers to all data used by an application and clients of that application. For example, resource records within a DNS zone integrated in the Active Directory is operational data for the DNS server service. This design methodology recommends enabling the DNS scavenging feature on all Active Directory-integrated DNS zones, and set to the default of 7 days. This will reduce the number of stale resource records within each DNS zone that stores the data in the Active Directory. Where possible, enable similar features for other applications that store relatively dynamic data within the Active Directory, with a low TTL.

• Determine the migration requirements for the application / service data from the Windows 2000 domain partition to, for example, a custom ADP within the target Windows Server 2003 forest. See the Forest Plan process “design of application directory partitions” for details of the design requirements for an ADP infrastructure within the Windows Server 2003 Active Directory infrastructure.

• Determine the nature and function of the application / service responsible for the storage of configuration and / or operational data within the Active Directory, for example:

♦ A Windows 2000 Certificate Authority to support the issue and management of X.509 certificates, issued to users to logon using smart cards / other form factor devices, for digital signing and encryption of e-mails, and so on.

♦ Windows 2000 DNS hosting a number of Active Directory-integrated DNS zones for a domain, which support the Windows 2000 domain and several intranet web sites.

• If there is a requirement to remove the application / service from the production environment, then determine the required or proposed date(s) for termination.

• If it is not possible to identify any requirements to remove the application, then determine if there is a requirement for the upgrade of the application / service, and migration of its configuration and / or operational data to the Windows Server 2003 infrastructure. If it is necessary to upgrade and migrate the application / service and its data, then identify when this requires execution, during the pre-migration, migration, or post-migration phases for the migration project.



• Determine the details of the potential impact associated with the termination or upgrade and migration of each identified application / service as a pre-migration, migration, or post-migration task.

Prior to the identification of redundant / design conflicting permissions on directory objects within a legacy Windows 2000 domain, consider the following:

The permissions that fall within the scope of analysis for this step are the access control entries on directory objects intended to control access to the directory objects, or delegate control over the directory objects, which:

• Do not match the design for the DOC infrastructure within the appropriate ORMI(s) for the Windows Server 2003 domain

• Are present on directory objects but represent security principals that no longer exist within the Windows 2000 domain

• Are present on directory objects but represent security principals that reside outside of the scope of migration, and hence within the scope of directory clean up tasks

The removal of all permissions that match the above criteria, during the pre-migration phase, can generate unacceptable consequences unless the permissions are carefully categorised as “actually” and “potentially” redundant.

The deletion of security principals from a legacy Windows 2000 domain will not automatically delete the access control entry for that security principal on an Active Directory object. This hence leaves a number of redundant entries on valid objects that an organisation may require removal prior to the execution of an in-place upgrade.

To identify redundant permissions on directory objects within a legacy Windows 2000 domain, execute the following:

Use a combination of the “dsquery” and “dsacls” command line resource kit tools to extract lists of directory objects in a Windows 2000 domain, and the permissions on these objects, respectively. For larger numbers of objects, output the “dsquery” queries to a text filed, modify the text filed to prefix the DN for the objects with, for example, “dsacls “\\<domain controller_name>\<DN of object>” and a unique output file reflecting the name of the object, and convert the text file into a batch file. Run the dsquery commands against the root of the domain to retrieve the DNs for all objects of a particular type in the domain, such as “dsquery user <DN of root of domain>” to retrieve the DNs for all user account objects in the domain.

Search the results of the “dsacls” query to identify all access control entries represented by a SID and not a readable name, such as: “Allow S-1-5-21-3703486802-3498517240-3634893875-2181 SPECIAL ACCESS for user CREATE CHILD DELETE CHILD”.

Summarise the results of the redundant access control lists on the Active Directory objects.

To identify permissions on directory objects within a legacy Windows 2000 domain that conflict with the design requirements for the Windows Server 2003 domain and DOC infrastructure, execute the following:

Examine the predefined business and technical migration goals to identify any goals that will influence the design and execution of permission clean up tasks



Analyse the design summary for the new Windows Server 2003 domain and understand the design requirements for the DOC infrastructure within each required ORMI for the domain.

Analyse the design summary for the legacy Windows 2000 domain to understand the design requirements for the existing DOC infrastructure, where applicable.

Identify all design differences between permission requirements on directory objects, and correlate these differences with the permissions on existing directory objects. Identify all design conflict permissions, and determine the requirements for their categorisation as “actually” or “potentially” redundant permissions, and then action as appropriate.

When attempting to identify “residue objects” for incorrectly removed Windows 2000 domain controllers within a domain, consider the following:

Within organisations that support a physically distributed IT administration team, responsible for the administration of an Active Directory infrastructure, regardless of whether the IT administration team is logically centralised or decentralised, mistakes can happen in remote locations. For example, a remote administrator accidentally irreversibly brings down a Windows 2000 domain controller for a domain, or encounters a failed Active Directory demotion. This leaves a number of “reside” objects within the Active Directory of objects that represent that domain controller. Prior to the upgrade of a legacy Windows 2000 domain to Windows Server 2003, it is important to remove as much redundant data as possible, and this hence includes such “residue” objects.

The Microsoft Knowledge Base article “KB216498” provides the procedure for the removal of such data from the Active Directory, using a variety of tools, such as NTDSUTIL, ADSIEdit, and so on. Reference this article and execute the relevant procedures if it is possible to identify the presence of such “residue” objects.

Using the above information and approaches, for each in-scope legacy Windows 2000 domain that requires migration using migration path “B”, execute the following to determine and document the following “actual” and “potentially” redundant directory data:


Configuration and / operational data stored within the Active Directory for Active Directory-integrated applications and / or services

Permissions on directory objects

• Factor A18: Determination of the design requirements for pre-migration tasks to prepare one or more legacy Windows NT 4.0 domains for the execution of in-place upgrade path “A”


Has identified the requirement for the migration of one or more legacy Windows NT 4.0 domains using simple migration path “A”, and

Wishes to determine the design requirements for pre-migration tasks to prepare a source Windows NT 4.0 domain for the execution of migration path “A”




Execution of the preparatory tasks for migration path “A” requires careful planning and design, to ensure success for the actual execution of this path. As this migration path has a direct impact on the production domain environment for an organisation, a failure in the execution of this in-place upgrade path may disrupt business continuity.

Hence, the objectives of this step, in conjunction with the design for the contingency plan, are to ensure the organisation acknowledges and considers all factors that can detrimentally affect the success of this path within in the design of this migration path.

Note that the objective of this step is just to determine the design requirements for the pre-migration tasks to execute any of the three supported approaches for migration path “A”.

This step does not consider the requirements for contingency or coexistence. The later steps within this process, “determination of the design requirements for a contingency plan” and “determination of the design requirements for a coexistence plan”, consider all of the design requirements for the preparatory tasks to support a rollback of an existing Windows NT 4.0 domain environment, and for continued coexistence during the migration phase.

Note that the pre-migration tasks discussed within this factor only represent those tasks that require design for execution, and thus the function of this step is to determine the design requirements for these tasks.

As it is possible to identify a significant number of additional tasks for each approach within migration path “A”, the later step within this process (“generation of the design for the migration checklists”) will provide a few examples of pre-migration tasks associated with each migration path, which do not require design for execution.

This design methodology supports three discrete approaches towards the execution of migration path “A” (see process “understanding supported migration paths” for more details). This step will hence assist an organisation in the determination of the design requirements for the following:

Pre-migration tasks common to the execution of any of the three approaches supported for migration path “A”.

Pre-migration tasks specific to:

Approach 1 of migration path “A” (in-place upgrade of an existing PDC to become a Windows Server 2003 domain controller and create a new Windows Server 2003 domain), and

Approach 2 of migration path “A” (in-place upgrade of an existing BDC (following its promotion to the PDC for the Windows NT 4.0 domain) to become a Windows Server 2003 domain controller and create a new Windows Server 2003 domain).

Pre-migration tasks specific to approach 3 of migration path “A” (in-place upgrade of a new BDC (built on new server hardware, promoted to become the PDC for the Windows NT 4.0 domain, and then removed from the production network) to become a Windows Server 2003 domain controller and create a new Windows Server 2003 domain).

When determining the design requirements for the pre-migration tasks common to all three approaches for migration path “A”, consider the following:

The preparatory tasks, for execution on a source Windows NT 4.0 domain, common to the execution of all approaches in migration path “A” include:

Completion of all appropriate procurements for Windows Server 2003 licenses



Completion of all standard build designs for the new Windows Server 2003 domain controllers

Implementation, upgrade, or modification of DNS server infrastructure to support Windows Server 2003 Active Directory infrastructure

Preparation of the PDC for the upgrade

All approaches will generate Windows Server 2003 domain controllers, and regardless of whether there is a requirement for the long-term or short-term retention of these domain controllers, it is important to ensure their build and configuration using the standard build.

Where the in-place upgrade of an existing Windows NT 4.0 domain will generate the first Windows Server 2003 forest and domain for the new Windows Server 2003 Active Directory infrastructure, then it is necessary to implement the design for the DNS infrastructure. See the Organisation-Wide Active Directory Plan process “Design of DNS infrastructure” for details of the requirements to:

Design and implement a new Windows Server 2003 DNS infrastructure, or

Modify and / or upgrade an existing DNS infrastructure

Note that it is important to ensure the implementation of the DNS servers for this infrastructure are in close network proximity to the PDC(s) that require upgrade using migration path “A”.

When upgrading a Windows NT 4.0 domain, which supports multiple Windows NT 4.0 domain controllers and member computers running Windows 2000 or later operating systems, the upgrade of the PDC to Windows Server 2003 will generate an increase workload on this domain controller. This is because all Windows 2000 and later member computers will preferentially connect to a Windows Server 2003 domain controller than a Windows NT 4.0 BDC. It is possible to prevent this via the configuration of a registry key on the PDC prior to its upgrade, which shields the upgraded domain controller from authentication requests by all Windows 2000 and later member computers in the domain. The REG_DWORD registry value “NT4Emulator” requires creation within the following registry key on the PDC prior to execution of the in-place upgrade: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters”, and assigned a data value of 1.

When determining the design requirements for the pre-migration tasks to execute approach 1 and / or 2 of migration path “A”, consider the following:

Where an organisation has identified the requirement for the execution of approach 1 and / or 2, this design methodology assumes compliance with all prerequisites for this approach (see factor B4 in the Migration Plan process, “Understanding Supported Migration Paths”, for details).

Note that all references in this specific section to the “PDC” will refer to the existing PDC for approach 1, and the BDC “promoted” to PDC for approach 2.

The preparatory tasks that require design for execution on a source Windows NT 4.0 domain, to support the execution of approaches 1 and 2 for migration path “A”, include:

Execution of an upgrade check on the PDC, to identify all upgrade issues, such as amount of free disk space, hardware compatibility, service pack version, presence of unsupported applications, requirements to disable SID filtering on external trusts, and so on.



Retrieval of all appropriate hardware drivers for Windows Server 2003 from the OEM for the server platform / hardware components, and BIOS and firmware updates for all hardware components

Procurement and installation of all hardware upgrade components on PDC for compliance with minimum hardware specifications / compatibility with the standard server build for Windows Server 2003 domain controllers

Migration of applications and services off PDC prior to upgrade

Verification of the completion of any pending trust relationship creation tasks

When executing the upgrade check on the PDC, this design methodology recommends execution of the following approach:

On each PDC to be migrated using approach 1 of migration path “A”, execute the upgrade compatibility check using “winnt32.exe /checkupgradeonly” from the “i386” folder for Windows Server 2003. This tool will perform an inspection of the PDC, without running the setup, and generate a report detailing all identified issues.

Typical upgrade issues identified by this check will include the following examples:

• Hard disk issues, such as file system and amount of free disk space on the PDC. For example, a PDC configured to use the FAT16 file system will be limited to a 2 GB sized partition, and this will not support the in-place upgrade of the server. This is because the upgrade process to Windows Server 2003 requires more than 2 GB of free disk space. Where it is possible to identify the use of a FAT16 file system on a PDC, then the only options are:

♦ Rebuild the PDC and configure an NTFS version 4.0 formatted boot partition with a minimum of 2 GB free disk space, or

♦ Execute approach 2 on an existing BDC which meets the in-place upgrade prerequisites

• Where a PDC has an NTFS version 4.0 formatted boot partition, but less than 2 GB of free disk space, it is necessary to free up space via:

♦ Deletion of unnecessary files and data on the boot partition for the PDC

♦ Removal of superfluous applications and services that require hard disk space on the boot partition for the PDC

• Other hard disk issues may include incompatibility with the design requirements for the distribution of the Active Directory database and transaction logs on the domain controllers. Where an existing server hardware platform is unable to accommodate more disk drives, there may be a requirement for the procurement of an external disk array and disk array controller.

• Hardware issues, such as unsupported hardware components installed within the PDC or hardware components for which drivers are not available within Windows Server 2003. In this scenario, it is necessary to contact the OEM for the hardware component(s) to obtain hardware drivers for Windows Server 2003. For example, a RAID controller or fibre-channel controller may require specific drivers for Windows Server 2003. Check the hardware compatibility list (HCL) for Windows Server 2003 on Microsoft’s web site for all identified hardware components on the PDC(s).



• Software issues, such as the presence of unsupported software applications installed on the PDC. The “i386\COMPDATA” folder on the Windows Server 2003 CD-ROM contains the details of the unsupported applications and hardware devices, and is referenced by the “/checkupgradeonly” tool. Windows Server 2003 does not support the following software:

♦ Microsoft Exchange 5.5 and Exchange 2000

♦ Site Server 3.0 (SP4 and below)

♦ System Management Server 2.0 (SP2 and below)

♦ Proxy Server

• The upgrade compatibility tool may identify Service Pack issues on the PDC. All Windows NT 4.0 servers (member servers and domain controllers) must be running SP5 or later prior to execution of an in-place upgrade to Windows Server 2003.

• The report from upgrade compatibility check may contain the message “no quarantined trusted domains can exist during NT 4 PDC upgrade”. It is possible to identify this message where the legacy Windows NT 4.0 domain has one or more external trust relationships configured to use SID filtering. Windows NT 4.0 SP4 added support for enabling SID filtering on external trust relationships, but it is necessary to disable this feature prior to an in-place upgrade to Windows Server 2003. See the Microsoft Knowledge Base article 811961 for details on how to disable SID filtering.

As the server platform for the PDC will eventually be running the Windows Server 2003 operating system, it is necessary to retrieve, where possible, all hardware drivers for the server and its components, for Windows Server 2003. If the OEM for the server platform, or its hardware components, does not provide drivers for Windows Server 2003, then either replace the hardware component or use another server. It is important to also retrieve and implement all the latest BIOS updates for the server platform, and firmware updates for server hardware components, such as the RAID controller, and so on.

When determining the hardware upgrade requirements for the PDC of a legacy Windows NT 4.0 domain, this design methodology recommends execution of the following approach:

Analyse the results of the design gap analysis to identify all hardware specification differences between the PDC and the minimum hardware specifications for Windows Server 2003 domain controllers.

Identify all hardware components that require upgrade, and procure all upgrade components. Retrieve all firmware upgrades for all new hardware components, even if recently procured, as the components may have resided in the OEM’s / distributor’s warehouse for a period after manufacture.

Determine the most opportune time to install the hardware upgrades on the server.

Determine the impact of the necessary hardware upgrade(s) on the operation of the Windows NT 4.0 server. Note that this approach requires the Windows NT 4.0 server to be up and running as a Windows NT 4.0 PDC after the hardware upgrades and prior to initiation of the in-place upgrade. Hence, it is important to ensure that the hardware upgrades to the server do not prevent the normal operation of the server. If it is necessary to upgrade a hardware component that will “break” the Windows NT 4.0 operating system and require a re-installation,



such as addition / upgrade of CPUs, and so on, then it is necessary to rebuild the PDC after the upgrade.

Determine the design requirements for the process to implement the necessary hardware upgrades on the PDC, and implement firmware upgrades.

When determining the applications and services that require migration off the PDC prior to the execution of the in-place upgrade, this design methodology recommends execution of the following tasks:

Prior to the execution of an in-place upgrade of a PDC, it is necessary to transfer the role of Export Server for the Windows NT 4.0 LAN Manager Replication Service (LMRepl) to a BDC in the domain. When selecting the appropriate BDC to host this role, it is important to select a BDC that will be the last BDC that requires upgrading or decommissioning, to ensure continuity of this service during the migration phase. Following transfer of the role of Export Server for the LMRepl service, it is essential to test the continued functionality of this service, to ensure no disruption to logons by users, and the provision of logon scripts by the BDCs.

Certain applications and services currently running on a PDC may require removal prior to the in-place upgrade. Where these applications and services currently support business processes, it is necessary to not only remove them from the PDC, but also relocate them to another appropriate server in the domain. For example, the Windows Server 2003 Server operating system does not support applications such as Microsoft Exchange 5.5, Certificate Services 1.0, and so on.

Determine the applications and services that require migration to another server, and determine the design requirements for a process to execute this migration.

Prior to the execution of an in-place upgrade of a PDC, it is important to verify the completion of all activities associated with the creation of trust relationships between a Windows 2000 or Windows Server 2003 domain and that Windows NT 4.0 domain. For example, an administrator within a Windows 2000 or Windows Server 2003 domain initiates the generation of a trust (incoming or outgoing) relationship within a Windows NT 4.0 domain. However, prior to the completion of the trust creation tasks by the administrator in the Windows NT 4.0 domain, the PDC of that domain undergoes an upgrade to Windows Server 2003. This upgrade action will influence the functionality of the initiated trust relationship. The resolution is to remove the trust and recreate it from both sides. Until this resolution is execution, the partially create trust relationship will exhibit the following features:

It is not possible to verify, upgrade, of convert the trust to bi-directional trusts

It is not possible to employ the trust for authentication, where the Windows 2000 or Windows Server 2003 administrator created the trust as an incoming trust relationship.

When determining the design requirements for the pre-migration tasks to execute approach 3 of migration path “A”, consider the following:

Where an organisation has identified the requirement for the execution of approach 3, this design methodology assumes compliance with all prerequisites for this approach (see factor B4 in the process “Understanding Supported Migration Paths” for details).

As approach 3 involves the creation of a new instance of a Windows NT 4.0 BDC on new server hardware, this approach is associated with slightly different challenges to approaches 1 and 2.



The preparatory tasks that require design for execution on a source Windows NT 4.0 domain, to support the execution of approach 3 for migration path “A”, include:

Procurement, installation, and configuration of the new server hardware platform and components

Retrieval of all appropriate hardware drivers for Windows NT 4.0 and Windows Server 2003 from the OEM for the server platform / hardware components, and BIOS and firmware updates for all hardware components

Build of new Windows NT 4.0 (SP6a) BDC and synchronisation with current PDC to receive copy of SAM database

Transfer of BDC from production network to isolated network, and removal of computer account for this BDC from the production domain (Note that pre-migration ends here, with the execution of the in-place upgrade as a “migration” task)

Using the above information, execute an analysis to determine and document the design requirements for the pre-migration tasks, for each of the three supported approaches, for migration path “A”.

• Factor A19: Determination of the design requirements for pre-migration tasks to prepare one or more legacy Windows 2000 domains for the execution of in-place upgrade path “B”



Wishes to determine the design requirements for pre-migration tasks to prepare a source Windows 2000 domain for the execution of migration path “B”


Migration path “B” has one of the most complex set of pre-migration tasks of any of the simple migration paths. The pre-migration tasks reflect the complexity of the migration from an Active Directory infrastructure to a newer version of an Active Directory infrastructure, which hence requires careful preparation to ensure success.

In contrast, the actual migration tasks for migration path “B” require no design at all (see factor B9 in the step “determination of the design requirements for the migration tasks” for details).

Note that the objective of this step is just to determine the design requirements for the pre-migration tasks to execute any of the two supported approaches for migration path “B”. This step does not consider the requirements for contingency or coexistence.

The later steps within this process, “determination of the design requirements for a contingency plan” and “determination of the design requirements for a coexistence plan”, consider all of the design requirements for the preparatory tasks to support a rollback of an existing Windows 2000 domain environment, and for continued coexistence during the migration phase.




As it is possible to identify a significant number of additional tasks for each approach within migration path “B”, the later step within this process (“generation of the design for the migration checklists”) will provide a few examples of migration tasks associated with each migration path, which do not require design for execution

This design methodology supports two discrete approaches towards the execution of migration path “B” (see process “understanding supported migration paths” for more details).

This step will hence assist an organisation in the determination of the design requirements for the following:

Pre-migration tasks common to the execution of either of the two approaches for migration path “B”

Pre-migration tasks specific to the execution of approach 1 of migration path “B” (upgrade of an existing Windows 2000 domain controller to Windows Server 2003 and hence create a new Windows Server 2003 domain)

Pre-migration tasks specific to the execution of approach 2 of migration path “B” (build of a new Windows Server 2003 server and execution of the Active Directory Installation Wizard on this server to create an additional domain controller for an existing legacy Windows 2000 domain, and hence create a new Windows Server 2003 domain)

When determining the design requirements for the pre-migration tasks common to both approaches for migration path “B”, consider the following:

The preparatory tasks that require design for execution on a source Windows 2000 domain, to support the execution of either approach for migration path “B”, include:

Preparation of the existing Windows 2000 domain controllers for the domain upgrade

Preparation of the Windows 2000 Active Directory forest, and domain for an upgrade to Windows Server 2003 Active Directory

When determining the design requirements for the pre-migration tasks for migration path “B”, to prepare existing Windows 2000 domain controllers for the domain upgrade, this design methodology recommends execution of the following approach:

The pre-migration tasks for the preparation of existing Windows 2000 domain controllers that require design include:

• Verification that the minimum recommended version of the Windows 2000 service pack is present on all existing domain controllers within the Windows 2000 domain.

• Verification of end-to-end replication of the Active Directory database throughout the forest

When verifying compliance with the minimum service pack for Windows 2000 on the legacy Windows 2000 domain controllers, prior to an in-place upgrade of the domain to Windows Server 2003, consider the following:

• A Windows 2000 domain is upgraded to a Windows Server 2003 domain via:

♦ The in-place upgrade of a single Windows 2000 domain controller to Windows Server 2003, or



♦ The introduction of a single new Windows Server 2003 domain controller into an existing Windows 2000 domain

• Prior to the upgrade of a Windows 2000 domain, it is necessary to upgrade the Active Directory Schema, and other aspects of the forest and each domain that requires an upgrade, using the Windows Server 2003 adprep tools. The execution of these tools, and the subsequent presence of Windows Server 2003 domain controllers alongside existing Windows 2000 domain controllers, requires the installation of minimum service pack version on the Windows 2000 domain controllers. The minimum Windows 2000 service pack required is SP2, as this introduced support for changes to the Active Directory Schema. However, where there is an anticipated requirement for the coexistence of Windows Server 2003 and Windows 2000 domain controllers in the same domain, then it is necessary to set the minimum Windows 2000 service pack version for all existing Windows 2000 domain controllers to SP3 or later. The Microsoft Knowledge Base article “KB331161” details the service pack requirements for Windows 2000 domain controllers, prior to execution of “adprep /forestprep”.

• Where it is possible to identify a Windows 2000 domain environment where all Windows 2000 domain controllers are stabilised on Windows 2000 SP2, Microsoft recommends the retention of this version and not the implementation of any service pack upgrades.

• However, it is necessary for an organisation to design and implement a rollout of SP3 or later where it is possible to identify the following situation and requirements:

♦ All Windows 2000 domain controllers are running SP1, and / or

♦ There is a requirement for the continued coexistence between Windows 2000 and Windows Server 2003 domain controllers within a Windows Server 2003 domain

• Where it is necessary to implement SP3 or later on existing Windows 2000 domain controllers, then determine the following:

♦ The required mode of distribution of the service pack upgrades to the Windows 2000 domain controllers

♦ The most opportune data and time for implementation of the service pack upgrades, which will require a reboot of the target domain controllers after installation.

When verifying successful end-to-end replication of the Active Directory throughout the forest, consider the following:

• The execution of the “adprep /forestprep" tool and switch will execute 43 forest operational updates (reference: Microsoft Knowledge Base article “KB309628”) (36 of which are performed directly by the adprep tool) to upgrade the Active Directory Schema for the entire forest. These changes will require replication to all domain controllers within the forest. Hence, it is imperative to verify, prior to the execution of this pre-migration tasks, the successful end-to-end replication of the Active Directory throughout the forest. Any issues associated with the replication of the Active Directory to domain controllers within the forest will delay and / or prevent the replication of these Active Directory Schema updates throughout the forest.

• Replication of the Active Directory is managed by the Site infrastructure for a forest, and the presence of Sites, Site Link objects, Site Link Bridge objects



(where required), and connection objects (custom and automatically generated objects). The primary aspects of the Site infrastructure that require verification are the Site Links (and their schedules and replication intervals) and the connection objects.

• It is hence necessary to verify the presence of a minimum of one inbound and one outbound connection object on each domain controller for the following Active Directory partitions:

♦ The Schema and Configuration partition (requires replication to all domain controllers within the forest), and

♦ The Domain partition (requires replication to all domain controllers within each domain in the forest, and to all Global Catalog servers (all domain objects, but partial object attributes) in the forest)

• It is possible to verify replication using the Windows Server 2003 command line resource kit tool, repadmin.exe, executed from a Windows Server 2003 or Windows XP Professional member computer in the forest, with the following arguments: “repadmin /replsum /bysrc /bydest /sort:delta”. This command will retrieve the value of the “largest delta” for each domain controller. It is important to verify that the value for this delta does not:

♦ Exceed the replication frequency defined by a corresponding Site Link or connection object, and

♦ Exceed 60 days (the tombstone value)

• Where it is possible to identify compliance with these criteria, then this design methodology recommends the following approach to address the identified replication errors and inconsistencies:

♦ Identify all Windows 2000 domain controllers, currently operating in the forest and on the production network, replicating inbound and outbound changes greater than 60 days old. These domain controllers represent a source of unwanted directory objects, for which the tombstone flags have expired, and represent the highest priority for replication resolution. The high priority for the identification and troubleshooting of these domain controllers reflects the fact that they represent the source for a reversal of a Schema update to the forest.

♦ Identify all Windows 2000 domain controllers, previously in production within the forest, but now currently operating off the production environment, and have been so for less than 60 days. It is imperative to reintroduce these domain controllers to the production environment, where possible, prior to the execution of the “repadmin.exe” replication query. This will hence permit the incorporate of their role(s) in facilitating replication of the Active Directory throughout the forest.

♦ Identify all Windows 2000 domain controllers, currently on the production environment, which fail to replicate with their replication partners. Identification of such domain controllers may warrant the execution of the following steps:

The forceful demotion of these Windows 2000 domain controllers, and hence their removal from the forest

Removal of any “residue” objects in the Active Directory that represent these domain controllers after completion of the demotion



Rebuild of the domain controllers, where necessary, and reintroduction to their respective domain as domain controllers.

Manual initiation of the Knowledge Consistency Checker

Re-verification of the replication of these domain controllers with their replication partners

• Note that the later step within this process (“generation of the design for the migration checklists”) will provide a few examples of pre-migration tasks associated with each migration path, which do not require design for execution for migration path “B”.

When determining the design requirements for the pre-migration tasks for migration path “B”, to prepare the Windows 2000 forest and domains for the domain upgrade, this design methodology recommends execution of the following approach:

As discussed earlier, it is necessary to prepare a Windows 2000 forest and domain for an upgrade to Windows Server 2003 via execution of the following two “adprep.exe” commands:

• “Adprep /forestprep”, which directly executes 36 forest operational upgrades, in the Configuration and Schema partitions of the Active Directory

• “Adprep /domainprep”, which directly executes 50 operations on the domain controller hosting the Infrastructure Master FSMO role

When determining the design requirements for the execution of these two commands to the “adprep.exe” tool, consider the following:

• The “adprep /forestprep” command has the following execution profile:

♦ It requires execution only once per Windows 2000 forest

♦ It requires execution first, prior to the “adprep /domainprep” command

♦ It requires execution on a Windows 2000 domain controller in the forest root domain, hosting the Schema Master FSMO role

♦ It requires execution under the security context of a user account that is a member of the Enterprise Admins group in the forest root domain, and the Schema Admins group for the forest.

• The “adprep /domainprep” command has the following execution profile:

♦ It requires execution once within each domain in the forest, including the forest root domain

♦ It requires execution only after execution of the “adprep /forestprep” command, and successful verification of the replication of the Schema changes (from the /forestprep command) to all domain controllers in the forest.

♦ It requires execution on a Windows 2000 domain controller in a domain hosting the Infrastructure Master FSMO role

♦ It requires execution under the security context of a user account that is a member of the Domain Admins group in the Windows 2000 domain.



• When determining the design requirements for the pre-migration tasks to execute the “adprep /forestprep” command, consider the following:

♦ It is important to note that the deliverables from the execution of this command are not reversible, and hence considerable planning is required prior to execution on a production Windows 2000 forest. In addition, as this command will generate a replication wave across the entire Windows 2000 forest, it is important to plan the date and time for execution of this command appropriately.

♦ This design methodology recommends the execution of the following approach to determine the design requirements for the execution of the “adprep /forestprep” command, as a pre-migration task for migration path “B”:

Determine the steps necessary to prepare for the execution of this command, such as:

♦ The identification of the required date and time for execution of this command

♦ Identification of the user account to execute this command, based upon its membership to the Enterprise Admins group in the forest root domain, and the Schema Admins group

♦ Identification of the Windows 2000 domain controller hosting the Schema Master FSMO role

♦ Verification of the completion of all pre-execution tasks (such as verification of replication, and so on)

♦ Verification of the successful completion and replication of the results of the results of the “adprep /forestprep” command

When determining the most opportune date and time for execution of this command, the selection of the date and time is influenced by:

♦ The patterns in levels of available bandwidth within the supporting LAN and WAN infrastructure over a typical week

♦ The business hours and days of a week, taking into account the presence of overlaps in business hours and days due to time zone differences between the locations for the forest, and so on

♦ The logical and geographical distribution of the domain controllers within the forest

♦ The maximum replication latency to replicate a change from the domain controller hosting the Schema Master FSMO role, and the most physically remote domain controller (based upon the maximum number of hops in the supporting network infrastructure)

It is possible to verify the successful completion of the “adprep /forestprep” command via execution of the following methods:

♦ Examination of the event log following completion of the command

♦ Execution of a search for the object “CN=Windows2003Update” under the



“CN=ForestUpdates,CN=Configuration,DC=<name_of_forest_root_domain>” object

♦ Examination of the value for the “ObjectVersion” attribute for the Schema object (CN=Schema,CN=Configuration, DC=<name_of_forest_root_domain>), which should be incremented to 30.

It is possible to verify the successful replication of the changes from the /forestprep command to other domain controllers in the forest via execution of the following methods:

♦ At a remote domain controller, execute the above methods to verify the completion of the command, such as the search for the “CN=Windows2003Update” object and the increment to the version of the Schema to 30, via the value for the “ObjectVersion” attribute for the Schema object.

♦ Execute a comparison (using “windiff.exe”) of the export of the Active Directory Schema on a remote domain controller, prior to execution of the /forestprep command, with an export of the Schema from the same remote domain controller after execution of this command. Use the LDIFDE.exe command line tool and following argument to extract the Active Directory Schema: “ldifde -f schema.ldf -d "CN=Schema,CN=Configuration,DC=<name_of_domain>" -o *”. Successful replication of the changes to the Schema should reveal, within the analysis of the two Schema exports, the population of the Schema with new object classes and attributes. The ldif format import files (“SchXX.LDF”, where XX is number 14 to 30) in the %systemroot%\System32 folder detail the object classes and attributes imported into the Schema by the /forestprep command.

Execute an analysis to determine the above information, and the most opportune date and time for execution of the “adprep /forestprep” command, as a pre-migration task for migration path “B”. Pass these design requirements to the later step, “Design for each required migration path”.

• When determining the design requirements for the pre-migration tasks to execute the “adprep /domainprep” command, consider the following:

♦ As for the /forestprep command, the deliverables for the /domainprep command are also not reversible, and hence demands careful planning prior to execution. As the scope for the /domainprep command is defined by the logical boundary of a domain, this hence represents the scope for the replication of changes to the domain.

♦ This design methodology recommends the following approach to determine the design requirements for the execution of the “adprep /domainprep” command, as a pre-migration task for migration path “B”:

Determine the steps necessary to prepare for the execution of this command, such as:

♦ Verification of the completion of all other pre-execution tasks (such as verification of replication of Active Directory throughout the forest, and so on)

♦ The required date and time for execution of this command



♦ Identification of the user account to execute this command, based upon its membership to the Domain Admins group in the domain

♦ Identification of the Windows 2000 domain controller hosting the Infrastructure Master FSMO role

♦ Verification of the successful completion and replication of the results of the results of the “adprep /domainprep” command

It is possible to verify the successful completion of the “adprep /domainprep” command via execution of the following methods:

♦ Examination of the event log following completion of the command

♦ Execution of a search for a new container “CN=Windows2003Update” under the “CN=DomainUpdates,CN=System,DC=<name_of_ domain_where_command_executed>” object

♦ Execution of a search for a new container “CN=Operations, CN=DomainUpdates,CN=System,DC=<name_of_ domain_where_command_executed>”

♦ Execution of a search for a new container “CN=ComPartitions, CN=System,DC=<name_of_ domain_where_command_executed>”, and so on. (See the Microsoft Knowledge Base article “KB309628” for details of the objects created by the /domainprep command).

It is possible to verify the successful replication of the “adprep /domainprep” command to other domain controllers in the domain via execution of the following methods:

♦ At another domain controller in the same domain, execute the above methods to verify the completion of the command, such as the search for the “CN=Windows2003Update”, “CN=Operations”, “CN=ComPartitions” objects, and so on.

♦ Execute a comparison (using “windiff.exe”) of the export of the Active Directory Schema on another domain controller in the same domain, prior to execution of the /domainprep command, with an export of the Schema from the same domain controller after execution of this command. Use the LDIFDE.exe command line tool and following argument to extract the Active Directory Schema: “ldifde -f schema.ldf -d "CN=Schema,CN=Configuration,DC=<name_of_domain>" -o *”. Successful replication of the changes to the Schema should reveal, within the analysis of the two Schema exports, the population of the Schema with new object classes and attributes.

Execute an analysis to determine the above information, and the most opportune date and time for execution of the “adprep /domainprep” command, as a pre-migration task for migration path “B”. Pass these design requirements to the later step, “Design for each required migration path”.

When determining the design requirements for the pre-migration tasks for approach 1 of migration path “B”, consider the following:



The preparatory tasks that require design for execution on a source Windows 2000 domain, to support the execution of approach 1 for migration path “B”, include:

Preparation of a Windows 2000 domain controller for execution of approach 1 of migration path “B”

Execution of an upgrade check on a Windows 2000 domain controller, to identify all upgrade issues, such as amount of free disk space, hardware compatibility, service pack version, presence of unsupported applications, and so on.

Retrieval of all hardware drivers for Windows Server 2003 from the OEM of the server platform for each Windows 2000 domain controllers to be upgraded, and the BIOS and firmware updates for all hardware components.

Procurement and installation of all hardware upgrade components for compliance with the minimum hardware specifications / compatibility with the standard server build for Windows Server 2003 domain controllers

Migration of applications and services off the Windows 2000 domain controller prior to upgrade

Verification of the completion of all prerequisite tasks to the upgrade of an existing Windows 2000 domain controller (Note that pre-migration ends here, with the execution of the in-place upgrade as a “migration” task)

When preparing a Windows 2000 domain controller for execution of approach 1 of migration path “B”, consider the following:

The first execution of approach 1 must run against an appropriate domain controller in the forest root domain for the existing Windows 2000 forest.

Where the execution of approach 1 of migration path “B” is the first instance (to create a new Windows Server 2003 forest), the first Windows 2000 domain controller to be upgraded must:

• Host the Domain Naming Master, as this role will support the creation of the default application directory partitions for DNS in the Active Directory (the ForestDNSZones ADP (DN is: DC=ForestDNSZones,DC=<forest_root_domain_name>) and the DomainDNSZones ADP (DN is: DC=DomainDNSZones,DC=<domain_name>)

• Host the PDC Emulator FSMO roles, as this role will ensure visibility of the enterprise-wide security principals (generated by the /forestprep command) in the access control lists for Active Directory objects

Where the execution of approach 1 of migration path “B” is not the first instance (and will instead upgrade an existing Windows 2000 domain in an existing Windows Server 2003 forest), then the first Windows 2000 domain controller to be upgraded to create a non-root domain must host the PDC Emulator FSMO role. This is to ensure support for the creation of new domain-specific Windows Server 2003 security principals, including inetOrgPerson objects, and so on.

Hence, identification of the target Windows 2000 domain controller for an in-place upgrade, as approach 1 of migration path “B”, relies upon either:

• Identification of an existing Windows 2000 domain controller currently hosting the required FSMO roles, or

• Transfer of the appropriate FSMO roles to the target Windows 2000 domain controller for the in-place upgrade



When executing the upgrade check on the Windows 2000 domain controller, this design methodology recommends the following approach:

On each Windows 2000 domain controller that requires an in-place upgrade to Windows Server 2003, execute the upgrade compatibility check using “winnt32.exe /checkupgradeonly” from the “i386” folder for Windows Server 2003. This tool will perform an inspection of the Windows 2000 domain controller, without running the setup, and generate a report detailing all identified issues.

Typical upgrade issues identified by this check will include the following examples:

• Hard disk issues, such as file system and amount of free disk space on the Windows 2000 domain controller. An in-place upgrade of a Windows 2000 domain controller to Windows Server 2003 is associated with the following free disk space requirements:

♦ A minimum of 2 GB free space on the boot partition of the Windows 2000 domain controller

♦ A minimum of 15-20% of the current size of the ntds.dit database as free disk space on the partitions that hold the ntds.dit and log files

• Other hard disk issues may include incompatibility with the design requirements for the distribution of the Active Directory database and transaction logs on the domain controllers. Where an existing server hardware platform is unable to accommodate more disk drives, there may be a requirement for the procurement of an external disk array and disk array controller.

• Where the boot partition of a Windows 2000 domain controller has less than 2 GB of free disk space, it is necessary to free up space via:

♦ Deletion of unnecessary files and data on the boot partition for the Windows 2000 domain controller

♦ Removal of superfluous applications and services that require hard disk space on the boot partition for the Windows 2000 domain controller

• Hardware issues, such as unsupported hardware components installed within the Windows 2000 domain controller or hardware components for which drivers are not available within Windows Server 2003. In this scenario, it is necessary to contact the OEM for the hardware component(s) to obtain hardware drivers for Windows Server 2003. For example, a RAID controller or fibre-channel controller may require specific drivers for Windows Server 2003. Check the hardware compatibility list (HCL) for Windows Server 2003 on Microsoft’s web site for all identified hardware components on the Windows 2000 domain controller(s).

• Software issues, such as the presence of unsupported software applications installed on the Windows 2000 domain controller. The “i386\COMPDATA” folder on the Windows Server 2003 CD-ROM contains the details of the unsupported applications and hardware devices, and is referenced by the “/checkupgradeonly” tool. Windows Server 2003 does not support the following software:

♦ Microsoft Exchange 5.5 and Exchange 2000

♦ Site Server 3.0 (SP4 and below)



♦ System Management Server 2.0 (SP2 and below)

♦ Proxy Server

• The upgrade compatibility tool may identify Service Pack issues on the Windows 2000 domain controller. All Windows 2000 domain controllers must be running SP2 or later prior to execution of an in-place upgrade to Windows Server 2003.

As the server platform for the Windows 2000 domain controller will eventually be running the Windows Server 2003 operating system, it is necessary to retrieve, where possible, all hardware drivers for the server and its components, for Windows Server 2003. If the OEM for the server platform, or its hardware components, does not provide drivers for Windows Server 2003, then either replace the hardware component or use another server. It is important to also retrieve and implement all the latest BIOS updates for the server platform, and firmware updates for server hardware components, such as the RAID controller, and so on.

When determining the hardware upgrade requirements for the Windows 2000 domain controller of a legacy Windows 2000 domain, this design methodology recommends execution of the following approach:

Analyse the results of the design gap analysis to identify all hardware specification differences between the Windows 2000 domain controller and the minimum hardware specifications for Windows Server 2003 domain controllers.

Identify all hardware components that require upgrade, and procure all upgrade components. Retrieve all firmware upgrades for all new hardware components, even if newly procured, as the components may have resided in the OEM’s / distributor’s warehouse for a long period after manufacture.

Determine the most opportune time to install the hardware upgrades on the domain controller.

Determine the impact of the necessary hardware upgrade(s) on the operation of the Windows 2000 domain controller. Note that this approach requires the server to be up and running as a Windows 2000 domain controller after the hardware upgrades and prior to initiation of the in-place upgrade. Hence, it is important to ensure that the hardware upgrades to the server do not prevent the normal operation of the server. If it is necessary to upgrade a hardware component that will “break” the Windows 2000 operating system and require a re-installation, such as addition / upgrade of CPUs, and so on, then it is necessary to rebuild the Windows 2000 domain controller after the upgrade.

Determine the design requirements for the process to implement the necessary hardware upgrades on the Windows 2000 domain controller, and implement firmware upgrades.

When determining the applications and services that require migration off the Windows 2000 domain controller prior to the execution of the in-place upgrade, this design methodology recommends execution of the following approach:

Certain applications and services currently running on a Windows 2000 domain controller may require removal prior to the in-place upgrade. Where these applications and services currently support business processes, it is necessary to not only remove them from the Windows 2000 domain controller, but also relocate them to another appropriate server in the domain. For example, applications such as Microsoft Exchange 5.5, Microsoft Exchange 2000, and so on, which the Windows Server 2003 operating system does not support.



Determine the applications and services that require migration to another server, and determine the design requirements for a process to execute this migration.

The execution of approach 1 for migration path “B” is associated with the following strict prerequisites:

The completion of the “adprep /forestprep” and “adprep /domainprep” commands, and replication of all changes made by these commands to the Windows 2000 domain.

Installation of Windows 2000 SP2 or later on the target Windows 2000 domain controller for approach 1 of migration path “B”.

When determining the design requirements for the pre-migration tasks for approach 2 of migration path “B”, consider the following:

The preparatory tasks that require design for execution on a source Windows 2000 domain, to support the execution of approach 2 for migration path “B”, include:

Procurement, installation, and configuration of the new server hardware platform and components

Retrieval of all appropriate hardware drivers for Windows Server 2003 from the OEM for the server platform / hardware components, and BIOS and firmware updates for all hardware components

Verification of compliance with all prerequisites for the introduction of a new Windows Server 2003 domain controller into an existing Windows 2000 domain

Build of the new server using Windows Server 2003 and all available service packs, and post-service pack hotfixes (Note that pre-migration ends here, with the execution of the Active Directory Installation Wizard to create the additional Windows Server 2003 domain controller as a “migration” task).

Determine the requirements for the design of the processes to support execution of each of the above steps. For example:

For the procurement, installation, and configuration of the new server hardware, determine the following:

• The model and specifications of the new server(s) that require procurement

• The intended location(s) for the new server(s) within the organisation (server rooms, racks, logical location on network, and so on), and so on

For the retrieval of the drivers and OEM utilities, determine the following:

• The requirements to slipstream the OEM drivers and utilities into the medium used to deliver the standard server build for the Windows Server 2003 domain controllers.

• The required network location for the storage of the drivers and utilities (extract all drivers and utilities from the software packages they ship in, as it is simpler and quicker to access them), and so on.

Using the above information, execute an analysis to determine and document the design requirements for the pre-migration tasks, for each of the two supported approaches, for migration path “B”.

• Factor A20: Determination of the requirements for the use of SIDHistory for one or more of the inter-forest migration paths (“C”, “D”, “F”, and “H”)




Has identified the requirement for the use of one or more of the inter-forest migration paths (“C”, “D”, “F”, and “H”), and

Wishes to determine the requirements for use of SIDHistory or an alternative


Where an organisation has identified the requirement for the migration from one or more source Windows NT 4.0, Windows 2000, or Windows Server 2003 domains to a target Windows 2000 (interim domain) or Windows Server 2003 domain, it must consider the requirements for coexistence between the source and target domains.

Although this step is purely to support coexistence, it has direct implications on the design for the pre-migration, migration, and post-migration tasks for each of the inter-forest migration paths (“C”, “D”, “F”, and “H”), and is hence included in this section, and not in the later step, “determination of the design requirements for a coexistence plan”.

The objective of this step is to assist an organisation in the determination of the requirements for the use of SIDHistory, to facilitate the coexistence phase of the migration project, or the use of alternatives to SIDHistory.

Prior to the determination of the requirements for the design and use of SIDHistory, it is important to note the following facts about SIDHistory:

SIDHistory is a multi-valued attributes associated with migrated security principals in the user and group (security-enabled) object classes. The objective of the SIDHistory attribute is to hold the SID for the migrated security user or group from its source domain. It is then possible for a migrated user or group to present this legacy SID to domain controllers in the source domain, to ensure continued access to resources, upon which the legacy SID receives access permissions. This hence permits seamless access continuity for migrated security principals during the coexistence phase.

SIDHistory, as a multi-valued attribute, can hence support multiple SIDs. For example, a migrated security group object from a source domain can represent the target for security group consolidation. The SIDHistory attribute of the consolidated migrated security group in the target domain receives the SID for each consolidated security group in the source domain. The consolidated security group, with multiple SIDs in its SIDHistory attribute may hence access all resources in the source domain to which each consolidated security group previously received access. SIDHistory is hence a very powerful tool that requires careful use.

Note that the migration of SIDs from a source domain is applicable to both intra-forest and inter-forest migration paths. However, it is only necessary to design and execute extensive pre-migration tasks, to prepare a source and target domain, for inter-forest migration paths that require the use of SIDHistory. This is because ADMT version 2.0 automatically retains SIDHistory for all intra-forest migration tasks. Hence, this step will only consider the design and use of SIDHistory for the inter-forest migration paths.

The use of the SID(s) in the SIDHistory attribute relies upon the continued presence of the source domain and its domain controllers. Decommissioning of the source domain hence invalidates all SIDs stored in the SIDHistory attributes for migrated user and security group principals.

When determining the requirements for the design and use of SIDHistory for one or more inter-forest migration paths, consider the following:



This design methodology proposes execution of the following approach to assist an organisation in determination of the requirements for the design and use of SIDHistory:

Understand the prerequisites for the use of SIDHistory

Understand the advantages and disadvantages associated with the design and use of SIDHistory

Understand the alternatives to the use of SIDHistory during the coexistence phase between a source and legacy domain

Use the above information to determine the requirements for the design and use of SIDHistory, or an alternative.

The design and use of SIDHistory requires compliance the following prerequisites:

There is a requirement for the design, implementation, and support of a coexistence phase between the source and target domains, and the requirement to support the continued access to resources in the source domain by migrated user accounts in the target domain.

Where the target domain is a Windows 2000 domain, it must be operating in “Windows 2000 Native” mode (for example, for inter-forest migration path “H”)

There is a bi-directional trust relationship between the source and target domains, with SID filtering disabled on the outgoing trust from the target domain

Where the target domain is a Windows Server 2003 domain, it must be raised to either the “Windows 2000 Native” or “Windows Server 2003” domain functional level (for example, for inter-forest migration paths “C”, “D” and “F”)

There are specific pre-migration preparatory tasks that require design and execution on both the source and target domains to support the migration of SIDs to the SIDHistory attribute of migrated security principals. See the later factors in this step for details of these pre-migration tasks for the inter-forest migration paths “C”, “D”, “F”, and “H”.

There are specific migration tasks that require design and execution to support the migration of SIDs to the SIDHistory attribute of migrated security principals. See the later step “determination for the design requirements for the migration tasks” for details of these migration tasks for the inter-forest migration paths “C”, “D”, “F”, and “H”.

There are specific post-migration tasks that require design and execution to support the migration of SIDs to the SIDHistory attribute of migrated security principals. See the later step “determination for the design requirements for the post-migration tasks” for details of these migration tasks for the inter-forest migration paths “C”, “D”, “F”, and “H”.

The design and use of SIDHistory is associated with the following advantages:

The use of the SIDHistory attribute provides seamless access to legacy resources by migrated security principals during the coexistence phase, with minimal requirements for intervention by administrators in the source and target domains.

The use of the SIDHistory attribute supports the consolidation of security principals from the source to the target domain, without compromising continued access to resources in the source domain.



The design and use of SIDHistory is associated with the following disadvantages:

The use of the SIDHistory attribute requires extensive design and execution of pre-migration, migration, and post-migration tasks.

Compliance with the prerequisite to disable SID filtering on an incoming external trust relationship for a source domain, to the target domain, reduces the security level of the source domain. Source Windows 2000 or Windows Server 2003 domains supported by Windows 2000 SP4 or Windows Server 2003 domain controllers, respectively, enable SID filtering on all incoming external trust relationships. Source Windows NT 4.0 domains, supported by Windows NT 4.0 SP4 domain controllers are able to enable SID filtering manually on external incoming trust relationships. SID filtering on an incoming external trust relationship effectively blocks access to resources in the source domain to users presenting a SID in their SIDHistory attribute, as it is simple to “spoof” a well-known or highly provisioned SID valid in the source domain.

Compliance with the prerequisite to raise the domain mode or functional level of the target domain eliminates support for legacy Windows NT 4.0 BDCs in the target domain. This is obviously only a disadvantage where there is a business or technical requirement for the continued support for these legacy domain controllers in the target domain, to support (for example) legacy LOB applications and services.

The domain migration tool, ADMT version 2.0, supports the design and implementation of a viable two-step alternative to the use of SIDHistory, using the “Security Translation Wizard” within ADMT 2.0. The two-steps in the use of this approach are:

The first step of this alternative approach is to run the “Security Translation Wizard”, after the initial migration of all security groups and user account objects and without migration of the legacy SID, against all member servers in the source domain. It is possible to first configure this wizard to perform an “Add” security translation on all appropriate resources in the source domain. The wizard will instruct and dispatch the ADMT agent to the targeted member servers in the and perform the following actions:

• Using the details of the migrated security principals from the source domain (held in the ADMT “protar.mdb” database) the agent will search all objects and resources in the source domain for all instances of the ACEs representing the original migrated users and groups.

• When it finds an ACE on a DACL corresponding to a migrated security principal, it will, in “add” mode, copy the permissions on the ACE for the original security principal, add the migrated security principal to the DACL as an ACE, and assign it the same permissions as the original security principal. This process effectively ensures continued access to the resources in the source domain, to the same original level as the original security principals.

Following completion of all migration activities, and preparation of the source domain for decommissioning, it is necessary to execute the second step of this alternative approach. This involves re-execution of the “Security Translation Wizard” within ADMT 2.0, but this time in “Remove” mode and against the member servers migrated to the target domain. This mode will remove all instances of the original SIDs in the DACLs on resources, on servers now migrated to the target domain.

The design and use of this approach requires compliance with the following prerequisites:



The ADMT agent can only operate on target Windows NT 4.0, Windows 2000, Windows XP Professional, and Windows Server 2003 operating systems

Use of the Security Translation Wizard and the ADMT agent requires administrative rights on all targeted computers in the source domain, and once migrated to the target domain

The design and use of this approach is associated with the following advantages:

This approach requires minimal design and execution of specific pre-migration tasks to prepare a source and target domain

This approach requires minimal design and execution of specific migration and post-migration tasks

This approach does not compromise the security of the target domain, as the first-step is a pure duplication of existing ACEs on existing DACLs and does not modify the DACLs in any other manner. There is hence no disruption to the continuity of the source domain.

This approach hence does not require a source domain to disable SID filtering on the incoming external trust relationship with the target domain

The design and use of this approach is associated with the following disadvantages:

The execution of the first and second steps can take significant time to execute where it is possible to identify a significant number of target servers in a source domain, and resources that require security translation.

The execution of the first step, to “add” permissions may increase the size of the DACLs on resources.

Following consideration of all of the above information on SIDHistory and a viable alternative, and when determining the requirements for the design and use of SIDHistory, consider the following:

This design methodology proposes execution of the following approach to determine the requirements for the design and use of SIDHistory for one or more inter-forest migration paths:

Determine compliance with all of the stated prerequisites to the use of SIDHistory. If it is not possible to identify compliance with the prerequisites, or the organisation finds it unacceptable to ensure compliance with these prerequisites, it is necessary to consider the alternative approach.

Where it is possible and acceptable to ensure compliance with the design and use of SIDHistory, then ensure reflection of this requirement in the design for the pre-migration, migration, and post-migration tasks for the required inter-forest migration paths.

Using the above information and approach, execute an analysis to determine and document the requirements for the use of SIDHistory for these migration paths.

• Factor A21: Determination of the requirements for the preservation of closed “user” and “resource” sets using intra-forest migration paths “E” or “G”




Has identified the requirement for the intra-forest migration of one or more Windows 2000 or Windows Server 2003 domains using optional migration paths “E” or “G”, and

Wishes to determine the requirements for the preservation of closed “user” and “resource” sets using intra-forest migration paths “E” or “G”


Prior to executing this factor, review the background information section for details on the concepts of closed and open sets.

The objective of this step is to determine the requirements and opportunities to preserve closed “user” and “resource” sets during the execution of the intra-forest migration paths “E” and / or “G”.

If it is possible to identify the requirement to preserve closed “user” and “resource” sets, it is hence necessary to determine the design requirements for the pre-migration, migration, and post-migration tasks for migration paths “E” and “G”, to support this requirement. The later factors in the step and process will assist an organisation in the determination of the design requirements for these tasks to preserve closed sets.

This design methodology proposes execution of the following approach to determine the requirements for the preservation of closed “user” and “resource” sets:

Understand why it is necessary to preserve, where possible, closed “user” and “resource” sets during intra-forest migration

Understand the concepts of “temporarily broken” and “permanently broken” closed “user” and “resource” sets

Understand the factors that can prevent the preservation of closed “user” and “resource” sets before and during intra-forest migration

Understand the opportunities to preserve closed “user” and “resource” sets prior to execution of an intra-forest migration

Determine the requirements for the preservation of closed “user” and “resource” before and during intra-forest migration

As discussed in the background information section of this process, the preservation of closed “user” and “resource” sets is vital to ensure no disruption to business continuity during the migration phase.

For the intra-forest migration paths, it is more imperative to attempt to preserve closed “user” and “resource” sets because it is possible to create closed sets that span multiple domains within a forest. Inter-forest migrations cannot preserve closed sets, as there is no support for their preservation across external trust relationships.

As discussed in the background information section of this process, the “breaking” of a closed set creates an open set, which does not provide the same level of productivity as a closed set. This design methodology recognises that it is possible to break a closed set temporarily or permanently. A temporarily broken closed set implies that the temporary open set will “heal” to become a closed set once again, following the completion of subsequent migrations (see the background information section for more information on “healing” broken closed sets).

A permanently broken closed set hence implies that it is not possible to heal this closed set, and there is a permanent reduction in the functionality associated with the previously closed set.



It is possible to break a closed set temporarily via the phased migration of members of the closed set between domains within a forest. Completion of all intra-forest migrations (to the same target domain) will heal the closed set.

For example, an organisation has partitioned a source domain into “user”, “server”, and “logical” partitions (see step “determination of the design requirements for the migration tasks” for details of source domain partitioning) to support a phased migration. The organisation will execute an independent migration of a “user” partition (containing just user and computer account objects) to the migration of a “logical” partition (containing security group objects), and this will hence temporarily break any closed “user” sets, until all objects in the closed “user” set are together in the same target domain.

It is possible to break a closed set permanently if, for example, a source domain represents the source for one domain in the same forest and one or more other domains in a separate forest. The subsequent distribution of the objects across multiple target domains and forests will hence permanently separate the objects and thus may permanently break any closed sets from the source domain.

When attempting to understand the factors that can influence the preservation of closed “user” and “resource” sets, consider the following:

Any factors that can permanently break a closed “user” or “resource” set will naturally influence the ability to preserve the closed sets, such as:

The example illustrated above where a single source domain is the source for one domain in the same forest and one or more other domains in a separate forest.

If it is possible to identify any closed sets where members of the sets are outside of the scope of migration to a target domain, this will permanently break the closed set. For example, the out-of-scope security principals for a closed “user” set may be:

• Well-known security principals (such as built-in security groups like the Administrators, Users, Power Users, Domain Admins, Domain Users, and so on) and hence cannot be migrated to a target domain. Note that although this may permanently break a closed “user” set, it is possible to prepare a source domain to rectify this and hence preserve closed “user” sets. See the following later factors for details of the design requirements for the pre-migration tasks (to prepare the source domains for the preservation of closed sets):

♦ “Determination of the design requirements for the pre-migration tasks to prepare one or more source Windows 2000 domains for the execution of migration paths “D”, “G”, or “H” and

♦ “Determination of the design requirements for the pre-migration tasks to prepare one or more source Windows Server 2003 domains for execution of migration paths “E” and / or “F”

• Identified earlier as been “actually” or “potentially” redundant objects and hence within the scope of the pre-migration directory clean up tasks for a source domain.

Any factors that may temporarily break a closed “user” or “resource” set will influence the ability to preserve the closed sets, such as:

The example illustrated above where an organisation wishes to execute a phased migration of objects, via “user”, “server”, and “logical” partitions (see later for details)



The current domain mode / domain functional level of the source and target domains will influence the automatic preservation of closed sets by ADMT. For example, if the source and target domains are not at the minimum of “Windows 2000 Native” (domain mode for source Windows 2000 domains, and domain functional level for source Windows Server 2003 domains), then ADMT cannot automatically convert Global group objects in the source domain into Universal security groups to preserve a closed “user” set. Note that where it is possible to identify that the source and target domains are not operating at the minimum domain mode / functional level of “Windows 2000 Native”, then this does not prevent the preservation of closed sets during intra-forest migration. However, it does increase the number of migration tasks necessary to preserve closed sets. See the step “determination of the design requirements for the migration tasks” for details.

A factor that may influence the opportunity for an organisation to preserve closed sets during migration is the requirement to minimise any impact on Global Catalog replication within the forest. The automatic conversion of Global security groups within a closed “user” set to Universal security groups by ADMT, and the manual conversion of Domain Local security groups to Universal security groups (to preserve closed “resource” sets) will result in the publication of the membership of these Universal groups to the Global Catalog for the forest. Where these Global and Domain Local security groups, prior to conversion to Universal groups, support many hundreds or even thousands of members, then this may generate a significant impact on the replication of the Global Catalog to GC servers within the forest.

Note however that the requirement to convert the Global and Domain Local security groups into Universal security groups, to preserve closed “user” and “resource” sets, is a temporary requirement. Where ADMT is responsible for the automatic conversion of Global security groups into Universal security groups, upon completion of the closed set in the target domain, it will automatically re-convert the “new” Universal security groups back into Global security groups in the target domain. As the conversion of Domain Local groups into Universal groups is a manual process (ADMT will not perform this conversion) to preserve closed “resource” sets, it is necessary to manually re-convert these “new” Universal security groups back into Global security groups following their migration to the target domain.

Using the above information, determine and document the requirements to preserve closed sets during the execution of intra-forest migration paths. Where it is possible to identify this requirement, then it is necessary to determine and document the design requirements for the execution of specific pre-migration, migration, and post-migration tasks to preserve closed “user” and “resource” sets.

• Factor A22: Determination of the design requirements for pre-migration tasks to prepare one or more source Windows NT 4.0 domains for the execution of domain migration path “C”


Has identified the requirement for the migration of one or more legacy Windows NT 4.0 domains using simple migration path “C”, and

Wishes to determine the design requirements for pre-migration tasks to prepare one or more source Windows NT 4.0 domains for the execution of migration path “C”


The execution of migration path “C” involves the migration of directory objects and data from a legacy Windows NT 4.0 domain to a target Windows Server 2003 domain.



The objective of this step is to determine all of the design requirements for the pre-migration tasks necessary to prepare a source Windows NT 4.0 domain for execution of migration path “C”.

Note that this step does not consider the requirements for contingency or coexistence. The later steps within this process, “determination of the design requirements for a contingency plan” and “determination of the design requirements for a coexistence plan”, consider all of the design requirements for the preparatory tasks to support a rollback of an existing Windows NT 4.0 domain environment, and for continued coexistence during the migration phase.


As it is possible to identify a significant number of additional tasks for execution within migration path “C”, the later step within this process (“generation of the design for the migration checklists”) will provide a few examples of pre-migration tasks associated with each migration path, which do not require design for execution.

When determining the design requirements for the pre-migration tasks for migration path “C”, to prepare a source Windows NT 4.0 domain for migration of directory objects and data, consider the following:

Note that the source (Windows NT 4.0) and target (Windows Server 2003) domains share the majority of preparatory tasks for migration path “C”. However, the source domain does have a few additional preparatory tasks, outlined below.

The preparatory tasks that require design for execution on a source Windows NT 4.0 domain, to support the execution of migration path “C”, include the following:

Selection of the migration product to execute migration path “C”

Understanding the migration path requirements (from the predefined business and technical migration goals) that will influence the design of migration path “C”, and hence the pre-migration, migration, and post-migration tasks.

Preparation of a source Windows NT 4.0 domain to support execution of migration path “C”

Preparation of the network infrastructure to support execution of migration path “C”

Preparation of existing Windows NT 4.0 domain controllers to support execution of migration path “C”

Preparation of security principals to support execution of migration path “C”

Preparation of member computers in source domain for migration, security translation, and service account transition

When selecting the required migration tool / tool suite to support the execution of migration path “C”, consider the following:

In addition to the free domain migration utility provided by Microsoft, Active Directory Migration Tool (ADMT) version 2.0, it is possible to identify a number of other third party proprietary tools and application suites that support migration path “C”. These other products essentially perform the same function as ADMT, but with many additional or enhanced features and capabilities.



This design methodology will focus on the design and use of ADMT version 2.0 to execute migration path “C” (and all other domain migration paths supported by this design methodology). This design methodology will not provide the considerations for the selection of a domain migration tool, as the onus is on the organisation to perform their own investigations.

Determination of the design requirements for pre-migration tasks, to prepare a source domain for execution of migration path “C”, depends upon the migration requirements for this path and legacy Windows NT 4.0 domain.

The predefined business and technical migration goals will define the migration requirements for this path, and identify, for example, the requirements for the following:

The requirements for the continued support of access to non-migrated resources in the source domain by migrated security principals in the target domain, during the coexistence phase of this project. Both the use of the “SIDHistory” attribute of migrated security principal objects within a Windows Server 2003 domain, or the ADMT version 2.0 Security Translation Wizard support these requirements, where identified.

The requirements for the migration of user account passwords from the source Windows NT 4.0 domain to the target Windows Server 2003 domain. ADMT version 2.0 supports the migration of user account passwords from a source Windows NT 4.0, Windows 2000, or Windows Server 2003 domain to a target Windows 2000 or Windows Server 2003 domain.

The requirements for the renaming of user, computer, and group accounts, to permit distinction from existing account objects, or compliance with new object naming conventions. ADMT version 2.0 will support the renaming of account objects via the addition of a suffix or prefix to the migrated objects.

The requirements for the translation of security on resources migrated with computers from the source domain to the target domain. ADMT version 2.0 supports the translation of access control lists to replace, add, or remove ACEs, via the dispatch of agents to computers been migrated.

The requirements for the migration of security groups to support the consolidation of multiple Windows NT 4.0 security groups to a few number of Windows Server 2003 security groups. ADMT version 2.0 supports the consolidation of security groups in a legacy Windows NT 4.0 domain with groups in a target Windows Server 2003 domain.

When determining the migration requirements for the execution of migration path “C”, execute the following approach:

Analyse the predefined business and technical migration goals that influence the design of the required migration paths.

Identify all goals that will influence the design for the execution of migration path “C”, and each in-scope source Windows NT 4.0 domain(s) required to use migration path “C”.

Note that this design methodology will assume that all of the requirements for the migration of a legacy Windows NT 4.0 domain using migration path “C”, outlined above, are required, and will hence provide support as appropriate.

When determining the design requirements for pre-migration tasks to prepare a source domain for execution of migration path “C”, consider the following:

The preparatory tasks that require design to prepare a source domain for migration path “C” include the following:



The preparation of a source domain for the use of migration of legacy SIDs and the use of SIDHistory, where an organisation has identified this requirement

The preparation of a source domain for the migration of passwords for user accounts

The preparation (from the perspective of the source domain) of bi-directional trust relationships between the source and target domains to support the execution of migration path “C”

When determining the design requirements for the pre-migration tasks, for migration path “C”, to prepare a source Windows NT 4.0 domain for SIDHistory, consider the following:

The migration of SIDs for Windows NT 4.0 user and security group account objects requires the execution of the following tasks within the source Windows NT 4.0 domain:

• Enable auditing of user and group management, for both success and failure events.

• Create a local security group in the domain named “<Name_of_Source_Domain>$$$”. For example, within a Windows NT 4.0 domain, with a NetBIOS domain name of “Domain1”, a Domain Administrator is required to create a local security group named “Domain1$$$”.

• Clean up of permissions on resources assigned to security principals in the source domain

When determining the design requirements for the process to enable the auditing of user and group management within a source Windows NT 4.0 domain, consider the following:

• With auditing of user and group management enabled, this will generate entries in the Security Event Log on the domain controllers within the source domain. It is hence important to adjust the following parameters on the security event logs on the appropriate Windows NT 4.0 domain controller(s) in the source domain and, where password migration is required, the nominated “password export server” (a BDC in the source domain):

♦ The size of the security event log, in KB (the required size of the event log will depend upon the number of user and group objects within the source domain and within the scope of migration path “C”. The size of the log depends also upon the selected Event Log Wrapping parameter (see below). Where there is a requirement for the recommended option, to clear the even log manually, set the size of the log to be quite large, such as a few tens of MB. A small sized security event log, with a “clear log manually” option, will fill up quite quickly, and the domain controller may cease to function until an administrator clears the security event log. This may hence disrupt the migration process).

♦ The Event Log Wrapping parameters, to select one of the following appropriate settings:

Overwrite events as needed (this option is not recommended)

Overwrite events older than <number of days>

Do not overwrite events (clear log manually) (this option is recommended)



• Note that the Security Log Settings on the primary domain controller (PDC) and BDC default to "Maximum log size of 512 Kilobytes" and the Event Log Wrapping setting defaults to "Overwrite Events Older than 7 Days."

• This design methodology recommends that a Domain Administrator only enable the auditing of user and group management immediately prior to execution of migration path “C”, unless already enabled within a source Windows NT 4.0 domain. The enabling of auditing on user and group management can generate a significant impact on the performance of a Windows NT 4.0 domain controller, required to audit significant numbers of user and group management events.

When creating the “DomainName$$$” local security group, consider the following:

• If a Global or other security group already exists within the source Windows NT 4.0 domain with this name, it is necessary to either delete or rename these existing groups, prior to creation of this group.

• Although ADMT version 2.0 will create this group if it detects its absence in the source domain (for example, during a trial run), this design methodology recommends the manual creation of this group to allow control over the handling of any group naming conflicts, and so on.

• This group should have no security principals as members, and not be assigned any rights or permissions, and so on.

When determining the design requirements for the clean up of permissions on domain resources, assigned to security principals within the source domain, consider the following:

• ADMT version 2.0 will only clone the following directory objects from a source Windows NT 4.0 or Windows 2000 domain:

♦ User account objects

♦ Computer account objects

♦ Custom security-enabled group objects, including:

Local groups (but for Windows NT 4.0 domains, only the shared local groups on a domain controller can be migrated)

Domain local groups (for Windows 2000 and Windows Server 2003 domains operating in native mode)

Global groups

• ADMT version 2.0 will not clone the following directory objects:

♦ Built-in security principals, such as the “Administrators”, “Power Users”, “Users” and “Domain Users” groups, and so on, as these have “well known SIDs”.

♦ Source domain directory objects which have the same SID in the target domain, as the primary SID or SID within the SIDHistory attribute

• Because ADMT will not clone built-in groups and security principals to a target domain, these objects will not exist in the target domain with their existing SID. Hence, membership to built-in groups, granted permissions on



resources in the source domain, denies access to those resources for all users of those groups now migrated to the target domain. For example, within a source Windows NT 4.0 domain, a resource owner grants read and write access to shares and files on a file server to the “Domain Users” built-in Global security group. Users in the domain only gain access to these resources via membership to this group. As this group is a built-in group, ADMT will not clone it to the target domain, and as a result, the migrated users no longer gain access to the resources controlled by the “Domain Users” group in the source domain. This can generate significant disruptions to the productivity of users migrated from the source domain to the target Windows Server 2003 domain.

• Where it is possible to identify this very common scenario, this design methodology proposes the following two resolution options:

♦ The first option is to use the ADMT security translation wizard and a custom SID mapping file, when executing the migration of the computers with their resources to the target domain, to translate the security settings. Note that many other proprietary tools exist that can also perform this function, and some are components of migration suites.

♦ The second option is to change the access control entries manually on all resources within the domain that assign access permissions to built-in groups.

• Although the first option may seem the preferred option, it is possible to identify common scenarios where this is not a feasible option. For example, a Windows NT 4.0 domain for an autonomous division represents the source domain for migration path “C”, and the target domain is a single Windows Server 2003 domain owned by the parent organisation. Currently, the autonomous division controls access to resources within the source domain via NTFS permissions assigned to built-in groups, such as the Domain Users group. The autonomous division is reluctant to exercise option 1, as this would hence permit all users in the target domain, including the users from the parent organisation, to access their resources, and hence deems this a security breach. However, the use of a custom SID mapping file can circumvent this security breach (see later for details on the design of a custom SID mapping file).

• Selection and execution of the second option is a significant undertaking that should not be underestimated. Even small organisations, with only a few tens or hundreds of users, will have a considerable number of resources controlled by their source domain, and the process to identify the appropriate resources and then “re-acl” them may be extremely complex and lengthy.

• Where it is possible to identify this common scenario, then determine the required option, and the design requirements for the process to execute the required option. Where there is a requirement for the design and use of the first option and the a custom SID mapping file, then see a later section of this factor (preparation of member computers for migration) for details on the design of a SID mapping file.

When determining the design requirements for the pre-migration tasks, for migration path “C”, to prepare a source Windows NT 4.0 domain for migration of passwords for user accounts, consider the following:

The migration of user passwords, by ADMT version 2.0, requires that the password policies in the source domain match those in the target Windows Server 2003 domain. If the migrated passwords do not meet the requirements of the password policy in the target Windows Server 2003 domain, this will not



prevent the migrated users from logging onto the Windows Server 2003 domain. However, it will be necessary for all affected users to change their passwords immediately at logon, to a password that complies with the policy in the target domain.

When determining the design requirements for a process or strategy to prepare a source domain for the migration of user passwords, this design methodology proposes execution of the following approach:

• Analyse the design summary for the target Windows Server 2003 Active Directory domain, and identify the following:

♦ The final destination OU(s) for the migrated user account objects

♦ The final password policy or policies that will be applied to the user accounts once in their final destination OU(s) in the target Windows Server 2003 domain

• Analyse the results of the design summary for the source Windows NT 4.0 domain and perform a gap analysis of the password policies to identify the design differences.

• Where it is not possible to identify any design differences, then proceed to the next step. However, where it is possible to identify differences in the password policies for the source and target domain and OU(s), then this design methodology proposes three options to address this scenario:

♦ The first option is to implement the new (Windows Server 2003 Active Directory) password policy in the source Windows NT 4.0 domain. Respecting the default differences in password policy capabilities of these two directory service infrastructures, it is only necessary to port the policy that controls the minimum password length. This is because Windows NT 4.0 does not (by default) support policies for password complexity, or the storage of passwords in reversible encryption, and differences in password age and history will not require users to change their password on first logon. This option will hence ensure that the passwords for all user accounts, prior to execution of the migration, meet the minimum password length policy in the target domain and OU infrastructure. Note that SP2 for Windows NT 4.0 supports the optional implementation of “strong password functionality”, using the “password filter” (as “passfilt.dll”). See the Microsoft Knowledge Base article “KB161990” for details. Where it is possible to identify the implementation of the password filter in a source domain, then this corresponds with the Windows 2000 and Windows Server 2003 password policy “passwords must meet complexity requirements”, and hence the requirement to match any design requirements for the use of this policy. The Windows NT 4.0 SP2 password filter implements a password policy where passwords must meet all of the following minimum requirements:

The passwords must be a minimum of six (6) characters long.

The passwords must contain characters from at least three (3) of the following four (4) classes:

♦ English upper case letters, such as A, “B”, “C”, ... Z

♦ English lower case letters, such as a, b, c, ... z

♦ Westernized Arabic numerals, such as 0, 1, 2, ... 9



♦ Non-alphanumeric ("special”) characters, such as punctuation symbols

The passwords must not contain the user name or any part of the full name of the user.

Note that the Windows NT 4.0 SP2 password filter only filters and operates against password change requests. The password filter does not operate against any changes to passwords executed using “User Manager for Domains”, and hence an Administrator may manually set a non-compliant password for a user account.

♦ The second option is to implement the “migration object and resource management infrastructure (ORMI) strategy” devised by this design methodology. This strategy involves the generation of a temporary ORMI within each target Windows Server 2003 domain, to provide the temporary destination OUs, GPOs and DOC permissions for all migrated directory objects from one or more source Windows NT 4.0 and / or Windows 2000 domains. The “migration ORMI” will provide the required segregation of these migrated directory objects from the rest of the domain, but still support their presence within the target domain, and use of the target domain to log on and so on. The “migration ORMI” hence provides an alternative to the first option for matching password policies because all Windows Server 2003 Active Directory GPOs support the implementation of password policies, and not just the “Default Domain Policy” GPO implemented at the root of a domain (as in Windows 2000 Active Directory). Hence, the OU infrastructure within the “migration ORMI” could support, via “block inheritance” where necessary, one or more temporary GPOs that provide the same password policy settings in the source Windows NT 4.0 domain(s) for the migrated user accounts. Hence, a user account migrated into the “migration ORMI” in the target Windows Server 2003 domain, will receive the same password policy as the source Windows NT 4.0 domain. Thus, when a user logs on with that account, there is no requirement to change their password at first logon.

♦ The third option is to do nothing and force all migrated users to change their passwords at first logon after migration.

• When determining the requirements for the selection and design of option 1 outlined above, consider the following:

♦ This design methodology deems that the selection and execution of option 1 is only feasible where it is possible to identify compliance with the following example criteria (the onus is on the organisation to define their own criteria):

The source Windows NT 4.0 domain contains only a small number of user accounts (such as a few hundred or less). This option is not feasible for a source Windows NT 4.0 domain supporting a large number of users and a requirement to implement a maximum password age policy of only a few days. This is because as soon as the passwords for a large number of users expire, it will be necessary for all such users to change their passwords, for example, simultaneously at 9am on Monday morning, which would generate a significant disruption to the performance of the BDCs for the domain.

The IT administration culture within the organisation, generated by the IT administration team, supports the execution of a significant change to the working habits of users within a short period, without generation



of excessive complaints or queries. Within organisations where such changes meet strong resistance, this option is not feasible.

♦ Where it is not possible to identify compliance with any criteria to prevent the selection of option 1, then determine the following:

The approximate numbers of password changes generated daily, to respect a current minimum password age policy

The most opportune time to implement the change in the password policy for a source Windows NT 4.0 domain based upon this information.


♦ The design and implementation of a temporary “migration ORMI”, supported by option 2 supports the segregation of migrated directory objects, and supports the coexistence of the source and target domains during the migration phase. For example, multiple remote source domains are to be migrated, via migration path “C”, into a single Windows Server 2003 domain, centrally managed by the organisation. To support remote administrators of the source domain in managing the migrated users (until the source domain is decommissioned) the “migration ORMI” could support delegation of control for object management to these remote administrators for the duration of the coexistence phase. After all migrations are completed, and the source domains decommissioned, the migrated objects can be moved to their final destination ORMI(s) (and hence OU(s)) within the target domain and hence, where required, outside of the scope of management of the remote administrators. The phased “re-migration” of migrated users out of the “migration ORMI” to their final destination ORMI(s) will permit these users to receive their intended password policies, and other GPO policies and settings defined within their final destination ORMI(s).

♦ This option is suitable for scenarios where a single or few Windows Server 2003 domains will be the target for migration paths “C” and / or “D”, and will eventually support the migration of a large number of security principals from legacy Windows NT 4.0 and / or Windows 2000 domains.

♦ This design methodology recommends option 2 where possible. Where there is a requirement for the use of option 2 and the “migration ORMI”, see the step “determination of the specific pre-migration tasks to prepare a target domain” for details on determination of the design requirements for a “migration ORMI”. A migration “ORMI” can support the simple migration paths “C” and “D”, and even the optional migration paths “E”, “F”, “G”, and “H”.

• When determining the requirements for the selection and design of option 3 (the “do nothing option”) outlined above, consider the following:

♦ This design methodology does not recommend the selection of this option where it is possible to identify compliance with the following criteria:

The target Windows Server 2003 domain is the target for the migration of security principals from two or more source domains (as part of a domain consolidation approach).

The target Windows Server 2003 domain will receive a large number of migrated security principals that may all require a change in password.



As all password changes in Windows Server 2003 domains focus on the domain controller hosting the PDC Emulator FSMO role, this single domain controller may be subjected to a significantly increased workload.

♦ The selection of this option would force all migrated users to change their passwords at first logon. The enabling of all migrated user accounts and the requirement to permit all users to logon simultaneously using their Active Directory accounts, may disrupt the continuity of the Windows Server 2003 domain controller hosting the PDC Emulator FSMO role. Hence, this design methodology does not recommend the selection of option 3.

When determining the design requirements to establish the trust relationship between the source Windows NT 4.0 and target Windows Server 2003 domain, consider the following:

To support execution of migration path “C”, it is necessary to establish a minimum of a mono-directional trust relationship between the source and target domains, where the source domain trusts the target domain. However, where there is a requirement for coexistence between the two domains during the migration project, then it is necessary to establish bi-directional trust relationships between the source and target domains.

The objectives of the trust relationships are hence:

• To support the execution of migration path “C”, and

• To support the coexistence phase between the source and target domains during the migration project

In most organisations, the trust relationships will hence seem a permanent feature of the new Windows Server 2003 domain, until it is possible to decommission the source Windows NT 4.0 domain.

From the perspective of the source domain, it is necessary to trust the target Windows Server 2003 domain, to support:

• Access to the source domain and SAM database by the designated administrator performing the migration to the target domain, and

• Access to non-migrated resources in the source domain by migrated users in the target domain

Where there is a requirement to permit the continued administration of migrated users by administrators from the source domain, via (for example) temporary delegation of control permission within a “migration ORMI”), then the target domain must trust the source domain.

Note that it is important ensure that where the PDC for the source domain is operating SP4 or later, and there is a requirement to support the use of SIDHistory by migrated security principals, then the Domain Administrator does not enable SID filtering on the external trust with the target domain. Enabling SID filtering on an external trust will effectively prevent authentication via the use of SIDs within the SIDHistory attribute for a migrated security principal.

When determining the design requirements for the pre-migration tasks to prepare the network infrastructure to support execution of migration path “C”, consider the following:



The preparatory tasks that require design to prepare the network infrastructure (which supports both the source and target domains) for migration path “C” include the following:

The preparation of the name resolution infrastructure to support execution of migration path “C” and coexistence between the source and target domains

The preparation of components of the supporting network infrastructure to permit execution of migration path “C”

The determination of timescales and dependencies associated with parallel projects for the supporting network infrastructure, such as pending network upgrades or projects to redesign the TCP/IP network protocol, and so on.

When determining the design requirements for the preparation of the name resolution infrastructure within the organisation, to support execution of the migration path “C” and coexistence of the source and target domains, consider the following:

Where there is a requirement for coexistence between the source and target domains, then the migrated security principals in the target Windows Server 2003 will require access to the source domain, and all domains that trust the source domain. This hence implies the requirement for the migration of all existing trust-relationships, between the source domain and all other domains that trust the source domain, to the target domain and these external domains. For example, a source Windows NT 4.0 domain, “Domain1” has a trust relationship with another Windows NT 4.0 domain, “Domain2”, which trusts “Domain1”, and hence permits security principals from “Domain1” to access its resources. “Domain1” is the source domain for migration path “C” to a target Windows Server 2003 domain “Domain3”. To support continued access for users in “Domain3”, migrated from “Domain1”, to resources in “Domain2”, it is necessary for “Domain2” to trust “Domain3”. This will hence permit migrated users, using their SIDHistory (SIDs from “Domain 1”) to access resources in “Domain2”. The name resolution infrastructure is hence required to support name resolution between the target Windows Server 2003 domain and other non-source domains for a specific execution instance of migration path “C”.

To support the execution of migration path “C”, the Windows Server 2003 domain controllers in the target domain must be able to locate the source domain and its domain controllers, and vice versa. Windows NT 4.0 domains typically use WINS exclusively for name resolution, where as Windows Server 2003 domains use DNS.

This design methodology proposes the following approach to support these name resolution requirements:

• The first step involves execution of the following:

♦ Addition of the IP address for the DNS server, supporting the target Windows Server 2003 domain, to the TCP/IP protocol stack for the Windows NT 4.0 domain controllers in the source domain, and

♦ Configuration of the TCP/IP protocol stack on the Windows NT 4.0 domain controllers in the source domain with the DNS domain name for the source domain, and selection of the checkbox in the “WINS Address” tabbed page to “Enable DNS for Windows Resolution”

• The second step involves execution of one of two of the following options:



♦ The first option requires the creation of a Windows Server 2003 WINS server in the target domain, configuration of the Windows Server 2003 domain controllers to use this WINS server, and configuration of this WINS server to be a pull replication partner for the WINS server supporting the source domain.

♦ The second option requires the creation of a DNS zone (using the DNS domain name for the source domain) on the DNS server supporting the target Windows Server 2003 domain, and configuration of this zone to use WINS lookup, pointing to the WINS server supporting the source domain.

The selection of the first option in the second step is suitable where, for example, a single Windows Server 2003 domain is to be the target domain for multiple source Windows NT 4.0 domains. The configuration of pull replication of this server with multiple WINS servers, collectively representing all of the source domains, generates a consolidated view of all source domains, domain controllers, and member computers.

The selection of the second option in the second step is suitable where, for example, the DNS server used has the role of an internal root DNS server, and hence may represent the pinnacle for internal name resolution within the organisation. This option is also desirable where an organisation does not wish to introduce a Windows Server 2003 WINS server into the production environment, and generate pull replication traffic.

When determining the design requirements for the preparation of components of the network infrastructure to permit execution of migration path “C”, consider the following:

The execution of migration path “C”, using (for example) ADMT version 2.0, requires access to the Windows NT 4.0 domain controllers by the Windows Server 2003 domain controllers using the supporting network infrastructure. Access between the source and target domain controllers may be impaired or impeded by, for example, the following:

• The availability of network links that connect the source and target domain controllers

• The levels of available bandwidth within the network links that connect the source and target domain controllers

• The presence of firewalls, between the network links that connect the source and target domain controllers, may prevent access to services. For example, if the target Windows Server 2003 domain controllers reside on the other side of a firewall from source Windows NT 4.0 domain controllers, it may be necessary to open ports in the firewall identified in following table:

Port Number Protocol Service

137-139 TCP and UDP RPC locator

389 TCP LDAP

3268 TCP Global Catalog

88 UDP Kerberos

445 UDP Kerberos authentication

464 UDP Kerberos password

Table 44.4: Internal Firewall Configuration Requirements to Support Migration Path “C”



When determining the design requirements to prepare the network infrastructure to support execution of migration path “C”, this design methodology proposes execution of the following approach:

• Analyse the design summary for the network infrastructure that supports the source and target domain infrastructures

• Identify any issues associated with this network infrastructure that may impair or impede the execution of migration path “C”.

• Determine the design requirements for the process or processes to address and resolve the identified issues

Prior to the execution of migration path “C”, it is important to determine the dependencies and timescales for the completion of all parallel projects associated with the supporting network infrastructure. For example, parallel projects to redesign the network may impair or impede the migration, such as:

Where an organisation is planning a concurrent redesign of the TCP/IP architecture shared by both the source and target domain environments, until completed, the redesign project may impede name resolution between the source and target domains.

The migration of directory objects from a source domain may depend upon the completion of network link implementations (to remote locations that support the source domain), or upgrades to the links.

Where it is possible to identify any pending or proposed projects, associated with the supporting network infrastructure, that may impede the execution of any instance of migration path “C”, then:

Identify the nature of the dependency generated by the parallel network project, and assess the impact on the execution of migration path “C”.

Assign a risk rating to the dependency, and attempt to identify any processes to mediate the risk, where possible.

When determining the design requirements for pre-migration tasks to prepare the Windows NT 4.0 domain controllers for the source domain, for execution of migration path “C”, consider the following:

The preparatory tasks that require design to prepare the Windows NT 4.0 domain controllers within a source domain for execution of migration path “C” include the following:

Preparation of Windows NT 4.0 domain controllers for design and use of SIDHistory, via enabling TCP/IP transport support

Identification and configuration of a password export server (the PDC or a BDC in the source domain)

Preparation of Windows NT 4.0 domain controllers for migration to the target domain

When determining the design requirements for the pre-migration tasks to enable support for the use of inter-forest or Windows NT 4.0 to Active Directory migrations and the use of SIDHistory, consider the following:

It is necessary to create the “TcpipClientSupport” registry entry on all source Windows NT 4.0 domain controllers targeted by the ADMT. It is possible to create this registry entry automatically or manually. When the requirements to migrate



the SIDs for user accounts is selected, during the first test run of the ADMT version 2.0 user migration wizard, where the wizard does not detect this registry entry on the source domain controller, it will create it automatically. To create this entry manually, it is necessary to use the security context of a user account in the Administrators group to create the “TcpipClientSupport” registry entry, as a DWORD value with a value entry of 1, in the “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA” registry key on a Windows NT 4.0 domain controller in the source domain.

When determining the design requirements for the process to create this registry entry on the source Windows NT 4.0 domain controllers, consider the following:

• The process must first backup the registry of the Windows NT 4.0 domain controllers prior to implementation of this registry entry. Use, for example, the regedit.exe utility to export the entire registry to a “*.reg” file, or the resource kit tool “regback.exe” to export the five default registry hives.

• The process may be automated using a script to first backup the registry and then import the required registry entry on all Windows NT 4.0 domain controllers in the source domain, to which the ADMT tool will connect.

Where the organisation has identified the requirement for the migration of user passwords, it is necessary to prepare the Windows NT 4.0 domain controller(s) in the source domain, to which the ADMT tool will connect. This design methodology proposes the execution of the following approach to determine the design requirements to prepare the source Windows NT 4.0 domain controllers for password migration:

Determine the required password export server (PES) (a BDC in the source domain)

Configure the selected PES (to which the ADMT tool will exclusively connect to retrieve the passwords for migrated user accounts) to support the migration of user passwords.

When determining the most appropriate Windows NT 4.0 BDC in the source domain to be the preferred password export server, consider the following:

The PES must have sufficient hardware resources to cope with the demands of the export, depending upon the numbers of user account objects migration path “C” is required to process within the source domain. A BDC dedicated to this function, and not required to support logons and so on, is ideal.

The PES must be operating with a minimum of Windows NT 4.0 SP5 or later, and with the 128-bit high encryption pack installed.

The PES must have good network connectivity with the PDC, and have completed a full synchronisation with the PDC prior to export of the passwords.

The selected PES should be in close network proximity (preferably on the same LAN) to the computer running the ADMT tool and the domain controllers in the target Windows Server 2003 domain.

When determining the design requirements for the configuration of the selected password export server, consider the following:

The export of passwords from a Windows NT 4.0 domain and their import into a Windows Server 2003 domain requires the manipulation and encryption of the passwords to match the password encryption protocols employed in Windows Server 2003 Active Directory.



The process to set up a PES and perform password migrations involves the execution of specific tasks within both the source and target domain. Note that it is only necessary to configure one PES server for each source Windows NT 4.0 domain.

This process hence requires the execution of the following steps:

• At the server operating the ADMT in the target Windows Server 2003 domain, open a command prompt and navigate to the ADMT installation directory, such as “C:\Program Files\Active Directory Migration Tool”. At the command prompt, execute the following command to generate the password encryption key: “admt key <SourceDomainName> DriveLetter [Password]”, where:

♦ This command requires execution for each source domain the target domain is to support

♦ The password supplied here will be required when executing the later steps on the source PES (see later)

• Note that the “password encryption key” requires secure transport between the target Windows Server 2003 domain controller, which generated the file, and the PES in the source domain. Although it is possible to save this file to a hard drive and transport it across the network, this design methodology strongly recommends the transport of this file (named *.pes) (which is only approximately 40 bytes in size) by hand between the two domain controllers, using, for example, a USB storage key. This will hence prevent the requirement to transport the key across the network and accidentally leave the key on a file system accessible by the network.

• Execute a full backup of the selected PES in the source domain

• Retrieve the “password encryption key” generated on a target Windows Server 2003 domain controller using the ADMT tool.

• Execute, on the selected password export server, the “pwdmig.exe” utility from the Windows Server 2003 CD-ROM (in the “i386\ADMT\PWDMIG” folder). This utility will request access to the “password encryption key”, prompt for the password to access this key and then configure a migration DLL and various registry keys and entries on the PES.

• Modify the registry entry “AllowPasswordExport”, located in the “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA” key, to change the DWORD value from 0 to 1. A value of “0” disables the export of passwords by this PES.

• Reboot the PES.

When determining the design requirements for the preparation of legacy Windows NT 4.0 domain controllers within the source domain for migration to the target domain, consider the following:

ADMT cannot clone domain controllers from a source domain to a target domain. Where there is a requirement to migrate Windows NT 4.0 domain controllers into the target domain, then the design methodology proposes execution of the following approach:

• Define the criteria for the identification and inclusion of legacy domain controllers into the scope for migration to the target domain, such as compliance with minimum hardware specifications to support the Windows Server 2003 operating system, and so on.



• Evaluate all existing domain controllers within the source domain that comply with the defined criteria, and hence are supported for migration to the target domain

• Ensuring that a minimum number of existing domain controllers are retained to continue to support the legacy domain environment and the coexistence phase, identify all domain controllers that require migration to the target domain.

• Because it is not easily possible to change a Windows NT 4.0 domain controller into a member server, the only feasible option proposed by this design methodology is to perform a complete re-build of the operating system, and then join the new server to the target domain. Where this option is unacceptable, since there is a requirement to retain the data / applications / services (other than domain controller) on the server, then it is not possible to execute a migration of these servers, in their current role, to the target domain.

When determining the design requirements for pre-migration tasks to prepare the security principals within the source domain, for execution of migration path “C”, consider the following:

The preparatory tasks that require design to prepare the security principals within the source domain for execution of migration path “C” include the following:

Creation of the migration credentials

Requirements to map and merge security group objects from the source to the target domain

Verification of compliance with object naming conventions in the target domain and security principal migration prerequisites associated with ADMT version 2.0

When determining the design requirements for the creation of the migration credentials, employed in the execution of migration path “C”, consider the following:

Migration path “C” (and all other migration paths that may use ADMT version 2.0) requires execution from the target domain, to perform a “pull” clone of directory objects and their data. The credentials (user accounts and security group memberships) used by the administrator performing the migration must hence support access to both the source and target domains.

This design methodology strongly recommends the creation of a single dedicated “migration” user account, assigned all appropriate group memberships in the source and target domain (across the prerequisite mono or bi-directional trust relationships), in the target Windows Server 2003 domain. The use of a single migration account simplifies the management of the migration process, and the execution and auditing of the migration tasks.

The single migration user account should have the following group memberships, to reflect the objectives of the migration:

• Membership to the Domain Admins group in the source and target domain

• Where there is a requirement to translate security on mailboxes on an existing Exchange 5.5 infrastructure, to continue to provide access for migrated users, use the Exchange 5.5 Administration console to grant the Permissions Admin role, on the Site and Configuration container, to the migration user account.



Naturally, due to the nature and functionality of this account, access and use of the single migration user account should be restricted to users within an organisation delegated the right to execute migration tasks associated with migration path “C”.

When determining the design requirements for the mapping and merging of existing security groups with security groups in the target domain, prior to the execution of migration path “C”, consider the following:

ADMT version 2.0 supports the consolidation of multiple legacy security groups into a fewer number of security groups in the target domain.

This design methodology recommends the execution of the following approach to determine the requirements for the mapping and merging of security groups, from the source to the target domain, and the design requirements for this process where required:

• Execute an analysis of the design summary for the security group infrastructure in each appropriate ORMI for the target Windows Server 2003 domain(s) of a source Windows NT 4.0 domain. Understand the following details of the security group infrastructure within the target domain:

♦ The security group design model(s) employed, and hence the requirements for the nesting of security group objects

♦ The required custom security group objects to support object and resource administration within each ORMI for each target Windows Server 2003 domain

♦ The required security principal memberships for each required custom security group object

• Execute a similar analysis of the design summary for the source Windows NT 4.0 domain, to understand the details of the current custom security group infrastructure.

• Execute a gap analysis between the design summaries to identify all design similarities and differences between the security group infrastructures in the source and target domains, based upon:

♦ Types of custom security group objects, as a reflection of the security group models

♦ Memberships of custom security group objects

• Pass the results of this analysis to the next step “determination of the design requirements for the migration tasks”

Note that it is not necessary to determine the design differences based upon the permissions and rights assigned to the groups. This is because the onus should be on the design for the security group infrastructure in the target domain to determine and assign all new permissions and rights.

When verifying compliance with object naming conventions in the target domain and prerequisites for the migration of security principals using ADMT version 2.0, consider the following:

The naming convention used for all security principals that reside within the scope of migration path “C” must comply with the appropriate naming convention(s) employed within the target domain. It is important to remember



that the scope of a migration project is not limited to just the moving of directory objects and data from a legacy to a new domain, but also is required to support the migration away from current designs and design models, where necessary.

When attempting to verify compliance with the naming convention requirements for the new target domain, this design methodology recommends execution of the following approach:

• Execute an analysis of the design summary for the target Windows Server 2003 Active Directory infrastructure and identify the object naming conventions for the target domain relevant and applicable to the source domain.

• Execute an analysis of the design summary for the source Windows NT 4.0 domain, and identify the object naming convention(s) currently in use.

• Execute a gap analysis between the design summaries to identify all design similarities and differences between the security principal naming conventions in the source and target domains.

• Where it is possible to identify design differences, then determine the requirements for the resolution of these differences as pre-migration, migration, or post-migration tasks, as appropriate. This design methodology recommends the resolution of any naming convention design differences as post-migration tasks. To support this recommendation, it is hence necessary to differentiate migrated security principals with existing security principals within the target domain. ADMT version 2.0 supports the addition of a prefix or suffix to the names of all migrated security principal objects (user, computer, and security group objects).

Note that a migration prerequisite for the use of ADMT version 2.0 is that the user names for in-scope service user accounts in the source domain must not exceed 20 characters in length. ADMT will truncate the names for all service user accounts at 20 characters.

Note that Windows NT 4.0 user account names can contain characters not supported by Active Directory, such as “ * + , / : ; < > = [ ] \ ? |. ADMT version 2.0 will replace all such characters with an underscore “_” character in the account name and UPN. In addition, ADMT will replace a full stop or period character “.” with an underscore if this is the last character in the name for an account. It is hence imperative to ensure all account names in the Windows NT 4.0 SAM database comply with the X.500 naming conventions. Compliance with this requirement is critical for service accounts, which once migrated via ADMT, may cease to function as the application or service does not recognise the account due to character replacement by ADMT.

When determining the design requirements for the pre-migration tasks to prepare the member computers within a source Windows NT 4.0 domain for migration and security translation, consider the following:

ADMT version 2.0 can perform the following migration activities on member computers within a source domain:

Migrate the computer account object from the source domain to the target domain

Translate the SIDs on access control lists (ACLs) and system ACLs (SACLs) for resource on the member computers, via the dispatch and local execution of the ADMT Agent



Transition service accounts from the source domain to the target domain prior to the migration of the member computers in the source domain

To support the security translation on the member computers, it is necessary to execute the following preparatory tasks on the member computer estate for a source domain:

Confirmation of compliance with the minimum hardware and operating system specifications for use of the ADMT Agent on member computers

Confirmation of the compliance with operating system configuration requirements for the use of the ADMT Agent on member computers

Determination of the requirements for the design and use of a SID mapping file to support and guide security translation by ADMT version 2.0

Determination of the design requirements for the migration of service accounts supporting services on member computers

When determining compliance with the minimum hardware and operating system specifications for the use of the ADMT Agent on member computers, consider the following:

The ADMT Agent will support the following operating systems:

• Windows NT 3.51 with Service Pack 5 (both x86-based and Alpha-based computers)

• Windows NT 4.0 with Service Pack 4 or later (both x86-based and Alpha-based computers)

• Windows 2000

• Windows XP

• Windows Server 2003 family

Note that as ADMT will only clone member computers, and hence all client computers running operating systems other than those listed will fall outside of the scope of migration path “C”. For example, client computers running Windows 95, 98, ME, Apple Macintosh OS, Novell NetWare Client, Linux desktop operating systems, and so on.

Where it is possible to identify any member computers that fail to comply with the above operating system specifications, such as version of installed service pack on Windows NT 4.0 servers and workstations, then determine the design requirements for the process to resolve these issues.

To support the local installation of the ADMT Agent, the member computers must have a hard disk partition with at least 15 MB of free disk space for the agent and agent log files.

When determining compliance with the configuration requirements for the use of the ADMT Agent on member computers, consider the following:

Where it is possible to identify the presence of one or more Windows NT 3.51 member computers within the source domain, then it is necessary to ensure the existence of the ADMIN$ share, to support the successful installation of the ADMT Agent.



The local Administrators group must contain the Domain Admins group for the source domain as a member.

Ensure that remote access to the local registry is enabled on the member computers

Ensure that the NetBIOS protocol is enabled on the member computers

Ensure that the (NetBIOS) Server service is configured to start automatically and is running on the member computers prior to the migration

Ensure that the target member computer is a valid member of a valid domain. Note that it is possible for the computer account passwords to expire due to prolonged disconnection from the domain.

When determining the requirements for the design and use of a SID mapping file to support and guide security translation by ADMT, consider the following:

ADMT performs the translation of SIDs on a target computer using information about the source and target domains. However, it is possible to override this translation via the provision of a custom SID mapping file to ADMT. The objective of the SID mapping file is to map a SID in the source domain to a SID in the target domain.

For example, as ADMT does not clone built-in groups, such as Domain Admins or Domain Users, ADMT hence does not translate the ACLs on resources, which reside on a member computer, to migrated security principals. However, it is possible to supply a custom SID mapping file that can map (for example) the SID for the Domain Users group, in the source domain, to each user in the target domain, migrated from the source domain.

A SID mapping file specifies the name or SID of a source object followed by a comma, then the name or SID of a target object. Place each source SID and target user pair on a discrete line in the mapping file, such as:

S-1-5-21-203558792-319624891-1381041710-1089, Natsum\User01 S-1-5-21-203558792-319624891-1381041710-1089, Natusm\User02S-1-5-21-203558792-319624891-1381041710-1089, Natusm\User03

Create the SID mapping file as a simple text file, using a “*.txt” or “*.csv suffix.

Note that it is also possible to use the SID mapping file and the Security Translation Wizard to support execution of security translations independently of migrated objects.

When determining the design requirements for the pre-migration tasks to prepare member computers within a source domain for migration of the service user accounts, consider the following:

The transitioning of service accounts from a source domain to a target domain, using ADMT version 2.0, involves the execution of a two-step approach. The two steps in this approach are:

• The first step involves the use of the ADMT version 2.0 “Service Account Wizard” to identify all domain user accounts used to support the operation of services on member servers and domain controllers within the source domain. It performs this via the configuration and dispatch of an ADMT agent to targeted computers in the source domain and examination of all service accounts and corresponding services. The migration administrator may then select the service accounts for transition to the target domain, and ADMT tags these accounts in its “protar.mdb” database.



• The second step involves the use of the ADMT version 2.0 “User Account Migration Wizard” to perform the actual transition of the service account objects to the target domain. It is important to note that this wizard will reset the password for the service account, on the migrated computers, during the migration of the appropriate servers to the target domain, and grant the user account the “log on as a service” right.

Note that the “Service Account Wizard” will not permit the migration of service accounts for applications not supported in a Windows Server 2003 target domain, such as Microsoft Exchange 5.5, and so on.

It is necessary to determine the following design requirements for the pre-migration tasks to prepare the member computers in a source domain for service account transition:

• It is necessary to determine the design requirements for a process to scan all member servers in a source domain for their service account dependencies. The objective of this scan is to identify all service accounts that require migration to the target domain, and identify those accounts that require explicit exclusion from migration. The organisation and domain owner(s) may consider the use of dedicated service accounts, instead of dual or multi-function user accounts, as this will assist in prevention of malicious users taking advantage of the security loophole explained below.

• It is important to ensure execution of the “Service Account Wizard” only against “trusted” computers within a source domain. This requirement is a reflection of a security loophole associated with the use of the ADMT version 2.0 “User Account Migration Wizard” to transition the user account objects. During the transition of the service accounts to a target domain, ADMT version 2.0 will reset the password for the service accounts. Hence, a malicious user with physical or network access to a member server in a source domain may enter an account with administrative permissions in the source domain against a service, but use an invalid password. This will prevent the service from starting with these credentials, but as ADMT will reset the password during transition of the service account, the service will start with the administrative credentials on the member server. The term “trusted” server hence implies servers with secured physical and network access, and access to manipulation of the services on the servers. Using this information, identify all potentially “un-trusted” member servers within the source domain and included within the scope of a domain migration path.


Determine the required migration tool / tool suite to support the execution of migration path “C”

Determine and document the design requirements for the pre-migration tasks to prepare a source domain for the migration of SIDs to the SIDHistory attribute of migrated security principals in the target domain.

Determine and document the design requirements for the pre-migration tasks to prepare a source domain for the migration of passwords for user accounts, from the source Windows NT 4.0 domain to the target Windows Server 2003 domain.

Determine and document the design requirements for the pre-migration tasks to prepare bi-directional trust relationships between the source and target domains, to support the execution of migration path “C”, and coexistence between the source and target domains during the migration phase.

Determine and document the design requirements for the pre-migration tasks to prepare a name resolution infrastructure to support execution of migration path “C”



and coexistence between the source and target domains during the migration phase.

Determine and document the design requirements for the preparation of all components and elements of the supporting network infrastructure to support the execution of migration path “C”.

Determine and document the dependencies and timescales associated with any parallel projects for the supporting network infrastructure, which may impair or impede the execution of migration path “C”.

Determine and document the design requirements for the pre-migration tasks to enable TCP/IP transport support by the appropriate source Windows NT 4.0 domain controllers, to support the migration of SIDs to the SIDHistory attribute.

Determine and document the design requirements for the pre-migration tasks to identify and configure a password export server (PES) (a Windows NT 4.0 BDC), to support the migration of user account passwords during the execution of migration path “C”.

Determine and document the design requirements for the preparation and migration of existing Windows NT 4.0 domain controllers to the target domain

Determine and document the design requirements for the pre-migration tasks to create and prepare the credentials for the migration user account, to support execution of migration path “C”.

Determine and document the design requirements for the mapping and merging of custom security groups in the source Windows NT 4.0 domain to custom security groups in the target Windows Server 2003 domain, during execution of migration path “C”.

Determine and document the nature of compliance of the naming convention design for security principals in the source domain with the design for object naming conventions within the target domain. Where it is possible to identify design differences, determine and document the requirements for the resolution of the design differences as pre-migration, migration, or post-migration tasks (recommended as post-migration tasks).

Determine and document the design requirements for the preparation of member computers for migration and security translation using ADMT, via execution of migration path “C”.

Determine and document the design requirements for the preparation of member computers for service account transition to the target domain using ADMT, via execution of migration path “C”.

• Factor A23: Determination of the design requirements for pre-migration tasks to prepare one or more source Windows 2000 domains for the execution of migration paths “D”, “G”, or “H”


Has identified the requirement for the migration of one or more legacy Windows 2000 domains using simple migration path “D”, or optional migration paths “G” or “H” (as extended migration paths), and

Wishes to determine the design requirements for the pre-migration tasks to support and prepare for the execution of these migration paths.




The execution of migration paths “D”, “G”, or “H” involves the migration of directory objects and data from a legacy Windows 2000 domain to a target Windows Server 2003 domain, as either an inter-forest migration (paths “D” and “H”) or an intra-forest migration (path “G”).

The objective of this step is to determine all of the design requirements for the pre-migration tasks necessary to prepare a source Windows 2000 domain for execution of migration paths “D”, “G”, or “H”.

Note that this step does not consider the requirements for contingency or coexistence. The later steps within this process, “determination of the design requirements for a contingency plan” and “determination of the design requirements for a coexistence plan”, consider all of the design requirements for the preparatory tasks to support a rollback of an existing Windows 2000 domain environment, and for continued coexistence during the migration phase.


As it is possible to identify a significant number of additional tasks for each of the migration paths “D”, “G”, or “H”, the later step within this process (“generation of the design for the migration checklists”) will provide a few examples of pre-migration tasks associated with each migration path, which do not require design for execution.

When determining the design requirements for the pre-migration tasks for migration paths “D”, “G”, or “H”, to prepare a source Windows 2000 domain for migration of directory objects and data, consider the following:

Note that the source (Windows 2000) and target (Windows Server 2003) domains share the majority of preparatory tasks for migration paths “D”, “G”, or “H”. However, the source domain does have a few additional preparatory tasks, outlined below.

The preparatory tasks that require design for execution on a source Windows 2000 domain, to support the execution of migration paths “D”, “G”, or “H”, include the following:

Selection of the migration product to execute migration paths “D”, “G”, or “H”

Understanding the migration path requirements (from the predefined business and technical migration goals) that will influence the design of migration paths “D”, “G”, or “H”, and hence the pre-migration, migration, and post-migration tasks.

Preparation of a source Windows 2000 domain to support execution of:

• Inter-forest migration paths “D” and / or “H”, and

• Intra-forest migration path “G”

Preparation of the network infrastructure to support execution of migration paths “D”, “G”, or “H”

Preparation of existing Windows 2000 domain controllers to support execution of:





Preparation of security principals within the source Windows 2000 domain to support execution of:



Preparation of member computers within the source Windows 2000 domain for migration, security translation, and service account transition

As for migration path “C”, this design methodology will support the design and use of the free domain migration utility provided by Microsoft, Active Directory Migration Tool (ADMT) version 2.0, for execution of migration paths “D”, “G”, or “H”. Hence, the remainder of this step will determine the pre-migration tasks, for the preparation of a source Windows 2000 domain, exclusively from the perspective of supporting the use of ADMT 2.0 to perform the migrations.

Determination of the design requirements for pre-migration tasks, to prepare a source domain for execution of migration paths “D”, “G”, or “H”, depends upon the migration requirements for this path and legacy Windows 2000 domain.

The predefined business and technical migration goals will define the migration requirements for this path, and identify, for example, the requirements for the following:

Requirements for the continued support of access to non-migrated resources in the source domain by migrated security principals in the target domain, during the coexistence phase of this project via the:

Design for the pre-migration tasks to prepare a source domain for the migration of SIDs and the use of the “SIDHistory” attribute of migrated security principal objects within a Windows Server 2003 domain, where required for inter-forest migration paths “D” and / or “H”.

Preparation of the source domain for the migration of closed and open sets, where required, for intra-forest migration path “G”.

Requirements for the migration of user account passwords from the source Windows 2000 domain to the target Windows Server 2003 domain. ADMT version 2.0 supports the migration of user account passwords from a source Windows NT 4.0, Windows 2000, or Windows Server 2003 domain to a target Windows 2000 or Windows Server 2003 domain.

Requirements for the renaming of user, computer, and group accounts, to permit distinction from existing account objects, or compliance with new object naming conventions. ADMT version 2.0 will support the renaming of account objects via the addition of a suffix or prefix to the migrated objects.

Requirements for the translation of security on resources migrated with computers from the source domain to the target domain. ADMT version 2.0 supports the translation of access control lists to replace, add, or remove ACEs, via the dispatch of agents to computers been migrated.

Requirements for the migration of security groups to support the consolidation of multiple Windows 2000 security groups to a few number of Windows Server 2003 security groups. ADMT version 2.0 supports the consolidation of security groups in a legacy Windows 2000 domain with groups in a target Windows Server 2003 domain.

When determining the migration requirements for the execution of migration paths “D”, “G”, or “H”, execute the following approach:



Analyse the predefined business and technical migration goals that influence the design of the required migration paths.

Identify all goals that will influence the design for the execution of migration paths “D”, “G”, or “H”, and each in-scope source Windows 2000 domain(s) required to use migration paths “D”, “G”, or “H”.

Note that this design methodology will assume that all of the requirements for the migration of a legacy Windows 2000 domain using migration paths “D”, “G”, or “H”, outlined above, are required, and will hence provide support as appropriate.

When determining the design requirements for pre-migration tasks to prepare a source domain for execution of migration paths “D”, “G”, or “H”, consider the following:

The preparatory tasks that require design to prepare a source domain for migration paths “D”, “G”, or “H” include the following:

The preparation of a source domain for the use of migration of legacy SIDs and the use of SIDHistory to support the execution of inter-forest migration paths “D” and “H”.

The preparation of a source domain for the preservation of closed “user” and “resource” sets, where required, for intra-forest migration path “G”.


The preparation of GPOs within the source domain that assign user rights to security principals within the scope of migration

The preparation (from the perspective of the source domain) of bi-directional trust relationships between the source and target domains to support the execution of inter-forest migration paths “D” and “H”

The preparation of short-cut trust relationships between the source Windows 2000 domain(s) and the target Windows 2000 domain to support execution of intra-forest migration path “G”

The raising of a source Windows 2000 domain to native mode to support execution of intra-forest migration path “G”

When determining the design requirements for the pre-migration tasks, for inter-forest migration paths “D” or “H”, to prepare a source Windows 2000 domain for SIDHistory, consider the following:

The migration of SIDs for Windows 2000 user and security group account objects requires the execution of the following tasks within the source Windows 2000 domain:

• Enable auditing of security principal account management, for both success and failure events.

• Create a local security group in the domain named “<Name_of_Source_Domain>$$$”. For example, within a Windows 2000 domain, with a NetBIOS domain name of “Domain1”, a Domain Administrator is required to create a local security group named “Domain1$$$”.




When determining the design requirements for the process to enable the auditing of user and group management within a source Windows 2000 domain, consider the following:

• Unlike Windows NT 4.0 domains, in Windows 2000 Active Directory, it is necessary for an administrator to enable and configure auditing of account management using a Group Policy Object.

• This design methodology recommends enabling of auditing for account management using the “Default Domain Controllers Policy” GPO implemented at the Domain Controllers OU. It is important to enable auditing in this default GPO as APIs, developed for earlier versions of the operating system, update in the default “Default Domain Controllers Policy” GPO.

• With auditing of user and group management enabled, this will generate entries in the Security Event Log on the domain controllers within the source domain. It is hence important to adjust the following parameters on the security event logs on the appropriate Windows 2000 domain controller(s) for the source domain and, where password migration is required, the nominated “password export server”:

♦ The size of the security event log, in KB (the required size of the event log will depend upon the number of user and group objects within the source domain and within the scope of migration paths “D” or “H”. The size of the log depends also upon the selected Event Log Wrapping parameter (see below). Where there is a requirement for the recommended option, to clear the even log manually, set the size of the log to be quite large, such as a few tens of MB. A small sized security event log, with a “clear log manually” option, will fill up quite quickly, and the domain controller may cease to function until an administrator clears the security event log. This may hence disrupt the migration process).





• Note that the Security Log Settings on Windows 2000 domain controllers default to "Maximum log size of 512 Kilobytes" and the Event Log Wrapping setting defaults to "Overwrite Events Older than 7 Days."

• This design methodology recommends that a Domain Administrator only enable the auditing of user and group management immediately prior to execution of migration paths “D” or “H”, unless already enabled within a source Windows 2000 domain. The enabling of auditing on user and group management can generate a significant impact on the performance of a Windows 2000 domain controller, required to audit significant numbers of user and group management events.


• If a Global or other security group already exists within the source Windows 2000 domain with this name, it is necessary to either delete or rename these existing groups, prior to creation of this group.





• Only use the NetBIOS domain name for the domain to prefix the triple dollar symbol, and not the DNS domain name. It is important to note that the NetBIOS domain name for a Windows 2000 domain may not be the same as the DNS domain name without any domain suffixes. For example, a Windows 2000 domain assigned the DNS domain name of “Natsum.com” may have a NetBIOS domain name of “DATA”.


• ADMT version 2.0 will only clone the following directory objects from a source Windows NT 4.0 or Windows 2000 domain:




Local groups (but for Windows NT 4.0 domains, only the shared local groups on a domain controller can be migrated)

Domain local groups (for Windows 2000 and Windows Server 2003 domains operating in “Windows 2000 Native” or “Windows Server 2003” domain functional levels)

Global groups




• Because ADMT will not clone built-in groups and security principals to a target domain, these objects will not exist in the target domain with their existing SID. Hence, membership to built-in groups, granted permissions on resources in the source domain, denies access to those resources for all users of those groups now migrated to the target domain. For example, within a source Windows 2000 domain, a resource owner grants read and write access to shares and files on a file server to the “Domain Users” built-in Global security group. Users in the domain only gain access to these resources via membership to this group. As this group is a built-in group, ADMT will not clone it to the target domain, and as a result, the migrated users no longer gain access to the resources controlled by the “Domain Users” group in the source domain. This can generate significant disruptions to the productivity of users migrated from the source domain to the target Windows Server 2003 domain.




♦ The first option is to use the ADMT security translation wizard, when executing the migration of the computers with their resources to the target domain, to translate the security settings. Note that many other proprietary tools exist that can also perform this function, and some are components of migration suites.


• Although the first option may seem the preferred option, it is possible to identify common scenarios where this is not a feasible option. For example, a Windows 2000 domain for an autonomous division represents the source domain for inter-forest migration paths “D” or “H”, and the target domain is a single Windows Server 2003 domain owned by the parent organisation. Currently, the autonomous division controls access to resources within the source domain via NTFS permissions assigned to built-in groups, such as the Domain Users group. The autonomous division is reluctant to exercise option 1, as this would hence permit all users in the target domain, including the users from the parent organisation, to access their resources, and hence deems this a security breach.

• Note that for intra-forest migration path “G”, it is possible to address this scenario using closed sets. See the later step within this process, “determination of the design requirements for the migration tasks”, and factor A33 within this process for details.


• Where it is possible to identify this common scenario, then determine the required option, and the design requirements for the process to execute the required option.

When determining the design requirements for the pre-migration tasks, for migration paths “D”, “G”, or “H”, to prepare a source Windows 2000 domain for migration of passwords for user accounts, consider the following:

The migration of user passwords, by ADMT version 2.0, requires that the password policies in the source domain match those in the target Windows Server 2003 domain. If the migrated passwords do not meet the requirements of the password policy in the target Windows Server 2003 domain, this will not prevent the migrated users from logging onto the Windows Server 2003 domain. However, it will be necessary for all affected users to change their passwords immediately at logon, to a password that complies with the policy in the target domain.







• Analyse the results of the design summary for the source Windows 2000 domain and perform a gap analysis of the password policies to identify the design differences.


♦ The first option is to implement the new (Windows Server 2003 Active Directory) password policy in the source Windows 2000 domain. Note however, in Windows 2000 Active Directory, it is only possible to implement one password policy for the entire domain, via the modification of the “Default Domain Policy” GPO created and implemented at the root of a domain.

♦ The second option is to implement the “migration object and resource management infrastructure” (ORMI) strategy devised by this design methodology. This strategy involves the generation of a temporary ORMI within each target Windows Server 2003 domain, to provide the temporary destination OUs, GPOs and DOC permissions for all migrated directory objects from one or more source Windows 2000 and / or Windows 2000 domains. The “migration ORMI” will provide the required segregation of these migrated directory objects from the rest of the domain, but still support their presence within the target domain, and use of the target domain to log on and so on. The “migration ORMI” hence provides an alternative to the first option for matching password policies because all Windows Server 2003 Active Directory GPOs support the implementation of password policies, and not just the “Default Domain Policy” GPO implemented at the root of a domain (as in Windows 2000 Active Directory). Hence, the OU infrastructure within the “migration ORMI” could support, via “block inheritance” where necessary, one or more temporary GPOs that provide the same password policy settings in the source Windows 2000 domain(s) for the migrated user accounts. Hence, a user account migrated into the “migration ORMI” in the target Windows Server 2003 domain, will receive the same password policy as the source Windows 2000 domain. Thus, when a user logs on with that account, there is no requirement to change their password at first logon.




The source Windows 2000 domain contains only a small number of user accounts (such as a few hundred or less). This option is not feasible for a source Windows 2000 domain supporting a large number of users and a requirement to implement a maximum password age



policy of only a few days. This is because as soon as the passwords for a large number of users expire, it will be necessary for all such users to change their passwords, for example, simultaneously at 9am on Monday morning, which would generate a significant disruption to the performance of the Windows 2000 domain controller for the domain hosting the PDC Emulator FSMO role.

The IT administration culture within the organisation, generated by the IT administration team, supports the execution of a significant change to the working habits of users within a short period, without generation of excessive complaints or queries. Within organisations where such changes meet strong resistance, this option is not feasible.



The most opportune time to implement the change in the password policy for a source Windows 2000 domain based upon this information.


♦ The design and implementation of a temporary “migration ORMI”, supported by option 2 supports the segregation of migrated directory objects, and supports the coexistence of the source and target domains during the migration phase. For example, multiple remote source domains are to be migrated, via migration paths “D”, “G”, or “H”, into a single Windows Server 2003 / Windows 2000 domain, centrally managed by the organisation. To support remote administrators of the source domain in managing the migrated users (until the source domain is decommissioned) the “migration ORMI” could support delegation of control for object management to these remote administrators for the duration of the coexistence phase. After all migrations are completed, and the source domains decommissioned, the migrated objects can be moved to their final destination ORMI(s) (and hence OU(s)) within the target domain and hence, where required, outside of the scope of management of the remote administrators. The phased “re-migration” of migrated users out of the “migration ORMI” to their final destination ORMI(s) will permit these users to receive their intended password policies, and other GPO policies and settings defined within their final destination ORMI(s).

♦ This option is suitable for scenarios where a single or few Windows Server 2003 / Windows 2000 domains will be the target for migration paths “D”, “G”, or “H” and / or “C”, and will eventually support the migration of a large number of security principals from legacy Windows 2000 and / or Windows NT 4.0 domains.

♦ This design methodology recommends option 2 where possible. Where there is a requirement for the use of option 2 and the “migration ORMI”, see the step “determination of the specific pre-migration tasks to prepare a target domain” for details on determination of the design requirements for a “migration ORMI”. A migration “ORMI” can support the simple migration paths “D”, “G”, or “H” and “C”, and even the optional migration paths “E”, “F”, “G”, and “H”.



♦ See the later step (determination of the specific pre-migration tasks to prepare a target domain) for details on determination of the design requirements for the implementation of one or more migration ORMIs.



The target Windows Server 2003 / Windows 2000 domain is the target for the migration of security principals from two or more source domains (as part of a domain consolidation approach).

The target Windows Server 2003 / Windows 2000 domain will receive a large number of migrated security principals that may all require a change in password. As all password changes in Windows Server 2003 / Windows 2000 domains focus on the domain controller hosting the PDC Emulator FSMO role, this single domain controller may be subjected to a significantly increased workload.

♦ The selection of this option would force all migrated users to change their passwords at first logon. The enabling of all migrated user accounts and the requirement to permit all users to logon simultaneously using their Active Directory accounts, may disrupt the continuity of the Windows Server 2003 / Windows 2000 domain controller hosting the PDC Emulator FSMO role. Hence, this design methodology does not recommend the selection of option 3.

When determining the design requirements to prepare GPOs that assign user rights to security principals within the scope of migration paths “D”, “G”, or “H”, consider the following:

ADMT supports the removal of user rights (assigned to security principals within a source Windows 2000 domain via a GPO) during the migration of the security principals. However, this option is only available within the “Naming Conflicts” tabbed page for the User Account Migration Wizard upon selection of the option to “Replace Conflicting Accounts”.

Note that this option, to “Remove Existing User Rights” depends upon ADMT querying the applicable GPOs for a security principal, and matching the user right assignments to a user been migrated. The match depends upon the use of the domain name (for the source user account) prefixing the user name for the source user account, such as “Domain\User”. It is possible, within a Windows 2000 Active Directory GPO, to add a user account name to a user right by just using the user name, and not the domain prefix. Where ADMT detects this entry in a GPO for a security principal, it will ignore it and not remove the corresponding user right in the target domain for that security principal.

This design methodology proposes the following approach to determine the design requirements for the pre-migration tasks to prepare Windows 2000 GPOs:

• Determine the requirement to prepare Windows 2000 GPOs that assign user rights. Note that as the option to remove user rights is only available as a sub-option to “Replace Conflicting Accounts”, there is a requirement to identify and prepare the Windows 2000 GPOs that assign user rights only if this option is required.

• Where it is possible to identify a requirement to prepare the Windows 2000 GPOs that assign user rights, then execute the following:



♦ Analyse the design summary for the source Windows 2000 domain environment and identify all GPOs that assign user rights to security principals within the scope of migration paths “D”, “G”, or “H”.

♦ Execute an analysis of each identified GPO to ensure that the domain name prefixes the user name for all policies that assign user rights to the security principals.

When determining the design requirements to establish the trust relationship between a source Windows 2000 and target Windows Server 2003 (for inter-forest migration path “D”) or (interim) Windows 2000 domain (for inter-forest migration path “H”), consider the following:

To support execution of inter-forest migration paths “D” or “H”, it is necessary to establish a minimum of a mono-directional trust relationship between the source and target domains, with the source domain trusting the target domain. However, where there is a requirement for coexistence between the two domains during the migration project, then it is necessary to establish bi-directional trust relationships between the source and target domains.


• To support the execution of inter-forest migration paths “D” or “H”, and


In most organisations, the trust relationships will hence seem a permanent feature of the new Windows Server 2003 / (interim) Windows 2000 domain, until it is possible to decommission the source Windows 2000 domain.


• Access to the source domain and Active Directory database by the designated administrator performing the migration to the target domain, and



Note that where the source Windows 2000 domain controllers are running SP4, then all external trust relationships, by default, operate with SID filtering enabled. Where there is a requirement for the source domain to continue to support access to resources by migrated security principals, using their SIDHistory attribute, then it is necessary to disable SID filtering on the incoming trust relationship. To disable SID filtering on the incoming trust, execute the following “Netdom” command at a command prompt on a Windows 2000 domain controller in the source domain: “Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:No /usero:<domainadministratorAcct> /passwordo:<domainadminpwd>”. (Please note the “o” at the end of /usero: and /passwordo: switches).

When determining the design requirements to establish the trust relationship between a source Windows 2000 and target (interim) Windows 2000 domain (for intra-forest migration path “G”), consider the following:



Because the source Windows 2000 domain is in the same forest as the target (interim) Windows 2000 domain, for intra-forest migration path “G”, it is not necessary to create any external trust relationships, as all domains trust each other via bi-directional transitive trust relationships that follow tree hierarchies, and tree root-to-forest root relationships.

Note however, where an organisation is planning on the consolidation of multiple legacy Windows 2000 domains within a forest, and the forest supports a number of domain trees and domains, then it may be necessary to design and implement short-cut trust relationships. This design methodology proposes execution of the following approach to determine the requirements for the design and implementation of short-cut trust relationships within a forest, to support execution of the optional intra-forest migration path “G”:

• Generate or obtain a diagram of the domains within the Windows 2000 forest and highlight the source and target Windows 2000 domains

• Using the built-in bi-directional transitive trust relationships between the domains in the forest, determine the number of “hops” between the source and target domains. This design methodology proposes that where it is possible to identify three or more than “hops” (as intra-forest trusts) between the source and target domains, generate a direct short-cut trust relationship between them.

• In the following example diagram, which illustrates this approach, it is possible to identify five default intra-forest transitive trust relationships between the source and target Windows 2000 domains. A single short-cut trust between the source and target domains would speed up the migration process, as it would reduce the requirements for LDAP referrals up the domain hierarchies in the domain trees, and between domain trees via the forest root domain.

ForestRoot

TreeRoot

TreeRoot

1

2

3

45Target Windows

2000 Domain

Source Windows 2000 Domain


Figure 44.9: Illustration of Requirement for Design of Short-Cut Trust Relationships

When determining the design requirements to raise a source Windows 2000 domain to native mode to support execution of intra-forest migration path “G”, consider the following:

The execution of certain domain migration activities between domains in the same forest requires the source domain to be operating in native mode, and not in mixed mode. For example, when executing a domain migration exercise using ADMT, it is possible to note the following if the source domain is operating in mixed mode:

• The “Undo Last Migration Wizard” of ADMT version 2.0 is unavailable



• Where migrated user account objects belong to migrated security groups, which both originally reside in different source domains for a target Windows 2000 domain, then the migrated user accounts will not retain their memberships to the migrated group objects from other forest / trusted domains. This is the temporary breaking of a closed “user” set.

Where an existing legacy Windows 2000 domain is currently operating in mixed mode, specifically to support one or more legacy Windows NT 4.0 BDCs, then it may not be possible to raise the domain mode via the upgrade or decommissioning of the BDCs. Their continued presence may represent a reflection for a significant business or technical requirement. To identify the opportunity to upgrade or decommission the BDC(s), this design methodology recommends a re-evaluation of the business and / or technical requirements to retain these domain controllers, and hence determine whether these requirements are still justified and viable.

When determining the design requirements for the pre-migration tasks to prepare the network infrastructure to support execution of migration paths “D”, “G”, or “H”, consider the following:

The preparatory tasks that require design to prepare the network infrastructure (which supports both the source and target domains) for migration paths “D”, “G”, or “H” include the following:

The preparation of the name resolution infrastructure to support execution of migration paths “D”, “G”, or “H” and coexistence between the source and target domains

The preparation of components of the supporting network infrastructure to permit execution of migration paths “D”, “G”, or “H”


When determining the design requirements for the preparation of the name resolution infrastructure within the organisation, to support execution of the migration paths “D”, “G”, or “H” and coexistence of the source and target domains, consider the following:

Where there is a requirement for coexistence between the source and target domains, then the migrated security principals in the target Windows Server 2003 will require access to the source domain, and all domains that trust the source domain. This hence implies the requirement for the migration of all existing trust-relationships, between the source domain and all other domains that trust the source domain, to the target domain and these external domains. For example, a source Windows 2000 domain, “Domain1” has a trust relationship with another internal or external Windows 2000 domain, “Domain2”, which trusts “Domain1”, and hence permits security principals from “Domain1” to access its resources. “Domain1” is the source domain for migration paths “D”, “G”, or “H” to a target Windows Server 2003 domain “Domain3”. To support continued access for users in “Domain3”, migrated from “Domain1”, to resources in “Domain2”, it is necessary for “Domain2” to trust “Domain3”. This will hence permit migrated users, using their SIDHistory (SIDs from “Domain 1”) to access resources in “Domain2”. The name resolution infrastructure is hence required to support name resolution between the target Windows Server 2003 domain and other non-source domains for a specific execution instance of migration paths “D”, “G”, or “H”.

To support the execution of migration paths “D”, “G”, or “H”, the Windows Server 2003 domain controllers in the target domain must be able to locate the source



domain and its domain controllers, and vice versa. As both Windows 2000 and Windows Server 2003 domains exclusively use DNS for name resolution, it is a simple process to enable concurrent support for both domain environments.


• Configure the Windows Server 2003 DNS server or another DNS server as an internal root DNS server.

• Configure the DNS server(s) supporting the Windows 2000 domain environment(s) to point to the internal root DNS server using a root hint, where necessary.

• Configure the internal root DNS server to use forwarder entries to, for example, a dedicated forwarder DNS server, residing with a firewall-partitioned network. See the Organisation-Wide Active Directory Plan process “Design of a DNS Infrastructure” for details.

When determining the design requirements for the preparation of components of the network infrastructure to permit execution of migration paths “D”, “G”, or “H”, consider the following:

The execution of these migration paths, using (for example) ADMT version 2.0, requires network access between the source and target domain controllers, which may be impaired or impeded by, for example, the following:



• The presence of firewalls, between the network links that connect the source and target domain controllers, may prevent access to services. For example, if the target domain controllers reside on the other side of a firewall from source Windows 2000 domain controllers, it may be necessary to open ports in the firewall identified in following table:



389 TCP LDAP


88 UDP Kerberos



Table 44.5: Internal Firewall Configuration Requirements to Support Execution of Migration Paths “D”, “G”, and “H”

When determining the design requirements to prepare the network infrastructure to support execution of migration paths “D”, “G”, or “H”, this design methodology proposes execution of the following approach:




• Identify any issues associated with this network infrastructure that may impair or impede the execution of migration paths “D”, “G”, or “H”.


Prior to the execution of migration paths “D”, “G”, or “H”, it is important to determine the dependencies and timescales for the completion of all parallel projects associated with the supporting network infrastructure. For example, parallel projects to redesign the network may impair or impede the migration, such as:



Where it is possible to identify any pending or proposed projects, associated with the supporting network infrastructure, that may impede the execution of any instance of migration paths “D”, “G”, or “H”, then:

Identify the nature of the dependency generated by the parallel network project, and assess the impact on the execution of migration paths “D”, “G”, or “H”.


When determining the design requirements for pre-migration tasks to prepare the Windows 2000 domain controllers for the source domain, for execution of migration paths “D”, “G”, or “H”, consider the following:

The preparatory tasks that require design to prepare the Windows 2000 domain controllers within a source domain include the following:

Enabling TCP/IP transport support to support migration of SIDHistory using inter-forest migration paths “D” or “H”

Identification and configuration of a password export server (a Windows 2000 domain controller in the source domain) to support password migration using migration paths “D”, “G”, or “H”

Preparation of Windows 2000 domain controllers within the source domain for migration to the target domain

To enable support for the use of inter-forest or Windows 2000 to Active Directory migrations and the use of SIDHistory, it is necessary to create the “TcpipClientSupport” registry entry on all source Windows 2000 domain controllers targeted by the ADMT.

It is possible to create this registry entry automatically or manually. When the requirements to migrate the SIDs for user accounts is selected, during the first test run of the ADMT version 2.0 user migration wizard, where the wizard does not detect this registry entry on the source domain controller, it will create it automatically. To create this entry manually, it is necessary to use the security context of a user account in the Administrators group to create the “TcpipClientSupport” registry entry, as a DWORD value with a value entry of 1, in the “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA” registry key on a Windows 2000 domain controller in the source domain.



When determining the design requirements for the process to create this registry entry on the source Windows 2000 domain controllers, consider the following:

The process must first backup the registry of the Windows 2000 domain controllers prior to implementation of this registry entry. Perform, for example, a system state backup, use the regedit.exe utility to export the entire registry to a “*.reg” file, or the resource kit tool “regback.exe” to export the five default registry hives.

The process may be automated using a script to first backup the registry and then import the required registry entry on all Windows 2000 domain controllers in the source domain, to which the ADMT tool will connect.

Where the organisation has identified the requirement for the migration of user passwords, it is necessary to prepare the Windows 2000 domain controller(s) in the source domain, to which the ADMT tool will connect. This design methodology proposes the execution of the following approach to determine the design requirements to prepare the source Windows 2000 domain controllers for password migration:

Determine the required password export server (PES) (a Windows 2000 domain controller in the source domain)


When determining the most appropriate Windows 2000 domain controller in the source domain to be the preferred password export server, consider the following:

The PES must have sufficient hardware resources to cope with the demands of the export, depending upon the numbers of user account objects migration paths “D”, “G”, or “H” is required to process within the source domain. A Windows 2000 domain controller dedicated to this function, and not required to support logons and so on, is ideal.

The PES in a source Windows 2000 domain must be operating on a Windows 2000 domain controller with SP3 or later and the 128-bit high encryption pack installed.



The export of passwords from a Windows 2000 domain and their import into a Windows Server 2003 domain requires the manipulation and encryption of the passwords to match the password encryption protocols employed in Windows Server 2003 Active Directory.

The process to set up a PES and perform password migrations involves the execution of specific tasks within both the source and target domain. Note that it is only necessary to configure one PES server for each source Windows 2000 domain.


• At the server operating the ADMT in the target Windows Server 2003 / Windows 2000 domain, open a command prompt and navigate to the ADMT



installation directory, such as “C:\Program Files\Active Directory Migration Tool”. At the command prompt, execute the following command to generate the password encryption key: “admt key <SourceDomainName> DriveLetter [Password]”, where:



• Note that the “password encryption key” requires secure transport between the target Windows Server 2003 / Windows 2000 domain controller, which generated the file, and the PES in the source domain. Although it is possible to save this file to a hard drive and transport it across the network, this design methodology strongly recommends the transport of this file (named *.pes) (which is only approximately 40 bytes in size) by hand between the two domain controllers, using, for example, a USB storage key. This will hence prevent the requirement to transport the key across the network and accidentally leave the key on a file system accessible by the network.


• Retrieve the “password encryption key” generated on a target Windows Server 2003 / Windows 2000 domain controller using the ADMT tool.


• Modify the registry entry “AllowPasswordExport”, located in the “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA” key, to change the DWORD value from 0 to 1. A value of “0” disables the export of passwords by this PES.

• Reboot the PES.

When determining the design requirements for the preparation of legacy Windows 2000 domain controllers within the source domain for migration to the target domain, consider the following:

ADMT cannot clone domain controllers from a source domain to a target domain. Where there is a requirement to migrate Windows 2000 domain controllers into the target domain, then the design methodology proposes execution of the following approach:

• Define the criteria for the identification and inclusion of legacy domain controllers into the scope for migration to the target domain, such as compliance with minimum hardware specifications to support the Windows Server 2003 operating system, and so on.


• Ensuring that a minimum number of existing domain controllers are retained to continue to support the legacy domain environment and the coexistence



phase, identify all domain controllers that require migration to the target domain.

• Execute the Active Directory Installation Wizard (dcpromo.exe) on the legacy Windows 2000 domain controllers to demote them to member servers

• Migrate the Windows 2000 member server using ADMT, and execute security translation (from within the Computer Migration Wizard)

• Upgrade the migrated Windows 2000 member server to a Windows Server 2003 server and, where necessary, execute the Active Directory Installation Wizard (dcpromo.exe) on the server to generate an additional domain controller for the target domain.

Note that any domain local groups referenced by security descriptors on the Windows 2000 domain controller that requires migration after demotion to member server require migration prior to joining the server to the target domain.

When determining the design requirements for pre-migration tasks to prepare the security principals within the source Windows 2000 domain, for execution of migration paths “D”, “G”, or “H”, consider the following:

The preparatory tasks that require design to prepare the security principals within the source domain for execution of migration paths “D”, “G”, or “H” include the following:



Verification of compliance with object naming conventions in the target domain and security principal migration prerequisites associated with ADMT version 2.0

Requirements for the preparation of the source domain security principals for preservation of closed “user” sets

Requirements for the preparation of the source domain security principals for preservation of closed “resource” sets

When determining the design requirements for the creation of the migration credentials, employed in the execution of migration paths “D”, “G”, or “H”, consider the following:

Migration paths “D”, “G”, or “H” (and all other migration paths that may use ADMT version 2.0) require execution from the target domain, to perform a “pull” clone of directory objects and their data. The credentials (user accounts and security group memberships) used by the administrator performing the migration must hence support access to both the source and target domains.

This design methodology strongly recommends the creation of a single dedicated “migration” user account, assigned all appropriate group memberships in the source and target domain (across the prerequisite bi-directional trust relationships), in the target Windows Server 2003 domain. The use of a single migration account simplifies the management of the migration process, and the execution and auditing of the migration tasks.

The single migration user account should have membership to the Domain Admins group in the source and target domain.



Naturally, due to the nature and functionality of this account, access and use of the single migration user account should be restricted to users within an organisation delegated the right to execute migration tasks associated with migration paths “D”, “G”, or “H”.

When determining the design requirements for the mapping and merging of existing security groups with security groups in the target domain, prior to the execution of migration paths “D”, “G”, or “H”, consider the following:


Note that the consolidation of security group objects may break any closed “user” sets for the intra-forest migration path “G”.


• Execute an analysis of the design summary for the security group infrastructure in each appropriate ORMI for the target Windows Server 2003 domain(s) of a source Windows 2000 domain. Understand the following details of the security group infrastructure within the target domain:




• Execute a similar analysis of the design summary for the source Windows 2000 domain, to understand the details of the current custom security group infrastructure.






When verifying compliance with object naming conventions in the target domain and prerequisites for the migration of security principals using ADMT version 2.0, consider the following:



The naming convention used for all security principals that reside within the scope of migration paths “D”, “G”, or “H” must comply with the appropriate naming convention(s) employed within the target domain. It is important to remember that the scope of a migration project is not limited to just the moving of directory objects and data from a legacy to a new domain, but also is required to support the migration away from current designs and design models, where necessary.

When attempting to verify compliance with the naming convention requirements for the new target domain, this design methodology recommends execution of the following approach:

• Execute an analysis of the design summary for the target Windows Server 2003 Active Directory infrastructure and identify the object naming conventions for the target domain relevant and applicable to the source domain.

• Execute an analysis of the design summary for the source Windows 2000 domain, and identify the object naming convention(s) currently in use.

• Execute a gap analysis between the design summaries to identify all design similarities and differences between the security principal naming conventions in the source and target domains.

• Where it is possible to identify design differences, then determine the requirements for the resolution of these differences as pre-migration, migration, or post-migration tasks, as appropriate. This design methodology recommends the resolution of any naming convention design differences as post-migration tasks. To support this recommendation, it is hence necessary to differentiate migrated security principals with existing security principals within the target domain. ADMT version 2.0 supports the addition of a prefix or suffix to the names of all migrated security principal objects (user, computer, and security group objects).

Note that a migration prerequisite for the use of ADMT version 2.0 is that the user names for in-scope user accounts in the source domain must not exceed 20 characters in length. ADMT will truncate all user account names at 20 characters.

When determining the design requirements for the preparation of a source domain to preserve closed “user” sets, for intra-forest migration path “G”, consider the following:

It is necessary to prepare a source domain, to preserve closed “user” sets where it is possible to identify that well-known security principals are members of closed sets. Their natural exclusion from inter-domain migration will permanently break any closed sets in the source domain without the execution of the pre-migration preparatory tasks on the source domain. This is because the intra-forest migration of user account objects from a source domain, in which they currently gain access to resources and inherit permissions and rights via membership to the built-in security groups, will not maintain these access rights and permissions. It is hence necessary to reassign these permissions.

This design methodology proposes execution of the following approach to determine the design requirements for the process to prepare a source domain (to preserve closed “user” sets):

• Execute an analysis to identify all resources within a source domain that assign access permissions to built-in security groups, like Domain Admins, Domain Users, and so on. The Windows 2000 and Windows Server 2003



resource kits tools can assist in extraction of the DACLs and ACEs on resources in a source domain.

• Where it is possible to identify a large number of resources that assign access permissions to built-in security groups, identify the built-in security groups, and create corresponding Domain Local security groups. Create Global security groups to hold all security principals that currently rely upon membership to the built-in groups for access rights to resources, permissions, and rights. Add the Global security groups to the new Domain Local groups.

• Then create a SID mapping file that maps the SIDs for the well-known security groups to the new Domain Local groups.

• Execute the Security Translation Wizard using the SID mapping file and the “add” mode to perform a security translation on all relevant resources on the appropriate computers in the source domain.

Using the above approach, determine the design requirements for the process to execute these tasks. These tasks require execution as pre-migration tasks, to prepare a source Windows 2000 domain for intra-forest migration path “G” and preservation of closed “user” sets.

When determining the design requirements for the preparation of a source domain to preserve closed “resource” sets, for intra-forest migration path “G”, consider the following:

The preservation of closed “resource” sets during migration depends upon the co-migration of Domain Local security groups. Where this does not occur due, for example, to the requirements for the phased migration of “user”, “server” and “logical” partition of a source domain (see later for details of these terms), then this will temporarily break the closed “resource” sets.

To preserve the closed “resource” sets during the execution of the intra-forest migration path “G”, it is necessary to convert the Domain Local security groups manually into Universal security groups. This conversion naturally depends upon the domain mode for the source Windows 2000 domain (for migration path “G”) to be operating in native mode.

This design methodology proposes execution of the following approach to determine the design requirements for the process to prepare a source domain (to preserve closed “resource” sets):

• Execute an analysis to identify all Domain Local security groups used on multiple member computers for the assignment of permissions to resources on those computers, either directly or via membership to local security groups. The Windows 2000 / Windows Server 2003 resource kit tools can assist in identification of the DACLs and ACEs on the member computers, to identify any Domain Local security groups.

• Where it is possible to identify these Domain Local security groups, record the list of these groups and modify the description field on the groups, to mark them for conversion to Universal security groups during the pre-migration phase. It is necessary to record the list of these Domain Local groups to facilitate their manual conversion back to Domain Local groups following migration (as interim Universal security groups) to the target domain. It is necessary to execute the conversion back to Domain Local groups as a post-migration task for intra-domain migration path “H” (see the later step, “determination of the design requirements for the post-migration tasks” for details).



Using the above approach, determine and document the design requirements for the process to execute these tasks. These tasks require execution as pre-migration tasks, to prepare a source Windows 2000 domain for intra-forest migration path “G” and preservation of closed “resource” sets.

When determining the design requirements for the pre-migration tasks to prepare the member computers within a source Windows 2000 domain for migration and security translation, consider the following:








Determination of the requirements for the design and use of a SID mapping file to support and guide security translation by ADMT





• Windows 2000

• Windows XP



Where it is possible to identify any member computers that fail to comply with the above operating system specifications, such as version of installed service pack



on Windows NT 4.0 servers and workstations, then determine the design requirements for the process to resolve these issues.













• S-1-5-21-203558792-319624891-1381041710-1089, Natsum\User01 S-1-5-21-203558792-319624891-1381041710-1089, Natusm\User02S-1-5-21-203558792-319624891-1381041710-1089, Natusm\User03











• It is necessary to determine the design requirements for a process to scan all member servers in a source domain for their service account dependencies. The objective of this scan is to identify all service accounts that require migration to the target domain, and identify those accounts that require explicit exclusion from migration. The organisation and domain owner(s) may consider the use of dedicated service accounts, instead of dual or multi-function user accounts, as this will assist in prevention of malicious users taking advantage of the security loophole explained below.

• It is important to ensure execution of the “Service Account Wizard” only against “trusted” computers within a source domain. This requirement is a reflection of a security loophole associated with the use of the ADMT version 2.0 “User Account Migration Wizard” to transition the user account objects. During the transition of the service accounts to a target domain, ADMT version 2.0 will reset the password for the service accounts. Hence, a malicious user with physical or network access to a member server in a source domain may enter an account with administrative permissions in the source domain against a service, but use an invalid password. This will prevent the service from starting with these credentials, but as ADMT will reset the password during transition of the service account, the service will start with the administrative credentials on the member server. The term “trusted” server hence implies servers with secured physical and network access, and access to manipulation of the services on the servers. Using this information, identify all potentially “un-trusted” member servers within the source domain and included within the scope of a domain migration path.




Determine the required migration tool / tool suite to support the execution of migration paths “D”, “G”, or “H”

Determine and document the design requirements for the pre-migration tasks to prepare a source domain for the migration of SIDs to the SIDHistory attribute of migrated security principals in the target domain.

Determine and document the design requirements for the pre-migration tasks to prepare a source domain for the migration of passwords for user accounts, from the source Windows 2000 domain to the target Windows Server 2003 domain / (interim) Windows 2000 domain.

Determine and document the design requirements to prepare existing Windows 2000 GPOs that assign user rights, for execution of migration paths “D”, “G”, or “H”.

Determine and document the design requirements for the pre-migration tasks to prepare bi-directional trust relationships between the source and target domains, to support the execution of migration paths “D” or “H”, and coexistence between the source and target domains during the migration phase.

Determine and document the design requirements for the pre-migration tasks to prepare short-cut trust relationships between source and target Windows 2000 domains in a forest, to support the execution of intra-forest migration path “G”.

Determine and document the design requirements for the pre-migration tasks to raise a source Windows 2000 domain to native mode, to enable features associated with the execution of intra-forest migration path “G”.

Determine and document the design requirements for the pre-migration tasks to prepare a name resolution infrastructure to support execution of migration paths “D”, “G”, or “H” and coexistence between the source and target domains during the migration phase.

Determine and document the design requirements for the preparation of all components and elements of the supporting network infrastructure to support the execution of migration paths “D”, “G”, or “H”.

Determine and document the dependencies and timescales associated with any parallel projects for the supporting network infrastructure, which may impair or impede the execution of migration paths “D”, “G”, or “H”.

Determine and document the design requirements for the pre-migration tasks to enable TCP/IP transport support by the appropriate source Windows 2000 domain controllers, to support the migration of SIDs to the SIDHistory attribute via execution of inter-forest migration paths “D” or “H”.

Determine and document the design requirements for the pre-migration tasks to identify and configure a password export server (PES), to support the migration of user account passwords during the execution of migration paths “D”, “G”, or “H”.

Determine and document the design requirements for the preparation and migration of existing Windows 2000 domain controllers to the target domain

Determine and document the design requirements for the pre-migration tasks to create and prepare the credentials for the migration user account, to support execution of migration paths “D”, “G”, or “H”.

Determine and document the design requirements for the mapping and merging of custom security groups in the source Windows 2000 domain to custom security groups in the target Windows Server 2003 domain, during execution of migration paths “D”, “G”, or “H”.



Determine and document the nature of compliance of the naming convention design for security principals in the source domain with the design for object naming conventions within the target domain. Where it is possible to identify design differences, determine and document the requirements for the resolution of the design differences as pre-migration, migration, or post-migration tasks (recommended).

Determine and document the design requirements for the preparation of security principals within the source domain to preserve closed “user” and “resource” sets for intra-forest migration path “G”.

Determine and document the design requirements for the preparation of member computers for migration and security translation using ADMT, via migration paths “D”, “G”, or “H”.

Determine and document the design requirements for the preparation of member computers for service account transition to the target domain using ADMT, via execution of migration paths “D”, “G”, or “H”.

• Factor A24: Determination of the design requirements for the pre-migration tasks to prepare one or more source Windows Server 2003 domains for execution of migration paths “E” and / or “F”


Has identified the requirements for the execution of one or more instances of migration paths “E” or “F”, and

Wishes to determine the design requirements for the pre-migration tasks to prepare each source Windows Server 2003 domain for the execution of these paths


Most organisations execute the optional migration paths “E” and “F” to consolidate multiple Windows Server 2003 domains, generated as “interim” domains and / or forests of domains, via execution of one or more of the simple migration paths.

The execution of migration paths “E” or “F” involves the migration of directory objects and data from a source Windows Server 2003 domain to a target Windows Server 2003 domain, as either an inter-forest migration (path “F”) or an intra-forest migration (path “E”). The objective of this step is to determine all of the design requirements for the pre-migration tasks necessary to prepare a source Windows Server 2003 domain for execution of migration paths “E” or “F”.

Note that this step does not consider the requirements for contingency or coexistence. The later steps within this process, “determination of the design requirements for a contingency plan” and “determination of the design requirements for a coexistence plan”, consider all of the design requirements for the preparatory tasks to support a rollback of an existing Windows Server 2003 domain environment, and for continued coexistence during the migration phase.


As it is possible to identify a significant number of additional tasks for each of the migration paths “E” or “F”, the later step within this process (“generation of the design for the migration checklists”) will provide a few examples of pre-migration tasks associated with each migration path, which do not require design for execution.



When determining the design requirements for the pre-migration tasks for migration paths “E” or “F”, to prepare a source Windows Server 2003 domain for migration of directory objects and data, consider the following:

Note that the source (Windows Server 2003) and target (Windows Server 2003) domains share the majority of preparatory tasks for migration paths “E” or “F”. However, the source domain does have a few additional preparatory tasks, outlined below.

The preparatory tasks that require design for execution on a source Windows Server 2003 domain, to support the execution of migration paths “E” or “F”, include the following:

Selection of the migration product to execute migration paths “E” or “F”

Preparation of a source Windows Server 2003 domain to support execution of:

• Intra-forest migration path “E”, and

• Inter-forest migration path “F”

Preparation of the network infrastructure to support execution of migration paths “E” or “F”

Preparation of existing Windows Server 2003 domain controllers to support execution of:



Preparation of security principals within the source Windows Server 2003 domain to support execution of:



Preparation of member computers within the source Windows Server 2003 domain for migration, security translation, and service account transition using ADMT, via execution of migration paths “E” or “F”

As for migration path “C”, this design methodology will support the design and use of the free domain migration utility provided by Microsoft, Active Directory Migration Tool (ADMT) version 2.0, for execution of migration paths “E” or “F”. Hence, the remainder of this step will determine the pre-migration tasks, for the preparation of a source Windows Server 2003 domain, exclusively from the perspective of supporting the use of ADMT 2.0 to perform the migrations.

When determining the design requirements for pre-migration tasks to prepare a source domain for execution of migration paths “E” or “F”, consider the following:

The preparatory tasks that require design to prepare a source domain for migration paths “E” or “F” include the following:

The preparation of a source domain for the use of migration of legacy SIDs and the use of SIDHistory to support the execution of inter-forest migration path “F”




The preparation (from the perspective of the source domain) of bi-directional trust relationships between the source and target domains to support the execution of inter-forest migration path “F”

The preparation of short-cut trust relationships between the source Windows Server 2003 domain(s) and the target Windows Server 2003 domain to support execution of intra-forest migration path “E”

The raising of a source Windows Server 2003 domain to “Windows 2000 Native” or “Windows Server 2003” domain functional level to support execution of intra-forest migration path “E”

When determining the design requirements for the pre-migration tasks, for inter-forest migration paths “F”, to prepare a source Windows Server 2003 domain for SIDHistory, consider the following:

The migration of SIDs for Windows Server 2003 user and security group account objects requires the execution of the following tasks within the source Windows Server 2003 domain:

• Enable auditing of security principal account management, for both success and failure events.

• Create a local security group in the domain named “<Name_of_Source_Domain>$$$”. For example, within a Windows Server 2003 domain, with a NetBIOS domain name of “Domain1”, a Domain Administrator is required to create a local security group named “Domain1$$$”.


When enabling the auditing of user and group management within a source Windows Server 2003 domain, consider the following:

• Unlike Windows NT 4.0 domains, in Windows Server 2003 Active Directory, it is necessary for an administrator to enable and configure auditing of account management using a Group Policy Object.

• This design methodology recommends enabling of auditing for account management using the “Default Domain Controllers Policy” GPO implemented at the Domain Controllers OU. It is important to enable auditing in this default GPO as APIs, developed for earlier versions of the operating system, update in the default “Default Domain Controllers Policy” GPO.

• With auditing of user and group management enabled, this will generate entries in the Security Event Log on the domain controllers within the source domain. It is hence important to adjust the following parameters on the security event logs on the appropriate Windows Server 2003 domain controller(s) for the source domain and, where password migration is required, the nominated “password export server”:

♦ The size of the security event log, in KB (the required size of the event log will depend upon the number of user and group objects within the source domain and within the scope of migration path “F”. The size of the log depends also upon the selected Event Log Wrapping parameter (see below). Where there is a requirement for the recommended option, to clear the even log manually, set the size of the log to be quite large, such as a few tens of MB. A small sized security event log, with a “clear log manually” option, will fill up quite quickly, and the domain controller may



cease to function until an administrator clears the security event log. This may hence disrupt the migration process).





• Note that the Security Log Settings on Windows Server 2003 domain controllers default to "Maximum log size of 512 Kilobytes" and the Event Log Wrapping setting defaults to "Overwrite Events Older than 7 Days."

• This design methodology recommends that a Domain Administrator only enable the auditing of user and group management immediately prior to execution of migration path “F”, unless already enabled within a source Windows Server 2003 domain. The enabling of auditing on user and group management can generate a significant impact on the performance of a Windows Server 2003 domain controller, required to audit significant numbers of user and group management events.


• If a Global or other security group already exists within the source Windows Server 2003 domain with this name, it is necessary to either delete or rename these existing groups, prior to creation of this group.



• Only use the NetBIOS domain name for the domain to prefix the triple dollar symbol, and not the DNS domain name. It is important to note that the NetBIOS domain name for a Windows Server 2003 domain may not be the same as the DNS domain name without any domain suffixes. For example, a Windows Server 2003 domain assigned the DNS domain name of “Natsum.com” may have a NetBIOS domain name of “DATA”.


• ADMT version 2.0 will only clone the following directory objects from a source Windows Server 2003 domain:






Domain local groups (for Windows Server 2000 and Windows Server 2003 domains operating in “Windows 2000 Native” or “Windows Server 2003” domain functional level)

Global groups




• Because ADMT will not clone built-in groups and security principals to a target domain, these objects will not exist in the target domain with their existing SID. Hence, membership to built-in groups, granted permissions on resources in the source domain, denies access to those resources for all users of those groups now migrated to the target domain. For example, within a source Windows Server 2003 domain, a resource owner grants read and write access to shares and files on a file server to the “Domain Users” built-in Global security group. Users in the domain only gain access to these resources via membership to this group. As this group is a built-in group, ADMT will not clone it to the target domain, and as a result, the migrated users no longer gain access to the resources controlled by the “Domain Users” group in the source domain. This can generate significant disruptions to the productivity of users migrated from the source domain to the target Windows Server 2003 domain.


♦ The first option is to use the ADMT security translation wizard, when executing the migration of the computers with their resources to the target domain, to translate the security settings. Note that many other proprietary tools exist that can also perform this function, and some are components of migration suites.


• Although the first option may seem the preferred option, it is possible to identify common scenarios where this is not a feasible option. For example, a Windows Server 2003 domain for an autonomous division represents the source domain for inter-forest migration paths “F”, and the target domain is a single Windows Server 2003 domain owned by the parent organisation. Currently, the autonomous division controls access to resources within the source domain via NTFS permissions assigned to built-in groups, such as the Domain Users group. The autonomous division is reluctant to exercise option 1, as this would hence permit all users in the target domain, including the users from the parent organisation, to access their resources, and hence deems this a security breach.

• Note that for intra-forest migration path “E”, it is possible to address this scenario using closed sets. See the later step within this process, “determination of the design requirements for the migration tasks”, and factor A33 within this process for details.




• Where it is possible to identify this common scenario, then determine the required option, and the design requirements for the process to execute the required option.

When determining the design requirements for the pre-migration tasks, for migration paths “E” or “F”, to prepare a source Windows Server 2003 domain for migration of passwords for user accounts, consider the following:

The migration of user passwords, by ADMT version 2.0, requires that the password policies in the source domain match those in the target Windows Server 2003 domain. If the migrated passwords do not meet the requirements of the password policy in the target Windows Server 2003 domain, this will not prevent the migrated users from logging onto the Windows Server 2003 domain. However, it will be necessary for all affected users to change their passwords immediately at logon, to a password that complies with the policy in the target domain.





• Analyse the results of the design summary for the source Windows Server 2003 domain and perform a gap analysis of the password policies to identify the design differences.


♦ The first option is to implement the new (Windows Server 2003 Active Directory) password policy in the source Windows Server 2003 domain.

♦ The second option is to implement the “migration object and resource management infrastructure (ORMI) strategy” devised by this design methodology. This strategy involves the generation of a temporary ORMI within each target Windows Server 2003 domain, to provide the temporary destination OUs, GPOs and DOC permissions for all migrated directory objects from one or more source Windows Server 2003 domains. The “migration ORMI” will provide the required segregation of these migrated directory objects from the rest of the domain, but still support their presence within the target domain, and use of the target domain to log on and so on. Although the “migration ORMI” does not provide an alternative to the first option, it can assist the migration of security principals between the source and target Windows Server 2003 domains. The step



“determination of the specific pre-migration tasks to prepare a target domain” provides more information on the design and implementation of a “migration ORMI”.




The source Windows Server 2003 domain contains only a small number of user accounts (such as a few hundred or less). This option is not feasible for a source Windows Server 2003 domain supporting a large number of users and a requirement to implement a maximum password age policy of only a few days. This is because as soon as the passwords for a large number of users expire, it will be necessary for all such users to change their passwords, for example, simultaneously at 9am on Monday morning, which would generate a significant disruption to the performance of the Windows Server 2003 domain controller for the domain hosting the PDC Emulator FSMO role. Note that this criterion assumes that the interim source Windows Server 2003 domain is a fully functioning production domain prior to execution of migration path “E” or “F”.

The IT administration culture within the organisation, generated by the IT administration team, supports the execution of a significant change to the working habits of users within a short period, without generation of excessive complaints or queries. Within organisations where such changes meet strong resistance, this option is not feasible.



The most opportune time to implement the change in the password policy for a source Windows Server 2003 domain based upon this information.


♦ The design and implementation of a temporary “migration ORMI”, supported by option 2 supports the segregation of migrated directory objects, and supports the coexistence of the source and target domains during the migration phase.

♦ This option is suitable for scenarios where a single or few Windows Server 2003 domains will be the target for migration paths “E” or “F”, and will eventually support the migration of a large number of security principals from interim Windows Server 2003 and / or legacy Windows NT 4.0 and Windows 2000 domains.



♦ This design methodology recommends option 2 where possible. Where there is a requirement for the use of option 2 and the “migration ORMI”, see the step “determination of the specific pre-migration tasks to prepare a target domain” for details on determination of the design requirements for a “migration ORMI”.



The target Windows Server 2003 domain is the target for the migration of security principals from two or more source domains (as part of a domain consolidation approach).

The target Windows Server 2003 domain will receive a large number of migrated security principals that may all require a change in password. As all password changes in Windows Server 2003 domains focus on the domain controller hosting the PDC Emulator FSMO role, this single domain controller may be subjected to a significantly increased workload.

♦ The selection of this option would force all migrated users to change their passwords at first logon. The enabling of all migrated user accounts and the requirement to permit all users to logon simultaneously using their Active Directory accounts, may disrupt the continuity of the Windows Server 2003 domain controller hosting the PDC Emulator FSMO role. Hence, this design methodology does not recommend the selection of option 3.

When determining the design requirements to establish the trust relationship between a source and target Windows Server 2003, to support execution of inter-forest migration path “F”, consider the following:

To support execution of inter-forest migration path “F”, it is necessary to establish a minimum of a mono-directional trust relationship between the source and target domains, where the source domain trusts the target domain. However, where there is a requirement for coexistence between the two domains during the migration project, then it is necessary to establish bi-directional trust relationships between the source and target domains.


• To support the execution of inter-forest migration path “F”, and


In most organisations, the trust relationships will hence seem a permanent feature of the final Windows Server 2003 and (interim) Windows Server 2003 domain, until it is possible to decommission the interim source Windows Server 2003 domain.


• Access to the source domain and Active Directory database by the designated administrator performing the migration to the target domain, and





Note that Windows Server 2003 domain controllers automatically enable SID filtering on all external trust relationships. Hence, where there is a requirement for an instance of migration path “F” (inter-forest) to support the use of SIDHistory, then it is necessary to disable SID filtering on the incoming external trust relationship on the trusting source Windows Server 2003 domain. Disable SID filtering on a source Windows Server 2003 domain using the following “Netdom” command at a command prompt on a source domain Windows Server 2003 domain controller: “Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:No /usero:<domainadministratorAcct> /passwordo:<domainadminpwd>”. (Please note the “o” at the end of /usero: and /passwordo: switches).

When determining the design requirements to establish the trust relationship between a source (interim) Windows Server 2003 and target Windows Server 2003 domain (for intra-forest migration path “E”), consider the following:

Because the source (interim) Windows Server 2003 domain is in the same forest as the target Windows Server 2003 domain, for intra-forest migration path “E”, it is not necessary to create any external trust relationships, as all domains trust each other via bi-directional transitive trust relationships that follow tree hierarchies, and tree root-to-forest root relationships.

Note however, where an organisation is planning on the consolidation of multiple legacy Windows Server 2003 domains within a forest, and the forest supports a number of domain trees and domains, then it may be necessary to design and implement short-cut trust relationships. This design methodology proposes execution of the following approach to determine the requirements for the design and implementation of short-cut trust relationships within a forest, to support execution of the optional intra-forest migration path “E”:

• Generate or obtain a diagram of the domains within the Windows Server 2003 forest and highlight the source and target Windows Server 2003 domains

• Using the built-in bi-directional transitive trust relationships between the domains in the forest, determine the number of “hops” between the source and target domains. This design methodology proposes that where it is possible to identify three or more than “hops” (as intra-forest trusts) between the source and target domains, generate a direct short-cut trust relationship between them.

• In the following example diagram, which illustrates this approach, it is possible to identify five default intra-forest transitive trust relationships between the source and target Windows Server 2003 domains. A single short-cut trust between the source and target domains would speed up the migration process, as it would reduce the requirements for LDAP referrals up the domain hierarchies in the domain trees, and between domain trees via the forest root domain.



ForestRoot

TreeRoot

TreeRoot

1

2

3

45Target Windows

Server 2003 Domain

Source Windows Server 2003 Domain


Figure 44.10: Illustration of Requirement for Design of Short-Cut Trust Relationships

When determining the design requirements to raise a source Windows Server 2003 domain to “Windows 2000 Native” or “Windows Server 2003” domain functional level to support execution of intra-forest migration path “E”, consider the following:

The execution of certain domain migration activities between domains in the same forest requires the source domain to be operating in native mode, and not in mixed mode. For example, when executing a domain migration exercise using ADMT, it is possible to note the following if the source domain is note operating in “Windows 2000 Native” or “Windows Server 2003” domain functional level:

• The “Undo Last Migration Wizard” of ADMT version 2.0 is unavailable

• Where migrated user account objects belong to migrated security groups, which both originally reside in different source domains for a target Windows Server 2003 domain, then the migrated user accounts will not retain their memberships to the migrated group objects from other forest / trusted domains. This is the temporary breaking of a closed “user” set.

Where an existing legacy Windows Server 2003 domain is currently operating in mixed mode, specifically to support one or more legacy Windows NT 4.0 BDCs or Windows 2000 domain controllers, then it may not be possible to raise the domain mode via the upgrade or decommissioning of the BDCs / Windows 2000 domain controllers. Their continued presence may represent a reflection for a significant business or technical requirement. To identify the opportunity to upgrade or decommission the BDC(s) / Windows 2000 domain controllers, this design methodology recommends a re-evaluation of the business and / or technical requirements to retain these domain controllers, and hence determine whether these requirements are still justified and viable.

When determining the design requirements for the pre-migration tasks to prepare the network infrastructure to support execution of migration paths “E” or “F”, consider the following:

The preparatory tasks that require design to prepare the network infrastructure (which supports both the source and target domains) for migration paths “E” or “F” include the following:

The preparation of the name resolution infrastructure to support execution of migration paths “E” or “F” and coexistence between the source and target domains

The preparation of components of the supporting network infrastructure to permit execution of migration paths “E” or “F”




When determining the design requirements for the preparation of the name resolution infrastructure within the organisation, to support execution of the migration paths “E” or “F” and coexistence of the source and target domains, consider the following:

Where there is a requirement for coexistence between the source and target domains, then the migrated security principals in the target Windows Server 2003 will require access to the source domain, and all domains that trust the source domain. This hence implies the requirement for the migration of all existing trust-relationships, between the source domain and all other domains that trust the source domain, to the target domain and these external domains. For example, a source Windows Server 2003 domain, “Domain1” has a trust relationship with another internal or external Windows Server 2003 domain, “Domain2”, which trusts “Domain1”, and hence permits security principals from “Domain1” to access its resources. “Domain1” is the source domain for migration paths “E” or “F” to a target Windows Server 2003 domain “Domain3”. To support continued access for users in “Domain3”, migrated from “Domain1”, to resources in “Domain2”, it is necessary for “Domain2” to trust “Domain3”. This will hence permit migrated users, using their SIDHistory (SIDs from “Domain 1”) to access resources in “Domain2”. The name resolution infrastructure is hence required to support name resolution between the target Windows Server 2003 domain and other non-source domains for a specific execution instance of migration paths “E” or “F”.

To support the execution of migration paths “E” or “F”, the Windows Server 2003 domain controllers in the target domain must be able to locate the source domain and its domain controllers, and vice versa. As both Windows Server 2003 and Windows Server 2003 domains exclusively use DNS for name resolution, it is a simple process to enable concurrent support for both domain environments.


• Configure a Windows Server 2003 DNS server or another DNS server as an internal root DNS server.

• Configure the DNS server(s) supporting the source domain environment(s) to point to the internal root DNS server using a root hint, where necessary.

• Configure the internal root DNS server to use forwarder entries to, for example, a dedicated forwarder DNS server, residing with a firewall-partitioned network. See the Organisation-Wide Active Directory Plan process “Design of a DNS Infrastructure” for details.

When determining the design requirements for the preparation of components of the network infrastructure to permit execution of migration paths “E” or “F”, consider the following:

The execution of these migration paths, using (for example) ADMT version 2.0, requires network access between the source and target domain controllers, which may be impaired or impeded by, for example, the following:





• The presence of firewalls, between the network links that connect the source and target domain controllers, may prevent access to services. For example, if the target Windows Server 2003 domain controllers reside on the other side of a firewall from source Windows Server 2003 domain controllers, it may be necessary to open ports in the firewall identified in following table:



389 TCP LDAP


88 UDP Kerberos



Table 44.6: Internal Firewall Configuration Requirements to Support Execution of Migration Paths “E” or “F”

When determining the design requirements to prepare the network infrastructure to support execution of migration paths “E” or “F”, this design methodology proposes execution of the following approach:


• Identify any issues associated with this network infrastructure that may impair or impede the execution of migration paths “E” or “F”.


Prior to the execution of migration paths “E” or “F”, it is important to determine the dependencies and timescales for the completion of all parallel projects associated with the supporting network infrastructure. For example, parallel projects to redesign the network may impair or impede the migration, such as:



Where it is possible to identify any pending or proposed projects, associated with the supporting network infrastructure, that may impede the execution of any instance of migration paths “E” or “F”, then:

Identify the nature of the dependency generated by the parallel network project, and assess the impact on the execution of migration paths “E” or “F”.




When determining the design requirements for pre-migration tasks to prepare the Windows Server 2003 domain controllers for the source domain, for execution of migration paths “E” or “F”, consider the following:

The preparatory tasks that require design to prepare the Windows Server 2003 domain controllers within a source domain include the following:

Enabling TCP/IP transport support to support migration of SIDHistory using inter-forest migration paths “F”

Identification and configuration of a password export server (a Windows Server 2003 domain controller in the source domain) to support password migration using migration paths “E” or “F”

Preparation of Windows Server 2003 domain controllers in the source domain for migration to the target domain

To enable support for the use of inter-forest migrations and the use of SIDHistory, it is necessary to create the “TcpipClientSupport” registry entry on all source Windows Server 2003 domain controllers targeted by the ADMT.

It is possible to create this registry entry automatically or manually. When the requirements to migrate the SIDs for user accounts is selected, during the first test run of the ADMT version 2.0 user migration wizard, where the wizard does not detect this registry entry on the source domain controller, it will create it automatically. To create this entry manually, it is necessary to use the security context of a user account in the Administrators group to create the “TcpipClientSupport” registry entry, as a DWORD value with a value entry of 1, in the “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA” registry key on a Windows Server 2003 domain controller in the source domain.

When determining the design requirements for the process to create this registry entry on the source Windows Server 2003 domain controllers, consider the following:

The process must first backup the registry of the Windows Server 2003 domain controllers prior to implementation of this registry entry. Perform, for example, a system state backup, use the regedit.exe utility to export the entire registry to a “*.reg” file, or the resource kit tool “regback.exe” to export the five default registry hives.

The process may be automated using a script to first backup the registry and then import the required registry entry on all Windows Server 2003 domain controllers in the source domain, to which the ADMT tool will connect.

Where the organisation has identified the requirement for the migration of user passwords, it is necessary to prepare the Windows Server 2003 domain controller(s) in the source domain, to which the ADMT tool will connect. This design methodology proposes the execution of the following approach to determine the design requirements to prepare the source Windows Server 2003 domain controllers for password migration:

Determine the required password export server (PES) (a Windows Server 2003 domain controller in the source domain)




When determining the most appropriate Windows Server 2003 domain controller in the source domain to be the preferred password export server, consider the following:

The PES must have sufficient hardware resources to cope with the demands of the export, depending upon the numbers of user account objects migration paths “E” or “F” is required to process within the source domain. A Windows Server 2003 domain controller dedicated to this function, and not required to support logons and so on, is ideal.



The process to set up a PES and perform password migrations involves the execution of specific tasks within both the source and target domain. Note that it is only necessary to configure one PES server for each source Windows Server 2003 domain.


• At the server operating the ADMT in the target Windows Server 2003 domain, open a command prompt and navigate to the ADMT installation directory, such as “C:\Program Files\Active Directory Migration Tool”. At the command prompt, execute the following command to generate the password encryption key: “admt key <SourceDomainName> DriveLetter [Password]”, where:



• Note that the “password encryption key” requires secure transport between the target Windows Server 2003 domain controller, which generated the file, and the PES in the source domain. Although it is possible to save this file to a hard drive and transport it across the network, this design methodology strongly recommends the transport of this file (named *.pes) (which is only approximately 40 bytes in size) by hand between the two domain controllers, using, for example, a USB storage key. This will hence prevent the requirement to transport the key across the network and accidentally leave the key on a file system accessible by the network.


• Retrieve the “password encryption key” generated on a target Windows Server 2003 domain controller using the ADMT tool.


• Modify the registry entry “AllowPasswordExport”, located in the “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA” key, to



change the DWORD value from 0 to 1. A value of “0” disables the export of passwords by this PES.

• Reboot the PES.

When determining the design requirements for the preparation of existing Windows Server 2003 domain controllers within the source domain for migration to the target domain, consider the following:

ADMT cannot clone domain controllers from a source domain to a target domain. Where there is a requirement to migrate Windows Server 2003 domain controllers into the target domain, then the design methodology proposes execution of the following approach:

• Define the criteria for the identification and inclusion of existing Windows Server 2003 domain controllers into the scope for migration to the target domain, such as requirements for compliance with the attainment of a minimum numbers of domain controllers in the target domain, and hence the requirement for the migration of existing domain controllers, and so on.


• Ensuring that a minimum number of existing domain controllers are retained to continue to support the existing Windows Server 2003 domain environment and the coexistence phase, identify all domain controllers that require migration to the target domain.

• Execute the Active Directory Installation Wizard (dcpromo.exe) on the existing Windows Server 2003 domain controllers to demote them to member servers

• Migrate the Windows Server 2003 member server using ADMT, and execute security translation (from within the Computer Migration Wizard)

• Then, where necessary, execute the Active Directory Installation Wizard (dcpromo.exe) on the server to generate an additional domain controller for the target domain.

Note that any domain local groups referenced by security descriptors on the Windows Server 2003 domain controller that requires migration after demotion to member server require migration prior to joining the server to the target domain.

When determining the design requirements for pre-migration tasks to prepare the security principals within the source Windows Server 2003 domain, for execution of migration paths “E” or “F”, consider the following:

The preparatory tasks that require design to prepare the security principals within the source domain for execution of migration paths “E” or “F” include the following:



Requirements to prepare the source domain for preservation of closed “user” sets for intra-forest migration path “E”

Requirements to prepare the source domain for preservation of closed “resource” sets for intra-forest migration path “E”



When determining the design requirements for the creation of the migration credentials, employed in the execution of migration paths “E” or “F”, consider the following:

Migration paths “E” or “F” (and all other migration paths that may use ADMT version 2.0) require execution from the target domain, to perform a “pull” clone of directory objects and their data. The credentials (user accounts and security group memberships) used by the administrator performing the migration must hence support access to both the source and target domains.

This design methodology strongly recommends the creation of a single dedicated “migration” user account, assigned all appropriate group memberships in the source and target domain (across the prerequisite bi-directional trust relationships), in the target Windows Server 2003 domain. The use of a single migration account simplifies the management of the migration process, and the execution and auditing of the migration tasks.

The single migration user account should have membership to the Domain Admins group in the source and target domain.

Naturally, due to the nature and functionality of this account, access and use of the single migration user account should be restricted to users within an organisation delegated the right to execute migration tasks associated with migration paths “E” or “F”.

When determining the design requirements for the mapping and merging of existing security groups with security groups in the target domain, prior to the execution of migration paths “E” or “F”, consider the following:



• Execute an analysis of the design summary for the security group infrastructure in each appropriate ORMI for the target Windows Server 2003 domain(s) of a source Windows Server 2003 domain. Understand the following details of the security group infrastructure within the target domain:




• Execute a similar analysis of the design summary for the source Windows Server 2003 domain, to understand the details of the current custom security group infrastructure.








When determining the design requirements for the preparation of a source domain to preserve closed “user” sets, for intra-forest migration path “E”, consider the following:

It is necessary to prepare a source domain, to preserve closed “user” sets where it is possible to identify that well-known security principals are members of closed sets. Their natural exclusion from inter-domain migration will permanently break any closed sets in the source domain without the execution of the pre-migration preparatory tasks on the source domain. This is because the intra-forest migration of user account objects from a source domain, in which they currently gain access to resources and inherit permissions and rights via membership to the built-in security groups, will not maintain these access rights and permissions. It is hence necessary to reassign these permissions.

This design methodology proposes execution of the following approach to determine the design requirements for the process to prepare a source domain (to preserve closed “user” sets):

• Execute an analysis to identify all resources within a source domain that assign access permissions to built-in security groups, like Domain Admins, Domain Users, and so on. The Windows 2000 and Windows Server 2003 resource kits tools can assist in extraction of the DACLs and ACEs on resources in a source domain.

• Where it is possible to identify a large number of resources that assign access permissions to built-in security groups, identify the built-in security groups, and create corresponding Domain Local security groups. Create Global security groups to hold all security principals that currently rely upon membership to the built-in groups for access rights to resources, permissions, and rights. Add the Global security groups to the new Domain Local groups.

• Then create a SID mapping file that maps the SIDs for the well-known security groups to the new Domain Local groups.

• Execute the Security Translation Wizard using the SID mapping file and the “add” mode to perform a security translation on all relevant resources on the appropriate computers in the source domain.

Using the above approach, determine the design requirements for the process to execute these tasks. These tasks require execution as pre-migration tasks, to prepare a source Windows Server 2003 domain for intra-forest migration path “E” and preservation of closed “user” sets.

When determining the design requirements for the preparation of a source domain to preserve closed “resource” sets, for intra-forest migration path “E”, consider the following:



The preservation of closed “resource” sets during migration depends upon the co-migration of Domain Local security groups. Where this does not occur due, for example, to the requirements for the phased migration of “user”, “server” and “logical” partition of a source domain (see later for details of these terms), then this will temporarily break the closed “resource” sets.

To preserve the closed “resource” sets during the execution of the intra-forest migration path “E”, it is necessary to convert the Domain Local security groups manually into Universal security groups. This conversion naturally depends upon the domain functional level for the source Windows Server 2003 domain (for migration path “E”) to be operating at “Windows 2000 Native” or “Windows Server 2003”.

This design methodology proposes execution of the following approach to determine the design requirements for the process to prepare a source domain (to preserve closed “resource” sets):

• Execute an analysis to identify all Domain Local security groups used on multiple member computers for the assignment of permissions to resources on those computers, either directly or via membership to local security groups. The Windows 2000 / Windows Server 2003 resource kit tools can assist in identification of the DACLs and ACEs on the member computers, to identify any Domain Local security groups.

• Where it is possible to identify these Domain Local security groups, record the list of these groups and modify the description field on the groups, to mark them for conversion to Universal security groups during the pre-migration phase. It is necessary to record the list of these Domain Local groups to facilitate their manual conversion back to Domain Local groups following migration (as interim Universal security groups) to the target domain. It is necessary to execute the conversion back to Domain Local groups as a post-migration task for intra-forest migration path “E” (see the later step, “determination of the design requirements for the post-migration tasks” for details).

Using the above approach, determine the design requirements for the process to execute these tasks. These tasks require execution as pre-migration tasks, to prepare a source Windows Server 2003 domain for intra-forest migration path “E” and preservation of closed “resource” sets.

When determining the design requirements for the pre-migration tasks to prepare the member computers within a source Windows Server 2003 domain for migration and security translation, consider the following:










Determination of the requirements for the design and use of a SID mapping file to support and guide security translation by ADMT





• Windows 2000

• Windows XP



Where it is possible to identify any member computers that fail to comply with the above operating system specifications, such as version of installed service pack on Windows NT 4.0 servers and workstations, then determine the design requirements for the process to resolve these issues.















S-1-5-21-203558792-319624891-1381041710-1089, Natsum\User01 S-1-5-21-203558792-319624891-1381041710-1089, Natusm\User02S-1-5-21-203558792-319624891-1381041710-1089, Natusm\User03











• It is necessary to determine the design requirements for a process to scan all member servers in a source domain for their service account dependencies. The objective of this scan is to identify all service accounts that require migration to the target domain, and identify those accounts that require explicit exclusion from migration.

• The organisation and domain owner(s) may consider the use of dedicated service accounts, instead of dual or multi-function user accounts, as this will assist in prevention of malicious users taking advantage of the security loophole explained below.

It is important to ensure execution of the “Service Account Wizard” only against “trusted” computers within a source domain. This requirement is a reflection of a security loophole associated with the use of the ADMT version 2.0 “User Account Migration Wizard” to transition the user account objects. During the transition of the service accounts to a target domain, ADMT version 2.0 will reset the password for the service accounts. Hence, a malicious user with physical or network access to a member server in a source domain may enter an account with administrative permissions in the source domain against a service, but use an invalid password. This will prevent the service from starting with these credentials, but as ADMT will reset the password during transition of the service account, the service will start with the administrative credentials on the member server. The term “trusted” server hence implies servers with secured physical and network access, and access to manipulation of the services on the servers. Using this information, identify all potentially “un-trusted” member servers within the source domain and included within the scope of a domain migration path.


Determine the required migration tool / tool suite to support the execution of migration paths “E” or “F”

Determine and document the design requirements for the pre-migration tasks to prepare a source domain for the inter-forest migration of SIDs to the SIDHistory attribute of migrated security principals in the target domain.

Determine and document the design requirements for the pre-migration tasks to prepare a source domain for the migration of passwords for user accounts, from the source (interim) Windows Server 2003 domain to the target Windows Server 2003 domain

Determine and document the design requirements for the pre-migration tasks to prepare bi-directional trust relationships between the source and target domains, to support the execution of migration path “F”, and coexistence between the source and target domains during the migration phase.

Determine and document the design requirements for the pre-migration tasks to prepare short-cut trust relationships between source and target Windows Server 2003 domains in a forest, to support the execution of intra-forest migration path “E”.

Determine and document the design requirements for the pre-migration tasks to raise a source Windows Server 2003 domain to “Windows 2000 Native” or “Windows Server 2003” domain functional level, to enable features associated with the execution of intra-forest migration path “E”.

Determine and document the design requirements for the pre-migration tasks to prepare a name resolution infrastructure to support execution of migration paths “E”



or “F” and coexistence between the source and target domains during the migration phase.

Determine and document the design requirements for the preparation of all components and elements of the supporting network infrastructure to support the execution of migration paths “E” or “F”.

Determine and document the dependencies and timescales associated with any parallel projects for the supporting network infrastructure, which may impair or impede the execution of migration paths “E” or “F”.

Determine and document the design requirements for the pre-migration tasks to enable TCP/IP transport support by the appropriate source Windows Server 2003 domain controllers, to support the migration of SIDs to the SIDHistory attribute via execution of inter-forest migration path “F”.

Determine and document the design requirements for the pre-migration tasks to identify and configure a password export server (PES), to support the migration of user account passwords during the execution of migration paths “E” or “F”.

Determine and document the design requirements for the preparation of the existing Windows Server 2003 domain controllers for migration to the target domain

Determine and document the design requirements for the pre-migration tasks to create and prepare the credentials for the migration user account, to support execution of migration paths “E” or “F”.

Determine and document the design requirements for the mapping and merging of custom security groups in the source Windows Server 2003 domain to custom security groups in the target Windows Server 2003 domain, during execution of migration paths “E” or “F”.

Determine and document the design requirements for the preparation of the security principals in the source domain for preservation of closed “user” and “resource” sets, for intra-forest migration path “E”.

Determine and document the design requirements for the preparation of member computers within the source Windows Server 2003 domain for migration and security translation using ADMT, via execution of migration paths “E” or “F”.

Determine and document the design requirements for the preparation of member computers for service account transition to the target domain using ADMT, via execution of migration paths “E” or “F”.

5.9.1.2.4. Determination of the Specific Pre-Migration Tasks to Prepare a Target Domain

Consider the following when determining the pre-migration tasks, for the simple and optional migration paths “A”, “C”, “D”, “E”, “F”, “G”, and “H”, to prepare a target Windows Server 2003 / (interim) Windows 2000 domain for migration:

• Factor A25: Determination of the design requirements for the pre-migration tasks to prepare an existing target Windows Server 2003 forest for migration path “A”


Has identified the requirement for the execution of migration path “A” against one or more legacy Windows NT 4.0 domains

The upgraded Windows NT 4.0 domains are to become child domains within an existing Windows Server 2003 forest, and



Wishes to determine the design requirements for the pre-migration tasks, necessary to prepare the target Windows Server 2003 forest for reception of the upgraded Windows NT 4.0 domain(s)


The execution of the Active Directory Installation Wizard on the Windows NT 4.0 domain controller upgraded to a Windows Server 2003 server (see figure 44.15 for details of the second step in the migration tasks for migration path “A”) provides the following three domain creation options:

Figure 44.11: “Create New Domain Options” in Active Directory Installation Wizard When Executed on an Upgraded Windows NT 4.0 Domain Controller

The selection of the first option creates a new forest, and the option to select the “Windows Server 2003 Interim” or “Windows 2000 Mixed” forest functional levels for the new forest.

The selection of the second or third option, to join an existing Windows Server 2003 forest, will result in the upgraded domain “inheriting” the functional level of the target Windows Server 2003 forest.

This design methodology recommends raising the functional level of the forest to “Windows Server 2003 Interim” prior to the introduction of any upgraded Windows NT 4.0 domains. Note that although this functional level is associated with advanced features (see the Forest Plan process “Setting and Raising the Forest Functional Level” and figure 17.1 for details) it does preclude the addition of any new Windows 2000 domain controllers to any domain within the forest.

When determining the requirement to raise the functional level of the target Windows Server 2003 forest to “Windows Server 2003 Interim”, consider the following:

It is only necessary to execute this step where it is possible to identify compliance with the following criteria:

The target Windows Server 2003 forest is not currently at the “Windows Server 2003 Interim” forest functional level, and is instead at the default “Windows 2000”, and the forest root domain is at the “Windows 2000 Mixed” domain functional level, and



The forest owner(s) are unable to identify any future requirements to introduce Windows 2000 domain controllers into any current or new domains in the forest. Raising the forest functional level to “Windows Server 2003 Interim” precludes the introduction of new Windows 2000 domain controllers (built as new domain controllers or introduced as existing additional domain controllers via the execution of migration path “B”), and only supports Windows NT 4.0 BDCs and Windows Server 2003 domain controllers, and / or

The forest owner(s) have identified the requirement to raise the forest functional level to leverage new enabled features such as improved group membership replication and an improved Inter-Site Topology Generator (ISTG) algorithm.

Only when it is possible to identify compliance with these criteria may the forest owner(s) justifiably execute the irreversible action to raise the forest functional level to “Windows Server 2003 Interim”.

When determining the design requirements for the process to execute this action, consider the following:

The execution of this action requires the following:

• The security context of a user account that is a member of the Enterprise Admins group in the forest root domain

• The use of an LDAP client, such as “LDP.exe” or “ADSIEdit”, to modify the msDSBehavior-Version attribute

• Focus of the LDAP client to the Windows Server 2003 domain controller in the forest root domain hosting the Schema Master FSMO role.

The process to use ADSIEdit to raise the forest functional level to “Windows Server 2003 Interim” involves execution of the following steps:

• Connect to the Configuration partition in the target Windows Server 2003 forest (CN=Configuration,DC=<forestname>,DC=<top-level-domain>)

• Open the Properties dialog box for the “CN=Partitions” object

• Select the msDS-Behavior-Version attribute, and then click Edit.

• In the Value field, type 1 to raise the forest functional level to Windows Server 2003 interim, and then click OK. Note that a value of “2” sets the forest functional level to “Windows Server 2003”.


Determine and document the current functional level for a target Windows Server 2003 forest

Where the current functional level is not at “Windows Server 2003 Interim” or “Windows Server 2003”, determine and document the following:

The requirements to raise the functional level for the forest, and

Compliance with the criteria for the execution of this action

Where it is possible to attain compliance with the criteria for the execution of this irreversible action, then determine and document the design requirements for the process to raise the functional level for the forest.



• Factor B8: Understanding the pre-migration tasks to prepare a target domain for the simple and optional domain migration paths

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the pre-migration tasks, necessary to prepare a target domain for migration, for specific simple and optional domain migration paths.


The simple and optional migration paths “C”, “D”, “E”, “F”, “G”, and “H” all involve the use of migration techniques and tools to execute a migration from a legacy Windows NT 4.0 (“C”), Windows 2000 (“D”, “G”, and “H”), or Windows Server 2003 (“E” and “F”) domain to target Windows 2000 or Windows Server 2003 domains.

The objective of this step is to determine the design requirements for the pre-migration tasks necessary to prepare a target Windows 2000 (as an interim domain) or Windows Server 2003 domain for migration using migration paths “C”, “D”, “E”, “F”, “G”, and “H”.

This design methodology hence proposes execution of the following approach to support this objective:

Understand the scope of directory clean up tasks that require execution on a target Windows Server 2003 and / or Windows 2000 domain prior to execution of any of the simple and optional domain migration paths.

Determination of the design requirements for the pre-migration tasks to execute directory clean up tasks, specific to simple and optional domain migration paths, to prepare a target Windows 2000 / Windows Server 2003 domain

Determination of the design requirements for pre-migration tasks to prepare a target Windows Server 2003 domain for a domain migration using simple migration paths “C”, “D”, “E”, or “F”

Determination of the design requirements for pre-migration tasks to prepare a target (interim) Windows 2000 domain for a domain migration using:

Optional migration path “G” (for a Windows 2000 intra-forest domain consolidation migration), or

Optional migration path “H” (for a Windows 2000 inter-forest domain consolidation migration)

Determination of the design requirements for the implementation of the target Windows Server 2003 domain for simple migration paths “C”, “D”, “E”, or “F”.

• Factor A26: Understanding and determining the scope of directory clean up tasks

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand and determine the scope of directory clean up tasks that require execution on a target Windows Server 2003 and / or Windows 2000 domain, prior to execution of any of the domain migration paths.


Execution of directory clean up tasks on a target domain for a domain migration path is only necessary where it is possible to identify compliance with the following criteria:



The target domain is an existing Windows Server 2003 domain, created via an in-place upgrade of another Windows 2000 domain, or

The target domain is a new Windows Server 2003 domain, created as a pristine domain, but already populated with (legacy) directory objects and data from the execution of one or more earlier instances of migration paths “C”, “D”, “E”, or “F”, or

The target domain is an existing production Windows 2000 domain, or

The target domain is a new Windows 2000 domain, created as a pristine domain, but already populated with (legacy) directory objects and data from the execution of one or more earlier instances of migration paths “G” and / or “H”

Hence, where the target domain is an existing pristine Windows 2000 or Windows Server 2003 domain, devoid of legacy directory objects and data, then these domains are outside of the scope of pre-migration directory clean up tasks.

It is important to note that the scope of directory clean up tasks for Windows Server 2003 domains that comply with the above criteria is extremely limited. This is because these domains (typically) are not currently functioning as production domain environments, and hence have not collected potentially redundant objects.

The scope of directory clean up tasks for these non-production domains is hence restricted to targeting directory objects and data the domain has received, via earlier executions of migration paths “C”, “D”, “E”, or “F”, from one or more source domains. Ideally, there should be no requirements for directory clean up at all in these Windows Server 2003 domains, as the pre-migration directory clean up tasks for migration paths “C”, “D”, “E”, or “F”, will have already identified and removed any redundant objects and their data.

This design methodology will hence assume that the target Windows Server 2003 domains for migration paths “C”, “D”, “E”, or “F”, within the scope of pre-migration directory clean up tasks, are not currently functioning as production domain environments within the organisation. Where this assumption is invalid, then the onus is with the organisation to execute more intensive directory clean up investigations and activities on these domains.

The objective of these directory clean up tasks, as pre-migration tasks to prepare a target domain, are to prevent, for example, the generation of conflicts in object migration during execution of any of the domain migration paths, or the generation of any disruptions to the productivity of the migrated and existing users and computers.

For example, a target Windows 2000 or Windows Server 2003 domain contains five user account objects, each assigned to different applications and / or services within the production domain environment. The user names assigned to these user accounts reflect the application / service they support, such as “SQLUser”, “SQLAdmin”, or “ExchUser”, “ExchAdmin”, and so on. Where a parallel source Windows NT 4.0 and / or Windows 2000 domain also contains similar service account objects, also generically named to reflect the application / service they support, this may generate conflicts during migration, and even potentially disrupt the continued operation of these applications and / or services. Depending upon the configurations employed within the migration, the disruption may extend to just the applications / services in the source domain, or in both the source and target domains.

This design methodology hence proposes the pre-migration clean up of target domains, rather than the alternative approach not to prevent the occurrence of conflicts, followed by the subsequent requirements to execute post-migration troubleshooting and directory clean up tasks.

The nature of the domain migration paths defines the scope of directory clean up tasks within an in-scope target Windows 2000 and / or Windows Server 2003 domain. As



these migration paths are limited to the migration of only user, computer, and security group objects and their data, it is not necessary to execute extensive clean up tasks on directory objects and data these migration paths cannot clone to the target domain.

Using the above information, execute an analysis to identify and document all target Windows Server 2003 and Windows 2000 domains that comply with the criteria for inclusion within the scope of the pre-migration directory clean up tasks.

• Factor A27: Determination of the design requirements for the pre-migration tasks to execute directory clean up tasks on target Windows 2000 and Windows Server 2003 domains


Has identified the requirements for the migration of one or more existing Windows NT 4.0 or Windows 2000 domains to a target Windows Server 2003 or (interim) Windows 2000 domain

Can confirm the absence of a single organisation-wide formal naming convention for user, computer, and group objects within each source domain for any domain migration path

Has identified one or more target Windows Server 2003 and / or (interim) Windows 2000 domains within the scope of the pre-migration directory clean up tasks, and

Wishes to determine the design requirements for the pre-migration tasks, to execute directory clean up tasks on the target Windows Server 2003 and / or Windows 2000 domains, to prepare for execution of the domain migration paths


As discussed earlier, the scope of the directory clean up tasks is restricted to the preparation of a target Windows Server 2003 and / or Windows 2000 domain to identify and resolve naming conflicts for the following objects:



Group account objects

When determining the design requirements for the pre-migration directory clean up tasks on target domains, consider the following:

The requirements to identify and resolve object naming conflicts is self-explanatory, as the migration of directory objects into Windows Server 2003 or Windows 2000 Active Directory requires that all objects have a unique name. As stated above, this design methodology supports the prevention of conflict generation, rather than the resolution of conflicts as post-migration tasks.

It is possible to note the following about the occurrence of naming conflicts for these three object classes:

The occurrence of naming conflicts between these objects is a direct reflection of the presence and scope of object naming conventions within an organisation. This design methodology recommends the generation of a single, organisation-wide naming convention for Active Directory objects (see Organisation-Wide Active Directory Plan process “Design of Object Naming Models” for details) as this will prevent naming conflicts. However, within most organisations, it is not



possible to identify an existing single formal and organisation-wide naming convention, and instead it is possible to identify one or more of the following:

• The complete absence of any formal and informal naming conventions

• The presence of multiple autonomous divisions within the organisation that generate their own independent formal and / or informal naming conventions

• The presence of multiple formal and informal naming conventions within an organisation, due (for example) to the geographical distribution of a centralised or decentralised IT administration team

Where it is possible to identify compliance with one or more of the above scenarios within an organisation, then it is highly likely to identify naming conflicts for user, computer, and group objects. The conflicts require identification and resolution where they may occur collectively across multiple legacy source domains that require consolidation to a single target Windows Server 2003 domain and / or (interim) Windows 2000 domain.

This design methodology proposes execution of the following approach to determine the design requirement for pre-migration directory clean up tasks, to prepare a target Windows Server 2003 and / or Windows 2000 domain:

Execute an analysis of the source domain(s) that require migration, using domain migration paths, to each target Windows Server 2003 and / or Windows 2000 domain, to identify the presence of absence of any formal and informal naming conventions.

Where it is possible to identify the presence of one or more formal naming conventions, then execute the following:

• Determine their boundary and scope, with respect to the source domains. For example, within an organisation it is possible to identify three source domains (domains 1, 2, and 3) for one target Windows Server 2003 domain, using migration paths “C” and “D”. Between these three source domains, it is possible to identify only one formal naming convention. The single naming convention only supports the naming of all user and computer account objects within two of the three source domains (domains 1 and 2), and this hence represents the boundary and scope of this naming convention.

• Determine the in and out of scope objects collectively across all three source domains, and hence the nature and source(s) for potential naming conflicts. For example, extrapolating on the above example, the single naming convention hence does not support the naming of group objects in either of the three source domains, and the naming of user and computer objects in the one of the three source domains (domain 3). There is hence the potential for the generation of naming conflicts between group objects across all of the three source domains, and naming conflicts between user and computer account objects in domain 3 and those collectively in domains 1 and 2.

• Execute an analysis of the identified potential sources for naming conflicts to identify all name conflict instances. For example, an analysis of the names for the security group objects across all three domains identified:

♦ A number of instances of naming conflicts involving group objects across all three domains

♦ A number of instances of naming conflicts for user account objects within domain 3 and within domains 1 and 2 (both supported by a single naming convention for user account objects)



• Determine whether any of the identified objects have already been migrated to the common target Windows Server 2003 / Windows 2000 domain. Where it is possible to identify that the first instances of these name conflicting objects already exist in the target domain, it is appropriate to execute any name resolution actions on these objects in the target domain, and not in the original source domain.

• Determine the most appropriate course of action to resolve the name conflicts, where identified. This design methodology proposes the following options to resolve the identified name conflicts:

♦ Rename the first instances of the migrated objects, already in the target domain, or

♦ Rename the other instances of these name conflicting objects, still awaiting migration to the target domain, where a name conflicting instance of these objects already resides

Where it is not possible to identify any formal or informal naming conventions that support the naming of user, computer, or group objects in any of the source domains common to each target Windows Server 2003 / Windows 2000 domain, then execute the following:

• Execute an analysis of the user, computer, and group account objects in all source domains for each target domain, to identify the presence of any naming conflicts. The design methodology proposes the following approach to execute this analysis:

♦ Perform an export of the user, computer, and group objects from each source (Windows NT 4.0 / Windows 2000 / Windows Server 2003) domain (use, for example, the Windows NT 4.0 resource kit utility “addusers.exe” to extract lists of users and groups in Windows NT 4.0 and / Active Directory domains; use LDIFDE.exe to extract lists of objects per object class from Windows 2000 / Windows Server 2003 domains, and so on)

♦ Collate the exports into one spreadsheet and run a comparison to identify any naming conflicts between instances of each object class

• Determine the presence of any of the instances of naming conflicts in the target Windows Server 2003 or Windows 2000 domain

• Where it is possible to identify naming conflicts, then determine the most appropriate course of action to resolve the name conflicts, where identified

When determining the design requirements for the most appropriate course of action to address and resolve the identified naming conflicts, consider the following:

Following identification of the presence of naming conflicts for user, computer, and group objects it is now necessary to determine the design requirements for the process to resolve these conflicts. This process will subsequently require execution as a pre-migration task to prepare the target domain for execution of any of the domain migration paths, as appropriate.

Note that the renaming of “normal” user accounts to avoid conflicts will not significantly interfere in the productivity of the affected users, as the renaming of the user name for these account objects will not influence the SID for the accounts.

However, the renaming of “service” user accounts to avoid conflicts may significantly interfere in the productivity of the affected applications and / or services. Although the majority of applications and services will require only minor



configuration modification to support the use of a renamed service user account, some applications and services require either extensive modification to support the use of a renamed user account object. Note that some bespoke applications are “hard coded” to use a specific service user account name, and it may be unfeasible to engineer the application to use another service account.

It is important to asses any identified requirements for the mapping and merging of security groups with any identified naming conflicts. For example, where it is possible to identify a naming conflict between two security group objects in a source Windows NT 4.0 and a target Windows Server 2003 domain (already migrated from another parallel Windows NT 4.0 domain), then the naming conflict may be resolved via the use of the group mapping and merging wizard.

Renaming of computer account objects for client computers may generate less disruption than the renaming of computer account objects for servers. The names assigned to servers are often “hard coded” into applications and scripts, and deployment builds for operating systems, and so on. Changing the name of a server due to a naming conflict with another server may break many processes and hence requires careful evaluation.


Determine and document the presence of naming conflicts for user, computer, and group objects within all source domains common to each target Windows Server 2003 and / or Windows 2000 domain

Determine and document the requirements for the design of a process that reflects the required course of action to resolve the identified naming conflicts. This process will require execution as a pre-migration task for the appropriate domain migration path.

• Factor A28: Determination of the design requirements for the pre-migration tasks to prepare a target Windows Server 2003 domain for execution of migration paths “C”, “D”, “E”, or “F”


Has identified the requirements for the execution of one or more instances of the migration paths “C”, “D”, “E”, or “F”, and

Wishes to determine the design requirements for the pre-migration tasks to prepare each target Windows Server 2003 domain for the execution of these paths


The execution of migration paths “C”, “D”, “E”, or “F” involves the migration of directory objects and data from a legacy Windows NT 4.0 (path “C”), legacy Windows 2000 (path “D”), or interim Windows Server 2003 (“E” or “F”) domain to a target Windows Server 2003 domain.

The objective of this step is to determine all of the design requirements for the pre-migration tasks necessary to prepare a target Windows Server 2003 domain for execution of migration paths “C”, “D”, “E”, or “F”.

Note that this step does not consider the requirements for contingency or coexistence. The later steps within this process, “determination of the design requirements for a contingency plan” and “determination of the design requirements for a coexistence plan”, consider all of the design requirements for the preparatory tasks to support a



rollback of an existing source domain environment, and for continued coexistence during the migration phase.

Note that the pre-migration tasks discussed within this factor only represent those tasks that require design for execution, and thus the function of this step is to determine the design requirements for these tasks. As it is possible to identify a significant number of additional tasks for each of the migration paths “C”, “D”, “E”, or “F”, the later step within this process (“generation of the design for the migration checklists”) will provide a few examples of pre-migration tasks associated with each migration path, which do not require design for execution.

When determining the design requirements for the pre-migration tasks to prepare a target Windows Server 2003 domain for execution of migration paths “C”, “D”, “E”, or “F”, consider the following:

The preparatory tasks that require design for execution, to prepare a target Windows Server 2003 domain for execution of these domain migration paths include the following:

Preparation of a target Windows Server 2003 domain to support execution of:

• Inter-forest migration paths “C”, “D”, and “F” and

• Intra-forest migration paths “E”

Selection and preparation of the server required to operate the ADMT version 2.0 from within the target Windows Server 2003 domain

This design methodology will continue to support the use of ADMT version 2.0 when providing the considerations for the preparation of a target Windows Server 2003 domain for each of the migration paths “C”, “D”, “E”, and “F”.

When determining the design requirements for pre-migration tasks to prepare a target Windows Server 2003 domain for execution of migration paths “C”, “D”, “E”, or “F”, consider the following:

The preparatory tasks that require design to prepare a target Windows Server 2003 domain for migration paths “C”, “D”, “E”, or “F” include the following:

The preparation of a target Windows Server 2003 domain to support the use of SIDHistory for all inter-forest migration paths (“C”, “D”, and “F”)

The preparation of a target Windows Server 2003 domain to support the preservation of closed “user” and “resource” sets using the intra-forest migration path “E”

The preparation of a target Windows Server 2003 domain to support the migration of user passwords from one or more source domains, using ADMT and migration paths “C”, “D”, “E”, or “F”

The establishment and configuration (from the perspective of the target domain) of trust relationships to support execution of the migration paths, and coexistence between the source and target domains

Determination of the design requirements for one or more “migration ORMIs” within the target Windows Server 2003 domain to support execution of the migration paths

When determining the design requirements for the preparation of a target Windows Server 2003 domain to support the inter-forest migration of SIDs and use of the SIDHistory attribute (for migration paths “C”, “D”, and “F”), consider the following:



The inter-forest migration of SIDs from one or more legacy / external Windows domains requires execution of the following tasks within the target Windows Server 2003 domain:

• Enabling of auditing in the target domain for account management

• Raising the domain functional level of the target Windows Server 2003 domain

When determining the design requirements for the process to enable auditing of account management within a target Windows Server 2003 domain, consider the following:

• This design methodology recommends enabling of auditing for account management within the “Default Domain Controllers Policy” GPO implemented at the Domain Controllers OU. It is important to enable auditing in this default GPO as APIs, developed for earlier versions of the operating system, update in the default “Default Domain Controllers Policy” GPO.

• With auditing of user and group management enabled, this will generate entries in the Security Event Log on the domain controllers within the target domain. It is hence important to adjust the following parameters on the security event logs on the appropriate Windows Server 2003 domain controller(s) for the target domain:

♦ The size of the security event log, in KB (the required size of the event log will depend upon the number of user and group objects within the source domain and within the scope of migration paths “C”, “D”, “E” or “F”. The size of the log depends also upon the selected Event Log Wrapping parameter (see below). Where there is a requirement for the recommended option, to clear the even log manually, set the size of the log to be quite large, such as a few tens of MB. A small sized security event log, with a “clear log manually” option, will fill up quite quickly, and the domain controller may cease to function until an administrator clears the security event log. This may hence disrupt the migration process).





• Note that the Security Log Settings on Windows Server 2003 domain controllers default to "Maximum log size of 512 Kilobytes" and the Event Log Wrapping setting defaults to "Overwrite Events Older than 7 Days."

• This design methodology recommends that a Domain Administrator only enable the auditing of account management immediately prior to execution of migration paths “C”, “D”, “E” or “F”, unless already enabled within a source Windows 2000 domain. The enabling of auditing on the management of user and group account objects can generate a significant impact on the performance of a Windows Server 2003 domain controller, required to audit significant numbers of such management events.



When raising the domain functional level of the target domain to support the migration of SIDs from a source domain, and use of the SIDHistory attribute, consider the following:

• The target Windows Server 2003 domain must be operating at either the “Windows 2000 Native” or “Windows Server 2003” domain functional level to support the inter-forest migration of SIDs and the use of SIDHistory. This requirement hence implies that the target Windows Server 2003 domain cannot support any legacy Windows NT 4.0 domain controllers. For most instances of execution of migration paths “C”, “D”, “E”, or “F”, this is not an issue, and it is hence possible to raise the target Windows Server 2003 domain to the appropriate domain functional level. However, where creation of the target Windows Server 2003 domain was via the execution of the first or second approach in migration path “A” (in-place upgrade of a Windows NT 4.0 PDC / BDC respectively), then the target domain may still be required to support one or more legacy BDCs. The continued presence of these BDCs will hence prevent the migration of SIDs until it is possible to upgrade or decommission these legacy domain controllers.

• Where it is possible to identify the continued presence of one or more legacy Windows NT 4.0 domain controllers, then determine the feasibility of upgrading or decommissioning these domain controllers, without generating any disruptions to business continuity.

When determining the design requirements for the preparation of a target Windows Server 2003 domain to support the preservation of closed “user” and “resource” sets, using intra-forest migration path “E”, consider the following:

To support the preservation of closed “user” and “resource” sets during the execution of the intra-forest migration path “E”, it is necessary to raise the domain functional level of the target domain to the minimum of “Windows 2000 Native”, or (preferably, and where possible) the “Windows Server 2003” level. This requirement to raise the domain functional level is a reflection of the requirement to create and support Universal security groups within the forest for intra-forest migrations of closed “user” and “resource” sets.

Consider the information detailed above for raising the domain functional level of the target Windows Server 2003 domain.

When determining the design requirements to prepare a target Windows Server 2003 domain for migration of user account passwords from one or more source domains, consider the following:

To support the migration of user account passwords from one or more source domains, it is necessary to prepare the target Windows Server 2003 domain via execution of the following:

• Modification of the “Default Domain Controllers Policy” GPO, to support null credential access to the domain controllers in the target domain, via enabling the policy “Let Everyone permissions apply to anonymous users”.

• Modification of the membership “Pre-Windows 2000 Compatible Access” group via the addition of “Everyone” group as a member.

• Verification that the “restrictanonymous” REG_DWORD registry value is set to a data value of zero, in the registry key “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA”

• Verification that the “Pre-Windows 2000 Compatible Access” group is assigned the permissions “Read” and “Enumerate Entire SAM Domain” on



the object “CN=Server,CN=System,DC=<domain>,DC=<tld>”. It is possible to use ADSI Edit to verify the permissions on this object.

Note that these configurations effectively reduce the security level of the target domain, and hence should only be in effect until all password migration activities are completed. Following completion of all migration activities for all user account objects and their passwords from each source domain, reverse these configurations as post-migration tasks (see later for details).

When determining the design requirements to establish and configure trust relationships between the source and target domains, to support migration and coexistence, consider the following:

The preparatory tasks associated with the establishment and configuration of trust relationships with the target Windows Server 2003 domain are:

• Establishing trust relationships for inter-forest migration paths “C”, “D” and “F”

• Configuring external trust relationships to disable SID filtering

• Determining the requirements for the design and implementation of short-cut trust relationships for intra-forest migration path “E”

• Determining the requirements for the migration of trust relationships from the source to the target domain

To support execution of the inter-forest migration paths “C”, “D”, and “F”, it is necessary to establish a minimum of a mono-directional trust relationship between the source and target domains, with the source domain trusting the target domain. However, where there is a requirement for coexistence between the two domains during the migration project, then it is necessary to establish bi-directional trust relationships between the source and target domains.

To support the continued use of the SIDHistory attribute across a trust relationship with a legacy source domain, it is important to disable SID filtering on the trust relationship. Although Windows NT 4.0 domain controllers, with SP4 support the use of SID filtering, only Windows 2000 SP4 and Windows Server 2003 domain controllers enable SID filtering on external trusts automatically. It is hence necessary to disable SID filtering manually on all migration paths that support a source Windows 2000 or Windows Server 2003 domain (“D” and “F” respectively). See the pre-migration tasks for migration paths “D” and “F” (to prepare a source domain for migration) for details on disabling SID filtering on an external trust by the trusting domain.

To support the efficient execution of migration path “E” (intra-forest migration), ensure that it is not possible to identify more than three internal trusts between the source and target domains. See the pre-migration tasks for migration path “E” (to prepare a source domain) for details on the requirements for the design of short-cut trust relationships.

When determining the design requirements to migrate existing external trust relationships on the source domain to the target domain, consider the following:

• To ensure continued support during the migration and coexistence phase it is important to ensure that the target Windows Server 2003 domain trusts the same external domains as the source Windows NT 4.0, Windows 2000, or Windows Server 2003 domain. The following diagram provides examples of the trust relationships that require migration to the target Windows Server 2003 using the “Trust Migration Wizard”:



TreeRoot

Forestroot

Target Windows Server 2003 domain

for migration path “C”

TreeRoot

Trusting ExternalWindows NT 4.0

Domain

Target Windows Server 2003 domain for

migration path “E”

Source Windows Server 2003 domain

for migration path “E”

Source Windows NT 4.0 domain for migration path “C”


for migration path “D”

Existing single one-way trust relationship between source Windows Server

2003 domain and external Windows 2000 domain

Existing single one-way trust relationship between source Windows NT 4.0

domain and external Windows NT 4.0 domain

Trusting external Windows 2000

domain

Trusting external Windows Server

2003 domain

Source Windows Server 2003 domain for migration path “F”

Existing single one-way trust relationship between source

Windows Server 2003 domain and external Windows Server

2003 domain

C

E

D


2003 domain

Existing single one-way trust relationship between source Windows 2000 domain and external Windows Server

2003 domain

Source Windows 2000 domain for migration path “D”

F


for migration path “F”

LEGEND:Existing trust relationship from source domain with an external domain that requires migration to target Windows Server 2003 domain

Trust relationship, from trusting external domain to target Windows Server 2003 domain that requires creation using Trust Migration Wizard


Figure 44.12: Example of Requirements for the Migration of External Trusts for Paths “C”, “D”, “E”, and “F”

• When determining the requirements for the migration of existing trust relationships between a source domain and other external domains, consider the following:

♦ The ADMT version 2.0 Trust Migration Wizard is able to scan the existing trust relationships on the source domain and copy the mono or bi-directional trusts to the target domain, where it does not already exist.

♦ The trusts copied by the Trust Migration Wizard do not affect any trusts already in place on the target Windows Server 2003 domain

♦ This design methodology proposes the following approach to determine the requirements for the migration of trust relationships from a source domain to the target Windows Server 2003 domain:

Analyse the design summary for the source Windows NT 4.0, Windows 2000, or Windows Server 2003 domain and identify all existing external trust relationships

Identify all currently viable trust relationships where an external domain trusts a source domain. Although the Trust Migration Wizard can copy bi-directional trusts, as the primary objective of this step is to preserve continuity of access to resource by migrated security principals, an incoming trust to the target Windows Server 2003 domain may not be required.



Define criteria for the retention and migration of existing external trust relationships from a source domain, such as preservation of business continuity via the maintenance of access to remote resources in a trusting external domain, and so on.

For each identified outgoing external trust, where the source domain is trusted by an external domain, evaluate the trust against the predefined criteria for the retention of the trust. If it is possible to identify compliance with the predefined criteria, then determine the design requirements for the process to migrate the existing external trust relationships, from a source domain to the target Windows Server 2003 domain.

When determining the requirements for the design and use of one or more “migration ORMIs” for a target Windows Server 2003 domain, consider the following:

This design methodology proposes the concept of a “migration ORMI”, represented as a temporary ORMI within a target Windows Server 2003 domain and comprised of the same four components of a “normal” ORMI, such as:

• A Group Policy Object (GPO) infrastructure

• A Delegation of Control (DOC) infrastructure

• A Security Group infrastructure

• An Organizational Unit (OU) infrastructure

The objectives for the design and implementation of a “migration ORMI” within a target Windows Server 2003 domain are as follows:

• To provide a temporary object administration environments for the reception of migrated security principals from one or more source domains.

• To provide, via the components of the ORMI, a directory service environment that will facilitate and minimise errors in execution of the domain migration paths.

The following are examples of scenarios of how a “migration ORMI” can facilitate and minimise errors in execution of the domain migration paths:

• The migration of passwords from a source to target domain relies upon the presence of exactly similar or more restrictive password policies for user account objects in the source domain to the target domain. For example, a source Windows NT 4.0 domain employs a relaxed password policy that permits a minimum of only four characters, and not enforcement for the generation of complex passwords, and so on. User accounts and passwords migrated from this domain environment to a target Windows Server 2003 domain environment may require compliance with a new password policy that requires, for example, a minimum of eight character and complex passwords. The lack of compliance with the target password policies will force all migrated users immediately to change their migrated passwords to one that complies with the more stringent password policy in the Windows Server 2003 domain. A “migration ORMI” can “shield” users from a more stringent password policy, allow them to log on using their migrated accounts and existing passwords. The Domain Administrators may then slowly move users in batches to their final OU destinations in the target domain, and hence into compliance with the actual password policies. This phased approach will permit a more manageable number of support calls, and reduce any surges



in workload for password changes, targeted to the Windows Server 2003 domain controller hosting the PDC Emulator FSMO role for the target domain.

• The execution of a phased migration, that may consolidate multiple source domains into one or fewer target Windows Server 2003 domains, may result in the migration of many hundreds or thousands of security principals. To reduce the workload on the administrators of the target domain, the domain owners wish to delegate control of management of the migrated security principals to the current administrators within each respective source domain. Although the domain owners intend this delegation requirement to only last for the duration of the migration phase, there is hesitancy in delegating control to migrated security principals to administrators outside of the target domain, and thus have stated the following conditions:

♦ It is imperative that there is complete revocation of all temporary assigned DOC permissions as soon as the source domains are decommissioned and hence the migration phase completed.

♦ To ensure the complete revocation of all assigned DOC permissions, and prevention of the generation of any residue ACEs in ACLs, it is not permissible to implement the required permissions on “production” custom OUs.

• To support these requirements, the domain owners may wish to design and implement one or more “migration ORMIs”, such as one to support each source domain for a target Windows Server 2003 domain. It is possible to design the migration ORMIs to support all object management requirements for the migrated security principals, and requirements for temporary delegation of administration to external administrators, across the trust relationships between the source and target domains. After the phased introduction of the migrated objects into the “production” ORMI for a target Windows Server 2003 domain, it is possible to completely delete the OU infrastructure that supports each ORMI, all temporary objects (such as temporary security groups) contained in the OUs, and all implemented DOC permissions on the OU infrastructure for the migration ORMI.

• An organisation has identified the requirement to consolidate multiple source domains into one target Windows Server 2003 domain, which will represent and support many autonomous divisions within the organisation. The organisation has a requirement to conceal, from autonomous divisions already represented in the target domain, the security principal objects been migrated from other external source domains. There is also a requirement to secure all migrated security principals, once created within the target domain, until “released” for use, by the assigned users within the organisation. To support these requirements, it is possible to design and implement a “migration ORMI”, with the following characteristics:

♦ It is possible to configure an OU infrastructure within a “migration ORMI” with the “List Contents” permission set to “Deny” for all users in the domain, except the Domain Administrators. This would hence support the requirement to “conceal” all objects migrated into the domain from external source domains.

♦ It is possible to design and implement particularly restrictive GPOs to the “migration ORMI” to secure all of the user and computer account objects, as they are migrated directly into the OU infrastructure for the migration ORMI, from a source domain. Once the objects are ready for “release” and activation, it is possible to move the objects into the “production” ORMI and their final destination OUs.



• It is possible to identify, within the design for a production OU infrastructure (within a production ORMI) a maximum OU depth of ten OU levels from the root of the domain, and extremely long and descriptive names for OUs at each level. This bad practice design for an OU infrastructure consequently results in the generation of a distinguished name, for the deepest custom OUs, of more than one thousand characters long. These terminal OUs also represent the final destinations for migrated security principal objects from one or more source domains. The domain owners have a requirement to retain this OU design and target OUs as custom GPOs already provide specific policies to existing users and computers within these terminal OUs. Using ADMT version 2.0, the execution of a domain clone will fail if the distinguished name (DN) of the path to the destination OU is greater than one thousand characters long. A migration ORMI can support the temporary migration of these users, and support (via linking of GPOs to the temporary OU) the policy requirements for the migrated users and computers.

This design methodology proposes execution of the following approach to determine the design requirements for one or more “migration ORMIs” within a target Windows Server 2003 domain:

• Execute an analysis to identify any business and technical migration goals that will support the design and implementation of one or more “migration ORMIs” within one or more target Windows Server 2003 domains

• Execute an analysis of the design summary for the target Windows Server 2003 domain(s) and determine whether any required design aspects and components may:

♦ Present issues with the execution of a smooth migration from each source domain to the target domain, and

♦ Support the design and implementation of one or more “migration ORMIs”

• Where it is possible to identify the requirements for one or more target Windows Server 2003 domains to support the design and implementation of one or more “migration ORMIs” within, then it is necessary to determine the following:

♦ The number of migration ORMIs required within each target domain

♦ The upper boundary for each migration ORMI within each target domain

♦ The criteria for the decommissioning of the migration ORMIs within each target domain

♦ The requirements for the generation of a design for implementation of each migration ORMI within each target Windows Server 2003 domain

When determining the number of migration ORMIs required within each target domain, consider the following:

• The objectives and functions of each migration ORMI are to:

♦ Temporarily emulate aspects of the source domain environment for the migrated security principals, to prevent any issues on first induction of users and computers into the target domain environment

♦ Ensure and support the execution of an issue-free migration from the source domain to the target domain.



• These objectives and functions support a recommendation for the design and implementation of one temporary migration ORMI to support each source domain for the target Windows Server 2003 domain. However, with careful design a single “migration” ORMI could support multiple source domains without the generation of any conflicts or subsequent issues.

When determining the upper boundary for each required migration ORMI within a target domain, consider the following:

• The upper boundary for a migration ORMI refers to the highest point of creation of the top level OUs that will support the migration ORMI.

• This design methodology recommends assignment of an upper boundary, for all temporary migration ORMIs, represented by the root of the target.

• This design methodology does not recommend the creation of a migration ORMI beneath any planned production ORMIs for a target domain.

When determining the criteria for the decommissioning the migration ORMIs within a target domain, consider the following:

• As each migration ORMI is a temporary structure within a target domain, it will eventually require decommissioning and removal from the production domain.

• Although the onus is with the organisation to define the criteria for the decommissioning of each required migration ORMI, this design methodology proposes the following example criteria:

♦ The migration ORMI may be decommissioned where it no longer supports any more migrated security principals. This is because the Domain Administrators have completed all account initiation and induction activities and subsequently moved all migrated security principals to their final destination ORMIs.

♦ The migration ORMI may be decommissioned where it no longer supports any more migrated security principals and it is possible to identify compliance with the criteria for the decommissioning of each source domain for the migration ORMI. Compliance with these criteria implies redundancy of the migration ORMI and hence a requirement for decommissioning.

When determining the requirements for the generation of a design for implementation of each migration ORMI within each target Windows Server 2003 domain, consult the Domain Plan processes that support the design of a production ORMI, and consider the following:

• The scope of the migration ORMI is strictly limited to the temporary support of migrated security principals from one or more source domains. It is hence not necessary for the generation of a detailed design for a migration ORMI.

• The design for each required migration ORMI requires execution at the highest level, generating only those components of the design for an ORMI that will support migration goals and requirements.

When determining the design requirements for the selection and preparation of the server to operate the ADMT to execute migration paths “C”, “D”, “E”, and “F”, consider the following:

Prior to the selection of the server to operate ADMT, consider the following:



It is possible to install the ADMT on any member server or domain controller in the target domain

It is possible to execute ADMT locally at the server, or via a terminal service session to the server

This design methodology recommends the following selection criteria for the server to operate ADMT:

Select a Windows Server 2003 domain controller to operate the ADMT, as this will achieve better performance during execution of the migration wizards than the use of a member server.

Ensure that the Windows Server 2003 domain controller selected is either hosting the RID Master FSMO role, or is in close network proximity to the domain controller hosting this FSMO role for the target domain

Ensure that the Windows Server 2003 domain controller selected has adequate available RAM (approximately 10Mb and 4Kb for each migrated user)

Ensure that the administrative shares are enabled on the Windows Server 2003 domain controller


Determine and document the design requirements for the pre-migration tasks to prepare a target Windows Server 2003 domain for execution of migration paths “C”, “D”, “E”, or “F”

Determine and document the design requirements for the selection and preparation of a server to operate ADMT within the target domain

• Factor A29: Determination of the design requirements for the pre-migration tasks to prepare a target Windows 2000 domain for execution of migration paths “G” and / or “H”


Has identified the requirements for the execution of one or more instances of the optional migration paths “G” or “H” (Windows 2000 domain consolidation prior to migration of the consolidated Windows 2000 domain), and

Wishes to determine the design requirements for the pre-migration tasks to prepare each target Windows 2000 domain for the execution of these paths


The execution of migration paths “G” or “H” involves the migration of directory objects and data from one or more Windows 2000 domains to a target Windows 2000 domain in the same forest (intra-forest migration path “G”) or in another forest (inter-forest migration paths “H”).

The objective of this step is to determine all of the design requirements for the pre-migration tasks necessary to prepare a target Windows 2000 domain for execution of migration paths “G” or “H”.

Note that this step does not consider the requirements for contingency or coexistence. The later steps within this process, “determination of the design requirements for a contingency plan” and “determination of the design requirements for a coexistence plan”, consider all of the design requirements for the preparatory tasks to support a



rollback of an existing source domain environment, and for continued coexistence during the migration phase.

Note that the pre-migration tasks discussed within this factor only represent those tasks that require design for execution, and thus the function of this step is to determine the design requirements for these tasks. As it is possible to identify a significant number of additional tasks for each of the migration paths “G” or “H”, the later step within this process (“generation of the design for the migration checklists”) will provide a few examples of pre-migration tasks associated with each migration path, which do not require design for execution.

When determining the design requirements for the pre-migration tasks to prepare a target Windows 2000 domain for execution of migration paths “G” or “H”, consider the following:

The preparatory tasks that require design for execution, to prepare a target Windows 2000 domain for execution of these domain migration paths include the following:

Preparation of a target Windows 2000 domain to support execution of:

• Intra-forest migration paths “G” and

• Inter-forest migration path “H”

Selection and preparation of the server required to operate the ADMT version 2.0 from within the target Windows 2000 domain

This design methodology will continue to support the use of ADMT version 2.0 when providing the considerations for the preparation of a target Windows 2000 domain for each of the migration paths “G” and “H”.

When determining the design requirements for pre-migration tasks to prepare a target Windows 2000 domain for execution of migration paths “G” or “H”, consider the following:

The preparatory tasks that require design to prepare a target Windows 2000 domain for migration paths “G” or “H” include the following:

The preparation of a target Windows 2000 domain to support the use of SIDHistory for the inter-forest migration path “H”

The preparation of a target Windows 2000 domain to support the preservation of closed “user” and “resource” sets using the intra-forest migration path “G”

The preparation of a target Windows 2000 domain to support the migration of user passwords from one or more source domains, using ADMT and migration paths “G” or “H”

The establishment and configuration (from the perspective of the target domain) of trust relationships to support execution of the migration paths, and coexistence between the source and target domains

Determination of the design requirements for one or more “migration ORMIs” within the target Windows 2000 domain to support execution of the migration paths

When determining the design requirements for the preparation of a target Windows 2000 domain to support the inter-forest migration of SIDs and use of the SIDHistory attribute (for migration path “H”), consider the following:



The inter-forest migration of SIDs from one or more legacy / external Windows domains requires execution of the following tasks within the target Windows 2000 domain:

• Enabling of auditing in the target domain for account management

• Raising the domain mode of the target Windows 2000 domain

When determining the design requirements for the process to enable auditing of account management within a target Windows 2000 domain, consider the following:

• This design methodology recommends enabling of auditing for account management within the “Default Domain Controllers Policy” GPO implemented at the Domain Controllers OU. It is important to enable auditing in this default GPO as APIs, developed for earlier versions of the operating system, update in the default “Default Domain Controllers Policy” GPO.

• With auditing of user and group management enabled, this will generate entries in the Security Event Log on the domain controllers within the target domain. It is hence important to adjust the following parameters on the security event logs on the appropriate Windows 2000 domain controller(s) for the target domain:

♦ The size of the security event log, in KB (the required size of the event log will depend upon the number of user and group objects within the source domain and within the scope of migration path “H”. The size of the log depends also upon the selected Event Log Wrapping parameter (see below). Where there is a requirement for the recommended option, to clear the even log manually, set the size of the log to be quite large, such as a few tens of MB. A small sized security event log, with a “clear log manually” option, will fill up quite quickly, and the domain controller may cease to function until an administrator clears the security event log. This may hence disrupt the migration process).





• Note that the Security Log Settings on Windows 2000 domain controllers default to "Maximum log size of 512 Kilobytes" and the Event Log Wrapping setting defaults to "Overwrite Events Older than 7 Days."

• This design methodology recommends that a Domain Administrator only enable the auditing of account management immediately prior to execution of migration path “H”, unless already enabled within a source Windows 2000 domain. The enabling of auditing on the management of user and group account objects can generate a significant impact on the performance of a Windows 2000 domain controller, required to audit significant numbers of such management events.

When raising the domain mode of the target domain to support the migration of SIDs from a source domain, and use of the SIDHistory attribute, consider the following:



• The target Windows 2000 domain must be operating in “Windows 2000 Native Mode” to support the inter-forest migration of SIDs and the use of SIDHistory. This requirement hence implies that the target Windows 2000 domain cannot support any legacy Windows NT 4.0 domain controllers. For most instances of execution of migration paths “G” or “H”, this is not an issue, and it is hence possible to raise the target Windows 2000 domain to the appropriate domain mode. However, where creation of the target Windows 2000 domain was via the execution of the first or second approach in migration path “A” (in-place upgrade of a Windows NT 4.0 PDC / BDC respectively), then the target domain may still be required to support one or more legacy BDCs. The continued presence of these BDCs will hence prevent the migration of SIDs until it is possible to upgrade or decommission these legacy domain controllers.

• Where it is possible to identify the continued presence of one or more legacy Windows NT 4.0 domain controllers, then determine the feasibility of upgrading or decommissioning these domain controllers, without generating any disruptions to business continuity.

When determining the design requirements for the preparation of a target Windows 2000 domain to support the preservation of closed “user” and “resource” sets, using intra-forest migration path “G”, consider the following:

To support the preservation of closed “user” and “resource” sets during the execution of the intra-forest migration path “G”, it is necessary to raise the domain mode of the target domain to the “Windows 2000 Native” level. This requirement to raise the domain mode is a reflection of the requirement to create and support Universal security groups within the forest for intra-forest migrations of closed “user” and “resource” sets.

Consider the information detailed above for raising the domain mode of the target Windows 2000 domain.

When determining the design requirements to prepare a target Windows 2000 domain for migration of user account passwords from one or more source domains, consider the following:

To support the migration of user account passwords from one or more source domains, it is necessary to modify the membership “Pre-Windows 2000 Compatible Access” group via the addition of “Everyone” group as a member.

Note that this modification effectively reduces the security level of the target domain, and hence should only be in effect until all password migration activities are completed. Following completion of all migration activities for all user account objects and their passwords from each source domain, reverse these configurations as post-migration tasks (see later for details).

When determining the design requirements to establish and configure trust relationships between the source and target domains, to support migration and coexistence, consider the following:

The preparatory tasks associated with the establishment and configuration of trust relationships with the target Windows 2000 domain are:

• Establishing trust relationships for inter-forest migration path “H”

• Configuring external trust relationships to disable SID filtering

• Determining the requirements for the design and implementation of short-cut trust relationships for intra-forest migration path “G”



• Determining the requirements for the migration of trust relationships from the source to the target domain

To support execution of the inter-forest migration path “H”, it is necessary to establish a minimum of a mono-directional trust relationship between the source and target domains, with the source domain trusting the target domain. However, where there is a requirement for coexistence between the two domains during the migration project, then it is necessary to establish bi-directional trust relationships between the source and target domains.

To support the continued use of the SIDHistory attribute across a trust relationship with another Windows 2000 source domain, it is important to disable SID filtering on the trust relationship. All Windows 2000 domains with domain controllers running on SP4 enable SID filtering on external trusts automatically. See the pre-migration tasks for migration paths “D” and “F” (to prepare a source domain for migration) for details on disabling SID filtering on an external trust by the trusting domain.

To support the efficient execution of migration path “G” (intra-forest migration), ensure that it is not possible to identify more than three internal trusts between the source and target domains. See the pre-migration tasks for migration path “F” (to prepare a source domain) for details on the requirements for the design of short-cut trust relationships.

When determining the design requirements to migrate existing external trust relationships on the source domain to the target domain, consider the following:

• To ensure continued support during the migration and coexistence phase it is important to ensure that the target Windows 2000 domain trusts the same external domains as the source Windows 2000 domain. The following illustration provides examples of the trust relationships that require migration to the target Windows 2000 using the “Trust Migration Wizard”:

TreeRoot

Forestroot

TreeRoot

Target Windows 2000 domain for

migration path “E”

Source Windows 2000 domain for migration

path “G”

Existing single one-way trust relationship between

source Windows 2000 domain and external

Windows 2000 domain

Trusting external Windows 2000

domain


2003 domain

Source Windows 2000 domain for migration path “H”

Existing single one-way trust relationship between source Windows 2000 domain and

external Windows Server 2003 domain

GH

Target Windows 2000 domain for migration

path “H”

LEGEND:Existing trust relationship from source domain with an external domain that requires migration to target Windows 2000 domain

Trust relationship, from trusting external domain to target Windows 2000 domain that requires creation using Trust Migration Wizard


Figure 44.13: Example of Requirements for the Migration of External Trusts for Paths “G” and “H”

• When determining the requirements for the migration of existing trust relationships between a source domain and other external domains, consider the following:



♦ The ADMT version 2.0 Trust Migration Wizard is able to scan the existing trust relationships on the source domain and copy the mono or bi-directional trusts to the target domain, where it does not already exist.

♦ The trusts copied by the Trust Migration Wizard do not affect any trusts already in place on the target Windows 2000 domain

♦ This design methodology proposes the following approach to determine the requirements for the migration of trust relationships from a source domain to the target Windows 2000 domain:

Analyse the design summary for the source Windows 2000 domain and identify all existing external trust relationships

Identify all currently viable trust relationships where an external domain trusts a source domain. Although the Trust Migration Wizard can copy bi-directional trusts, as the primary objective of this step is to preserve continuity of access to resource by migrated security principals, an incoming trust to the target Windows 2000 domain may not be required.

Define criteria for the retention and migration of existing external trust relationships from a source domain, such as preservation of business continuity via the maintenance of access to remote resources in a trusting external domain, and so on.

For each identified outgoing external trust, where the source domain is trusted by an external domain, evaluate the trust against the predefined criteria for the retention of the trust. If it is possible to identify compliance with the predefined criteria, then determine the design requirements for the process to migrate the existing external trust relationships, from a source domain to the target Windows 2000 domain.

When determining the requirements for the design and use of one or more “migration ORMIs” for a target Windows 2000 domain, consider the following:

This design methodology proposes the concept of a “migration ORMI”, represented as a temporary ORMI within a target Windows 2000 domain and comprised of the same four components of a “normal” ORMI, such as:

• A Group Policy Object (GPO) infrastructure

• A Delegation of Control (DOC) infrastructure

• A Security Group infrastructure

• An Organizational Unit (OU) infrastructure

The objectives for the design and implementation of a “migration ORMI” within a target Windows 2000 domain are as follows:

• To provide a temporary object administration environments for the reception of migrated security principals from one or more source domains.

• To provide, via the components of the ORMI, a directory service environment that will facilitate and minimise errors in execution of the domain migration paths.



See earlier for examples of scenarios of how a “migration ORMI” can facilitate and minimise errors in execution of the domain migration paths

When determining the design requirements for the selection and preparation of the server to operate the ADMT to execute migration paths “G”, and “H”, consider the following:

Prior to the selection of the server to operate ADMT, consider the following:

It is possible to install the ADMT on any member server or domain controller in the target domain

It is possible to execute ADMT locally at the server, or via a terminal service session to the server

This design methodology recommends the following selection criteria for the server to operate ADMT:

Select a Windows 2000 domain controller to operate the ADMT, as this will achieve better performance during execution of the migration wizards than the use of a member server.

Ensure that the Windows 2000 domain controller selected is either hosting the RID Master FSMO role, or is in close network proximity to the domain controller hosting this FSMO role for the target domain

Ensure that the Windows 2000 domain controller selected has adequate available RAM (approximately 10Mb and 4Kb for each migrated user)

Ensure the administrative shares are enabled on the Windows 2000 domain controller operating ADMT version 2.0


Determine and document the design requirements for the pre-migration tasks to prepare a target Windows 2000 domain for execution of migration paths “G” or “H”

Determine and document the design requirements for the selection and preparation of a server to operate ADMT within the target domain

• Factor A30: Determination of the design requirements for the pre-migration tasks to deploy a target Windows Server 2003 domain for migration paths “C”, “D”, “E”, or “F”


Has identified the requirement(s) for the migration of one or more legacy Windows NT 4.0, Windows 2000, and / or Windows Server 2003 domains to a target Windows Server 2003 domain, and

Wishes to determine the design requirements for the pre-migration tasks to deploy the target Windows Server 2003 domain(s) (and supporting Active Directory infrastructure) into the production environment, to support execution of migration paths “C”, “D”, “E”, or “F”


The most important prerequisite for the execution of migration paths “C”, “D”, “E”, or “F” is the presence of the target Windows Server 2003 domain or domains for each source Windows NT 4.0, Windows 2000, and Windows Server 2003 domain.



To support this prerequisite, it is hence necessary to execute pre-migration activities to deploy each Windows Server 2003 domain, required to represent the target domain for migration paths “C”, “D”, “E”, or “F”.

The objective of this step is hence to determine the design requirements for the process to deploy each required Windows Server 2003 domain, essential to the execution of migration paths “C”, “D”, “E”, or “F”.

When determining the design requirements for the deployment of the target Windows Server 2003 domains, consider the following:

The target domain environment must support the migration requirements for migration paths “C”, “D”, “E”, or “F”

All dependencies associated with the implementation of the target domain(s) require observation and compliance

This design methodology proposes the following approach towards determination of the design requirements for the deployment of the target Windows Server 2003 domain(s):

Determine the scope of the deployment of each required target Windows Server 2003 domain

Determine the dependencies that require observation for the deployment of each required target Windows Server 2003 domain

Determine the deployment tasks that require design, and the design requirements for these tasks

Determine the required sequence for execution of the identified deployment tasks

When determining the scope of the deployment of each required target Windows Server 2003 domain, consider the following:

The design components of the target Windows Server 2003 domain infrastructure, which require deployment during the pre-migration phase for migration paths “C”, “D”, “E”, or “F”, define scope of the deployment.

When determining the scope of the deployment of a target Windows Server 2003 domain, the following options are available:

Deploy the entire Windows Server 2003 Active Directory infrastructure, regardless of the number of actual target domains, designed forests and non-target domains. This hence implies the deployment of all forests and domains, all supporting components of this infrastructure, such as the entire DNS infrastructure, entire Site infrastructure, all required domain controllers, and so on.

Deploy the minimum number and aspects of the components of a supporting infrastructure (such as DNS, Site infrastructure, placeholder forest root domains, tree root domains, and so on) required to support each required target domain infrastructure, and all of the design components for each target domain.

Deploy the minimum number of components and aspects of the Windows Server 2003 Active Directory and target domain infrastructure required to support the execution and completion of all pre-migration and migration activities associated with migration paths “C”, “D”, “E”, or “F”.

When determining the requirement for the execution of the first option, to deploy the entire Windows Server 2003 Active Directory infrastructure, during the pre-migration phase for migration paths “C”, “D”, “E”, or “F”, consider the following:



Note that the scope of these pre-migration tasks may infringe upon the scope of the Deployment Plan for the Windows Server 2003 Active Directory infrastructure. Where there is overlap, ensure the reflection of this overlap within the scope of the Deployment Plan.

The selection of this option is only feasible where the target Windows Server 2003 Active Directory infrastructure has a simple design comprising of, for example, the following components and aspects:

• A single forest supporting only one or a few domains

• A single simple DNS and supporting network infrastructure

• The requirement for the Active Directory infrastructure to support only one or two physical locations, where existing users and computers are within the scope of migration paths “C”, “D”, “E”, or “F”, and so on.

This design methodology does not recommend the selection of this option where the design for a new Windows Server 2003 Active Directory infrastructure is complex and incorporates, for example, multiple forests, multiple domains within each forest, multiple geographical locations to represent the domains, a complex supporting LAN and WAN infrastructure, a complex DNS infrastructure, and so on. This type of Active Directory infrastructure will require significant time to deploy and such activities may, for example, require additional resources or utilise key resources and hence impede the execution of the migration paths. There are also significant logistical issues to resolve to deploy this entire infrastructure, such as procurement, delivery, installation, and configuration of new servers, server rooms in remote locations, and so on, and associated financial and administrative overheads.

To execute this deploy the entire Windows Server 2003 Active Directory infrastructure for an organisation, it will be necessary to implement all tested, piloted, and verified design components within the Organisation-Wide Active Directory Plan, each Forest and Site Plan for each required forest, and each Domain Plan for each required domain. See later for details on the design of a process for implementation.

When determining the requirement for the execution of the second option, to deploy each target Windows Server 2003 domain in its entirety (all required domain design components and aspects), but only a minimal supporting infrastructure, during the pre-migration phase for migration paths “C”, “D”, “E”, or “F”, consider the following:

The selection of this option is only technically possible and logically feasible where the entire Windows Server 2003 Active Directory infrastructure is complex, and comprises of one or more forests and multiple domains, geographical locations where domains require representation, and so on.

This design methodology hence only recommends the selection and execution of this option where it is possible to identify compliance with the following example criteria:

• The design for the entire Windows Server 2003 Active Directory infrastructure is quite complex.

• One or more migration requirements for migration paths “C”, “D”, “E”, or “F” depend upon the presence of all design aspects and components of each target domain.



• The entire deployment of each required target Windows Server 2003 domain will not involve complex and lengthy activities, and is not associated with multiple physical locations, significant resource overheads, and so on.

• The time required for the execution of all deployment activities, to deploy each target domain in its entirety and the minimum supporting infrastructure to support each deployed domain, does not impede the migration schedule for this project.

• The organisation anticipates and accepts partitioning of the deployment activities, to focus on the completion of all migration phase activities prior to all other non-migration related deployment activities for the new Windows Server 2003 Active Directory infrastructure.

When determining the requirement for the execution of the third option, to deploy only the minimum design components and aspects of the entire Windows Server 2003 Active Directory infrastructure, during the pre-migration phase for migration paths “C”, “D”, “E”, or “F”, consider the following:

Although the selection and execution of this option requires the most planning to carefully partition, prioritise, and schedule deployment activities, it is the most feasible option for any organisation, regardless of the complexity of their design for a Windows Server 2003 Active Directory infrastructure.

This design methodology recommends the selection and execution of this option where it is possible to identify compliance with the following example criteria:

• The organisation has identified a requirement to complete all migration activities as soon as possible. Reducing the time required to prepare the target domain environment to support execution of migration paths “C”, “D”, “E”, or “F” hence shortens the pre-migration phase. For example, an organisation has identified a migration goal to complete all migration activities by a certain date, to support the deployment and use of a new Active Directory-integrated line of business application, such as Exchange Server 2003, or a CRM solution. Reducing the time to complete migration will ensure all users and computers are migrated across to the Windows Server 2003 Active Directory infrastructure and hence able to use the new applications and services.

• The organisation is willing to complete all non-migration activities, to deploy the remainder of the Windows Server 2003 Active Directory infrastructure, after completion of all migration activities.

• The organisation is willing to spend time partitioning the design for the Windows Server 2003 Active Directory infrastructure into migration-dependent and non-migration dependent design components and aspects that require deployment into the production environment.

When determining the dependencies that require observation for the deployment of the target Windows Server 2003 Active Directory infrastructure, consider the following:

To support the execution of migration paths “C”, “D”, “E”, or “F”, it is necessary to identify compliance with all of the following minimum deployment requirements for the target Windows Server 2003 domain environment (note that the following are not the domain preparation requirements, which are discussed in detail later):

The target domain is deployed, fully operational, and available on the same network as the existing source domain(s) for migration paths “C”, “D”, “E”, or “F”.



The target domain environment has a (recommended) minimum of two domain controllers configured and running, using the designed standard Windows Server 2003 domain controller build.

The target domain environment is running in either “Windows 2000 Native” or “Windows Server 2003” domain functional level, to support the migration of SIDs from the source Windows NT 4.0 / Windows 2000 / Windows Server 2003 domain into the SIDHistory attribute of migrated security principals.

The target domain environment contains either the final destination OUs for the migrated security principals, or the interim “migration ORMI”, with supporting temporary OU infrastructure.

When determining compliance with the deployment of the required target domain for migration paths “C”, “D”, “E”, or “F”, consider the following:

It is possible to create the target Windows Server 2003 domain for migration paths “C”, “D”, “E”, or “F” either as:

• A pristine domain to receive the migrated directory objects from the legacy domains, using these migration paths, or

• Via an in-place upgrade of a legacy Windows NT 4.0 or Windows 2000 domain

Where it is possible to identify that the required target domain requires creation via completion of an in-place upgrade migration path (“A” or “B”) then it is necessary to determine the dependencies and timelines upon its presence to support execution of migration paths “C”, “D”, “E”, or “F”.

Where a target domain is not a forest root domain within a proposed Windows Server 2003 Active Directory forest, then implementation of this domain depends upon the completed implementation / presence of the forest root domain. Note that it may be possible to identify the requirement for the creation of the forest root domain as either:

• A pristine and dedicated placeholder forest root domain, and hence not the target for any instances of migration paths “C”, “D”, “E”, or “F”, or

• As a pristine dual-function forest root domain, and hence the target for one or more instances of execution of migration paths “C”, “D”, “E”, or “F”, or

• As an in-place upgrade from a legacy Windows NT 4.0 or Windows 2000 domain, or

• As an in-place upgrade from a legacy Windows NT 4.0 or Windows 2000 domain and as the target for one or more instances of execution of migration paths “C”, “D”, “E”, or “F”

Where it is possible to identify the requirement for the creation of a forest root domain prior to the target Windows Server 2003 domain, then determine the required mode for its creation, and hence the dependencies and timelines upon its presence to support the forest.

Where a target domain is not a forest root domain, but a child domain within a tree of domains in a Windows Server 2003 forest, then implementation of this domain depends upon the completed implementation / presence of each parent domain, the tree root domain, and the forest root domain.



When determining compliance with the deployment of the minimum number of Windows Server 2003 domain controllers in the required target domain for migration paths “C”, “D”, “E”, or “F”, consider the following:

The requirements for the presence of the minimum recommended two Windows Server 2003 domain controllers, in each target domain, generates dependencies upon the following:

• The completion of all activities associated with procurement, delivery, installation, and hardware configuration activities for the two Windows Server 2003 domain controllers (assuming new server hardware), or

• The completion of all activities associated with hardware upgrade procurement, delivery, installation, and hardware configuration activities for two existing servers to support the role of Windows Server 2003 domain controllers, and

• Completion of the standard server build(s) for the Windows Server 2003 domain controllers and the medium for delivery and installation of the build(s).

Note that the hardware upgrade of existing servers to become Windows Server 2003 domain controllers either implies the redundancy of the role(s) of the existing servers, or an upgrade of their role(s), such as the in-place upgrade of an existing Windows 2000 domain controller to create the target domain. Hence, it is important to ascertain any dependencies upon the continued presence of these two servers prior to their transformation into Windows Server 2003 domain controllers.

It is also important to ensure completion of all Windows Server 2003 operating system licence procurement activities to support the implementation of the target Windows Server 2003 domain.

When determining compliance with the requirement to ensure that the target domain environment is running in either “Windows 2000 Native” or “Windows Server 2003” domain functional level, consider the following:

Compliance with this requirement is a prerequisite to the execution of migrations paths “C”, “D”, or “F” to support the population and use of the SIDHistory attribute.

Where the target Windows Server 2003 domain requires creation via an in-place upgrade of a legacy Windows NT 4.0 domain, using migration path “A”, then it is necessary to upgrade or decommission all currently supported BDCs in that domain. Once all BDCs are removed (via upgrades or decommissions) from the target Windows Server 2003 domain, it is possible to then raise the domain functional level to “Windows 2000 Native” or “Windows Server 2003”.

Where the target Windows Server 2003 domain requires creation via an in-place upgrade of a legacy Windows 2000 domain, using migration path “B”, this does not necessarily imply support for raising the domain functional level. This is because the legacy Windows 2000 domain, prior to execution of the in-place upgrade, may currently support one or more BDCs, and hence be operating in “Windows 2000 Mixed Mode”. This hence requires retention of this domain functional level until it is possible to upgrade or remove all BDCs from the domain before or after the upgrade to a Windows Server 2003 domain.

Where it is possible to identify such dependencies on the continued presence of any legacy BDCs within a target Windows Server 2003 domain, then determine the timelines and dependencies for the upgrade or removal of these BDCs. It is important to note that in some scenarios, there may be a requirement to retain



these BDCs until it is possible to terminate all dependencies upon their continued presence.

When determining compliance with the requirement to ensure that the target domain environment contains either the final destination OUs for the migrated security principals, or the interim “migration ORMI”, consider the following:

The execution of migration paths “C”, “D”, “E”, or “F” relies upon the presence of a suitable container in the target domain environment for the directory objects migrated from the source domain(s). Although not a strict prerequisite for the execution of these migration paths, it is important to ensure that either:

• The final destination OU infrastructure is implemented within the target domain for all source domain security principals, or

• An interim “migration ORMI”, with a supporting temporary OU infrastructure is implemented in the target Windows Server 2003 domain

The implementation of the final designed OU infrastructure depends upon the following:

• The mapping of each source domain to one or more ORMIs that the target Windows Server 2003 domain is required to support

• The determination of the number of OUs / OU infrastructures that require implementation within the target Windows Server 2003 domain

Where an organisation has identified the requirement for the design and implementation of a “migration ORMI” (see above), then implementation of the appropriate destination custom OUs within this temporary infrastructure depends upon:

• Completion of the design for each required “migration ORMI” in the target Windows Server 2003 domain

• Implementation of each required “migration ORMI” to support the security principals migrated from each source domain

When determining the deployment tasks that require design, and the design requirements for these tasks, consider the following:

The previous steps in this factor have identified the scope for the deployment of the Windows Server 2003 Active Directory infrastructure, and the dependencies that require observation to implement the required scope of the Windows Server 2003 Active Directory infrastructure. It is not necessary to determine the design requirements for the deployment tasks to implement the target Windows Server 2003 domain(s) to support execution of migration paths “C”, “D”, “E”, or “F”.

This design methodology proposes the following approach to determine the deployment tasks that require design for execution as pre-migration tasks for migration paths “C”, “D”, “E”, or “F”:

Determine the precise deployment scope for the Windows Server 2003 Active Directory infrastructure, where option two or three was required (and not option one, which was to implement the Windows Server 2003 Active Directory infrastructure, in its entirety, as a pre-migration task for migration paths “C”, “D”, “E”, or “F”).

Determine the steps that require execution to implement the defined scope for the Windows Server 2003 Active Directory infrastructure, as a pre-migration task for migration paths “C”, “D”, “E”, or “F”.



When determining the precise deployment scope for the Windows Server 2003 Active Directory infrastructure, to support option two or three, consider the following:

As options two and three partitioned the design for the entire Windows Server 2003 Active Directory infrastructure, to support a limited deployment scope, it is necessary to partition all design components and aspects into the following two categories:

• Migration-dependent design components and aspects

• Non-migration dependent design components and aspects

The migration-dependent design components and aspects of a proposed Windows Server 2003 Active Directory infrastructure are those aspects that generate dependencies upon the execution of migration paths “C” and / or “D”. For example, the most important migration-dependent component of a proposed design for a Windows Server 2003 Active Directory infrastructure is the target Windows Server 2003 domain itself.

When identifying all migration-dependent components of a Windows Server 2003 Active Directory infrastructure that require deployment, this design methodology proposes execution of the following approach:

• For the second option (implement the entire target Windows Server 2003 domain, but only a minimal supporting infrastructure) the migration-dependent components are:

♦ All design components within the Domain Plan for the target Windows Server 2003 domain, and

♦ All components of the supporting infrastructure necessary to ensure the correct and normal operation of each required target Windows Server 2003 domain, such as:

All domains (such as parent, tree, and forest root domains) the target Windows Server 2003 domain is dependent upon

The DNS infrastructure

The Site infrastructure for the forest, where there is a requirement to implement the target Windows Server 2003 domain in multiple geographical locations as a pre-migration phase task

• For example, the design for a Windows Server 2003 Active Directory infrastructure is comprised of two forests, and three domains within each forest. A single target Windows Server 2003 (non-root) domain is required to support the migration of security principals from a single source Windows 2000 domain. The target Windows Server 2003 domain requires creation as a pristine domain, and not via an in-place upgrade of an existing Windows NT 4.0 or Windows 2000 domain. The source domain currently requires representation within three physical locations for the organisation, as does the design for the target Windows Server 2003 domain. As each location currently supports a local domain controller, due to the numbers of local users and applications that query the Active Directory, it is necessary to implement the target Windows Server 2003 in each location, as a pre-migration task for migration path “D”. Hence, the following design components of the proposed Windows Server 2003 Active Directory infrastructure represents the detailed deployment scope (for option two) to support the execution of migration path “D”:



♦ The deployment of the forest root domain for the target forest

♦ The deployment of the entire design for the actual target Windows Server 2003 domain, including the following:

The implementation of each required ORMI and migration ORMI (where required)

The implementation of any external trust relationships (where possible and required)

The raising of the domain functional level of the domain to “Windows 2000 Native” or “Windows Server 2003”

♦ The deployment of a minimum of three Windows Server 2003 domain controllers, using the design for the standard build, with deployment of a minimum of one domain controller in each required geographical location for the organisation

♦ The deployment of the Site infrastructure, as Sites, appropriate Site Link objects, and TCP/IP subnet-to-Site mappings, to support replication between the domain controllers for the target domain

♦ The deployment of the supporting DNS infrastructure

• For the third option (to deploy only the minimum design components and aspects of the entire Windows Server 2003 Active Directory infrastructure to support execution of migration paths “C”, “D”, “E”, or “F”) the migration-dependent components are:

♦ All domain components of the forest to support implementation of the target Windows Server 2003 domain (such as the tree and / or forest root domain(s), and so on)

♦ The following design components for the target Windows Server 2003 domain:

A minimum of two domain controllers, or one per required geographical location, which ever is greater, using the standard server build

The OU infrastructure for each required ORMI and / or migration ORMI

The GPO infrastructure for each required ORMI and / or migration ORMI (to reflect any predefined migration goals for migration paths “C”, “D”, “E”, or “F”)

♦ The minimal components of the design for the DNS infrastructure to support normal and continued name resolution between the deployed Windows Server 2003 domain controllers

♦ The minimal components of the design for a Site infrastructure, for each required forest, to support normal and continued replication between the deployed Windows Server 2003 domain controllers

When determining the precise steps that require execution to implement the defined scope for the Windows Server 2003 Active Directory infrastructure, as a pre-migration task for migration paths “C”, “D”, “E”, or “F”, consider the following:



Use the identified precise scope for the deployment of the Windows Server 2003 Active Directory infrastructure to identify all of the precise steps that require execution to implement this defined scope.

For example, where the precise scope includes an entire ORMI for a target Windows Server 2003 domain, then the precise steps to implement the required ORMI include:

• The creation of the OU infrastructure for the ORMI

• The creation of the security group objects (which do not require migration to the target domain from a source domain) to support the targeting of GPOs and DOC permissions

• The creation, implementation, targeting, and linking (where necessary) of each GPO object designed for initial implementation in the ORMI

• The implementation of all DOC permissions designed for initial implementation in the ORMI

Generate a list of all implementation steps, and determine the requirements for the design of the procedure to support execution of all precise implementation steps identified.

When determining the required sequence for execution of all identified deployment tasks, consider the following:

Execution of all identified deployment tasks must follow a specific sequence, which will influence the assignment of resource(s) to the execution of the deployment tasks, and the dependencies upon the execution of their assigned tasks.

Determination of the required sequence for execution of the identified deployment tasks is a simple matter of logically organising the tasks based upon their fundamental dependencies. This design methodology proposes the following approach to determine the required sequence for execution of the identified deployment tasks:

Partition all identified deployment tasks into large sections, such as “deployment of an ORMI within a target domain”, or “deployment of two Windows Server 2003 domain controllers in “location A”, or “deployment of the Site infrastructure for a forest”, and so on.

Then, for each large section, determine the existence and nature of any dependencies between it and the other sections, such as:

• To implement an ORMI it is first necessary to implement the domain controllers to create the target Windows Server 2003 domain

• To create the target Windows Server 2003 domain it is first necessary to implement the forest root domain

• To create the forest root domain, it is necessary to procure, install, and configure new servers, then deploy the standard Windows Server 2003 domain controller build to these servers, and then run the Active Directory Installation Wizard to create the forest root domain, and so on.

Once the dependencies between each large section of the deployment scope is identified, then run through the same process for all of the detailed implementation steps within each large section, such as:



• To create and implement a GPO infrastructure it is necessary to implement the supporting OU infrastructure, and to target a GPO it is necessary to implement the required security group objects

• To create the required security group objects, it is necessary to implement the OU infrastructure to hold the objects, and so on.


Determine and document the selected option to implement the Windows Server 2003 Active Directory infrastructure to support execution of migration paths “C”, “D”, “E”, or “F”, and hence definition of the required scope for deployment of the target Windows Server 2003 Active Directory infrastructure.

Determine and document the dependencies that require observation for the deployment of each required target Windows Server 2003 domain

Determine and document the deployment tasks that require design for execution, and the design requirements for these tasks

Determine and document the required sequence for the execution of the identified deployment tasks

5.9.1.3. Determination of the Design Requirements for the Migration Tasks

Consider the following information when determining the design requirements for the migration tasks to support each required migration path:

• Factor B9: Understanding the migration tasks that require determination for design and execution

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the migration tasks, for each supported migration path, that require determination for design and execution


The objectives for the execution of this step within this process are to determine the design requirements for the migration tasks necessary to execute each required “simple” and “optional” migration path.

Note that it is only necessary to determine the design requirements for the migration tasks for “simple” and “optional” migration paths because the migration tasks for “optional” migration paths are common to all “extended” migration paths that employ them. The next step in this process will generate the design for the execution of the identified migration tasks, based upon the results of this analysis.

The migration tasks represent all of the tasks necessary to execute the required migration path. Execution of the migration tasks associated with a specific migration path depends upon the completed execution of all associated pre-migration tasks.

This design methodology partitions this step, to determine the design requirements for the migration tasks of supported migration paths, into the following three sections:

Determination of the requirements for the design of the migration tasks to execute each required instance of migration path “A”, and supported approaches within migration path “A”



Determination of the requirements for the design of the migration tasks to execute each required instance of the inter-forest migration paths (“C”, “D”, “F” and “H”) using ADMT version 2.0

Determination of the requirements for the design of the migration tasks to execute each required instance of the intra-forest migration paths (“E” and “G”) using ADMT version 2.0

To execute a simple or optional migration path, it is necessary to make decisions to address and action a multitude of variables presented during execution of the paths. The objective of this step is to assist an organisation in the determination of their requirements for each variable presented during the execution of each supported migration path.

Knowledge of the design requirements (for the variables within each supported migration path) hence supports the generation of a design, manifested as a process, for the execution of the required migration paths.

It is important to note that the design requirements must reflect the specific migration goals exclusive and / or influential to the execution of each required instance of a migration path. For example, an organisation has identified the requirements for the execution of approach two for migration path “A” for two existing legacy domains.

A variable in the execution of this path is, for example, the requirement to state the required domain functional level for the upgraded Windows NT 4.0 domain, during execution of the Active Directory Installation Wizard. The required domain functional level will influence the continued support for existing domain controllers, and the introduction of new domain controllers operating on legacy operating systems. This decision may hence be unique for each existing Windows NT 4.0 domain within the scope of migration path “A”, as a reflection of the migration goals for each domain.

Note that there are no design requirements for the execution of the migration tasks for migration path “B”. Migration path “B” supports two approaches, with the following execution profiles:

Execution of the migration tasks for the first supported approach for migration path “B” involves a single step, which is the execution of an in-place upgrade of the operating system for an existing Windows 2000 domain controller to create a Windows Server 2003 domain controller. The in-place upgrade of a Windows 2000 domain controller preserves Active Directory, and hence no requirement to re-execute the Active Directory Installation Wizard.

Execution of the migration task for the second supported approach for migration path “B” also involves a single step, which is the execution of the Active Directory Installation Wizard on a new Windows Server 2003 server to create an additional Windows Server 2003 domain controller for an existing Windows 2000 domain. Note that where the target existing Windows 2000 forest supports a dedicated (placeholder) forest root domain, this design methodology recommends the introduction of the first Windows Server 2003 domain controller into this domain. This is because a dedicated forest root domain will support fewer logons and hence presents a reduced risk to the production environment.

The following diagram illustrates, at a very high level, the pre-migration and migration tasks for each approach in migration path “B”:



MIGRATIONPRE-MIGRATION

Windows Server 2003 Domain Controller

Approach 2Build new

Windows Server 2003 Server


Execution ofActive Directory

Installation Wizard

Approach 1

ExistingWindows 2000

domain controller


Figure 44.14: Comparison of Pre-Migration & Migration Tasks for Path “B”

The migration task for the first approach does not require any design for execution, as the fully automated in-place upgrade requires no intervention. The migration task for the second approach will not require any design decisions, as there are no requirements to create a new forest or domain, but simply add an additional domain controller to an existing forest and domain.

• Factor A31: Determination of the requirements for the design of the migration tasks to execute path “A”


Has identified the requirement(s) for the migration of one or more legacy Windows NT 4.0 domains using any one of the three supported approaches within migration path “A”, and

Wishes to determine the requirements for the design of each required instance of migration path “A”, and required approaches within migration path “A”


Execution of the migration tasks for any of the three supported approaches for migration path “A” involves the following two steps:

Execution of an in-place upgrade of the operating system for a Windows NT 4.0 PDC to create a Windows Server 2003 server

Execution of the Active Directory Installation Wizard on the upgraded Windows Server 2003 server to create a Windows Server 2003 domain controller

These two steps are common to all three approaches, regardless of the differences in pre-migration and post-migration tasks for these approaches. The following diagram illustrates the different (at a very high level) pre-migration tasks for each approach in migration path “A”, but the common migration tasks for each approach:



MIGRATIONPRE-MIGRATION

Second Step in Migration

Windows Server 2003 Domain Controller

First Step in Migration

UpgradedWindows Server 2003

Approach 1

ExistingNT4 PDC

Approach 2

Promote toNT4 PDC

ExistingNT4 BDC

1 2

Approach 3

New NT4 BDC

Promote toNT4 PDC

ReplicateWithExistingNT4 PDC

ConfigureNew

Server

1

2

3 4


1

Execution ofActive Directory

Installation Wizard


Figure 44.15: Comparison of Pre-Migration & Migration Tasks for Path “A”

From the above illustration, it is possible to note that the only step within the execution of the migration activities for migration path “A” that requires design is the second step, to execute the Active Directory Installation Wizard. The first step is a simple process and does not require design for execution.

Within the second step, it is possible to address the majority of questions prompted by the Active Directory Installation Wizard using the completed design for the target Windows Server 2003 Active Directory infrastructure. However, the design for the target Windows Server 2003 Active Directory may not address all of the decisions within the wizard.

For example, it may be necessary for this step to address the following three decisions:

Selection of the required functional level for the Windows Server 2003 Active Directory forest

Selection of the requirements for the default permissions for user and group objects in the Active Directory domain

Selection of the administrator password for directory service restore

Where it is possible to identify that the design for the target Windows Server 2003 domain does not address these three decisions, then consider the following:

When determining the required forest functional level for the new forest, consider the following:

Only when executing Active Directory Installation Wizard against an upgraded Windows NT 4.0 domain controller, with the requirement to create a new forest, is the unique option presented within the wizard to select the “Windows Server 2003 Interim” or “Windows 2000” forest functional level.

The Active Directory Installation Wizard does not present the forest functional level options where there is a requirement to select one of the alternative domain



creation options (“child domain in an existing domain tree” or “domain tree in an existing forest”). This is because the new domain will inherit the forest functional level of the forest it joins.

This design methodology recommends consultation of the Forest Plan process “Selection and Raising of the Forest Functional Level” for details of the considerations to support selection of the appropriate forest functional level.

When determining the requirements for selection of the default permissions for the user and group objects in the Active Directory domain, consider the following:

The Active Directory Installation Wizard presents the following two options for the selection of the default permissions for user and group objects in the Active Directory domain:

• Permissions compatible with pre-Windows 2000 server operating systems

• Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems

This design methodology recommends selection of the second option, as this is a more secure option. However, this design methodology only supports selection of the first option where it is possible to identify either of the following requirements:

• There is a requirement to continue the operation and support for applications and services running on legacy Windows NT 4.0 server operating systems, such as Remote Access Services. These applications and services require the ability to establish null authentication sessions with a domain controller. Windows 2000 and Windows Server 2003 domain controllers disable this function by default, as this otherwise reduces the level of security and permits anonymous users to read domain information.

• There is a requirement for the migration of passwords from a legacy source Windows NT 4.0 domain to the upgraded Windows Server 2003 domain, using ADMT version 2.0 to execute a simple or optional domain migration path.

Note that both of these requirements justify the selection of the first option, but it is important to note that both of these requirements must be temporary selections, and require reversal once:

• It is possible to replace or upgrade all existing Windows NT 4.0 member servers to run on Windows 2000 or Windows Server 2003 server operating systems, and / or

• The migration activities associated with one or more domain migration paths, which use the upgraded Windows Server 2003 domain as a target domain, are completed

Reversal of the first option involves removal of the “Everyone” and “Anonymous Logon” groups from the “Pre-Windows 2000 Compatible Access” group.

When determining the requirements for the selection of the directory service restore mode Administrator password, consider the following:

This password is only used to logon to the domain controller when it is booted up into directory service restore mode (as an “F8” boot option)

When selecting a password for this account, it is important to ensure that it is not the same password as the “Administrator” account, but another secure



password. This design methodology recommends that knowledge of this password should be restricted to the member of the Enterprise Admin group in the forest root domain.

Using the above information, determine and document the design requirements for the process to support the execution of each required approach and instance of a required approach for migration path “A”.

• Factor A32: Determination of the requirements for the design of the migration tasks to execute each required instance of the inter-forest migration paths (“C”, “D”, “F” and “H”) using ADMT 2.0


Has identified the requirement for the inter-forest migration of one or more source Windows NT 4.0, Windows 2000, or Windows Server 2003 domains to one or more target Windows Server 2003 or Windows 2000 domains, using one of the supported domain migration paths (“C”, “D”, “F” and “H”), and

Wishes to determine the design requirements for the execution of the migration tasks for the required inter-forest migration path(s)


The successful completion of any of the supported inter-forest migration paths requires adoption of a methodical approach towards the design and execution of each required path.

The objective of this step is to guide an organisation in the determination of the specific design requirements to support the execution of any of the supported inter-forest migration paths. The deliverables for this step are all of the design requirements necessary to support the generation of a design for the execution of the migration activities for one or more of these paths.

When determining the design requirements for the execution of an inter-forest migration path, consider the following:

This design methodology proposes the following approach towards determination of the design requirements to support execution of any of the inter-forest migration paths:

Determine the requirements to partition a source domain to support the phased execution of a migration path

Analyse the contents of each required partition for the source domain

Determine the requirements for the design of the scripted or manual execution of the ADMT version 2.0 migration wizards

Understand the steps involved in the execution of an inter-forest migration path using ADMT version 2.0

Determine the design requirements for the execution of each identified step for an inter-forest migration path

When determining the requirements to partition a source domain to support the phased execution of a migration path, consider the following:



This design methodology proposes execution of the following approach to determine the requirements to partition a source domain:

Understand the objectives and components of a partition within a source domain

Define criteria to support the requirements to partition a source domain for a phased migration approach, and determine compliance with criteria to support partitioning of a source domain

Where it not possible to identify compliance with the defined criteria, then go to the next step, to determine the requirements for the scripted or manual execution of the ADMT version 2.0 migration wizards.

Where it is possible to identify compliance with the defined criteria to support partitioning of a source domain, then define criteria for the partitioning of the domain.

When attempting to understand the objectives and components of a source domain partition, consider the following:

The objectives for partitioning of directory objects within a source domain are to:

Support the execution of the relevant migration path in discrete and controlled phases or batches, where the objects within each partition represent the scope of each phase / batch.

Bridge the logical aspects and components of the migration paths with the physical aspects and components of the source domain. For example, execution of the actual migration, to clone directory objects from a source domain to a target domain, not only changes the domain membership for the directory objects but also alters the working domain for the actual users and computers. This change is associated with a significant impact on the users as it may temporarily disrupt the continuity of their work.

To respect the objectives of a partition, the contents of each partition are required to reflect the physical aspects and components of a source domain, as well as the logical aspects and components of the relevant migration path.

This design methodology hence recommends the definition and identified of the following three types of partitions:

A “user” partition just to reflect directory objects that represent actual users and their computers within an organisation, and that require migration from the source domain to the target domain. For example, where there is a requirement for the discrete, phased migration of a complete department or remote physical location, then the partition that supports this requirement will comprise of all directory objects that represent all users and computers in that department / location.

A “server” partition just to reflect directory objects that represent actual member servers within an organisation that require migration from the source domain to the target domain. Note that it may be possible and necessary to define multiple “server” partitions within a source domain to reflect, for example, server types, roles, physical locations, ownership, and so on.

A “logical” partition just to reflect purely logical objects and do not represent actual users or computers, such as security group objects

When defining the criteria to support the requirements to partition a source domain for a phased migration approach, although the onus is with the organisation to define these criteria, this design methodology provides the following examples:



There is a requirement to partition a source domain where the scope of migration for a source domain currently contains many hundreds or thousands of user and computer account objects. Where a source domain contains only a few tens or a couple of hundred objects within the scope of migration, then it is not necessary to partition the source domain.

There is a requirement partition a source domain to ensure compliance with the following business and technical migration goals and reality considerations:

The “big bang” approach is not feasible due to scale of the migration from a source domain

The organisation has predefined business and technical migration goals that require a reduction in the mean time between failures

It is necessary to consider the physical distribution of users and computers within the organisation, represented within, and dependent upon, the source domain.

It is necessary to consider the number skilled and experienced resources available to execute the migration activities

It is necessary to consider the physical distribution of these resources within the organisation

It is necessary to consider the correlation of the distribution of the these resources with the distribution of the users and computers that require migration

It is necessary to consider the level of skill, experience, and trust in remote administrators to correctly execute the required migration activities

It is necessary to consider the availability of appropriate resources to provide post-migration support (floor-walking and help desk, and so on) for the migrated users and their client computers

It is necessary to consider the availability of appropriate resources to provide post-migration support for migrated member servers, applications, and services

It is necessary to attain an even distribution of migration tasks across each day and week of the migration phase to support resource availability and physical distribution within the organisation.

After definition of the required criteria, execute an analysis to determine compliance and hence the requirement to partition a source domain.

When defining the criteria to partition a source domain for a phased migration approach, although the onus is with the organisation to define these criteria, this design methodology provides the following examples:

There is a requirement to perform a phased migration of users and their computers in a source domain based upon their distribution across multiple physical locations

There is a requirement to perform a phased migration of users and their computers in a source domain based upon their membership / alignment to departments and divisional structures within the organisation

There is a requirement to perform a phased migration of member servers in a source domain based upon their distribution across multiple physical locations

There is a requirement to perform a phased migration of member servers in a source domain based upon their role(s) in the domain and organisation, such as application servers, web server farms, terminal server farms, and so on.



There is a requirement to perform a phased migration of member servers in a source domain based upon their exclusive alignment to departments and divisional structures within the organisation

Each “user” partition (to represent directory objects for actual users and computers) must contain a minimum of one hundred “collective” objects, and a maximum of one hundred and fifty “collective” objects (onus is with organisation to define these limits if this criterion is required). This hence implies, for example, that a department with fifty users and their computers (counted not as one hundred objects but fifty “collective” objects) requires co-migration with another department comprising of between fifty and one hundred users and their computers. (Note that it is not necessary to define any limits on the maximum number of objects a “logical” partition may hold, as the migration of these objects does not influence the productivity of the actual users and computers).

Each partition must reflect the logical distribution of the users, computers, and resources to execute the migration activities. For example, an organisation headquartered in London has three other remote offices in three other European cities. The administrators in the remote offices are not skilled in execution of post-migration tasks, understaffed and over utilised, and hence not capable of providing the required levels of post-migration support for their local users and computers. Hence, although the centralised IT administration team will execute the migrations from the London headquarters, it is necessary to dispatch skilled resources to each remote location to manage the execution of post-migration activities, in co-ordination with the migration tasks executed in London. As only a single team is available for dispatch to each remote location, it is necessary to partition the source domain to reflect the directory contents of each remote office location.

Using the above information, execute an analysis to identify all required “user”, “server”, and “logical” partitions for a source domain.

Following identification of the requirements to partition a source domain, and the required partitions, it is necessary to execute the following analyses against each identified “user” partition:

To support the design for the execution of migration tasks, it is necessary to:

Map the directory objects, within the source domain and scope of migration, to the contents of each required “user” partition

Map the directory objects within each “user” partition to each other, where necessary, possible, and appropriate

For example, an identified “user” partition supports one hundred “collective” object, as users and their client desktop and laptop computers. However, the source domain supports over ten thousand user and computer account objects, and it is hence necessary to:

Map the 100 users and their client computers within an identified “user” partition to their respective user and computer account objects in the source domain, and then

Map each user account object with one or more computer account objects, where necessary, possible, and appropriate.

When mapping the contents of an identified partition to their actual directory objects, within the majority of organisations where the user name for user account objects correlates to the actual users, it is hence a simple task to map these objects to the actual users. However, in most organisations, it is not so simple to map actual users and computers to their representative directory objects. Some organisation maintain spreadsheets mapping computer serial numbers of asset tags to computer account



names, and some organisation use asset tag details in the names for the computer account objects.

The requirement to map user account objects with computer account objects is a reflection of the necessary sequence for execution of migration tasks, and the objectives of the migration tasks. For example, following completion of the migration of a batch of user account objects, it is necessary to translate the security on the local user profiles on their client computers, and then execute a migration of their client computers. If the mapping of users to their client computers within a migration batch is unknown, it is not possible to execute these migration tasks, in their required sequence.

Determination of this information is particularly difficult in most organisations, unless pre-defined and continually maintained lists of such mappings exist. Some of the complications to this process to determine the mapping of users to computers include:

Some organisations permit users to roam amongst several client computers, although roaming is typically restricted to the logical boundaries of the respective department / divisional structure.

Some organisations do not assign all users with a client desktop or laptop computer, based upon their roles within the organisation, and instead only permit these users to use shared kiosk or team computers. Note that for these types of users, it is hence not necessary to map their accounts to one or more client computers.

Some users, although formally assigned an office location, are not permanently at that location and instead continually roam with laptop computers between multiple offices and, for example, locations for clients of the organisation.

Using the above information, execute an analysis of the contents of each “user” partition of a source domain and generate a list of user account to computer account mappings.

When determining the requirements for the design of the scripted or manual execution of the ADMT version 2.0 migration wizards, consider the following:

Most domain migration tools and suites, including ADMT version 2.0, support the manual or scripted (and hence automated) execution of the migration tasks supported by the tools and suites.

In addition to the manual execution of each required migration wizard, ADMT version 2.0 supports the use of command line and VBScript commands. It is possible to manually execute the command line commands, one at a time, or compile them into a simple batch file for simultaneous manual or scheduled execution. The VBScript commands require compilation into a VB script file (*.vbs) for manual or scheduled execution (for example, executed via a command inside a batch file).

Prior to the determination of the requirements for the use of the GUI tools, scripts, or batch files to execute the migration wizards and tasks, consider the following:

The use of the GUI tools to execute the migration tasks is associated with the following advantages:

• There is less design and preparation work required to execute the migration wizards using the GUI tools instead of scripts and batch files



• The use of the GUI tools support unexpected and unplanned changes to the migration scope, for a partition of a source domain, without the generation of any significant administrative overheads

• The use of the GUI tools are intuitive for the majority of administrators of legacy source and target domains

• The use of the GUI tools permit the instant identification of any issues or migration errors and failures as a result of the execution of a migration wizard

The use of GUI tools to execute the migration tasks is associated with the following disadvantages:

• The use of GUI tools requires the presence of migration administrators to execute the migration. Within the majority of organisations, it is necessary to execute the migrations outside of business hours and even during weekends and Bank / National Holidays. In addition, where the only available windows for execution of the migration tasks are, for example, during the “un-friendly” hours (between midnight and 6am) of a business week, this may cause issues for the migration administrators.

• The use of GUI tools is resource and time intensive where it is necessary to execute a significant number of migration wizard executions. In these scenarios, it is also very easy to become complacent and execute a significant error.

The use of scripts and batch files to execute the migration tasks is associated with the following advantages:

• It is possible to execute required migration tasks unattended and at any time required, including the “un-friendly” hours.

• The use of tested and verified scripts and batch files can eliminate the risk of human error in execution of migration tasks.

• The use of scripts and batch files can abstract the requirements for skilled resources to execute the required migration tasks. For example, there is a requirement for the execution of migration tasks in a remote physical location due to WAN link issues, and the remote administrators are not skilled in the execution of these tasks.

The use of scripts and batch files to execute the migration tasks is associated with the following disadvantages:

• Although Microsoft provides excellent samples of command line commands and VB scripts to execute all ADMT migration wizards and tasks, it is still necessary to design and test all scripts and supporting batch files. This may hence increase the time required to prepare for execution of the migration tasks, and generates significant administrative overheads.

• It may be necessary to create a significant number of batch files and scripts for each partition / batch migration, and it is hence also necessary to design and implement the following support infrastructure:

♦ A naming convention for the generated scripts and batch files, to support unambiguous differentiation between the scripts and batch files

♦ A storage location for each generated script and batch file, with permissions for access across the network, where required



♦ The schedules for local execution of migration scripts and batch files

• It is necessary to populate each required migration batch file / script with the details of all of the specific objects that require migration, although ADMT does support the use of “include” files for large lists of objects for migration.

• It is necessary to support changes to the scripts to accommodate unexpected and unplanned changes in the migration scope for each partition of a source domain.

Using the above information, determine the requirements for the design of procedures for the manual execution of each required migration task, or the design of scripts, batch files, and their supporting components (naming conventions, storage and distribution infrastructure, schedules for execution, and so on).

When attempting to understand the steps involved in the execution of an inter-forest migration path, consider the following:

This design methodology recommends execution of the following steps, in the order listed below, for each required inter-forest migration path:

Execute a migration of the trust relationships between each source domain and any other external domains it trusts using the “Trust Migration Wizard”

Where there is a requirement for the mapping and merging of source domain groups with target domain groups, then it is necessary to execute the following:

• Where the target domain groups already exist, then execute the “Group Mapping and Merging Wizard” to consolidate the required source domain groups with the required groups in the target domain

• Where the target groups for the consolidation of the source domain groups do not exist yet in the target domain, but still in the source domain, then:

♦ Execute the “Group Account Migration Wizard” to migrate the required groups from the source domain to the target domain, and then

♦ Execute the “Group Mapping and Merging Wizard” to consolidate the required source domain groups with the newly migrated target domain groups

Following completion of all group mapping and merging exercises, execute a migration of all remaining in-scope Global security group objects, within all identified “logical” partitions of the source domain, to the target domain.

Execute an analysis to identify all in-scope service account objects within the source domain, within each identified “server” partition

Execute a migration of the identified in-scope service account objects from the source to the target domain. Note that this design methodology requires execution of this step after all Global security groups are migrated to the target domain as most organisation include service user accounts into Global security groups, to assign permissions and rights, and so on.

Execute a migration of all user account objects in the source domain to the target domain, regardless of their association with any “user” partitions

Where there is a requirement to not use SIDHistory, then execute the Security Translation Wizard in “add” mode for each member server in each “server” partition



Select a “user” partition and execute the following:

• Execute a translation of the local user profiles, using the Security Translation Wizard, for the user accounts in the “user” partition

• Execute a migration of the client computers within the “user” partition

• Re-execute a migration of the user account objects within the “user” partition

• Where there is a requirement to not use SIDHistory, execute the Exchange Directory Migration Wizard in “add” mode, where necessary, against all Exchange 5.5 objects that represent users within the “user” partition.

Repeat the above process for all remaining identified “user” partitions of the source domain

Following completion of the migration of all “user” partitions, re-execute a migration of all Global security group objects

Execute a migration of all member servers within each identified “server” partition

Execute a migration of shared local groups (only in source Windows NT 4.0 domains) and Domain Local groups (only in source Windows 2000 and Windows Server 2003 domains) in each identified “logical” partition

Where there is a requirement to not use SIDHistory, re-execute the Exchange Directory Migration Wizard in “add” mode, where necessary, against all remaining Exchange 5.5 objects, such as distribution lists, custom recipients, organizations, sites, and containers.

Where there is a requirement to use scripts and batch files for the execution of one or more inter-forest migration paths, then use the above approach to execute the following:

Determine the number of “user”, “server”, and “logical” partitions identified for the source domain

Determine the number of scripts required to support each identified partition, considering the following:

• There is a requirement for one script to execute the migration of all Global security group objects in a source domain to the target domain

• There is a minimum requirement for one script for each “server” partition to identify all service user account objects

• There is a minimum requirement for one script for each “server” partition to migrate all identified service user account objects, employed by servers in each “server” partition, to the target domain

• There is a requirement for one script to execute the migration of all user account objects in the source domain to the target domain

• Where migration of SIDHistory is not required, then there is a minimum requirement for one script for each “server” partition to execute the Security Translation Wizard in “add” mode

• There is a minimum requirement for one script for each “user” partition to execute the security translation on the local user profiles for the computers within each “user” partition



• There is a minimum requirement for one script for each “user” partition to migrate all client computer account objects in each “user” partition to the target domain

• There is a minimum requirement for one script for each “user” partition to re-migrate all user account objects in each “user” partition to the target domain

• There is a requirement for one script to re-execute the migration of all Global security groups in the target domain

• There is a minimum requirement for one script for each “server” partition to migrate all member servers to the target domain

• There is a minimum requirement for one script for each “logical” partition to migrate all shared local and Domain Local groups in each “logical” partition to the target domain

Note that the above list does not include the scripts for the execution of the Group Mapping and Merging Wizard or the Exchange Director Wizard, as the requirements for the execution of these two migration tasks are not common to the majority of organisations.

For example, an organisation has identified the following requirements:

To partition a source Windows NT 4.0 domain into two “user” partitions, two “server” partitions, and one “logical” partition

Not to migrate SIDHistory from this domain

Use ADMT version 2.0 scripts to execute the migration tasks

The following diagram illustrates the scripts that require generation to support all required executions from this above example of a source Windows NT 4.0 domain and five identified partitions:



Source Windows NT 4.0 Domain

“Server” partition

“Logical” partition

“Server” partition

“User” partition

“User” partition

6 Script to translate local security profiles

7 Script to migrate client computer accounts

8 Script to re-migrate user accounts

8 Script to re-migrate user accounts

6 Script to translate local security profiles

7 Script to migrate client computer accounts

3 Script to migrate service accounts

2 Script to identify service accounts

5 Script to “Add” permissions (No SIDHIstory)

10 Script to migrate server accounts

3 Script to migrate service accounts

2 Script to identify service accounts

5 Script to “Add” permissions (No SIDHIstory)

10 Script to migrate server accounts

1 Script to migrate all global groups

9 Script to re-migrate all global groups

4 Script to migrate all user accounts

11 Script to migrate shared local groups

LEGEND:VB Script & / or Batch File to Execute Migration 1 Script execution sequence

between partition migrations


Figure 44.16: Example of Script Requirements for Inter-Forest Migration Using ADMT version 2.0

Note that it may be possible to consolidate the number of scripts required via the use of “include” files to abstract the names of the security principals from the scripts. This hence increases the portability of the scripts for application against multiple “user”, “server”, and “logical” partitions.

When determining the design requirements for the execution of the migration tasks for an inter-forest migration path, using ADMT version 2.0, consider the following:

To execute the migration of Global security groups from the source domain, using the Group Account Migration Wizard, it is necessary to determine the following design requirements:

Identify the target OU(s) for the migrated Global security groups



Determine the requirements to migrate the SID of the Global groups into the SIDHistory attribute on the migrated group object in the target domain

Prior to execution of the analysis to identify service accounts within the source domain, consider the following:

The Service Account Migration Wizard within ADMT will only identify domain user accounts used as service accounts for services and applications, and tag them for migration to the target domain. It will not identify and mark for migration the “Local System” or “Network Service” accounts, as these are “well known” accounts, and hence have a common SID, or any accounts in the local SAM database of member servers.

It is important to execute this step only against “trusted” computers within the source domain, and this hence reflects on the partitioning of the source domain to create the “server” partition(s).

Although it is not necessary to determine any design requirements for the execution of the Service Account Migration Wizard to identify the service accounts in a source domain, it is necessary to record the following:

• The list of service account objects identified by the Service Account Migration Wizard, and

• The list of servers in each “server” partition using one or more of the identified service accounts

• The mapping of services on these servers to the identified service accounts

To execute the migration of identified service accounts, using the User Account Migration Wizard, it is necessary to determine the following design requirements:

Identify the target OU(s) for the migrated service account objects

Determine the requirements to migrate the SID of the service accounts into the SIDHistory attribute on the migrated user account objects in the target domain

Determine the requirements for the design of a process to change the service accounts on all identified servers, in each “server partition, to use the new migrated service accounts.

To execute the migration of all user accounts in the source domain, using the User Account Migration Wizard, it is necessary to determine the following design requirements:

Identify the target OU(s) for the migrated user account objects

Determine the requirements to migrate the SID of the user accounts into the SIDHistory attribute on the migrated user account objects in the target domain

Determine the requirements for the exclusion of the migration of specific properties, and their directory data, for the user account objects.

Where an organisation does not wish to execute the migration of SIDs for migrated user accounts into the corresponding SIDHistory attributes, it is necessary to execute the Security Translation Wizard in “add” mode on all member computers. Prior to the execution of this migration task, consider the following:

The security translation, in “add” mode, will scan all required objects on the target computers and search for the ACEs on DACLs that refer to source domain objects the ADMT wizard has already migrated to the target domain. Where the



dispatched ADMT agent locates an entry, it will copy the permissions on that object assigned to the source domain account, add the corresponding migrated account in the target domain to the DACLs, and assign it the same permissions as the original source domain account.

The security translation requires execution against all objects on the target computers, except the user profiles.

It is important to translate the security, in the “add” mode, only on trusted servers. Where the source domain is a Windows NT 4.0 domain, then it is necessary to include at least one domain controller in the source domain, to translate security on the shared local groups. As the objective of this migration task is to ensure continued access to resources on existing servers in the source domain, by migrated user accounts (without using SID History), it is only necessary to include servers that host such resources. It is not necessary to include workstations in the scope of this migration task, unless users assign permissions to local resources on the workstations to domain user accounts.

After the completion of all migration activities, and all member servers and associated domain resources are migrated to the target domain, it is necessary to re-execute the Security Translation Wizard in “remove” mode. This is a post-migration task discussed in the next step, “determination of the design requirements for the post-migration tasks”.

It is not necessary to determine any design requirements for the execution of the Security Translation Wizard against servers in each “server” partition, to translate security in “add” mode.

Prior to determination of the design requirements to translate the security on the local user profiles on workstations within each “user” partition / batch, using the Security Translation Wizard, consider the following:

The Security Translation Wizard within ADMT will only translate local user profiles for computers running Windows NT 4.0, Windows 2000, Windows XP Professional, or Windows Server 2003.

It is necessary to execute the security translation in “replace” mode because the use of “add” mode may invalidate the assignment of software packages to the target users and computers using Windows Server 2003 Active Directory GPOs. For example, a software package created using Windows Installer version 2.0 may not uninstall correctly if the last user removes the application on a computer where the Security Translation Wizard employed the “add” mode.

Prior to execution of the Security Translation Wizard and the dispatch of the ADMT agent to the target computer, it is necessary to log all users off the target computer, and (where possible) stop all currently running services. This requirement is to prevent the Security Translation Wizard employing the “add” mode instead of “replace” during the security translation of local user profiles. The wizard will be unable to execute a “replace” translation if the dispatched ADMT agent is executing the translation on the target computer while a local use profile is still in use by user or service. If it is not necessary to translate the local user profiles for domain service accounts supporting running services, then it is not necessary to stop these services.

This design methodology hence recommends that the execution of all migration activities (for all migration paths) take place outside of business hours, so as not to disrupt use and business continuity.

To translate the security on the local user profiles on workstations within each “user” partition / batch, using the Security Translation Wizard, it is necessary to determine the following design requirements:



Determine the design requirements for the process, script, or batch file to log all users off the workstations within each target “user” partition, prior to execution of the security translation on the local user profiles.

When executing the security translation wizard, to translate security on local user profiles, only select “user profiles” in the “Translate Objects” page of the wizard.

Prior to determination of the design requirements to migrate workstations within each “user” partition / batch, using the Computer Account Migration Wizard, consider the following:

The Computer Account Migration Wizard within ADMT will perform the following actions:

• Clone the computer account object from the source domain to the target domain

• Dispatch an agent to the target workstations for the migrated computer account objects, and:

♦ Run a security translation, on the computer been migrated, for files and folders, local groups, printers, registry, shares, user profiles and rights, and

♦ Change the domain membership of the computer been migrated to the target domain

♦ Reboot the migrated computer after a pre-set period, to permit it to boot up as a member of the target domain

When determining the number of minutes to set before the migrated computer reboots, consider the following:

• The ADMT Computer Account Migration Wizard provides a default setting of five minutes before the migrated computer reboots.

• The migrated computer receives the reboot command upon dispatch of the ADMT agent to the computer. Note that where there is a concurrent requirement to translate security on the migrated computer, this occurs whilst a countdown timer for shutdown operates. Hence, where the target computer has, for example, a significant number of objects to translate security upon, has insufficient or over utilised hardware resources (CPU, RAM, and so on), then the computer may shutdown prior to completion of the security translation.

• Hence, in order to determine the most appropriate wait period prior to a reboot of a migrated computer, it is necessary to execute the following:

♦ Determine the security translation requirements on computers that require migration, and where required, the volume of objects that require translation. It is feasible to perform a test migration first to retrieve details of the number of objects that require security translation, and the time required to execute the translation.

♦ Use these findings to determine the minimum required number of minutes prior to the reboot of a migrated computer.

To execute the migration of the workstations within each “user” partition, using the Computer Account Migration Wizard, it is necessary to determine the following design requirements:



Identify the target OU(s) for the migrated computer account objects

Determine the security translation options on the target computers (to translate security on local files and folders, local groups, printers, registry, shares, user profiles and rights)

Determine the security translation mode (note can only execute a user rights translation on a migrated computer in the “add” mode)

Using the above approach, determine the number of minutes the migrated computer will wait for before executing a reboot

Determine the requirements to exclude specific properties of the computer account objects to be migrated

To re-execute the migration of the user account objects within each “user” partition, using the User Account Migration Wizard, it is necessary to determine the following design requirements:

As this is a re-migration of the user account objects, it is necessary to determine the account transition requirements for the source domain accounts. The options available are to disable the source user accounts, and set the number of days until the accounts expire. The user accounts will expire at midnight on the last day.

It is important to clear the “Migrate associated user groups” checkbox, but select the “fix users’ group memberships” option in the User Options page of the User Account Migration Wizard.

It is only necessary to disable the source user accounts where it is certain that the migrated users will no longer use them to log on.

Following the completion of all “user” partition migrations, it is necessary to re-execute a migration of the Global security groups from the source domain, using the Group Account Migration Wizard, only where it is possible to identify compliance with the following criteria:

The elapsed period between the initial migration of the Global security group objects from the source domain and the completion of the last “user” partition migration is greater than a few days or weeks, and

During this elapsed period, administration of the source domain proceeded as normal, and hence it is possible for administrators of the source domain to have executed changes to these Global security groups.

Where it is possible to attain compliance with these criteria, then it is necessary to determine the following design requirements for the re-execution of the migration of Global security groups from the source domain, using the Group Account Migration Wizard:

It is necessary to ensure the selection of the options “Update user rights”, “Fix membership of group”, and “Migrate Group SIDs to target domain” (where the use of SIDHistory is required) in the Group Options page of the Group Account Migration Wizard.

It is necessary to ensure de-selection of the options “Copy group members” and “Update previously migrated objects” in the Group Options page of the Group Account Migration Wizard.

It is necessary to ensure selection of the option “Replace conflicting accounts” on the Naming Conflicts page of the Group Account Migration Wizard.



To execute the migration of the remaining servers within each “server” partition, using the Computer Account Migration Wizard, it is necessary to determine the following design requirements:

As for the migration of the workstation computers executed earlier, using the Computer Account Migration Wizard, the migration involves the migration of the computer account object, security translation on local resources and objects, changing domain membership of the migrated computers, and rebooting of the migrated computers.

As the member servers of a source domain, within each “server” partition, represent the scope of this task, the reboot element of this migration task requires significant consideration. It is necessary to hence ensure that:

• Execution of this task occurs outside of business hours, when the target servers are not expected to support clients and service requests, and

• Appropriate members of the server team(s) are present to perform any reconfiguration tasks on the rebooted servers

It is necessary to ensure selection of the objects “Local Groups” and “User rights” on the Security Translation Options page of the Computer Account Migration Wizard.

As outlined before, it is necessary to determine the number of minutes prior to the automated reboot of the migrated server.

To execute the migration of the domain and shared local group objects (where applicable to the version of the source domain), using the Group Account Migration Wizard, it is necessary to determine the following design requirements:

Identify the target OU(s) for the migrated domain local / shared local group objects

Determine the requirements to migrate the SIDs for the source groups to the SIDHistory attribute of the migrated group objects in the target domain

Using the above information, execute an analysis to determine and document all of the design requirements for the execution of each required inter-forest migration path, using either the GUI tools or scripts and / or batch files.

• Factor A33: Determination of the requirements for the design of the migration tasks to execute each required instance of the intra-forest migration paths (“E” and “G”) using ADMT 2.0


Has identified the requirement for the intra-forest migration of one or more source Windows 2000 or Windows Server 2003 domains to one or more target Windows Server 2003 or Windows 2000 domains, using one of the supported domain migration paths (“E” and “G”), and

Wishes to determine the design requirements for the execution of the migration tasks for the required intra-forest migration path(s)


As for the inter-forest migration paths, the successful execution of an intra-forest migration path is dependent upon the adoption of a methodical approach towards the



design and execution of each required path. It is not possible to stress this strongly enough.

The execution of an intra-forest migration path requires a significantly different approach than for any of the supported inter-forest migration paths. The fundamental differences between these two types of paths are:

A reflection of the approach towards coexistence between the source and target domains during the migration phase, and

The fact that an intra-forest migration path moves objects between domains in the forest and does not clone or copy the objects like an inter-forest migration path. There is hence a greater dependency upon careful planning, as rollback is not so simple. Note that it is possible to use the “Undo Wizard” in ADMT version 2.0 (where the source and target domains are in (minimum) “Windows 2000 Native” mode / level) to perform remigrations of security principals back to the source domain. However, it is important to note the following pertinent facts about the use of the “Undo Wizard” in ADMT version 2.0:

• The “Undo Wizard” will only reverse the last migration operation performed in the ADMT version 2.0 console

• The “Undo Wizard” will only reverse migrations performed using the “User Account Migration Wizard”, the “Group Account Migration Wizard”, and the “Computer Account Migration Wizard”. It will not reverse the operations of any of the other ADMT version 2.0 wizards, such as the “Service Account Migration Wizard” or “Security Translation Wizard”, and so on.

An intra-forest migration path must address the migration of closed “user” and “resource” sets, as discussed in the background information section of this process. The requirements to preserve and support the preservation of closed “user” and “resource” sets will influence the design for the migration activities for each required intra-forest migration path.

The objective of this step is to guide an organisation in the determination of the specific design requirements to support the execution of any of the supported intra-forest migration paths (“E” or “G”). The deliverables for this step are all of the design requirements necessary to support the generation of the design for the execution of the migration activities for either or both of these paths, where required.

When determining the design requirements for the execution of an intra-forest migration path, consider the following:

This design methodology proposes the following approach towards determination of the design requirements to support execution of either of the intra-forest migration paths:

Determine the requirements to partition a source domain to support the phased execution of a migration path

Analyse the contents of each required partition for the source domain

Determine the requirements for the design of the scripted or manual execution of the ADMT version 2.0 migration wizards

Understand the steps involved in the execution of an intra-forest migration path using ADMT version 2.0

Determine the design requirements for the execution of each identified step in an intra-forest migration path



Consult the considerations for the previous factor when:

Determining the requirements to partition a source domain to support the phased execution of a migration path, and

Analysing the contents of each required partition for the source domain, and

Determining the requirements for the design of the scripted or manual execution of the ADMT version 2.0 migration wizards

When attempting to understand the steps involved in the execution of an intra-forest migration path, consider the following:

This design methodology recommends execution of the following steps, in the order listed below, for each required intra-forest migration path:

Where there is a requirement for the mapping and merging of source domain groups with target domain groups, then it is necessary to execute the following:

• Where the target domain groups already exist, then execute the “Group Mapping and Merging Wizard” to consolidate the required source domain groups with the required groups in the target domain

• Where the target groups for the consolidation of the source domain groups do not exist yet in the target domain, but still in the source domain, then:

♦ Execute the “Group Account Migration Wizard” to migrate the required groups from the source domain to the target domain, and then

♦ Execute the “Group Mapping and Merging Wizard” to consolidate the required source domain groups with the newly migrated target domain groups

Following completion of all group mapping and merging exercises, execute a migration of all in-scope Universal security groups, within all identified “logical” partitions of the source domain, to the target domain.

Execute a migration of all in-scope Global security groups, within all identified “logical” partitions of the source domain, to the target domain.

Execute an analysis to identify all in-scope service account objects within the source domain, within each identified “server” partition

Execute a migration of the identified in-scope service account objects from the source to the target domain. Note that this design methodology requires execution of this step after all Universal and Global security groups are migrated to the target domain as most organisation include service user accounts into security groups, to assign permissions and rights, and so on.

Select a “user” partition and execute the following:

• Execute a migration of the user account objects within the “user” partition

• Execute a translation of the local user profiles, using the Security Translation Wizard, for the user accounts in the “user” partition.

• Execute a migration of the client computers within the “user” partition

Repeat the above process for all remaining identified “user” partitions of the source domain



Execute a migration of all member servers within each identified “server” partition

Execute a migration of Domain Local groups in each identified “logical” partition

When determining the design requirements for the execution of the migration tasks for an inter-forest migration path, using ADMT version 2.0, consider the following:

To execute the migration of Universal security groups from the source domain, using the Group Account Migration Wizard, it is necessary to determine the following design requirements:

Identify the target OU(s) for the migrated Universal security groups in the target domain

In the Group Options page of the Group Account Migration Wizard, select the option “Do not rename accounts” and ensure no other boxes are selected (except the already checked “Migrate Group SIDs to the target domain” and “Fix Group Membership” checkboxes)

In the Naming Conflicts page of the Group Account Migration Wizard, select the option “Ignore conflicting accounts and don’t migrate”.

To execute the migration of Global security groups from the source domain, using the Group Account Migration Wizard, it is necessary to determine the following design requirements:

Identify the target OU(s) for the migrated Global security groups in the target domain



Prior to execution of the analysis to identify service accounts within the source domain, consider the following:

The Service Account Migration Wizard within ADMT will only identify domain user accounts used as service accounts for services and applications, and tag them for migration to the target domain. It will not identify and mark for migration the “Local System” or “Network Service” accounts, as these are “well known” accounts, and hence have a common SID, or any accounts in the local SAM database of member servers.

It is important to execute this step only against “trusted” computers within the source domain, and this hence reflects on the partitioning of the source domain to create the “server” partition(s).

Although it is not necessary to determine any design requirements for the execution of the Service Account Migration Wizard to identify the service accounts in a source domain, it is necessary to record the following:

• The list of service account objects identified by the Service Account Migration Wizard, and

• The list of servers in each “server” partition using one or more of the identified service accounts



• The mapping of services on these servers to the identified service accounts

To execute the migration of identified service accounts, using the User Account Migration Wizard, it is necessary to determine the following design requirements:

Identify the target OU(s) for the migrated service account objects

Determine the requirements for the design of a process to change the service accounts on all identified servers, in each “server partition, to use the new migrated service accounts.

To execute the migration of user account objects within each “user” partition of the source domain, using the User Account Migration Wizard, it is necessary to determine the following design requirements:

Identify the target OU(s) for the migrated user account objects in the target domain

Determine the requirements for the migration of entire OUs or OU hierarchies to the target domain. Where it is possible to identify this requirement, it is necessary to use command line commands (in a batch file) or scripts. The GUI tool only supports the selection of user account objects individually, and not via residence within source domain OUs.

Within the User Options page of the User Account Migration Wizard, it is necessary to select the following options:

• Translate roaming profiles

• Update user rights

Within the User Options page, it is important to clear the “Migrate associated user groups”, and click OK to the warning that appears. The warning states the f the Global groups to which the user accounts belong are not also migrated, users will lose access to resources.

Within the Naming Conflicts page of the User Account Migration Wizard, it is necessary to select the option “Ignore conflicting accounts and don’t migrate”.

Prior to determination of the design requirements to translate the security on the local user profiles on workstations within each “user” partition / batch, using the Security Translation Wizard, consider the following:

The Security Translation Wizard within ADMT will only translate local user profiles for computers running Windows NT 4.0, Windows 2000, Windows XP Professional, or Windows Server 2003.

It is necessary to execute the translation of local user profiles, for intra-forest migration paths, only against Windows NT 4.0 computers in the source domain. There is no requirement for the execution of this step against Windows 2000 or later client computers because for an intra-forest migration, the GUID for the user remains the same. Windows 2000 and later clients can then use the SID-to-GUID mapping for the local profile, stored in the registry, to reassign the profile to the user and re-associate it with the new SID for the user from the target domain.

Note that where a Windows XP Professional SP1 client computer uses offline folders, it is necessary to execute the Security Translation Wizard against the profile folder on these computers

It is necessary to execute the security translation for the local user profiles on Windows NT 4.0 computers in “replace” mode because the use of “add” mode



may invalidate the assignment of software packages to the target users and computers using Windows Server 2003 Active Directory GPOs. For example, a software package created using Windows Installer version 2.0 may not uninstall correctly if the last user removes the application on a computer where the Security Translation Wizard employed the “add” mode.

Prior to execution of the Security Translation Wizard and the dispatch of the ADMT agent to the target computer, it is necessary to log all users off the target computer, and (where possible) stop all currently running services. This requirement is to prevent the Security Translation Wizard employing the “add” mode instead of “replace” during the security translation of local user profiles. The wizard will be unable to execute a “replace” translation if the dispatched ADMT agent is executing the translation on the target computer while a local use profile is still in use by user or service. If it is not necessary to translate the local user profiles for domain service accounts supporting running services, then it is not necessary to stop these services.

This design methodology hence recommends that the execution of all migration activities (for all migration paths) take place outside of business hours, so as not to disrupt use and business continuity.

To translate the security on the local user profiles on workstations within each “user” partition / batch, using the Security Translation Wizard, it is necessary to determine the following design requirements:

Determine the design requirements for the process, script, or batch file to log all users off the Windows NT 4.0 workstations within each target “user” partition, prior to execution of the security translation on the local user profiles.

When executing the security translation wizard, to translate security on local user profiles, only select “user profiles” in the “Translate Objects” page of the wizard.

Prior to determination of the design requirements to migrate workstations within each “user” partition / batch, using the Computer Account Migration Wizard, consider the following:

The Computer Account Migration Wizard within ADMT will perform the following actions:

• Clone the computer account object from the source domain to the target domain

• Dispatch an agent to the target workstations for the migrated computer account objects, and:

♦ Run a security translation, on the computer been migrated, for files and folders, local groups, printers, registry, shares, user profiles and rights, and

♦ Change the domain membership of the computer been migrated to the target domain

♦ Reboot the migrated computer after a pre-set period, to permit it to boot up as a member of the target domain

When determining the number of minutes to set before the migrated computer reboots, consider the following:

• The ADMT Computer Account Migration Wizard provides a default setting of five minutes before the migrated computer reboots.



• The migrated computer receives the reboot command upon dispatch of the ADMT agent to the computer. Note that where there is a concurrent requirement to translate security on the migrated computer, this occurs whilst a countdown timer for shutdown operates. Hence, where the target computer has, for example, a significant number of objects to translate security upon, has insufficient or over utilised hardware resources (CPU, RAM, and so on), then the computer may shutdown prior to completion of the security translation.

• Hence, in order to determine the most appropriate wait period prior to a reboot of a migrated computer, it is necessary to execute the following:

♦ Determine the security translation requirements on computers that require migration, and where required, the volume of objects that require translation. It is feasible to perform a test migration first to retrieve details of the number of objects that require security translation, and the time required to execute the translation.

♦ Use these findings to determine the minimum required number of minutes prior to the reboot of a migrated computer.

To execute the migration of the workstations within each “user” partition, using the Computer Account Migration Wizard, it is necessary to determine the following design requirements:

Identify the target OU(s) for the migrated computer account objects

In the Translate Objects page of the Computer Account Migration Wizard, it is important to select only “local groups” and “user rights”.

Using the above approach, determine the number of minutes the migrated computer will wait for before executing a reboot

To execute the migration of the remaining servers within each “server” partition, using the Computer Account Migration Wizard, it is necessary to determine the following design requirements:

As for the migration of the workstation computers executed earlier, using the Computer Account Migration Wizard, the migration involves the migration of the computer account object, security translation on local resources and objects, changing domain membership of the migrated computers, and rebooting of the migrated computers.

As the member servers of a source domain, within each “server” partition, represent the scope of this task, the reboot element of this migration task requires significant consideration. It is necessary to hence ensure that:

• Execution of this task occurs outside of business hours, when the target servers are not expected to support clients and service requests, and

• Appropriate members of the server team(s) are present to perform any reconfiguration tasks on the rebooted servers

It is necessary to ensure selection of the objects “Local Groups” and “User rights” on the Security Translation Options page of the Computer Account Migration Wizard.

As outlined before, it is necessary to determine the number of minutes prior to the automated reboot of the migrated server.



To execute the migration of the Domain Local group objects using the Group Account Migration Wizard, it is necessary to determine the following design requirements:

Identify the target OU(s) for the migrated Domain Local group objects in the target domain



Using the above information, execute an analysis to determine and document all of the design requirements for the execution of each required intra-forest migration path, using the GUI tools or scripts and / or batch files.

5.9.1.4. Determination of the Design Requirements for the Post-Migration Tasks

Consider the following information when determining the design requirements for the post-migration tasks to support each required migration path:

• Factor B10: Understanding the post-migration tasks that require determination for design and execution

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the post-migration tasks that require determination for design and execution for specific supported migration paths.


The objective of this step is to assist an organisation in the determination of the design requirements for the execution of post-migration tasks, for specific migration paths.

It is important to note that post-migration implies the completion of all migration activities, and hence post-migration tasks do not include the following migration activities:

The in-place upgrade a of PDC within legacy Windows NT 4.0 domain (approaches 1, 2, or 3 of migration path “A”)

The first upgrade of a Windows 2000 domain controller in a forest to Windows Server 2003 (approach 1 of migration path “B”)

The introduction of the first Windows Server 2003 domain controller into an existing legacy Windows 2000 domain and forest (approach 2 of migration path “B”)

The cloning of any security principals from a source domain to a target domain using an inter-forest migration path (migration paths “C”, “D”, “F”, or “H”)

The moving of any security principals from a source domain to a target domain using an intra-forest migration path (migration paths “E” or “G”)

The post-migration tasks represent all of the tasks that require execution following the completion of migration tasks for a migration path. Execution of the post-migration tasks associated with a specific migration path hence depends upon the completed execution of specific migration tasks.



Note that where an organisation is executing the recommended phased migration approach, it is possible for the requirement to execute post-migration tasks alongside migration tasks for a migration path. For example, where an organisation executes inter-forest migration path “D”, and performs migration task to migrated client computers within a “user” partition of the source domain, it is necessary to execute post-migration tasks on the migrated computers while the migration phase execute the next migration task for that “user” partition.

It is not feasible to execute all migration tasks and then initiate execution of the post-migration tasks. This is unlike the relationship between pre-migration and migration tasks, where this design methodology strongly recommends the completion of all pre-migration tasks for a migration path prior to the initiation of any of the relevant migration tasks for that migration path.

The following diagram illustrates the relationships between the pre-migration, migration, and post-migration stages for supported migration paths:

COEXISTENCE PHASE

MIGRATION PHASE

PRE-MIGRATIONMIGRATION

POST-MIGRATION


Figure 44.17: Relationships between Pre-Migration, Migration, and Post-Migration Stages of a Migration Path

It is important to note that post-migration tasks vary with respect to their urgency for execution. Some post-migration tasks require execution within one or two minutes of the completion of a specific migration task, while it is possible to execute other tasks any time up to a week or month after the completion of specific migration tasks. To assist an organisation in the identification of the urgency for execution of the post-migration tasks, this design methodology places post-migration tasks in the following three categories:

Post-migration tasks that require “immediate” execution

Post-migration tasks that require “urgent” execution

Post-migration tasks that require “non-urgent” execution

“Immediate” post migration tasks have the following execution profile:

They require execution after the completion of one or more specific migration tasks

They require execution either immediately after completion of one or more specific migration tasks or between one minute and a couple of hours after completion of one or more specific migration tasks

The failure to execute “immediate” post-migration tasks may generate a range of consequences, ranging from minor inconvenience to disastrous consequences, such as temporary or permanent disruption to business continuity.

“Urgent” post migration tasks have the following execution profile:


They require execution between a few hours and one or two days after completion of one or more specific migration tasks



The failure to execute “urgent” post-migration tasks may generate unacceptable consequences, such as temporary or permanent disruption to continuity of the migration project, and so on.

“Non-urgent” post-migration tasks have the following execution profile:


They require execution between a few hours or even up to months and years after completion of one or more specific migration tasks

The failure to execute “non-urgent” post-migration tasks may generate unacceptable consequences, such as the generation of delay to the completion of the migration project or other parallel projects dependent upon the completed post-migration tasks, lack of compliance with the criteria for the completion of a migration path, and so on.

It is important to note that the design and execution of post-migration tasks must strictly reflect requirements to attain compliance with criteria that represents completion of a migration path. Each migration path discussed below will define the criteria for compliance with their completion.

This design methodology proposes that the boundary and scope of the post-migration tasks must not infringe the boundary and scope of a Deployment Plan. A Deployment Plan, which requires design and execution after completion of the Migration Plan, will assist an organisation in the deployment of the designed Active Directory infrastructure. The objective of a Deployment Plan is to assist an organisation in the design of the processes, activities, communications plan, and schedule for the deployment of all remaining aspects of the Windows Server 2003 Active Directory infrastructure for the organisation.

This design methodology partitions this step, to determine the design requirements for the post-migration tasks for supported migration paths, into the following two sections:

Determination of the requirements for the design of the post-migration tasks for each required instance of the inter-forest migration paths (“C”, “D”, “F” and “H”) using ADMT version 2.0

Determination of the requirements for the design of the post-migration tasks for each required instance of the intra-forest migration paths (“E” and “G”) using ADMT version 2.0

Note that this design methodology does not identify any post-migration tasks for migration paths “A” and “B” that require design for execution, although it is possible to identify a significant number of coexistence and deployment tasks for these paths. The later step in this process, “design of the migration checklists”, will provide a few examples of pre-migration tasks associated with migration paths “A” and “B”, which do not require design for execution.

The completion of the in-place upgrade of a PDC, either representing or within a Windows NT 4.0 domain, to create a new Windows Server 2003 domain, denotes the completion of the migration activity for an instance of migration path “A”.

The completion of the in-place upgrade of a Windows 2000 domain controller or the addition of a new Windows Server 2003 domain controller into an existing Windows 2000 domain denotes completion of the migration activity for an instance of migration path “B”.

The completion of these migration activities hence complies with the objectives and scope of migration paths “A” and “B” (see step “supported migration paths”, within the earlier process “understanding supported migration paths”, for details).



• Factor A34: Determination of the requirements for the design of the post-migration tasks for each required instance of the inter-forest migration paths (“C”, “D”, “F” and “H”) using ADMT version 2.0


Has identified the requirement(s) for the execution of one or more instances of the inter-forest migration paths (“C”, “D”, “F” and “H”) using ADMT version 2.0, and

Wishes to determine the requirements for the design of the post-migration tasks for each required instance of the inter-forest migration paths (“C”, “D”, “F” and “H”)


Note that this factor only considers the following post-migration tasks:

Post-migration tasks that require determination for design and execution

Post-migration tasks that only support the continuation and termination of migration-related activities within a migration path

It is important to remember that the focus for the post-migration tasks is the attainment of compliance with the completion of migration activities for the inter-forest migration paths, and not to support any requirements for coexistence between source and target domains. These tasks are within the scope of the coexistence plan. See the next step within this process, “determination of the design requirements for the coexistence plan”, for details.

Note that the later step in this process, “design of the migration checklists”, will provide a few examples of post-migration tasks associated with each migration path, which do not require design for execution.

When determining the requirements for the design of the post-migration tasks for the inter-forest migration paths, consider the following:

This design methodology proposes execution of the following approach to determine the design requirements for the post-migration tasks for the inter-forest migration paths:

Understand the scope for the post-migration tasks for the inter-forest migration paths

Determine all post-migration tasks that require execution to complete migration the inter-forest migration paths

Categorise the identified post-migration tasks into the “immediate”, “urgent”, and “non-urgent” categories

When attempting to understand the scope of the post-migration tasks for the inter-forest migration paths, consider the following:

Prior to determination of the post-migration tasks that require design for execution, it is important to understand the boundary and scope for their execution, with respect to the migration path they support. The scope of the post-migration tasks for the inter-forest migration paths is a direct reflection of the tasks required to “complete” the paths. The post-migration tasks must hence support compliance with criteria that represent the completion of the inter-forest migration paths. Note that this design methodology does not support the design and execution of post-migration tasks that infringe upon the scope of a Deployment Plan.



This design methodology recognises that within some organisations, migrations are never “completed”. In fact, in some organisations, new migrations may commence whilst old migrations remain uncompleted. Hence, this design methodology has only identified criteria that represent the completion of a migration path, which are fairly attainable and realistic for the majority of organisations.

The criteria that represent the completion of the inter-forest migration paths are a reflection of the objectives of the migration paths. See the step “supported migration paths”, within the process “understanding supported migration paths”, for details of the objectives and scope for each inter-forest migration path.

This design methodology proposes that compliance with the following minimum criteria represents the completion of the inter-forest migration paths, and hence the scope of the post-migration tasks:

All migration tasks for the inter-forest migration paths are completed

Each source domain for each instance of an inter-forest migration path is decommissioned, where required and appropriate

When determining the post-migration tasks for the inter-forest migration paths that require design for execution, consider the following:

Note that although the onus is with the organisation to determine their specific post-migration tasks for the inter-forest migration paths that require design for execution, this design methodology will provide examples of post-migration tasks.

When determining the design requirements for the post-migration tasks that require execution after completion of specific migration wizards, consider the following:

This design methodology identifies a number of post-migration tasks (examples provided in the later step “design of the migration checklists”), but only a few post-migration tasks that require design for execution.

The post-migration tasks for the inter-forest migration paths are partitioned into two sections:

• Post-migration tasks for inter-forest migration paths that required the design and use of the SIDHistory attribute

• Post-migration tasks for inter-forest migration paths that did not require the design and use of the SIDHistory attribute

For all instances of inter-forest migration paths that used the SIDHistory attribute, the following post-migration tasks require design for execution (the tasks require execution strictly in the order listed):

Execution of the Security Translation Wizard on all cloned member computers

Removal of all trust relationships on the source domain

Decommissioning or migration of all remaining domain controllers from the source domain to the target domain, where required

Removal of legacy SIDs from the SIDHistory attributes of all cloned security principals

When determining the design requirements for the execution of the ADMT version 2.0 Security Translation Wizard on all cloned member computers, consider the following:



Following the completion of migrations of all “user” and “server” partitions in the source domain, it is necessary to replace the SIDs on all DACLs, on all resources on the cloned computers, which refer to the source domain security principals. It is hence necessary to execute the Security Translation Wizard, in “replace” mode against all cloned member computers.

When determining the design requirements for the process to execute this step, consider the following:

• This design methodology recommends that the scope of this re-execution of the Security Translation Wizard in “replace” mode must include all cloned computers from the source domain. This hence includes all cloned client and server computers.

• The execution of this wizard in “replace” mode will identify all SIDs from the source domain, in DACLs on the cloned computers, and replace them with the corresponding SIDs from the target domain.

When determining the design requirements for the post-migration process to remove all existing trust relationships, consider the following:

The scope for the trust relationships that require removal on the source domain are:

• All external trust relationship between the source and target domains, in preparation for termination of the migration phase for an instance of an inter-forest migration path

• All external trust relationships between the source and other domains, in preparation for decommissioning of the source domain

This design methodology requires compliance with the following criteria prior to termination of all external trusts relationships on the source domain:

• The organisation has positively identified the requirement to decommission the source domain, following completion of all migration and post-migration activities.

• All migration and post-migration activities that rely upon the continued presence of the source domain are completed

• It is possible to positively confirm that all other domains, trusted by the source domain, no longer depend upon the continued presence of the source domain

Where it is possible to identify compliance with these criteria, then it is possible to terminate all appropriate external trust relationships.

Note that where there is a requirement, in the next post-migration task, to clone demoted domain controllers in the source domain, as member servers, to the target domain using ADMT version 2.0, then it is necessary to retain the trust-relationships between the source and target domain. Following completion of the migration activities, and it is possible to remove the trust relationships from within the target domain.

When determining the design requirements for the process, to support the execution of this post-migration task, the process must ensure the following:



• The required steps to terminate the external trust relationships are performed on both the source domain and the trusted / trusting external domains (including the target domain for an inter-forest migration path)

• The employment of the appropriate credentials to terminate the trusts

When determining the design requirements for the post-migration process to either decommission or migrate all domain controllers in the source domain, consider the following:

The decommissioning or migration of all domain controllers that represent a source domain effectively decommissions the source domain, and hence all directory objects and data within that domain. The execution of this step hence demands significant planning and consideration.

The predefined business and technical migration goals for a migration path will influence and direct the decommissioning or migration of all domain controllers in the source domain to the target domain.

Where it is possible to identify requirements to redeploy the domain controllers in the source domain, then consider the following:

• The organisation must determine the requirements to redeploy the domain controllers in the source domain as domain controllers in the target domain, or as member servers in the target domain.

• The decision to re-deploy these domain controllers as Windows Server 2003 domain controllers in the target domain depends upon compliance with the following:

♦ The minimum and recommended hardware specifications for the standard server build for Windows Server 2003 domain controllers, and

♦ The minimum and maximum number of domain controllers the target domain requires

• Where it is not possible to attain compliance with these criteria, then the existing domain controllers from the source domain may require redeployment as member servers in the target domain.

When determining the design requirements for the post-migration process to redeploy existing domain controllers within a source domain, consider the following:

• ADMT version 2.0 is unable to execute a migration of domain controllers from one domain to another, as an inter-forest or intra-forest migration path.

• For the inter-forest migration path “C” (from a Windows NT 4.0 to Windows Server 2003 domain), it is not possible to “demote” a BDC to a member server without performing a complete re-build of the server. The design of the process to execute a migration of one or more BDCs to a target Windows Server 2003 domain hence depends upon the requirement to retain the legacy operating system (Windows NT 4.0) or deploy a new supported operating system (Windows Server 2003) on the server. If there is a requirement to retain the legacy Windows NT 4.0 operating system, then the process must provide the details for the steps to rebuild the BDC as a Windows NT 4.0 member server in the target domain. If there is a requirement to deploy a new supported operating system (Windows Server 2003), then the process must provide the details for the steps to rebuild the BDC as a Windows Server 2003 member server in the target domain.



• For inter-forest migration paths “D”, “F”, and “H”, as the domain controllers in the source domain are running Windows 2000 or Windows Server 2003, migration is a simpler process. The required process to execute the migration of these domain controllers must hence provide the details for execution of the following steps:

♦ Execution of the Active Directory Installation Wizard, on the domain controllers in the source domain (remember to select the checkbox “this is the last domain controller in the domain”, when executing this step on the last domain controller in the domain)

♦ Execution of the ADMT version 2.0 Computer Account Migration Wizard, to migrate the demoted domain controllers, as member servers, into the target domain

♦ Execution of the Active Directory Installation Wizard to create additional Windows Server 2003 domain controllers in the target domain, where required, or

♦ Configuration of the new Windows Server 2003 member servers in their new role(s), such as file and print servers, application servers, web servers, and so on.

When determining the design requirements for the process to remove the legacy SIDs from the SIDHistory attribute from cloned security principals in the target domain, consider the following:

Following the decommissioning of the source domain for cloned security principals, the legacy SIDs in the SIDHistory attributes are redundant, and it is hence necessary to remove these legacy SIDs.

It is not possible to remove the SIDHistory attribute from the cloned security principals, as the Active Directory SAM owns this attribute. However, it is possible to clean the data values within the SIDHistory attributes using a script or a third-party migration tool. Microsoft does not provide any tools or user interfaces to clean the SIDHistory attribute on cloned security principals.

When determining the design requirements for the process to clear legacy SIDs from the SIDHistory attribute, consider the following:

• It is necessary to determine the required vehicle to execute this step, as a script or a third-party migration tool. If an organisation has employed the use of ADMT version 2.0 to execute the inter-forest migration path(s), then the use of a third-party tool to clear the SIDHistory attributes is not feasible. This design methodology hence recommends the creation and use of a script to execute this step, and recommends consultation of the Microsoft Knowledge Base article KB295758 for details on how to build and execute a VB script.

• This design methodology recommends the execution of the script or third party migration tool against the Windows Server 2003 domain controller in the target domain hosting the PDC Emulator FSMO role.

For all instances of inter-forest migration paths that did not use the SIDHistory attribute, the following post-migration tasks require design for execution (the tasks require execution strictly in the order listed):

Execution of the ADMT version 2.0 Security Translation Wizard against all migrated member computers



Execution of the ADMT version 2.0 Exchange Directory Migration Wizard against the migrated Exchange 5.5 servers

Removal of all trust relationships on the source domain (see earlier for details of the considerations for this step)

Decommissioning or migration of all remaining domain controllers from the source domain to the target domain, where required. (See earlier for details of the considerations for this step.)

When determining the design requirements for the execution of the ADMT version 2.0 Security Translation Wizard on cloned member servers in the target domain, consider the following:

During the migration phase, where an organisation elected not to design and use SIDHistory, it was necessary (to support coexistence) to execute the Security Translation Wizard on all member computers, in the source domain, in the “add” mode. This step added the SIDs, for the cloned security principals, to the DACLs on the resources hosted by the member computers in the source domain.

Following the completion of the migration of all members of each identified “user” and “server” partition of the source domain, it is necessary to re-execute the Security Translation Wizard, on the cloned member computers, in “remove” mode.


• This design methodology recommends that the scope of this re-execution of the Security Translation Wizard in “remove” mode must include all cloned computers from the source domain. This hence includes all cloned client and server computers.

• The execution of this wizard in “remove” mode will identify all SIDs from the source domain, in DACLs on the cloned computers, and remove them from the DACLs.

When determining the design requirements for the execution of the ADMT version 2.0 Exchange Directory Migration Wizard on cloned Exchange 5.5 member servers in the target domain, consider the following:

During the migration phase, where an organisation elected not to design and use SIDHistory, it was necessary (to support coexistence) to execute the Exchange Directory Migration Wizard on all Exchange 5.5 member servers, in the source domain, in the “add” mode. This step added the SIDs, for the cloned security principals, to the DACLs on the mailboxes, distribution lists, Sites, containers, and so on in the Exchange 5.5 Organisation.

Following the completion of the migration of all Exchange 5.5 members in each identified “server” partition of the source domain, it is necessary to re-execute the Exchange Directory Migration Wizard, on the cloned Exchange 5.5 member servers, in “remove” mode.


• This design methodology recommends that the scope of this re-execution of the Exchange Directory Migration Wizard in “remove” mode must include all cloned Exchange 5.5 members servers from the source domain.



• The execution of this wizard in “remove” mode will identify all SIDs from the source domain, in DACLs on the mailboxes, distribution lists, Sites, containers, and so on in the Exchange 5.5 Organisation, and remove them from the DACLs.

When categorising the identified post-migration tasks, which require design for execution, into “immediate”, “urgent”, and “non-urgent”, consider the following:

Although the onus is with the organisation to categorise all of their identified post-migration tasks, this design methodology places the identified examples of post-migration tasks into the following categories:

Execution of the Security Translation Wizard in “replace” mode (for inter-forest migration paths that used SIDHistory) is an “urgent” post-migration task

Execution of the Security Translation Wizard in “remove” mode (for inter-forest migration paths that did not use SIDHistory) is an “urgent” post-migration task

Execution of the Exchange Directory Migration Wizard in “remove” mode (for inter-forest migration paths that did not use SIDHistory) is an “urgent” post-migration task

Execution of the termination of all trust relationships on the source domain is a “non-urgent” post-migration task

Execution of the decommissioning or migration of legacy domain controllers from the source domain to the target domain (where required) is a “non-urgent” post-migration task

Execution of the process to clear the SIDHistory attributes of cloned security principals (for inter-forest migration paths that used SIDHistory) is a “non-urgent” post-migration task

Using the above information, execute an analysis to determine and document all of the design requirements for the post-migration tasks for each required instance of the inter-forest migration paths (“C”, “D”, “F” and “H”) using ADMT version 2.0.

• Factor A35: Determination of the requirements for the design of the post-migration tasks for each required instance of the intra-forest migration paths (“E” and “G”) using ADMT version 2.0


Has identified the requirement(s) for the execution of one or more instances of the intra-forest migration paths (“E” and “G”) using ADMT version 2.0, and

Wishes to determine the requirements for the design of the post-migration tasks for each required instance of the intra-forest migration paths (“E” and “G”)


Note that, as for the inter-forest migration paths, this factor only considers the following post-migration tasks:

Post-migration tasks that require determination for design and execution

Post-migration tasks that only support the continuation and termination of migration-related activities within a migration path



It is important to remember that the focus for the post-migration tasks is the attainment of compliance with the completion of migration activities for the intra-forest migration paths, and not to support any requirements for coexistence between source and target domains. These tasks are within the scope of the coexistence plan. See the next step within this process, “determination of the design requirements for the coexistence plan”, for details.

Note that the later step in this process, “design of the migration checklists”, will provide a few examples of post-migration tasks associated with each migration path, which do not require design for execution.

When determining the requirements for the design of the post-migration tasks for the intra-forest migration paths, consider the following:

This design methodology proposes execution of the following approach to determine the design requirements for the post-migration tasks for the intra-forest migration paths:

Understand the scope for the post-migration tasks for the intra-forest migration paths

Determine all post-migration tasks that require execution to complete migration the intra-forest migration paths

Categorise the identified post-migration tasks into the “immediate”, “urgent”, and “non-urgent” categories

When attempting to understand the scope of the post-migration tasks for the intra-forest migration paths, consider the following:

Prior to determination of the post-migration tasks that require design for execution, it is important to understand the boundary and scope for their execution, with respect to the migration path they support. The scope of the post-migration tasks for the intra-forest migration paths is a direct reflection of the tasks required to “complete” the paths. The post-migration tasks must hence support compliance with criteria that represent the completion of the intra-forest migration paths. Note that this design methodology does not support the design and execution of post-migration tasks that infringe upon the scope of a Deployment Plan.

This design methodology recognises that within some organisations, migrations are never “completed”. In fact, in some organisations, new migrations may commence whilst old migrations remain uncompleted. Hence, this design methodology has only identified criteria that represent the completion of a migration path, which are fairly attainable and realistic for the majority of organisations.

The criteria that represent the completion of the intra-forest migration paths are a reflection of the objectives of the migration paths. See the step “supported migration paths”, within the process “understanding supported migration paths”, for details of the objectives and scope for each inter-forest migration path.

This design methodology proposes that compliance with the following minimum criteria represents the completion of the intra-forest migration paths, and hence the scope of the post-migration tasks:

All migration tasks for the intra-forest migration paths are completed

Each source domain for each instance of an intra-forest migration path is decommissioned, where required and appropriate

When determining the post-migration tasks for the intra-forest migration paths that require design for execution, consider the following:



Note that although the onus is with the organisation to determine their specific post-migration tasks for the intra-forest migration paths that require design for execution, this design methodology will provide examples of post-migration tasks.

This design methodology identifies a number of post-migration tasks (a few examples provided in the later step “design of the migration checklists”), but only a few post-migration tasks that require design for execution.

The following post-migration tasks for the intra-forest migration paths require design for execution:

Execution of the Security Translation Wizard on all cloned member computers

Removal of all trust relationships on the source domain

Decommissioning or migration of all remaining domain controllers from the source domain to the target domain, where required

When determining the design requirements for the execution of the ADMT version 2.0 Security Translation Wizard on all cloned member computers, consider the following:

Following the completion of migrations of all “user” and “server” partitions in the source domain, it is necessary to replace the SIDs on all DACLs, on all resources on the cloned computers, which refer to the source domain security principals. It is hence necessary to execute the Security Translation Wizard, in “replace” mode against all cloned member computers.


• This design methodology recommends that the scope of this re-execution of the Security Translation Wizard in “replace” mode must include all cloned computers from the source domain. This hence includes all cloned client and server computers.

• The execution of this wizard in “replace” mode will identify all SIDs from the source domain, in DACLs on the cloned computers, and replace them with the corresponding SIDs from the target domain.

When determining the design requirements for the post-migration process to remove all existing trust relationships, consider the following:

The scope for the trust relationships that require removal on the source domain are:

• Any short-cut trust relationships between the source and target domains, in preparation for termination of the migration phase for an instance of an intra-forest migration path

• All external trust relationships between the source and other domains, in preparation for decommissioning of the source domain

This design methodology requires compliance with the following criteria prior to termination of all external trusts relationships on the source domain:

• The organisation has positively identified the requirement to decommission the source domain, following completion of all migration and post-migration activities.



• All migration and post-migration activities that rely upon the continued presence of the source domain are completed

• It is possible to positively confirm that all other domains, trusted by the source domain, no longer depend upon the continued presence of the source domain

Where it is possible to identify compliance with these criteria, then it is possible to terminate all appropriate external trust relationships.

Note that where there is a requirement, in the next post-migration task, to move demoted domain controllers in the source domain, as member servers, to the target domain using ADMT version 2.0, then it is necessary to retain any short-cut trust-relationships between the source and target domain. Following completion of the migration activities, and it is possible to remove any short-cut trust relationships from within the target domain.

When determining the design requirements for the process, to support the execution of this post-migration task, the process must ensure the following:

• The required steps to terminate the external trust relationships are performed on both the source domain and the trusted / trusting external domains (including the target domain for an intra-forest migration path, to terminate a short-cut trust)

• The employment of the appropriate credentials to terminate the trusts

When determining the design requirements for the post-migration process to either decommission or migrate all domain controllers in the source domain, consider the following:

The decommissioning or migration of all domain controllers that represent a source domain effectively decommissions the source domain, and hence all directory objects and data within that domain. The execution of this step hence demands significant planning and consideration.

The predefined business and technical migration goals for a migration path will influence and direct the decommissioning or migration of all domain controllers in the source domain to the target domain.

Where it is possible to identify requirements to redeploy the domain controllers in the source domain, then consider the following:

• The organisation must determine the requirements to redeploy the domain controllers in the source domain as domain controllers in the target domain, or as member servers in the target domain.

• The decision to re-deploy these domain controllers as Windows 2000 / Windows Server 2003 domain controllers in the target domain depends upon compliance with the following:

♦ The minimum and recommended hardware specifications for the standard server build for Windows 2000 / Windows Server 2003 domain controllers, and

♦ The minimum and maximum number of domain controllers the target domain requires



• Where it is not possible to attain compliance with these criteria, then the existing domain controllers from the source domain may require redeployment as member servers in the target domain.

When determining the design requirements for the post-migration process to redeploy existing domain controllers within a source domain, consider the following:

• ADMT version 2.0 is unable to execute a migration of domain controllers from one domain to another, as an inter-forest or intra-forest migration path.

• For intra-forest migration paths “E”, and “G”, as the domain controllers in the source domain are running Windows Server 2003 or Windows 2000 respectively, migration is a simpler process. The required process to execute the migration of these domain controllers must hence provide the details for execution of the following steps:

♦ Execution of the Active Directory Installation Wizard, on the domain controllers in the source domain (remember to select the checkbox “this is the last domain controller in the domain”, when executing this step on the last domain controller in the domain)

♦ Execution of the ADMT version 2.0 Computer Account Migration Wizard, to migrate the demoted domain controllers, as member servers, into the target domain

♦ Execution of the Active Directory Installation Wizard to create additional Windows 2000 / Windows Server 2003 domain controllers in the target domain, where required, or

♦ Configuration of the new Windows Server 2003 member servers in their new role(s), such as file and print servers, application servers, web servers, and so on.

When categorising the identified post-migration tasks, which require design for execution, into “immediate”, “urgent”, and “non-urgent”, consider the following:

Although the onus is with the organisation to categorise all of their identified post-migration tasks, this design methodology places the identified examples of post-migration tasks into the following categories:

Execution of the Security Translation Wizard in “replace” mode is an “urgent” post-migration task

Execution of the termination of all trust relationships on the source domain is a “non-urgent” post-migration task

Execution of the decommissioning or migration of legacy domain controllers from the source domain to the target domain (where required) is a “non-urgent” post-migration task

Using the above information, execute an analysis to determine and document all of the design requirements for the post-migration tasks for each required instance of the intra-forest migration paths (“E” and “G”) using ADMT version 2.0.

5.9.2. Determination of the Design Requirements for the Coexistence Plan

Consider the following when determining the design requirements for the coexistence plan.

Presented within the following two sections are the considerations for the execution of this step within this process:



1. Considerations for understanding the scope and objectives of the coexistence plan

2. Considerations for the determination of the design requirements for coexistence plan tasks specific to supported migration paths

5.9.2.1. Understanding the Scope and Objectives of the Coexistence Plan

Consider the following when attempting to understand the scope and objectives of the coexistence plan:

• Factor B11: Understanding the scope and objectives of the coexistence plan

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the scope and objectives of the coexistence plan, prior to determination of the appropriate design requirements.


This design methodology defines the term “coexistence”, with respect to a migration plan, to imply the following requirements:

The requirement for security principals, member computers, domain controllers, services, applications, processes, and so on, from a source / legacy domain and production environment to interact with a target / new domain for the execution of activities that do not effect any actual migrations, and / or

The requirement for security principals, member computers, domain controllers, services, applications, processes, and so on, from a target / new domain and production environment to interact with a source / legacy domain for the execution of routine activities.

It is hence only necessary to design and execute a coexistence plan where it is possible to identify either or both of these requirements, which define the requirements for coexistence.

Where, for example, an organisation elects to execute a “big bang” migration over one night or weekend, and there will be hence no requirements to support any interactions between the current and new domain environments, then a coexistence plan is not required. However, this approach is only suitable for small organisations with a few hundred or less users and computers in a simple legacy domain environment.

Where it is possible to identify the requirement for a coexistence plan, then this design methodology identifies the requirement for the design of a single coexistence plan to support specific required migration paths. The required migration paths and their required instances hence define the scope of the coexistence plan.

A coexistence plan is comprised of a number of coexistence tasks, which require design for execution during the pre-migration and post-migration phases of specific required migration paths.

A coexistence plan supports the coexistence phase of a migration project. Figure 44.17 illustrates that a coexistence phase logically starts once the migration activities for a migration path commence, based upon the above definition of “coexistence”. Although a new domain environment might require implementation as a pre-migration task for specific migration paths, no requirements for coexistence between the old and new domain environments exist until migration commences.

The objectives of the coexistence plan are hence to assist an organisation in the execution of the following:



Identification of all requirements for coexistence between the source and target domains before, during, and after migration

Determination of all of all necessary tasks, to support all identified coexistence requirements, which require design and execution during the pre-migration and post-migration phases for specific required migration paths.

A coexistence plan supports the following objectives of coexistence phase of a migration project:

To keep the legacy production environment running to same efficient levels as before, prior to the execution of any pre-migration, migration, and post-migration activities for any required migration paths

To support all required interactions between the current legacy domain environment and any new domain environments generated during execution of any required migration paths

It is important to note that the intentions of the coexistence tasks are not to perform any “migration” activities but to retain productivity, security, continuity, and so on, of the organisation during the coexistence phase.

This design methodology requires that the design for a coexistence plan include the following components:

A design for the coexistence tasks for execution during the pre-migration phase for specific required migration paths

A design for the coexistence tasks for execution during the post-migration phase for specific required migration paths

Only the migration paths “A” and “C” may support requirements for the design and execution of coexistence plan tasks. Migration paths “B” and “D” have a very low potential to support requirements for the design and execution of coexistence plan tasks.

This design methodology hence proposes execution of the following approach to determine the design requirements for a coexistence plan to support the specified migration paths, and instances of each required path:

Select a required migration path, and for each required instance of that migration path, determine the following:

Determine the design requirements for coexistence plan tasks generated by the migration path

Categorise each identified coexistence plan task for execution during the pre-migration or post-migration phase of the migration path, where applicable

Repeat these analysis activities for each required migration path

Collate all design requirements for the coexistence tasks for each required migration path and submit to the later step in this process, “design of the coexistence plan”.

5.9.2.2. Determination of the Design Requirements for Coexistence Plan Tasks for Specific Supported Migration Paths

Consider the following when determining the design requirements for coexistence plan tasks for specific migration paths supported by this design methodology:



• Factor A36: Determination of the design requirements for coexistence plan tasks to support migration path “A”


Has identified the requirements for the migration of one or more legacy Windows NT 4.0 domains using migration path “A”, and

Wishes to determine the requirements for the design of coexistence plan tasks to support the pre-migration and post-migration phases of migration path “A”


Execution of migration path “A” involves the in-place upgrade of a Windows NT 4.0 domain to become a Windows Server 2003 domain. Hence, any requirements for “coexistence” are predominantly between the Windows Server 2003 domain controllers and the following legacy components of the Windows NT 4.0 domain:

Any legacy Windows NT 4.0 BDCs within the Windows Server 2003 domain

Windows NT 4.0 member servers running services that:

Run under the context of the Local System account, and

Require communication with other services over the network using null sessions

Windows NT 4.0 clients (servers and client computers) and Windows 95, 98, and earlier clients

These computers represent the only “remnants” of the legacy Windows NT 4.0 domain that may influence the design requirements for coexistence plan tasks. There are no requirements for any coexistence plan tasks to support interactions between computers running Windows 2000 or later operating systems and Windows Server 2003 domain controllers.

Note that only approaches 1 or 2 of migration path “A” will generate any requirements for coexistence between Windows Server 2003 domain controllers and BDCs, as approach 3 negates support for Windows NT 4.0 BDCs.

When determining the coexistence plan tasks that require design for execution to support migration path “A”, consider the following:

The design methodology proposes that the following coexistence plan tasks require design for execution to support migration path “A”:

The requirement to bridge the Windows NT 4.0 LAN Manager Replication Service on legacy BDCs with the Windows Server 2003 File Replication Service on new Windows Server 2003 domain controllers

The requirement to ensure service continuity for specific Windows NT 4.0 member servers that require the use of null sessions

The requirement to ensure continuity of operation of legacy client computers in the Windows NT 4.0 domain

The requirements to configure DNS to use WINS lookup to support interactions between Windows 2000 and later member computers and other member computers running pre-Windows 2000 operating systems.



The requirements to recreate external trust relationship to use DNS domain names and not NetBIOS domain names

The requirements to reduce the workload on the Windows Server 2003 domain controller hosting the PDC Emulator FSMO role

When determining the design requirements for the coexistence plan tasks to ensure continued support for BDCs (for approaches 1 and 2 of migration path “A”), consider the following:

After the execution of the in-place upgrade of a PDC, it is necessary to ensure continued support for the LMRepl Service on the BDCs. The LMRepl service is responsible for the replication of the NETLOGON share between Windows NT 4.0 domain controllers in a domain. Most Windows NT 4.0 domain owner(s) typically employ the NETLOGON share to hold the logon scripts and batch files for the users. In Windows Server 2003 Active Directory, the SYSVOL share provides a similar function, but is supported by a different replication system, known as the File Replication System, which will only replicate the contents of the SYSVOL share between domain controllers running Windows 2000 or later.

It is hence necessary to “bridge” these two file replication services together to ensure, for example, that all domain controllers within the upgraded Windows Server 2003 domain will provide the same logon scripts to all authenticated users. Consult the Microsoft Knowledge Base article KB317368 for details of the necessary steps to use a Microsoft-provided script (“LBridge.cmd”) to bridge LMRepl and FRS.

When determining the design requirements for the coexistence plan tasks to ensure continued support for specific Windows NT 4.0 member servers that require the use of null sessions, consider the following:

The most common Windows NT 4.0 service that requires the use of null sessions is Windows NT 4.0 RAS. The coexistence plan must hence support a process to either upgrade / migrate the routing and remote access service, where present, currently running on Windows NT 4.0 servers to a Windows Server 2003 RRAS solution, or devise an alternative solution to support Windows NT 4.0 RAS clients.

This step is necessary to ensure continued support for this solution following the in-place upgrade of the Windows NT 4.0 domain to a Windows Server 2003 domain. This is because the Windows NT 4.0 RAS service runs under the context of a local system account, and hence this service will communicate with other services over the network by using null sessions (a session in which a user name or password is not provided). In Windows 2000 and later operating systems, services running in the context of the Local System account on the local computer use the local computer account to authenticate to other servers, and Active Directory, by default, does not accept null session queries. Hence, when a Windows NT 4.0 RAS service attempts to use a null session against a Windows Server 2003 domain controller, to authenticate a RAS user, this will fail.

This design methodology identifies the following options:

• Upgrade the Windows NT 4.0 RAS server to a Windows 2000 or Windows Server 2003 RAS server (recommended option), or

• Reduce the security on the Active Directory to accept null credentials (not recommended option)

When determining the design requirements for the upgrade of all remote access servers running Windows NT 4.0 to Windows Server 2003, this design methodology proposes the following approach:



• Analyse the results of the analysis into the legacy domain environment to identify all routing and remote access servers and services running Windows NT 4.0 servers. Identify all RRAS services that require continued operation following the migration, and those that do not currently provide any services to the production environment of the organisation, and are hence outside of the scope of this step.

• Determine the following details for those RRAS servers within the scope of this step:

♦ Determine the routing and remote access service options installed on each server, as:

Remote access service (Installs support for client dial-up networking)

LAN routing (Installs support for LAN-to-LAN routing, including WAN cards that support LAN emulation)

Demand-dial routing (Installs support for routing over WANs and dial-up media, such as ISDN and PPTP)

♦ For all remote access service installations, determine the following details:

The protocols installed and supported (IP / IPX) by each instance of the remote access service, and details for each protocol. This information is necessary to support the recreation of the same minimum levels of support following the upgrade of this service to Windows Server 2003.

The requirements for the use of a RADIUS server for authentication, and where required, the details of the selected RADIUS service

The clients of the remote access service, and their geographical distribution, and supported access modes

The details of the dial-in permissions assigned to users, and supported configurations for dial back, static routes, packet filters, local host filters, PPTP filters, and so on.

The frequency of use of this service, and the associated dependencies upon this service

The consequences of an outage of this service to the users and the continuity of the organisation

The most opportune time for the migration of this service, to minimise disruption to the users that depend upon the service.

Where it is possible to identify Windows NT 4.0 RAS servers, determine the feasibility of an upgrade of these servers to a Windows 2000 or Windows Server 2003 RAS server. It is necessary to consider all aspects of this upgrade, such as the hardware specifications for the existing Windows NT 4.0 RAS server, and compatibility of these specifications with the minimum required specifications for Windows 2000 Server or Windows Server 2003, and so on.

Where an organisation does wish to consider the upgrade of existing Windows NT 4.0 RAs servers, then execute following:

• Where it is possible to identify Windows NT 4.0 RRAS servers hosting remote access services in addition to routing and demand-dial services, then determine the requirements to either:



♦ Partition the routing and demand-dial services to another Windows NT 4.0 server in the domain, or

♦ Upgrade these services to Windows Server 2003

• Where there is a requirement to partition the routing and / or demand-dial services from the remote access services, then determine the following:

♦ The details of the routing service on the Windows NT 4.0 server(s), identifying for example, the following information:

Details of the networks, protocols, and protocol architectures the routing server connects, the routing protocols installed and their configurations, and so on.

Details of the client computers of the routing service on these servers

♦ The details of the demand-dial service on the Windows NT 4.0 server(s), identifying for example, the following information:

Details of the demand-dial interfaces installed on the servers

Details of the ports configured for demand-dial, and so on

♦ The identity of a target server for the existing routing and / or demand-dial services

♦ The consequences of an outages to these services, during the migration, to business continuity

♦ The most opportune time for the migration of this service, to minimise disruption to the computers that depend upon the service.

• Where there is a requirement to upgrade these services to Windows Server 2003, determine the details of these services (as outlined above) and any requirements to modify these services after migration.

Where an organisation does not wish to upgrade the Windows NT 4.0 RAS servers, then consider the following:

• To ensure continued support for the Windows NT 4.0 RAS service, determine the requirement for the following:

♦ Selection of the option “Permissions compatible with pre-Windows 2000 Server operating systems” within the Active Directory Installation Wizard, or alternatively

♦ Addition of the “Everyone” and “Anonymous Logon” groups to the “Pre-Windows 2000 Compatible Access” built-in Domain Local security group, which allows read access on all users and groups in the domain. This action requires a restart of the Server service on all domain controllers within the domain.

• Note that following the completion of the upgrade of all legacy Windows NT 4.0 RAS servers to Windows 2000 or later, it is important to remove the “Everyone” and “Anonymous Logon” groups from the Domain Local “Pre-Windows 2000 Compatible Access” security group.

When determining the design requirements for coexistence plan tasks to ensure continued support for legacy clients, see the next factor.



An important coexistence plan task that requires design for execution is the configuration of the DNS infrastructure, supporting the new domain environment. All domain member computers running Windows 2000 and later operating systems will preferentially use the DNS infrastructure for name resolution. However, as member computers running Windows NT 4.0 or earlier operating systems do not dynamically update DNS zones with resource records, they will continue to use a WINS infrastructure for name resolution.

Hence, it may be necessary to configure the DNS zone to perform a WINS-lookup, pointing the existing WINS servers. This will hence facilitate Windows Server 2003 domain controllers and all other Windows 2000 or later member computers in location of pre-Windows 2000 computers.

Following the execution of the in-place upgrade of a PDC and the creation of the new Windows Server 2003 domain, it is necessary to recreate any external trust relationships still required between the upgraded domain and other external Windows NT 4.0 domains. This coexistence plan task is necessary to ensure all member computers and domain controllers running Windows 2000 and later operating systems gain better use of the external trusts.

When determining the design requirements for the process to execute this step, the process must consider the following:

The execution of this coexistence plan task involves the deletion and recreation of each external trust with a Windows NT 4.0 domain, from within both domains

The process must hence ensure cooperation of the owners of all affected domains, and use of the appropriate security credentials

The in-place upgrade of a PDC to create the Windows Server 2003 domain results in the creation of the first Windows Server 2003 domain controller. If the upgraded domain creates a new forest, and is hence the forest root domain, then the Windows Server 2003 domain controller will host all five FSMO roles. However, if the upgraded domain joins an existing forest, then the Windows Server 2003 domain controller will host only the three domain-level FSMO roles.

The PDC Emulator FSMO role is the most demanding role, with respect to hardware resource utilisation, on the Windows Server 2003 domain controller. Although the PDC was prepared (during pre-migration) with the “NT4Emulator” registry key (to negate differentiation between the Windows Server 2003 domain controller and existing BDCs), the role of the PDC Emulator function will still place a significant demand on the Windows Server 2003 domain controller.

However, it is possible to supplement the use of the “NT4Emulator” registry key via modification of the weight and priority values for this Windows Server 2003 domain controller in the appropriate DNS SRV resource records.

When determining the design requirements for the execution of this coexistence plan task, consider the following:

The execution of this task is only necessary where it is possible to identify compliance with all of following criteria:

The upgraded Windows NT 4.0 domain supports a very large number of security principals, such as a few thousand to tens of thousands, and

It is possible to observe that the CPU utilisation on the Windows Server 2003 domain controller hosting the PDC Emulator role constantly exceeds 50% and / or the disk queue length constantly exceeds 2 for several hours or days, and



It is possible to eliminate any other factors that may directly contribute to the excessive CPU utilisation and disk queue length, such as custom / proprietary Active Directory-enabled or LDAP-enabled applications designed to execute a significant number of read and / or write queries to the Active Directory.

Only where it is possible to identify compliance with all of the above criteria is it necessary to execute this task.

When determining the design requirement for the process to execute this task, consider the following:

Active Directory assigns a default value of 100 for the weight, and 0 (zero) for the priority of a DNS SRV resource record.

It is necessary to execute modifications to the weight and priority values for the DNS SRV resource records of a Windows Server 2003 domain controller hosting the PDC Emulator role via the creation of the following two registry entries:

• A REG_DWORD value named “LdapSrvWeight” for the weight

• A REG_DWORD value named “LdapSrvPriority” for the priority

The assignment of a value less than 100 for the “LdapSrvWeight” entry (recommended value is 50) will proportionately reduce the number of client authentications sent to the Windows Server 2003 domain controller hosting the PDC Emulator FSMO role

The assignment of a value greater than 0 (zero) for the “LdapSrvPriority” entry (recommended value is 200) will ensure that the Windows Server 2003 domain controller hosting the PDC Emulator FSMO role will never receive any requests for authentication, unless it is the only accessible domain controller.

It is necessary to create these REG_DWORD registry entries on the Windows Server 2003 domain controller hosting the PDC Emulator role, within the following registry key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters”

This design methodology categorises the coexistence plan tasks identified above for execution during the following phases of migration path “A”:

The coexistence plan task to bridge the LMRepl and FRS infrastructures requires execution during the post-migration phase of migration path “A”

The coexistence plan task to upgrade Windows NT 4.0 RAS servers to Windows 2000 or later operating systems requires execution during the pre-migration phase for migration path “A”

The coexistence plan task to modify the security settings on the new Active Directory domain to provide support for null sessions requires execution during the post-migration phase of migration path “A”

The coexistence plan task to configure DNS to use WINS lookup requires execution during the post-migration phase of migration path “A”

The coexistence plan task to recreate external trusts with Windows NT 4.0 domains requires execution during the post-migration phase of migration path “A”

The coexistence plan task to modify the weight and priority values for DNS SRV resource records for the Windows Server 2003 domain controller hosting the PDC



Emulator FSMO role requires execution during the post-migration phase of migration path “A”

Using the above information, execute an analysis to determine and document all of the design requirements for the coexistence plan tasks to support migration path “A”

• Factor A37: Determination of the design requirements for the coexistence plan tasks to ensure support for legacy clients for execution of migration path “A” and / or “C”


Has identified the requirement for the migration of one or more legacy Windows NT 4.0 domains using migration path “A” and / or “C”

Has identified the presence of a variety of client computers running operating systems earlier than Windows 2000 Professional, and

Wishes to determine the design requirements necessary to prepare these clients for the domain migration


Note that the criteria for the application of this factor exclude all client computers, running operating systems earlier than Windows 2000, which reside within legacy Windows 2000 domains. The assumption for these criteria is that the organisation has already prepared these clients to operate within the Windows 2000 Active Directory environment.

However, where this assumption is invalid, and the execution of migration paths “B” and / or “D” result in a Windows Server 2003 domain supporting pre-Windows 2000 domains, then it is necessary to consider the following to ensure support for these clients.

The execution of a migration from a legacy Windows NT 4.0 domain infrastructure to a Windows Server 2003 Active Directory infrastructure generates a significant number of changes to processes and infrastructure components for the clients of the legacy domain.

The ability for client computers to accommodate the changes to processes and infrastructure components are a reflection of the version of their operating system and the requirements to redesign a number of infrastructure support elements for these clients. Windows 2000 and later operating systems interoperate, by design, with a Windows 2000 and Windows Server 2003 Active Directory infrastructure.

However, Windows 95, Windows 98, and Windows NT 4.0 Workstation and Server clients are unable to interoperate with certain new features associated with Windows 2000 and Windows Server 2003 Active Directory.

The objectives of this step are to hence:

Prepare these clients for the changes and hence ensure business continuity throughout the migration phase

Identify changes required in infrastructure support elements to ensure continuity for the client computers during the migration phase

When determining the requirements to prepare the client computer operating systems for interoperation with a Windows Server 2003 Active Directory infrastructure, consider the following:



Some of the key changes that the client computers (which, for this factor, from now on refers exclusively to Windows 95, 98, and Windows NT 4.0 Server and Workstation) will experience when the legacy Windows NT 4.0 domain infrastructure is migrated to the new Windows Server 2003 Active Directory infrastructure are:

The ability to use the Active Directory Site infrastructure to locate a (Windows Server 2003) domain controller

The ability to interact with an Active Directory-integrated DFS infrastructure

The ability to view and change personal details for user account objects in the Active Directory

The ability to execute scripts that employ the Active Directory Service Interface (ADSI) on the client computers

The ability to use the default authentication protocol for Windows 2000 and Windows Server 2003 Active Directory (Kerberos V5)

The ability to receive and process Active Directory Group Policies

The ability to support IPSEC and L2TP networking protocols

The ability to support the use of Service Principal Names (SPNs) and mutual authentication

Microsoft released Active Directory client extensions for Windows 95, 98, and Windows NT 4.0 operating systems for Windows 2000 and Windows Server 2003 Active Directory that support the following:

Provision of support for:

• Location of Windows Server 2003 domain controllers using the Active Directory Site infrastructure, and hence location of domain controllers in the same Site or Site closest to the client, and

• Changing user account passwords at any Windows Server 2003 domain controller (and not just the PDC when interacting with the legacy Windows NT 4.0 domain)

Provision of support for the client to access DFS shared resources on Windows 2000 or Windows Server 2003 servers, and seamless access to failover shares

Provision of support for use of the improved features of NTLM version 2 authentication, such as encryption and hashing of the password (generation of 128-bit password-derived keys), use of case-sensitive passwords, better session security, and so on

Provision of support for the use of the Windows Address Book (WAB) to access user account objects in the Active Directory and change (where authorised) personal details, such as telephone numbers, address, and so on

Provision of support for the execution of scripts on the client machines that interface with the ADSI API via the Windows Scripting Host or other scripting systems

Note that the Active Directory client extensions do not provide support for the following elements associated with a Windows 2000 or Windows Server 2003 Active Directory infrastructure:



No support for the use of the default Active Directory authentication protocol (Kerberos V5), as this requires extensions to the kernel of the client operating system

No support for the use of Active Directory Group Policies or IntelliMirror management technologies, and hence there is a requirement for the (continued) use of Windows NT 4.0 System Policies to manage elements of these client computers

No support for the use of IPSEC and L2TP networking protocols, although Microsoft does provide discrete IPSEC and L2TP client extensions for these client computers

No support for the use of SPN or mutual authentication

When determining the design requirements for the process to identify and prepare all in-scope client computers, this design methodology proposes the following approach:

Identify all existing client computers that require installation of the Active Directory client extensions

Identify the opportunity to deploy the directory service client extensions to the client computers (recommended approach) or the necessity to modify the security policy for the Active Directory to support these clients (not recommended)

Where it is possible to identify the opportunity to deploy the directory service client, then execute the following:

• Identify all in-scope client computers that fail to comply with prerequisites for the installation of the Active Directory client extensions

• Upgrade the software elements of selected client computers to comply with the prerequisites for the installation of the Active Directory client extension

• Determine the design requirements for the process to deploy the Active Directory client extensions to the in-scope client computers

• Deploy the Active Directory client extension to the in-scope client computers

Where it is necessary to modify the default security policy for the Active Directory to support these legacy clients, then disable the following policy settings within the “Default Domain Controllers Policy” GPO (implemented on the Domain Controllers OU):

• Disable the Microsoft network server policy: “Digitally sign communications (always)”, and

• Disable the Domain member policy: “Digitally encrypt or sign secure channel data (always)”

When identifying the client computers that require the installation of the Active Directory client extensions, consider the following:

Only those client computers required to interoperate with the new Windows Server 2003 Active Directory infrastructure require this client extension. This hence excludes all client computers that currently and will comply with the following criteria:



• The client computers are standalone computers (members of a workgroup) and either not currently within the legacy Windows NT 4.0 domain, or not required to interact with the Windows Server 2003 domain.

• The client computers are destined for an upgrade / replacement to a new currently supported operating system (Windows 2000 or later).

• The client computers are outside of the scope of the migration for a legacy domain infrastructure. Note that there Windows 95 and 98 client computers are not assigned a computer account object, and hence not represented within a legacy Windows NT 4.0 domain as member computers. This absence often leads to the miscalculation of the scope of migration of a legacy domain infrastructure.

When identifying the client computers that fail to comply with the prerequisites for the installation of the Active Directory client extensions, consider the following:

For Windows NT 4.0 client computers, there is a requirement for the operating system to be running Service Pack (SP) version 6a, and Internet Explorer version 4.01 or later

For Windows 95 and 98 client computers, there is a requirement for the operating system to be running Internet Explorer version 4.01 or later

All Windows 95 and 98 client computers, with the installed Active Directory client extension, require an Active Directory computer account object. This is necessary to support client access and use of the features installed by the Active Directory client extension. Where an organisation has a large population of client computers running Windows 95 and / or 98, then this may significantly increase the size of the migration scope for the legacy domain.

When determining the design requirements for the process to deploy the Active Directory client extensions to the identified client computers, consider the following:

The “clients” folder on a Windows 2000 CD-ROM provides the Active Directory client extension for Windows 95 and 98 client computers, or alternatively, it is freely available for download from the Microsoft website.

The Active Directory client extension for Windows NT 4.0 clients is freely available for download from the Microsoft website.

The installation application for the Active Directory client extensions are small, and may be distributed using current software distribution channels, such as SMS 2.0 or SMS 2003, and so on.

When determining the requirements for the redesign of infrastructure support elements for these clients, consider the following:

The following infrastructure support elements are essential for client computers to interoperate with a new Windows Server 2003 Active Directory infrastructure:

The DNS infrastructure, to support the location of domain controllers and other member servers and services

The DHCP infrastructure, to support the leasing of IP address and scope options to the DHCP clients

Elements of the proposed DNS and DHCP infrastructures may hence require implementation as pre-migration tasks to ensure continued support for the client computers during the migration phase.



Note that following the in-place upgrade of a Windows NT 4.0 print server to become a Windows Server 2003 server, the upgrade process will remove drivers from the print queues that supported Windows 95 and 98 clients. It is hence necessary to re-install these drivers, from the “Printers\WIN9x” folder on the Windows Server 2003 CD-ROM.

This design methodology categorises the coexistence plan tasks identified above for execution during the following phases of migration path “A”:

The coexistence plan task to deploy the directory service client extension to pre-Windows 2000 computer in the domain requires execution during the pre-migration phase of migration path “A”

The coexistence plan task to modify the default security policies on Windows Server 2003 domain controllers, to disable requirements for SMB packets and secure channel signing, requires execution during the post-migration phase of migration path “A

The coexistence plan task to reinstall printer drivers for Windows 95 and 98 on print servers upgraded to Windows Server 2003 from Windows NT 4.0 requires execution during the post-migration phase of migration path “A”

Using the above information, execute an analysis to determine and document all of the design requirements for the coexistence plan tasks to ensure support for legacy clients for execution of migration path “A” and / or “C”.

• Factor A38: Determination of the design requirements for coexistence plan tasks to support migration path “B”


Has identified the requirements for the migration of one or more legacy Windows 2000 domains using migration path “B”, and

Wishes to determine the requirements for the design of coexistence plan tasks to support the pre-migration and post-migration phases of migration path “B”


Execution of approach 1 of migration path “B” involves the in-place upgrade of an existing Windows 2000 domain controller to become a Windows Server 2003 domain controller. Execution of approach 2 of migration path “B” involves the introduction of an additional domain controller into an existing Windows 2000 domain running the Windows Server 2003 operating system.

The execution of the pre-migration tasks for both of these approaches, and the actual migration activities, will immediately modify an existing Windows 2000 domain, and forest infrastructure to become a Windows Server 2003 domain and forest infrastructure.

Windows 2000 Active Directory and domain controllers support a significant number of features in common to Windows Server 2003 Active Directory and domain controllers. Hence, the only coexistence plan requirements for this migration path are to ensure continued support for the following:

Legacy Windows NT 4.0 servers that require the use of null sessions

Member computers running pre-Windows 2000 operating systems without the directory service client extensions installed



As the execution of migration path “B” typically occurs against a production Windows 2000 domain environment, it is highly unlikely to identify any existing legacy Windows NT 4.0 servers running services that require null sessions, or pre-Windows 2000 member computers without the appropriate directory service client extensions installed.

However, where it is possible to identify the presence of these coexistence requirements, then consult the previous factors (for migration path “A”) for details.

Using the above information, execute an analysis to determine and document all of the design requirements for the coexistence plan tasks to support the pre-migration and post-migration phases of migration path “B”.

5.9.3. Determination of the Design Requirements for the Contingency Plan

Consider the following when determining the design requirements for the contingency plan:

• Factor B12: Understanding the contingency plan

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concepts, scope, objectives, and components of the contingency plan, prior to determination of the design requirements for the plan.


This design methodology requires the design of a single contingency plan to support all required and supported migration paths.

The term “contingency” refers to an event that may occur in the future, such as a problem, emergency, or expense that might arise unexpectedly, and requires preparation to attend, handle, and where possible, resolve the event.

Due to the extensive number of variables associated with the execution of the majority of pre-migration, migration, and post-migration tasks for supported migration paths, there is a very high probability of contingency occurring. In addition, because of the level of impact of migration activities within a migration path on an organisation, contingency during execution of migration activities can have consequences ranging from mere inconvenience to disastrous disruptions to business continuity. This design methodology hence requires the design of a contingency plan to attend, handle, and resolve all predictable contingencies.

This design methodology hence defines the scope of the contingency plan by the requirements to handle all predictable contingencies, occurring only during the execution of any of the activities associated with any of the supported migration paths. The scope of this contingency plan hence excludes all unpredictable contingencies, and all contingencies that do not arise directly from the execution of any of the activities associated with any of the supported migration paths.

A contingency plan comprises the following:

The goals and scope of the contingency plan, and

The logical and physical manifestations of the contingency plan within the organisation to support each required migration path, such as:

Contingency plan tasks, for execution during pre-migration, migration, and post-migration phases of a migration path, to provide the foundations for the execution of a contingency plan procedure

Contingency plan procedures to reverse any identified contingencies



Criteria for the execution of the contingency plan procedures

Infrastructure components to support execution of the contingency plan procedures, such as backup hardware and software, restore servers, standard server builds, and so on

Resources within the organisation to manage and execute the contingency plan manifestations, and so on

The checklists to support execution of the contingency plan elements

Execution of contingency plan procedures typically relies upon the completion of preparatory tasks, and hence it is necessary to design and execute contingency plan tasks. The contingency plan tasks include, for example, the tasks to backup a server or domain prior to migration. The presence of a backup of a server or domain hence supports the execution of a contingency procedure, to perform a restore of a server or domain from the backup. Not all contingency plan procedures rely upon the completion of contingency plan tasks.

Hence, when determining the design requirements for the contingency plan, it is necessary for the design to address and support each of the components listed above.

When determining the design requirements for the goals and scope of the contingency plan, consider the following:

The goals of the contingency plan are a reflection of the predefined business and technical migration goals for this migration plan. The contingency plan goals will dictate the contents and extent of the contingency plan manifestations for each required migration path. For example, the organisation may have predefined a business migration goal that states that all failed migration activities require recovery and reversal within a specified period. The time allowed for recovery and reversal of any migration activities will dictate the design and scope of the contingency plan tasks and procedures.

The extent of the logical and physical manifestations of the contingency plan, and the number of migration paths it is required to support, define its scope.

The combination of the goals and the scope define the amount of time an organisation may allocate to:

The design and development of the contingency plan tasks and procedures, and

The execution of the preparatory contingency plan tasks for each required migration path

This design methodology proposes execution of the following approach to determine the design requirements for the contingency plan, to support each required migration path:

For each required instance of migration path “A”, determine the following:

The criteria for the execution of the contingency plan procedures, to attend, handle, and resolve contingency, arising during execution of migration path “A”.

The pre-migration and migration tasks in migration path “A”, which may generate compliance with the criteria for execution of the contingency plan procedures

The design requirements for the contingency plan tasks, to provide the foundation for:

• Execution of contingency plan procedures, and



• Categorisation of these tasks for execution during the pre-migration or migration phases of migration path “A”

The design requirements for the contingency plan procedures, to attend, handle, and resolve contingency arising during execution of migration path “A”

The design requirements for the contingency plan checklists to support execution of the identified tasks and procedures

Repeat for each required instance of migration path “B”

Repeat for each required instance of the inter-forest migration paths “C”, “D”, “F”, and “H”

Repeat for each required instance of the intra-forest migration paths “E” and “G”

• Factor A39: Determination of the design requirements for the contingency plan to support migration path “A”


Has identified the requirements for the migration of one or more legacy Windows NT 4.0 domains using migration path “A”, and

Wishes to determine the design requirements for the contingency plan to support each required instance of migration path “A”


When determining the criteria for the execution of the contingency plan procedures for migration path “A”, consider the following:

It is only necessary to execute the contingency plan procedures for migration path “A” where contingency arises during execution of the pre-migration and / or migration activities of this path.

The criteria for the execution of the contingency plan procedures must hence reflect only significant contingencies, and not events that are easily and simply addressed and / or reversible.

The criteria defined here may reflect specific activities executed within migration path “A”, or abstracted to the direct or indirect consequences of activities executed within the path.

Although the onus is with the organisation to define the criteria for the execution of the contingency plan procedures for migration path “A”, this design methodology provides the following example criteria. This design methodology considers it necessary to execute the contingency plan procedures for migration path “A” where it is possible to identify compliance with the following (example) criteria:

The execution of a migration activity has resulted in the loss of business continuity due to loss, for example, of the PDC for the domain

The execution of a pre-migration activity to perform directory clean up has deleted an active directory object, and not an “actually” or “potentially” redundant object

The execution of a pre-migration activity has compromised the continuity of a Windows NT 4.0 domain controller or member server



The activity generates a significant unacceptable consequence that is not easily reversible. For example, the accidental deletion of an external trust relationship is an unacceptable consequence of a pre-migration directory clean up activity. However, it is a simple matter to recreate the trust relationship, without any requirements for the execution of contingency plan procedures to restore a domain controller, and so on.

When determining the pre-migration and migration tasks, for migration path “A”, which may generate contingency and hence compliance with the criteria for execution of contingency plan procedures, consider the following:

All migration activities that alter the any aspect or component of a legacy Windows NT 4.0 domain environment can potentially generate contingency. Although the onus is with the organisation to determine all specific migration activities, for each required instance of migration path “A”, that can generate contingencies, this design methodology provides the following examples of such activities:

Pre-migration activities which can generate contingencies include the following examples:

• The execution of the pre-migration directory clean up tasks, to identify and remove redundant directory objects and data from a source domain, including policies and trust relationships, may generate contingencies. For example, the accidental deletion of viable directory objects or data elements, such as security group objects.

• The execution of any pre-migration tasks to modify the registry on domain controllers prior to migration may generate contingencies.

• The execution of pre-migration tasks to prepare the server hardware platform for a PDC for an in-place upgrade, via the installation of additional / replacement hardware components, may generate contingencies.

• The execution of pre-migration tasks to rebuild a PDC prior to upgrade to create an NTFS partition (where originally a FAT partition existed) may generate contingencies.

• The installation of service packs and post-service pack hotfixes and security patches on a PDC prior to upgrade may generate contingencies.

• The execution of the pre-migration tasks to prepare a PDC for migration may generate contingencies. For example, the migration and / or removal of applications and services off a PDC, and the failure to reinstall these applications and services successfully on to another server in the domain may generate disruptions to business continuity.

• The execution of the pre-migration tasks to prepare a target Windows Server 2003 Active Directory forest (for the upgraded Windows NT 4.0 domain) may generate contingencies. The pre-migration task to raise the functional level of the forest to “Windows Server 2003 Interim” is a non-reversible action, and can have significant unacceptable consequences.

Migration activities which can generate contingencies include the following examples:

• The execution of the first step in the migration (in-place upgrade of the operating system to Windows Server 2003) may generate contingencies due to a failure to complete successfully. It may be possible to identify a number of variables that could contribute to this contingency, such as failure to



upgrade the RAM on the PDC prior to execution of the in-place upgrade, and so on.

• The execution of the second step in the migration (execution of the Active Directory Installation Wizard) may generate contingencies. For example, it may be possible for the Active Directory Installation Wizard to fail, or the migration administrator accidentally selects the wrong options in the Wizard and, for example, creates a new forest instead of joining an existing forest, and so on.

When determining the design requirements for contingency plan tasks for migration path “A”, to support execution of contingency plan procedures, consider the following:

Although the onus is with the organisation to determine the design requirements for the contingency plan tasks for execution during the pre-migration phase of migration path “A”, this design methodology provides the following examples:

This design methodology recommends execution of a full backup of the PDC and at least one other BDC in a Windows NT 4.0 domain prior to the execution of any pre-migration directory clean up activities. It is important to confirm the absence of errors after the backup process is complete by checking the Backup.log file, clearly label each backup as a pre-migration backup, and store the backups in a safe location.

Where possible, this design methodology recommends taking one BDC offline, after completion of a full synchronisation with the PDC, just prior to execution of the in-place upgrade of the PDC. Taking the BDC offline protects the SAM database from any corruption, and executing this task just prior to the execution of the in-place upgrade ensures the SAM database is up to date.

This design methodology recommends the creation / update of the Emergency Repair Disk (ERD) for each domain controller, using the RDISK application. Execution of the RDISK command without any switches launches a dialog box with two options, to update an emergency repair disk, or to create an emergency repair disk. Execution of the RDISK command with the switch “/S” prompts the application to skip the initial dialog box and go straight into saving the configuration. The addition of a hyphen “-“ after the “/S” switch, as “/S-“, terminates the program after saving the configuration. Note that both of these options also overwrite the saved SAM._ and SECURITY._ registry hives created during initial Windows NT Installation. The default administrator account and password used during Setup is all that is contained in these small files. Execution of RDISK with these switches copies the entire current SAM and SECURITY database files containing all users and groups into the repair directory. On a domain controller, containing many hundreds or even thousands of users, these files can become very large which may hence prevent their copy to the emergency repair diskette (ERD). Hence, it is imperative to ensure adequate disk space prior to using either of these switches on Windows NT Machines and Domain Controllers that have a large number of users and groups defined. This design methodology also recommends, as a precaution, that a backup copy of the %systemroot%\repair directory is created first, to ensure the ability to create an emergency repair diskette after running RDISK while using one of the above switches.

This design methodology recommends the back up of the Master Boot Record and Partition Boot Sector on the PDC prior to execution of the in-place upgrade. It is important to back up the Master Boot Record after every change to the partition information for primary or extended partitions. It is important to back up the Partition Boot Sector after formatting a volume, installing Windows NT in the volume, or converting a volume from the FAT file system to the NTFS file system. It is possible to back up these disk sectors via the Windows NT 4.0 resource kit utilities “DiskProbe”, or the MS-DOS-based program, “DiskSave”. Note that



where the PDC has more than one hard disk or more than one partition on a disk, it is necessary to back up every Master Boot Record and Partition Boot Sector. The Master Boot Record for the startup disk and the Partition Boot Sector for your system partition are the most critical. The ones for the other disks and volumes are not as critical to the startup process, but it may not be possible to access files if the Master Boot Record for the disk or the Partition Boot Sector for the volume is not correct. This design methodology recommends the use of the DiskProbe tool to save the Master Boot Record and Partition Boot Sector to “*.dsk” files, which should be stored on the ERD for the domain controller. Ensure at least two copies of each set of files (ERD and *.dsk) exist, and are accessible at all times.

This design methodology recommends the export of the entire registry on the PDC prior to execution of any registry modifications. The registry editor “regedit.exe” provides the functionality to export the entire registry to a “*.reg” file, or it is possible to use the resource kit utility “regback.exe”, which exports the five registry hives (default, SAM, security, software, and system).

To protect against contingencies potentially generated during the upgrade of server hardware components of the domain controllers, during pre-migration phase of migration path “A”, it is important to confirm with the distributor and OEM for the server the validity of the upgrade components.

To protect against contingencies potentially generated during the rebuild of a domain controller, ensure the availability of a standard server build for the domain controllers or an updated and complete configuration worksheet. If neither is available, then there is a pre-migration contingency plan task to either create a standard server build or complete documentation of all domain controllers in the domain. The documentation of the domain controllers must include the following information for each domain controller, in sufficient detail to permit the accurate recreation of the domain controller where necessary:

• The NetBIOS name for the domain controller

• The physical and logical (network) location for the domain controller within the organisation

• The operating system, service pack, and post / interim service pack updates / hotfixes

• Use the Windows NT Diagnostics tool, in the Administrative Tools menu, to generate a print out of a complete report on the server.

• The role(s) of the domain controller

• The services the domain controller supports, such as participation in LMRepl (as an export or import server), RAS server, WINS, DNS, DHCP, and so on.

• The hardware configuration of the server, detailing the disk array configuration, partitions, file systems, NICs, network protocol configurations, and so on.

To protect the target Windows Server 2003 forest from any contingencies associated with the pre-migration tasks to raise the functional level of the target forest, it is necessary to ensure the execution of a full backup of the following domain controllers:

• All forest and domain-level FSMO role holders in the forest root domain



• All domain-level FSMO role holders in every other domain currently existing within the target Windows Server 2003 forest

Although the onus is with the organisation to determine their requirements for the contingency plan tasks for execution during the migration phase of migration path “A”, this design methodology provides the following examples:

To protect against failures during execution of the first step in the migration phase for migration path “A”, it is important to ensure all hardware upgrades are completed and tested. The most common cause for failures are hardware issues. This design methodology also recommends execution of the following steps, as pre-migration contingency plan tasks:

• Ensure the server hardware platform and all hardware components are on the Hardware Compatibility List for Windows Server 2003

• Check the System, Application, and Security event logs in Event Viewer to verify the absence of any errors. Where it is possible to identify any errors, it is necessary to troubleshoot and resolve all errors prior to execution of the in-place upgrade.

• Remove all superfluous software and utilities, virus scanners, third-party network services, and client software. This design methodology recommends consultation of the Release Notes file (Relnotes.htm found in the DOCS folder on the Windows Server 2003 Server CD-ROM) prior to execution of the in-place upgrade, as it provides detailed information about any known problems with specific programs.

• Disconnect uninterruptible power supply (UPS) devices from the PDC, via removal of the serial cable that connects any UPS devices to the server. During the upgrade process, Windows Server 2003 will automatically detect devices connected to serial ports, and this may cause problems with the detection process.

• Where the server platform for the PDC supports non-Plug and Play ISA devices, it is important to reserve all IRQs currently in use by non-Plug and Play ISA devices. Failure to perform this task may result in the generation of an error message such as “INACCESSESSIBLE_BOOT_DEVICE”. Note that some non-Plug and Play ISA devices may not function correctly after the upgrade and it is hence important to verify their presence on the HCL for Windows Server 2003. If any non-Plug and Play ISA devices are not present on the HCL for Windows Server 2003, consider the removal of these devices and / or replacement, where possible.

To protect against incorrect selection of configuration options for the second step (execution of Active Directory Installation Wizard), generate a detailed checklist of all required options for this step.

This design methodology also recommends execution of the following steps, as pre-migration contingency plan tasks:

• Where there is a requirement for the Windows NT 4.0 domain to become an upgraded Windows Server 2003 domain in an existing Windows Server 2003 forest, then execute the following:

♦ Configure the TCP/IP protocol stack on the PDC with the IP addresses for the appropriate DNS servers, supporting the target Windows Server 2003 forest.



♦ Where there is a requirement to permit the Active Directory Installation Wizard to perform the initial population of the DNS zone for this domain with the DNS SRV resource records, then ensure that:

The DNS zone for the domain is created on the appropriate DNS server, to which the PDC is configured to primarily use, and

The DNS zone is configured to permit dynamic updates (secure and non-secure)

♦ Run name resolution tests on the PDC to ensure connectivity with the existing Windows Server 2003 domain controllers for the target forest.

• Where there is a requirement to create a new forest via the in-place upgrade of the existing Windows NT 4.0 domain, then execute the following:

♦ Configure the TCP/IP protocol stack on the PDC with the IP addresses for the DNS servers to support the new forest.

♦ Where there is a requirement to permit the Active Directory Installation Wizard to perform the initial population of the DNS zone for this domain with the DNS SRV resource records, then ensure that:

The DNS zone for the domain is created on the appropriate DNS server, to which the PDC is configured to primarily use, and

The DNS zone is configured to permit dynamic updates (secure and non-secure)

When determining the design requirements for the contingency plan procedures, for execution upon identification of compliance with the predefined criteria, consider the following:

This design methodology requires the contingency plan procedures to define the following:

The steps necessary to evaluate the predefined criteria to identify compliance

The steps necessary to recover from an identified contingency, that complies with the predefined criteria for execution of the contingency plan procedure

The estimated time required to execute the defined contingency plan procedures

The physical and logical manifestations of the contingency plan procedure necessary to support its execution, such as:

• Logical aspects to include:

♦ Availability of the software to perform a recovery, such as the operating system, service packs, drivers, utilities, applications, and so on

♦ Availability of the computer account objects, and the security credentials to execute the contingency plan procedures, and so on

• Physical aspects to include:

♦ Availability of the server hardware platforms, such as a dedicated standby restore server, the backup hardware, network infrastructure components (hubs, switches, routers), and so on



♦ Availability of the server room; server rack; pilot laboratory environment to support execution of the contingency plan procedures, and so on

When determining the design requirements for the steps necessary to evaluate the predefined criteria, consider the following:

This design methodology recommends nomination of a migration team leader or migration board to perform the following activities during execution of the pre-migration and migration tasks for migration path “A”:

• Collect the results of all pre-migration and migration tasks executed for migration path “A”

• Evaluate all results against the predefined criteria for the execution of a contingency plan procedure, and determine the requirements for the execution of the contingency plan procedure

It is necessary identify and define, in writing, which users are nominated to perform these tasks, and responsible for the determination of the requirements for the execution of the contingency plan procedure

Although the onus is with the organisation to determine their design requirements for the steps to recover from an identified contingency, this design methodology provides the following guidance:

For each identified potential cause of a contingency, determine the design requirements for a contingency plan procedure to counter and resolve the contingency. The procedure should utilise any foundations for contingency resolution generated by the execution of the contingency plan tasks, during the pre-migration and / or migration phases of migration path “A”.

For example, upon failure of the in-place upgrade of the PDC, the contingency plan procedure must detail the necessary steps to recovery the original domain functionality. This hence implies re-establishing a PDC for the domain via either the re-build of the failed PDC, or the recommended option to bring online the previously removed BDC, and promote this to become the PDC for the domain. Synchronise the promoted PDC with the remaining BDCs in the domain, and the Windows NT 4.0 domain can then continue to function while the failed PDC undergoes a rebuild.

Note that this example procedure requires any existing Windows Server 2003 domain controllers for the domain to be taken offline prior to the promotion of the previously offline BDC to the role of PDC for the Windows NT 4.0 domain.


Determine and document the criteria for the execution of the contingency plan procedures, to attend, handle, and resolve contingency, arising during execution of migration path “A”

Determine and document the pre-migration and migration tasks in migration path “A”, which may generate compliance with the criteria for execution of the contingency plan procedures

Determine and document the design requirements for the contingency plan tasks, to provide the foundation for:

Execution of contingency plan procedures, and

Categorisation of these tasks for execution during the pre-migration or migration phases of migration path “A”



Determine and document the design requirements for the contingency plan procedures, to attend, handle, and resolve contingency arising during execution of migration path “A”

Determine and document the design requirements for the contingency plan checklists to support execution of the identified tasks and procedures

• Factor A40: Determination of the design requirements for the contingency plan to support migration path “B”


Has identified the requirements for the migration of one or more legacy Windows 2000 domains using migration path “B”, and

Wishes to determine the design requirements for the contingency plan to support each required instance of migration path “B”


When determining the criteria for the execution of the contingency plan procedures for migration path “B”, consider the following:

It is only necessary to execute the contingency plan procedures for migration path “B” where contingency arises during execution of the pre-migration and / or migration activities of this path.


The criteria defined here may reflect specific activities executed within migration path “B”, or abstracted to the direct or indirect consequences of activities executed within the path.

Although the onus is with the organisation to define the criteria for the execution of the contingency plan procedures for migration path “B”, this design methodology provides the following example criteria. This design methodology considers it necessary to execute the contingency plan procedures for migration path “B” where it is possible to identify compliance with the following (example) criteria:

The execution of a migration activity has resulted in the loss of business continuity due to loss, for example, of one or more domain controllers for the domain


The execution of a pre-migration activity has compromised the continuity of a Windows 2000 domain controller or member server




When determining the pre-migration and migration tasks, for migration path “B”, which may generate contingency and hence compliance with the criteria for execution of contingency plan procedures, consider the following:

All migration activities that alter the any aspect or component of a legacy Windows 2000 forest and domain environment can potentially generate contingency. Although the onus is with the organisation to determine all specific migration activities, for each required instance of migration path “B”, that can generate contingencies, this design methodology provides the following examples of such activities:

The pre-migration activities, common to both approaches in migration path “B”, which can generate contingencies include the following examples:

• The execution of the extensive pre-migration directory clean up tasks, to identify and remove redundant directory objects and data from a source domain, may generate contingencies. For example, the accidental deletion of viable directory objects or data elements, such as security group objects.

• The execution of the irreversible “adprep.exe” commands, “adprep /forestprep” and “adprep /domainprep” (to extend and prepare the Windows 2000 Active Directory Schema, forest, and domain(s) for Windows Server 2003 Active Directory), may generate contingencies. For example, the commands may fail to execute where it is possible to identify one or more of the following example scenarios:

♦ The security context employed for the execution of these commands has insufficient rights and permissions, due to lack of membership to the “Enterprise Admins” security group in the forest root domain, the “Schema Admins” group, the “Domain Admins” group for each domain where the /domainprep command requires execution, and so on.

♦ The pre-migration tasks to prepare a Windows 2000 forest Schema, extended with Exchange 2000 object classes and attributes, were not executed, and the /forestprep command “mangles” certain attributes.

The pre-migration activities, specific to approach 1 of migration path “B” (in-place upgrade of existing Windows 2000 domain controller), which can generate contingencies include the following examples:

• The execution of any pre-migration tasks to update the service pack versions, post-service pack hotfixes, and security patches may generate contingencies.

• The execution of any pre-migration tasks to modify the registry on a Windows 2000 domain controller prior to migration may generate contingencies.

• The execution of pre-migration tasks to prepare the server hardware platform for a Windows 2000 domain controller for an in-place upgrade, via the installation of additional / replacement hardware components, may generate contingencies.

• The execution of the pre-migration tasks to prepare a Windows 2000 domain for migration may generate contingencies. For example, the migration and / or removal of superfluous and unsupported applications and services off a Windows 2000 domain controller, and the failure to reinstall these applications and services successfully on to another server in the domain, may generate disruptions to business continuity.

Pre-migration activities, specific to approach 2 of migration path “B” (introduction of an additional Windows Server 2003 domain controller), which can generate contingencies include the following examples:



• The execution of the pre-migration tasks to build and prepare an additional Windows Server 2003 member server may generate contingencies. For example, the installation of the Windows Server 2003 operating system on existing server hardware may fail due to lack of support for this operating system by the OEM (no drivers available) and lack of support of the operating system for the server hardware.

Migration activities which can generate contingencies include the following examples:

• Although the execution of the migration for approach 1 is an automated process, it may generate contingencies due to a failure to complete successfully. It may be possible to identify a number of variables that could contribute to this contingency, such as failure to upgrade the RAM on the Windows 2000 domain controller prior to execution of the in-place upgrade, and so on.

• The execution of the migration for approach 2 (execution of the Active Directory Installation Wizard) may generate contingencies. For example, it may be possible for the Active Directory Installation Wizard to fail, or the migration administrator accidentally selects the wrong options in the Wizard and, for example, creates a new domain and / or forest instead of creating an additional domain controller for the existing domain, and so on.

When determining the design requirements for contingency plan tasks for migration path “B”, to support execution of contingency plan procedures, consider the following:

Although the onus is with the organisation to determine the design requirements for the contingency plan tasks for execution during the pre-migration phase of migration path “B”, this design methodology provides the following examples:

This design methodology recommends determination of the design requirements for the execution of the following contingency plan tasks, for both approaches 1 and 2 of migration path “B”:

• To protect a Windows 2000 forest and domain from any contingencies that may arise via the execution of the “adprep /forestprep” and “adprep /domainprep” commands, this design methodology recommends execution of the following tasks:

♦ Execute a system state backup of all domain controllers, in the forest root domain hosting the forest and domain-level FSMO roles for this domain and forest, prior to the execution of any Schema clean up tasks.

♦ Prior to execution of any Schema clean up tasks, perform an export of the Schema using LDIFDE (see earlier for details of the required commands). After execution of any Schema clean up tasks, verify the success of the tasks.

♦ If the clean up tasks are successful, then execute following contingency plan tasks prior to execution of the “adprep /forestprep” and “adprep /domainprep” commands:

Execute another system state backup of all domain controllers, in the forest root domain hosting the forest and domain-level FSMO roles for this domain and forest

Perform another export of the Schema using LDIFDE. Note that the pre-migration tasks for the execution of the “adprep /forestprep” and “adprep /domainprep” commands already define the necessary steps to



export the Schema, but from the perspective to support the verification of the results of these commands, and not from the perspective of the requirement to support a possible reversal of these commands.

• To protect against contingencies potentially generated during the requirement to rebuild of a domain controller, ensure the availability of a standard server build for the domain controllers or an updated and complete configuration worksheet. If neither is available, then there is a pre-migration contingency plan task to either create a standard server build or complete documentation of all domain controllers in the domain. The documentation of the domain controllers must include the following information for each domain controller, in sufficient detail to permit the accurate recreation of the domain controller where necessary:

♦ The NetBIOS and DNS Host names for the domain controller

♦ The physical and logical (network) location for the domain controller within the organisation

♦ The operating system, service pack, and post / interim service pack updates / hotfixes

♦ Use the System Information tool, in the “Accessories\System Tools” menu, to generate and save a System Information File (*.nfo). This file contains a significant amount of detail about the hardware, operating system, and software environment of the domain controller.

♦ The role(s) of the domain controller, including the hosting of domain-level and / or forest-level FSMO roles

♦ The hardware configuration of the server, detailing the disk array configuration, partitions, file systems, NICs, network protocol configurations, and so on.

• To protect against contingencies potentially generated during the upgrade of server hardware components of the domain controllers, during pre-migration phase of migration path “B”, it is important to confirm with the distributor and OEM for the server the validity of the upgrade components.

This design methodology recommends determination of the design requirements for the execution of the following contingency plan tasks, for approach 1 of migration path “B”:

• A full backup of the target Windows 2000 domain controller and at least one other Windows 2000 domain controller prior to the execution of any pre-migration directory clean up activities. It is important to confirm the absence of errors after the backup process is complete by checking the Backup.log file, clearly label each backup as a pre-migration backup, and store the backups in a safe location. A backup of only the System State on these Windows 2000 domain controllers may suffice.

• Where possible, this design methodology recommends taking one Windows 2000 domain controller for the domain offline, after completion of a full synchronisation with its replication partners, just prior to execution of the in-place upgrade. Taking a Windows 2000 domain controller offline protects the Active Directory database from any corruption, and executing this task just prior to the execution of the in-place upgrade ensures the Active Directory database is up to date.



• Create / update the Emergency Repair Disk (ERD) for each domain controller using the Windows 2000 Backup application (NTBackup.exe). Selection of the “Emergency Repair Disk” option from the Welcome page for Windows 2000 Backup prompts to create the ERD and backup the registry to the repair directory.

• Back up the Master Boot Record and Partition Boot Sector on the Windows 2000 domain controller prior to execution of the in-place upgrade. It is important to back up the Master Boot Record after every change to the partition information for primary or extended partitions. It is important to back up the Partition Boot Sector after formatting a volume, installing Windows NT in the volume, or converting a volume from the FAT file system to the NTFS file system. It is possible to back up these disk sectors via the Windows 2000 Support Tools “DiskProbe”. Note that where the Windows 2000 domain controller has more than one hard disk or more than one partition on a disk, it is necessary to back up every Master Boot Record and Partition Boot Sector. The Master Boot Record for the startup disk and the Partition Boot Sector for your system partition are the most critical. The ones for the other disks and volumes are not as critical to the startup process, but it may not be possible to access files if the Master Boot Record for the disk or the Partition Boot Sector for the volume is not correct. This design methodology recommends the use of the DiskProbe tool to save the Master Boot Record and Partition Boot Sector to “*.dsk” files, which should be stored on the ERD for the domain controller. Ensure at least two copies of each set of files (ERD and *.dsk) exist, and are accessible at all times.

• Export the entire registry on the Windows 2000 domain controller prior to execution of any registry modifications. The registry editor “regedit.exe” provides the functionality to export the entire registry to a “*.reg” file, or it is possible to use the resource kit utility “regback.exe”, which exports the five registry hives (default, SAM, security, software, and system).

This design methodology recommends determination of the design requirements for the execution of the following contingency plan tasks, for approach 2 of migration path “B”:

• As the pre-migration tasks for approach 2 complete with the generation of a Windows Server 2003 member server, destined to become a Windows Server 2003 domain controller, any contingencies that arise from the build and preparation of this server are insignificant. This is because, at this stage in migration path “B”, where this server is designed exclusively to become a new Windows Server 2003 domain controller, then this server is superfluous to the continuity of the Windows 2000 domain and organisation.

• There are hence no requirements to design for execution any contingency plan tasks, for the pre-migration phase of approach 1 of migration path “B”.

Although the onus is with the organisation to determine their requirements for the contingency plan tasks for execution during the migration phase of migration path “B”, this design methodology provides the following examples:

To protect against failures during execution of the migration phase for approach 1 of migration path “B”, it is important to ensure all hardware upgrades are completed and tested. The most common cause for failures are hardware issues. This design methodology also recommends execution of the following steps, as pre-migration contingency plan tasks:

• Ensure the server hardware platform and all hardware components are on the Hardware Compatibility List for Windows Server 2003



• Check the System, Application, and Security event logs in Event Viewer to verify the absence of any errors. Where it is possible to identify any errors, it is necessary to troubleshoot and resolve all errors prior to execution of the in-place upgrade.

• Remove all superfluous software and utilities, virus scanners, third-party network services, and client software. This design methodology recommends consultation of the Release Notes file (Relnotes.htm found in the DOCS folder on the Windows Server 2003 Server CD-ROM) prior to execution of the in-place upgrade, as it provides detailed information about any known problems with specific programs.

• Disconnect uninterruptible power supply (UPS) devices from the Windows 2000 domain controller, via removal of the serial cable that connects any UPS devices to the server. During the upgrade process, Windows Server 2003 will automatically detect devices connected to serial ports, and this may cause problems with the detection process.

To protect against incorrect selection of configuration options during execution of Active Directory Installation Wizard (for approach 2 of migration path “B”), generate a detailed checklist of all required options for this step.
















This design methodology recommends nomination of a migration team leader or migration board to perform the following activities during execution of the pre-migration and migration tasks for migration path “B”:

• Collect the results of all pre-migration and migration tasks executed for migration path “B”




Determine and document the criteria for the execution of the contingency plan procedures, to attend, handle, and resolve contingency, arising during execution of migration path “B”

Determine and document the pre-migration and migration tasks in migration path “B”, which may generate compliance with the criteria for execution of the contingency plan procedures



Categorisation of these tasks for execution during the pre-migration or migration phases of migration path “B”

Determine and document the design requirements for the contingency plan procedures, to attend, handle, and resolve contingency arising during execution of migration path “B”


• Factor A41: Determination of the design requirements for the contingency plan to support the inter-forest migration paths “C”, “D”, “F”, and “H”


Has identified the requirements for the migration from one or more Windows NT 4.0 / Windows 2000 / Windows Server 2003 domains using the inter-forest migration paths “C”, “D”, “F”, and “H”, and

Wishes to determine the design requirements for the contingency plan to support each required instance of these migration paths


When determining the criteria for the execution of the contingency plan procedures for migration paths “C”, “D”, “F”, and “H”, consider the following:



It is necessary to execute the contingency plan procedures for migration paths “C”, “D”, “F”, and “H” where contingency arises during execution of the pre-migration, migration, or post-migration activities of these paths.


The criteria defined here may reflect specific activities executed within migration paths “C”, “D”, “F”, and “H”, or abstracted to the direct or indirect consequences of activities executed within these paths.

Although the onus is with the organisation to define the criteria for the execution of the contingency plan procedures for migration paths “C”, “D”, “F”, and “H”, this design methodology provides the following example criteria. This design methodology considers it necessary to execute the contingency plan procedures for migration paths “C”, “D”, “F”, and “H” where it is possible to identify compliance with the following (example) criteria:



The execution of a pre-migration activity has compromised the continuity of a domain controller or member server in the source or target domains


When determining the pre-migration, migration, and post-migration tasks for migration paths “C”, “D”, “F”, and “H”, which may generate contingency and hence compliance with the criteria for execution of contingency plan procedures, consider the following:

All migration activities that alter the any aspect or component of a source and target domain environment can potentially generate contingency.

The nature of the inter-forest migration paths “C”, “D”, “F”, and “H” mean that there is very little disruption to the source domain during execution of the actual migration activities themselves. However, there is significant potential for contingencies to arise due to execution of the following migration activities:

Pre-migration activities to prepare a source domain for execution of an inter-forest migration path

Pre-migration activities to prepare a target domain for execution of an inter-forest migration path

The results of migration activities on the target domain

Post-migration activities for an inter-forest migration path

Although the onus is with the organisation to determine all specific migration activities, for each required instance of migration paths “C”, “D”, “F”, and “H”, that



can generate contingencies, this design methodology provides the following examples of such activities:

The pre-migration activities to prepare a source domain for execution of an inter-forest migration path, which may generate contingencies include the following examples:

• The execution of the pre-migration directory clean up tasks, to identify and remove redundant directory objects and data from a source domain, may generate contingencies. For example, the accidental deletion of viable directory objects or data elements, such as security group objects.

• The execution of pre-migration tasks to prepare a source domain and domain controllers for migration of SIDs into the SIDHistory attribute of cloned security principals

• The execution of pre-migration tasks to prepare a source domain and domain controller(s) for migration of user account passwords

The pre-migration activities to prepare a target domain for execution of an inter-forest migration path, which may generate contingencies include the following examples:

• The execution of the pre-migration directory clean up tasks, to identify and remove redundant directory objects and data from a target domain, may generate contingencies. For example, the accidental deletion of viable directory objects or data elements, such as security group objects.

• The execution of pre-migration tasks to prepare a target domain and domain controllers for migration of SIDs from the source domain into the SIDHistory attribute of cloned security principals

• The execution of pre-migration tasks to prepare a target domain and domain controller(s) for migration of user account passwords from the source domain

The results of migration activities that may generate contingencies include the following example:

• The incorrect execution of any ADMT version 2.0 Migration Wizards, such as the User Account Migration Wizard, or the Computer Account Migration Wizard, followed by the immediate execution of another migration wizard. This hence negates the ability to use the “Undo Wizard”, and generates a contingency. The deliverables of the incorrectly executed migration wizard will determine the extent of the contingency, and hence the possible procedures for reversal of the contingency.

The post-migration activities that may generate contingencies include the following examples:

• The execution of post-migration tasks migrate legacy domain controllers and decommission the source domains

• The execution of the post-migration task to clear the SIDHistory attributes of cloned security principals

When determining the design requirements for contingency plan tasks for migration paths “C”, “D”, “F”, and “H”, to support execution of contingency plan procedures, consider the following:

Although the onus is with the organisation to determine the design requirements for the contingency plan tasks, for execution during the pre-migration phase of



migration paths “C”, “D”, “F”, and “H”, this design methodology provides the following examples:

To protect a source domain from any contingencies associated with the execution of pre-migration directory clean up tasks, execute a complete backup of at least two domain controllers in the source domain. For migration path “C”, backup the PDC and one BDC in the source domain. For migration paths “D”, “F”, and “H”, backup the system state on the two domain controllers hosting the domain-level FSMO roles for the source domain. It is important to confirm the absence of errors after the backup process is complete by checking the Backup.log file, clearly label each backup as a pre-migration backup, and store the backups in a safe location.

Where possible, this design methodology recommends taking one domain controller for the source domain offline, after completion of a full synchronisation with the PDC / replication partners, just prior to execution of any pre-migration tasks. Taking a domain controller offline protects the SAM / Active Directory database from any corruption, and executing this task just prior to the execution of the pre-migration tasks ensures the SAM / Active Directory database is up to date.

Prior to execution of the pre-migration tasks to configure the Password Export Server (PES) for the source domain, execute the following tasks:

• Execute a full backup of the domain controller

• Export the entire registry on the domain controller prior to execution of any registry modifications. The registry editor “regedit.exe” provides the functionality to export the entire registry to a “*.reg” file, or it is possible to use the resource kit utility “regback.exe”, which exports the five registry hives (default, SAM, security, software, and system).

Although the onus is with the organisation to determine their requirements for the contingency plan tasks for execution during the migration phase of migration paths “C”, “D”, “F”, and “H”, this design methodology provides the following guidance and examples:

The ADMT version 2.0 “Undo Wizard” will only reverse the last migration operation performed in the ADMT version 2.0 console using the “User Account Migration Wizard”, the “Group Account Migration Wizard”, and the “Computer Account Migration Wizard”. It will not reverse the operations of any of the other ADMT version 2.0 wizards, such as the “Service Account Migration Wizard” or “Security Translation Wizard”, and so on. It is hence also important to ensure the following:

• Only one migration administrator and one instance of ADMT version 2.0 executes the migration wizards

• The migration administrator / team perform extensive post-migration checks after the live execution of each migration wizard, and prior to the next live execution

To protect against incorrect execution of migration wizards, and selection of configuration options within the wizards, generate a detailed checklist of all required options for this step.
















This design methodology recommends nomination of a migration team leader or migration board to perform the following activities during execution of the pre-migration and migration tasks for migration paths “C”, “D”, “F”, and “H”:

• Collect the results of all pre-migration and migration tasks executed for migration paths “C”, “D”, “F”, and “H”




Determine and document the criteria for the execution of the contingency plan procedures, to attend, handle, and resolve contingency, arising during execution of migration paths “C”, “D”, “F”, and “H”

Determine and document the pre-migration, migration, and post-migration tasks in migration paths “C”, “D”, “F”, and “H”, which may generate compliance with the criteria for execution of the contingency plan procedures





Categorisation of these tasks for execution during the pre-migration, migration, and post-migration phases of migration paths “C”, “D”, “F”, and “H”

Determine and document the design requirements for the contingency plan procedures, to attend, handle, and resolve contingency arising during execution of migration paths “C”, “D”, “F”, and “H”


• Factor A42: Determination of the design requirements for the contingency plan to support the intra-forest migration paths “E” and “G”


Has identified the requirements for the migration of one or more Windows Server 2003 / Windows 2000 domains using the intra-forest migration paths “E” and “G” respectively, and

Wishes to determine the design requirements for the contingency plan to support each required instance of these migration paths


When determining the criteria for the execution of the contingency plan procedures for migration paths “E” and “G”, consider the following:

It is necessary to execute the contingency plan procedures for migration paths “E” and “G” where contingency arises during execution of the pre-migration, migration, or post-migration activities of these paths.


The criteria defined here may reflect specific activities executed within migration paths “E” and “G”, or abstracted to the direct or indirect consequences of activities executed within these paths.

Although the onus is with the organisation to define the criteria for the execution of the contingency plan procedures for migration paths “E” and “G”, this design methodology provides the following example criteria. This design methodology considers it necessary to execute the contingency plan procedures for migration paths “E” and “G” where it is possible to identify compliance with the following (example) criteria:



The execution of a pre-migration activity has compromised the continuity of a domain controller or member server in the source or target domains




When determining the pre-migration, migration, and post-migration tasks for migration paths “E” and “G”, which may generate contingency and hence compliance with the criteria for execution of contingency plan procedures, consider the following:

All migration activities that alter the any aspect or component of a source and target domain environment can potentially generate contingency.

The nature of the intra-forest migration paths “E” and “G” mean that there is potential for significant disruption to the source domain during execution of the actual migration activities. This is because an intra-forest migration path moves directory objects between the domains in the same forest, and not copy or clone the objects. Hence, a failed or incorrect execution of a migration wizard may generate a contingency for both the source and target domains.

This design methodology hence recognises the significant potential for contingencies to arise due to execution of the following migration activities:

Pre-migration activities to prepare a source domain for execution of an intra-forest migration path

Pre-migration activities to prepare a target domain for execution of an intra-forest migration path

The results of migration activities on the source and target domains

Post-migration activities for an intra-forest migration path

Although the onus is with the organisation to determine all specific migration activities, for each required instance of migration paths “E” and “G”, that can generate contingencies, this design methodology provides the following examples of such activities:

The pre-migration activities to prepare a source domain for execution of an intra-forest migration path, which may generate contingencies include the following examples:

• The execution of the pre-migration directory clean up tasks, to identify and remove redundant directory objects and data from a source domain, may generate contingencies. For example, the accidental deletion of viable directory objects or data elements, such as security group objects.

• The execution of pre-migration tasks to prepare a source domain for preservation of closed “user” and “resource” sets

• The execution of pre-migration tasks to prepare a source domain and domain controller(s) for migration of user account passwords

The pre-migration activities to prepare a target domain for execution of an intra-forest migration path, which may generate contingencies, include the execution of pre-migration tasks to raise the domain mode / functional level for the domain.

The results of migration activities that may generate contingencies include the following example:



• The incorrect execution of any ADMT version 2.0 Migration Wizards, such as the User Account Migration Wizard, or the Computer Account Migration Wizard, followed by the immediate execution of another migration wizard. This hence negates the ability to use the “Undo Wizard”, and generates a contingency. The deliverables of the incorrectly executed migration wizard will determine the extent of the contingency, and hence the possible procedures for reversal of the contingency.

The post-migration activities that may generate contingencies include the following examples:

• The execution of post-migration tasks migrate domain controllers and decommission the source domains

• The execution of security translation wizards on migrated member computers

When determining the design requirements for contingency plan tasks for migration paths “E” and “G”, to support execution of contingency plan procedures, consider the following:

Although the onus is with the organisation to determine the design requirements for the contingency plan tasks, for execution during the pre-migration phase of migration paths “E” and “G”, this design methodology provides the following examples:

To protect a source domain from any contingencies associated with the execution of pre-migration directory clean up tasks, execute a complete backup of at least two domain controllers in the source domain. Execute a backup of the system state on the two domain controllers hosting the domain-level FSMO roles for the source domain. It is important to confirm the absence of errors after the backup process is complete by checking the Backup.log file, clearly label each backup as a pre-migration backup, and store the backups in a safe location.

Where possible, this design methodology recommends taking one domain controller for the source domain offline, after completion of a full synchronisation with the replication partners, just prior to execution of any pre-migration tasks. Taking a domain controller offline protects the Active Directory database from any corruption, and executing this task just prior to the execution of the pre-migration tasks ensures the Active Directory database is up to date.

Prior to execution of the pre-migration tasks to configure the Password Export Server (PES) for the source domain, execute the following tasks:

• Execute a full backup of the domain controller

• Export the entire registry on the domain controller prior to execution of any registry modifications. The registry editor “regedit.exe” provides the functionality to export the entire registry to a “*.reg” file, or it is possible to use the resource kit utility “regback.exe”, which exports the five registry hives (default, SAM, security, software, and system).

Although the onus is with the organisation to determine their requirements for the contingency plan tasks for execution during the migration phase of migration paths “E” and “G”, this design methodology provides the following guidance and examples:

The ADMT version 2.0 “Undo Wizard” will only reverse the last migration operation performed in the ADMT version 2.0 console using the “User Account Migration Wizard”, the “Group Account Migration Wizard”, and the “Computer Account Migration Wizard”. It will not reverse the operations of any of the other ADMT version 2.0 wizards, such as the “Service Account Migration Wizard” or



“Security Translation Wizard”, and so on. It is hence also important to ensure the following:

• Only one migration administrator and one instance of ADMT version 2.0 executes the migration wizards

• The migration administrator / team perform extensive post-migration checks after the live execution of each migration wizard, and prior to the next live execution

To protect against incorrect execution of migration wizards, and selection of configuration options within the wizards, generate a detailed checklist of all required options for this step.

This design methodology recommends design of the following contingency plan task to guard against contingencies associated with the failed / incorrect execution of a migration wizard:

• Because an intra-forest migration moves directory objects between domains, where there is a requirement to reverse this action, an organisation has the following two options:

♦ The first option is to perform a “reverse migration”, which involves execution of the appropriate migration wizard within ADMT version 2.0 once again. However, the re-execution relies upon the configuration of the wizard to switch the roles of “source” and “target” domains. This design methodology does not recommend this procedure, as the objects moved back again to the source domain will in fact be new objects to the “original” source domain, and hence assigned new SIDs.

♦ The second, recommended, option is to perform an authoritative restore of a sub tree of the DIT in the source domain. The foundation for this option is that it is possible, using a backup, executed just prior to a migration wizard and the “ntdsutil.exe” command line tool (used in the “directory service restore mode” on a domain controller) to authoritatively restore just one OU and the contents of that OU. This option is feasible, as although it theoretically will not require frequent execution, it will generate the desired results.

• The selection of the second option hence relies upon execution of the following contingency plan tasks:

Creation of a temporary “migration OU infrastructure”, in the source domain, to hold just the security principals that require migration within a “user”, “server”, or “logical” partition of the source domain. Then, just prior to the live execution of the appropriate migration wizard, it is necessary to move the security principals that require migration into the migration OU / OU infrastructure. Note that it is very important to make a written note the DN for the migration OU in the source domain, to facilitate execution of the complimentary contingency plan procedure.

Force replication between domain controllers within the domain, and execute a backup of the system state on at least two domain controllers within the domain. A backup to a file on a local hard drive may suffice.

Then, execute the appropriate migration wizard to move the required security principals to the target domain in the same forest.



• Note that the execution of these contingency plan tasks also facilitates post-migration checks to validate the migration of the objects, as the contents of the migration OUs will be empty after a successful migration to the target domain.














This design methodology recommends nomination of a migration team leader or migration board to perform the following activities during execution of the pre-migration and migration tasks for migration paths “E” and “G”:

• Collect the results of all pre-migration and migration tasks executed for migration paths “E” and “G”



When determining the design requirements for the contingency plan procedures to support the second option (use of temporary “migration OU infrastructure”), consider the following:



Upon identification of the requirements to execute a contingency plan procedure to support the second option, this design methodology provides the following example procedure for the resolution of this contingency:

• Reboot the domain controller in the source domain into directory service restore mode, and perform a restore of the system state, and hence the Active Directory database.

• Use the ntdsutil command line interface to perform an authoritative restore of just the migration OU and its contents.

• Reboot the domain controller and force replication with partner domain controllers in the same domain

• Re-execute the contingency plan procedures and the appropriate ADMT version 2.0 migration wizard.


Determine and document the criteria for the execution of the contingency plan procedures, to attend, handle, and resolve contingency, arising during execution of migration paths “E” and “G”

Determine and document the pre-migration, migration, and post-migration tasks in migration paths “E” and “G”, which may generate compliance with the criteria for execution of the contingency plan procedures



Categorisation of these tasks for execution during the pre-migration, migration, and post-migration phases of migration paths “E” and “G”

Determine and document the design requirements for the contingency plan procedures, to attend, handle, and resolve contingency arising during execution of migration paths “E” and “G”


5.9.4. Design for Each Required Migration Path

Consider the following when generating the design for each required migration path:

• Factor D1: Understanding and generating the design for each required migration path

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand and generate the design for each required migration path.


This design methodology requires the generation of a discrete design for each required instance of a migration path, and each required approach (for migration paths “A” and “B”).

Note that the design for the required migration paths must include all pre-migration, migration, and post-migration activities for each path, whether the activity required



design for execution or not. The considerations provided earlier only supported those migration activities that required design for execution.

The next step, “design of the migration checklists”, will provide a few examples of migration tasks associated with each migration path, which do not require design for execution. This design methodology deemed that these migration activities did not require design for execution, as they represent simple activities such as checks, or execution of simple scripts, and so on.

When generating the design for each required migration path / approach for a migration path, this design methodology proposes execution of the following approach:

Generate a high level overview of the scope and objectives of the required migration path / approach for a migration path

Generate a design for all infrastructure components to support execution of the migration path / approach for a migration path. For example, it is necessary to create / provide a migration log (such as an electronic document or handwritten book); a portal to distribute migration information to concerned parties within the organisation, and so on.

Generate a detailed explanation of all pre-migration tasks that require execution on the source and target domain environments for the required migration path / approach for a migration path, including coexistence and contingency tasks, where appropriate

Generate a detailed explanation of all migration tasks that require execution for the required migration path / approach for a migration path, including coexistence and contingency tasks, where appropriate

Generate a detailed explanation of all post-migration tasks that require execution on the source and target domain environments for the required migration path / approach for a migration path, including coexistence and contingency tasks, where appropriate.

Generate the criteria for the identification of success or failure of the execution of each required pre-migration, migration, and post-migration task. For example, the criteria for success of a pre-migration task to execute a migration using ADMT version 2.0 and the User Account Migration Wizard is that the error log for the wizard did not log any significant errors.

Generate a detailed procedure that orders, collates, and links all pre-migration, migration, and post-migration tasks together for seamless and logical execution. For example, such a procedure may also include steps such as:

Execute a pre-migration, migration, or post-migration task

Record results in migration log

Evaluate results against the following:

• The criteria for success or failure of the pre-migration, migration, or post-migration task

• Where it is possible to identify compliance with the success criteria, proceed to the next migration activity.

• Where it is possible to identify compliance with the failure criteria for the task, then evaluate the results against the criteria for execution of the appropriate contingency plan procedure for that task.



• If it is possible to identify compliance with these criteria, then execute the appropriate contingency procedure for that specific step. If it is not possible to identify compliance with the criteria for the execution of any contingency procedures, then proceed to next migration activity, and so on.

Generate a design for the contingency plan to support each required migration path / approach for a migration path

Using the above approach, generate the design for each required migration path.

5.9.5. Design of the Migration Checklists

Consider the following when generating the design for the migration checklists:

• Factor B13: Understanding the objectives, desired format, and content of the migration checklists


Has generated the design for each required migration path / approach for a migration path, and

Wishes to understand the objectives, desired format, and content for the migration checklists


The objectives of the migration checklists are to summarise and list all of the steps necessary to execute each required migration path / approach for a migration path. The actual live execution of the migration paths / approaches requires quick access to simple instructions, and not the requirement to sift through detailed concepts and procedures held within the design for the migration paths for migration activity instructions.

This design methodology requires the generation of one checklist for each required migration path / approach for a migration path.

When attempting to understand the desired format and content of the migration checklists, consider the following:

Although the onus is with the organisation to define the components and form factor of the migration checklists, this design methodology proposes that each migration checklist comprise the following (minimum and example) components:

A section detailing all the pre-migration tasks (and the supporting coexistence, and contingency plan tasks) to prepare the source domain supported by a migration path, and supporting success and failure criteria for each task

A section detailing all the pre-migration tasks (and the supporting coexistence, and contingency plan tasks) to prepare each target domain supported by a migration path, and supporting success and failure criteria for each task

A section detailing all of the migration tasks (and the supporting coexistence, and contingency plan tasks) to execute a migration path / approach for a path, and supporting success and failure criteria for each task

A section detailing all of the post-migration tasks (and the supporting coexistence, and contingency plan tasks) for execution on the source and target domains, and supporting success and failure criteria for each task



References to the appropriate sections in the detailed design for the required migration path, against each migration activity, where there is a requirement for further details on a migration activity.

A simple flow chart to guide the migration administrators required to execute the migration paths

A sign off sheet for use by the migration administrators to verify the correct execution of all migration path activities

• Factor B14: Understanding migration activities, for inclusion in migration checklists, that do not require design for execution for supported migration paths

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the pre-migration, migration, and post-migration activities for supported migration paths that do not require design for execution.


The following migration activities require execution, in the appropriate phase of a migration path, but do not necessarily require design for execution. This implies that it is not necessary to design specific processes to support the execution of the tasks listed in this factor.

It is important to understand that the tasks listed here must supplement the designed migration, contingency, and coexistence tasks for each required migration path. Note that the onus is with the organisation to determine all such tasks that require execution, but not necessarily design for execution, as the tasks listed here are not exclusive.

The tasks listed here are categorised per migration path, and per phase for execution within the migration paths.

The following pre-migration activity requires execution for all migration paths:

Create test user, computer, and group account objects in the source domain. It is then possible to use these security principals to test the success of any migration activities associated with a migration path. Assign these security principals an appropriate name, such as “migration test user” and so on, to prevent their accidental deletion during pre-migration directory clean up tasks.

The following pre-migration activities require execution for migration path “A”:

Prior to execution of the in-place upgrade of a PDC, it is necessary to configure the properties of the TCP/IP protocol stack, on the appropriate NIC(s) in the PDC, to use one or more of the appropriate DNS servers designed to support the Windows Server 2003 Active Directory infrastructure.

Where it is possible to identify that a PDC is running IIS 4.0, then it is necessary to secure this service prior to the upgrade. Use the IIS Lockdown Tool (version 2.1) to secure an IIS 4.0 installation to disable unnecessary features, thus reducing the surface area for attack.

The following post-migration activities require execution for migration path “B”:

Run an offline defragmentation of the ntds.dit on all upgraded Windows Server 2003 domain controllers, 24 hours after completion of the upgrade (for approach 1)



Run an offline defragmentation of the ntds.dit on all upgraded Windows Server 2003 domain controllers, 60 days after completion of the upgrade (to remove all tombstoned objects from the DLT and other directory clean up tasks executed during the pre-migration phase.

Ensure Enterprise Domain Controllers group in upgraded Windows Server 2003 domain has Read access to all pre-upgrade Windows 2000 Active Directory GPOs, via the execution of the following steps:

• Installation of the Group Policy Management Console (GPMC) on a Windows Server 2003 domain controller

• Under the security context of a member of the Domain Admins group, at a command prompt on the Windows Server 2003 domain controller, navigate to the %programfiles%\gpmc\scripts folder, and execute the following command: “Cscript GrantPermissionOnAllGPOs.wsf "Enterprise Domain Controllers" /Permission:Read /Domain:value”, where the value of domain parameter is the DNS name of the domain.

The following pre-migration activities require execution for all migration paths that employ ADMT version 2.0, or equivalent third-party tools:

Modify the logon batch file for source domain users to include a command to synchronise the time on all member computers that require migration. This helps when using the event log while troubleshooting.

Prior to the execution of the Security Translation Wizard on local user profiles, it is important to empty the Recycle Bin on any computer used by a user whose profile will be migrated. Failure to empty the Recycle Bin results in a benign "Recycle Bin corrupted" error.

The following post-migration activity require execution for the intra-forest migration paths “E” and “G”:

After completion of the migration of Domain Local security groups, manually converted to Universal security groups in the source domain (to preserve closed “resource” sets), it is necessary to reconvert these Universal security group objects back to Domain Local groups in the target domain. This is an “immediate” post-migration task, to prevent excessive replication of the members of the temporary Universal group objects to the GC servers in the forest.



6. Design of Migration Schedule and Communications Plan

This process requires execution by all organisations generating a design for a migration plan.


The objectives of the migration schedule are to coordinate the execution of all migration activities, associated with all required migration paths and approaches for paths, against a time-driven schedule.

The objectives of the communications plan are to raise awareness of the migration project to all directly affected users within the organisation, via communication of the plans and objectives of the project.


Within organisations designing complex migration projects, which may directly affect many hundreds or thousands of users, it may be possible to identify the requirements for the design and execution of multiple migration paths, and instances of migration paths.

In this scenario, coordination of all pre-migration, migration, post-migration, contingency, and coexistence activities for each required instance of a migration path is a significant undertaking. The design for the migration schedule is hence required to identify and respect the multitude of dependencies generated between the activities and tasks of each path / instance of path.

The design for the migration schedule will marry the design for each required migration path with the following elements of this project:

• The predefined business and technical migration goals for this project

• The execution of all required migration activities for all required migration paths, and instances of migration paths

• The appropriate elements and aspects of the test, pilot, and production environments for the organisation

Communication is probably the most vital element of any migration project that directly affects the users and any aspect of their computers within the organisation. It is important to note, as strange as it may seem, that the perception by the user population, of the success or failure of a migration project, is more important to most organisations than the technical success or failure of the project. An organisation may hence deem a migration project, with a technically successful execution profile but a poor perception by the user population of disruption and inconvenience, as a failure.

A migration project, via its very nature, introduces changes to the production environment for an organisation. Within most organisations, users resist change, regardless of the scope of the changes.

Perception of the migration project hence requires active management by the migration project team via the design and execution of a communications plan. Active communication of the objectives, goals, and timelines for the migration activities, to directly affected users within the organisation, assists in the reduction of resistance to change and hence increases acceptance of the planned and required changes to the organisation and production environment.


To reflect and support the objectives of this process, this design methodology proposes the following approach for the execution of this process:

1. Execute an analysis to determine the design requirements for the migration schedule



2. Execute an analysis to determine the design requirements for the migration communications plan

3. Generate the design for the migration schedule

4. Generate the design for the migration communications plan


Based upon the above approach, this process is composed of the following four components:

• Determination of the design requirements for the migration schedule

• Determination of the design requirements for the migration communications plan

• Design for the migration schedule

• Design for the migration communications plan



• The determination of the design requirements for the migration schedule

• The determination of the design requirements for the migration communications plan

• Generation of the design for the migration schedule

• Generation of the design for the migration communications plan



Migration Plan – Inter-Component Dependencies for Process to Design Migration Schedule and Communications Plan

STARTDetermination of the

design requirements for the migration schedule

Generation of the design for the migration communications plan


the migration communications plan

Generation of the design for the migration

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

6.7. Process to Design the Migration Schedule and Communications Plan

Migration Plan – Process to Design a Migration Schedule and Communications Plan

STARTExecute

B1

Execute

A1

Execute

B2

Execute

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

ENDExecute

D1 – D2


Consider the following information when executing this process to design the migration schedule and communications plan components for the migration plan.

Presented within the following four sections are the considerations for the components of this process:



1. Considerations for the determination of the design requirements for the migration schedule

2. Considerations for the determination of the design requirements for the migration communications plan

3. Considerations for the generation of the design for the migration schedule

4. Considerations for the generation of the design of the migration communications plan

6.8.1. Determination of the Design Requirements for the Migration Schedule

Consider the following information when determining the design requirements for the migration schedule:

• Factor B1: Understanding the components of the migration schedule

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the components of the migration schedule prior to determination of the appropriate design requirements.


The design for a migration schedule is typically comprised of the following two primary components:

The migration schedule itself, to map migration activities, activity dependencies, resources, project dates, and so on.

A “migration database” to support the management, tracking, and execution of the migration schedule

Although the onus is with the organisation to define the contents of their migration schedules, this design methodology proposes that the design for a migration schedule is required to comprise the following minimum components:

A schedule to coordination the execution of all required migration activities for all required migration paths and instances of paths

The details of the dependencies on execution between each required migration activity

The specific future dates and times for the execution of each required task and process

The schedule for the coordination of all ancillary activities

The issue and risk logs for the migration project

The stability checklists for execution after each phase

The migration database is typically required to provide a centralised repository for all migration schedule components, to support the tracking of pending and completed migration activities.

This design methodology will provide the considerations for the determination of the design requirements for the migration schedule, and the generation of the design for the migration schedule.

Note that this design methodology does not provide the considerations for the determination of the design requirements for the issues and risk logs for the migration



schedule, the stability checklists, and the migration database. The onus is with the organisation to design these components of the migration schedule.

• Factor A1: Determination of the design requirements for the migration schedule

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for the migration schedule.


The migration schedule is essentially a list of migration activities assigned for execution during specific future dates, and assigned to specific resources for execution. However, development of the design for this schedule requires consideration for the following influential factors:

The scope of the migration schedule

The required start and / or end data for the initiation / completion of the migration activities

The number of migration activities that require execution

The requirements to partition the migration activities

The availability and skill levels of resources to execute the migration activities

When determining the design requirements for the migration schedule, this design methodology proposes execution of the following approach:

Determine the scope of the migration schedule

Determine the required end date and / or the required start date for the migration activities

Determine the number of migration activities that require execution, and the dependencies between all required migration activities

Determine the requirements and opportunities to partition the required migration activities to facilitate a phased execution

Determine the requirements for the assignment of resources to the execution of the migration activities

When determining the scope of the migration schedule, consider the following:

Most migration projects for Active Directory support multiple technology and work streams, and rarely are dedicated to just the migration to Active Directory. For example, it may be possible to identify multiple concurrent projects, such as project to perform migration of the following:

Migration of an Exchange 5.5 or Exchange 2000 infrastructure to Exchange Server 2003

Migration of member server operating systems and standard builds from Windows NT 4.0 / Windows 2000 to Windows Server 2003

Migration of applications to operate on a Windows Server 2003 operating system



Migration of client computer operating systems and standard builds from Windows NT 4.0 / Windows 2000 to Windows XP Professional

Some of these concurrent migration project may also have multiple sub-projects, such as:

Migration of an Exchange 5.5 infrastructure to Exchange Server 2003 may also incorporate projects to perform the following migrations:

• Migration of local server storage to a centralised SAN solution

• Migration of archiving, anti-virus, anti-spam software solutions to operate against an Exchange Server 2003 infrastructure

Migration of member server and client computer projects may also incorporate projects to perform the following migrations:

• Migration of applications, and application testing

• Application packaging and distribution

When designing a migration schedule to support the execution of Active Directory-related migration activities, it is hence also necessary to include all of these ancillary projects, and their migration activities, within the scope of the migration schedule.

When determining the start and / or end dates for the migration project, consider the following:

The predefined business and technical migration goals will define the required end and / or start dates for the migration project.

Some organisations prefer to design the migration schedule against a desired end date. This approach permits an organisation to prioritise the requirements for compliance against external influences, such as financial year dates, via the design of the migration schedule.

Some organisations prefer to design the migration schedule against a desired start date. This approach permits an organisation to retain flexibility in completion of the migration activities, without any constraints on compliance with specific end date requirements.

When determining the number of migration activities that require execution, and the dependencies between the activities, consider the following:

The design for the required migration paths will illustrate all of the Active Directory-related migration activities that require execution.

In addition to the Active Directory-related migration activities, it is necessary to accommodate all ancillary project activities, such as the migration activities for parallel projects.

It is important to factor into the design of the schedule the potential requirements for the execution of contingency plan procedures. A carefully planned and tested migration plan should not theoretically require execution of contingency plan procedures. However, due to the number of variables associated with a migration plan, it is not possible to guarantee the prevention of contingencies. This design methodology recommends execution of the following approach to determine the amount of time the migration schedule must accommodate to support the emergency execution of contingency plan procedures:



Identify all contingency plan procedures design to support resolution of any pre-migration, migration, and post-migration activities

Identify the time allocated for the execution of each contingency plan procedure, and collate into a total number of days and hours

Take a percentage of these days and hours as the time required to support the execution of contingency plan procedures. For example, a value between 10 and 25 percent of the total time may be adequate for most organisations and their migration schedules.

The dependencies between the migration activities will represent the most significant influential factors in the design of the migration schedule. The critical paths within and between chains of migration activities, in conjunction with the availability of resources to execute parallel chains, will ultimately dictate the minimum time required to complete all in-scope migration activities.

When determining the requirements and opportunities to partition the required migration activities to facilitate a phased execution, consider the following:

The dependencies identified between the migration activities will generate raw phases or partitions within the migration schedule.

Where an organisation identifies the requirement for the design and execution of any of the inter-forest or intra-forest migration paths, it is possible to refine these raw phases in the migration schedule using the design for these migration paths. These migration paths partitioned a source domain into “user”, “server”, and “logical” partitions. The “user” partitions may reflect the divisional structures within an organisation, and hence the basis for partitioning all migration activities within the migration schedule.

It may be necessary to partition a migration schedule to reflect resource availability and skill levels. The lack of available and skilled resources to execute migration activities may hence restrict the number of migration tasks executable each working day.

When determining the requirements for the assignment of resources to the required migration activities, consider the following:

The execution of certain migration activities may require significant levels of skill and experience, to ensure the successful first-time execution of the activity. Some migration activities demand less skilled and experienced resources to, for example, prepare servers for migration, or provide “floor-walking” support for post-migration phases, and so on.

When determining the requirements for assignment of resources to required migration activities, this design methodology proposes the following approach:

Define categories for the resources required to execute the migration activities, to reflect their levels of skill, experience, seniority, and so on.

Assign each required migration activities to one of these identified categories

Determine the number of resources required to execute each migration activity

Determine the availability profiles for the resources (for example, on annual leave, geographical location within the organisation, and so on)

Use this information to assign migration activities to the appropriate resources



6.8.2. Determination of the Design Requirements for the Migration Communications Plan

Consider the following when determining the design requirements for the migration communications plan:

• Factor B2: Understanding the components of the migration communications plan

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the components of the migration communications plan.


The design for a migration communications plan is typically comprised of the following primary components:

The scope of the communications plan and input in its development and execution

The categories of target users for the communications

The contents of the communications, tailored for each category of target user

The schedule for the generation and distribution of the communications to the target users

The vehicles for the distribution of the communications to the target users

This design methodology provides considerations for the determination of the design requirements for all of the above components of a migration communications plan.

• Factor A2: Determination of the design requirements for the migration communications plan

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the design of the migration communications plan.


When determining the scope of the communications plan, and the required input into its development and execution, consider the following:

The scope of the migration communications plan defines the following:

The types of communications the plan is required to generate and distribute. The communications plan may not be restricted to just generation of informational communications to end users, but also to members of the migration teams, members of the IT administrators, communications to external consultants and distributors, and so on.

The users within the organisation targeted to receive the communications. Within most organisations, the migration activities for the migration project do not necessarily affect all users and computers, either directly or indirectly. For example, the scope of the migration may be restricted to the logical boundaries of an autonomous division within a parent organisation, and hence users within the parent organisation, or sister divisions, are not affected.

The nature and function of the communications plan, to raise awareness of the migration project, and generate acceptance of change, it more a public relations



activity than a migration activity. Within some organisations, the IT department may hence enlist the assistance of other internal departments and users, or even external consultancies, to develop the contents of the communications plan, and assist in the design for its execution. For example, it may be possible to solicit assistance from the marketing department, to provide ideas on the required vehicles for distribution of communications to target users. The marketing department may also have the ability to solicit marketing funds to assist in the development and execution of the communications plan. Some organisations even have a dedicated internal communications department, with funding to assist such migration communication plans.

The Human Resources department for an organisation may provide assistance in the development of the communications plan, via the identification of the following:

The ideal categories for target users

The appropriate technical levels for the content of the communications for each category of target users, and so on

When determining the design requirements for the required categories of target users, consider the following:

For the majority of organisations, a “one-size-fits-all” approach is not feasible for a communications plan. Different roles for target users within the organisation may demand, for example:

Differing levels of information contained within the communications

Different schedules for the reception of communications

Different mediums for distribution of the information

This design methodology proposes consideration of the following examples as categories of target users for communications:

Migration team members

IT department members

Directors and executives

Department heads

Team leaders

End users

When determining the design requirements for the contents of the communications, generated and distributed by the communications plan, consider the following:

The contents of each communication must reflect the required categories of target users. For example, end users will only require high-level information about proposed migration activities, and not detailed information more suitable for distribution to the migration team members. Directors, executives, and stakeholders in the migration project will be more interested in status reports and updates than end user tasks and responsibilities, and so on.

As stated earlier, it may be possible to enlist assistance from the HR department on the required contents of the communications.



The communications should include, for example, pointers or references to further detailed information or specific people associated with the migration project who can provide information and address concerns, and so on.

When determining the design requirements for the required schedule for the generation and distribution of the communications, consider the following:

It is necessary to generate and distribute new communications to the target users on a frequent basis. The frequency of generation and distribution of the communications should increase as the project moves closer to the execution of the first set of migration activities, and maintained at a high frequency from that stage until completion of all migration activities. The scope of the communications will naturally decrease as the completion of migration activities for users and departments will permit their gradual exclusion from the scope of the communications plan.

It is important to execute the communications plan as early as possible in the migration project. Some organisations prefer to distribute the first communications up to two or three months in advance of the proposed dates for the first migration activities. The sooner the communications are distributed, the higher the probability for acceptance by the user population for change associated with the migration activities.

When determining the design requirements for the vehicles to distribute the required communications, consider the following:

This design methodology proposes that selection of the appropriate vehicles for distribution of the required communications comply with the following example criteria:

The vehicle(s) used will reach all of the targeted users within each required category

The vehicle(s) used must be cost effective and simple to generate

The vehicle(s) used must effectively communicate all required information within a few seconds of notice by the targeted users

Enlist assistance from any internal marketing department users for ideas on the most effective vehicles. The use of a combination of vehicles will generate the most successful results, and not the strict reliance on the use of only one or two vehicles.

Consider the use of “themes” for the communications, to generate interest and amusement. Dull and sombre communications typically receive little notice by targeted users. Interesting and amusing communications generate conversations between end users and hence raise general awareness. The HR department can provide guidance on the culture of the organisation, and acceptable themes.

This design methodology proposes consideration of the following examples of vehicles for the generation and distribution of the required information:

This design methodology recommends the use of a combination of electronic and non-electronic vehicles for distribution of the required communications.

Non-electronic vehicles:

• Strategically distributed (around facilities such as drinks and vending machines, and photocopiers, and so on) A1 or A0 sized posters are very effective vehicles for communications. They have the following compliance profile with the criteria for selection of vehicles:



♦ Their large size will gain the attention of the majority of users in a department

♦ They are cost effective to produce and simple to design and generate

♦ They effectively support the communication of all required information visually in one simple medium

• Strategically distributed leaflets

• Free mugs, pens, and so on, with references to intranet web sites or e-mail addresses for further information.

Electronic vehicles;

• Most organisations employ e-mails due to their ease of generation, controlled distribution, and relative effectiveness. However, “internal SPAM” is becoming a more commonplace occurrence within organisations, with users automatically filtering out all “internal” e-mails from the organisation or departments within the organisation. Hence, consider the use of a dedicated e-mail account for the generation of such e-mail communications. This design methodology recommends the use of e-mails only in conjunction with at least two other non-electronic forms of communication, and one other electronic form of communication.

• Most organisations actively encourage users to use intranet web sites or web portals. These provide an ideal vehicle for communication.

• Specialist vehicles for specific categories of users may include Simple Message Service (SMS) messages to mobile phones or use of pager messages. For example, to distribute urgent communications to migration team members, status updates, and so on.

6.8.3. Design for the Migration Schedule

Consider the following when generating the design for the migration schedule:

• Factor D1: Generation of the design for the migration schedule


Has determined all of their design requirements for the migration schedule, and

Wishes to generate the design for the migration schedule


Although the onus is with the organisation to design their migration schedule and database, this design methodology proposes that the design for the migration schedule take the following (example) form factors:

A detailed project plan illustrating the following:

The migration activities that require execution

The dates and times for the execution of the required migration activities

The dependencies and relationships between the required migration activities



The resources assigned to each required migration activity

A design document detailing the design for the migration schedule, as a reflection of the design requirements identified earlier

A “migration pack” for each migration resource responsible for the execution of migration activities, which contains, for example, the following information:

A summary of the migration tasks assigned to them

A list of references to electronic documents detailing the required procedures to execute the migration activities

A schedule for execution of their assigned migration activities, and the dependencies upon, and generated by, their assigned migration activities

Using the above information, generate the design for the migration schedule.

6.8.4. Design for the Migration Communications Plan

Consider the following when generating the design for the migration communications plan:

• Factor D2: Generation of the design for the migration communications plan


Has determined all of their design requirements for the migration communications plan, and

Wishes to generate the design for the migration communications plan


Although the onus is with the organisation to design their own migration communications plan, this design methodology proposes that the design for the migration communications plan take the following (example) form factors:

A design document detailing the following:

The design for the scope of the communications plan and input in its development and execution

The design for the categories of target users for the communications

The design for the contents of each required communication, tailored for each category of target user

The design for the schedule for the generation and distribution of each required communication to the target users

The design for the vehicles for the distribution of the communications to the target users

The required vehicles for the distribution of the generated communications

The design for a supporting infrastructure for reception of queries about the migration project, such as a dedicated e-mail account, an e-mail distribution list, and a dedicated e-mail enabled public folder, and so on.



Using the above information, generate the design for the migration communications plan.


Migration to AD 2003

Documents

Transcript of Migration to AD 2003