migrating windows 2000

8/3/2019 Migrating Windows 2000

http://slidepdf.com/reader/full/migrating-windows-2000 1/23

Window s 2000 M igratioBest Practices



Contents

General Terminology................... 1

Understanding Your Migration

Options........................................... 2

Migration Scenarios..................... 3

Implementation Strategy for

Windows 2000 Migrations........... 8

Recommended Steps for

Windows 2000 Migration .......... 10

Common Issues That Effect

Migration..................................... 14

Additional Information to

Consider....................................... 14

Partial List of Windows 2000

Technologies................................ 16

Migration Checklists.................. 17

Windows 2000Migration:Best Practices

White PaperAugust 25, 2000

The purp ose of this documen t is to provide an introdu ction to

Windows 2000 migration concepts, scenarios, common issues,

and best practices. This docum ent assumes you have an

adm inistrator-level un derstand ing of Window s networking

architecture and dom ain migration concepts.



First Edition

NetIQ Corporation provides this docum ent “as is” without war ranty of any kind, either express or

implied, includ ing, but n ot limited to, the imp lied warran ties of merchantability or fitness for a

particular pu rpose. Some states do n ot allow d isclaimers of express or implied warran ties in certain

transactions; therefore, this statement m ay not app ly to you.

This docum ent and the software d escribed in this documen t are furnished u nd er a license agreement

or a non-disclosure agreement an d m ay be used on ly in accordance with the terms of the agreement.

This document m ay not be lent, sold, or given aw ay withou t the w ritten permission of NetIQ

Corporation. No p art of this pu blication may be reprod uced, stored in a retrieval system, or

transmitted in any form or by any m eans, electronic, mechanical, or otherwise, with the p rior written

consent of NetIQ Corporation. Compan ies, names, and data u sed in this docum ent are fictitious

un less otherwise noted.

This document could include technical inaccuracies or typograp hical errors. Changes are

periodically made to the information herein. These changes may be incorporated in new editions of

the document. NetIQ Corporation may make improvements in and/ or changes to the products

described in th is document at any time.

© 1995-2000 NetIQ Corporation, all rights reserved.

U.S. Governm ent Restricted Rights: Use, duplication, or disclosure by th e Governm ent is subject to

the restrictions as set forth in subp aragrap h (c)(1)(ii) of the Rights in Techn ical Data and Com pu ter

Software clause of the DFARs 252.227-7013 and FAR 52.227-29(c) and any successor rules or

regulations.

App Manager, the App Manager logo, AppAn alyzer, Knowled ge Scripts, Work Smarter, NetIQ

Partner N etwork, the N etIQ Partner Netw ork logo, Chariot, Pegasus, Qcheck, OnePoint, the

OnePoint logo, OnePoint Directory Adm inistrator, OnePoint Resource Adm inistrator, OnePoint

Exchange Adm inistrator, OnePoint Domain Migration Adm inistrator, OnePoint Operations Manager,

OnePoint File Ad ministrator, OnePoint Event Manager, Enterprise Ad ministrator, Know ledge Pack,

ActiveKnowledge, ActiveAgent, ActiveEngine, Mission Cr itical Software, the Mission Critical

Software logo, Ganymed e, Ganymede Software, the Ganym ede logo, NetIQ, and the NetIQ logo are

tradem arks or registered tradem arks of NetIQ Corporation or its subsidiaries in the United States and

other jurisdictions. All other compan y and prod uct names m entioned are used only for identification

pu rposes and m ay be trademarks or registered trademar ks of their respective comp anies.



Windows 2000 Migration: Best Practices 1

General Terminology

This section provides some p reliminary d omain m igration concepts and term inology you should

know before reading this docum ent.

Clean and pristine

Term u sed to d escribe a brand n ew Window s 2000 native mode d omain that w ill be the

target of a migration.

Upgrade in place

A migration strategy wh ere the affected d omain is simply up graded either before or instead

of a domain migration.

Inter-forest migration

Term u sed to d escribe domain m igration between either two d omains residing in different

Window s 2000 forests or a d omain m igration from Window s NT 4 to Window s 2000.

Intra-forest migration

Term u sed to d escribe a domain m igration between two d omains in the same forest, with a

native mod e target. Special conditions apply to intra-forest migration, such as the source

object being m oved (deleted in th e source and re-created on the target d omain) to the target

domain . In this case, the GUID is retained and the sour ce object SID is app end ed to the SID

History o f the target object.

Mixed mode domain

A Windows 2000 dom ain that is run ning in Windows N T 4 comp atibility mod e. Customers

typically run in this mod e because they h ave Window s NT 4 Backup Dom ain Controllers

(often run ning app lications that make an u pgrad e difficult). Mixed mod e domains u se the

Window s NT 4 single-master mod el for wr ites to the directory.

Native mode domain

A Window s 2000 domain th at is ru nning the Wind ows 2000 native Kerberos-based

authen tication system. Native mod e domains are mu lti-master for pu rposes of directory

up dates. They also sup port SID History and intra-forest moves via MoveObject.SID History

An Active Directory attribute that is often used in m igrations to native mode. Its function is

to retain SIDs in the access token from oth er dom ains. SID History is a mu lti-valued

attribute, meaning that it can contain more than on e Sid from previous d omains. This

attribute is only accessible in native mod e target domains. For more information and a

detailed list of requirements, please see “Understand ing SID H istory” on p age 14.

MoveObject

An Active Directory op eration that involves the source object being moved (deleted in the

source and created on th e target domain) to the target dom ain. In this case, the GUID is

