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 England.
Engl 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 exercise
exer
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
registered trademarks or trademarks of Microsoft
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-mail

e addresses, logos,s, people, places, and events depicted herein are fictitious. No
association with any real company, organisation, product, domain name, e-mail
e mail address, logo, person, places, or events is intended or should be inferred.
Page ii
Active Directory Migration Guide
TABLE OF CONTENTS
1 Executive Summary ................................................................................................
................................ ....................................................... 1
2 Introduction ................................................................................................................................
................................ .................................... 2
2.1 Value Proposition................................................................................................
................................ ...................................................... 2
2.2 Knowledge Prerequisites ................................................................................................
.......................................... 2
2.2.1 Skills and Knowledge ................................................................................................
.......................................... 2
2.2.2 Training and Assessment ................................................................................................
.................................... 3
2.3 Infrastructure Prerequisites ................................................................................................
...................................... 3
2.4 Audience ................................................................................................................................
................................ ................................... 3
2.5 Assumptions ................................................................................................
................................ ............................................................. 3
3 Using This Document ................................................................................................

................................ .................................................... 4
3.1 Document Structure ................................................................................................
................................ .................................................. 4
4 Envision ................................................................................................................................
................................ .......................................... 5
4.1 Active Directory Overview ................................................................................................
........................................ 5
4.2 Initial State Environment ................................................................................................
........................................... 5
4.2.1 Public Domain Active Directory Migration Guidance ..........................................................
................................ 6
4.2.2 Microsoft Healthcare Platform Optimisation Active Directory Migration Guidance
Gu ............. 6
4.2.3 Technology Scenarios ................................................................................................
......................................... 7
4.3 End State Environment ................................................................................................
............................................. 9
5 Plan ................................................................
................................................................................................
............................................... 10
5.1 Migration Type ................................................................................................
................................ ........................................................ 10
5.1.1 New Active Directory or In-Place
In (Upgrade) Migration .....................................................
................................ 11
5.1.2 Direct or Phased Migration ................................................................................................
................................ 12
5.2 Evaluating the Existing Environment ................................................................
...................................................... 12
5.3 Scope of Migration ................................................................................................
................................ .................................................. 13
5.3.1 Users ................................................................................................................................
................................ ................................. 14
5.3.2 Groups ...............................................................................................................................
................................ ............................... 15
5.3.3 Computers ................................................................................................
................................ ......................................................... 15
5.3.4 Printers ..............................................................................................................................
................................ .............................. 17
5.3.5 Data ................................................................................................................................
................................ ................................... 17
5.3.6 Login Scripts ................................................................................................
................................ ...................................................... 17
5.4 Migration Process ................................................................................................
................................ ................................................... 18
5.4.1 Manual Migration ................................................................................................
................................ ............................................... 18
5.4.2 Automated Migration ................................................................................................
......................................... 18
5.5 Migration Tools Available ................................................................................................
....................................... 18
5.5.1 Migrating from Microsoft Operating Systems ................................................................
.................................... 18
5.5.2 Migrating from Novell NetWare Operating Systems .........................................................
................................ 22
Page iii
6 Develop ................................................................................................................................
................................ ......................................... 27
6.1 Windows NT 4.0 Domain or Active Directory Migration .........................................................
................................ 27
6.1.1 ADMT Prerequisites ................................................................................................
.......................................... 27
6.1.2 Installing ADMT ................................................................................................
................................ ................................................. 35
6.1.3 Enabling Password Migration................................................................
............................................................ 38
6.1.4 Configuring ADMT ................................................................................................
................................ ............................................. 41
6.1.5 ADMT Option File and Include File ................................................................
................................................... 46
6.2 Novell NetWare Migration ................................................................................................
....................................... 49
6.2.1 Microsoft SfN Prerequisites ...............................................................................................
............................... 49
6.2.2 Installing Microsoft Services for Netware ................................................................
.......................................... 53
6.2.3 Directory Synchronisation Using MSDSS ................................................................
......................................... 56
6.2.4 Password Synchronisation Using MSDSS ................................................................
........................................ 60
7 Stabilise ................................................................................................................................
................................ ........................................ 61
7.1 Migration Test Process ................................................................................................
........................................... 61
7.1.1 Pilot ................................................................................................................................
................................ ................................... 61
7.2 Reviewing Log Files................................
................................................................................................
................................................ 62
7.2.1 Microsoft
crosoft Migration Logs ................................................................................................
................................... 62
7.2.2 Novell Migration Logs ................................................................................................
........................................ 62
APPENDIX A Skills and Training Resources................................................................

................................................. 63
PART I Microsoft Active Directory 2003 ................................................................
........................................................ 63
PART II Active Directory Migration ................................................................
............................................................. 63
APPENDIX B ADMT Sample Option File ................................................................

........................................................ 64
APPENDIX C Document Information ..............................................................................................

