Tài liệu Module 5: Restructuring Domains pdf

„#Cloning Security Principals On each page, explain the process and implications of cloning users, global and universal groups, computers and local group accounts, and local groups on do

products, people, characters, and/or data mentioned herein are fictitious and are in no way intended

to represent any real individual, company, product, or event, unless otherwise noted Complying with all applicable copyright laws is the responsibility of the user No part of this document may

be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation If, however, your only means of access is electronic, permission to print one copy is hereby granted

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2000 Microsoft Corporation All rights reserved

Microsoft, MS, Windows, Windows NT, Active Directory, and Windows 2000 are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted

Other product and company names mentioned herein may be the trademarks of their respective owners

Project Lead/Instructional Designer: Sangeeta Garg (NIIT (USA) Inc.) Lead Program Manager: Angie Fultz

Instructional Designer: Robert Deupree (S&T OnSite) Subject Matter Expert: Brian Komar (3947018 Manitoba Inc) Technical Contributors: John Pritchard, Greg Parsons, David Cross, Rodney Fournier, Tony de

Freitas, Christoph Felix, Shaun Hayes, Megan Camp, Richard Maring, Glenn Pittaway, Anne Hopkins, Bob Heath, Jeff Newfeld, Jim Glynn, Paul Thompson (Mission Critical Software, Inc.), David Stern, Lyle Curry, Steve Tate, Bill Wade (Wadeware LLC)

Testing Leads: Sid Benavente, Keith Cotton Testing Developer: Greg Stemp (S&T Onsite) Testers: Testing Testing 123

Instructional Design Consultants: Susan Greenberg, Paul Howard Instructional Design Contributor: Kathleen Norton

Graphic Artist: Kirsten Larson (S&T OnSite) Editing Manager: Lynette Skinner

Editors: Marilyn McCune (Sole Proprietor), Wendy Cleary (S&T OnSite), Jane Ellen Combelic

(S&T OnSite)

Copy Editor: Shawn Jackson (S&T Consulting) Online Program Manager: Debbi Conger Online Publications Manager: Arlo Emerson (Aditi) Online Support: Eric Brandt (S&T Onsite)

Multimedia Development: Kelly Renner (Entex) Testing Leads: Sid Benavente, Keith Cotton Testing Developer: Greg Stemp (S&T OnSite) Courseware Testing: Data Dimensions, Inc

Production Support: Lori Walker (S&T Consulting) Manufacturing Manager: Rick Terek (S&T Onsite) Manufacturing Support: Laura King (S&T Onsite) Lead Product Manager, Development Services: Bo Galford Lead Product Managers: Dean Murray, Ken Rosen Group Product Manager: Robert Stewart

This module provides students with knowledge and ability to restructure

domains

At the end of this module, students will be able to:

„#Describe the components of domain security and resource access

„#Describe inter-forest restructure scenarios

„#Examine the implications of inter-forest restructuring on security principals

„#Describe intra-forest restructure scenarios

„#Examine the implications of intra-forest restructuring on security principals

„#Describe and compare the various domain restructure tools

0DWHULDOV#DQG#3UHSDUDWLRQ#

This section provides you with the required materials and preparation tasks that are needed to teach this module

5HTXLUHG#0DWHULDOV#

To teach this module, you need the following materials:

„#Microsoft® PowerPoint® file 2010A_05.ppt

„#Module 5, “Restructuring Domains”

3UHSDUDWLRQ#7DVNV#

To prepare for this module, you should:

„#Read all of the materials for this module

„#Complete the lab

„#Read all of the delivery tips

„#Read the white paper, Planning Migration from Microsoft Windows NT to Microsoft Windows 2000, on the Student Materials compact disc

„#Read chapter 9, “Planning the Active Directory Structure,” of the Windows

2000 Server Deployment Planning Guide on the Student Materials compact

disc

„#Read chapter 10, "Determining Domain Migration Strategies,” of the

Windows 2000 Server Deployment Planning Guide on the Student Materials

Use the following strategy to present this module:

„#Introduction to Domain Restructuring The module begins with a summary of what a domain restructure is Give a brief explanation of what inter-forest and intra-forest restructuring are and when students can perform them In your introduction, you may want to review the reasons why an organization might choose domain restructure and the benefits of this migration path