retained and the source object SID is appen ded to the SID History of the target object. This

process allows all prop erties of the object to be preserved.



2 White Paper

Understanding Your Migration Options

What is driving organ izations to migrate? Compan ies are performing migrations for a variety of

reasons:

• New technology, such as Wind ows 2000 or Exchan ge 2000

• Business unit re-organizations, mergers, acquisitions and spin-offs

• Adm inistrative restructuring d riven by a need to simp lify the environment

Once you hav e decided to m igrate to the latest technology base, wh at are your options for migrating

to Windows 2000? There are a nu mber of general strategies for migrating to Wind ows 2000 and

restructuring domains:

Upgrade in place and l eave domain s tructure in tact

Upgrade in place to Window s 2000 and then migrate intra-forest

The most common reasons for upgrad ing in this fashion is the organization only has one

Window s NT account auth entication dom ain or there is a big need to m aintain their curren t

password s (note that Domain Migration Adm inistrator from N etIQ will copy p assword s

between d omains). On the d own side, there is very little ability to rollback changes and the

current environm ent mu st be in a state that is comp atible with the d esired stru cture for

Wind ows 2000.

Upgrade in place and collapse resource domains

This scenario is common in en vironments w here the resource dom ain structure can be better

mana ged by collapsing resources into organizational units (OUs) in the m igrated account

dom ain structure. Without a tool to autom ate this process—changing machines domain

affiliations and creating a new compu ter account in Window s 2000 in th e desired OU—this

wou ld not be a viable option. The ActiveAgent technology in N etIQ Domain Migration

Adm inistrator copies the comp uter accounts to the Wind ows 2000 domain an d p laces them

in the correct OU, then the systems are joined to the new dom ain.

Migrate Window s NT 4 or Novel l environmen t to a clean and pristine Window s 2000 domain

This scenario is used wh en customers take the opp ortun ity to restructure their d omain

environment ar ound the capabilities of the Active Directory. A common p hrase used to

describe this operation is a parallel environment. New Window s 2000 Domain Controllers

(DCs) holding th e Active Directory stru cture are built alongside th e existing infrastructure.

User accounts and gr oup s are migrated to the new environmen t, and existing workstations

are joined to the n ew d omain by th e ActiveAgent technology in NetIQ Domain Migration

Administra tor. In some cases, existing Backup Domain Con trollers (BDCs) in the source

Window s NT 4 dom ain cannot be quickly up graded to Windows 2000 due to the risk

associated with client-server applications installed on those machines. The pa rallel

environment allows Ad ministrators to take advan tage of the new features in the Active

Directory while users still access resources in the old environment.




Many customers require guidan ce on designing and executing their migration strategy. Here are

some helpful questions for determining customer m igration need s:

• When w ill the migration begin?

• When is it expected to conclud e?

• How many u sers are being migrated?

• How man y domains are planned?

• How many forests are planned?• What d oes the curren t dom ain structure look like?

• Will the target domain be mixed mod e or native mode?

• Will SID History be u sed?

• Will re-ACLing be u sed for files, shares, user p rofiles, etc?

• Are other platforms (NetWare, Banyan, etc.) being migrated to Windows 2000 in conjunction

with the domain restructuring?

• Will the DN S reside on Unix or on Wind ows 2000?

Migration Scenarios

This document ad dresses different business scenarios based on th e migration operations pr eviously

described. The scenarios are based on actual and p lanned m igrations:

• Migration from Novell NetWare/ NDS

• Single account dom ain m igration

• Resource d omain consolidation

• Multiple account d omain m igration

The following tw o NetIQ prod ucts are the tools used in th e migration scenarios:

• NetIQ Domain Migration Administrator (DMA): A client-only tool used to migrate user IDs,

member servers, member w orkstations, trusts and other resources from either a Wind ows N T 4.0

to a Wind ows 2000 environment. Employs NetIQ technology also delivered in th e Microsoft

Active Directory Migra tion Tool (ADMT).

• NetIQ NetWare Migrator : Migrates users from NetWa re Bind ery or NDS to Window s 2000.

Multiple source bindery an d/ or NDS accounts can be merged into Window s 2000. Copies files

and associated permissions to Windows 2000 file servers.

Migration from Novell NetWare/NDSA med ium-sized legal firm h as two m ain offices and two rem ote offices. The firm has p laced a

Window s 2000 server in each location an d has comp leted design of their Active Directory stru cture.

Each office has a N etWare 4.11 server (run ning N DS), and the m ain offices each ha ve a NetWare 3.12

server (running bind ery). The offices are connected by h igh-speed links.

The primary ap plication runn ing on the NetWare 4.11 servers had been an SQL database system. Thedatabase system h as been crossed over to Window s 2000 and the users of that system hav e completed

their changeover.

One d esign d ecision mad e early on was to create a new tree structure in Active Directory rather th an

use the tree structure in their existing NDS environment. The IT staff had learned throu gh their own

experience how to best organize the tree and th ey wanted to begin with a clean structure.

Since users need ed to be migrated to Active Directory an d files to Window s 2000 file servers, the

NetWare servers would n ot be needed post-migration.



4 White Paper

An OU w as then created in Active Directory for the bind ery user objects. The bindery-based users

were migrated to th is OU, and then cleanu p w as performed. Similarly, an OU was created for NDS

user objects, and th en cleanup was d one after the u ser objects were m igrated from N DS to Active

Directory.

Files were copied w ith permissions to file servers located in the var ious offices. Server consolida tion

