Active Directory Migration Guide

Active Directory
Migration Guide
Prepared by Microsoft Version 1.0.0.0 Baseline
First published 17 March 2008
Prepared by Microsoft
Copyright This document and/or software (this Content) has been created in partnership with the National Health Service (NHS) in Engl England. Intellectual Property Rights to this Content are jointly owned by Microsoft and the NHS in England, although both Microsoft and the NHS are entitled to independently exer exercise their rights of ownership. Microsoft acknowledges the contribution of the NHS in England through their Common User Interface programme to this Content. Readers are referred to www.cui.nhs.uk for further information on the NHS CUI Programme. All trademarks are the property of their respective companies. Microsoft and Windows are either registered trademarks or trademarks of Microsoft registered Corporation in the United States and/or other countries. Microsoft Corporation and Crown Copyright 2008
Disclaimer At the time of writing this document, Web sites are referenced using active hyperlinks to the correct Web page. Due to the dynamic nature of Web sites, in time, these links may become invalid. Microsoft is not responsible for the content of external Internet sites. The example companies, organisations, products, domain names, e e-mail addresses, logos, people, places, and events depicted herein are fictitious. No s, association with any real company, organisation, product, domain name, e mail address, logo, person, places, or events is intended or should be inferred. e-mail
Page ii Active Directory Migration Guide Version 1.0.0.0 Baseline
TABLE OF CONTENTS
1 2 Executive Summary ................................ ................................................................................................ ....................................................... 1 Introduction ................................ ................................................................................................................................ 2 .................................... 2.1 2.2 Value Proposition................................ ................................................................................................ ...................................................... 2 Knowledge Prerequisites ................................................................................................ .......................................... 2 Skills and Knowledge ................................................................................................ .......................................... 2 Training and Assessment ................................................................................................ 3 ....................................
2.2.1 2.2.2 2.3 2.4 2.5 3
Infrastructure Prerequisites ................................................................................................ ...................................... 3 Audience ................................ ................................................................................................................................ 3 ................................... Assumptions ................................ ................................................................................................ ............................................................. 3
Using This Document ................................ ................................................................................................ .................................................... 4 3.1 Document Structure ................................ ................................................................................................ .................................................. 4
Envision ................................ ................................................................................................................................ .......................................... 5 4.1 4.2 Active Directory Overview ................................................................................................ ........................................ 5 Initial State Environment ................................................................................................ ........................................... 5 Public Domain Active Directory Migration Guidance ................................ .......................................................... 6 Microsoft Healthcare Platform Optimisation Active Directory Migration Gu Guidance ............. 6 Technology Scenarios ................................................................................................ ......................................... 7
4.2.1 4.2.2 4.2.3 4.3 5
End State Environment ................................................................................................ ............................................. 9
Plan ................................................................ ................................................................................................ ............................................... 10 5.1 Migration Type ................................ ................................................................................................ ........................................................ 10 New Active Directory or In In-Place (Upgrade) Migration ................................ ..................................................... 11 Direct or Phased Migration ................................................................................................ 12 ................................
5.1.1 5.1.2 5.2 5.3
Evaluating the Existing Environment ................................................................ ...................................................... 12 Scope of Migration ................................ ................................................................................................ .................................................. 13 Users ................................ ................................................................................................................................ 14 ................................. Groups ................................ ............................................................................................................................... 15 ............................... Computers ................................ ................................................................................................ ......................................................... 15 Printers ................................ .............................................................................................................................. 17 .............................. Data ................................ ................................................................................................................................ 17 ................................... Login Scripts ................................ ................................................................................................ ...................................................... 17
5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.4
Migration Process ................................ ................................................................................................ ................................................... 18 Manual Migration ................................ ................................................................................................ ............................................... 18 Automated Migration ................................................................................................ ......................................... 18
5.4.1 5.4.2 5.5
Migration Tools Available ................................................................................................ ....................................... 18 Migrating from Microsoft Operating Systems ................................................................ 18 .................................... Migrating from Novell NetWare Operating Systems ................................ ......................................................... 22
5.5.1 5.5.2
Page iii Active Directory Migration Guide Version 1.0.0.0 Baseline
Develop ................................ ................................................................................................................................ ......................................... 27 6.1 Windows NT 4.0 Domain or Active Directory Migration ................................ ......................................................... 27 ADMT Prerequisites ................................................................................................ .......................................... 27 Installing ADMT ................................ ................................................................................................ ................................................. 35 Enabling Password Migration................................................................ ............................................................ 38 Configuring ADMT ................................ ................................................................................................ ............................................. 41 ADMT Option File and Include File ................................................................ ................................................... 46
6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.2
Novell NetWare Migration ................................................................................................ ....................................... 49 Microsoft SfN Prerequisites ............................................................................................... 49 ............................... Installing Microsoft Services for Netware ................................................................ .......................................... 53 Directory Synchronisation Using MSDSS ................................................................ ......................................... 56 Password Synchronisation Using MSDSS ................................................................ ........................................ 60
6.2.1 6.2.2 6.2.3 6.2.4 7
Stabilise ................................ ................................................................................................................................ ........................................ 61 7.1 Migration Test Process ................................................................................................ ........................................... 61 Pilot ................................ ................................................................................................................................ 61 ...................................
7.1.1 7.2
Reviewing Log Files................................ ................................................................................................ ................................................ 62 Microsoft Migration Logs ................................................................................................ 62 crosoft ................................... Novell Migration Logs ................................................................................................ ........................................ 62 Skills and Training Resources................................................................ ................................................. 63
7.2.1 7.2.2
APPENDIX A PART I PART II APPENDIX B APPENDIX C PART I PART II
Microsoft Active Directory 2003 ................................................................ ........................................................ 63 Active Directory Migration ................................................................ ............................................................. 63 ADMT Sample Option File ................................................................ ........................................................ 64 Document Information .............................................................................................. 66 ..............................
Terms and Abbreviations ................................................................................................ 66 .................................. References ................................ ................................................................................................ .................................................... 67
Page iv Active Directory Migration Guide Version 1.0.0.0 Baseline
EXECUTIVE SUMMARY
The Active Directory Migration Guide will help accelerate the planning and subsequent migration to Microsoft Windows Server 2003 Active Directory within a healthcare organisation and help organisation, bring about a reduction in diversity of server operating systems. The Active Directory Design Guide provides a healthcare organisation with the information required to design a new Active Directory infrastructure. This document (Active Directory Migration Active Guide) provides guidance and current best practice specific to the healthcare industry for the planning and creation of an Active Directory migration solution. This document includes guidance for a healthcare organisation migrating from the following: Microsoft Windows NT Server 4.0 domains Microsoft Windows 2000 Se Server Active Directory Microsoft Windows Server 2003 Active Directory Novell Directory Services (NDS) 4.x, 5.x and 6.x
1
Active Directory Design Guide {R1}: : http://www.microsoft.com/industry/healthcare/technology/hpo/security/activedirectory.aspx http://www.microsoft.com/industry/healthcare/technology/hpo/security/activedirecto Page 1 Active Directory Migration Guide Version 1.0.0.0 Baseline
INTRODUCTION
At present, healthcare organisations typically use one of a number of solutions available for user authentication and providing access to resources. Should a healthcare organisation wish to deploy Active Directory within their environment, they need to first ascertain how the users, computers, applications, data and other resources will be migr migrated across. This document is a component of the strategic Microsoft infrastructure guidance provided through Microsoft Healthcare Platform Optimisation. It provides current best practice guidance, sample Optimisation. scripts and specific design decision recommendations on migrating to Microsoft Windows Server 2003 Active Directory from a number of different network operating systems systems.
2.1
Value Proposition
This document provides guidance on the planning aspects required to carry out an Active Directory migration, and the tools and utilities that can be used The guidance is designed to: ion, used. Help identify potential design and deployment risks Provide rapid knowledge transfer to reduce the learning curve of designing an Active Directory migration solution Establish some preliminary design decisions before moving ahead with the migration Provide a consolidation of relevant and publicly available best practice guidance for Active Directory migration that that: Focuses on guidance specific to healthcare scenarios Reduces the need for decision making by making recommendations where appropriate
2.2
Knowledge Prerequisites
To implement the recommendations in this document effectively, a number of knowledge knowledge-based and environmental infrastructure prerequisites should be in place This section outlines t required place. the knowledge and skills to use the Active Directory Migration Guide, and provides suggested training Guide, and skill assessment resources to make the most of this guidance. The necessary infrastructure prerequisites are detailed in se section 2.3.
2.2.1
Skills and Knowledge

Windows Server 2003 Active Directory and Windows 2000 Server Active Directory Directory: Active Directory design concepts Organisational Unit design Windows NT Server 4.0 operating system (if migrating from this environment if environment): Administrative knowledge for maintaining users and computers NDS or Bindery (if migrating from a Novell environment): if NDS or Bindery object properties for mapping to Active Directory Migration Tools: Active Directory Migration Tool, if migrating from a Microsoft environment Tool, Microsoft Services for NetWare if migrating from a Novell environment NetWare,
The technical knowledge and minimum skills required to use the Deliverable are:
Page 2 Active Directory Migration Guide Version 1.0.0.0 Baseline
2.2.2
Training and Assessment
Guidelines on the basic skill set required to make best use of this Deliverable are detailed in sets APPENDIX A. These represent the training courses and other resources available. However, all courses mentioned are optional and can be provided by a variety of certified training partners.
2.3
Infrastructure Prerequisites
The following are prerequisites for using the Active Directory Migration Guide within a healthcare ive organisation: Available hardware and Windows Server 2003 software for installing the migration tools Full administrative rights to all domains, servers and objects involved in the migration
2.4
Audience
The guidance contained in this document is targeted at a variety of roles within the healthcare IT dance organisations. Table 1 provides a reading guide for this document, illustrating the roles and the illustrating sections of the document that are likely to be of most interest. The structure of the sections is these described in section 3.1.
Executive Summary
Envision
Stabilise
Develop
IT Manager
Review the relevant areas within the document to understand the justification and drivers, and to develop an understanding of the implementation requirements Review the relevant areas within the document against local architecture strategy and implementation plans Detailed review and implementation of the guidance to meet local requirements
IT Architect IT Professional/ Administrator
Table 1: Document Audience
2.5
Assumptions
The guidance provided in this document assumes that healthcare organisations that want to share services and resources between sites already have suitable Internet Protocol (IP Addressing IP) schemes to enable successful site nable site-to-site communication (that is, unique IP Addressing schemes that assigned to each participating healthcare organisation with no overlap). Active Directory and the . underlying Domain Name System (DNS) require the use of unique IP Addressing schemes at adjoining sites for cross-site communication to function successfully. The use of NAT (Network site Address Translation) within an Active Directory environment is neither recommended nor supported by Microsoft.
Plan
Role
Document Usage
Operate
USING THIS DOCUMENT

This document is intended for use by healthcare organisations and IT administrators who wish to migrate to Windows Server 2003 Active Directory. The document should be used to assist with the Directory. planning and implementation of a migration solution and as a reference guide for the most common tasks involved.
3.1
Document Structure
Envision Plan Develop Stabilise
This document contains four sections that deal with the project lifecycle, as illustrated in Figure 1:
Each section is based on the Microsoft IT Project Lifecycle as defined in the Microsoft Solutions Framework (MSF) Process Model, and the Microsoft Operations Framework (MOF). The IT Project 2 Lifecycle is described in more detail in the Microsoft Solutions Framework Core White Papers and cribed 3 the MOF Executive Overview . The MSF Process Model and MOF describe a high high-level sequence of activities for building, deploying and managing IT solutions. Rather than prescri prescribing a specific series of procedures, they are flexible enough to accommodate a broad range of IT projects.
Figure 1: MSF Process Model Phases and Document Structure :
Microsoft Solutions Framework Core Whitepapers {R2}: http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b-ac05-42a6-bab8-fc886956790e&DisplayLang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b fc886956790e&DisplayLang=en