.............................. 66
PART I Terms and Abbreviations ................................................................................................
.................................. 66
PART II References ................................................................................................
................................ .................................................... 67
Page iv
1 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,
organisation and help
bring about a reduction in diversity of server operating systems.
1
The Active Directory Design Guide provides a healthcare organisation with the information
required to design a new Active Directory infrastructure. This document (Active
Active Directory Migration
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 Server
Se 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
2 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 migrated
migr across.
This document is a component of the strategic Microsoft infrastructure guidance provided through
Microsoft Healthcare Platform Optimisation.
Optimisation. It provides current best practice guidance, sample
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,
ion, and the tools and utilities that can be used.
used The guidance is designed to:
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-based
knowledge
and environmental infrastructure prerequisites should be in place.
place This section outlines the
t required
knowledge and skills to use the Active Directory Migration Guide,
Guide, and provides suggested training
and skill assessment resources to make the most of this guidance. The necessary infrastructure
prerequisites are detailed in section
se 2.3.
2.2.1 Skills and Knowledge

The technical knowledge and minimum skills required to use the Deliverable are:
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 (ifif migrating from this environment):
environment
Administrative knowledge for maintaining users and computers
®
NDS or Bindery (ifif migrating from a Novell environment):
NDS or Bindery object properties for mapping to Active Directory
Migration Tools:
Active Directory Migration Tool,
Tool, if migrating from a Microsoft environment
Microsoft Services for NetWare,
NetWare if migrating from a Novell environment
Page 2
2.2.2 Training and Assessment

Guidelines on the basic skill sets
set required to make best use of this Deliverable are detailed in
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
ive Directory Migration Guide within a healthcare
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
dance contained in this document is targeted at a variety of roles within the healthcare IT
organisations. Table 1 provides a reading guide for this document, illustrating
illustrating the roles and the
sections of the document that are likely to be of most interest. The structure of these
the sections is
described in section 3.1.
Executive
Summary
Envision
Stabilise
Develop
Operate
Role Document Usage
Plan
IT Manager Review the relevant areas within the document to
understand the justification and drivers, and to develop an
understanding of the implementation requirements
IT Architect Review the relevant areas within the document against

local architecture strategy and implementation plans
IT Professional/ Detailed review and implementation of the guidance to

Administrator meet local requirements
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 IP) Addressing
schemes to enable
nable successful site-to-site
site communication (that
that is, unique IP Addressing schemes
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
site communication to function successfully. The use of NAT (Network
Address Translation) within an Active Directory environment is neither recommended nor supported
by Microsoft.
Page 3
3 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.
Directory. The document should be used to assist with the
planning and implementation of a migration solution and as a reference guide for the most common
tasks involved.
3.1 Document Structure

This document contains four sections that deal with the project lifecycle, as illustrated in Figure 1:
Envision
Plan
Develop
Stabilise
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
cribed in more detail in the Microsoft Solutions Framework Core White Papers and
3
the MOF Executive Overview . The MSF Process Model and MOF describe a high-levelhigh sequence
of activities for building, deploying and managing IT solutions. Rather than prescribing
prescri 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
2
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
4 ENVISION
The Envision phase addresses one of the most fundamental
fundamental requirements for success in any
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
all goals and constraints, will serve as an early form of planning,
planning and sets
the stage for the more formal planning process that will take place during the planning phase.
Figure 2 acts as a high-level
level checklist, illustrating the sequence of events that should be
undertaken when envisioning an Active Directory migration within a healthcare organisation:
organisation
Active Directory
Overview
Microsoft Healthcare
Public Domain
Initial State Platform Optimisation
Active Directory
Environment Active Directory
Migration Guidance
Migration Guidance
End State
Environment
Microsoft Windows
Technology Microsoft Windows NT
2000/2003 Active Novell Netware
Scenarios 4.0
Directory
Figure 2: Sequence for Envisioning an Active Directory Migration
4.1 Active Directory Overview

Active Directory is the network-focused
network focused directory service included in the Windows 2000 Server and
Windows Server 2003 operating systems. Active Directory provides an extensible
extensibl and scalable
service that enables network authentication, administration and management of directory services
to an organisation running a Windows-based
Windows 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
specific guidance to reduce the complexity of planning a migration to Active
Directory within a healthcare organisation,
organisation, thereby reducing the support and management
requirements for the migration.
migration. The provision of a standardised design approach, including key
design recommendations, will reduce the time and effort
effort required to design and migrate users and
computers to Active Directory within the healthcare organisation.
Page 5
4.2.1 Public Domain Active Directory Migration Guidance

The Internet hosts many Web sites, documents and guidance that provide assistance in
understanding
nding the various aspects involved in a migration.
migration. This information can be hard to
navigate, and can contain inconsistencies or out-of-date
date information. This document seeks to
provide accurate and current best practice guidance,
guidance much of which is based on a number of
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:
4
Migrating from Windows NT Server 4.0 to Windows Server 2003 Active
Active Directory , which
provides information on migration methods and Active Directory considerations
5
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
6
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
7
Migrating Novell NetWare to Windows Server
S 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:
8
To download the Word document, visit the Download Center
9
To view the information online, visit the Technet Library
10
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
4
Migrating from Windows
ows NT Server 4.0 to Windows Server 2003 {R4}:
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
ilable for download from Solution for Migrating File, Print, and Directory Services from Novell
NetWare to Windows Server 2003 {R8
R8}: http://go.microsoft.com/fwlink/?LinkID=46606
9
Solution for Migrating File, Print, and Directory Services from Novell NetWare to Windows
Windows Server 2003 {R9}:
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
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,
dated, organised and structured reference list to the documents listed in section
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,
available when migrating to
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.
Directory. There are three scenarios covered by this guidance,
guidance to
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-way
two trust
relationship between them:
Figure 3: Microsoft Windows NT 4.0 Domain Scenario

S
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.
Page 7
Figure 3 could, for example, represent a centralised account domain where both user and
computer accounts reside,, with resource domains distributed throughout the remote
rem sites. In turn,
these
hese resource domains then trust the account domain with a one-way
one way trust; however,
however it is also
common to find that a two-way
way trust is used.
Whether there are only a few Windows NT 4.0 domains or over 100, 100 with a complicated
implementation
on of trust relationships between them, the migration of user and computer accounts
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 ng Active Directory forest to a current best practice Active Directory
environment is included in this guidance.
guidance Migration information is provided from both a Windows
2000 Server domain or forest and a Windows Server 2003 domain or forest.. The purpose of
including
ncluding a migration of this type is for those healthcare organisations that have Active Directory
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
bjects from one or more Active Directory domains to the new Active Directory
domain.
Page 8
4.2.3.3 Novell NetWare

Figure 5 represents the implementation of a Novell NetWare-based
NetWare authentication
uthentication mechanism for
the healthcare organisation’ss users and computers:
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 focuses
focus on these NetWare versions, it is still possible to use this
™
guidance if migrating from an implementation of a Novell eDirectory environment or a Novell
NetWare 3.x environment (that
that uses binderies to store user accounts and other resource
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 g complex design and implementation decisions to migrate to an
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
m to consider local
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,
organisation aiding in the supportability of the healthcare organisations’
organisations
directory services.
Page 9
5 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.
level checklist, illustrating the sequence of events that the IT Manager and
IT Architect need to determine when planning for an Active Directoryory migration solution within a
healthcare organisation:
Figure 6: Sequence for Planning an Active Directory Migration
5.1 Migration Type

The initial decisions
ecisions to be made as part of a migration project are to first ascertain how to create the
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
he current environment may determine the way in which the environment is built:
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-place
in migration to Windows Server 2003
and the new Active Directory environment
Page 10
If a healthcare organisation currently uses Novell NetWare, or has an Active Directory

environment that does not meet the needs of the healthcare organisation,
organisation a new Active
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, typically
typi 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
ew Active Directory or In-Place
In (Upgrade)) Migration
The decision on whether a new Active Directory environment is created from a fresh installation
i or
an in-place migration should consider some basic advantages and disadvantages as detailed
below.
Important
The in-place
place migration approach is not available to healthcare organisations that are looking to migrate to
Active Directory from Novell NetWare;
NetWare therefore, they must use the new Active Directory method.
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
ronment to remain in place,
place which
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 their
the computer accounts migrated through a manual
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
tion Tool (ADMT) or the Microsoft Directory Synchronization Services
(MSDSS) utility.
It is important to also consider the hardware requirements for the in-place
in place migration approach. If a
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 Backupkup Domain Controller (BDC) on a new server that
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,
2003 retaining the user and computer
objects.
Caution
If a new server is to be purchased to install Windows NT 4.0 and subsequently upgraded
upgrade to Windows
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 R1} to aid in the
designing of the new Active Directory.
Page 11
5.1.2 Direct or Phased Migration

