Tài liệu Microsoft Active Directory Migration Tool pptx

1

Release Notes
This document provides late-breaking or other information that supplements the
Microsoft
® Active Directory™ Migration Tool online Help documentation.
Information in this document, including URL and other Internet Web site
references, is subject to change without notice. Unless otherwise noted, the
example companies, organizations, products, people, and events depicted herein
are fictitious and no association with any real company, organization, product,
person, or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced
into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without
the express written permission of Microsoft Corporation.
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.
© 2002 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Windows, and Windows NT are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or
other countries/regions.
The names of actual companies and products mentioned herein may be the
trademarks of their respective owners.

Contents
How to View This Document
Installation

ADMT Installation
Password Export Server Installation
New Feature In ADMT Version 2.0
Microsoft Active Director
y

Migration Tool
2 Microsoft Windows 2000 Professional, Server, and Advanced Server

Known Issues
ADMT
User Migration
Group Migration
Service Account Migration
Trust Migration
Computer Migration
User Profile Migration
Password Migration
Report Creation
Retry Wizard
Online Help
Active Directory Migration Tool Remote Agent Software
Active Directory Migration Tool Migration Database
Intraforest Migration
Command line Tool
Scripting Component

How to View This Document
To review the latest release notes, the Domain Migration Cookbook, and other
updated information for Active Directory Migration Tool, see the Domain

Migration Web site at:
/>
ADMT Installation
This section describes a known issue related to the installation of this version of
Active Directory Migration Tool.
ADMT Version 1.0 will Install Over Version 2.0
ADMT Version 1.0 will install itself over Version 2.0 without warning the user.
ADMT Version 2.0 Installation will preserve the ADMT
Version 1.0 Database.
When upgrading, ADMT v.2 will upgrade the internal database to a new version
of the Microsoft Access database. The installation will copy the old database to a
file named protar3x.mdb. Should the upgrade fail, ADMT v.1 can be reinstalled.
To use the current database again, rename protar3x.mdb to protar.mdb.
Microsoft Windows 2000 Release Notes 3

Installing Active Directory Migration Tool in a Terminal
Server Session
The Active Directory Migration Tool installation program may not install
successfully in a terminal server session. Internal error 2755 occurs. If you
experience this behavior, cancel the installation, copy the ADMT installation files
to the terminal server, and restart the installation.
Installation of ADMT on i64-Bit Computers not supported
This version of ADMT is not supported on 64-Bit computers. This issue will be
addressed in a later version of ADMT.
Rights needed to run ADMT
Local administrator rights are required on the local server to run ADMT. If
ADMT runs on a domain controller, domain admins or administrator rights are
required. If ADMT runs on a member server, local administrator rights are
required.
Password Export Server Installation

This section describes the requirements for installing and using a Password Export
Server (PES) to perform password migration with ADMT. You can find more
detailed information in the Domain Migration Cookbook referenced under How
to View This Document.
1. We recommend that the source domain’s Password Export Server be a BDC
dedicated for this purpose.
2. 128-bit encryption must be installed on any PES.
3. 128-bit encryption must be installed on the machine running ADMT.
4. The Password Export Server installation will not complete without supplying
an encryption key created on the ADMT machine. The key must be available
on a local drive. This can be a floppy drive or a folder on the local hard drive.
Network mapped drives or shares are not allowed. It is recommended that you
transport the key via a floppy and either store the floppy in a secure location
or format it after the installation.
a. On the ADMT machine, run ADMT.exe from the command line
specifying “key” as the operation to perform (the syntax for this
command is “ADMT.exe key %Source_Domain_NetBIOSName%
4 Microsoft Windows 2000 Professional, Server, and Advanced Server

%folder%: %Optional Password% (i.e. “c:\admt.exe key srcdomain
a: pswrd”)). Type “ADMT.exe key” at the command line for more
usage information.
b. On the Password Export Server, make sure that the key is available
on a local drive, either by inserting the floppy disk or copying the
key to a local hard drive. You will be prompted on the Password
Export Server for the location of the key during the installation. You
will have to provide a matching password if one was given when
creating the encryption key on the ADMT machine.
1. The AllowPasswordExport registry key value (located in HKLM\
SYSTEM\CurrentControlSet\Control\Lsa on the Password Export Server)