was relatively easy since newer server-class computers were being u sed for the Wind ows 2000 file

servers.

Where necessary, Wind ows 2000 login scripts were m odified to rep lace the file accesses that h ad been

designated in th e NetWare login scripts.

Once migration had been d one, the file permissions on th e NetWare servers were set to read-only so

they could find a ny da ngling pointers to NetWare-hosted files. After these were cleaned up , the

NetWare servers were removed from th e network so that an y add itional references could be

discovered.

Files didn’t have to be erased du ring the m igration process since the migration w as accomp lished in

parallel with the Wind ows 2000 environment.

Single Account Domain MigrationA small manu facturing comp any is currently on a Wind ows N T 4 environment, using Exchange for

their email application. They are planning th eir migration to Windows 2000 now since they are very

interested in mov ing to Exchan ge 2000 as soon as it becomes available.

Because they are plann ing for Exchange 2000, they are looking a t migrating awa y from their

Window s NT 4 infrastructure to a clean and pristine environment. They had originally planned to

build the n ative mod e Wind ows 2000 forest using ClonePrincipal un til Microsoft released th e Active

Directory Migration Tool (ADMT). After reviewing the ADMT features, they decided to purchase

NetIQ Domain Migration Adm inistrator for the p assword migration capabilities. DMA also offers

enhanced r eporting, better performance and project-tracking capabilities. In add ition to the

functionality of ADMT, DMA has the ability to test a migration and report on wh at wou ld hav e

hap pened before any changes are comm itted.

The entire migra tion p roject will encomp ass 1,500 user s in four sites (three office spaces and one

manu facturing facility). The DMA project wizard will allow the m igration team to track the p rogress

of the migration at the four individu al sites (translated p rofiles, security tran slation n ot completed,

failed w orkstations, etc) as well as run weekly reports for the en tire domain to assess adherence to

their strict schedu le (migrated users, migrated grou ps).

The migration team will create separate m igration projects containing the u sers, groups, and

workstations at each site to be migrated. The DMA wizard allows you to select the groups that

identify each site, enum erate the members of the group s, and load grou ps and users into the

migration project.

The initial migration p lan w as to take adv antage of the SID History attribute in the Active Directory

so security wou ld not hav e to be translated. After a more careful evaluation, however, the migration

plan w as mod ified to include a SID History cleanup to preven t complications in the Directory fromlarge Kerberos authentication packets. (For more inform ation, see TechN et article Q263693 ). NetIQ

Domain Migration Adm inistrator provides a w izard for this operation to simplify this process.




In the first and second sites, the users norm ally shu t dow n their workstations wh en they leave for the

evening. In preparation for the weekend m igration, users were instructed to log off their machines

withou t shutting d own. This will facilitate the profile translation, domain mem bership change and

subsequen t reboot of the local machine by the ActiveAgent technology. In the third site to be

migrated, the systems are laptop s that travel with outside employees. These employees were

contacted so other arran gements could be mad e -- some were able to dock their laptop s for the

weekend, others returned the laptop for an u pgrade d ue to hard ware requirements with theirdesktop rollout.

Because they could install the ActiveAgent on mu ltiple machines simultaneou sly for security

translation tasks and dom ain membership change, the migration plan was designed arou nd a five-

day cycle for each site.

• Two d ays w ere allotted for testing of the environm ent: verification of perm issions for the

migration account, testing of WINS and DNS name resolution and final identification of

workstations to be migrated.

• One d ay w as allotted for the execution of the m igration project: user accoun ts were m igrated;

then group s and group membership s; and w orkstations were the last step.

• Two days w ere allotted for failed task resolution (machines not online) and testing. A failed

tasks report identified the m igration tasks that needed to be repeated after the cause wasidentified and the problem was resolved.

In this particular case, add itional user IDs were created with known password s and ad ded to group s

being migrated so the m igration team could test file access.

The SID History clean-up operation was then executed after all sites were successfully migrated.

Backups w ere mad e of all file servers before executing th e operation. The DMA wizard identified th e

accounts in the Active Directory with SID History attributes and then tran slated security for those

accounts so permissions accurately reflected the new Windows 2000 account and SID.

Resource Domain ConsolidationAn insuran ce company is currently operating in a Wind ows NT 4 environment. They have a single

master accoun t dom ain with m ultiple resource domains for each rem ote site. Their goal for

migrating to Wind ows 2000 is to reduce ad ministrative costs by collapsing the resour ce domains into

Organization Units in the Wind ows 2000 doma in.

Before evaluating an y migration tools, the existing Window s NT 4 PDC was u pgrad ed to

Window s 2000. They originally planned to change the d omain m embership of 130 resource servers

man ually until they d iscovered th at several servers in d ifferent resource dom ains had una cceptable

compu ter names.

An engineer was brou ght on site to assist with the migration plan an d d evelop guidelines for

consistently naming m achines, dep loying th e naming convention and joining the systems to the new

dom ain. Because of her experience with NetIQ Domain Migration Administrator, she knew that the

Computer Rename wizard w ould change system names and implement the naming standard. The

engineer established a nam ing standard based on location and server role, which was implementedbefore the systems were m igrated to the n ew d omain to eliminate confusion.

A target OU was sp ecified for systems from each resource domain in th e Compu ter Migration

wizard . By creating the account an d d ispatching the ActiveAgent to change the dom ain affiliation

and reboot the machine, she simplified the migration process. The engineer did not have to m anu ally

change the d omain m embership of each machine, and then move each compu ter to a specific OU