„#Understanding Domain Security Explain what a security identifier (SID) is

Students may ask what credentials are required for logon authentication A user provides the system with the following set of credentials: the user name, the domain to be logged on to, and a password (or smart card) Remind students that discretionary access control lists (DACLs) exist on files, shares, the registry, and Active Directory™ directory service objects Emphasize that the authorization process is automatic and transparent to users

Students may ask what the difference is between SIDs, relative identifiers (RIDs), object identifiers, and globally unique identifiers (GUIDs) Be prepared to define these terms for them

Emphasize that in an inter-forest scenario, user, global, and shared local

group accounts are cloned by using the ClonePrincipal utility or the Active Directory Migration Tool (ADMT), while computer accounts are moved by

using Netdom or the ADMT

Explain the requirements and restrictions that apply for inter-forest restructuring The lab takes students through each of the steps in preparing the environment for restructuring

„#Cloning Security Principals

On each page, explain the process and implications of cloning users, global and universal groups, computers and local group accounts, and local groups

on domain controllers Students may find this section more interesting if you use the ADMT to demonstrate cloning operations for each type of security principal

Describe the intra-forest restructure scenarios Make sure that students

understand that objects are moved between domains of the same forest

Objects cannot be cloned in this scenario

Explain the requirements for intra-forest restructuring Intra-forest restructuring is not covered in the hands-on lab, and you will not be able to demonstrate these operations

„#Moving Security Principals Explain the implications of using closed sets to move users and global groups, domain local groups, computers and local accounts, and domain controllers Computers, local accounts, and domain controllers are moved in the same way in an intra-forest scenario as they are in an inter-forest scenario

Emphasize that moving a security principal between domains has the effect

of changing the security principal’s SID, just as cloning an account does

„#Domain Restructure Tools Describe and compare the tools for domain restructuring

This section is an overview of the migration tools that Microsoft provides The characteristics and functionality of each tool differ widely Encourage students to thoroughly investigate and test each tool prior to beginning their migrations

Students may have questions about the details and specific functionality of each tool Tell them that they can refer to the migration tools comparison table on the Student Materials compact disc Be sure also to point students

to the Help files, where they can obtain additional information on the tools Consider demonstrating the ADMT interface, showing the list of wizards available

You may want to mention third-party migration tools that Microsoft endorses, which can be found on the Microsoft Web site

The purpose of this module is to explain how to restructure domains and to discuss the implications that restructuring domains has on security principals The module also explains some restructure scenarios that facilitate the movement of users and resources from a Microsoft® Windows NT® version 4.0 source domain to a Microsoft Windows® 2000 target domain, or from a Windows 2000 domain in one forest to a Windows 2000 domain in another forest The remainder of this module describes the various tools that assist you

in restructuring your domains during migration

At the end of this module, you will be able to:

„#Describe the components of domain security and resource access

„#Describe inter-forest restructure scenarios

„#Examine the implications of inter-forest restructuring on security principals

„#Describe intra-forest restructure scenarios

„#Examine the implications of intra-forest restructuring on security principals

„#Describe and compare the various domain restructure tools

Domain restructuring can involve inter-forest copy operations or intra-forest move operations In inter-forest restructuring, security principals are copied from a Windows NT 4.0 domain to a Windows 2000 domain, or from a Windows 2000 domain in one forest to a Windows 2000 domain in another forest Intra-forest restructuring involves moving security principals from one Windows 2000 domain to another in the same forest

There are specific issues with restructuring security principals from a Windows NT 3.51 domain For more information, refer to the white paper,

Planning Migration from Windows NT to Windows 2000, which is located on

the Student Materials compact disc

Access Token

Groups: S-1-5-21-645522239-1957994488-725345543-1108

S-1-5-21-397955417-626881126-188441444-101018 S-1-5-21-645522239-1957994488-725345543-1109

Allow R W S-1-5-21-645522239-1957994488-725345543-1108

SIDhistory grants access for moved user

User’s primary SID

User’s primary SID

sIDHistory of user

sIDHistory of user

SIDs of groups to which user belongs

SIDs of groups to which user belongs

ACL on source shared folder

Windows NT 4.0 and Windows 2000 domain security depends on security

identifiers (SIDs) SIDs are domain-specific identifiers that the operating