must be set to “1” to allow ADMT to use that Password Export Server for
password migration. You can disable a Password Export Server from
supporting password migration by setting that same value to “0”.
2. “Everyone” must be added to the “Pre-Windows 2000 Compatible Access”
group on the target domain in order for password migration to succeed. If this
is not done, ADMT will log an “Access Denied” error. The command line
syntax for this is “NET LOCALGROUP "Pre-Windows 2000 Compatible
Access" Everyone /ADD” (The Active Directory Users and Computers snapin
will not allow you to add “Everyone” to this group).
3. Verify permissions on the server object. The PES requires that the “Pre-
Windows 2000 Compatible Access” group has “Read All Properties” rights
on the following object:
CN=Server,CN=System,DC=<domain_name>
4. Verify that anonymous access is allowed to domain controllers in the target
domain. Open the group policy editor for the domain, and navigate to the
following setting:
Default Domain Controllers Policy/Computer
Configuration/Windows Settings/Security Settings/Local
Policies/Security Options/Additional restrictions for
anonymous connections
Verify that either 'Rely on default permissions' or 'not defined'
is selected. If '
No access without explicit anonymous
permissions
' is selected, password migration to the target domain will fail
with “
Access Denied”.
5. If you are running ADMT on a .NET server, you also have to make sure that
the “Let Everyone permissions apply to anonymous users” right has been
enable on that machine, or that the Anonymous Logon user has been added to

the Pre-Windows 2000 Compatible Access group.
Microsoft Windows 2000 Release Notes 5

New Features in ADMT Version 2.0
Scripting and Command line interface
Most ADMT operations can now be performed via a scriptable interface or the
new command line (ADMT.exe) tool. TemplateScript.vbs is a template script that
is installed with ADMT and explains most of the interface. For usage help with
the command line tool, type “ADMT.exe”. The Undo Wizard is one of the more
significant wizards not available through these new interfaces. If an operation
that can be “undone” if performed through the wizards is performed through
scripting or the command line, it can still be “undone” through the Undo Wizard.
Password Migration
Passwords can now be migrated for inter-forest user migrations. ADMT uses a
Password Export Server (PES) in the source domain to perform that migration.
See the Password Export Server Installation section for more specifics and
requirements.
Migration Log Files
A single log file was used in ADMT v.1 to log migration results and issues. In
ADMT v.2, a new log file is created for each new migration operation. The most
current log file is migration.log. When a new migration is started, the old
migration.log file is renamed to migrationxxxx.log, where xxxx is the next
available sequence number. The second most current log file is the
migrationxxxx.log file, where xxxx is the highest number. ADMT v.2 will only
save a specific number of log files. By default, this number is 20. The number can
be changed through the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADMT\LogHistory: 20
Credentials needed for migration operations
ADMT v.1 has a hard-coded check that verifies that the account running ADMT
is an administrator in both the source and the target domain. ADMTv.2 will not

perform security checks anymore, but will leave this up to the operating system.
Note 1: When users are migrated and SIDHistory migration is selected, then the
underlying API enforces that the user running ADMT is an administrator in the
source domain and a domain admin in the target domain. Since this check is
enforced by the operating system, domain admin rights for SIDHistory migrations
are still needed in ADMT v.2.
6 Microsoft Windows 2000 Professional, Server, and Advanced Server

Note 2: In Windows .NET, SIDHistory migration can be delegated. The user who
migrates accounts with SIDHistory needs appropriate rights in the target
Organizational Unit (Create Users), plus the delegated extended right
MigrateSIDHistory on the domain object (DC=<domain_name>). When ADMT
v.2 runs against a Windows .NET domain controller, domain admin rights for
SIDHistory migrations will no longer be required.
Note 3: When user passwords are migrated, the user running ADMT must be an
administrator in the source domain.
Note 4: For agent-based operations like security translations or computer
migrations, local administrator rights are required on the target computer.
SID Mapping Files for Security Translation
ADMT can now perform security translation based on a comma-separated file
instead of just previously migrated object. The form of the comma-separated file
is “%Source Object%, %Target Object%” followed by a new line. Both objects
can take one of two forms 1) Domain\Username (but the domain must be
accessible) or 2) the decimal representation of a SID (i.e. S-1-5-21-1222312332-
327112949-1237804090-1056). The Account Reference report has been modified
to include an object SID in decimal form and can be used to help build this
mapping file. The Windows 2000 version of LDP.exe does not display the full
SID in decimal form. This has been fixed in the Windows .NET version of
LDP.exe.
Windows 2000 Attribute Exclusion