throu gh the AD Users and Compu ters snap -in.



6 White Paper

Post-migration analysis furth er illustrated the operation efficiency. The two reboots requ ired for the

name change and th e domain mem bership change amoun ted to only a fraction of the scheduled

dow ntime. Since the naming stand ard w as in place, trouble tickets were more quickly routed to the

app ropriate adm inistrator for resolution.

The engineer left behind a d ocument d etailing the naming stan dard for systems, though th e LAN

adm inistrator ind icated there w as no way to force administrators to follow the stand ard. Because of

her familiarity with N etIQ pr odu cts, she was th en able to demon strate the NetIQ Directory andResource Administrator prod uct, wh ich allows an Ad ministrator to delegate adm inistrative tasks

while enforcing business rules and p olicy on the delegated environm ent. DRA enabled the LAN

adm inistrator to not only enforce a new naming standar d for m achines, but also restrict the OU

where comp uter accounts could be created.

Multiple Account Domain MigrationA large financial services company is prepar ing for an enterprise-wide dep loyment of Wind ows 2000.

In contrast to many sm aller operations, every step of the process must be d etailed.

The Windows 2000 migration plan w ill incorporate a parallel environment in ord er to minimize the

amoun t of service disru pt ion and facilitate complete rollback of un foreseen inciden ts. This will be

achieved by keep ing most of the Wind ows NT 4 environment intact throughou t the migration period.Except for Windows NT 4 app lication servers that h ave to be m oved to the Window s 2000, the

environment will not be rebuilt anew in the Wind ows 2000 environment.

This scenario outlines a five-ph ase migration p lan for the bu siness units to m igrate to Window s 2000

from the existing Window s NT 4.0 and / or Novell NetWare environm ent(s). The plans take into

accoun t the differences in th e organization, operations and architecture of the existing Window s

NT 4.0 and NDS environments.

The curren t state of the Window s NT 4.0 environment w ill be analyzed and map ped to the desired

Window s 2000 environment in the post-migration period. The migration process will be executed in

five ph ases. For more information, see “Recommended Steps for Windows 2000 Migration” on

page 10:

• Phase 1: Research, Plann ing and Requirem ent Definition• Phase 2: Test/ Trial Migration, Contingency Planning

• Phase 3: Domain and Server Migrat ion

• Phase 4: Desktop/ Workstation Migration

• Phase 5: Post Migration Testing an d Clean Up

The scope of this scenario will cover design pr inciples, migra tion tools setup and configuration s. The

project p lan will include migration of master and resource dom ains includ ing user IDs, security

settings, disk shares, printers, pro files, logon scripts, exchange m ail, rem ote access, dynamic DNS and

WINS.

In sum mary, the m igration w ill involve the creation of a n ew Wind ows 2000 infrastructure in a

parallel environm ent to the existing Wind ows N T 4 infrastructure. The migration p rocess will be a

collaborative effort between enterp rise level administrators and business unit ad ministrators. NetIQ

Domain Migration Adm inistrator will be used for the m igration

Windows NT 4.0 Pre-Migration EnvironmentThe Window s NT 4 environ men t consisted of six Trusted Master Account Dom ains; five of wh ich

were in a Mu ltiple Master/ Resource configuration; the other w as a Master accoun t dom ain in Single

Master configuration.




Domain Architecture and Trust Configurations

The environment contained an estimated 200 resource dom ains globally. Enterprise resources, such

as Exchange, were in the master account d omains. Business-specific resources, such as file and p rint

services and app lication servers, resided in the resou rce domains.

Name Service Structure (WINS/DNS)The WINS servers in the Wind ows N T 4.0 environment will be upgr aded in place to Window s 2000

to leverage better performan ce in su pp orting both the Wind ows N T 4.0 and Window s 2000

environmen t. The performance will come from WINS service enhancements and improved IP stack

in Wind ows 2000.

Resource Structure (Exchange, File and Print, Application Servers)

Exchange Servers currently reside in four of the five master account d omains. File and Print an d

App lication servers reside in resource dom ains that tru st into the global multiple master dom ains.

The infrastructure d escribed above mu st be inventoried, divided an d d elegated to sp ecific business

un its group tha t will take be responsible for migrating them to Windows 2000. The management

structures of the environments vary. Several of the account d omains have a distributed m anagemen tstructure with most of the operations handled by bu siness un its. One of the accoun t domains has a

very strict hierarchical structure. NetIQ Domain Migration Ad ministrator prov ides the flexibility to

allow all domains to configure their migration p roject ind epend ently.

The assessment of files, profile location, etc. will be han dled by DMA. The reporting m odule will

gather information from th e servers in the resour ce domains an d compile it in a central location.

These reports will be used to determine w hich servers need to be migrated with sp ecific business

un its. In add ition, service account information will be gathered to ensure service is not interrup ted

du ring the upgrade.

Windows 2000 Post-Migration Environment

The Wind ows 2000 environ men t will consist of a Place Holder d omain and location trees. Businessun it OUs and resource dom ains will be contained w ithin the trees -- all boun d by tra nsitive trusts.

This will allow resources to be shared seamlessly across the world and facilitate distributed

administration.

All enterprise and business-specific resources will be contained in the resource dom ains. The

dom ains will be d ivided into Organizational Units (OU) to facilitate d istributed adm inistration.

Name Service Structure (WINS/DNS)

The WINS environment will remain in the p re-migration state u ntil all Window s NT 4.0 doma in and

resources have been m igrated to Wind ows 2000.