system uses to distinguish security principals, such as users, groups, and computers While the user interface displays security principals as names, the operating system maps these names to SIDs for logon authentication,

permissions assignment, and resource authorization

When logging on, authenticating users present to the system a set of credentials, including their display user names If the credentials match those that the system has on record, the user is authenticated and granted an access token The access token is a key that enables access to network resources It consists of a list of SIDs that identify the user and the groups of which he or she is a member, in addition to the various system rights granted to the user

Discretionary access control lists (DACLs), which administrators use to define access permissions on resources, contain user and group SIDs and the access permissions granted to each security principal When a user attempts to access a resource, his or her access token (granted at logon), together with the type of access requested (read, write, and so on), is compared with the SIDs in the DACL of the resource being requested If the SIDs match, the user is granted the permissions defined in the DACL

5HVROYLQJ#6,'V#$IWHU#5HVWUXFWXULQJ#

SIDs are specific to domains The only way to move or copy a security principal between domains is to create a new object in the target domain Creating a new security principal in the target domain assigns a new SID to the object Prior to Windows 2000, granting resource access to the new security principal required searching the source domain and trusting domains looking for references to the old SID, and then adding the new SID to resource DACLs

sIDHistory makes this situation considerably easier sIDHistory is an attribute

of security principal objects that is used to store the former SIDs of restructured security principals The sIDHistory value ensures that appropriate access is granted after restructuring, even on systems that predate Windows 2000 or Active Directory

The sIDHistory attribute of a migrated object is updated with its former SID as part of the migration operation When the user logs on to the system with a migrated account, the system retrieves the user’s primary SID and the entries in the user’s sIDHistory and adds them to the user’s access token Because groups are security principals with a sIDHistory attribute, the sIDHistory of all the groups of which the user is a member is also added to the user’s access token when he or she logs on

The value of the sIDHistory attribute can be populated only in native-mode Windows 2000 domains, which has the effect of requiring all migration operations relying on sIDHistory to have a native-mode target domain for restructure

,PSRUWDQW#

Inter-forest restructuring is sometimes referred to as prune and graft, a more

complex migration scenario used to relocate security principals between two Windows 2000 forests in cases of corporate mergers or acquisitions

Restructuring a Windows NT 4.0 account domain involves incrementally

copying users and groups from a Windows NT 4.0 account domain to a parallel

Windows 2000 Active Directory environment This environment operates in tandem with the existing Windows NT 4.0 network and reflects the forest proposed by the Active Directory design

In this scenario, Windows NT 4.0 user, global, and shared local group accounts are copied from the source domain to the pristine environment While this migration path is more expensive because of the hardware requirements of creating a duplicate environment, it ensures that you can recover from problems during migration because the original accounts remain untouched during the process This scenario can also preserve existing security until cloned account access is fully tested by migrating the sIDHistory After the users and groups have all been copied to Active Directory, the environment has been tested, and the new accounts are in use, the Windows NT 4.0 domain can be

decommissioned

5HVWUXFWXULQJ#D#:LQGRZV#17#713#5HVRXUFH#'RPDLQ#

An inter-forest scenario may also involve restructuring resources Collapsing a Windows NT 4.0 resource domain into an organizational unit (OU) in a destination Windows 2000 domain reduces the number of domains and the administrative cost of managing trust relationships

In this scenario, a combination of copying and moving techniques is used to restructure the resource domain Computer accounts for workstations and member servers are moved or copied to the destination domain Shared local groups residing on a Windows NT 4.0 domain controller must also be cloned to the target domain

„#Upgrading to Windows 2000 server, whereupon they can join the Active Directory forest as a member server or domain controller, or

„#Demoting to a member server, which requires reinstalling Windows NT 4.0 Then the member server account can be moved to the Active Directory forest

After all accounts have been migrated and resource servers have joined the forest, you can completely decommission the Windows NT 4.0 resource domain

You cannot truly combine forests because there is currently no way

to merge the schemas of separate Active Directory forests

,PSRUWDQW#

Be sure to restart after making this change to the server

„#The user performing the restructure operation must be a member of Domain Admins in the target domain and have administrative privileges in the source and target domains

„#Account auditing must be enabled on both the source and target domains

For a Windows NT 4.0 domain, success and failure Group Management