For inter-forest migrations, a list of attributes can be defined that will be excluded
in a user, group, or computer migration. There are three lists of attributes:
• Attributes always excluded by the system
• Attributes in the system exclusion list
• Attributes that can be excluded by the administrator
Attributes always excluded by the system
These attributes will always be excluded by ADMT. This is done to protect
system owned attributes and cannot be configured. The attributes are:
• Object GUID
• Object SID (but can be written to the SIDHistory)
Microsoft Windows 2000 Release Notes 7

• pwdLastSet
• userPassword (can be migrated by ADMT)
• isCriticalSystemObject
• LegacyExchangeDN
System Attribute Exclusion List
ADMT stores a system attribute exclusion list in its database. Attributes in this list
will be excluded from migration operations even if the attribute is not specified in
the attribute exclusion list. The list can be changed by the administrator through
any scripting language using the ADMT scripting interface. This is done to
protect attributes that are important for server-based applications to work, like
Exchange. By default, the following attributes are members of the system attribute
exclusion list:
• Mail
• proxyAddresses
The following is an example of a script that can be used to reset the System
Attribute Exclusion list to contain the attributes “Mail”, “proxyAddresses” and
“description”:
Set objMigration = CreateObject("ADMT.Migration")

objMigration.SystemPropertiesToExclude = "description,mail,proxyAddresses"

Attribute Exclusion List
This is a list of attributes that the administrator defines for every single migration.
The UI can be used to display and select the attributes. The UI keeps state
information; in other words if an attribute is added to the exclusion list, the UI
will add it to the list at the next migration by default. Scripting and command line
have no state information. The attributes must be defined for every single
migration operation, either through the attribute name or through an option file.
However, if an attribute exclusion list is used through the command line or
scripting interface, the state information used by the UI is updated with the
context of that list.
8 Microsoft Windows 2000 Professional, Server, and Advanced Server

Agent Credentials
Agent dispatch credentials are no longer required. Previously, ADMT prompted
the user for credentials used by the agent to report its results back to ADMT. Due
to a change in the architecture of the agents, the computer running ADMT will
now retrieve results from the agents. Therefore, credentials are no longer required.
Skip Membership Restoration
A “Fix Membership” option has been added to the User and Group Migration
Wizards so that performance can be vastly improved if group membership
reconstruction is not needed.
Decommission Source Domains
During security translation, ADMT v.1 has to communicate with the source
domain of the account that is referenced on an ACL. If the source domain is
decommissioned, the security translation fails. In ADMT v.2, all necessary
information will now be stored in the database. Therefore, the source domains can
be decommissioned, and security translations will still work.
If ADMT v.2 is installed as an update of ADMT v.1, ADMT v.2 will have to

update the database to a new format. ADMT v.2 will also have to add information
to the database to make this feature work. If an ADMT v.1 database is upgraded,
ADMT v.2 will perform the following operations:
• Prompt the user that ADMT v.2 will attempt to contact all source
domains from which objects had been migrated using ADMT v.1. The
administrator can then configure which domains should be excluded.
• Contact the domain and retrieve the necessary information.
This process will only happen when ADMT v.2 is run for the first time. Should a
source domain controller not be online at the time when ADMT v.2 is run for the
first time, the information can be added later. This is done by migrating an object
from the source domain to any target domain once a domain controller is online
again. This can also be a test migration only. If one migration or test run succeeds,
the database is updated, and domain controllers from the source domain will no
longer be needed for subsequent operations.
Microsoft Windows 2000 Release Notes 9

Known Issues
ADMT
Operating ADMT in a NetBIOS-less environment is not
supported
ADMT requires NetBIOS name resolution for all migration operations. This issue
will be addressed in a later version of ADMT.
If Install Path is empty, Installation Wizard shuts down
If the user changes the default installation path to an empty path and then clicks
Browse, the installation wizard will present a dialog box with “Error 2343” and
then shutdown. This issue will be addressed in a later version of ADMT.

User Migration
This section describes known issues related to migrating users with this version of
Active Directory Migration Tool.

Replaces Special Characters when Migrating Account
Names
ADMT replaces the following characters with an underscore character ‘_’ in the
pre-Windows 2000 name (SAM Account Name) and User Principal Name:
\"*+,/:;<=>?[\\]|
The period character (‘.’) is replaced with an underscore character (‘_’) if it is the
last character of the name.
List of Characters not allowed as a prefix/suffix
The following table lists the characters not allowed in a prefix or suffix. The SAM
column indicates characters that are invalid in a SAM account name. The DN column
indicates characters that need escaping in a distinguished name and/or a canonical
name and/or an ADsPath.