The WINS servers in the Wind ows N T 4.0 environment will be upgr aded in place to Window s 2000

to leverage better performan ce in su pp orting both the Wind ows N T 4.0 and Window s 2000environment.

Dynamic DNS is required by Window s 2000. The networking group will provide infrastructure

guid elines for the dyn amic DNS implementation.

The DMA Reporting Wizard will be used to gather service information from the rem ote servers. This

information will allow the iden tification of the existing WINS servers for up grade planning.



8 White Paper

Resource Structure (Exchange, File and Print, Application Servers)

Exchange, File and Print and App lication servers w ill reside in th e respective OU of the bu siness

un its. DMA will create the new system accoun t in the Window s 2000 dom ain and change the dom ain

membership of the servers (includ ing the reboot). The destination OU can be sp ecified in th e

migration project to ensure th e users, groups, and servers are all located in th e business unit OU.

Implementation Strategy for Windows 2000 Migrations

NetIQ Directory and Resource Adm inistrator m anages the existing Wind ows N T 4 infrastructure.

This p rodu ct allows adm inistrators to create ActiveViews (logical units for organ izing dom ain

objects) and d elegate specific admin istrative tasks to users in the enterp rise. This facilitates delegated

adm inistration and aud iting of all adm inistrative operations.

Design Principles

The following p rinciples will guide the migration p rocess in all areas where th e plann ing andinstructions are insufficient:

• Top-level business OU w ill exist consistently in all regiona l dom ains.

• Where ap plicable, existing DRA ActiveViews w ill map into top -level business OU.

• Full rollback capability w ill be ava ilable throu ghout the m igration process.

• Migration p rocess will not disrup t business operations.

• Migration w ill be project-based .

• Migration assessment reporting will be available at all time.

• A parallel environ men t will be created except for existing WINS servers.

• Immediate re-ACLing will be used instead of SID migration.

• Migration w ill be done in a distributed m anner.

• Security and nam ing standard s will be applied and enforced.

Migration Process Implementation OverviewThe migration pr ocess will consists of collaboration w ork between Master Domain Ad ministrators

and business unit resource domain ad ministrators as follows:

• For distributed manag ement environm ents, resource doma in adm inistrators will have Directory

and Resource Administrator delegated rights in the master account d omains and full

adm inistrative rights in their source resource domains.

• For centrally managed environments, rights w ill be delegated u sing Directory and Resource

Adm inistrator. Very few people will actually have Domain or Enterprise Adm in accounts to

both source resource dom ains and sou rce master account d omain environm ents.




• Resource dom ains admin istrators w ill use th e DMA tool to create a Migration Project (a

migration project is an actual migration wh ere the transactions are not immed iately app lied bu t

saved to an Access database to be executed/ app lied at a later time by an ID having full

adm inistrative rights in both master an d r esource domains). The migration project will contain

the users, groups and compu ters they wish to migrate and settings related to the migration

process, such as renaming objects.

• They will save the file project file and send it to the team actually run ning and app roving themigration pr ojects. This team w ill have ad ministrator rights to all objects in both the master an d

resource domains.

• Project will be tested and assessment r eports w ill be generated for review.

• Once the migration p roject has been ap proved -- that p roject will run in Migrate Now mode

instead of Testing mode.

• Upon completing the bu lk of the migration pr ocess, they will use the Window s 2000 Server

resource kit, scripts, and other tools for special case migrations and clean u p as necessary.

Migration Tool Initial Configuration and Requirements• A two-way tru st between source Wind ows NT 4.0 master domain an d th e target Wind ows 2000

domain.

• A one-way trust mu st between source resource domain and the target Wind ows 2000 dom ain.

• Domain Migration Adm inistrator (DMA) installed on a Window s 2000 member server.

• Team ru nning th e migration must be given ad ministrator access on all systems and d omains

involved in the migration.

• Domain Adm inistrative rights in both source and target d omain environmen t is required to

execute migra tion p roject file.

• DRA delegation rights m ust be g iven to resource dom ain ad ministrators (or ACL perm ission set

on OUs) in the target Window s 2000 dom ain. This is needed so ad ministrators of resource

dom ains can still manage their users after the migration.

Domain/Trust ConfigurationAll source Window s NT 4.0 domain en vironments w ill trust the target Wind ows 2000 domain d uring

the m igration -- facilitating the m igration from the Window s NT 4.0 environm ent to th e d elegated

Wind ows 2000 OU.

Migrating ObjectsThe recomm ended order for Windows N T 4.0 objects to be migrated:

• Group s Accoun t and their members (Users) by DMA.

• Security tr anslation on all ACLs.

• User workstation m achine accounts migration and local profile translation by DMA.

• Service account migration.

• Exchange server security translation.

• Special case migrations with oth er utilities and man pow er.

− App lication migration to Window s 2000 and new d omain.

− Window s 9x platforms m igration.

− Logon script changes needed for new dom ain structure.



10 White Paper

The DMA prod uct w ill track failed w orkstation migration or failed security translation for retry after

the pr oblem is resolved. Common points of failure are insufficient perm issions (Domain Ad mins

group is no longer in the local Administrator grou p of the system) or nam e resolution (WINS

database did not have an entry for the system).

Recommended Steps for Windows 2000 Migration

This section provides th e recommend ed steps for an org anization migrating from Window s NT 4 to

Wind ows 2000.

Phase 1: Research, Planning and Requirement Definition

Inventory All the Resources in Your Windows NT 4.0 Environment• Domain environment configurations (network protocols, trusts, pr ofiles, home shares, scripts

etc.).• Servers and workstations to be m igrated (app lications and server locations).