Once the decision has been made on how to implement the new Active Directory environment,
env 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-time
one migration.
ation. This approach should only be used
where any earlier systems, such as a Windows NT 4.0 PDC or BDC, or a NetWare server, are no
longer required (as
as all applications have been replaced or relocated away from these servers).
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 thathat have already been
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,
rollback should issues occur, as well as reducing the risk involved in a direct
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
Windows based environment, this can occur
through the use of external trust relationships,
relationships whereas in a Novell environment,
environment this involves using
tools to synchronise directory information.
5.2 Evaluating the Existing Environment

The aim of evaluating the existing environment is to understand the infrastructure
tructure that is currently in
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,
issues which may arise during the actual migration.
As part of the evaluation, a number of infrastructure areas should be assessed and documented as
listed in Table 2:
Infrastructure
Comment
Area
Network Diagram 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,
server and so on. For each server, the server operating system’s
version,, patch revision, and the transport protocols that are in use should also be documented.
documented
Printers Ensure all printers currently used within the environment can continue to be used once migrated. Especially
in NetWare environments,
environments where a printer currently uses the Internetwork Packet Exchange (IPX)
( protocol,
ensure it can use TCP/IP. If not, the printer may need replacing.
Network stored All information stored on the network servers needs to be identified, whether it is user data or application
information data. The
he location of the data,
data who is responsible for it,, which users have access to it and the security
requirements for data storage must also be noted.
Server operating Ensure that if any software installed on a server to be decommissioned is still required,
required it is catered for in the
systems dependent migration process. This involves documenting the version installed, any configuration and whether or not the
software software can run on Windows Server 2003. If not, the software may need updating or replacing.
repla
Page 12
Infrastructure
Comment
Area
Local Area Networks Along with the network diagram detailing the servers, it is also important to create a diagram that includes the
(LAN)/Wide Area network links in place and the available bandwidth. This is a prerequisite for an Active Directory design.
Networks (WAN) links
User environment This includes the identification of login scripts, system or group policies in place, and home folder locations.
properties
Health of current This primarily refers to the synchronisation between servers but also to the server operating system. For NT4
domain or NDS 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,
servers, use tools such as DSTRACE and
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.
identified This
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 physically
physical and logically within the domain or NDS
DS Tree)
Target destination (the Active Directory organisational unit (OU) to which
ich the object will be
migrated, and the location of a server if a physical move of the server takes
tak place)
Page 13
5.3.1 Users
Different types of user accounts have different requirements and
and access needs. Typically, a user
account can be placed into one of three categories:
categories
IT administrator
Service account
Standard user
Migrating
igrating to a new Active Directory environment provides an ideal opportunity to ensure that
appropriate administrative accounts
counts are created. These administrative accounts are those that are
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 accounts
account that should be used to run administrative
adminis
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 day accounts. Instead, a separate
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).(CN) For example, when creating a user in NDS, a common name
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
with the common name of Anna, but 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,
conventions including users with the same name.
Recommendation
If users exist with the same name, it is recommended that a healthcare organisation change the logon
names of the users within n NDS, to make them unique, prior to the migration.
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
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,
MSDSS any NDS organization or NDS OU that will be part of the
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 organisation
organi ation or NDS OU.
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.
group. If migrating groups, and user membership of
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 the old and new
domains as part of the installation and initial usage process.
Caution
A global group migration process can consume large amounts of network resources,
resources as well as local
resources on the domain controller in the target domain. Therefore, a global
global group migration should be
completed outside of normal or peak working periods.
5.3.3 Computers
As with users, computers can also be placed into their different categories such as:
Servers
Desktops
Portable computers
Each computer type will need different considerations
siderations when being migrated to the new
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,
server and
operating as an intranet Web site for users, could be migrated without many configuration changes.
However, a Novell NetWare server authenticating
aut users and running an unsupported application
could require a lot more planning to migrate and potentially to decommission.
Recommendation
Replacing existing directory-enabled
enabled services or applications with new Active Directory-enabled
Directory software
is a task that should be performed independently of the migration of NetWare users, groups, distribution
lists, organisational units, organisations, and files.
Page 15
5.3.3.2 Desktops
Desktops are commonly seen as one of the easiest objects to migrate.
migrate However,
owever, there are areas
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 required
requi
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,
required which
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,
installed which will become
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
are environment, a computer would typically have the Novell Client32 or Novell Client for
Windows software installed. As part of the migration,
migration the Client32 software would need to be
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
atch command file.
As part of a migration from a Microsoft or Novell environment, unless an in-place
place migration is taking
place, all desktops will need to be configured with new domain membership to become part of the
new environment.
Important
One of the most
ost common failures during a migration of computer accounts is due to the desktop computer
being switched off and, as such,
such it cannot be migrated. It is important for a communication to be sent out
to all computer users informing them that computers must be be left on for the duration of the migration.
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 ensure
e
the computer accounts for these computers are migrated to the new environment.
environment This is typically
because the computers are not connected to the network outside of normal working hours,
hours as
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.
time This
should be clearly communicated to users so
s that they are aware when their portable computers are
required to be connected to the network for successful migration and to help keep the project within the
allotted timeframe.
Page 16
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, ensure
e
that the printers can be printed to using TCP/IP and not just IPX.
If migrating from a Windows-based