Character SAM DN
" X X
# X
$ X
* X
10 Microsoft Windows 2000 Professional, Server, and Advanced Server

+ X X
, X X
. X
/ X X
: X
; X X
< X X
= X X
> X X
? X

[ X
\ X X
] X
| X

Clicking Stop on the Migration Progress Page of the User
Migration Wizard Does Not Pause the Operation
When you click Stop on the Migration Progress page of the User Migration
Wizard, it does not pause the user migration operation even though the
verification message is displayed. This will be addressed in a future release.
Re-migrating Previously Migrated Users Updates the Group
Membership of the Target User Account
When you use the User Migration Wizard with the Replace conflicting accounts
option to migrate a user who has been previously migrated, any new groups that
the source account has subsequently been added to will be appended to the
original group membership of the user.
Example: Bob is a user in the domain HB-ACCT-WC. He is a member of the
group HB-ACCT-WC \Writers and is migrated along with the Writers and Editors
groups to the target domain hay-buv.tld (NetBIOS name HAY-BUV). After the
first migration, the following occurs:
1) HB-ACCT-WC\Bob is added to HB-ACCT-WC \Editors
2) HAY-BUV\Bob is added to HAY-BUV\TechEditors
Upon remigration, HAY-BUV\Bob will be a member of HAY-BUV\Writers,
HAY-BUV\Editors, and HAY-BUV\TechEditors.
This behavior is by design. If this behavior is not desired and you want to
completely reset the target account to only be a member of the source user’s
groups, you must delete the target domain user and migrate the source user again.
Microsoft Windows 2000 Release Notes 11

Undo Wizard Does Not Reset Properties on Target Users

and Groups After a Migration in Replace Mode
When the properties of a migrated user or group are changed in the target domain
and that same user or group is re-migrated with the Replace conflicting accounts
option, the Undo Wizard will not undo the change to the properties of the target
user or group. This is by design, because ADMT does not store attribute values
that are overwritten during a migration in replace mode.
User Names Using Double Byte Character Sets Cannot Be
Migrated with Password Same as User Name
User names consisting of characters from Double Byte Character Sets (DBCS)
should not be migrated using the Same as the user name password setting
option, because Windows 2000 does not accept DBCS passwords. When
migrating users with names containing DBCS characters, use the complex
password or copy password setting option.
Security Permissions on a User Migrated From a Windows
2000 Domain Are Reset to the Default Values During
Migration
When migrating a user from one Windows 2000 domain to another, the User
Migration Wizard creates a new security descriptor on the user object using
settings from the target domain (Default Security Descriptor defined for users in
the schema of the target forest and inheritable Access Control Entries on the target
Organizational Unit). The security tab is only visible for users if the
View\Advanced Features option has been selected. This is by design, because
security settings on the migrated user account should be dictated by the target
domain, not the source domain.
UPNs in Excess of 255 Characters in Length can cause the
ADMT to stop
During an inter-forest migration of user objects with a UPN attribute in excess of
255 characters in length, the migration progress dialogue can hang and state that
"the agent is no longer running." UPNs longer than 255 characters in length can
cause this behavior. The migration log file stops writing when the first +255

character UPN is read. UPNs longer than 255 characters are not supported in this
version of ADMT.
12 Microsoft Windows 2000 Professional, Server, and Advanced Server

User Account Control is not migrated if Password is not
migrated
If “copy password” is not selected during user migration, the user account control
is not migrated correctly. This issue will be addressed in a later version of ADMT.
Failure to set specific Attributes during User Migration are
not flagged as Errors
When the user who migrates user accounts does not have the rights to set specific
attributes on user objects, such as disable accounts or source account expiration,
the update on the attributes will fail. The failure is logged to the migration log
file, however, it is not flagged as an error. Therefore, the UI does not display this
as an error, and the failures are harder to find in the migration log. This issue will
be addressed in a later version of ADMT.
All Attributes are copied if Attribute Exclusion List has an
Error
If ADMT experiences an error while processing the Attribute Exclusion List, all
attributes on user and group objects are migrated. This issue will be addressed in a
later version of ADMT.
No Error Message when non-privileged Account is used for
SID History Migration
If the user enters credentials for an invalid account in the Credential Dialog box
for SID History migration, no error message is displayed by the UI, but SID
History migration fails. Invalid accounts include both accounts that are disabled
or accounts for which the "User must change password" option is selected. The
“Migrate SID History” option will be disabled until credentials for a valid account
are entered. This issue will be addressed in a later version of ADMT.
Wrong Error Message created during User Group Fix-up