• Users and group s to be migrated.

• Positions of DCs over data highwa y network.

Domain Migration Adm inistrator has rep orts available to identify location of profiles, status of

dom ain trusts, group membership , user accoun t conflicts between dom ains and more. In addition,

the existing DRA installation can be used for ActiveView m embership to mod el the migration

products.

Define the Windows 2000 Features You Plan to Use in Addition the

Global Ones• Categorize features as must haves an d like to haves. For more information see “Partial List of

Wind ows 2000 Technologies” on page 16.

• Define the timeframe in which you wish to complete the migration.

• Define milestones dates and goals for migration.

• Determine required training for sup port staff and end u sers.

Tools for Research and Planning• The Windows 2000 Server Resource Kit and the Windows 2000 Server Deployment Guide

available on the Microsoft Web Site at http:/ / ww w.microsoft.com/ wind ows2000 are very useful.

• The Domain Migration Ad ministrator and Directory and Resource Administrator reporting tools

can be used to inventory u sers and a ssess security settings.

• The Directory and Resource Adm inistrator ability to create ActiveViews allows you to p lan you r

OU structure and your m igration p rojects.




Training for IT Staff• Window s 2000 training for your IT staff is required in order to research your en vironment and

plan your migration.

• Classes are av ailable from Microsoft an d their pa rtners.

• Web-based classes are also available from var ious ven dor s (Learn2.com, Pinacor.com)

Phase 2: Test/Trial Migration, Contingency PlanningThis is probably the m ost important pha se of the migration p rocess.

Prepare Your Test and Production Environment• All hardw are and software sh ould be checked for Wind ows 2000 comp atibility.

• Non-compliant packages mu st be u pgraded.

• Upgrad e RAM in servers and workstations as required by Microsoft.

• Apply latest Windows 2000 service pack.

Use DMA Tool to Test and Plan Trial Migration and ContingencyThe prod uct has d atabase mod eling capabilities as well as a test (no change) mod e for preparation.

Most connectivity and permissions problems can be identified w ith the test mode. Note that all

machines mu st be online for testing and migration. In add ition, users mu st be logged off for local

profile translation.

The NetIQ Adm inistration pr odu ct line consists of the following m odu les:

Directory and Resou rce Adminis trator

Provides distributed ad ministration of user accoun ts, groups, and system resources

increasing security and redu cing n etwork costs with au tomated, p olicy-based

adm inistration and extensive aud iting and r eporting.

Exchange Administrator

Provides d istributed adm inistration of Microsoft Exchange mailboxes and

distribution lists lowering network cost throu gh au tomated policy based Exchange

administration.

Domain Migration Administrator

Migrates user accoun ts, groups, member servers, workstations, user rights and other

components between Wind ows NT and Wind ows 2000 dom ains. Preserves existing

resources and can operate without disrupting end users.

NetIQ NetWare Migrator

Migrates user accounts from N etWare Bindery or N DS to Wind ows 2000.

File and Storage AdministratorAllows you to proactively man age file and sh are perm issions and prop erties across

servers. This produ ct also prov ides extensive reporting on d isk space utilization, file

statistics, and security reference data. File and Storage Adm inistrator d ram atically

redu ces the time, effort, and resources required to secure and adm inister the

Wind ows N T 4.0 and Wind ows 2000 file system.



12 White Paper

Testing RequirementsThe trial migration environment should contain a representative structure of the prod uction

Window s NT 4 environment an d Wind ows 2000 dom ains. If app ropriate, a test resource domain

should a lso be constructed. One app roach to setting u p a good lab scenario is to restore produ ction

servers from a back-up d evice in the lab. In add ition, bringing up a BDC in the produ ction Window s

NT doma in and then m oving it into the lab and prom oting it to a PDC in the lab will allow for a real

copy of your produ ction domains users and groups.

The resource domain w ill need to tru st the source master account dom ains -- creating a tw o-way trust

between each master accoun t dom ain and the Window s 2000 dom ain.

Several migration projects could be created to simulate migration of business units. Reports can be

run du ring testing from inside the p roject (information specific to the migrated objects) and globally

for the domain (information abou t the entire source domain). The DMA produ ct will record resu lts

(success and failur e) of the test m igration p rojects.

The DMA produ ct provides Project Wizards for migrating u sers, group s and machine accoun ts to a

Window s 2000 environment. It also supp orts Enterprise Adm inistrator Territories map ping into

Windows 2000 OU or NetIQ Directory and Resource Administrator ActiveViews.

For the Novell NetWare environment, NDS OU and resources will be mapp ed d irectly into MSActive Directory. The NetIQ NetWare Migrator is able to recreate the existing N DS hierarchy.

The recommen ded steps are:

• Test the execution of the migra tion p roject.

• Record a ll issues encountered to a dd ress in subsequent trials.

• Test all app lications and serv ices in Wind ows 2000 environm ent, including Active Directory

security a nd file perm issions, Exchange, and custom ap plications.

• Check that monitoring tools continue to w ork.

• Create a gu ideline checklist for the actual migration .

Phase 3: Domain/Users and Server Resource MigrationAt this point, you are ready to actually begin the m igration of dom ains and u sers to servers. The

minimum requirements are:

• Existing Wind ows N T 4.0 environment as d escribed in the p re-migration state.

• New Window s 2000 environment as described in the post-migration.

• Dynamic DNS environment.

• NetIQ Domain Migration Adm inistrator

