P. 1
Migration to AD 2003

Migration to AD 2003

|Views: 129|Likes:
Published by saurabhsareen

More info:

Published by: saurabhsareen on Oct 28, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

09/04/2010

pdf

text

original

© 2004 Mustan Bharmal. All Rights Reserved.

Table of Contents
1. 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

Page 1 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 2 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 inscope 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

Page 3 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

2. 1.3.1.

Understanding the migration plan concepts and terminology

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.

Page 4 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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-ofconcept 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. 2. 3. 4. 5. 1.4. 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 A coexistence plan to support coexistence during the migration phase A contingency plan to support the rollback of a failed migration A migration schedule to co-ordinate the execution of all identified migration paths during the migration phase A migration communications plan to support the distribution of information about the migration project to appropriate users within the organisation.

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

Page 5 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. 3. 4. 5. 6. 7. 1.5. Understand all of the migration paths supported by this design methodology Determine the required strategy for the migration of each legacy domain infrastructure to the new Windows Server 2003 Active Directory infrastructure 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. Select a migration path for each in-scope legacy domain infrastructure, that complies with the migration strategy and goals Determine the design requirements for each required migration path, and generate the appropriate design Determine the design requirements for the migration schedule and communications plan, and generate the appropriate design

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

Page 6 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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
Analysis of legacy domain infrastructure(s) Determination of required migration strategy, goals, and path(s) Design of required migration path(s)

START
Understanding supported migration paths

Design of migration schedule & communications plan
© 2004 MUSTANSHI
R

BHAR

MAL

The following diagram illustrates how each of these five processes within the migration plan depends and builds upon the results of the previous process:
DESIGN OF MIGRATION SCHEDULE & COMMUNICATIONS PLAN DESIGN OF REQUIRED MIGRATION PATH(S) DETERMINATION OF MIGRATION STRATEGY UNDERSTANDING SUPPORTED MIGRATION PATHS ANALYSIS OF LEGACY DOMAIN INFRASTRUCTURES
© 2004 MUSTANSHI
R

BH AR

MAL

Figure 40.1: Migration Plan Process Dependencies

Page 7 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. 1.8.

Process to Create the Migration Plan
Migration Plan – Process to Create the Migration Plan

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

END

Execute process “design of migration schedule & communications plan”

Execute process “design of required migration path(s)”
© 2004 MUSTANSHI
R

BHAR

MAL

Page 8 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

2.3.

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

2.

Page 9 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. j. 2.5. The details of the current security policies and operations for each in-scope domain The details of any formal and / or informal directory service change control infrastructures for each in-scope domain

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:

Page 10 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 inscope domain infrastructure
© 2 0 0 4 MU ST AN SH I
R

BHARMAL

2.8.

Process to Analyse Legacy Domain Infrastructure(s)
Migration Plan – Process to Analyse Legacy Domain Infrastructure(s)
Does the organisation know exactly which legacy infrastructures require migration?

START

YES

Execute B1

Execute A3

Execute B2

Execute A4 – A13

END
© 2004 MUSTANSHI
R

BHAR

MAL

YES

Execute A1 – A2

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. 2. 3. Considerations for the identification of existing legacy domain infrastructures that require migration Considerations for the determination of the scope of the migration plan 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:

Page 11 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ 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 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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an 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:

Page 12 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 13 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 14 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 NT4 BDC NT4 PDC INSIDE OF MIGRATION SCOPE OUTSIDE of MIGRATION SCOPE

Windows NT 4.0 Domain

W2K DC

W2K3 DC

W2K3 DC

W2K DC

W2K DC

Windows 2000 Domain NT4 BDC

Windows Server 2003 Domain NT4 PDC

Windows Server 2003 Domain

Windows 2000 Domain Windows NT 4.0 Domain

© 2004 MUSTANSHI

R

BHAR

MAL

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

Page 15 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 16 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 17 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 18 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 19 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 Using the above information and approach, execute the following:  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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 20 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 21 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 22 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 23 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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) Using the above information and approach, execute the following:  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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 primary directory service query profiles for each in-scope legacy domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: “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.

Page 24 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 configuration details for each domain controller within each in-scope legacy domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 25 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 26 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 directory objects within each in-scope legacy domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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:
Found in Windows NT 4.0 domains     Found in Windows 2000 domains  1  

Directory Objects

User account objects InetOrgPerson account objects Computer account objects Security Group objects

Page 27 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

Directory Objects

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