after User Account was deleted
If a user is migrated between domains, the account in the target domain is then
deleted, and a group is migrated between the same domains that had the user
account in the source domain as a group member, ADMT will log the following
wrong error message:
<account>
has not been migrated to the target domain.
This issue will be addressed in a later version of ADMT.
Microsoft Windows 2000 Release Notes 13

Bogus Error Messages for Group Fix-up Failures during
Trial Migration
Migrating a user with the User Migration Wizard who is a member of a previously
migrated global group in an inter-forest scenario, logs a bogus group membership
fixup error in "no change" mode.
W1:7352 Failed to add to CN=Executives. RC=80005008. One or more input
parameters are invalid.
This issue will be addressed in a later version of ADMT.
Group Migration
This section describes known issues related to migrating groups with this version
of Active Directory Migration Tool.
Local Group Contains Both Source and Target Account
when that Account is Migrated after Migrating the Local
Group
When migrating a member of a previously migrated local group, the source
account for that member will not be removed when the target member is added. If
the member is migrated before migrating the local group, only the target account
member will be added. This is by design and applies to inter-forest migrations
only.
Group Membership is not maintained for Nested Groups

Group membership within other groups is not maintained for inter-forest
migrations.
Group Member List Is Not Updated For a Group That
Includes a Migrated Group From Another Domain
If you migrate a group from a source domain to a target domain, any groups from
a third domain that include that original group as a member will still refer to the
group in the source domain. In the case of an intra-forest migration, that original
group in the source no longer exists. All access is properly maintained, however,
and all group memberships are fixed when the group in the third domain is later
migrated to the same target domain.
14 Microsoft Windows 2000 Professional, Server, and Advanced Server

Group Migration Wizard and User Migration Wizard Treat
Nested Groups in Windows 2000 Domains Differently
When migrating users with the User Migration Wizard, if the Migrate associated
user groups option is selected, the wizard will only migrate the groups of which
the user is directly a member (i.e. it will not migrate groups the user is a member
of through group nesting).
When migrating groups using the Group Migration Wizard, if the Copy group
members option is selected, the wizard will recursively migrate all users and
groups which are members of that group, including groups that are members
through group nesting.
Where the source domain is running Windows 2000 and group nesting is being
used, if you wish to preserve group membership gained through such nesting, it is
recommended that you migrate the objects affected using the Group Migration
Wizard.
Service Account Migration
This section describes known issues related to migrating service accounts with
this version of Active Directory Migration Tool.
Service Account Migration Wizard has Hidden “Service

Account” Column
The Service Account Migration Wizard displays a list of service accounts. The
“Service” column is the Display Name of the service. A hidden column also
displays the “Service Name” of the service.
Updating a Service Account on a Remote Computer While
Migrating that Account
The user who is running Active Directory Migration Tool must have Logon
Locally rights to any remote computer on which the tool will dispatch an agent.
This also applies to any remote computer whose Service Control Manager (SCM)
will be modified while migrating a service account with the User Migration
Wizard. If you do not have the rights to change the SCM, the service account will
still be migrated to the target domain, but the service on the remote computer will
not be updated to use the target domain account. Once the access rights have been
fixed, the SCM on that remote computer can be fixed by running the Service
Account Migration Wizard and selecting the No, use the previously collected
information option. The user’s lack of access may not always be flagged as an
Microsoft Windows 2000 Release Notes 15

error in Migration Progress, so it is good practice to check the migration log file
for any errors after migrating service accounts.
Services should be enumerated on all Computers before
Service Accounts are migrated
When service accounts are migrated, ADMT creates a new complex password and
saves the password in an encrypted file. The password is needed to configure
services on remote servers for the new service account and password. After the
last service was configured, ADMT deletes the password.
If services on servers are enumerated after ADMT had already deleted the
password, configuration of these services with the migrated account and password
information will fail. Therefore, services on all servers must be enumerated before
service accounts are migrated. This issue will be addressed in a later version of