3
MOF Executive Overview {R3}: http://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/mofeo.mspx Page 4 Active Directory Migration Guide Version 1.0.0.0 Baseline
ENVISION
The Envision phase addresses one of the most fundamental requirements for success in any fundamental project: unification of the project team behind a common vision. There must be a clear vision of what is to be accomplished such that it can be stated in clear terms. Envisioning, by creating a high-level view of the overall goals and constraints, will serve as an early form of planning and sets all planning, the stage for the more formal planning process that will take place during the planning phase. Figure 2 acts as a high-level checklist, illustrating the sequence of events that should be level undertaken when envisioning an Active Directory migration within a healthcare organisation organisation:
Active Directory Overview
Initial State Environment
Public Domain Active Directory Migration Guidance
Microsoft Healthcare Platform Optimisation Active Directory Migration Guidance
End State Environment
Technology Scenarios
Microsoft Windows NT 4.0
Microsoft Windows 2000/2003 Active Directory
Novell Netware
Figure 2: Sequence for Envisioning an Active Directory Migration
4.1
Active Directory Overview
Active Directory is the network focused directory service included in the Windows 2000 Server and network-focused Windows Server 2003 operating systems. Active Directory provides an extensibl and scalable extensible service that enables network authentication, administration and management of directory services to an organisation running a Windows Windows-based network infrastructure.
4.2
Initial State Environment
A migration to Active Directory can be a complex undertaking and there are many different approaches to completing such a project. Microsoft Healthcare Platform Optimisation seeks to provide healthcare-specific guidance to reduce the complexity of planning a migration to Active specific Directory within a healthcare organisation, thereby reducing the support and management organisation, requirements for the migration. The provision of a standardised design approach, including key migration. design recommendations, will reduce the time and effort required to design and migrate users and effort computers to Active Directory within the healthcare organisation.
4.2.1
Public Domain Active Directory Migration Guidance
The Internet hosts many Web sites, documents and guidance that provide assistance in understanding the various aspects involved in a migration. This information can be hard to nding migration. navigate, and can contain inconsistencies or out-of-date information. This document seeks to date provide accurate and current best practice guidance much of which is based on a number of guidance, publicly available sources of information for migrating to Active Directory. It also provides guidance from multiple current server operating systems in use. These sources include: Migrating from Windows NT Server 4.0 to Windows Server 2003 Active Directory , which Active provides information on migration methods and Active Directory considerations Designing and Deploying Directory and Security Services , which provides specific chapters on both upgrading and restructuring Windows NT Server 4.0 domains and Active Directory domains ADMT v3 Migration Guide , which details how to use the Active Directory Migration Tool (ADMT) version 3 to migrate and restructure Windows NT Server 4.0 domains and Active Directory domains Migrating Novell NetWare to Windows S Server 2003 , details how to deploy Windows Server 2003 Active Directory into an existing NetWare environment and on migrating NetWare Directory Service (NDS) objects to Active Directory Solution for Migrating File, Print, and Directory Services from Novell NetWare to Windows Server 2003, which provides information on planning, testing and deploying a migration solution. This information can be downloaded as a Microsoft Office Word document or . browsed online: To download the Word document, visit the Download Center To view the information online, visit the Technet Library
10 9 8 7 6 5 4
Microsoft Services for NetWare 5.03 White Paper , which provides detailed technical reference information on the use of Services for NetWare (SfN)
4.2.2
Microsoft Healthcare Platform Optimisation Active Directory Migration Guidance
The guidance provided within this document is predominantly based on the information in the sources listed in section 4.2.1, which has only been included where it is deemed relevant to the , healthcare industry. Coupled with this is current best practice guidance, which is provided to help a
Migrating from Windows NT Server 4.0 to Windows Server 2003 {R4}: ows http://www.microsoft.com/downloads/details.aspx?familyid=E92CF6A0-76F0-4E25-8DE0-19544062A6E6&displaylang=en http://www.microsoft.com/downloads/details.aspx?familyid=E92CF6A0 19544062A6E6&displaylang=en
5
Designing and Deploying Directory and Security Services {R5}: http://technet2.microsoft.com/windowsserver/en/library/d2ff1315-1712-48e4-acdc-8cae1b593eb11033.mspx http://technet2.microsoft.com/windowsserver/en/library/d2ff1315 8cae1b593eb11033.mspx
6
ADMT v3 Migration Guide {R6}: http://www.microsoft.com/downloads/details.aspx?familyid=D99EF770 .microsoft.com/downloads/details.aspx?familyid=D99EF770-3BBB-4B9E-A8BC-01E9F7EF7342&displaylang=en 01E9F7EF7342&displaylang=en