auditing must be enabled on the primary domain controller (PDC) For a Windows 2000 domain, Audit account management must be enabled on the Default Domain Controllers Policy

„#A local group, sourcedomainname$$$, must be created in the source

domain; for example, Contoso$$$ This group is used for auditing and must

„#The source domain must not be in same forest as the target domain

„#The source object must be a user account or security-enabled group

„#The SID of the source object must not already exist in the target forest, either as a primary account SID or in the sIDHistory of an account

Certain objects, such as built-in groups and accounts that have well-known SIDs or well-known relative identifiers (RIDs), cannot be

migrated For details on these accounts, see the white paper, Planning Migration from Microsoft Windows NT to Microsoft Windows 2000, on the

Student Materials compact disc

„#The migration tools must be run on the target domain controller Physical access to the target computer is required unless Windows Terminal Services are used to run tools remotely

Cloning is not possible between domains in the same forest

Although a clone has a different primary SID than the source account, the sIDHistory attribute retains the SID of the source account Populating the sIDHistory attribute with the SID of a source account allows the clone the same

access to network resources available to the source account, provided that

appropriate trusts exist from the resource domains to the clone’s account domain

One advantage to cloning is that it does not disrupt the existing production environment Users are cloned to a parallel environment, allowing them to log

on by using their cloned account in Active Directory while maintaining the

ability to fall back to the source account from the production environment, if

necessary, until the target domain is decommissioned

Cloning is only possible between domains in different forests forest) Moving objects while updating sIDHistory is only possible between domains in the same Windows 2000 forest (intra-forest)

You use ClonePrincipal and the Active Directory Migration Tool (ADMT) to clone user accounts for inter-forest restructuring

When you clone user accounts with the ClonePrincipal utility, the source accounts are automatically disabled You can configure the ADMT to disable either the source or target account

Not all source account properties are copied during cloning operations For more information on the properties that are copied during migration, see the

white paper, Planning Migration from Microsoft Windows NT to Microsoft Windows 2000, on the Student Materials compact disc

„ &ORQLQJ#*OREDO#DQG#8QLYHUVDO#*URXSV#3RSXODWHV#WKH V,'+LVWRU\ 9DOXH#RI#WKH#1HZ#&ORQHG#$FFRXQW

„ &ORQHG#*URXS#0HPEHUVKLS#,V#$XWRPDWLFDOO\#5HVWRUHG#WR#

5HIOHFW#7KDW#RI#WKH#6RXUFH#$FFRXQW

When cloning global or universal groups, the primary SID of the source group

is retained as the sIDHistory value of the new cloned account The membership

of the target group is restored to reflect that of the source account if member clone accounts exist If the member accounts are cloned after the group, membership is restored at that time This is also true for nested groups when cloning from a Windows 2000 source domain

You use ClonePrincipal and the ADMT to clone group accounts for inter-forest restructuring

During the cloning operation, you can merge multiple source groups into a single target group When collapsing multiple Windows NT account domains into the same Windows 2000 domain, this feature has the advantage of allowing global groups to be combined

As a part of the local Security Accounts Manager (SAM) database, local group accounts and their properties are migrated when the computer on which they reside joins the target domain This means that local groups are unaffected by migration, so their SIDs do not need to be changed

Local groups provide access to resources on the computer on which they reside Permissions granted to local groups in resource DACLs on the moved computer will be maintained Resource access will continue to function properly,

provided that appropriate trusts to the target domain exist

If local groups contain members from trusted domains, trusts must exist between the target domain and any domains from which local group members reside

When a shared local group is cloned, the sIDHistory of the former account is retained, and a domain local group is created in the target domain Shared local groups are converted to domain local groups when cloned because the target domain is in native mode

To clone shared local groups, the ADMT tool is recommended because it is the easiest and most comprehensive way to migrate local groups The ADMT will copy the local group and populate its membership automatically if the member accounts are migrated at the same time

Retaining membership in cloned shared local groups is more complex when using ClonePrincipal, as opposed to using the ADMT See the Windows 2000 Support Tools Help files located in the support folder on the Windows 2000 Server compact disc for more information

To ensure that resource permissions granted to the cloned local group still function, you must establish appropriate trusts If the shared local group contained members from trusted domains, you must establish a trust between the target domain where the clone account resides and the domain where the group members reside