ADMT.
Trust Migration
This section describes known issues related to migrating trusts with this version of
Active Directory Migration Tool.
Trust Migration Wizard Does Not Verify Existing Trusts
If a domain is listed as a trusted domain on the source and the target domains, the
Trust Migration Wizard will not allow the creation of that trust, even if the trust is
broken in any way. Only use the Trust Migration Wizard to create new trusts. Do
not use it to verify pre-existing trusts.
Final “Next” Button not enabled in Wizard
After trusts were migrated using the “Copy Trust” button, there is no finish button
to leave the wizard. The “Next” button is only enabled if at least one trust was
migrated. The dialog can be closed by clicking the “Cancel” button. This issue
will be addressed in a later version of ADMT.
Computer Migration
This section describes known issues related to migrating computers with this
version of Active Directory Migration Tool.
Intra-forest Computer Migration Does Not Disable the
Computer Account in the Source Domain
After an intra-forest computer migration, the migrated computer source domain
account is not disabled or deleted. As a workaround, you can write a simple
16 Microsoft Windows 2000 Professional, Server, and Advanced Server

Active Directory Service Interfaces (ADSI) script to disable or remove the
accounts of migrated computers in the source domain. This is by design and
needed to enable the undo functionality.
Computer Account created even if Migration fails
If computer migration fails due to an agent-related error, the computer account
created for the computer in the target domain is not deleted. This issue will be
addressed in a later version of ADMT.

Intra-forest Computer Migration Should be Performed Prior
to Migrating any Groups of which Those Computers are
Members
If you have any computers that are members of groups (other than the Domain
Computers group), you should always migrate those computers prior to migrating
the groups to which they belong. This is a condition for intra-forest migrations
and prevents those computers from losing their group membership.
A Prefix Given to a Windows NT 4.0 Computer During a
Computer Migration Can Create Duplicate Computer
Names
When adding a prefix to a Windows NT 4.0 computer with the Computer
Migration Wizard, caution must be taken not to create a computer name that
duplicates the name of another computer being migrated or an existing computer
in the target domain. Active Directory Migration Tool truncates Windows NT 4.0
computer names to 15 characters during the migration. Because of this you must
take precautions that computer names resulting from a prefix being added will still
be unique in the target domain. Any computer with a duplicate name will not be
prevented from successfully joining the target domain.
Intermittent Failure of the Active Directory Migration Tool
Remote Agent Service
There have been reported instances of the Active Directory Migration Tool
remote agent service failing to stop or uninstall itself when the service is deployed
on a remote computer as part of computer migration, security translation, or
service account identification and a failure occurs. If this occurs, it will manifest
itself during subsequent agent deployments as a failure with the message "An
instance of the agent is already running". This persists until either the ADMT
agent process is closed or the remote computer is rebooted. This will be addressed
in a future release.
Microsoft Windows 2000 Release Notes 17

Security Translation Done By the Computer Migration
Wizard Cannot be Undone By the Undo Wizard
The Undo Wizard cannot undo security translation operations even if that security
translation was performed as part of a computer migration. Therefore, we
recommend performing any security translation as part of a computer migration in
“Add” mode.
Computer Migration may fail if there already is a Computer
Account with the same Name in the Target Domain
Dispatching an agent to migrate a computer from a source domain may fail if
there is already a computer account with the same name in the target domain. This
issue will be addressed in a later version of ADMT.
Computer Name gets truncated in Migration Log File if
Computer Name is too long
If a prefix or suffix is added to a computer name during migration and the new
computer name is longer than 15 characters, the computer name must be truncated
to 15 characters. The entry in the migration log will only show the original
computer name in some locations and the full new computer name in other
locations. This issue will be addressed in a later version of ADMT.
User Profile Migration
This section describes a known issue related to migrating user profiles with this
version of Active Directory Migration Tool.
Active Directory Migration Tool Remote Agent Service
Reports That the User Profile Is Locked During Profile
Migration When User Is Logged Off
If you deploy the Active Directory Migration Tool remote agent service on a
remote computer as part of a user profile migration, the agent may fail to migrate
the profile, even if the user whose profile is being migrated has logged off the
computer. It displays Error enumerating the profile list entries, rc=32. The
process cannot access the file because it is being used by another process. This
error has not been traced, but appears to relate to a process that keeps the user

profile open after the user has logged off. Rebooting the computer before
reattempting to migrate the profile may cure the problem. This will be addressed
in a future release.
18 Microsoft Windows 2000 Professional, Server, and Advanced Server