Following 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 28 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 object and resource management infrastructures within each in-scope legacy domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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)

Page 29 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 any current disaster recovery infrastructure for each in-scope legacy domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 30 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 backup and restore infrastructure for each in-scope legacy domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 31 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 security policies and operations for each in-scope legacy domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 32 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 any existing formal and / or informal change control infrastructures for each in-scope legacy domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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:

Page 33 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 34 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

3.1.

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

3.2.

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

Page 35 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. 3.3.

Process Components 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
Execute B1 – B13

END
© 2004 MUSTANSHI
R

BHAR

MAL

3.5.

Process Considerations 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. 2. 3. Supported migration paths Understanding the features of each supported migration path 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 36 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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 postmigration 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:

Page 37 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 38 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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”

Page 39 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 40 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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 ♦ Deployment of all remaining aspects and components of the new Windows Server 2003 Active Directory infrastructure for the organisation  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: ♦ Addition of new 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  Inter-Forest Domain Consolidation: “Path D”

Page 41 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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: ♦ Addition of new 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  “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

Page 42 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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: ♦ Addition of new 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, 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: ♦ Addition of new 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, where applicable  Intra-Forest Domain Consolidation: “Path G”

Page 43 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 44 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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 IN-PLACE UPGRADE Path A B Category SIMPLE SIMPLE Source Domain Windows NT 4.0 Windows 2000 Target Domain Windows Server 2003 Windows Server 2003

Page 45 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

C D DOMAIN CLONING / MIGRATION E F G H

SIMPLE SIMPLE OPTIONAL OPTIONAL OPTIONAL OPTIONAL

Windows NT 4.0 Windows 2000 Windows Server 2003 Windows Server 2003 Windows 2000 Windows 2000

Windows Server 2003 Windows Server 2003 Windows Server 2003 Windows Server 2003 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
Migration Domain Upgrade

C L K E F G M H I
= “Extended” Migration Path

B I

J

D

Migration Domain Consolidation

A H

= “Simple” Migration Path = “Optional” Migration Path

Pre or Post Migration Domain Consolidation

© 2004 MUSTANSHI

R

BHAR

MAL

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

Page 46 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 It is simpler to migrate directly from multiple legacy Windows 2000 domains to one or more Windows Server 2003 domains without prior consolidation or inplace 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 inplace 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.

Page 47 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

Migration Plan – “Simple” and “Optional” Migration Paths to Windows Server 2003 Active Directory Supported by this Design Methodology
EXISTING FOREST EXISTING FOREST PRE “ACTUAL” MIGRATION DOMAIN CONSOLIDATION

LEGEND:
“NT4" = Windows NT 4.0 “W2K3" = Windows Server 2003 “W2K" = Windows 2000 “DC" = Domain Controller W2K DC W2K DC W2K DC W2K DC

A

= “Simple” Migration Path

H

= “Optional” Migration Path

Windows 2000 Domain

Windows 2000 Domain

H A
NT4 BDC NT4 PDC New W2K3 DC Windows NT 4.0 Domain
Windows Server 2003 CD-ROM

G
“adprep” prepared domain and forest

B B

“ACTUAL” MIGRATION FROM LEGACY TO NEW

W2K DC

W2K DC

Windows 2000 Domain

A

C

D

B

NT4 BDC W2K3 DC

W2K3 DC

W2K3 DC

W2K3 DC

W2K DC

Windows Server 2003 Domain NEW or EXISTING FOREST

Windows Server 2003 Domain NEW or EXISTING FOREST

Windows Server 2003 Domain

Windows Server 2003 Domain NEW or EXISTING FOREST

F E

NEW or EXISTING FOREST

E F

POST “ACTUAL” MIGRATION DOMAIN CONSOLIDATION

E
NT4 BDC W2K3 DC

F
W2K3 DC

E
W2K3 DC W2K3 DC

W2K3 DC

Windows Server 2003 Domain

Windows Server 2003 Domain

Windows Server 2003 Domain

Windows Server 2003 Domain
© 2004 MUSTANSHI
R

BHAR

MAL

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)

Page 48 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 49 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 50 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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”)  Approach 2 has the following prerequisites:

Page 51 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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.  Approach 3 has the following prerequisites:  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)  Approach 3 is associated with the following advantages:  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.

Page 52 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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.  Approach 3 is associated with the following disadvantages:  It may be possible to identify requirements for the execution of extensive premigration tasks, such as directory clean up tasks  It may be possible to identify requirements for the execution of extensive postmigration 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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 53 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 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  Approach 1 is associated with the following advantages:  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.  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 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:

Page 54 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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.  Approach 2 has the following prerequisites:  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.  Approach 2 is associated with the following advantages:  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.  Approach 2 is associated with the following disadvantages:  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 Directoryenabled, 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)

Page 55 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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:

Page 56 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The following represent the strict prerequisites for the selection of path “D”:  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 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 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 “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.

Page 57 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 58 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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”):

Page 59 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 60 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 61 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

Page 62 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The strict prerequisites for the selection of path “K” are:  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

Page 63 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 64 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 “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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 65 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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)  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.  To support execution of path “E” or “F” after path “C”, 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 “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”):

Page 66 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 “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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The strict prerequisites for the selection of path “M” are:  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  To support execution of path “D” (before “E” or “F”), there is a requirement for compliance with the following criteria:

Page 67 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 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.  To support execution of path “E” or “F” after path “D”, 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 “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.

Page 68 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 69 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 Windows NT 4.0 Server (SP5 or SP6a) Windows NT 4.0 Enterprise Edition (SP5 or SP6a) Windows NT 4.0 Terminal Server Edition (SP5 or SP6a) Windows 2000 Server Windows 2000 Advanced Server Supported version(s) of Windows Server 2003 operating system for in-place upgrade Windows Server 2003 Standard or Enterprise Edition Windows Server 2003 Enterprise Edition Windows Server 2003 Standard or Enterprise Edition Windows Server 2003 Standard or Enterprise Edition 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).

Page 70 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

4.1.

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

4.3.

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

Page 71 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 72 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 73 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 74 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ The many-to-many mapping of two or more legacy domains to two or more target Windows Server 2003 domains 4.4. Process Approach 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.

Page 75 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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:
First Null Hypothesis In-place upgrade (paths “A” and / or “B”) Second Null Hypothesis Domain cloning (paths “C” and / or “D”) Select an extended migration path for design and execution, for one or more legacy domains “Default Migration Path” YES It is possible to disprove the second null hypothesis?

“Default Migration Path”

YES It is possible to disprove the first null hypothesis?

Legacy Windows NT 4.0 and / or Windows 2000 domain For one or more legacy Windows NT 4.0 / Windows 2000 domains

Legacy Windows NT 4.0 and / or Windows 2000 domain For one or more legacy Windows NT 4.0 / Windows 2000 domains

NO Use “in-place upgrade” approach

NO Use “simple domain cloning” approach
© 2004 MUSTANSHI
R

BHAR

MAL

Page 76 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 Determine the business and technical migration goals for this project Analyse the results of the design gap analysis and evaluate against the defined migration goals to identify all migration issues 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 Determine the domain creation dependencies

2. 3. 4. 5.

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:

Page 77 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

PROCESS

DESIGN OF MIGRATION COMMUNICATIONS PLAN DESIGN OF MIGRATION SCHEDULE DESIGN OF REQUIRED MIGRATION PATH(S) IDENTIFICATION OF DOMAIN CREATION DEPENDENCIES DETERMINATION OF REQUIRED MIGRATION APPROACH IDENTIFICATION OF MIGRATION ISSUES DETERMINATION OF MIGRATION GOALS EXECUTION OF DESIGN GAP ANALYSIS DETERMINATION OF MIGRATION STRATEGY

PROCESS COMPONENTS

Current design of legacy Windows NT 4.0 domain infrastructure(s)

Current design of legacy Windows 2000 Active Directory infrastructure(s)
© 2004 MU ST AN
SHI R

ANALYSIS OF LEGACY DOMAIN INFRASTRUCTURES
BHAR
MAL

Figure 43.2: Illustration of Dependencies between Components of Migration Plan 4.5. Process Components 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 4.6. Deliverables of Process Components This process will have the following deliverables: • 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

Page 78 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. 4.7.

Inter-Component Dependencies Each component within this process will have the following inter-component dependencies:
Migration Plan – Inter-Component Dependencies for Determination of Required Migration Strategy START
Execution of Design Gap Analysis Determination of Migration Goals Identification of Migration Issues

Determination of Domain Creation Dependencies

Determination of Required Migration Approach
© 2 0 0 4 MU S TAN SH I
R

BHAR

MAL

4.8.

Process to Determine the Required Migration Strategy
Migration Plan – Process to Determine the Required Migration Strategy
Does the organisation have one or more legacy Windows NT 4.0 domains? Does the organisation have one or more legacy Windows 2000 domains?