7
SFNmig.doc available for download from NetWare to Windows Server 2003 Migration Planning Guide {R7}: http://www.microsoft.com/windowsserver2003/techinfo/overview/sfnmig.mspx
8
Microsoft Word document available for download from Solution for Migrating File, Print, and Directory Services from Novell ilable NetWare to Windows Server 2003 {R8 http://go.microsoft.com/fwlink/?LinkID=46606 R8}:
9
Solution for Migrating File, Print, and Directory Services from Novell NetWare to Windows Server 2003 {R9}: Windows http://technet.microsoft.com/en-gb/library/bb496964.aspx gb/library/bb496964.aspx
10
Services for NetWare 5.03 White Paper {R10}: http://www.microsoft.com/windowsserver2003/techinfo/overview/sfn503wp.mspx http://www.microsoft.com/windowsserver Page 6 Active Directory Migration Guide Version 1.0.0.0 Baseline
healthcare organisation make decisions in order to plan a migration solution that meets their requirements. The referenced documentation is not expected to be a universal solution for all healthcare organisations, but rather a set of design choices and best practices that can be used to initiate the , local directory services migration solution, understand what decisions are available, why a decision is made, and how to implement that decision. This Active Directory guidance endeavours not to repeat content from public documentation, but to provide a consolidated, organised and structured reference list to the documents listed in section dated, 4.2.1. It highlights recommendations when it is appropriate for a typical healthcare organisation to . deviate from the current default installation configurations of the tools available when migrating to available, Windows Server 2003 Active Directory Directory.
4.2.3
Technology Scenarios
This guide aims to provide current best practice recommendations on how to migrate user and computer accounts to Active Directory. There are three scenarios covered by this guidance to Directory. guidance, which a healthcare organisation can map their environment. These scenarios are: Microsoft Windows NT Server 4.0 domain(s) Active Directory domain(s) Novell Netware (either NetWare 3.x Binderies or NDS) The following diagrams in this section represent some example environments and illustrate the scenarios covered in this guidance guidance.
4.2.3.1
Microsoft Windows NT Server 4.0
Figure 3 represents a simple implementation of two Windows NT 4.0 domains with a two two-way trust relationship between them:
Figure 3: Microsoft Windows NT 4.0 Domain S Scenario
Where an organisation still utilises Windows NT 4.0 domains, it is common to find domains deployed within each physical location of the organisation. Trust relationships are then created between them, in order to share resources amongst the users.
Figure 3 could, for example, represent a centralised account domain where both user and computer accounts reside, with resource domains distributed throughout the rem , remote sites. In turn, these resource domains then trust the account domain with a one way trust; however it is also hese one-way however, common to find that a two-way trust is used. way Whether there are only a few Windows NT 4.0 domains or over 100 with a complicated 100, implementation of trust relationships between them, the migration of user and computer accounts on to an Active Directory environment is dealt with in a similar manner.
4.2.3.2
Active Directory
Figure 4 represents the implementation of an Active Directory directory service:
Figure 4: Microsoft Windows 2000/2003 Active Directory Scenario :
The migration from an existing Active Directory forest to a current best practice Active Directory ng environment is included in this guidance Migration information is provided from both a Windows guidance. 2000 Server domain or forest and a Windows Server 2003 domain or forest. The purpose of . including a migration of this type is for those healthcare organisations that have Active Directory ncluding deployed, but did not follow current best practice guidance when designing the Active Directory infrastructure. This can typically result from the deployment of an application that had an Active . Directory requirement, and the project scope for the delivery of the application did not include a detailed design for Active Directory Directory. A healthcare organisation can use the Active Directory Design Guide {R1} to aid in the production of a new Active Directory design. They will then be able to use this migration guidance to migrate the Active Directory objects from one or more Active Directory domains to the new Active Directory bjects domain.
4.2.3.3
Novell NetWare
Figure 5 represents the implementation of a Novell NetWare NetWare-based authentication mechanism for uthentication the healthcare organisations users and computers s computers:
Figure 5: Novell NetWare Scenario
This guidance covers in detail the options available and the current best practice methods to migrate from an NDS using NetWare version 4.x, 5.x or 6.x to a Windows Server 2003 Active Directory. While this guidance focus on these NetWare versions, it is still possible to use this focuses guidance if migrating from an implementation of a Novell eDirectory environment or a Novell NetWare 3.x environment (that uses binderies to store user accounts and other resource that information).
4.3
End State Environment
The Active Directory migration guidance in this document will help lead a healthcare organisation through the process of making complex design and implementation decisions to migrate to an g Active Directory infrastructure. Whilst no Active Directory migration guidance can be all encompassing, this document enables a healthcare organisation to simplify the decision process, whilst allowing them to consider local m requirements. This will enable the organisation to migrate users, computers and other resources to the new Active Directory environment environment. This guidance, when used with the Active Directory Design Guide {R1}, can assist a healthcare organisation in implementing a directory service that can reduce diversity in Active Directory designs across the organisation aiding in the supportability of the healthcare organisations organisation, organisations directory services.
PLAN
The Plan phase is where the bulk of the implementation planning is completed. During this phase phase, the areas for further analysis are identified and a design process commences. Figure 6 acts as a high-level checklist, illustrating the sequence of events that the IT Manager and level IT Architect need to determine when planning for an Active Directory migration solution within a ory healthcare organisation:
Figure 6: Sequence for Planning an Active Directory Migration
5.1
Migration Type
The initial decisions to be made as part of a migration project are to first ascertain how to create the ecisions new Active Directory environment and then the approach as to how objects will be migrated to it. There are two ways in which a healthcare organisation can build the new Active Directory environment. The current environment may determine the way in which the environment is built: he If a healthcare organisation currently uses a Windows NT 4.0 domain or a Windows 2000 Active Directory, it is possible to carry out an in in-place migration to Windows Server 2003 and the new Active Directory environment
If a healthcare organisation currently uses Novell NetWare, or has an Active Directory environment that does not meet the needs of the healthcare organisation a new Active organisation, Directory installation should be deployed There are also two ways in which a healthcare organisation can populate the new Active Directory environment with the objects that should be migrated from the old environment environment: A Direct migration approach involves the migration of all users, groups, computers, and any other objects required, typi typically within a one-time migration A Phased migration approach enables a healthcare organisation to migrate various objects while maintaining both the old and new environments using trust relationships or synchronisation tools during the transition period
5.1.1
New Active Directory or In ew In-Place (Upgrade) Migration )
The decision on whether a new Active Directory environment is created from a fresh i installation or an in-place migration should consider some basic advantages and disadvantages as detailed below.
Important The in-place migration approach is not available to healthcare organisations that are looking to migrate to place Active Directory from Novell NetWare therefore, they must use the new Active Directory method. NetWare;
The creation of a new Active Directory installation provides a clean environment that is not populated with users or computers that potentially no longer exist. It also allows a clear distinction . between the old and new environments and allows the old environment to remain in place which ronment place, can act as part of a rollback facility should issues occur during the migration. A disadvantage of creating a new Active Directory installation is that all computers that are members of the old environment need to have the computer accounts migrated through a manual their or automated/scripted process. The same process needs to take place for the user accounts that need to be migrated. These disadvantages can be addressed using migration tools such as the Active Directory Migration Tool (ADMT) or the Microsoft Directory Synchronization Services tion (MSDSS) utility. It is important to also consider the hardware requirements for the in place migration approach. If a in-place healthcare organisation is assessing an in-place migration from a Windows NT 4.0 domain, the server to be used should be both the Primary Domain Controller (PDC) and be capable of running Windows Server 2003. If the server is not capable of running Windows Server 2003, a common approach is to install Windows NT 4.0 as a Backup Domain Controller (BDC) on a new server that kup does meet the hardware requirements of Windows Server 2003, and to promote this as the PDC PDC. This server can then be upgraded to Windows Server 2003 retaining the user and computer 2003, objects.
Caution If a new server is to be purchased to install Windows NT 4.0 and subsequently upgrade to Windows upgraded Server 2003, ensure the hardware vendor provides Windows NT 4.0 drivers for the server because many new servers fail to run the Windows NT 4.0 operating system properly, due to the lack of available drivers drivers. Recommendation It is recommended that a new Active Directory installation is deployed to introduce a clean environment that can be designed from the ground up. Use the Active Directory Design Guide {R1 to aid in the R1} designing of the new Active Directory.
5.1.2
Direct or Phased Migration
Once the decision has been made on how to implement the new Active Directory env environment, a decision needs to be made on whether the migration takes a direct or phased approach. A direct migration is one that involves the migration of all objects including servers, users, groups, client computers, and so on, in a single, one one-time migration. This approach should only be used ation. where any earlier systems, such as a Windows NT 4.0 PDC or BDC, or a NetWare server, are no longer required (as all applications have been replaced or relocated away from these servers as servers). Servers running Windows 2000 Server that act as a domain controller can be demoted and act as a member server. This process should be fully tested in a test environment as an issue could require a rollback of changes, which could mean having to revisit all the computers that have already been hat migrated to the new environment environment. A phased migration, also referred to as a staged migration, involves running the new and old , environment in parallel for a period of time. This enables the migration to be split into more manageable stages, therefore reducing the element of risk involved. This also allows easier rollback of the changes made. This is because the IT administrators have a more focused view on . a specific stage, as opposed to an entire migration completed at one time.
Recommendation It is recommended that a healthcare organisation use the phased migration approach due to the potential complexity and size of their environment. This allows IT administrators to focus on easily managed stages, cater for easier rollback should issues occur, as well as reducing the risk involved in a direct rollback, migration.
In a phased migration, it is important to make both the old and new environments accessible accessible, whether through trusts or synchronisation. In a Windows based environment, this can occur Windows-based through the use of external trust relationships whereas in a Novell environment this involves using relationships, environment, tools to synchronise directory information.
5.2
Evaluating the Existing Environment
The aim of evaluating the existing environment is to understand the infrastructure that is currently in tructure place and to be aware of the risks involved in such a migration project. The aim is to also reduce the potential for unforeseen issues which may arise during the actual migration. issues, As part of the evaluation, a number of infrastructure areas should be assessed and documented as listed in Table 2:
Infrastructure Area
Network Diagram
Comment
The current network should be documented in a diagram to show the location of servers, and the server type, such as file server, Web server, database server and so on. For each server, the server operating systems server, version, patch revision, and the transport protocols that are in use should also be documented , documented. Ensure all printers currently used within the environment can continue to be used once migrated. Especially in NetWare environments where a printer currently uses the Internetwork Packet Exchange ( environments, (IPX) protocol, ensure it can use TCP/IP. If not, the printer may need replacing. All information stored on the network servers needs to be identified, whether it is user data or application data. The location of the data who is responsible for it, which users have access to it and the security he data, , requirements for data storage must also be noted. Ensure that if any software installed on a server to be decommissioned is still required it is catered for in the required, migration process. This involves documenting the version installed, any configuration and whether or not the software can run on Windows Server 2003. If not, the software may need updating or repla replacing.
Printers
Network stored information Server operating systems dependent software
Infrastructure Area
Local Area Networks (LAN)/Wide Area Networks (WAN) links User environment properties Health of current domain or NDS
Comment
Along with the network diagram detailing the servers, it is also important to create a diagram that includes the network links in place and the available bandwidth. This is a prerequisite for an Active Directory design. This includes the identification of login scripts, system or group policies in place, and home folder locations. This primarily refers to the synchronisation between servers but also to the server operating system. For NT4 domains or Active Directory, ensure replication is occurring properly between domain controllers and the event viewer does not contain any unexpected errors. For Novell servers, use tools such as DSTRACE and servers, DSREPAIR to verify synchronisation.
Systems to be migrated Determine which servers are to be migrated or decommissioned. As part of this, understand which users, groups, computers, files, and databases will be affected.
Table 2: Evaluating the Existing Environment
5.3
Scope of Migration
As part of any migration project, it is important to understand all the components that are to be migrated. As part of the infrastructure documentation listed in Table 2, the evaluation of the systems to be migrated enables each of the individual objects for migration to be identified This identified. includes: Users Groups Computers Printers Data Login scripts For each of these, document the details such as: Current name (including domain name if a user, group or computer account) Target name (especially if domain consolidation is part of the migration and multiple objects currently share the same name name) Current location (both physical and logically within the domain or NDS Tree) physically DS Target destination (the Active Directory organisational unit (OU) to which the object will be ich migrated, and the location of a server if a physical move of the server tak place) takes
5.3.1
Users
Different types of user accounts have different requirements and access needs. Typically, a user and account can be placed into one of three categories categories: IT administrator Service account Standard user Migrating to a new Active Directory environment provides an ideal opportunity to ensure that igrating appropriate administrative accounts are created. These administrative accounts are those that are counts used by members of the IT department or that are delegated certain permissions. These are not the day-to-day accounts for users, but rather the account that should be used to run adminis accounts administrative tasks.
Recommendations Administrators, or those users being delegated administrative rights for certain job role functions, should not have administrative permissions granted to their normal day-to-day accounts. Instead, a separate day account should be created with the appropriate rights and permissions. The user should then use the Run as feature to carry out this portion of their responsibilities. For more information on the current best 11 practice method of using Run as, see the Windows Server 2003 Product Help Web page Using Run as . The migration of user accounts should be carried out using the following order:
1. Administrative accounts 2. Service accounts 3. User accounts If migrating from an NDS environment, a user is uniquely identified through the distinguished name, and not the common name (CN) For example, when creating a user in NDS, a common name (CN). could be specified as Anna, whereas the NDS distinguished name could be Anna Bedecs. If another user existed in a different NDS organisational unit with the common name of Anna, but with with an NDS distinguished name of Anna Lidman, this is allowed. However, in Active Directory, user account names must be unique across the whole domain, not just the OU, as is the case in NDS.
Note The specific user account names that need to be unique in Active Directory are: Distinguished Name (DN) Relative Distinguished Name SamAccountName
If both users were to be migrated, the first user migrated would have the logon name Anna, but the second user would have the logon name Anna0. The Active Directory Design Guide {R1} provides information on naming conventions including users with the same name. conventions,
Recommendation If users exist with the same name, it is recommended that a healthcare organisation change the logon names of the users within NDS, to make them unique, prior to the migration. n The same process should be applied to users with the same name that currently exist in different Windows NT or Active Directory domains that are being restructured into a single Active Directory domain.
11
Using Run as {R11}: http://technet2.microsoft.com/windowsserver/en/library/8782f8ab-9538-4111-8a68-7bfd130c21c01033.mspx?mfr=true http://technet2.microsoft.com/windowsserver/en/library/8782f8ab 7bfd130c21c01033.mspx?mfr=true Page 14 Active Directory Migration Guide Version 1.0.0.0 Baseline
5.3.2
Groups
Groups are a common object found in all current server operating systems and must be catered for in the migration. If migrating from NDS using MSDSS any NDS organization or NDS OU that will be part of the MSDSS, migration will have a domain local security group created in Active Directory. These domain local security groups will then be mapped to the corresponding NDS organi ation or NDS OU. organisation In a Windows NT 4.0 environment, a local group is converted to a domain local security group and a global group converts to a global security group. If migrating groups, and user membership of group. their groups is still required, Security Identification (SID) history must also be migrated. SID history migration is completed using ADMT v3, which can automatically configure the old and new the domains as part of the installation and initial usage process.
Caution A global group migration process can consume large amounts of network resources as well as local resources, resources on the domain controller in the target domain. Therefore, a global group migration should be global completed outside of normal or peak working periods.
5.3.3
Computers
Servers Desktops Portable computers
As with users, computers can also be placed into their different categories such as:
Each computer type will need different considerations when being migrated to the new siderations environment. These computer types are discussed in more detail below.
5.3.3.1
Servers
Servers require particular focus and the amount of effort required to migrate them is highly dependent upon the current role they play within the existing infrastructure. For example, a server running Windows Server 2003 configured as a member server and server, operating as an intranet Web site for users, could be migrated without many configuration changes. However, a Novell NetWare server aut authenticating users and running an unsupported application could require a lot more planning to migrate and potentially to decommission.
Recommendation Replacing existing directory-enabled services or applications with new Active Directory enabled Directory-enabled software is a task that should be performed independently of the migration of NetWare users, groups, distribution lists, organisational units, organisations, and files.
5.3.3.2
Desktops
Desktops are commonly seen as one of the easiest objects to migrate However, there are areas migrate. owever, that need careful consideration and can sometimes be overlooked. For example, in an environment where a computer currently runs a small application that requires the Microsoft Windows 98 operating system to operate, if secure communication is requi required between the server and client computer, the computer will require the Active Directory Client Extension (DSClient) to be installed. This is also the case for Windows NT 4.0 client computers. These computers will therefore require a resource to manually install the software required which required, takes additional time and planning.
Recommendation It is highly recommended that if a healthcare organisation has computers with the Microsoft Windows 95 , Windows 98 or Microsoft Windows NT Workstation 4.0 operating systems installed which will become installed, part of the new Active Directory environment, the DSClient is installed for more secure communication between the server and client computer (through the use of the NTLMv2 level of LAN Manager Authentication).
In a NetWare environment, a computer would typically have the Novell Client32 or Novell Client for are Windows software installed. As part of the migration the Client32 software would need to be migration, removed and the computer would then use the Windows client for user authentication to the new environment. This Client32 software can either be removed manually or via a script that is run through a login script or batch command file. atch As part of a migration from a Microsoft or Novell environment, unless an in-place migration is taking place place, all desktops will need to be configured with new domain membership to become part of the new environment.
Important One of the most common failures during a migration of computer accounts is due to the desktop computer ost being switched off and, as such it cannot be migrated. It is important for a communication to be sent out such, to all computer users informing them that computers must be left on for the duration of the migration. be
5.3.3.3
Portable Computers
Migrating portable computers is a similar process to that involved in migrating desktops but with one additional complication. Due to the nature of portable computers, it can be difficult to e ensure the computer accounts for these computers are migrated to the new environment This is typically environment. because the computers are not connected to the network outside of normal working hours as hours, users take the computers home. It is important to have a process in place whereby users can bring their portable computers into the workplace to have them migrated during normal working hours. Alternatively, provide a secure location for users to leave them overnight, or during other periods outside of normal working hours.
Recommendation A migration project should contain a schedule of which computer will be migrated and at what time This time. should be clearly communicated to users s that they are aware when their portable computers are so required to be connected to the network for successful migration and to help keep the project within the allotted timeframe.
5.3.4
Printers
Printers are an important resource to users and access to them must be maintained at all stages of the migration.
Important If all printers used in a Novell environment are required to be migrated to the new environment, e ensure that the printers can be printed to using TCP/IP and not just IPX.
If migrating from a Windows-based environment, the Microsoft Windows Server 2003 Print Migrator based tool can be used to migrate printers from a print server running Microsoft Windows NT 4 4.0, Microsoft Windows 2000 or Microsoft Windows Server 2003 2003. The Print Migrator Tool 3.1 can be downloaded from the Microsoft Download Web site . A technical document providing detailed information around planning, deploying and managing Windows based print servers using the Print Migrator tool can be downloaded fro the Microsoft from 13 Download Web site . In a Novell environment, print queues made available through a NetWare server can still be used through the Client Service for NetWare (CSNW), until the printers are migrated to the new environment. For more information on the CSNW, see the Client Service for NetWare Windows 14 Server 2003 Product Help Web page .
12
5.3.5
Data
In Novell environments, the File Migration Utility (FMU) which is part of SfN, can be used When (FMU), used. using MSDSS, it is possible to complete a migration that includes an option for a file migration. This includes option creates a migration log that the FMU can use to maintain users access rights to their data. users In Microsoft environments, use a backup and restore method to migrate the data and use a tool such as Robocopy to ensure that any files updated by users during the backup and restore process are kept up to date. Shared folders cannot be migrated, so a tool such as the Wi Windows Server 2003 Resource Kit tool (Permcopy.exe can be used to copy the permissions from a sour share Permcopy.exe) source path to a target share path.
5.3.6
Login Scripts
Login scripts can currently take the form of batch files, such as a . .cmd or .bat file, a KiXtart script (commonly referred to as a KIX script), or other proprietary scripting languages typically found s within a NetWare environment. Migration of these scripts requires careful planning when migrat in migrating into an Active Directory environment. Active Directory provides the ability to specify a batch file (configured in the user properties) as th the login script for individual users It also provides the batch file processing method when using Group users. Policy objects (GPOs). Using GPOs, a healthcare organisation can specify startup, logon, logoff bjects and shutdown scripts, providing a very precise control over when the scripts are run.
12
Print Migrator Tool 3.1 {R12}: http://download.microsoft.com/download/4/5/2/452d431e-5a5c-43bd-b398-6fc27208e001/printmig.exe http://download.microsoft.com/download/4/5/2/452d431e 6fc27208e001/printmig.exe

13
Microsoft Print Migrator 3.1 {R13}: http://download.microsoft.com/download/2/e/5/2e57d536 2bb5-40f1-b52dhttp://download.microsoft.com/download/2/e/5/2e57d536-2bb5 a11f5aae2e22/Microsoft%20Print%20Migrator%203.1.doc

14
Client Service for NetWare {R14}: http://technet2.microsoft.com/windowsserver/en/library/eda1cc2b-c3cc-4845-add0-503439f6d1271033.mspx?mfr=true http://technet2.microsoft.com/windowsserver/en/library/eda1cc2b 503439f6d1271033.mspx?mfr=true Page 17 Active Directory Migration Guide Version 1.0.0.0 Baseline
5.4
Migration Process
Two options exist for a migration process; a manual migration, or an automated migration through the use of tools. The option use is mainly dependent upon the following: used The size of the migration (number of objects to migrate) Whether the objects that exist in the current environment are valid or not ( example of an (an invalid object is when a user account exist for a user that has left employment exists employment) The configuration of objects such as access control lists (ACLs) of files and so on
5.4.1
Manual Migration
A manual migration process is one that involves re entering user accounts, computer accounts and re-entering group membership, and the securing of files and folders that are copied across to the new environment. This option is typically used in an environment where: The number of objects to migrate is relatively small The objects need extensive updating due to inaccuracy of the objects properties The information to be migrated is out of date and no longer required The investment in learning, installing and using the migration tools could take longer than ent the manual migration process itself
5.4.2
Automated Migration
An automated migration process uses tools to populate the new environment with information and data taken from the current environment. This option is typically used in situations where a large ent number of objects and files need to be migrated and these already exist in the current environment.
Recommendation A healthcare organisation should use an automated migration process due to the number of objects process typically found within the environment and the data security already put in place.
The tools available to use as part of the migration depend upon the platform from which objects are migrated. The freely-available tools provi available provided by Microsoft enable a healthcare organisation to migrate to Active Directory in a much faster and more efficient manner than using manual migration.
5.5
Migration Tools Available
A number of tools are available to assist in the migration to Active Directory. The specific tool that Directory. should be used is dependent on whether the migration is from a Microsoft or Novell environment, and the object that is migrated.
5.5.1
Migrating from Microsoft Operating Systems
When migrating from a Microsoft Microsoft-based environment, a number of tools can be used to automate the migration. Depending on what objects within the current environment are to be migrated, both epending the extent of control needed over these objects and the resources available (including their including technical abilities) can influence which tool is used.
5.5.1.1
Active Directory Migration Tool
ADMT v3 is the free Microsoft tool that is available on a Windows Server 2003 CD or that can be 15 downloaded from Microsoft Download Center . ADMT can be used to migrate users, groups, service accounts, computers and trusts from a Windows NT 4.0 domain, or a Windows 2000 Server or Windows Server 2003 Active Directory environment. ADMT also allows for the translation of security from the old to the new environment. ADMT can also be used to restructure domains currently in place. The Active Directory Design Guide {R1} recommends the implementation of a single domain Active Directory fo forest for a healthcare organisation. Based upon this recommendation an environment that currently has . recommendation, multiple Windows NT 4.0 domains such as account and resource domains, can use ADMT to domains, restructure these domains into a single domain Active Directory forest.
Important When restructuring domains, the target Active Directory domain functional level must be at Windows 2000 native level or Windows Server 2003 level.
ADMT can also be used to restructure domains if migrating from an existing Active Directory ctive infrastructure. Two types of restructuring exist for Active Directory domains: interforest and . intraforest. , An interforest restructure, as shown in Figure 7, involves migrating objects between Active Directory forests; typically faced in a merger between organisations, such as two healthcare organisations amalgamating and combining the IT infrastructure to reduce administrative s complexity and overhead:
Figure 7: Active Directory Interforest Restructure using ADMT :
15
Active Directory Migration Tool v3.0 {R15}: http://www.microsoft.com/downloads/details.aspx?FamilyID=6f86937b-533a-466d-a8e8-aff85ad3d212&DisplayLang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=6f86937b aff85ad3d212&DisplayLang=en Page 19 Active Directory Migration Guide Version 1.0.0.0 Baseline
An intraforest restructure involves migrating objects between multiple domains within the same Active Directory forest as shown in Figure 8:
Figure 8: Active Directory Intraforest Restructure using ADMT :
A major difference that can influence the decision between these types of restructuring should be fully understood: Objects during an intraforest restructure are migrated and no longer exist in the old environment. Objects in an interforest restructure are cloned, and therefore the original objects remain in place. In this case, a healthcare organisation would have the immediate benefit of having an environment that could be rolled back to, should an issue occur.
Recommendation A healthcare organisation migrating from a current Active Directory infrastructure shoul use the should interforest restructure migration method to ensure that the new environment contains only the required objects and has been designed according to the guidelines set out within the Active Directory Design Guide {R1}. This provides the additional benefit of keeping the old environment intact should a rollback be required. Only consider an intraforest restructure if the current Active Directory is in a healthy state with a well managed collection of objects that are known to be up to date and the design of the Active Directory date, follows the Active Directory Design Guide {R1} recommendations and/or is well documented.
ADMT can be run by using thre different methods: ree ADMT console Command line A script When using ADMT through a command line, both an option file and an include file can be specified. The option file contains the appropriate answers to the options available for the type of object being migrated. The include file contains the names of those objects to include when migration takes place.
Recommendation For a healthcare organisation that does not have in-house expertise in Microsoft Visual Basic Scripting house Edition (VBScript), it is recommended that the command line method is used, combined with an option file , and an include file. This provides the easiest method to test a migration; it aids in documenting the objects . being migrated, and in running the final migration.
By default, ADMT uses the Microsoft SQL Server 2000 Desktop Engine (WMSDE) as its data store. It is also possible to configure ADMT to use SQL Server 2000 SP4 Standard SQL Server Standard, 2000 SP4 Enterprise Edition, or Microsoft SQL Server 2005.
Recommendation It is recommended that healthcare organisations use the default WMSDE database store as installed and store, configured during the installation of ADMT.
5.5.1.2
Password Export Server Service
The Password Export Server (PES) service part of the ADMT download, allows the migration of service, passwords between the current and new environments. The PES service needs to be installed on a domain controller in the source domain to enable password m migration. For password migration to take place using the PES service, both the computer that has ADMT installed and the computer that will have the PES service installed require 128- high encryption. -bit This encryption is standard on domain controllers running Windows Server 2003 Windows 2000 running 2003, Server Service Pack 3 (SP3) or Windows 2000 Server Service Pack 4 (SP4). If installation is . required on a computer that does not currently support 128 bit high encryption, a high encryption 128-bit pack is available for download from Microsoft. For Windows 2000 Server, obtain the Windows 2000 High Encryption Pack (128 (128-bit) Microsoft Download Center.
16
from the
For Windows NT 4.0, if Microsoft Internet Explorer 5.5 is installed, this includes 128 128-bit high encryption. If not, Internet Explorer 4.1 plus Internet Explorer High Encryption Pack 4.0 is required required, 17 which is available from the Microsoft Download Center . icrosoft
5.5.1.3
Third-Party Tools Party
Whilst ADMT provides an extensive array of options when migrating from Windows NT 4.0 or Active Directory, for large complex environments, some limitations of ADMT could require a healthcare organisation to provide extra resource in planning, developing and migrating between provide environments. Other migration tools are available for purchase from other companies, for example, Quest Software has a Domain Migration Wizard product focusing on migrations from Windows NT, and the Migration Manager for Active Directory product, for migrations and domain restructuring from Active Directory. These tools can provide enhanced benefits such as: Complete rollback capabilities Directory synchronisation Post-migration clean-up of resources up Detailed statistics of the migration
16
Windows 2000 High Encryption Pack (128 (128-bit) {R16}: http://www.microsoft.com/downloads/details.aspx?FamilyID=C10925A0-AC66-4C44-B5C3http://www.microsoft.com/downloads/details.aspx?FamilyID=C10925A0 9DCAB4DA1C63&displaylang=en
17
Internet Explorer High Encryption Pack 4.0 {R17}: http://go.microsoft.com/fwlink/?LinkId=76038 Page 21 Active Directory Migration Guide Version 1.0.0.0 Baseline
For more details on the tools available from Quest Software, visit the Migration Tools for Active 18 Directory Web page .
Note The information provided here on Quest Software tools is neither a recommendation nor an endorsement for its use within a healthcare organisation If a healthcare organisation wishes to consider these tools for organisation. their Active Directory migration project, careful assessment, planning and testing of the migration must still take place.
5.5.2
Migrating from Novell NetWare Operating Systems
When migrating from a Novell-based environment, a number of tools are available to help automate -based the migration to Active Directory as described in this section. Directory,
5.5.2.1
Microsoft Services for NetWare
Microsoft Services for NetWare 5.03 (SfN) enables a healthcare organisation to integrate Windows ces Server 2003 servers into an existing Novell NetWare network whether this is a Bindery or network, NDS-based environment, and carry out a phased migration running the Windows environm , environment and the NetWare environment in parallel. SfN includes Microsoft Directory Services Synchronization (MSDSS) and the File Migration Utility ft Synchronization (FMU). These tools, coupled with the necessary protocols used within a NetWare network, allow IT administrators to migrate and synchronise objects, and offer basic interoperability between a between, Microsoft Active Directory and a Novell NetWare Directory Service (NDS). SfN also provides tools to aid in troubleshooting connectivity, login scripts and password 19 synchronisation issues, as well as monitoring network traffic. SfN, version 5.03 SP2 at the time of writing this document, can be downloaded from the Microsoft Download Center Center.
Note SfN requires the installation o the Novell Client for Windows available from the Novel Downloads Web of Novell page.
20
File and Print Services for NetWare (FPNW) is a tool that can make a Windows Server 2003 server appear to be a NetWare 3.x server to client machines. FPNW is available to download from the 19 same Web page as SfN .
18 19
Migration Tools for Active Directory {R18}: http://www.quest.com/active-directory/migration.aspx directory/migration.aspx
Microsoft Services for NetWare 5.03 SP2 and FPNW {R19}: http://www.microsoft.com/downloads/details.aspx?FamilyID=a819838d-acb2-4794-87eb-82a6a3af4be8&DisplayLang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=a819838d 82a6a3af4be8&DisplayLang=en
20
Novell Downloads {R20}: http://download.novell.com/index.jsp Page 22 Active Directory Migration Guide Version 1.0.0.0 Baseline
5.5.2.2
Microsoft Directory Services Synchronisation
MSDSS enables bidirectional synchronisation between Active Directory and NDS or eDirectory directory services. With MSDSS, a healthcare organisation can configure a one y one-way or two-way synchronisation between the different directory services This allows objects, such as user services. accounts, to be updated in Active Directory; these updates are then synchronise across to NDS. synchronised Table 3 describes in detail the following types of synchronisation that can occur as part of MSDSS MSDSS:
Synchronisation Type
Forward synchronisation
Description
A forward synchronisation is the process of synchronising data from Active Directory to Novell (whether this is NDS, eDirectory or Bindery). The forward synchronisation process queries Active Directory for new objects or existing objects that have been changed. If a new object has that been created, only this new object and its attributes are synchronised. If an existing object has changed, then only the changes are synchronised, not the entire object. A reverse synchronisation is the process of synchronising data from Novell to Active Directory. This type of synchronisation is less efficient than a forward synchronisation as MSDSS compares all objects in NDS against those existing in Active Directory. I any objects have been If changed or new ones created, they are synchronised in their entirety. Due to the way a reverse synchronisation takes place, an increase in network traffic could be expected. Reducing the frequency of synchronisation could help reduce the network utilisation, but can have an adverse reduce effect on the data held within Active Directory and potentially cause Active Directory to become out of date. A one one-way synchronisation allows a healthcare organisation to introduce Active Directory into a Novell environment and manage the directory service objects from Active Directory while ensuring that the Novell directory service is kept up to date. This method of synchronisation is completed through an initial reve synchronisation followed by subsequent forward reverse synchronisations. A two two-way synchronisation is the same as a one-way synchronisation except that additional way objects can be created and existing objects altered from within Active Directory or the Novell directory service. This is typically useful in environments where both Active Directory and NDS are to be maintained. A scheduled synchronisation ensures that changes are replicated from one directory service to the other. By default, a forward synchronisation is carried out every 15 minutes, 24 hours a day. A reverse synchronisation is carried out every hour from 00:00 (midnight) to 06:00 due to the midnight) 06:00, increased network traffic caused by this type of synchronisation. If two two-way synchronisation is in use, a different schedule can be configured for each direction. A manual synchronisation can be initiated by an IT administrator to synchronise changes immediately between one directory service and the other. This can be useful in situations where a migration activity has taken place and a password change or disabled u account needs to user be synchronised immediately, rather than waiting for the next scheduled synchronisation. A password synchronisation process can only take place if the passwords are changed from Active Directory. A password sy synchronisation occurs when an initial reverse synchronisation takes place, a user account is created in NDS as part of a two way synchronisation, or a two-way password is changed in Active Directory. It is not possible to synchronise passwords from a Novell directory service to Active Directory. A directory password scheme is used if either an initial reverse synchronisation is completed or new users are created in NDS. A password scheme is then used to determine what the password will be for the first logon. The user is then prompted to change it once successfully logged on.
Reverse synchronisation
One-way synchronisation
Two-way synchronisation
Scheduled synchronisation
Manual synchronisation
Password synchronisation
Table 3: MSDSS Synchronisation Types
Recommendation It is recommended that a healthcare organisation uses an initial reverse synchronisation, followed by one oneway forward synchronisations configured with a default schedule. Once the initial synchronisation has occurred, objects should be managed through Active Directory and any changes including passwords changes, passwords, will be synchronised to NDS. ll
For the full functionality of MSDSS, both the Active Directory and NDS directory schemas require extending. The Active Directory schema extensions enable the following features features: Migration One-way synchronisation way Two-way synchronisation isation The NDS directory schema extensions are only required for a two-way synchronisation. way
Note As the recommendation is to use a one way synchronisation, it is possible to carry out the migration one-way without the need to extend the NDS directory schema.
MSDSS provides the ability to migrate passwords from Active Directory to NDS, Bindery or S eDirectory; however, it is not possible to migrate passwords from a Novell environment to Active Directory. For this reason, when synchronising users during an initial reverse synchronisation, a password scheme is used to specify what the password should be for new users in Active Directory. Four possible options are available, as detailed in Table 4: ,
Password Scheme
Set passwords to blank Set passwords to the user name Set passwords to random values
Description
When this option is selected, users are created with a blank password When logging on for the password. first time, the user will have to create a password. When this option is selected, users are created with a password that matches their user name. When logging on for the first time, the user will have to change this password. When this option is selected, users are created with a password that is set to a random value, eight characters in length. When logging on for the first time, the user will have to change this password. This option is the most secure password scheme available. The random values are written to a text file that members of the Administrators group on the domain controller can access.
Set all passwords to the following
When this option is selected, users are created with a password that is specified within the fields available in the Password Synchronisation Options dialog box. When logging on for the first time, Options the user will have to change this password.
Table 4: MSDSS Password Schemes
The following example text has been extracted from a MSDSS generated file using the random an value password option:
Session 1: {21AD8B68-2A42 2A42-459e-BD29-F082F47E71B2} Started: 01-31-2008 08:21 2008 jonathan sagiv jNA$3mR_h7 X.kQ#tu68B
jacqueline WJr+66Ru.e rich ivo +bq-I2ZxM4 T%?Db3vZ2b
The first line provides the session identification and the second line displays the time and date the synchronisation started. All subsequent lines contain the username of the user account being synchronised followed by a randomly generated password. Choosing the random value option provides the most secure password scheme but also requires the most planning regarding the but communication of the new passwords to the migrated users.
Recommendation It is recommended that a healthcare organisation uses the option of setting passwords to random value values because all other options would enable any user to logon using any other users migrated account and gain access to data and other resources to which they normally would not have access. A communication should be created for all users, informing them of the time they will be migrated to the new environment and any changes to the logon process as well as any new location for storing their data, process, and so on. This communication can also be used to relay what the user s new password will be. For . users example, creating a mail-merge document while using the password file as a data source, allows merge using communications to be created directly focusing on the individual user. directly,
5.5.2.3
Microsoft File Migration Utility
The FMU enables the migration of files between a NetWare server and a Windows Server 2003 server, including the security permissions of those files. It also allows users to continually access the files during migration. Prior to the use of the FMU, a migration of directory service objects must take place to enable the translation of file system rights and permissions when migrating to the equivalent rights and permissions in the NTFS file system. When migrating using MSDSS, an option to migrate files is , available. Selecting this option creates a log file which is then used by FMU as a mapping file to file, ensure users and groups effective rights on the NetWare files are translated correctly to the permissions in the Windows environment.
Note It should be noted that the FMU cannot be used without the use of MSDSS because the relationship between NDS and Active Directory objects must be translated. Within NDS, permissions to files and folders can be granted to users, groups, organisational units and organisations. It is not possible to specify permissions on a file in Windows to an organisational unit. In this case, MSDSS maps an NDS organisational unit or organisation to an Active Directory domain local security group.
Using FMU, it is possible to view migration maps to see which objects from NDS are being mapped to the corresponding objects in Active Directory. The following maps are available to view: NDS organisational units and organisations to Active Directory group NDS group to Active Direc Directory group NDS user to Active Directory user Using these migration maps allows an IT administrator to confirm the translation of objects from NDS to the corresponding objects in Active Directory. When using the FMU, the source must always be a volume or directory on an NDS server and the directory target must be a shared folder on a Windows Server 2003 or Windows 2000 Server The FMU Server. allows for a single source to be mapped to multiple targets or multiple targets mapped to a single o source.
5.5.2.4
Third-Party Tools Party
SfN provides a set of freely available tools and utilities when migrating from Novell NetWare. es However for larger, more complex environments, some limitations of SfN could require a healthcare organisation to provide extra resource in planning, developing and migrating between migrating environments. Other migration tools are available for purchase from other companies, for example, Quest Software has developed NDS Migrator; a tool specifically designed to aid in migrating from NDS or Bindery services to Active Directory. NDS Migrator can provide enhanced benefits such as: A single tool for migration of both objects and data Does not require additional software installed on a domain controller Simple exclusion of unused, disabled or locked locked-out accounts Supports a rollback facil of specific migrated objects facility For more details on the NDS Migrator tool available from Quest Software, visit the Migrate Novell 21 Directory Services to Active Directory Web page .
Note The information provided here on Quest Software tools is neither a recommendation nor an endorsement for its use within a healthcare organisation If a healthcare organisation wishes to consider these tools for organisation. their Active Directory migration project, careful assessment, planning and testing of the migration must still careful take place.
21
Migrate Novell Directory Services to Active Directory {R21}: http://www.quest.com/nds-migrator Page 26 Active Directory Migration Guide Version 1.0.0.0 Baseline
DEVELOP
During the Develop phase, the solution components are built based on the planning and designs completed during the earlier phases. Further refinement of these components will continue into the stabilisation phase. Figure 9 acts as a high-level checklist, illustrating the sequence of events that the IT Manager and level IT Architect need to determine when planning for an Active Directory migration within a healthcare organisation. This section is split into two distinct areas, each focusing on the server operating systems in use in t the old environment.
Figure 9: Sequence for Developing an Active Directory Migration :
If migrating from a Windows NT Server 4.0 or Active Directory domain, see section 6.1. If migrating from a NetWare environment, see section 6.2.
Recommendation The steps, scripts and processes provided in this section should be thoroughly tested before any large-scale live migrations are performed to ensure they work as expected. scale performed,
6.1
Windows NT 4.0 Domain or Active Directory Migration .0
As detailed within the Plan phase (section 5), the ADMT can be used for either a Windows NT 4.0 lan , or Active Directory domain migration. This section provides the information required to prepare both rmation current and new environments, completing the configuration necessary for password migration and installing the tools needed for a migration to take place.
6.1.1
ADMT Prerequisites equisites

Installation of high encryption software ncryption Creating trust relationships elationships Creating migration accounts Configuring domains for SID history migration Configure the target domain OU structure
There are a number of prerequisites for the migration of accounts and resources migration resources:
6.1.1.1
Installation of High Encryption Softwar Software
High encryption software is required to enable the migration of passwords using the PES service from either a Windows NT Server 4.0 or a Windows 2000 Server domain. Section 5.5.1.2 provides details of the download locations for the High Encryption Packs available. The instructions in Table 5 relate to the installation of the Microsoft Windows 2000 High Encryption Pack on a Windows 2000 Server but can also be used as a guide for installation on a Windows NT Server, 4.0 Server.
Step Description
1. On the Windows 2000 Server, run the downloaded file Encpack_Win2000_En.exe and click Yes in the Microsoft Windows 2000 High Encryption (128-bit) Capability dialog box to start the installation. Read the license agreement, and if applicable, click Yes to accept.
Screenshot
2.
3.
Once the files have finished copying, click Yes to restart the computer, or No if the computer is to be restarted later.
Table 5: Microsoft Windows 2000 High Encryption Pack Installation :
6.1.1.2
Creating Trust Relationships
Trust relationships need to be created between the source and target domains. rget The following instructions in Table 6 provide the steps involved in creating a two two-way trust between a Windows NT 4.0 domain and a new Windows Server 2003 Active Directory environment. These omain instructions require that a name resolution mechanism is in place so that the Windows NT 4.0 place, domain can communicate with the Active Directory domain. If creating a trust relationship between a Windows 2000 Server Active Directory domain and a new Windows Server 2003 Active Directory environment, the steps outlined below only differ slightly and as such can be used as a reference.
Step Description
1. On the Windows NT Server 4.0 computer, click Start on the taskbar and select Programs > Administrative Tools (Common) and open User Manager for Domains. Click the Policies menu and select Trust Relationships.
Screenshot
2.
In the Trust Relationships dialog box, click Add next to the Trusted Domains: box.
3.
In the Add Trusted Domain dialog box, enter the NetBIOS name of the Windows Server 2003 Active Directory domain in the Domain text box and the password that will be used to establish the trust in Password, and click OK. A User Manager for Domains information message displays stating the trust relationship could not be verified. Click OK to continue. In the Trust Relationships dialog box, click Add next to the Trusting Domains: box.
4.
5.
Step Description
6. In the Add Trusting Domain dialog box, enter the NetBIOS name of the Windows Server 2003 Active Directory domain in the Trusting Domain box. Enter the password that will be used to establish the trust in the Initial Password field and the Confirm Password field, and click OK. In the Trust Relationships dialog box, the Windows Server 2003 Active Directory domain will be shown as both a Trusted and Trusting Domain. Click Close.
Screenshot
7.
8.
On the Windows 2003 Server, open Active Directory Domains and Trusts located in Start > Programs > Administrative Tools. Right-click the domain name in the left pane and select Properties.
9.
In the domain Properties dialog box, select the Trusts tab and click New Trust.
Step Description
10. The New Trust Wizard starts. Click Next to continue.
Screenshot
11.
Type the name of the Windows NT 4.0 domain in the Name box and click Next.
12.
Click Two-way as the direction of trust and click Next.
Step Description
13. Click Domain-wide authentication for the outgoing trust authentication level and click Next.
Screenshot
14.
In the Trust password and Confirm trust password boxes, type the password entered in step 3 and click Next.
15.
Click Next in the Trust Selections Complete page.
Step Description
16. Click Next in the Trust Creation Complete page.
Screenshot
17.
Click Yes, confirm the outgoing trust and click Next.
18.
Click Yes, confirm the incoming trust and type the administrative credentials for the Windows NT Server 4.0 domain in the User name and Password boxes, then click Next.
Step Description
19. Once the trust relationships have been confirmed, click Finish, to , complete the New Trust Wizard.
Screenshot
20.
An Active Directory dialog box will display stating security identifier (SID) filtering is enabled. Click OK to close the dialog box.
21.
The newly-created trust relationships will be shown in the domain Properties dialog box. Click OK to close.
Table 6: Creating Trust Relationships
6.1.1.3
Creating a Migration Account
When running the migration, a specific migration account should be created and used, rather than , an IT administrators individual account. This ensures that an IT administrator tasked with a portion of the migration is not granted permissions that would not normally be provided outside of the migration. It also ensures that if the account is used in a script, an individua account credentials individuals are not shared.
Recommendation A healthcare organisation should create a single account in the source domain to simplify administration for the migration of all objects. This account should then be provided domain administrator credentials in the source domain and made a member of the Administrators domain local security group in the target l domain to allow the migration of SID history for user accounts and global groups.
6.1.1.4
Configuring Domains for Security Identifier History Migration
To allow SID history migration, both the source and target domains require config configuration. The following configuration is required: A local group is created in the Windows NT 4.0 domain to allow auditing TCP/IP client support is enabled on the source domain PDC Auditing is enabled in the Windows Server 2003 Active Directory domain Auditing is enabled in the Windows NT 4.0 domain
Recommendation While the configuration listed above can be manually set, ADMT checks for these options the first time it is , run and sets them if not configured It is therefore recommended that healthcare organis configured. organisations allow ADMT to automatically configure these items.
6.1.1.5
Configure the Target Domain O Organisational Unit Structure
Before the migration of objects can take place, the OU structure that will house the objects needs to be created. Detailed information on OUs, specific to healthcare organisations is available within organisations, 22 the Group Policy for Healthcare Desktop Management document.
Recommendation A healthcare organisation should review the recommendations for OUs provided within the Group Policy for Healthcare Desktop Management {R22} document. This will help keep an OU design simple and create a structure that is easy to administer, yet meets the business and technical requirements of the healthcare organisation.
6.1.2
Installing ADMT
The installation of ADMT is a simple process involving only a few steps, which are detailed in Table 7. The installation requires that a Windows Server 2003 server has been built, and as recommended in section 5.5.1.1, ADMT will use the default database installation. 5.5.1.1,
Important If ADMT v2 has been installed, this must first be removed using Add or Remove Programs from within the Control Panel, otherwise the installation will fail. Any database created as part of a previous installation can be imported into ADMT during t installation. the ADMT v3 cannot be installed on Windows Server 2003 64-bit.
22
Group Policy for Healthcare Desktop Management {R22}: http://www.microsoft.com/industry/healthcare/technology/hpo/desktop/grouppolicy.aspx Page 35 Active Directory Migration Guide Version 1.0.0.0 Baseline
Step Description
1. While logged onto the Windows Server 2003 server with administrative credentials, run the downloaded , Admtsetup.exe file to start the Active Directory Migration Tool Installation Wizard. Click Next on the Welcome page page.
Screenshot
2.
Read the license agreement, and if applicable, click I Agree and click Next to continue.
3.
The Microsoft SQL Server Desktop Engine (WMSDE) will install. Note This will install even if using an existing Microsoft SQL Server. If choosing an existing SQL database, ADMT will disable WMSDE.
Step Description
4. As recommended in Section 5.5.1.1 5.5.1.1, click Use Microsoft SQL Server Desktop Edition (Windows) and click Next.
Screenshot
5.
Click No, do not import data from an ADMT v2 database (Default) and click Next.
6.
Click Finish to complete the installation.
Table 7: Active Directory Migration Tool Installation
6.1.3
Enabling Password Migration
To allow the migration of passwords, the PES service requires configuration in the source domain. As part of this process, an encryption key is required, which is created within the target domain using ADMT. To create an encryption key, at the command prompt on the server where ADMT is installed type installed, the following:
C:>admt key /option:create /sourcedomain: admt /sourcedomain:<DomainName> /keyfile:<KeyFilePath KeyFilePath> /keypassword:*
Where: <DomainName> is the name of the source domain <KeyFilePath> is the full path including file name of the encryption key to be created This encryption key file needs to then be made available, either on a removable disk or network share, to the domain controller in the source domain where the PES service will be installed.
Step Description
1. Log on to the Windows Server 2003 server in the target domain. Open a Command Prompt window and type the command to create the encryption key file. When prompted, type the password assword, and type it again to confirm.
Screenshot
2.
Log on to the Windows NT 4.0 domain controller in the source domain. Run the Pwdmig.msi file in the default folder location of %systemroot%\Windows\ADMT\ \PES on the Windows Server 2003 server where ADMT in installed. The ADMT Password Migration DLL Setup installation wizard starts. Click Next to continue. Note The Pwdmig.msi file can be run in e two ways: Connect to the hidden drive share and run the file. Copy the PES folder and run the file locally on the Windows NT Server 4.0 computer.
Step Description
3. Click Browse and locate the encryption key file created in step 1, and click Next.
Screenshot
4.
Type the password supplied during the creation of the encryption key file in step 1 into the Password and Confirm text boxes. Click Next to continue.
5.
Click Next to start the installation.
Step Description
6. Provide the migration account details using the domain\username format in username the Log on as text box and type the e password for this account in the Password and Confirm password text boxes. Click OK to continue.
Screenshot
7.
Click OK to close the information message box.
8.
Click Finish to exit the installation wizard.
9.
Click Yes in the Installer Information dialog box to restart the server to complete the installation of the PES service, or click No to restart the computer later.
Step Description
10. Once the Windows Server 2003 server has restarted, log on with administrative credentials and open the Services window by clicking Start > Control Panel > Services. The Password Export Server Service is set to a Manual Startup mode. Important This service should only be started when a password migration is about to be carried out and should be stopped once the password migration is complete.
Table 8: Password Export Server installation
Screenshot
6.1.4
Configuring ADMT
Once ADMT has been installed the configuration of the source and target domains needs to be installed, completed to enable the migration of SID history. This can be accomplished by running a test migration, which will then prompt to automatically complete the configuration items listed in section 6.1.1.4.
Important This activity needs to be carried out while logged in using the migration account created in section 6.1.1.3.
Step Description
1. On the Windows Server 2003 computer, open the Active Directory Migration Tool located in Start > All Programs > Administrative Tools. Right-click Active Directory Migration Tool and select Group Account Migration Wizard.
Screenshot
Step Description
2. In the Group Account Migration Wizard, click Next to continue.
Screenshot
3.
In the Domain Selection page, select the Domain and Domain Controller for the Source. In the Target section, select the target Domain and Domain Controller. Click Next to continue.
4.
Click Select groups from domain, and click Next.
Step Description
5. In the Group Selection page, click , Add and select some test groups to migrate from the source domain. It is not important which groups are chosen, as this process is for the configuration to take place, not the actual migration. Click Next to continue.
Screenshot
6.
In the Organizational Unit Selection page, enter the OU to be used as the target for the migrated groups in Target OU, or click Browse to locate and select the required OU. Click Next to continue.
7.
In the Group Options page, clear the Fix membership of group check box and select Migrate group SIDs to target domain, as , shown in the screenshot. Click Next to continue.
Step Description
8. At this point, ADMT will check for the appropriate configuration options necessary and offer to enable them, if required. Click Yes to enable auditing on the source domain. 9. Click Yes to enable auditing on the target domain.
Screenshot
10.
Click Yes to create the local group.
11.
Click Yes to add the TcpipClientSupport registry key.
12.
Click Yes to reboot the source domain PDC.
13.
Once the source domain PDC has restarted, click OK to continue.
14.
In the User Account page, supply , the credentials for the migration account (the creation of which was recommended in section 6.1.1.3), and click Next.
Step Description
15. In the Conflict Management page page, ensure Do not migrate source object if a conflict is detected in the target domain is selected and click Next.
Screenshot
16.
Click Finish to complete the wizard and initiate the migration of the groups added in step 5.
17.
The Migration Progress dialog box displays. Click View Log, if required, and click Close to complete the configuration of ADMT.
Table 9: Active Directory Migration Tool Configuration :
Once the steps above have been completed, the configuration of ADMT can be verified by checking that: A local group has been created in the source domain named <DomainName DomainName>$$$, where <DomainName> is the name of the source domain. The TcpipClientSupport registry DWORD entry has been created on the source domain PDC in the HKEY_LOCAL_MACHINE KEY_LOCAL_MACHINE\System\CurrentControlSet\Control Control\LSA subkey, and the value is set to 1. Auditing has been enabled for account management in both the source and target domains.
Information Auditing can be verified on a Windows NT Server 4.0 computer through User Manager for Domains. In Active Directory, auditing can be verified within the Default Domain Controllers Policy accessed through Active Directory Users and Computers or the Group Policy Management Console.
6.1.5
ADMT Option File and Include File
The ADMT option file and include file were introduced in section 5.5.1.1, recommending that a , healthcare organisation uses these two files when running ADMT from a command line. This command section provides an example of both files and an example of the commands that can be run from a command prompt to use them.
6.1.5.1
Option File
The option file provides the options that will be used when running the ADMT command. Different options are available depending on the objects that are to be migrated, for example, users, groups, computers, and so on. The text below is an example options file used to migrate user accounts from a server named ADMIG-NT4 in a test Windows NT 4.0 domain named N NT4 NT4DOMAIN. The target domain is a . Windows Server 2003 Active Directory domain named ADHealthOrg, using a domain controller , named ADMIG-2K3-MS. The users would be migrated to an OU named Knowledge Based Users MS. and have their passwords migrated using the PES service installed on the ADMIG service ADMIG-NT4 server.
[Migration] IntraForest=No SourceDomain="NT4DOMAIN" SourceDomainController="ADMIG-NT4" SourceDomainController="ADMIG ;SourceOu="Source Organisational Unit Name" TargetDomain="ADHealthOrg HealthOrg" TargetDomainController="ADMIG-2K3-MS" TargetDomainController="ADMIG TargetOu="LDAP://adhealthorg healthorg.contoso.com/OU=Knowledge Based Users,OU=Users,OU=Healthcare Organisation Healthcare Organisation,DC=adhealthorg,DC=contoso contoso,DC=com" PasswordOption=Complex PasswordServer="ADMIG-NT4" NT4" ;PasswordFile="Password File Name" ConflictOptions=Ignore ;UserPropertiesToExclude="Property1,Property2,Property3" ;UserPropertiesToExclude="Prop ;InetOrgPersonPropertiesToExclude="Property1,Property2,Property3" ;GroupPropertiesToExclude="Property1,Property2,Property3" ;ComputerPropertiesToExclude="Property1,Property2,Property3"
[User] DisableOption=EnableTarget SourceExpiration=None MigrateSIDs=Yes TranslateRoamingProfile=No UpdateUserRights=No MigrateGroups=No UpdatePreviouslyMigratedObjects=No FixGroupMembership=Yes MigrateServiceAccounts=No UpdateGroupRights=No
The example option file above has a Migration section and a User section. Other sections such as section Group, Computer and Security can all be specified within the same option file. When run, depending upon the command given, ADMT will determine which options are relevant for the migration it is running. For example, if running a user migration, the TranslateRegistry option for a xample, computer will be ignored. For a full list of available options in an example option file, see APPENDIX B.
Note The TargetOU line is wrapped onto the following line in this document but must not be when creating the text file for use during the migration. If a line begins with a semi-colon (;), or an option has not been specified within the option file, ADMT colon r ignores it and uses the default value for that option.
For details of the options available for use with ADMT, type the following at the command prompt:
C:>admt /?
Further help can be displayed on the options for objects that can be migrated. For example, for a d user, type the following at the command prompt prompt:
C:>admt user /?
The user parameter can be substituted with group, computer, security, service or password service to obtain specific help on the options for each of these objects.
Recommendation The service, computer and security objects of an ADMT migration can all use the PreCheckOnly option within the option file. Healthcare organisations should use this to gather information about wh ealthcare whether the migration will be successful or not before the actual migration takes place. Verbose logging should also be enabled to ensure the maximum amount of data is recorded to aid in troubleshooting, if issues occur.
Type the following at the command pro prompt to enable verbose logging:
C:>admt config logging /LogAttributes=Yes admt
6.1.5.2
Include File
As with the option file, the contents of the include file depend upon the objects that are migrated, but all objects follow the same basic syntax The text below is the first few lines of an example syntax. include file used in the test migration above. This include file provides ADMT with the list of users to be migrated with the options file provided above above:
SourceName,TargetName Jesper.Aaberg,Jesper.Aaberg Lene.Aalling,Lene.Aalling ling Syed.Abbas,Syed.Abbas Kim.Abercrombie,Kim.Abercrombie Lina.Abola,Lina.Abola Hazem.Abolrous,Hazem.Abolrous Sam.Abolrous,Sam.Abolrous Luka.Abrus,Luka.Abrus Ahmad.Abu-Dayah,Ahmad.Abu Dayah,Ahmad.Abu-Dayah Humberto.Acevedo,Humberto.Acevedo Gustavo.Achong,Gustavo.Achong Pilar.Ackerman,Pilar.Ackerman ilar.Ackerman,Pilar.Ackerman
The first row (header row) contains the headings SourceName and TargetName separated by a comma. Beneath the header row, each subsequent row contains the name of the user account to . be migrated, once for the source and once for the target. An include file can also be used to rename the objects to be migrated. The example below specifies a new target User Principal Name (UPN) for each user:
SourceName,TargetUPN EAndersen,Elizabeth.Andersen@contoso.com EAndersen,Elizabeth.Andersen ErAndersen,Erik.Andersen@ @contoso.com HAndersen,Henriette.Andersen@contoso.com HAndersen,Henriette.Andersen MAndersen,Mary.Andersen@contoso.com contoso.com TAndersen,Thomas.Andersen@contoso.com TAndersen,Thomas.Andersen NAnderson,Nancy.Anderson@ @contoso.com
The target can also be the TargetRDN which specifies the relative distinguished name or TargetRDN, name, TargetSAM, which specifies the security accounts manager name for the object. All three options can be specified in the header row of a single include file, for example:
SourceName,TargetUPN,TargetSAM,TargetRDN Important The TargetName option in the include file cannot be used with the TargetUPN, TargetSAM or TargetRDN. The TargetUPN option can only be used with user accounts. The TargetRDN option can contain commas, but each comma must be preceded by a back slash ( For (\). example, CN=surname\, firstname The TargetRDN option must include the text CN= , firstname. CN=.
6.1.5.3
ADMT Command Line
If both an option file and an include file are created that contain both the objects to be migrated and how they should be migrated, ADMT can be run from a command prompt to start the migration. , The example below uses an option file named OPTIONS.TXT and an include file name named USERS.TXT to migrate a set of users users:
C:>admt user /O:OPTIONS.TXT /F:USERS.TXT Note If the location of the option file or include file is not in the current working directory, the full path should be on specified. If the path name contains spaces, enclose the full path and file name in double quotation marks ().
6.2
Novell NetWare Migration
This section focuses on migrating from a NetWare environment to a Windows Server 2003 Active migrating Directory environment using SfN. It covers the tasks to complete to prepare the environments for the installation of the tools and synchronisation of objects using MSDSS.
6.2.1
Microsoft SfN Prerequi Prerequisites

Permissions given to the credentials to be used to change the schema for both the Microsoft and Novell environment Installation of the Novell Client for Windows
There are two prerequisites for the migration of accounts and resources when using SfN:
6.2.1.1
Creating a Migration Account reating
When running the migration, a migration account should be created and used, rather than an IT administrators individual account. This ensures that an IT administrator tasked with a portion of the account. migration is not granted permis permissions that would not normally be provided outside of the migration. It also ensures that if the account is used in a script, an individuals account credentials are not shared. The installation of SfN will attempt to extend the Active Directory schema and as such appropriate and, such, credentials are required.
Recommendation A healthcare organisation should create a single account in the target domain for the installation of SfN and the migration of all objects. This account should then be made a member of the foll following security groups: Domain Admins Enterprise Admins Schema Admins Important Due to the permissions gained through these security groups, of which the migration account will be made a member, it is important to ensure that auditing is carried out on this account. Also, once the migration is complete, the migration account must be removed from these security groups.
6.2.1.2
Installing the Novell Client for Windows
The steps in Table 10 provide the details needed to install the Novell Client for Windows on a Windows Server 2003 Active Directory domain controller. The installation steps assume that IPX is in use in the NetWare environment The IPX protocol should only be installed if the NetWare environment. rotocol environment is using it.
Note At the time of writing this document, the latest Novell Client for Windows is version 4.91 SP4. This can be 23 downloaded from the Novell Downloads Web page .
Step Description
1. Log on to the Windows Server 2003 domain controller using the migration account. Run Novell Client 4.91 SP4 English.exe to extract the necessary files to install the software. Setupnw.exe Once extracted, run the Setupnw located, by default, in C:\Novell\Novell Novell Client 4.91 SP4 English. Read the license agreement, and if applicable, click Yes to continue.
Screenshot
2.
Click Custom Installation and click Next.
23
Novell Downloads {R20}: http://download.novell.com/index.jsp Page 50 Active Directory Migration Guide Version 1.0.0.0 Baseline
Step Description
3. Ensure Novell Client for Windows (Required) is selected. Click Next to continue.
Screenshot
4.
Clear any additional products that are selected and click Next.
5.
Click IP and IPX and click Next.
Step Description
6. Click NDS (NetWare 4.x or later) and click Next. Note If migrating from a NetWare 3.x environment, click Bindery (NetWare 3.x).
Screenshot
7.
Click Finish to complete the installation options and start the file copy process.
8.
Once the installation is complete, the Windows Server 2003 domain controller needs to be restarted. Click Reboot to restart the server.
Table 10: Novell Client for Windows Installation nstallation
6.2.2
Installing Microsoft S Services for Netware
This section focuses on the installation of SfN and the instructions below assume SfN has already 24 been downloaded from Microsoft Services for Netware 5.03 SP2 and FPNW on the Microsoft Web site.
Step Description
1. On the Windows Server 2003 computer, run the downloaded SFN 5.03 SP2.MSI file and when the Microsoft Services for NetWare (version 5.03) Setup wizard displays displays, click Next to continue.
Screenshot
2.
Read the license agreement, and if applicable, click I accept the terms in the License Agreement and click Next to continue
24
Microsoft Download Center: Microsoft Services for NetWare 5.03 SP2 and FPNW {R19}:
http://www.microsoft.com/downloads/details.aspx?FamilyID=a819838d-acb2-4794-87eb-82a6a3af4be8&DisplayLang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=a819838d 82a6a3af4be8&DisplayLang=en

Step Description
3. Type a User Name and Organiz Organization into the relevant boxes and click Next. Note The user name specified here is for personalising the software installation and therefore does not need to be a valid domain account.
Screenshot
4.
Click Custom setup type and click Next.
5.
In the Custom Setup page, all features will be installed by default. Click Next lick to continue.
Step Description
6. Click Next to begin the installation.
Screenshot
7.
Click OK to allow the setup process to extend the Active Directory schema.
8.
Click Finish to exit the wizard.
9.
Click Yes to restart the server and complete the installation, or click No to restart the computer later.
Table 11: Microsoft Services for NetWare Installation Page 55 Active Directory Migration Guide Version 1.0.0.0 Baseline
6.2.3
Directory Synchronisation Using MSDSS
Once the Novell Client for Windows and SfN ha been installed, an initial reverse synchronisation have can take place. This is initiated throug the creation of a one-way synchronisation, as through way recommended in section 5.5.2.2, and selecting the option to perform an initial reverse 5.5.2.2, synchronisation. This is detailed in the steps provided in Table 12. iled The steps provided below will synchronise a set of users from a Netware 6.5 NDS environment to an Active Directory domain. If using other NetWare versions, such as 4.x, 5.x or 6.x, the steps to synchronise are similar and, therefore, Table 12 can be used as a reference. These steps can be used as a reference for configuring multiple synchronisations for varying ed objects in the old environment. Once all the objects have been synchronised between the two environments, the NDS or Bindery servers can be decommissioned because Active Directory take takes over the provision of user access to the required resources resources.
Step Description
1. On the Windows Server 2003 computer, select Start > All Programs > Administrative Tools > Directory Synchronization to open MSDSS. Right-click MSDSS (<DomainName>) and select New Session.
Screenshot
2.
The New Session Wizard starts. Click Next to continue.
Step Description
3. Choose Novell Directory Services (NDS) from the Select NDS or Bindery drop-down and down click One-way synchronization way (from Active Directory to NDS or Bindery). Click Next to continue.
Screenshot
4.
Type the name of the Active Directory container in the relevant text box, or click Browse to locate and select the container container. Ensure the Domain Controller box is populated with the server name currently in use. Click Next to continue.
5.
Type the name of the NDS container in the relevant text box box, or click Browse to locate and select the container. Type the User name and Password of the Novell administrator account to be used for the synchronisation in the relevant boxes. Click Next to continue.
Step Description
6. In the Initial Reverse Synchronization page, ensure the , Run this session when I close this wizard check box is selected and click Perform an initial reverse synchronization. Click Password Options.
Screenshot
7.
The Password Synchronization Options dialog box displays. By default, the Set passwords to a random value option is selected. Click OK to continue. Click Next when the Initial Reverse Synchronization screen displays again.
8.
In the Object Mapping Scheme page, click Default in the Object Mapping section and click Next. Note If the synchronised objects will reside in directory structures that are not identical, the Custom Object Mapping option must be selected and an Object Mapping Table needs to be used to map Active Directory objects to corresponding NDS objects. Filters can also be used to exclude specific objects such as administrative accounts when synchronising between environments.
Step Description
9. To identify this synchronisation session in the MSDSS window, type a Session Name, or accept the default name, and click Next Next.
Screenshot
10.
Click Finish to complete the wizard and start the synchronisation.
11.
The Synchronize dialog box opens and displays the progress of the synchronisation. Click OK to close the dialog box. Note To open the MSDSS Event Viewer, click the View Logs button.
Table 12: Directory Synchronisation Using MSDSS : Page 59 Active Directory Migration Guide Version 1.0.0.0 Baseline
Once the synchronisation session has been created, it is displayed in the MSDSS window. The session can then be managed Right-click the session name to select a number of tasks such as managed. as: View Logs Opens the MSDSS Event viewer pens Clone Session Runs the New Session Wizard and pre populates the field values with uns pre-populates those used in the selected session Synchronize Changes - Forward Forces a forward synchronisation Update Status Refreshes the status shown in the MSDSS window efreshes Disable Session Pauses the synchronisation of objects within the selected session auses Properties Displays the session properties, such as synchronisation schedule, Novell credentials used, level of detail logged, and password options
6.2.4
Password Synchronisation Using MSDSS
As part of the synchronisation session created using the New Session Wizard, a dialog box is provided to choose how passwords will be handled when users are first synchronised to Active w Directory. During the steps detailed in section 6.2.3, the Set passwords to a random value option et was selected. Selecting this option creates a random password for each user synchronised to Active Directory during the initial reverse synchronisation. The passwords generated are stored in a text file that can be opened using Notepad by members of the Administrators and MSDSS Admins group. The file of location is written to the MSDSS event log, with an event identification of 0 (zero). The dialog box shown in Figure 10 provides the name and path of the file containing users and their password passwords:
Figure 10: MSDSS Event Properties Displaying Password File Location
Once the initial reverse synchronisation has completed, all users logging onto the Active Directory onto domain for the first time must change their passwords. When a password change occurs in Active Directory, MSDSS initiates a forward synchronisation. Any password changes made within Active Directory overwrite the existing NDS passwor passwords. If a password is changed in NDS, it is not synchronised to Active Directory and will therefore cause the user to have to enter two different passwords when trying to access resources on the different environments. If this occurs, the user can initiate a password change within Active Directory to . rectify the situation.
STABILISE
The Stabilise phase involves testing the solution components whose features are complete, and resolving and prioritising any issues that are found. Testing during this phase emphasises usage and operation of the solution components under realistic environmental conditions. This involves testing and acceptance of the Active Directory migration solution. Figure 11 acts as a high-level check level checklist, illustrating the critical components that an IT professional responsible for stabilising the Active Directory migration needs to determine.
Figure 11: Sequence for Stabilising an Active Directory Migration ing
7.1
Migration Test Process
The migration test process is the part of the Active Directory migration solution that needs to verify that the migration will be successful. It should also include the process of testing the rollbac plan rollback to be implemented if issues are encountered that are deemed too serious to continue with the migration. Also, the scripts and processes developed for the migration should be thoroughly tested before any large-scale live migrations are performed to ensure they work as expected. scale performed,
7.1.1
Pilot
As part of the pilot, all aspects of the migration solution will be carried out on a selected number of users. These users will be expected to carry out their day . day-to-day activities as normal but with the day normal, additional responsibility of feeding back any issues regarding access to resources that were available prior to the migration. The typical basic steps involved in a pilot include: Identifying the pilot users, their computers and the data to which they require continued access Migrating or synchronis synchronising these user accounts, including group membership and login scripts Migrating computer accounts to Active Directory, including the removal of any Novell Client for Windows in a NetWare environment Migrating data and other resources that are part of the migration but that do not interfere with other production environment users. This includes maintaining access to shared data and server-based applications for the pilot users based During the pilot, focus on the following areas: Check that all the users and their permissions to files and folders were migrated as expected
Note the time taken to perform migration for the number of users taking part in the pilot Note the network bandwidth used during migration and ensure that other live users are not affected Once the pilot has been completed document the findings and rework the migration processes as completed, necessary.
7.2
Reviewing Log Files
Whether migrating from a Windows or Novell environment, log files are crucial c components in ensuring a successful migration. ADMT utilises log files stored in the ADMT database while SfN utilises the MSDSS Event Log to provide feedback on the status of tasks being carried out.
7.2.1
Microsoft Migration Logs
ADMT keeps a detailed log of the actions that it performs when migrating resources between Windows NT 4.0 and Active Directory domains. Whilst errors that occur during the migration process are written to the migration log, they may not produce a warning message in ADMT. Examine the migration log after a migration is complete to verify that all tasks were completed ation successfully.
Important As it is important to complete the steps of the migration in the order specified in this document check the document, migration log after each step, s that any failures discovered can be fixed. so
The log files can be viewed from within the ADMT console, or by running ADMT at the command prompt using the task parameter.
7.2.2
Novell Migration Logs
The logs relating to MSDSS can be accessed through the MSDSS Event Viewer. To open the MSDSS Event Viewer, right-click any item in the left pane of the MSDSS window and select View click Logs. Figure 12 shows the events logged during a number of migration tasks tasks:
Figure 12: MSDSS Event Log
APPENDIX A
SKILLS AND TRAINING RESOURCES
The tables in this Appendix provide details of the suggested training and skill assessment resources available. This list is not exhaustive; there are many third party providers of such skills. third-party The resources listed are those provided by Microsoft Microsoft.
PART I
Microsoft Active Directory 2003

Resource Location Description
For further information on Active Directory see http://www.microsoft.com/activedirectory Directory,
Skill or Technology Area
Active Directory Design, including http://technet2.microsoft.com/WindowsServer/en/Libr Links to sections on designing Active DNS design ary/c283b699-6124-4c3a-87efary/c283b699 Directory 865443d7ea4b1033.mspx OU design As above As above
Table 13: Microsoft Active Directory 2003 Skills and Training Resources :
PART II
Active Directory Migration
For further information on Active Directory migration, see http://technet.microsoft.com/en http://technet.microsoft.com/enus/interopmigration/bb380225.aspx
Skill or Technology Area

Upgrading from Windows NT Server 4.0 to Windows Server 2003 Upgrading from Windows 2000 Server to Windows Server 2003
Resource Location
http://www.microsoft.com/windowsserver2003/upgra ding/nt4/default.mspx http://www.microsoft.com/windowsserver2003/upgra ding/w2k/default.mspx
Description
Links to various resources on migrating from Windows NT 4.0 Links to various resources on migrating from Windows 2000 Server Active Directory Links to various resources on migrating from Novell NetWare NDS or Bindery
Resources for Interoperability and http://technet.microsoft.com/en http://technet.microsoft.com/enMigration of NetWare and us/interopmigration/bb380216.aspx Windows
Table 14: Active Directory Migration Skills and Training Resources :
APPENDIX B
ADMT SAMPLE OPTION FILE
The text below represents an example option file including all the available options that can b be specified for the migration of users, groups, computers, security and service accounts accounts.
[Migration] IntraForest=No SourceDomain="NT4DOMAIN" SourceDomainController="ADMIG-NT4" SourceDomainController="ADMIG ;SourceOu="Source Organisational Unit Name" TargetDomain="ADANYTRUST" TargetDomainController="ADMIG-2K3-MS" TargetDomainController="ADMIG TargetOu="LDAP://adhealthorg healthorg.contoso.com/OU=Knowledge Based Users,OU=Users,OU=Healthcare Organisation Healthcare Organisation,DC=adhealthorg,DC=contoso contoso,DC=com" PasswordOption=Complex PasswordServer="ADMIG-NT4" NT4" ;PasswordFile="Password File Nam Name" ConflictOptions=Ignore ;UserPropertiesToExclude="Property1,Property2,Property3" ;InetOrgPersonPropertiesToExclude="Property1,Property2,Property3" ;GroupPropertiesToExclude="Property1,Property2,Property3" ;ComputerPropertiesToExclude="Property1,Property2,Property3" ;ComputerPropertiesToExclude="Property1,Property2
[User] DisableOption=EnableTarget SourceExpiration=None MigrateSIDs=Yes TranslateRoamingProfile=No UpdateUserRights=No MigrateGroups=No UpdatePreviouslyMigratedObjects=No FixGroupMembership=Yes MigrateServiceAccounts=No UpdateGroupRights=No
[Group] UpdateGroupRights=No FixGroupMembership=Yes MigrateSIDs=Yes MigrateMembers=No UpdatePreviouslyMigratedObjects=No DisableOption=EnableTarget SourceExpiration=None

[Computer] PreCheckOnly=No TranslationOption=Replace TranslateFilesAndFolders=No TranslateLocalGroups=No TranslatePrinters=No TranslateRegistry=No TranslateShares=No TranslateUserProfiles=No TranslateUserRights=No RestartDelay=5 AutoPreCheckRetry=No AutoPreCheckRetryInterval=30 AutoPreCheckRetryNumber=48 AutoPostCheckRetry=No AutoPostCheckRetryInterval=5 heckRetryInterval=5 AutoPostCheckRetryNumber=2
[Security] PreCheckOnly=No TranslationOption=Replace TranslateFilesAndFolders=No TranslateLocalGroups=No TranslatePrinters=No TranslateRegistry=No TranslateShares=No TranslateUserProfiles=No TranslateUserRights=No SIDMappingFile=SID Mapping File Path AutoPreCheckRetry=No AutoPreCheckRetryInterval=30 AutoPreCheckRetryNumber=48
[Service] PreCheckOnly=No AutoPreCheckRetry=No AutoPreCheckRetryInterval=30 AutoPreCheckRetryNumber=48
APPENDIX C
PART I
Abbreviation
ACL ADMT BDC CN CSNW DNS FMU FPNW GPO IP IPX IT LAN MOF MSDSS MSF NAT NDS NTLM OU PDC PES RDN SAM SfN SID SP TCP/IP UPN WAN WMSDE
Table 15: Terms and Abbreviations
DOCUMENT INFORMATION
Terms and Abbreviations

Definition
Access Control List Active Directory Migration Tool Backup Domain Controller Common Name Client Service for NetWare Domain Name System File Migration Utility File and Print Services for NetWare Group Policy object Internet Protocol Internetwork Packet Exchange Information Technology Local Area Network Microsoft Operations Framework Microsoft Directory Synchronisation Services Microsoft Solutions Framework Network Address Translation NetWare Directory Service NT LAN Manager Organisational Unit Primary Domain Controller Password Export Server Relative Distinguished Name Security Accounts Manager Service for NetWare Security Identifier Service Pack Transport Core Protocol/Internet Protocol User Principal Name Wide Area Network Microsoft SQL Server 2000 Desktop Engine
PART II
References
Version
1.0.0.0
Reference Document
R1. R2. Active Directory Design Guide Guide: http://www.microsoft.com/industry/healthcare/technology/hpo/security/activedirectory.aspx Microsoft Download Center: Microsoft Solutions Framework Core Whitepapers: http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b-ac05-42a6-bab8http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b fc886956790e&DisplayLang=en Microsoft TechNet: Microsoft Operations Framework MOF Executive Overview: Framework: http://www.microsoft.com/technet/itsolutions/cits/mo/mof/mofeo.mspx Microsoft Download Center: Migrating Windows NT Server 4.0 Domains to Windows Server 2003 2003: http://www.microsoft.com/downloads/details.aspx?familyid=E92CF6A0-76F0-4E25-8DE0http://www.microsoft.com/downloads/details 19544062A6E6&displaylang=en Microsoft TechNet: Windows Server TechCenter: Designing and Deploying Directory and Security Services: http://technet2.microsoft.com/windowsserver/en/library/d2ff1315-1712-48e4-acdchttp://technet2.microsoft.com/windowsserver/en/library/d2ff1315 8cae1b593eb11033.mspx Microsoft Download Center ADMT v3 Migration Guide: Center: http://www.microsoft.com/downloads/details.aspx?familyid=D99EF770-3BBB-4B9E-A8BChttp://www.microsoft.com/downloads/details.aspx?familyid=D99EF770 01E9F7EF7342&displaylang=en Microsoft Windows Server 2003 R2: NetWare to Windows Server 2003 Migration Planning Guide rosoft Guide: Migrating Novell NetWare to Windows Server 2003 Microsoft Word document (SFNmig.doc): http://www.microsoft.com/windowsserver2003/techinfo/overview/sfnmig.mspx Microsoft Download Center: Solution for Migrating File, Print, and Directory Services from Novell NetWare to Windows Server 2003 Microsoft Word document: 2003: http://go.microsoft.com/fwlink/?LinkID=46606 Microsoft TechNet: Solution for Migrating File, Print, and Directory Services from Novell NetWare to Windows Server 2003: http://technet.microsoft.com/en-gb/library/bb496964.aspx http://technet.microsoft.com/en Microsoft Windows Server 2003 R2: Services for NetWare 5.03 White Paper: http://www.microsoft.com/windowsserver2003/techinfo/overview/sfn503wp.mspx Microsoft TechNet: Microsoft Windows Server TechCenter: Using Run as: http://technet2.microsoft.com/windowsserver/en/library/8782f8ab-9538-4111-8a68http://technet2.microsoft.com/windowsserver/en/library/8782f8ab 7bfd130c21c01033.mspx?mfr=true Microsoft Download Center: Print Migrator Tool 3.1: nter: http://download.microsoft.com/download/4/5/2/452d431e-5a5c-43bd-b398-6fc27208e001/printmig.exe http://download.microsoft.com/download/4/5/2/452d431e 6fc27208e001/printmig.exe Microsoft Download Center: Microsoft Print Migrator 3.1: http://download.microsoft.com/download/2/e/5/2e57d536-2bb5-40f1-b52dhttp://download.microsoft.com/download/2/e/5/2e57d536 a11f5aae2e22/Microsoft%20Print%20Migrator%203.1.doc Microsoft TechNet: Microsoft Windows Server TechCenter: Client Service for NetWare: http://technet2.microsoft.com/windowsserver/en/library/eda1cc2b-c3cc-4845-add0http://technet2.microsoft.com/windowsserver/en/library/eda1cc2b 503439f6d1271033.mspx?mfr=true Microsoft Download Center: Active Directory Migration Tool v3.0: http://www.microsoft.com/downloads/details.aspx?FamilyID=6f86937b-533a-466d-a8e8http://www.microsoft.com/downloads/details.aspx?FamilyID=6f86937b aff85ad3d212&DisplayLang=en Microsoft Download Center: Windows 2000 High Encryption Pack (128 (128-bit): http://www.microsoft.com/downloads/details.aspx?FamilyID=C10925A0-AC66-4C44-B5C3 http://www.microsoft.com/downloads/details.aspx?FamilyID=C10925A0 B5C39DCAB4DA1C63&displaylang=en
R3. R4.
R5.
R6.
R7.
R8.
R9.
R10. R11.
R12. R13.
R14.
R15.
R16.
Reference Document
R17. R18. R19. Microsoft Download Center: Internet Explorer High Encryption Pack 4.0 4.0: http://go.microsoft.com/fwlink/?LinkId=76038 Quest Software, Migration Tools for Active Directory: http://www.quest.com/active-directory/migration.aspx http://www.quest.com/active Microsoft Download Center: Microsoft Services for NetWare 5.03 SP2 and FPNW: http://www.microsoft.com/downloads/details.aspx?FamilyID=a819838d-acb2-4794-87ebhttp://www.microsoft.com/downloads/details.aspx?FamilyID=a819838d 82a6a3af4be8&DisplayLang=en Novell Downloads: Novel Client for Windows: Novell http://download.novell.com/index.jsp Quest Software, Migrate Novell Directory Services to Active Directory Directory: http://www.quest.com/nds-migrator http://www.quest.com/nds Group Policy for Healthcare Desktop Management: http://www.microsoft.com/industry/healthcare/technology/hpo/desktop/grouppolicy.aspx
Version
R20. R21. R22.
1.0.0.0
Table 16: References

Active Directory Migration Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Active Directory Migration Guide

Uploaded by

Copyright:

Available Formats

Active Directory

Prepared by Microsoft Version 1.0.0.0 Baseline

First published 17 March 2008

Page ii Active Directory Migration Guide Version 1.0.0.0 Baseline

2.2.1 2.2.2 2.3 2.4 2.5 3

4.2.1 4.2.2 4.2.3 4.3 5

End State Environment ................................................................................................ ............................................. 9

5.1.1 5.1.2 5.2 5.3

5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.4

5.4.1 5.4.2 5.5

Page iii Active Directory Migration Guide Version 1.0.0.0 Baseline

6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.2

6.2.1 6.2.2 6.2.3 6.2.4 7

APPENDIX A PART I PART II APPENDIX B APPENDIX C PART I PART II

Page iv Active Directory Migration Guide Version 1.0.0.0 Baseline

Skills and Knowledge

Page 2 Active Directory Migration Guide Version 1.0.0.0 Baseline

Training and Assessment

IT Architect IT Professional/ Administrator

Table 1: Document Audience

Page 3 Active Directory Migration Guide Version 1.0.0.0 Baseline

USING THIS DOCUMENT

Figure 1: MSF Process Model Phases and Document Structure :

Microsoft Solutions Framework Core Whitepapers {R2}: http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b-ac05-42a6-bab8-fc886956790e&DisplayLang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b fc886956790e&DisplayLang=en

Active Directory Overview

Initial State Environment

Public Domain Active Directory Migration Guidance

Microsoft Healthcare Platform Optimisation Active Directory Migration Guidance

End State Environment

Microsoft Windows NT 4.0

Microsoft Windows 2000/2003 Active Directory

Figure 2: Sequence for Envisioning an Active Directory Migration

Active Directory Overview

Initial State Environment

Page 5 Active Directory Migration Guide Version 1.0.0.0 Baseline

Public Domain Active Directory Migration Guidance

Microsoft Healthcare Platform Optimisation Active Directory Migration Guidance

ADMT v3 Migration Guide {R6}: http://www.microsoft.com/downloads/details.aspx?familyid=D99EF770 .microsoft.com/downloads/details.aspx?familyid=D99EF770-3BBB-4B9E-A8BC-01E9F7EF7342&displaylang=en 01E9F7EF7342&displaylang=en

Microsoft Windows NT Server 4.0

Figure 3: Microsoft Windows NT 4.0 Domain S Scenario

Page 7 Active Directory Migration Guide Version 1.0.0.0 Baseline

Figure 4 represents the implementation of an Active Directory directory service:

Figure 4: Microsoft Windows 2000/2003 Active Directory Scenario :

Page 8 Active Directory Migration Guide Version 1.0.0.0 Baseline

Figure 5: Novell NetWare Scenario

End State Environment

Page 9 Active Directory Migration Guide Version 1.0.0.0 Baseline

Figure 6: Sequence for Planning an Active Directory Migration

Page 10 Active Directory Migration Guide Version 1.0.0.0 Baseline

New Active Directory or In ew In-Place (Upgrade) Migration )

Page 11 Active Directory Migration Guide Version 1.0.0.0 Baseline

Direct or Phased Migration

Evaluating the Existing Environment

Network stored information Server operating systems dependent software

Page 12 Active Directory Migration Guide Version 1.0.0.0 Baseline

Page 13 Active Directory Migration Guide Version 1.0.0.0 Baseline

Page 15 Active Directory Migration Guide Version 1.0.0.0 Baseline

Page 16 Active Directory Migration Guide Version 1.0.0.0 Baseline

Print Migrator Tool 3.1 {R12}: http://download.microsoft.com/download/4/5/2/452d431e-5a5c-43bd-b398-6fc27208e001/printmig.exe http://download.microsoft.com/download/4/5/2/452d431e 6fc27208e001/printmig.exe

Microsoft Print Migrator 3.1 {R13}: http://download.microsoft.com/download/2/e/5/2e57d536 2bb5-40f1-b52dhttp://download.microsoft.com/download/2/e/5/2e57d536-2bb5 a11f5aae2e22/Microsoft%20Print%20Migrator%203.1.doc

Migration Tools Available

Migrating from Microsoft Operating Systems

Page 18 Active Directory Migration Guide Version 1.0.0.0 Baseline

Active Directory Migration Tool