based environment, the Microsoft Windows Server 2003 Print Migrator
tool can be used to migrate printers from a print server running Microsoft Windows NT 4.0,
4
Microsoft Windows 2000 or Microsoft Windows Server 2003. 2003
12
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 from
fro the Microsoft
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 .
5.3.5 Data
In Novell environments, the File Migration Utility (FMU),
(FMU) which is part of SfN, can be used.
used When
using MSDSS, it is possible to complete a migration that includes
includes an option for a file migration. This
option creates a migration log that the FMU can use to maintain users’
users access rights to their data.
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 Windows
Wi Server
2003 Resource Kit tool (Permcopy.exe
Permcopy.exe) can be used to copy the permissions from a source
sour share
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 languagess typically found
within
in a NetWare environment. Migration of these scripts requires careful planning when migrating
migrat
into an Active Directory environment.
Active Directory provides the ability to specify a batch file (configured in the user properties) as the
th
login script for individual users.
users It also provides the batch file processing method when using Group
Policy objects
bjects (GPOs). Using GPOs, a healthcare organisation can specify startup, logon, logoff
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
http://download.microsoft.com/download/2/e/5/2e57d536 2bb5-40f1-b52d-
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
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 used
use is mainly dependent upon the following:
The size of the migration (number of objects to migrate)
Whether the objects that exist in the current environment are valid or not (an
( example of an
invalid object is when a user account exists
exist for a user that has left employment)
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
re entering user accounts, computer accounts and
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
ent in learning, installing and using the migration tools could take longer than
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
ent environment. This option is typically used in situations where a large
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
process due to the number of objects
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
available tools provided
provi 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.
Directory. The specific tool that
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-based
Microsoft environment, a number of tools can be used to automate
the migration. Depending
epending on what objects within the current environment are to be migrated, both
the extent of control needed over these objects and the resources available (including
including their
technical abilities) can influence which tool is used.
Page 18
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 forest
fo for a
healthcare organisation.. Based upon this recommendation,
recommendation an environment that currently has
multiple Windows NT 4.0 domains,
domains such as account and resource domains, can use ADMT to
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 ctive Directory
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
organisationss amalgamating and combining the IT infrastructure to reduce administrative
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
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 should
shoul use the
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,
date and the design of the Active Directory
follows the Active Directory Design Guide {R1} recommendations and/or is well documented.
ADMT can be run by using thre

ree different methods:
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.
Page 20
Recommendation
®
For a healthcare organisation that does not have in-house
house expertise in Microsoft Visual Basic Scripting
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,
Standard SQL Server
®
2000 SP4 Enterprise Edition, or Microsoft SQL Server 2005.
Recommendation
It is recommended that healthcare organisations use the default WMSDE database store,
store as installed and
configured during the installation of ADMT.
5.5.1.2 Password Export Server Service

The Password Export Server (PES) service,
service part of the ADMT download, allows the migration of
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 migration.
m
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--bit high encryption.
This encryption is standard on domain controllers running
running Windows Server 2003,
2003 Windows 2000
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
128 bit high encryption, a high encryption
pack is available for download from Microsoft.
16
For Windows 2000 Server, obtain the Windows 2000 High Encryption Pack (128-bit)
(128 from the
Microsoft Download Center.
®
For Windows NT 4.0, if Microsoft Internet Explorer 5.5 is installed, this includes 128-bit
128 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
icrosoft Download Center .
5.5.1.3 Third-Party
Party Tools
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
provide extra resource in planning, developing and migrating between
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
up of resources
Detailed statistics of the migration
16
Windows 2000 High Encryption Pack (128-bit)
(128 {R16}:
http://www.microsoft.com/downloads/details.aspx?FamilyID=C10925A0-AC66-4C44-B5C3-
http://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
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.
organisation If a healthcare organisation wishes to consider these tools for
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
based environment, a number of tools are available to help automate
the migration to Active Directory,
Directory as described in this section.
5.5.2.1 Microsoft Services for NetWare

Microsoft Services
ces for NetWare 5.03 (SfN) enables a healthcare organisation to integrate Windows
Server 2003 servers into an existing Novell NetWare network,
network whether this is a Bindery or
NDS-based environment,, and carry out a phased migration running the Windows environment
environm and
the NetWare environment in parallel.
SfN includes Microsoft
ft Directory Services Synchronization
Synchronization (MSDSS) and the File Migration Utility
(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,
between a
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
20
SfN requires the installation of
o the Novell Client for Windows available from the Novell
Novel Downloads Web
page.
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
Migration Tools for Active Directory {R18}: http://www.quest.com/active-directory/migration.aspx
directory/migration.aspx
19
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
5.5.2.2 Microsoft Directory Services Synchronisation

MSDSS enables bidirectional synchronisation between Active Directory and NDS or eDirectory
directoryy services. With MSDSS, a healthcare organisation can configure a one-way
one or two-way
synchronisation between the different directory services.
services This allows objects, such as user
accounts, to be updated in Active Directory; these updates are then synchronised
synchronise across to NDS.
Table 3 describes in detail the following types of synchronisation that can occur as part of MSDSS:
MSDSS
Synchronisation Type Description

Forward synchronisation 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
that have been changed. If a new object has
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.
Reverse synchronisation 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. IfI any objects have been
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
reduce the network utilisation, but can have an adverse
effect on the data held within Active Directory and potentially cause Active Directory to become
out of date.
One-way synchronisation A one-way

one 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 reverse
reve synchronisation followed by subsequent forward
synchronisations.
Two-way synchronisation A two-way

two synchronisation is the same as a one-way way synchronisation except that additional
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.
Scheduled synchronisation 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)
midnight) to 06:00,
06:00 due to the
increased network traffic caused by this type of synchronisation. If two-way
two synchronisation is in
use, a different schedule can be configured for each direction.
Manual synchronisation 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 user
u account needs to
be synchronised immediately, rather than waiting for the next scheduled synchronisation.
Password synchronisation A password synchronisation process can only take place if the passwords are changed from
Active Directory. A password synchronisation
sy occurs when an initial reverse synchronisation
takes place, a user account is created in NDS as part of a two-way
two way synchronisation, or a
password is changed in Active Directory.
It is not possible to synchronise passwords from a Novell directory
directory service to Active Directory. A
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.
Table 3: MSDSS Synchronisation Types
Recommendation
It is recommended that a healthcare organisation uses an initial reverse synchronisation, followed by one-
one
way forward synchronisations configured with a default schedule. Once the initial synchronisation has
occurred, objects should be managed through Active Directory and any changes,
changes including passwords,
passwords
willll be synchronised to NDS.
Page 23
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
way synchronisation
Two-way synchronisation
isation
The NDS directory schema extensions are only required for a two-way
way synchronisation.
Note
As the recommendation is to use a one-way
one way synchronisation, it is possible to carry out the migration
without the need to extend the NDS directory schema.
MSDSS S provides the ability to migrate passwords from Active Directory to NDS, Bindery or
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 Description

Set passwords to blank When this option is selected, users are created with a blank password.
password When logging on for the
first time, the user will have to create a password.
Set passwords to the user name 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.
Set passwords to random values 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
Options dialog box. When logging on for the first time,
the user will have to change this password.
Table 4: MSDSS Password Schemes
The following example text has been extracted from an

a MSDSS generated file using the random
value password option:
Session 1: {21AD8B68-2A42
2A42-459e-BD29-F082F47E71B2}
Started: 01-31-2008
2008 08:21
jonathan jNA$3mR_h7
sagiv X.kQ#tu68B
jacqueline WJr+66Ru.e
rich +bq-I2ZxM4
ivo 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 but also requires the most planning regarding the
communication of the new passwords to the migrated users.
Page 24
Recommendation
It is recommended that a healthcare organisation uses the option of setting passwords to random values
value
because all other options would enable any user to logon using any other user’s 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,
process as well as any new location for storing their data,
and so on.. This communication can also be used to relay what the user’s
user s new password will be. For
example, creating a mail-merge
merge document while using
using the password file as a data source, allows
communications to be created directly,
directly focusing on the individual user.
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,
file which is then used by FMU as a mapping file to
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 Directory
Direc 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
directory on an NDS server and the
target must be a shared folder on a Windows Server 2003 or Windows 2000 Server.Server The FMU
allows for a single source to
o be mapped to multiple targets or multiple targets mapped to a single
source.
Page 25
5.5.2.4 Third-Party
Party Tools
SfN provides
es a set of freely available tools and utilities when migrating from Novell NetWare.
However for larger, more complex environments, some limitations of SfN could require a healthcare
organisation to provide extra resource in planning, developing and migrating
migrating between
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-out
locked accounts
Supports a rollback facility
facil of specific migrated objects
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.
organisation If a healthcare organisation wishes to consider these tools for
their Active Directory migration project, careful
careful assessment, planning and testing of the migration must still
take place.
21
Migrate Novell Directory Services to Active Directory {R21}: http://www.quest.com/nds-migrator
Page 26
6 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.
level checklist, illustrating the sequence of events that the IT Manager and
IT Architect need to determine when planning for an Active Directory migration within a healthcare
organisation.
This section is splitt into two distinct areas, each focusing on the server operating systems in use in
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
scale live migrations are performed,
performed to ensure they work as expected.
6.1 Windows NT 4.0

.0 Domain or Active Directory Migration
As detailed within the Plan
lan phase (section 5),, the ADMT can be used for either a Windows NT 4.0
or Active Directory domain migration. This section provides the information
rmation required to prepare both
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
There are a number of prerequisites for the migration
migration of accounts and resources:
resources
Installation of high encryption
ncryption software
Creating trust relationships
elationships
Creating migration accounts
Configuring domains for SID history migration
Configure the target domain OU structure
Page 27
6.1.1.1 Installation of High Encryption Software

Softwar
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,
Server but can also be used as a guide for installation on a Windows NT
4.0 Server.
Step Description Screenshot

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.
2. Read the license agreement, and

if applicable, click Yes to accept.
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
rget domains.
The following instructions in Table 6 provide the steps involved in creating a two-way
two trust between
a Windows NT 4.0 domain
omain and a new Windows Server 2003 Active Directory environment. These
instructions require that a name resolution mechanism is in place,
place so that the Windows NT 4.0
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.
Page 28

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.
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.
4. A User Manager for Domains

information message displays
stating the trust relationship could
not be verified. Click OK to
continue.

dialog box, click Add next to the
Trusting Domains: box.
Page 29

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.

dialog box, the Windows Server
2003 Active Directory domain will
be shown as both a Trusted and
Trusting Domain. Click Close.
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.
Page 30

10. The New Trust Wizard starts.
Click Next to continue.
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.
Page 31

13. Click Domain-wide
authentication for the outgoing
trust authentication level and click
Next.
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.
Page 32

16. Click Next in the Trust Creation
Complete page.
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.
Page 33

19. Once the trust relationships have
been confirmed, click Finish,, to
complete the New Trust Wizard.
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
Page 34
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 administrator’s 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 individual’s
individua account credentials
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 locall security group in the target
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 configuration.
config 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.
configured It is therefore recommended that healthcare organisations
organis allow
ADMT to automatically configure these items.
6.1.1.5 Configure the Target Domain Organisational

O 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,
organisations is available within
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,
5.5.1.1, ADMT will use the default database installation.
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 thet installation.
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

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

4. As recommended in Section 5.5.1.1,
5.5.1.1
click Use Microsoft SQL Server
Desktop Edition (Windows) and click
Next.
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
Page 37
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,
installed type
the following:
C:>admt
admt key /option:create /sourcedomain:<DomainName>
/sourcedomain: /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.

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.
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.
Note
The Pwdmig.msi file can bee run in
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.
Page 38

3. Click Browse and locate the
encryption key file created in step 1,
and click Next.
4. Type the password supplied during the

creation of the encryption key file in
step 1 into the Password and Confirm
text boxes.
5. Click Next to start the installation.
Page 39

6. Provide the migration account details
using the domain\username
username format in
the Log on as text box and typee the
password for this account in the
Password and Confirm password
text boxes.
Click OK to continue.
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.
Page 40

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
6.1.4 Configuring ADMT

Once ADMT has been installed,
installed the configuration of the source and target domains needs to be
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.

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

2. In the Group Account Migration
Wizard, click Next to continue.
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.
4. Click Select groups from

domain, and click Next.
Page 42

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

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

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.

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
Page 45
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
command line. This
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
NT4 in a test Windows NT 4.0 domain named NT4DOMAIN.
N . The target domain is a
Windows Server 2003 Active Directory domain named ADHealthOrg,, using a domain controller
named ADMIG-2K3-MS. MS. The users would be migrated to an OU named Knowledge Based Users
and have their passwords migrated using the PES service
service installed on the ADMIG-NT4
ADMIG server.
[Migration]
IntraForest=No
SourceDomain="NT4DOMAIN"
SourceDomainController="ADMIG
SourceDomainController="ADMIG-NT4"
;SourceOu="Source Organisational Unit Name"
TargetDomain="ADHealthOrg
HealthOrg"
TargetDomainController="ADMIG
TargetDomainController="ADMIG-2K3-MS"
TargetOu="LDAP://adhealthorg
healthorg.contoso.com/OU=Knowledge Based
Users,OU=Users,OU=Healthcare
Healthcare Organisation,DC=adhealthorg,DC=contoso
Organisation contoso,DC=com"
PasswordOption=Complex
PasswordServer="ADMIG-NT4"
NT4"
;PasswordFile="Password File Name"
ConflictOptions=Ignore
;UserPropertiesToExclude="Prop
;UserPropertiesToExclude="Property1,Property2,Property3"
;InetOrgPersonPropertiesToExclude="Property1,Property2,Property3"
;GroupPropertiesToExclude="Property1,Property2,Property3"
;ComputerPropertiesToExclude="Property1,Property2,Property3"
Page 46
[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
section and a User section. Other sections such as
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,
xample, if running a user migration, the TranslateRegistry option for a
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
colon (;), orr an option has not been specified within the option file, ADMT
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 d on the options for objects that can be migrated. For example, for a
user, type the following at the command prompt:
prompt
C:>admt user /?
The ‘user’ parameter can be substituted with ‘group’, ‘computer’, ‘security’, ‘service
service’ or ‘password’
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
ealthcare organisations should use this to gather information about whether
wh 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 prompt

pro to enable verbose logging:
C:>admt
admt config logging /LogAttributes=Yes
Page 47
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.
syntax The text below is the first few lines of an example
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
EAndersen,Elizabeth.Andersen@contoso.com
ErAndersen,Erik.Andersen@
@contoso.com
HAndersen,Henriette.Andersen
HAndersen,Henriette.Andersen@contoso.com
MAndersen,Mary.Andersen@contoso.com
contoso.com
TAndersen,Thomas.Andersen
TAndersen,Thomas.Andersen@contoso.com
NAnderson,Nancy.Anderson@
@contoso.com
The target can also be the TargetRDN,
TargetRDN which specifies the relative distinguished name,
name or
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’.
firstname The TargetRDN option must include the text ‘CN=
CN=’.
Page 48
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 named
name
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
on file or include file is not in the current working directory, the full path should be
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
migrating from a NetWare environment to a Windows Server 2003 Active
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 Prerequisites

Prerequi
There are two prerequisites for the migration of accounts and resources when using SfN:
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
6.2.1.1 Creating
reating a Migration Account
When running the migration, a migration account should be created and used, rather than an IT
administrator’s individual account.
account. This ensures that an IT administrator tasked with a portion of the
migration is not granted permissions
permis that would not normally be provided outside of the migration. It
also ensures that if the account is used in a script, an individual’s account credentials are not
shared.
The installation of SfN will attempt to extend the Active Directory schema and,
and as such,
such appropriate
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 following
foll 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.
Page 49
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.
environment The IPX protocol
rotocol should only be installed if the NetWare
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 .

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.
Once extracted, run the Setupnw.exe
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.
2. Click Custom Installation and click

Next.
23
Novell Downloads {R20}: http://download.novell.com/index.jsp
Page 50

3. Ensure Novell Client for Windows
(Required) is selected. Click Next to
continue.
4. Clear any additional products that are

selected and click Next.
5. Click IP and IPX and click Next.
Page 51

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

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
Page 52
6.2.2 Installing Microsoft Services

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

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.
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
http://www.microsoft.com/downloads/details.aspx?FamilyID=a819838d-acb2-4794-87eb-82a6a3af4be8&DisplayLang=en
82a6a3af4be8&DisplayLang=en
Page 53

3. Type a User Name and Organization
Organiz
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.
4. Click Custom setup type and click

Next.
5. In the Custom Setup page, all features

will be installed by default. Click
lick Next
to continue.
Page 54

6. Click Next to begin the installation.
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
6.2.3 Directory Synchronisation Using MSDSS

Once the Novell Client for Windows and SfN have ha been installed, an initial reverse synchronisation
can take place. This is initiated through
throug the creation of a one-way
way synchronisation, as
recommended in section 5.5.2.2,
5.5.2.2, and selecting the option to perform an initial reverse
synchronisation. This is detailed
iled in the steps provided in Table 12.
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 ed as a reference for configuring multiple synchronisations for varying
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 takes take
over the provision of user access to the required resources.
resources

computer, select Start > All
Programs > Administrative
Tools > Directory
Synchronization to open
MSDSS.
Right-click MSDSS
(<DomainName>) and select
New Session.
2. The New Session Wizard starts.

Page 56

3. Choose Novell Directory
Services (NDS) from the Select
NDS or Bindery drop-down
down and
click One-way
way synchronization
(from Active Directory to NDS
or Bindery).
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.
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.
Page 57

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

9. To identify this synchronisation
session in the MSDSS window,
type a Session Name, or accept
the default name, and click Next.
Next

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
Once the synchronisation session has been created, it is displayed in the MSDSS window. The
session can then be managed.
managed Right-click the session name to select a number of tasks such as:
as
View Logs – Opens
pens the MSDSS Event viewer
Clone Session – Runsuns the New Session Wizard and pre-populates
pre populates the field values with
those used in the selected session
Synchronize Changes - Forward – Forces a forward synchronisation
Update Status – Refreshes
efreshes the status shown in the MSDSS window
Disable Session – Pauses
auses the synchronisation of objects within the selected session
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 w passwords will be handled when users are first synchronised to Active
Directory. During the steps detailed in section 6.2.3, the Set
et passwords to a random value option
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 of the Administrators and MSDSS Admins group. The file
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 passwords:
password
Figure 10: MSDSS Event Properties Displaying Password File Location
Once the initial reverse synchronisation has completed, all users logging onto
onto the Active Directory
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 passwords.
passwor 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.
Page 60
7 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.
level checklist,
check illustrating the critical components that an IT professional
responsible for stabilising the Active Directory migration needs to determine.
Figure 11: Sequence for Stabilising

ing an Active Directory Migration
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 rollback
rollbac plan
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
scale live migrations are performed,
performed to ensure they work as expected.
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-to-day
day day activities as normal,
normal but with the
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 synchronising
synchronis 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
based applications for the pilot users
During the pilot, focus on the following areas:
Check that all the users and their permissions to files and folders were migrated as
expected
Page 61
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,
completed document the findings and rework the migration processes as
necessary.
7.2 Reviewing Log Files

Whether migrating from a Windows or Novell environment, log files are crucial components
c 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
ation log after a migration is complete to verify that all tasks were completed
successfully.
Important
As it is important to complete the steps of the migration in the order specified in this document,
document check the
migration log after each step, so
s that any failures discovered can be fixed.
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
click any item in the left pane of the MSDSS window and select View
Logs.
Figure 12 shows the events logged during a number of migration tasks:
tasks
Figure 12: MSDSS Event Log
Page 62
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
third party providers of such skills.
The resources listed are those provided by Microsoft.
Microsoft
PART I Microsoft Active Directory 2003

For further information on Active Directory,
Directory see http://www.microsoft.com/activedirectory
Skill or Technology Area Resource Location Description

Active Directory Design, including http://technet2.microsoft.com/WindowsServer/en/Libr Links to sections on designing Active
DNS design ary/c283b699
ary/c283b699-6124-4c3a-87ef- 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/en
us/interopmigration/bb380225.aspx
Skill or Technology Area Resource Location Description

Upgrading from Windows NT http://www.microsoft.com/windowsserver2003/upgra Links to various resources on migrating
Server 4.0 to Windows Server ding/nt4/default.mspx from Windows NT 4.0
2003
Upgrading from Windows 2000 http://www.microsoft.com/windowsserver2003/upgra Links to various resources on migrating

Server to Windows Server 2003 ding/w2k/default.mspx from Windows 2000 Server Active
Directory
Resources for Interoperability and http://technet.microsoft.com/en-

http://technet.microsoft.com/en Links to various resources on migrating
Migration of NetWare and us/interopmigration/bb380216.aspx from Novell NetWare NDS or Bindery
Windows
Table 14:: Active Directory Migration Skills and Training Resources
Page 63
APPENDIX B ADMT SAMPLE OPTION FILE

The text below represents an example option file including all the available options that can be
b
specified for the migration of users, groups, computers, security and service accounts.
accounts
[Migration]
IntraForest=No
SourceDomain="NT4DOMAIN"
SourceDomainController="ADMIG
SourceDomainController="ADMIG-NT4"
;SourceOu="Source Organisational Unit Name"
TargetDomain="ADANYTRUST"
TargetDomainController="ADMIG
TargetDomainController="ADMIG-2K3-MS"
TargetOu="LDAP://adhealthorg
healthorg.contoso.com/OU=Knowledge Based
Users,OU=Users,OU=Healthcare
Healthcare Organisation,DC=adhealthorg,DC=contoso
Organisation contoso,DC=com"
PasswordOption=Complex
PasswordServer="ADMIG-NT4"
NT4"
;PasswordFile="Password File Name"
Nam
ConflictOptions=Ignore
;UserPropertiesToExclude="Property1,Property2,Property3"
;InetOrgPersonPropertiesToExclude="Property1,Property2,Property3"
;GroupPropertiesToExclude="Property1,Property2,Property3"
;ComputerPropertiesToExclude="Property1,Property2
;ComputerPropertiesToExclude="Property1,Property2,Property3"
[User]
MigrateSIDs=Yes
TranslateRoamingProfile=No
UpdateUserRights=No
MigrateGroups=No
MigrateServiceAccounts=No
[Group]
MigrateSIDs=Yes
MigrateMembers=No
Page 64
[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”
[Service]
PreCheckOnly=No
Page 65
APPENDIX C DOCUMENT INFORMATION
PART I Terms and Abbreviations

Abbreviation Definition
ACL Access Control List
ADMT Active Directory Migration Tool
BDC Backup Domain Controller
CN Common Name
CSNW Client Service for NetWare
DNS Domain Name System
FMU File Migration Utility
FPNW File and Print Services for NetWare
GPO Group Policy object
IP Internet Protocol
IPX Internetwork Packet Exchange
IT Information Technology
LAN Local Area Network
MOF Microsoft Operations Framework
MSDSS Microsoft Directory Synchronisation Services
MSF Microsoft Solutions Framework
NAT Network Address Translation
NDS NetWare Directory Service
NTLM NT LAN Manager
OU Organisational Unit
PDC Primary Domain Controller
PES Password Export Server
RDN Relative Distinguished Name
SAM Security Accounts Manager
SfN Service for NetWare
SID Security Identifier
SP Service Pack
TCP/IP Transport Core Protocol/Internet Protocol
UPN User Principal Name
WAN Wide Area Network
WMSDE Microsoft SQL Server 2000 Desktop Engine

Table 15: Terms and Abbreviations
Page 66
PART II References
Reference Document Version
R1. Active Directory Design Guide:
Guide 1.0.0.0
http://www.microsoft.com/industry/healthcare/technology/hpo/security/activedirectory.aspx
R2. Microsoft Download Center: Microsoft Solutions Framework Core Whitepapers:

http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b
http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b-ac05-42a6-bab8-
fc886956790e&DisplayLang=en
R3. Microsoft TechNet: Microsoft Operations Framework:

Framework MOF Executive Overview:
http://www.microsoft.com/technet/itsolutions/cits/mo/mof/mofeo.mspx
R4. Microsoft Download Center: Migrating Windows NT Server 4.0 Domains to Windows Server 2003:
2003
http://www.microsoft.com/downloads/details
http://www.microsoft.com/downloads/details.aspx?familyid=E92CF6A0-76F0-4E25-8DE0-
19544062A6E6&displaylang=en
R5. Microsoft TechNet: Windows Server TechCenter: Designing and Deploying Directory and Security
Services:
http://technet2.microsoft.com/windowsserver/en/library/d2ff1315
http://technet2.microsoft.com/windowsserver/en/library/d2ff1315-1712-48e4-acdc-
8cae1b593eb11033.mspx
R6. Microsoft Download Center:

Center ADMT v3 Migration Guide:
http://www.microsoft.com/downloads/details.aspx?familyid=D99EF770-3BBB-4B9E-A8BC-
http://www.microsoft.com/downloads/details.aspx?familyid=D99EF770
01E9F7EF7342&displaylang=en
R7. Microsoft
rosoft Windows Server 2003 R2: NetWare to Windows Server 2003 Migration Planning Guide:
Guide
Migrating Novell NetWare to Windows Server 2003 Microsoft Word document (SFNmig.doc):
http://www.microsoft.com/windowsserver2003/techinfo/overview/sfnmig.mspx
R8. Microsoft Download Center: Solution for Migrating File, Print, and Directory Services from Novell
NetWare to Windows Server 2003:
2003 Microsoft Word document:
http://go.microsoft.com/fwlink/?LinkID=46606
R9. Microsoft TechNet: Solution for Migrating File, Print, and Directory Services from Novell NetWare to
Windows Server 2003:
http://technet.microsoft.com/en
http://technet.microsoft.com/en-gb/library/bb496964.aspx
R10. Microsoft Windows Server 2003 R2: Services for NetWare 5.03 White Paper:
http://www.microsoft.com/windowsserver2003/techinfo/overview/sfn503wp.mspx
R11. Microsoft TechNet: Microsoft Windows Server TechCenter: Using Run as:
http://technet2.microsoft.com/windowsserver/en/library/8782f8ab
http://technet2.microsoft.com/windowsserver/en/library/8782f8ab-9538-4111-8a68-
7bfd130c21c01033.mspx?mfr=true
R12. Microsoft Download Center:

nter: Print Migrator Tool 3.1:
http://download.microsoft.com/download/4/5/2/452d431e
http://download.microsoft.com/download/4/5/2/452d431e-5a5c-43bd-b398-6fc27208e001/printmig.exe
6fc27208e001/printmig.exe
R13. Microsoft Download Center: Microsoft Print Migrator 3.1:

http://download.microsoft.com/download/2/e/5/2e57d536
http://download.microsoft.com/download/2/e/5/2e57d536-2bb5-40f1-b52d-
a11f5aae2e22/Microsoft%20Print%20Migrator%203.1.doc
R14. Microsoft TechNet: Microsoft Windows Server TechCenter: Client Service for NetWare:
http://technet2.microsoft.com/windowsserver/en/library/eda1cc2b
http://technet2.microsoft.com/windowsserver/en/library/eda1cc2b-c3cc-4845-add0-
503439f6d1271033.mspx?mfr=true
R15. Microsoft Download Center: Active Directory Migration Tool v3.0:

http://www.microsoft.com/downloads/details.aspx?FamilyID=6f86937b
http://www.microsoft.com/downloads/details.aspx?FamilyID=6f86937b-533a-466d-a8e8-
aff85ad3d212&DisplayLang=en
R16. Microsoft Download Center: Windows 2000 High Encryption Pack (128-bit):
(128
http://www.microsoft.com/downloads/details.aspx?FamilyID=C10925A0
http://www.microsoft.com/downloads/details.aspx?FamilyID=C10925A0-AC66-4C44-B5C3
B5C3-
9DCAB4DA1C63&displaylang=en
Page 67
Reference Document Version

R17. Microsoft Download Center: Internet Explorer High Encryption Pack 4.0:
4.0
http://go.microsoft.com/fwlink/?LinkId=76038
R18. Quest Software, Migration Tools for Active Directory:

http://www.quest.com/active
http://www.quest.com/active-directory/migration.aspx
R19. Microsoft Download Center: Microsoft Services for NetWare 5.03 SP2 and FPNW:
http://www.microsoft.com/downloads/details.aspx?FamilyID=a819838d
http://www.microsoft.com/downloads/details.aspx?FamilyID=a819838d-acb2-4794-87eb-
82a6a3af4be8&DisplayLang=en
R20. Novell Downloads: Novell

Novel Client for Windows:
http://download.novell.com/index.jsp
R21. Quest Software, Migrate Novell Directory Services to Active Directory:

Directory
http://www.quest.com/nds
http://www.quest.com/nds-migrator
R22. Group Policy for Healthcare Desktop Management: 1.0.0.0

http://www.microsoft.com/industry/healthcare/technology/hpo/desktop/grouppolicy.aspx
Table 16: References
Page 68

Active Directory Migration Guide

Uploaded by

Document Information

Original Description:

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

© Microsoft Corporation and Crown Copyright 2008

The example companies, organisations, products, domain names, e-mail

3 Using This Document ................................................................................................

APPENDIX A Skills and Training Resources................................................................

APPENDIX B ADMT Sample Option File ................................................................

APPENDIX C Document Information ..............................................................................................

2.1 Value Proposition

2.2 Knowledge Prerequisites

2.2.1 Skills and Knowledge

2.2.2 Training and Assessment

2.3 Infrastructure Prerequisites

IT Architect Review the relevant areas within the document against

IT Professional/ Detailed review and implementation of the guidance to

3 USING THIS DOCUMENT

3.1 Document Structure

Figure 1:: MSF Process Model Phases and Document Structure

Figure 2: Sequence for Envisioning an Active Directory Migration

4.1 Active Directory Overview

4.2 Initial State Environment

4.2.1 Public Domain Active Directory Migration Guidance

4.2.2 Microsoft Healthcare Platform Optimisation Active Directory

4.2.3 Technology Scenarios

4.2.3.1 Microsoft Windows NT Server 4.0

Figure 3: Microsoft Windows NT 4.0 Domain Scenario

4.2.3.2 Active Directory

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

4.2.3.3 Novell NetWare

Figure 5: Novell NetWare Scenario

4.3 End State Environment

Figure 6: Sequence for Planning an Active Directory Migration

5.1 Migration Type

If a healthcare organisation currently uses Novell NetWare, or has an Active Directory

5.1.2 Direct or Phased Migration

5.2 Evaluating the Existing Environment

5.3 Scope of Migration

5.3.3.3 Portable Computers

If migrating from a Windows-based

5.3.6 Login Scripts

5.4 Migration Process

5.4.1 Manual Migration

5.4.2 Automated Migration

5.5 Migration Tools Available

5.5.1 Migrating from Microsoft Operating Systems

5.5.1.1 Active Directory Migration Tool

Figure 7:: Active Directory Interforest Restructure using ADMT

Figure 8:: Active Directory Intraforest Restructure using ADMT

ADMT can be run by using thre

5.5.1.2 Password Export Server Service

5.5.2 Migrating from Novell NetWare Operating Systems

5.5.2.1 Microsoft Services for NetWare

5.5.2.2 Microsoft Directory Services Synchronisation

Synchronisation Type Description

One-way synchronisation A one-way

Two-way synchronisation A two-way

Manual synchronisation A manual synchronisation can be initiated by an IT administrator to synchronise changes

Password Scheme Description

The following example text has been extracted from an

5.5.2.3 Microsoft File Migration Utility

Figure 9:: Sequence for Developing an Active Directory Migration

6.1 Windows NT 4.0

6.1.1 ADMT Prerequisites

6.1.1.1 Installation of High Encryption Software