START

Execute B1

Execute A1

NO

NO

Execute A4

YES

Execute A2

YES

Execute A3

Execute B2

END

Execute A11

Execute B5

Execute A10

Execute B4

Execute A9

Execute B3

Execute A5 – A8
© 2004 MUSTANSHI
R

BH

AR MAL

4.9.

Process Considerations 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. 2. 3. 4. 5. Considerations for the execution of the design gap analysis Considerations for the determination of the migration goals for this migration project Considerations for the identification of migration issues in legacy domains Considerations for the determination of the required migration approach 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.

Page 79 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 80 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 81 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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) ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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) ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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: • CPU numbers, type, and specifications • RAM amount, type, and specifications • HDD numbers, type, capacities, free disk space, and specifications • NIC numbers, type, 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:

Page 82 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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) ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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) ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 83 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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: • CPU numbers, type, and specifications • RAM amount, type, and specifications • HDD numbers, type, capacities, free disk space, and specifications • NIC numbers, type, 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 84 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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)

Page 85 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 inscope 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

Page 86 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 premigration 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.

Page 87 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 One forest One domain Eight 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) 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 Design of aspect in Windows NT 4.0 domain infrastructure N/A Two domains Fourteen domain controllers Four domain controllers in HQ and ten domain controllers in ten remote office locations (locations 1 through to ten) Is domain aspect similar? N/A Design of aspect in Windows 2000 Active Directory infrastructure Two forests Three domains Six domain controllers Is domain aspect similar? Summary

Number of forests Number of domains Total number of domain controllers Geographic distribution of domain controllers

   

There is a requirement to decommission one forest There is a requirement to decommission four extra domains There is a potential* requirement to decommission twelve extra domain controllers. There is a requirement to decommission two extra domain controllers in HQ, and one extra domain controller in locations 2, 4, 6, and 8.

  

Two domain controllers in HQ and one domain controller in four remote office locations (locations 2, 4, 6, and 8)

Hardware specifications for domain controllers

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) All current WAN links that support replication between Windows 2000 domain controllers have a minimum of 512Kbps available bandwidth during a typical working week

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

Page 88 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 89 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 90 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 91 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 92 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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. Using the above information and approach, execute the following:  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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 93 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 94 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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. Using the above information, execute the following:  Determine and document the business and technical goals that will influence the design of the migration schedule for this project  Define and document the criteria for compliance with each defined business and technical migration goal • 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.

Page 95 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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 Using the above information, execute the following:  Determine and document the business and technical goals that will influence the design of the migration communications plan for this project  Define and document the criteria for compliance with each defined business and technical migration goal 4.9.3. Identification of Migration Issues Consider the following when identifying any issues associated with the migration of the inscope 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 96 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 97 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 98 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 99 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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:

Page 100 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 101 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 102 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 103 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 (legacyto-new) One-to-one (as entire domains and contents) One-to-many Many-to-one Many-to-many Migration Paths That Support Domain Mapping Categories A B C D E F G H

 2 2 2

 2 2 2

1   

1   

1   

1   

1 3  

1 3  

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

Page 104 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

Page 105 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 106 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 107 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the required migration approach for each in-scope legacy domain, and  Wishes to understand the concept of domain creation dependencies ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 108 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation: ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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:

Page 109 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 110 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

Page 111 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

5.1.

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

5.3.

Background Information 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. The concepts of closed and open sets for intra-forest migration paths The concepts behind the project and migration terms employed within this process

2. 3. 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:

Page 112 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

MIGRATION

CONTINGENCY

COEXISTENCE
© 2004 MUSTANSH
I R

BHAR

MAL

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

Page 113 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 User account objects

© 2004 MUSTANSHI

R

BHAR

MAL

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

Page 114 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 115 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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
Simple closed “resource” set

Domain Local groups Local security groups RW R 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 RWD
© 2004 MUSTANSHI
R

FC

Permissions assigned to local security groups on file share resources
BHAR
MAL

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

Page 116 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

Page 117 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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.

MIGRATION PHASE
PRE-MIGRATION MIGRATION POST-MIGRATION

COEXISTENCE PHASE
© 2 0 0 4 MU S TA NSH I
R

BHARMAL

POC

PILOT

DEPLOYMENT