Password Migration
Migrated Passwords may NOT Conform to Target
Domain’s/Site/OU Password Policy
A password policy is enacted only when the Domain Controller can read an
entered password in plain text. Since the password migration tool does not decrypt
the password, it cannot be seen by the Domain Controller in clear text until the
user is prompted to reset his/her password.
Report Creation
This section describes a known issue related to generating reports with this
version of Active Directory Migration Tool.
Expired Computer Account Report
The Expired Computer Account Report lists only computer accounts that have not
been in use for more than 30 days. If the default computer max password age has
been shortened in a domain, ADMT does not use the modified password age
interval to detect expired computer accounts.
Report Wizard will generate Report immediately if Agent
Monitor Dialog is closed
When an agent is dispatched to a machine to gather information for a report, and
the user closes the Agent Monitor Dialog before the agent finished the work and
reported results, the report is created immediately without the missing
information. This issue will be addressed in a later version of ADMT.
Account Reference Report fails to enumerate Printers on
Windows 2000 Computers if Spooler Service is stopped
If the printer sub-system or the spooler service is stopped on a remote Windows
2000 computer, the agent dispatched to this computer used to create the Account

Reference Report fails to enumerate printers and logs the following error into the
migration log file:
ERR2:7173 Failed to enumerate the printers on the local machine, rc=1722 The RPC
server is unavailable.
This issue will be addressed in a later version of ADMT.
Microsoft Windows 2000 Release Notes 19

Account Name Conflict Report does not report Conflicts on
inetOrgPerson Objects correctly
When the Account Name Conflict Report is run to determine whether migrations
of users, groups, or inetOrgPersons from one domain to another would create
conflicts with existing objects, it does not report name collisions that could be
caused by inetOrgPersons. This issue will be addressed in a later version of
ADMT.
inetOrgPerson Objects are reported as User Objects in the
Migrated User Accounts Report
After objects of the class inetOrgPerson are migrated, the Migrated User Accounts
Report reports these objects as class “user” instead of class “inetOrgPerson”. This
issue will be addressed in a later version of ADMT.

Retry Wizard
Retry Wizard has Hidden “Job File” and “Action ID”
Columns
The “Task Selection” dialog has two hidden columns (“Job File” and “Action
ID”) that contain internal ADMT implementation details not usually needed.
Online Help
This section describes a known issue related to the online Help shipped with this
version of Active Directory Migration Tool.
Help Window always stays on top
In any ADMT wizard, when the “Help” button is pressed and the help window

appears, if the user activates the wizard window again, the help window will stay
in the foreground. This issue will be addressed in a later version of ADMT.
20 Microsoft Windows 2000 Professional, Server, and Advanced Server

Active Directory Migration Tool Remote Agent Service
This section describes a known issue related to the Active Directory Migration
Tool remote agent shipped with this version of Active Directory Migration Tool.
The Agent does NOT Quit upon the Early Termination of
the Command line Tool or VBScript
If you CTRL+C or terminate the program early, the agent process will not stop.
The process must be killed manually.
Alpha Support is Removed From ADMT Version 2.0.
ADMT no longer supports deploying agents to ALPHA machines.
Agent Monitor Monitoring Settings Tab Is Not Used
The Monitoring Settings tab of the Agent Monitor is designed to allow the user
to view different logs on the remote computer. Since there is only one log created
by Active Directory Migration Tool agents on the remote computer, this feature is
not useful.
SIDs that cannot be resolved during Security Translation
are displayed in raw Format in the Migration Log File
If SIDs cannot be resolved during security translations (i.e., if the user or group
was deleted), the SIDs are printed in raw format in the migration log file. This
issue will be addressed in a later version of ADMT.
No Security Translation for Remote Desktop Settings
Security translation on a computer that has Windows Terminal Services enabled
does not translate permissions for users that were migrated. This issue will be
addressed in a later version of ADMT.
Security Translations with SID Mapping Files does not
allow One to Many Translations
When a SID Mapping file is used for security translations, the same account

cannot be used multiple times as source account. For example, if a SID Mapping
file has the following content:
Domain1\user1, domain2\user1
Domain1\user1, domain2\user2
and security translation runs in “Add” mode, only domain2\user1 is added as
trustee in security translations, not domain2\user2. This issue will be addressed in
a later version of ADMT.
Microsoft Windows 2000 Release Notes 21