The Netdom and ADMT utilities can assist in identifying and establishing the appropriate trusts when cloning shared local groups

„ 7R#0RYH#:LQGRZV#17#713#'RPDLQ#&RQWUROOHUV=

z 8SJUDGH#WKH#GRPDLQ#FRQWUROOHU#WR#:LQGRZV#5333#6HUYHU#

DQG#WKHQ#FRQILJXUH#LW#WR#MRLQ#WKH#WDUJHW#GRPDLQ 25

be moved Moving domain controllers is one of the final steps in inter-forest domain restructuring and, in effect, decommissions the source domain

If the domain controller is a Windows NT 4.0 PDC or BDC, there are two ways

to move the computer:

„#Upgrade the domain controller to Windows 2000 Server When the Active Directory Installation wizard runs, you can configure the computer to join the target domain

„#Reinstall the server as a Windows NT 4.0 member server, at which point the server’s computer account can be moved in the same way that other

computer accounts are moved Once the server is a member of the target domain, it can be maintained as a member server or be promoted as a replica domain controller to support the target domain

When upgrading domain controllers, you must always upgrade the PDC first

If you are moving a BDC that is also an application server and you select to reinstall it as a member server, make sure that all application data is backed up prior to the upgrade and then restored after the operating system re- installation is completed

The only one way to move Windows 2000 domain controllers is to demote the domain controller to a member server, whereupon the member server can join the target domain, or the account may be moved by using the Netdom or ADMT utility in the same way that other computer accounts are moved

to perform the more complex Active Directory redesigns required by a corporate reorganization

Over time, accounts may need to be moved between domains when a user transfers from one division of an organization to another Changes in business needs may influence more dramatic changes in the forest design (such as merging domains to create a smaller Active Directory), prompting postmigration intra-forest restructuring

Moving is the only migration operation in an intra-forest scenario Moving security principals between Windows 2000 domains imposes a certain amount

of risk to the production environment and does not provide fallback, because in

a move operation the source account is deleted

„ 7DUJHW#'RPDLQ#0XVW#%H#D#1DWLYH#0RGH#:LQGRZV#5333#'RPDLQ

„ 6RXUFH#'RPDLQ#&RQWUROOHU#0XVW#+DYH#WKH#)ROORZLQJ#5HJLVWU\#(QWU\

HKEY_LOCAL_MACHINE | System |CurrentControlSet | Control | LsaTcpipClientSupport:REG_DWORD:0X1

„#The target domain must be a Windows 2000 native-mode domain

„#The source domain controller’s registry must contain the following registry entry:

HKEY_LOCAL_MACHINE | System | CurrentControlSet | Control | Lsa TcpipClientSupport: REG_DWORD:0X1

„#The user performing the restructure operation must have administrative privileges in the source and target domains

„#Auditing must be enabled in both the source and target domains

„#Source object must not be a built-in account

Because built-in groups have well-known SIDs and RIDs, they cannot be moved

„#The SID of the source object must not already exist in the target domain, either as a primary account SID or in the sIDHistory of an account

„#Administrative shares must exist on the computer where the ADMT is running and any computer where the ADMT must install an agent

In intra-forest scenarios, you may run the migration tools on a target or source domain controller

To ensure that access permissions are maintained during an intra-forest restructuring, the underlying APIs used to move objects apply a constraint,

called closed sets, on these operations A closed set is a block of accounts that

are moved at the same time

MoveTree and ADMT move security principals and provide the ability to retain the source account SID in the target account sIDHistory attribute Including the source account SID in the target account sIDHistory attribute provides

continued resource access to moved accounts

Cloning is not possible in intra-forest migration scenarios because one SID would be associated with two security principals

If a global group contains other global groups—as can be the case with a Windows 2000 native-mode source domain—for each nested group, all of its members must be moved, including the membership of all nested groups

„ )RU#(DFK#'RPDLQ#/RFDO#*URXS#%HLQJ#0RYHG/#$OO#'RPDLQ#

&RQWUROOHUV#LQ#WKH#'RPDLQ#&RQWDLQLQJ#'$&/V 5HIHUHQFLQJ#WKH#*URXS#$UH#$OVR#0RYHG