Figure 44.4: Relationships between Migration and Project Phases 5.4. Process Approach To reflect and support the objectives of this process, this design methodology proposes the following approach for the execution of this process: 1. 2. 3. 4. 5. Execute an analysis to determine the design requirements for each required migration path Execute an analysis to determine the design requirements for the coexistence plan Execute an analysis to determine the design requirements for the contingency plan Generate the design for each required migration path Generate the design for the migration checklists summarising all migration, coexistence, and contingency tasks that require execution for each required migration path

Page 118 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. 5.5.

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

5.6.

Deliverables of Process Components This process will have the following deliverables: • 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

5.7.

Inter-Component Dependencies 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 START
Determination 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

Determination of the design requirements for the contingency plan
© 2004 MUSTANSHI
R

BHARMAL

Page 119 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. 5.8.

Processes to Design the Required Migration Path(s)
Migration Plan – Process to Design Required Migration Paths

START

Execute B1 – B5

Execute A1 – A6

Execute B6 – B7

Select a migration path and execute appropriate factors

PATH

PATH

PATH

PATH

PATH

PATH

PATH

PATH

A
Execute A7 Execute A18 Execute A25 Execute B9 Execute A31 Execute B10 Execute B11 Execute A36 – A37 Execute B12 Execute A39

B
Execute A8 – A17 Execute A19 Execute B9 Execute B10 Execute B11 Execute A38 Execute B12 Execute A40

C
Execute A20 Execute A22 Execute B8 Execute A26 – A28 Execute A30 Execute B9 Execute A32 Execute B10 Execute A34 Execute B11 Execute A37 Execute B12 Execute A41 Execute D1

D
Execute A20 Execute A23 Execute B8 Execute A26 – A28 Execute A30 Execute B9 Execute A32 Execute B10 Execute A34 Execute B11

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

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

G
Execute A21 Execute A23 Execute B8 Execute A26 – A27 Execute A29 Execute B9 Execute A33 Execute B10 Execute A35 Execute B11 Execute B12 Execute A42

H
Execute A20 Execute A23 Execute B8 Execute A26 – A27 Execute A29 Execute B9 Execute A32 Execute B10 Execute A34 Execute B11 Execute B12 Execute A41

Execute B13 – B14

Executed all factors for all required migration paths?

NO YES

END

© 2 0 0 4 MU S T AN

SHI R

BHARMAL

Page 120 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. 5.9.

Process Considerations 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. 2. 3. 4. 5. Considerations for the determination of the design requirements for each required migration plan Considerations for the determination of the design requirements for the coexistence plan Considerations for the determination of the design requirements for the contingency plan Considerations for the generation of the design for each required migration path 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. 2. 3. 4. Understanding the components of a design for a migration path Determination of the requirements for the design of pre-migration tasks to support each required migration path Determination of the requirements for the design of migration tasks to support each required migration path Determination of the requirements for the design of post-migration tasks to support each required migration path 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

5.9.1.1.

Page 121 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 postmigration 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:
First Three (Analysis) Sections of Process “Design of the Required Migration Path(s)” From Process “Determination of Required Migration Strategy” Determination of the design requirements for the migration path Determination of the design requirements for each required migration path Determination of the design requirements for the migration path Determination of the design requirements for the coexistence plan Determination of the design requirements for the contingency plan

Determination of the design requirements for the coexistence plan

Determination of the design requirements for 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

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
© 2004 MU ST AN SH I
R

BHAR

MAL

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 premigration tasks to support each required migration path.

Page 122 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

Presented within the following four sections are the considerations for the execution of this step within this process: 1. 2. 3. 4. 5.9.1.2.1. Understanding the pre-migration tasks that require determination and design Determination of the design requirements for common pre-migration tasks to prepare a source domain for migration Determination of the design requirements for specific pre-migration tasks to prepare a source domain for migration Determination of the design requirements for specific pre-migration tasks to prepare a target domain for migration 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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 premigration tasks for each required simple and optional migration path:

Page 123 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 premigration, 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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:

Page 124 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 125 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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”:

Page 126 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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 Objects User account objects InetOrgPerson account objects Computer account objects Found in Windows NT 4.0 domains    Found in Windows 2000 domains  1 

Page 127 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

Potentially Redundant Directory Objects Security Group objects Distribution Group objects

Found in Windows NT 4.0 domains  

Found in Windows 2000 domains  

Table 44.1: Types of Potentially Redundant Directory Objects Found in Windows NT 4.0 and Windows 2000 Domains
1

Following 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 128 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 129 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. Using the above information and approach, execute the following:  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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 130 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 131 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 • The assignment of rights to perform specific functions within the domain infrastructure