Active Directory Migration Tool Migration Database
This section describes a known issue related to the Active Directory Migration
Tool migration database.
Single Use
State information that is critical to the proper operation of Active Directory
Migration Tool is stored in a Microsoft Access database named Protar.mdb. This
database is installed in the same directory as all other installation files. Many of
the tool’s wizards require some knowledge of previous users or groups that were
migrated, the original source domain of those users, which users have been
enumerated as service accounts, and other state information. All of this
information is stored in the Protar.mdb database. With that in mind, some thought
should given when the following actions are being considered:
1) Moving Active Directory Migration Tool operations to another
computer. If, after performing some migration operations, it is decided to run
the tool on another computer, Protar.mdb and Scmdata.txt should be copied
from the original computer to that new computer.
2) Reinstalling Active Directory Migration Tool. Before reinstalling or
upgrading over an existing installation from which some migration operations
have occurred, you should save the Protar.mdb database and copy the saved
database over the new version.
3) Do not run multiple instances of Active Directory Migration Tool at any

one time. Currently, the tool is not designed to support simultaneous
operations, so you should not run multiple instances of the tool at the same
time. It is possible to have two installations of the tool carrying out
migrations, but it requires disciplined practices to keep the databases
manually synchronized. This will be addressed in a future release.
4) Backup and Restore. The Protar.mdb database should be backed up
frequently, especially if you are performing a migration process over an
extended time period.
Intra-forest Migration
This section describes a known issue related to intra-forest migrations.
Domain-wide User and Group Rights are NOT Migrated to
the Target Domain
Intra-forest user and group migrations fail to migrate domain-wide account rights
as selected by the “User Rights” checkbox.
22 Microsoft Windows 2000 Professional, Server, and Advanced Server

Global Group Migration and Native Mode Source Domains
When Global Groups are migrated between native mode source and target
domains, the groups are temporarily switched to Universal Groups. This is needed
until all group members from the source domain are migrated to the target
domain. The group is then automatically switched back to a Global Group. This is
by design because Global Groups can only have members from the domain in
which they reside.
Global Group Migration and Mixed Mode Source Domains
When Global Groups are migrated between a mixed mode source domain and a
native mode target domain and the groups are not empty, ADMT creates copies of
the Global Groups in the target domain and does not add the SID of the source
domains Global Group to the SID History. This is by design.
The reason why ADMT cannot convert the Global Group to a Universal Group
(as it does when both source and target domain are native mode) is that mixed

mode domains will not add Universal Groups into the user's access token.
Therefore, the users would lose access to resources based on the Universal Group
membership.
It is strongly recommended to migrate users and groups between native mode
domains only.
Global Groups Are Copied Without SIDHistory for
Intra-forest Migrations If Not Migrated with Group Members
and the Source Domain is in Mixed Mode
If you choose a global group in a mixed mode domain for an intra-forest
migration using the Group Migration Wizard and the Copy Group Members
option is not selected, that global group will be copied without SIDHistory rather
than being moved. This behavior is a result of the rules of global group
membership. If the global group was moved between domains instead of being
copied, the group members would be “orphaned” from the group and would lose
any resource access granted through membership of the group. This is because
global groups cannot contain members from other domains.
When that group’s members are later moved, the group membership will be
restored, but because SIDHistory is not migrated with the group, you must run the
Security Translation Wizard to translate its security, just as you would do in an
inter-forest migration without SIDHistory.
It is strongly recommended to migrate users and groups between native mode
domains only.
Microsoft Windows 2000 Release Notes 23

Undo Operations and Mixed Mode Source Domains
Undo operations of user and group migrations are not supported when the source
domain is mixed mode. This is by design. An undo is a re-migration to the source
domain, and ADMT only supports native mode domains as target domains for
migrations.
It is strongly recommended to migrate users and groups between native mode

domains only.
Command line Tool
Note that the command line tool uses the scripting component and, therefore,
scripting issues are applicable to the command line tool.
Command Line and Scripting do not provide detailed Error
Messages
When ADMT is invoked from the command line or a script, the calling process
will wait until ADMT has finished the migration task to return a general success
or error message. Detail information is only available through the migration log
file.
Duplicate Command line Switches Override any Previous
Occurrences
If a command line switch is specified more than once, it overrides the previous
value of the switch. This is by design.
Extended Characters are not displayed by Command Line
Interface
The ADMT command line interface does not convert Unicode to OEM. Extended
characters such as the German “Umlaute” are therefore not displayed correctly.
This issue will be addressed in a later version of ADMT.
ADMT does not support RUNAS command
Running ADMT from the command line under the runas command results in an
error:
ERR2:0080 Unable to migrate users. Server execution failed. This issue will be
addressed in a later version of ADMT.

24 Microsoft Windows 2000 Professional, Server, and Advanced Server

Scripting Component
There are no known issues in the scripting component.