When executing the Domain Migration Ad ministrator Project, be sure to:

• Backup every server involved in the migration and verify the backup s.

• Use the checklist genera ted in Phase Two of migra tion for consistency.

• Make use of contingency plans generated in Phase Two.




Phase 4: Desktop/Workstation MigrationThe next step is to perform th e migration of desktops and workstations.

Migrating workstation accounts to Windows 2000•

Use minimum h ardw are requirements and compatibility results from Phase One.• 96 to 128 MB of RAM is often required for optim um per forman ce.

• Confirm that p erformance on existing hard ware w ill be acceptable.

• Provide Window s 2000 training for you r end users as n ecessary.

Executing Domain Migration Administrator Project• Backup an y important d ata on workstation and verify the backup.

• Use the checklist generat ed in Phase Two of migra tion for consistency.

• Make use contingency plans generated in Ph ase Two.

Installing Windows 2000 on user Workstations• A desktop rollout is beyond the scope of workstation migration.

• Workstations can also be up grad ed to Wind ows 2000 preserving the Window s NT 4.0

configurations and settings.

Phase 5: Post-Migration Testing and CleanupUpon completing the migration, both the Window s NT 4.0 environment and the Window s 2000

environmen t will be operational. Users can be grad ually moved to the new environment.

After completing the m igration u sing the p roject plan:

• Re-test everything in the new Window s 2000 environmen t.

• Confirm that u sers can login an d app lication servers can be accessed.

• Confirm correctness of AD secur ity functions.

• Move a small subset of users to the new en vironment as a pilot.

• After a su ccessful p ilot, remaining users can be migrated to the Wind ows 2000 environment.



14 White Paper

Common Issues That Effect Migration

There are two common issues that account for a ma jority of problems encoun tered d uring th e

execution of a migration project:

• Connectivity

• Permissions

ConnectivityNam e resolution and connectivity are imperative for a successful m igration p roject testing and

execution. The migration d ispatcher COM object will requ est the location of specified resources for

installation of the ActiveAgent. If the WINS database has an outd ated entry or d oes not have an

entry for the d esired resou rce, the d ispatcher cannot copy files and install the ActiveAgent. The

migration d ispatcher will report any errors du e to nam e resolution or connectivity (rc=53 The network

name could not be found or rc=67 The shared resource does not exist ).

Note that WINS must be configured in a Wind ows 2000 environment w ith Windows N T 4 clients. In

add ition, the server service must be run ning on all systems to be contacted by the d ispatcher. Thedispatcher w ill attempt to connect to the Ad min$ share (adm inistrative share created by the Server

service).

PermissionsIn order to install the ActiveAgent componen t on remote m achines, the user account being u sed to

perform the migration mu st have Adm inistrator auth ority on the system wh ere the comp onent is to

be installed.

Determine if Domain Ad mins grou p of source dom ain is a member of local Administrators group for

all machines going to be translated and / or migrated (domain mem bership change). The migration

dispatcher will report any errors due to insufficient permissions (rc=5 Access is denied).

Additional Information to Consider

This section provides ad ditional information abou t the migration p rocess and related Window s 2000

technologies.

Understanding SID HistorySID History allows a u ser to retain access to resources protected by local groups and ACLs containing

the pre-migration source user and g roup SIDs. In a native mode Wind ows 2000 dom ain, user

interactive logon creates an access token containing th e users p rimary SID and globa l group SIDs -- inadd ition to the u ser SID History and gr oup SID History values.

The requirements for imp lementing SID H istory are:

• Target domain mu st be Wind ows 2000 native mode.

• Migration mu st be run from DC in target dom ain.

• Source and d estination dom ains must not be in the same forest.




• Source domain mu st trust the target dom ain.

• Logged-in user mu st be a member of Domain Adm ins global group in target dom ain.

• Logged-in user mu st be member of Administrators group on source.

• Aud iting mu st be enabled on target domain (User/ Group m anagement events = success and

failure)

− Event ID 718 (success) and 719 (failure) are generated on th e target DC w hen SID History is

implemented d uring the migration process.

• Aud iting mu st be enabled on source dom ain (User/ Group m anagemen t events = success and

failure).

• Domain local group na med NetBIOS$$$ must exist on th e source dom ain

− No sp ecific event IDs are generated by the Wind ows N T 4 source PDC, so the

implementation of SID History can be au dited by mon itoring Local Group Mem ber Add

(Event ID 636) and Mem ber Delete (Event ID 637) aud it events in the source doma in and

searching for events referencing th e special group name, NetBIOS$$$.

• The migration source m ust be the PDC (in Window s NT 4.0) or PDC emu lator (in

Wind ows 2000).

• Source SAM mu st listen on TCP/ IP in ad dition to named pipes.

− Create secure chan nel with registry value on PDC (or emu lator):

HKLM/System/Current Control Set/Control/LSA – TCPIPClientSupport -

Reg_DWORD = 1

− Reboot the DC for the cha nge to t ake effect.

The Domain Migration Ad ministrator migration wizard will assess the requirements outlined in blue

du ring configuration. If not p resent, the operator can choose to configure the options before the

migration is executed. The wizard w ill not assess the credentials of the user executing th e migration,

the installation location of the DMA p rodu ct or the tru st configuration of the sour ce and tar get

domains.

Security Issues When Using SID History• If users and his related grou ps are migrated to the AD using SID History, the group membership

of the Windows N T groups m igrated becomes static.

− If the user is then removed from the group in Windows N T the Wind ows 2000 user accoun t