Page 132 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 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:

Page 133 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 134 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

Page 135 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 136 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 137 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 Using the above information and approach, execute the following:  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

Page 138 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.  The objectives for the proposed approach are to:  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

Page 139 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 140 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 "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 • 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 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 • The assignment of rights to perform specific functions within the domain infrastructure • The assignment of GPOs (in a legacy Windows 2000 domain)  It is only authorised by the administrators of the issuing domain for use by a single assignee member server.

Page 141 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 142 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 143 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 144 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 145 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 Using the above information and approach, execute the following:  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

Page 146 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 147 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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.  The objectives for the proposed approach are to:  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 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 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

Page 148 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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:  "Actually redundant"  "Potentially redundant"  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:

Page 149 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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.

Page 150 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 151 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 152 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 153 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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

Page 154 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 155 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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:

Page 156 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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

Page 157 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 (nonspecific) 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

Page 158 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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:

Page 159 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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.  The execution of option 2 requires the following approach: • 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:

Page 160 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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:

Page 161 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 Using the above information and approach, execute the following:  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

Page 162 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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 emails 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.

Page 163 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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.  The objectives for the proposed approach are to:  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 assurance that the identified redundancy status (as “actually” or “potentially”) of the directory objects and data will either:

Page 164 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 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:  "Actually redundant"  "Potentially redundant"  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:

Page 165 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 166 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 167 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 168 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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.

Page 169 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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.

Page 170 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 171 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

Page 172 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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:  The execution of option 1 requires the following approach: • 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

Page 173 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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  The execution of option 2 requires the following approach: • 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.

Page 174 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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)

Page 175 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 Using the above information and approach, execute the following:  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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 176 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 177 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 178 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 179 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 180 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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:

Page 181 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 182 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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

Page 183 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 184 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 185 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 posttermination 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. Using the above information and approach, execute the following:  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

Page 186 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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”

Page 187 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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” (inplace upgrade of a legacy Windows 2000 domain):
Potentially Redundant Directory Objects Print queue objects Shared folder objects Contact objects Organizational Unit (OU) objects ForeignSecurityPrincipal objects (in the “CN=ForeignSecurityPrincipals,DC=<domain_name>” container) Found in Windows NT 4.0      Found in Windows 2000     

Page 188 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

Potentially Redundant Directory Objects 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

Found in Windows NT 4.0 

Found in Windows 2000 

 

 

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 postmigration phase. The step “determination of the design requirements for postmigration 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):

Page 189 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

Potentially Redundant Directory Data Windows NT 4.0 system policies Security Audit policies Security principal rights assignments User account password & account lockout policies External trust relationships Application data from Active Directory aware applications (for example, Active Directory integrated DNS zone data)

Found in Windows NT 4.0      

Found in Windows 2000  2 2 3  

Table 44.3: Directory Data within the Scope of Directory Clean Up Tasks for Migration Paths “A” and “B”
2

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

It 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 190 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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:  External trust relationships  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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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” ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 191 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 192 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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:  The acceptability (by the organisation) of the consequences that may arise from their deletion, and  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:  "Actually redundant"  "Potentially redundant"  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)

Page 193 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 194 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Print Queue

Print Queue

Print Queue Object Natsum. com.

Print Device

Client

Print Server

© 2004 MUSTANSHI

R

BHAR

MAL

Document to print

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

Page 195 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 196 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 197 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 Using the above information and approach, execute the following:  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.

Page 198 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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” ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 199 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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.  The objectives of this process are to:  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:  The acceptability (by the organisation) of the consequences that may arise from their deletion, and  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

Page 200 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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:  "Actually redundant"  "Potentially redundant"  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:

Page 201 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

Shared Folder

File Server

Shared Folder Object
Shared Folder

Client Natsum. com.
© 2004 MUSTANSHI
R

BHARMAL

Access Shared Folder

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

Page 202 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 203 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 Using the above information and approach, execute the following:  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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 204 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 premigration 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.  The objectives of this process are to:  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:  The acceptability (by the organisation) of the consequences that may arise from their deletion, and  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.

Page 205 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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:  "Actually redundant"  "Potentially redundant"  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:

Page 206 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

Foreign User

Contact Object

Natsum. com. External E-mail
© 2 0 0 4 MU ST AN
SHI R

User

BHAR

MAL

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

Page 207 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

Using the above information and approach, execute the following:  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 premigration 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 208 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 premigration 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  The objectives of this process are to:  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:  The acceptability (by the organisation) of the consequences that may arise from their deletion, and  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:

Page 209 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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:  "Actually redundant"  "Potentially redundant"  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:

Page 210 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 211 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 Using the above information and approach, execute the following:  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 premigration 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 212 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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:

Page 213 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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 vendorspecific container, as a child of the System container, to store configuration information for Active Directory-integrated applications.

Page 214 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 215 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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:

Page 216 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 217 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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”:

Page 218 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 219 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 220 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 221 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 222 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 directory data that requires inclusion within the scope of pre-migration directory clean up tasks for migration path “B”. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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:  External trust relationships  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)

Page 223 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 “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 postmigration 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:

Page 224 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 Directoryintegrated 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 emails, 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.

Page 225 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • Determine the details of the potential impact associated with the termination or upgrade and migration of each identified application / service as a premigration, 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 premigration 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-213703486802-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

Page 226 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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:  External trust relationships  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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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” ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 227 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 228 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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\Parame ters”, 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.

Page 229 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 230 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 inplace 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,

Page 231 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

Page 232 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 premigration 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 design requirements for pre-migration tasks to prepare a source Windows 2000 domain for the execution of migration path “B” ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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. 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.

Page 233 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 234 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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

Page 235 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

(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

Page 236 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 237 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 238 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

“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

Page 239 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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:

Page 240 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 241 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 242 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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.

Page 243 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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”)

Page 244 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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 interforest 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 intraforest 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:

Page 245 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 246 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 247 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 248 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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” ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 249 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 250 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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” ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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.

Page 251 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

The objective of this step is to determine all of the design requirements for the premigration 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. 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 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.

Page 252 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 253 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 254 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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

Page 255 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 256 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 257 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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

Page 258 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. • When determining the requirements for the selection and design of option 2 outlined above, consider the following: ♦ 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 “remigration” 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.

Page 259 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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:

Page 260 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 261 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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 137-139 389 3268 88 445 464 Protocol TCP and UDP TCP TCP UDP UDP UDP Service RPC locator LDAP Global Catalog Kerberos Kerberos authentication Kerberos password

Table 44.4: Internal Firewall Configuration Requirements to Support Migration Path “C”

Page 262 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 263 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.

Page 264 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 265 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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.

Page 266 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 267 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 268 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 269 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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\User02 S-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.

Page 270 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 premigration 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 multifunction 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. Using the above information and approaches, execute the following:  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”

Page 271 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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.

Page 272 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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 premigration 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. 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 “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: • Inter-forest migration paths “D” and / or “H”, and • Intra-forest migration path “G”

Page 273 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 Preparation of security principals within the source Windows 2000 domain to support execution of: • Inter-forest migration paths “D” and / or “H”, and • Intra-forest migration path “G”  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:

Page 274 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 a source domain for the migration of passwords for user accounts  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 interforest 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$$$”. • Clean up of permissions on resources assigned to security principals in the source domain

Page 275 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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). ♦ 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 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.  When creating the “DomainName$$$” local security group, consider the following: • 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.

Page 276 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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. • 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”.  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 “Windows 2000 Native” or “Windows Server 2003” domain functional levels)  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 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.

Page 277 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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, 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 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. • 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.  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.  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:

Page 278 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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 2000 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 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 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 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

Page 279 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. ♦ 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 2000 domain based upon this information. • When determining the requirements for the selection and design of option 2 outlined above, consider the following: ♦ 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”.

Page 280 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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. • 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 / 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:

Page 281 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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.  The objectives of the trust relationships are hence: • To support the execution of inter-forest migration paths “D” or “H”, 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 / (interim) Windows 2000 domain, until it is possible to decommission the source Windows 2000 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 Active Directory 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 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:

Page 282 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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.
Target Windows 2000 Domain

5

4 3

Tree Root

Forest Root

Tree Root

2 1
Source Windows 2000 Domain
© 2004 MUSTANSHI
R

BHAR

MAL

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

Page 283 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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”  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 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 nonsource 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

Page 284 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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.  This design methodology proposes the following approach to support these name resolution requirements: • 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 firewallpartitioned 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 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 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:
Port Number 137-139 389 3268 88 445 464 Protocol TCP and UDP TCP TCP UDP UDP UDP Service RPC locator LDAP Global Catalog Kerberos Kerberos authentication Kerberos password

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: • Analyse the design summary for the network infrastructure that supports the source and target domain infrastructures