in the source domain will be irresolvable Closed sets are used to prevent this from occurring To preserve group membership and retain resource access:

„#For each domain local group being moved, all domain controllers in the domain with resource DACLs referencing the group are moved at the same time

„#For each domain controller being moved, all domain local groups referenced

in DACLs on its resources are moved at the same time

There are three possible approaches to addressing closed set issues:

„#Create parallel groups This involves creating parallel global groups, instead

of moving groups, in the target domain Because the parallel group does not contain the sIDHistory of the source group, additional steps are required First, the new group membership must be defined Then, all resources in the enterprise containing DACLs referencing the original group must be modified to include permissions for the parallel global group that match the source global group

„#Leverage universal groups This involves changing the group type to universal of the groups to be moved Because universal groups have scope across the entire forest, such a change allows them to be safely be moved, in addition to retaining their membership and maintaining access to resources left behind After the restructure has been completed, the group types can be changed back to their original types

Be cautious when using this approach The membership of universal groups is stored in the global catalog, and when universal group membership changes, the entire group membership is replicated throughout the forest

„#Reconsider your migration strategy Cloning or copying security principals does not impose the use of closed sets However, cloning only works when

copying accounts between forests To avoid the restrictions of closed sets,

restructure directly from an existing Windows NT 4.0 domain or separate Windows 2000 forest

Moving computer accounts in an intra-forest scenario is functionally the same

as moving computer accounts in an inter-forest scenario Workstations and member servers have their own SAM database If they are moved between domains, they always take this database with them

Local user accounts are unaffected when moving a computer account in an intra-forest restructure Local group accounts defined on workstations and member servers always move with the computer and are unaffected by the move operation Local groups containing accounts from trusted domains are also unaffected by the move

Local groups provide access to resources on the local computer on which they reside Permissions granted to local groups in resource DACLs on the moved computer will be maintained Resource access will continue to function properly, provided that appropriate trusts to the target domain exist

If local groups contain members from trusted domains, trusts must exist between the target domain and any domains from which local group members reside

Computer accounts can be moved remotely with the ADMT and Netdom, or a user at the local computer can join the new domain manually

Moving domain controllers in an intra-forest scenario is functionally the same

as moving domain controllers in an inter-forest scenario Moving a Windows

2000 domain controller requires that it be demoted to a member server, whereupon the member server can join the target domain or the account can be moved using the Netdom or ADMT utility

Once the server is a member of the target domain, it can be maintained as a member server or promoted as a replica domain controller to support the target domain

„#Active Directory Migration Tool (ADMT) ADMT is a strategic tool for

facilitating migration operations for both inter-forest and intra-forest restructuring

„#ClonePrincipal ClonePrincipal is a set of scripts that clone users and

groups to the new Windows 2000 environment It facilitates inter-forest migration

„#Netdom Netdom is a command-line utility that can be used to query a

domain for trust relationships and create new trust relationships automatically Netdom can also be used to add, move, and query computer accounts in a Windows domain It facilitates both inter-forest and intra-forest migration operations

„#Ldp Ldp is a graphical tool that uses Lightweight Directory Access

Protocol (LDAP) to allow an administrator to display the attributes of any object in Active Directory By displaying the sIDHistory of a cloned principal, this tool validates that security principles have been migrated correctly

„#MoveTree MoveTree is a command-line utility that moves Active Directory

security principal objects, such as groups and users, between domains in a single forest

For details about the specific functionality of each tool, see the migration tools comparison table on the Student Materials compact disc

The ADMT is available for download on the Windows 2000 Web site at http://www.microsoft.com/windows2000

The ADMT copies and moves user accounts, groups, and computer accounts from one domain to another, populating the sIDHistory attribute of migrated security principals It can then resolve the related file, directory, and share security issues for the copied accounts by redefining permission on source resources that have not been migrated ADMT is a comprehensive tool that allows you to analyze the migration impact both before and after the actual migration process It also allows you to test migration scenarios before you perform the migration

The following table lists and describes the key features of ADMT

Feature Description

Reporting The tool provides a number of predefined reports, including:

Migrated users and computers

Expired computer accounts

Accounts referenced in DACLs

Name conflicts

Fallback capability The tool allows many operations to be undone to provide

fallback to an original state

Localized The tool is localized into the Windows 2000 Server