will still have access to da ta that th is group has access to. This is because the SID of the u ser

accoun t has been ad ded to the SID History of the group in Window s 2000 and taking a u ser

out of the grou p in Wind ows N T doesn’t remove tha t user account SID from the SID History

of the group in Window s 2000. The Wind ows 2000 group has access to everything that the

Window s NT group has access to because of the SID History attribute of the Window s NT

group.

• Aud iting (File, Registry, etc) is not tracked on a ccoun ts (users and grou ps) that have access to

data based on SID History attributes

− For examp le, a u ser account that is migrated to Window s 2000 using SID History and

aud iting is set up on a d irectory for his old account. If he then m akes changes to d ata in this

directory using his Wind ows 2000 accoun t, there will be no entries in aud it log on the system

he is accessing.



16 White Paper

• Window s NT tools (Explorer) only show that the source d omain accounts hav e access to

resou rces, even though via SID History Wind ows 2000 account also have access.

• Wind ows 2000 tools (Explorer) only show th at the ta rget d omain account h as access to objects (it

tran slates SID History), even th oug h Wind ows N T 4.0 accounts also hav e access.

• Once the last PDC is removed from th e source doma in, accounts from that d omain w ill not be

shown with access using Window s NT tools. Then, perm issions will show an u nknow n accoun tor no account p ermissions will be displayed.

Technical Issues When Using SID History• SID information for each u sers and all of the grou ps they ar e a mem ber of is add ed to th e target

user or g rou p -- increasing th e size of the Active Directory

• All SID histories and group mem bership s can have a total of 1,023 attribu tes.

• Kerberos au then tication packets size issue. (For m ore informa tion, see TechNet ar ticle Q263693 ).

Partial List of Windows 2000 Technologies

• Messaging (Exchange)

• Remote Access Services (RAS)

• Active Directory Services

• Clustering for High Availability

• Distributed File System

• Windows NT Distributed Security Services, Security Support provider interface

• PPTP and L2TP Private Networks

• Microsoft Transaction Server

• Microsoft Message Queu e Server

• Microsoft Certificate Server

• Microsoft Index Server• Wind ows N T File System

• Windows NT Directory Services Client Support

• Kerberos Secur ity w ith x.509 certificate map ping




Migration Checklists

Inter-Forest Migration: Native Mode Windows 2000 Target

Required Configuration Items:

Task

1. Verify that name resolution is functioning:

! DNS – required for the Active Directory. Usenslookup command line utility toverify name resolution

! WINS – required for Windows NT 4 clients and servers

2. Verify that domains and systems to be migrated are online and available:

! Browse My Network Places for domains and systems to be migrated

3. Verify that the source domain trusts the target domain:! This is required for appending the SID History attribute to the target domain

account.

4. Select account to be used for migration:

! Must be an Administrator in the source and target domains.

! Must be a member of the Domain Admins group in target. This is required forappending the SID History attribute to the target domain account.

! Must have the Permissions Admin role for the Exchange site to be translated.

5. Login to Domain Controller of target domain with selected account:

! Install NetIQ Domain Migration Administrator on DC of target domain. This is

required for appending the SID History attribute to the target domain account. 6. Verify Access 2000 is installed:

! Access 2000 run-time is included on the DMA installation CD.

7. Create MAPI profile for mailbox on Exchange Server in site to be translated.



18 White Paper

Optional Configuration Items:

Task

1. Verify that Admin$ share exists on all systems to be migrated:

! Created by the server service automatically unless disabled.

! Can only be accessed by Administrators.

2. Verify that target domain trusts source domain:

3. Select account in source domain that is member of Domain Admins group.

! This account can be used to change the domain membership of workstations.

! Account must be in local Administrators group of every workstation (explicitly orby global group membership).

Inter-Forest Migration: Mixed Mode Windows 2000 or Windows

NT 4 Target


Task





!Browse My Network Places for domains and systems to be migrated



! Must be a member of the Domain Admins group in target. This is required forappending the SID History attribute to the target domain account.


4. Select system to be used for migration console and dispatcher:

! Must be Windows 2000 – Server or Professional

5. Login to selected machine with selected account:

! Install NetIQ Domain Migration Administrator

6. Verify Access 2000 is installed:







Task




Intra-Forest Migration: Native Mode Windows 2000 Target


Task


! DNS – required for the Active Directory. Usenslookup command line utility to

verify name resolution! WINS – required for Windows NT 4 clients and servers


! Browse My Network Places for domains and systems to be migrated



! Must be a member of the Domain Admins group in target. This is required forappending the SID History attribute to the target domain account and using theMoveObject API.


4. Login to Domain Controller of target domain with selected account:

! Install NetIQ Domain Migration Administrator on DC of target domain. This isrequired for appending the SID History attribute to the target domain account.

5. Verify Access 2000 is installed:





20 White Paper


Task




2. Verify that target domain trusts source domain.

3. Select account in source domain that is member of Domain Admins group.

! This account can be used to change the domain membership of workstations.

! Account must be in local Administrators group of every workstation (explicitly orby global group membership).

NetWare/NDS to Windows 2000/Windows NT 4


Task




2. Ensure Windows 2000 system running the NetIQ NetWare Migrator has the Novell

Win32 client version 4.7 or greater:

! Should run the NetIQ NetWare Migrator on the Windows 2000 file server if files

are being transferred to reduce the number of file copies over the wire.


! Must be an Administrator in the target domain and on the target file server.

! Must be an Admin (or Supervisor) for the NetWare account.

migrating windows 2000

Documents