Page 285 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • Identify any issues associated with this network infrastructure that may impair or impede the execution of migration paths “D”, “G”, or “H”. • Determine the design requirements for the process or processes to address and resolve the identified issues  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 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 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”.  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 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 interforest 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.

Page 286 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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)  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 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 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 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.  This process hence requires the execution of the following steps: • At the server operating the ADMT in the target Windows Server 2003 / Windows 2000 domain, open a command prompt and navigate to the ADMT

Page 287 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 / 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. • Execute a full backup of the selected PES in the source domain • Retrieve the “password encryption key” generated on a target Windows Server 2003 / Windows 2000 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 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. • 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

Page 288 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 289 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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:  ADMT version 2.0 supports the consolidation of multiple legacy security groups into a fewer number of security groups in the target domain.  Note that the consolidation of security group objects may break any closed “user” sets for the intra-forest migration path “G”.  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 2000 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 2000 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:

Page 290 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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

Page 291 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 292 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 Using the above approach, determine and document the design requirements for the process to execute these tasks. These tasks require execution as premigration 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:  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  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 Alphabased 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

Page 293 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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\User02 S-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.

Page 294 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 premigration 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 multifunction 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. Using the above information and approaches, execute the following:

Page 295 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 296 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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 ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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 premigration 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. 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 “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.

Page 297 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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: • Intra-forest migration path “E”, and • Inter-forest migration path “F”  Preparation of security principals within the source Windows Server 2003 domain to support execution of: • Intra-forest migration path “E”, and • Inter-forest migration path “F”  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 of a source domain for the migration of passwords for user accounts

Page 298 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 intraforest migration path “E”  When determining the design requirements for the pre-migration tasks, for interforest 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$$$”. • Clean up of permissions on resources assigned to security principals in the source domain  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

Page 299 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 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.  When creating the “DomainName$$$” local security group, consider the following: • 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. • 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. • 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”.  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 Server 2003 domain: ♦ User account objects ♦ Computer account objects ♦ Custom security-enabled group objects, including:

Page 300 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 • 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 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. • 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, 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 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.

Page 301 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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.  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.  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 Server 2003 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 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

Page 302 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

“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 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 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. ♦ 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 Server 2003 domain based upon this information. • When determining the requirements for the selection and design of option 2 outlined above, consider the following: ♦ 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.

Page 303 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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”. • 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 a source and target Windows Server 2003, to support execution of interforest 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.  The objectives of the trust relationships are hence: • To support the execution of inter-forest migration path “F”, 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 final Windows Server 2003 and (interim) Windows Server 2003 domain, until it is possible to decommission the interim source Windows Server 2003 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 Active Directory database by the designated administrator performing the migration to the target domain, and

Page 304 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 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.

Page 305 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

Target Windows Server 2003 Domain Tree Root

5

4 3

Forest Root

Tree Root

2 1
Source Windows Server 2003 Domain
© 2004 MUSTANSHI
R

BHARMAL

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”

Page 306 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 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.  This design methodology proposes the following approach to support these name resolution requirements: • 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 firewallpartitioned 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 availability of network links that connect the source and target domain controllers

Page 307 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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 Server 2003 domain controllers, it may be necessary to open ports in the firewall identified in following table:
Port Number 137-139 389 3268 88 445 464 Protocol TCP and UDP TCP TCP UDP UDP UDP Service RPC locator LDAP Global Catalog Kerberos Kerberos authentication Kerberos password

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: • 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 paths “E” or “F”. • Determine the design requirements for the process or processes to address and resolve the identified issues  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 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 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”.  Assign a risk rating to the dependency, and attempt to identify any processes to mediate the risk, where possible.

Page 308 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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 interforest 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)  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.

Page 309 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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

Page 310 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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. • 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 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:  Creation of the migration credentials  Requirements to map and merge security group objects from the source to the target domain  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”

Page 311 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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:  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 Server 2003 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 Server 2003 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:

Page 312 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. ♦ 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 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:

Page 313 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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 premigration 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:  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:

Page 314 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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  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 Alphabased 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

Page 315 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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\User02 S-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.

Page 316 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 It is necessary to determine the following design requirements for the premigration 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. Using the above information and approaches, execute the following:  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”

Page 317 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

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” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  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

Page 318 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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) ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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

Page 319 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 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”. Using the above information, execute the following:  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.

Page 320 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved. • 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: 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:

Page 321 of 446

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

© 2004 Mustan Bharmal. All Rights Reserved.

 The target domain is an existing Windows Server 2003 domain, created via an inplace 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 t