ADMT Guide: Migrating and Restructuring Active Directory Domains

Microsoft Corporation

Published: June 2014

Author: Justin Hall

Editors: Jim Becker, Margery Spears

Abstract

This guide explains how to use the Active Directory® Migration Tool to migrate users, groups, standalone managed service accounts, and computers between Active Directory domains in different forests (interforest migration) or between Active Directory domains in the same forest (intraforest migration). It also shows how to use ADMT to perform security translation between different Active Directory forests.

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, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, 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.

© 2014 Microsoft Corporation. All rights reserved.

Active Directory, Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Contents

ADMT Guide: Migrating and Restructuring Active Directory Domains

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

To obtain a downloadable version of this guide in .doc format, see ADMT Guide: Migrating and Restructuring Active Directory Domains (http://go.microsoft.com/fwlink/?LinkId=191734).

As part of deploying the Active Directory® directory service or Active Directory Domain Services (AD DS), you might choose to restructure your environment for the following reasons:

∙?To optimize the arrangement of elements within the logical Active Directory structure

∙?To assist in completing a business merger, acquisition, or divestiture

Restructuring involves the migration of resources between Active Directory domains in either the same forest or in different forests. After you deploy Active Directory or AD DS, you might decide to further reduce the complexity of your environment by either restructuring domains between forests or restructuring domains within a single forest.

You can use the Active Directory Migration Tool (ADMT) to perform object migrations and security translation as necessary so that users can maintain access to network resources during the migration process. The latest version of ADMT 3.2 is available on Microsoft Connect (http://go.microsoft.com/fwlink/?LinkId=401534) and it supersedes all previous versions. It runs on all versions of Windows Server and can migrate objects to and from any Active Directory environment. All previous versions of ADMT have been removed from the Microsoft Download Center. 

In this guide

∙?Best Practices for Active Directory Migration

∙?Interforest Active Directory Domain Restructure

∙?Intraforest Active Directory Domain Restructure

∙?Appendix: Advanced Procedures

∙?Troubleshooting ADMT

∙?Additional Resources

The following sections explain the main migration scenarios for using ADMT. After you determine the appropriate scenario for your environment, follow the steps later in this guide for that scenario. 

Interforest Active Directory domain restructure

You might perform an interforest restructure for business changes, such as mergers or acquisitions or divestitures, in which your organizations have to combine or divide resources. As part of the restructuring process, when you migrate objects between forests both the source and target domain environments exist simultaneously. This makes it possible for you to roll back to the source environment during the migration, if necessary.

Splitting or cloning forests—for example, to accommodate divestiture of an organization—is not supported. For more information, see Restructuring Limitations (http://go.microsoft.com/fwlink/?LinkId=121736).

Intraforest Active Directory domain restructure

When you restructure domains in a forest, you can consolidate your domain structure and reduce administrative complexity and overhead. Unlike the process for restructuring domains between forests, when you restructure domains in a forest, the migrated accounts no longer exist in the source domain. Therefore, rollback of the migration can only occur when you carry out the migration process again in reverse order from the previous target domain to the previous source domain.

The following table lists the differences between an interforest domain restructure and an intraforest domain restructure.

Migration consideration	Interforest restructure	Intraforest restructure
Object preservation	Objects are cloned rather than migrated. The original object remains in the source location to maintain access to resources for users.	User and group objects are migrated and no longer exist in the source location. Computer and managed service account objects copied and the original accounts remain enabled in the source domain.
Security identifier (SID) history maintenance	Maintaining SID history is optional.	SID history is required for user, group, and computer accounts, but not managed service accounts.
Password retention	Password retention is optional.	Passwords are always retained.
Local profile migration	You must use tools such as ADMT to migrate local profiles.	Local profiles are migrated automatically because the user’s globally unique identifier (GUID) is preserved.
Closed sets	You do not have to migrate accounts in closed sets. For more information, see Background Information for Restructuring Active Directory Domains Within a Forest (http://go.microsoft.com/fwlink/?LinkId=122123).	You must migrate accounts in closed sets.

Terms and definitions

The following terms apply to the Active Directory domain restructure process.

Migration   The process of moving or copying an object from a source domain to a target domain, while preserving or modifying characteristics of the object to make it accessible in the new domain.

Domain restructure   A migration process that involves changing the domain structure of a forest. A domain restructure can involve either consolidating or adding domains, and it can take place between forests or in a forest.

Migration objects   Domain objects that are moved from the source domain to the target domain during the migration process. Migration objects can be user accounts, service accounts, groups, or computers.

Source domain   The domain from which objects are moved during a migration. When you restructure Active Directory domains between forests, the source domain is an Active Directory domain in a different forest from the target domain.

Target domain   The domain to which objects are moved during a migration.

Built-in accounts   Default security groups that have common sets of rights and permissions. You can use built-in accounts to grant permissions to any accounts or groups that you designate as members of these groups. Built-in account SIDs are identical in every domain. Therefore, built-in accounts cannot be migration objects.

Active Directory Migration Tool

You can use ADMT to migrate objects in Active Directory forests. This tool includes wizards that automate migration tasks, such as migrating users, groups, service accounts, computers, and trusts and performing security translation.

You can perform ADMT tasks by using the ADMT console, a command line, or a script. When you run ADMT at the command line, it is often more efficient to use an option file to specify command-line options. You can use the ADMT option file reference in the following example to assist you in creating option files. Examples of command-line syntax are provided for each task that you must perform to restructure the domains within the forest.

The following listing shows common options that apply to several migration tasks. Each type of migration task has a section that lists options that are specific to that task. The section name corresponds to the task name when you run ADMT at the command line. You can comment out items with a semicolon. In the following listing, the default values are commented out.

[Migration]

;IntraForest=No

;SourceDomain="source_domain_name" 

;SourceOu="source_ou_path" 

;TargetDomain="target_domain_name" 

;TargetOu="target_ou_path" 

;PasswordOption=Complex

;PasswordServer="" 

;PasswordFile="" 

;ConflictOptions=Ignore

;UserPropertiesToExclude="" 

;InetOrgPersonPropertiesToExclude="" 

;GroupPropertiesToExclude="" 

;ComputerPropertiesToExclude="" 

[User]

;DisableOption=EnableTarget

;SourceExpiration=None

;MigrateSIDs=Yes

;TranslateRoamingProfile=No

;UpdateUserRights=No

;MigrateGroups=No

;UpdatePreviouslyMigratedObjects=No

;FixGroupMembership=Yes

;MigrateServiceAccounts=No

;UpdateGroupRights=No

[Group]

;MigrateSIDs=Yes

;UpdatePreviouslyMigratedObjects=No

;FixGroupMembership=Yes

;UpdateGroupRights=No

;MigrateMembers=No

;DisableOption=EnableTarget

;SourceExpiration=None

;TranslateRoamingProfile=No

;MigrateServiceAccounts=No

[Security]

;TranslationOption=Add

;TranslateFilesAndFolders=No

;TranslateLocalGroups=No

;TranslatePrinters=No

;TranslateRegistry=No

;TranslateShares=No

;TranslateUserProfiles=No

;TranslateUserRights=No

;SidMappingFile="SidMappingFile.txt"

When you run ADMT at the command line, you do not have to include an option in your command if you want to accept the default value. In this guide, however, tables that list possible parameters and values are provided for reference. The tables list the command-line equivalent of each option that is shown in the corresponding ADMT console procedure, including those options for which you accept the default value.

You can copy the option file reference into Notepad and save it by using a .txt file name extension.

As an example, to migrate a small number of computers, you might type each computer name at the command line, using the /N option, and then list other migration options within an option file as follows:

ADMT COMPUTER /N "<computer_name1>" "<computer_name2>" /O:"<option_file>.txt"

Where <computer_name1> and <computer_name2> are the names of computers in the source domain that you are migrating in this batch.

Using an include file

When you migrate a large number of users, groups, or computers, it is more efficient to use an include file. An include file is a text file in which you list the user, group, and computer objects that you want to migrate, with each object on a separate line. You must use an include file if you want to rename objects during the migration. 

You can list users, groups, and computers together in one file, or you can create a separate file for each object type. Then, specify the include file name with the /F option, as follows:

ADMT COMPUTER /F "<includefile_name>" /IF:YES /SD:"<source_domain>” /TD:"<target_domain>" /TO:"<target_OU>"

To specify the names of users, groups, or computers, use one of the following conventions:

∙?The Security Accounts Manager (SAM) account name. To specify a computer name in this format, you must append a dollar sign ($) to the computer name. For example, to specify a computer with the name Workstation01, use Workstation01$.

∙?The relative distinguished name (also known as RDN), for example, cn= Workstation01. If you specify the account as a relative distinguished name, you must specify the source organizational unit (OU). 

∙?The canonical name. You can specify the canonical name as DNS domain name/ou_path/object_name or ou_path/object_name, for example, Asia.trccorp.treyresearch.net/Computers/Workstation01 or Computers/Workstation01.

The following sections describe the fields of an include file and provide examples for each field:

SourceName field

The SourceName field specifies the name of the source object. You can specify either an account name or a relative distinguished name. If you only specify source names, it is optional to define a header on the first line in the file.

The following example illustrates a header line that specifies the SourceName field. The example also shows a source object name that is specified in several formats. The second line specifies an account name. The third line specifies a relative distinguished name.

SourceName

name

CN=name

TargetName field

You can use the TargetName field to specify a base name that is used to generate a target relative distinguished name, a target SAM account name, and a target user principal name (UPN). The TargetName field cannot be combined with other target name fields that are described later in this section.

Note 

The target UPN is generated only for user objects, and only a UPN prefix is generated. A UPN suffix is appended using an algorithm that depends on whether a UPN suffix is defined for the target OU or the target forest. If the object is a computer, the target SAM account name includes a "$" suffix.

The following example of input generates the target relative distinguished name, target SAM account name, and target UPN as "CN=newname", "newname," and "newname" respectively.

SourceName,TargetName

oldname, newname

TargetRDN, TargetSAM, and TargetUPN fields

You can use the TargetRDN, TargetSAM, and TargetUPN fields to specify the different target names independently of each other. You can specify any combination of these fields in any order. 

TargetRDN specifies the target relative distinguished name for the object.

TargetSAM specifies the target SAM account name for the object. For computers, the name must include a "$" suffix to be a valid SAM account name for a computer.

TargetUPN specifies the target UPN for the object. You can specify either just the UPN prefix or a complete UPN name (prefix@suffix). If the name that you specify contains a space or a comma, you must enclose the name in double quotation marks (" "). 

SourceName,TargetRDN

oldname, CN=newname

SourceName,TargetRDN,TargetSAM

oldname, "CN=New RDN", newsamname

SourceName,TargetRDN,TargetSAM,TargetUPN

oldname, "CN=last\, first", newsamname, newupnname

Note 

A comma within the CN value must be preceded with an escape ("\") character or the operation will fail, and ADMT will record an invalid syntax error in the log file.

SourceName,TargetSAM,TargetUPN,TargetRDN

oldname, newsamname, newupnname@targetdomain, "CN=New Name"

Renaming objects

Use the following format in an include file to rename computer, user, or group objects during migration:

∙?Use SourceName, TargetRDN, TargetSAM, and TargetUPN as column headings at the top of the include file. SourceName is the name of the source account, and it must be listed as the first column heading. The TargetRDN, TargetSAM, and TargetUPN column headings are optional, and you can list them in any order.

∙?You must specify the account name as user name, relative distinguished name, or canonical name. If you specify the account name as a relative distinguished name, you must also specify the source OU.

The following are examples of valid include files in which the rename option is used:

SourceName,TargetSAM

abc,def

This include file entry changes the TargetSAM account name for user "abc" to "def." The TargetRDN and the TargetUPN, which are not specified in this include file, do not change as a result of the migration.

SourceName,TargetRDN,TargetUPN

abc,CN=def,def@contoso.com

This include file entry changes the TargetRDN for user abc to CN=def and the TargetUPN to def@contoso.com. The TargetSAM for user abc does not change as a result of the migration.

Important 

You must specify CN= before using an RDN value.

Using an exclude file

You can exclude objects from migration by using an exclude file. An exclude file is a text file that lists the SAMAccountName attribute of the objects that you want to exclude. For example, to exclude the following managed service accounts, create a text file:

MSA_USER5$

MSA_USER6$

Then, specify the name of the exclude file when you run the admt command. For example:

admt managedserviceaccount /ef:”exclude file name”

Optionally, you can exclude specific accounts by using the /en parameter:

admt managedserviceaccount /en:”managed service account 1” “managed service account 2”

Using scripts

The sample scripts that are provided in this guide refer to the symbolic constants that are defined in a file named AdmtConstants.vbs. The listing that follows shows the ADMT constants Microsoft Visual Basic® Scripting Edition (VBScript) file. The constants are also provided in the ADMT installation folder, in the TemplateScript.vbs file, in the %systemroot%\WINDOWS\ADMT directory.

To use the sample scripts in the guide, copy the ADMT constants VBScript file into Notepad and save it as AdmtConstants.vbs. Be sure to save it in the same folder where you plan to save the sample scripts that are provided in this guide. 

Option Explicit

'----------------------------------------------------------------------------

' ADMT Scripting Constants

'----------------------------------------------------------------------------

' PasswordOption constants

Const admtComplexPassword                   = &H0001

Const admtCopyPassword                      = &H0002

' Note that the following constant cannot be specified alone.

' It must be specified along with admtComplexPassword or admtCopyPassword.

Const admtDoNotUpdatePasswordsForExisting   = &H0010

' ConflictOptions constants

Const admtIgnoreConflicting           = &H0000

Const admtMergeConflicting            = &H0001

Const admtRemoveExistingUserRights    = &H0010

Const admtRemoveExistingMembers       = &H0020

Const admtMoveMergedAccounts          = &H0040

' DisableOption constants

Const admtLeaveSource        = &H0000

Const admtDisableSource      = &H0001

Const admtTargetSameAsSource = &H0000

Const admtDisableTarget      = &H0010

Const admtEnableTarget       = &H0020

' SourceExpiration constant

Const admtNoExpiration = -1

' Translation Option

Const admtTranslateReplace = 0

Const admtTranslateAdd     = 1

Const admtTranslateRemove  = 2

' Report Type

Const admtReportMigratedAccounts  = 0

Const admtReportMigratedComputers = 1

Const admtReportExpiredComputers  = 2

Const admtReportAccountReferences = 3

Const admtReportNameConflicts     = 4

' Option constants

Const admtNone     = 0

Const admtData     = 1

Const admtFile     = 2

Const admtDomain   = 3

Const admtRecurse           = &H0100

Const admtFlattenHierarchy  = &H0000

Const admtMaintainHierarchy = &H0200

Active Directory Migration Tool versions and supported environments

ADMT v3.2 can be downloaded from Microsoft Connect (http://go.microsoft.com/fwlink/?LinkId=401534). If necessary, join the Azure Active Directory Customer Connection program to obtain access to the download package. 

ADMT v3.2 has recently been updated and re-released. All previous versions of ADMT are deprecated. The version remains v3.2 because it’s functionally the same as its predecessor (that is, there are no new features). This final release includes various bug fixes and can be used with all supported Windows operating systems and versions of Windows Server Active Directory: 

∙?The server where you install ADMT can run any supported version of Windows Server, including Windows Server 2012 R2 and Windows Server 2012.

∙?The source and target domain controllers must be writeable, but they can run any supported version of Windows Server with a user interface (not Server Core), including Windows Server 2012 R2 and Windows Server 2012.

∙?The source and target domains must be at Windows Server 2003 domain functional level or higher.

∙?The computers that can be migrated can run any supported version of Windows, including Windows 8.1.

∙?You can use any version of SQL Server for the ADMT database.

Support for Windows Server features 

No versions of ADMT can be installed on a read-only domain controller (RODC) or a Server Core installation. An RODC cannot be used as a source or target domain controller for migration.

In addition, ADMT provides the following support for these Active Directory features: 

Feature	Impact of using ADMT
Standalone managed service accounts Note  Group Managed Service Accounts cannot be migrated.	Can be migrated by using use the Managed Service Account Migration Wizard or the admt managedserviceaccount command.
Authentication Mechanism Assurance	User accounts that are enabled for Authentication Mechanism Assurance need to be migrated by using an include file. Important  The User Principal Name (UPN) is changed when a user is migrated, which prevents Authentication Mechanism Assurance from working. To work around this issue, you need to keep a record of the UPNs of user accounts that are enabled for Authentication Mechanism Assurance and migrate them using an include file. In an include file, you can specify the targetUPNs for these users to be migrated. This way you can override the UPNs in that target domain with the original UPNS from the source domain. For more information about using an include file, see Use an Include File.
Offline Domain Join	No impact
Active Directory Recycle Bin	No impact
Windows PowerShell	Not incorporated into ADMT

Change History

Date	Revision
June 24, 2010	Original publication
June 28, 2010	Windows 7 and Windows Server 2008 R2 were added to the list of supported operating systems for computer migration objects for ADMT v3.1.
June 13, 2014	ADMT v3.2 was re-released. All operating system checks were removed, previous versions of ADMT were deprecated, and the guide was updated accordingly.

Best Practices for Active Directory Migration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

To ensure that your migration process is as seamless as possible, follow these best practice recommendations:

∙?Best Practices for Using the Active Directory Migration Tool

∙?Best Practices for Performing User and Group Account Migrations

∙?Best Practices for Performing Computer Migrations

∙?Best Practices for Rolling Back a Migration

Best Practices for Using the Active Directory Migration Tool

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

∙?Perform regular backups of domain controllers in both the source and target domains throughout the course of the migrations. If you are migrating computers that contain file shares to perform security translation, we recommend that you also back up those computers throughout migrations. 

∙?Before you begin a migration, perform a test migration by creating a test user, adding the test user to the appropriate global groups, and then verifying resource access before and after migration. 

∙?Test your migration scenarios in a test environment before migrating objects in the production environment. 

∙?Have a recovery plan, and ensure that your recovery plan works during the test phase of your migration. 

∙?Decrypt files that have been encrypted by means of Encrypting File System (EFS). Failure to decrypt encrypted files will result in loss of access to encrypted files after migration. Be sure to communicate to end users that they must decrypt any encrypted files or they will lose access to those files. 

∙?Ensure that the system time is synchronized in each domain from which objects are migrated. Kerberos authentication fails if time is skewed. 

Best Practices for Performing User and Group Account Migrations

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

∙?Perform regular backups of domain controllers in both the source and target domains throughout the course of the migrations. If you are migrating computers that contain file shares to perform security translation, we recommend that you also back up those computers throughout migrations. 

∙?We recommend that you migrate users in batches. A batch size of 100 users helps to keep the migration process manageable. 

∙?Always administer changes to user accounts and group accounts in the source domain during the migration process.

∙?Use the Migrate and merge conflicting objects option on the Conflict Management page of the User Account Migration Wizard and the Group Account Migration Wizard to remigrate users and groups as often as necessary throughout the migration. Administering changes in the source domain and then using the Migrate and merge conflicting objects option during migration ensures that all changes that are made to an object in the source domain are reflected after it has been migrated to the target domain.

∙?To maintain access to resources, ensure that group membership adheres to the following guidelines:

∙?Use global groups to group users. 

∙?Use local groups to protect resources. 

∙?Place global groups into local groups to grant members of the global groups access to a resource. 

∙?Adhere to the guidelines in the following table when you translate user profiles.

Profile type	Translation guidelines
Roaming profiles	Select the Translate roaming profiles option on the User Options page in the User Account Migration Wizard. Then, translate local user profiles for a batch of users immediately after you migrate those users.
Local profiles	Translate local profiles as a separate step from the user account migration process. Select the User profiles option on the Translate Objects page of the Security Translation Wizard. Translate local user profiles for a batch of users immediately after you migrate those users.
Unmanaged profiles	Users lose their existing profiles when their user accounts are migrated.

Important 

It is important to verify that local profile translation has succeeded before users attempt to log on to the target domain. If users log on to the target domain by using their new target accounts and their profiles have not translated successfully, those users must be migrated again from the source domain to the target domain. For more information about the steps to follow if local profile translation fails, see Troubleshooting Security Translation Issues.

Best Practices for Performing Computer Migrations

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

∙?Perform regular backups of domain controllers in both the source and target domains throughout the course of the migrations. If you are migrating computers that contain file shares to perform security translation, we recommend that you also back up those computers throughout the migration. 

∙?Verify that workstations and member servers have restarted immediately after you join them to the target domain. The Active Directory Migration Tool (ADMT) automates the restart of workstations and member servers, but you use the Minutes before computers restart after wizard completion option in the Computer Migration Wizard to select the amount of time that passes before the computer is restarted. Computers that do not restart after migration are in an indeterminate state. 

∙?Communicate to end users that their computers must be connected to the network at the time that their computer is scheduled to be migrated. 

Best Practices for Rolling Back a Migration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

∙?Roll back user and group accounts that have been migrated between forests by enabling the accounts in the source domain (if they were disabled during the migration), verifying that the accounts have access to resources in the source domain, and then verifying that logon scripts and user profiles work as configured in the source domain.

∙?Roll back resources that have been migrated between forests by changing the domain membership of servers and workstations and then restarting them. Log on to the resources in the source domain to ensure that the resources are accessible.

∙?Roll back accounts and resources that have been migrated within a forest by migrating the objects back from the target domain to the source domain. Accounts and resources that are migrated within a forest are moved and not copied. Therefore, they do not continue to exist in the source domain. 

Note 

To ensure a successful rollback of an intraforest migration, do not attempt to delete the objects in the target domain and then restore them in the source domain. You will not be able to recover the objects in the source domain because they are automatically deleted by the cross-domain move proxy if a restore is attempted.

Interforest Active Directory Domain Restructure

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Restructuring Active Directory domains between forests involves relocating objects from source domains in one forest to target domains in another forest. You might have to restructure Active Directory domains between forests to: 

∙?Migrate a pilot domain into your production environment. 

∙?Merge users and resources with another organization because of a corporate merger and the need to consolidate the two information technology (IT) infrastructures. 

∙?Relocate users and resources on a regular basis because of a planned multiforest deployment. 

∙?Remove objects from your forest because of a divestiture to another organization or to merge later into a new or existing forest for that organization. 

In this section

∙?Checklist: Performing an Interforest Migration

∙?Overview of Restructuring Active Directory Domains Between Forests

∙?Restructuring Limitations

∙?Planning to Restructure Active Directory Domains Between Forests

∙?Preparing the Source and Target Domains

∙?Migrating Accounts

∙?Migrating Resources

∙?Completing the Migration

Checklist: Performing an Interforest Migration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Migrating Active Directory domains between forests (interforest migration) involves relocating objects from source domains in one forest to target domains in another forest. You might have to restructure Active Directory domains between forests for the following reasons: 

∙?To migrate a pilot domain into your production environment

∙?To merge your Active Directory forest with the forest of another organization and consolidate the two information technology (IT) infrastructures

Task	Reference
Review the Active Directory Migration Tool (ADMT) preinstallation instructions.	Installing ADMT in the Target Domain
To migrate computers running Windows Server 2003, Windows Vista (without Service Pack 1), Windows XP, and Microsoft Windows 2000 (using ADMT 3.1) to a target domain, first set the following registry key on the target domain controllers: Note  This registry key does not need to be set to migrate computers that run later versions of Windows (such as Windows Server 2008, Windows Server 2008 R2, Windows 7, or Windows Vista SP1) or that installed the RODC client compatibility pack (hotfix 944043). Registry path: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters Registry value: AllowNT4Crypto Type: REG_DWORD Data: 1 Note  This registry setting corresponds to the Allow cryptography algorithms compatible with Windows NT 4.0 setting in Group Policy.	For more information about making this change using Group Policy, see Microsoft Knowledge Base article 942564 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;942564). For more information about the RODC client compatibility pack, see Microsoft Knowledge Base article 944043 (http://support.microsoft.com/kb/944043).
For any migration tasks that use agent deployment and where Windows Firewall is in use, enable the File and Printer Sharing exception. This can include migration for the following situations: ∙?Migrating workstation computers and member servers that are running Windows Server 2003 or Windows XP or later. ∙?Migrating security settings or performing security translation	For more information about making this change in Windows Firewall, see Enable or Disable the File and Printer Sharing Exception (http://go.microsoft.com/fwlink/?LinkID=119315).
Prepare to restructure Active Directory domains within a forest. This task has the following subtasks: ∙?Determine your account migration process. ∙?Assign object roles and locations. ∙?Develop a test plan for your migration. ∙?Create a rollback plan.  ∙?Manage users, groups, and user profiles. ∙?Create a user communication plan.	Installing ADMT in the Target Domain Planning to Restructure Active Directory Domains Between Forests
Prepare the source and target domains. This task has the following subtasks: ∙?Install 128-bit encryption software. ∙?Establish trusts that are required for migration. ∙?Establish migration accounts for your migration. ∙?Configure the source and target domains for security identifier (SID) history migration. ∙?Configure the target domain organizational unit (OU) structure. ∙?Install ADMT in the target domain. ∙?Specify service accounts for your migration.	Installing ADMT in the Target Domain Planning to Restructure Active Directory Domains Between Forests
Specify and transition service accounts using either the Service Account Migration Wizard or ADMT command-line tools. You can use the admt service command-line tool to specify service accounts in the source domain. You can use the admt user command-line tool to transition service accounts that you specify.	Transitioning Service Accounts in Your Migration
Migrate global groups using either the Group Account Migration Wizard or the admt group command-line tool.	Migrating Global Groups
Migrate standalone managed service accounts, user accounts, and workstation accounts with their SID histories in batches. You can use either the User Account Migration Wizard or the admt user command-line tool to migrate user accounts. You can use the Managed Service Account Migration Wizard or admt managedserviceaccount command-line tool to migrate standalone managed service accounts. Group managed service accounts cannot be migrated.	Migrating Accounts While Using SID History Migrating Managed Service Accounts Migrating All User Accounts
Migrate resources, such as member servers and domain local groups. You can use either the Computer Account Migration Wizard or the admt computer command-line tool to migrate computer accounts. You can use the Group Account Migration Wizard or the admt group command-line tool to migrate groups.	Remigrating User Accounts and Migrating Workstations in Batches
Translate security on servers to add the SIDs of the user and group accounts in the target domain to the access control lists (ACLs) of the resources. You can use either the Security Translation Wizard or the admt security command-line tool.	Translating Security in Add Mode
Repeat a migration of user accounts, workstation computers, and member servers, including translating local user profiles to user and computer objects that you migrated earlier.	Remigrating User Accounts and Migrating Workstations in Batches
Migrate domain local groups using either the Group Account Migration Wizard or the admt group command-line tool.	Migrating Domain and Shared Local Groups
Migrate domain controllers.	Migrating Domain Controllers
Complete postmigration tasks. This task has the following subtasks: ∙?Translate security on member servers. ∙?Decommission the source domains.	Translating Security on Your Member Servers Decommissioning the Source Domain

Overview of Restructuring Active Directory Domains Between Forests

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

When you restructure domains between forests, you can reduce the number of domains in your organization, which helps to reduce the administrative complexity and associated overhead costs of your Active Directory environment. Restructuring domains involves copying accounts and resources from a source domain to a target domain in a different Active Directory forest. The source and target domains must be at least at a Windows Server 2003 functional level.

If your organization has recently merged with another organization or information technology (IT) infrastructure, you can restructure domains to consolidate accounts and resources between the two infrastructures.

In this section

∙?Process for Restructuring Active Directory Domains Between Forests

∙?Background Information for Restructuring Active Directory Domains Between Forests

Process for Restructuring Active Directory Domains Between Forests

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Restructuring Active Directory domains between forests involves planning and preparing for the domain restructure for your organization. It also entails successfully migrating accounts and resources to an Active Directory domain in another forest. The following figure shows the process for restructuring Active Directory domains between forests. 

Background Information for Restructuring Active Directory Domains Between Forests

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

The migration process between forests is not considered to be destructive because the migration objects continue to exist in the source domain until the source domain is decommissioned. Because the source and target domain environments exist simultaneously during the migration, you have the option to roll back to the source environment if migration fails for any reason, for example, if a particular object does not migrate or access is not maintained or preserved in the target domain after you perform the migration. You can use the Active Directory Migration Tool (ADMT) to migrate accounts and resources between domains while preserving user and object permissions. During the interforest restructure process, users have continuous access to required resources. Furthermore, you can move users, groups, and resources independently of each other.

The remaining sections in this topic explain the account and resource migration process .

Account migration process

Restructuring accounts between Active Directory forests involves the copying of users, groups, and local profiles from the source domain to the target domain, while preserving the access rights and attributes of those objects.

When user accounts are migrated between Active Directory domains in different forests, the original account remains in place in the source domain and a new account is created in the target domain. Because the security identifier (SID) of a security principal (user or group) always contains an identifier for the domain in which the security principal is located, a new SID is created for the user in the target domain. Because ADMT can migrate the SID of the original security principal to the security principal in the target domain, you do not have to perform additional tasks to ensure resource access unless you are using SID filtering between the forests.

If you are using Group Policy to manage folder redirection or software distribution, ensure that these policies continue to apply when you migrate user accounts to a new forest. Also, if you are using a Group Policy object (GPO) to grant or deny remote access in the source domain and not the target domain, ADMT cannot determine which remote access to assign to the user.

If you are using Group Policy to manage folder redirection, Offline Files does not work after the user account is migrated to a new forest. Offline Files stores the SID of the user as owner; the SID changes when the user account is migrated. To restore ownership of Offline Files, use the ADMT Security Translation Wizard to replace the permissions on the files and folders on the client computer that contains the offline files cache.

To ensure that users continue to have access to Offline Files after you migrate user accounts to the target domain, you can do the following:

1.    Translate security on client computers to update the Offline Files.

2.    If the SID history of the user account was not migrated to the target domain, translate security on the server that hosts redirected folders.

If you are using folder redirection, one of the following occurs:

∙?If the folder redirection path is different in the new environment, users can access the folder if the SID history of the user account was migrated to the target domain. The folder redirection extension copies the files from the original location in the source domain to the new location in the target domain. SID history enables the user account to access the source folders.

∙?If the folder redirection path is the same in the new environment, users cannot access the redirected folder because folder redirection will check ownership of the redirected folder and fail. You must then translate security on the redirected folder on the server.

If you are using Group Policy to manage software installation and the Windows Installer package requires access to the original source for operations such as repair and remove, you must translate security on the software distribution point after you migrate users to ensure that software installation continues to function properly in the target domain.

Resource migration process

Active Directory domains include three types of resources:

∙?Workstation accounts

∙?Member server accounts

∙?Resources on member servers

The migration of workstations and member servers is a straightforward process. The local groups that you create to assign permissions to users are located in the local Security Accounts Manager (SAM) database, and they are moved when you move the server. You do not have to reconfigure access control lists (ACLs) so that users can access resources after the migration.

To migrate domain controllers between domains, remove Active Directory Domain Services (AD DS) from the domain controller, migrate it as a member server to the target domain, and then reinstall AD DS.

Planning to Restructure Active Directory Domains Between Forests

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Completing the necessary planning tasks before you begin your migration helps ensure that users can continue to log on to the network and access resources during the migration. Planning your domain restructure involves the following: 

∙?Determining your account migration process

∙?Assigning object locations and roles

∙?Developing a test plan

∙?Creating a rollback plan for use if the migration fails

∙?Managing users, groups, and user profiles

∙?Creating an end-user communication plan

To prepare for the restructuring process, the Active Directory deployment team must obtain the necessary design information from the Active Directory design team.

The following illustration shows the steps involved in planning to restructure Active Directory domains between forests.

Determining Your Account Migration Process

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

With the Active Directory Migration Tool (ADMT), you can use security identifier (SID) history to maintain resource permissions when you migrate accounts. However, if SID filtering is enabled between your source and target domains and you do not trust the administrators in the source domain, you cannot disable SID filtering. Nor can you use SID history to enable access to resources in the source domain. In this case, you must use a different migration process.

You can choose one of the following three methods to migrate accounts between forests while maintaining user rights to access resources in the source domain:

∙?Migrate user accounts while using SID history for resource access. With this method, you remove SID filtering on the trusts between the domains to enable users to access resources in the source domain by means of their SID history credentials. 

∙?If you have a forest trust in place, you remove SID filtering on the forest trust. (You can also override the forest trust by creating an external trust so that the domain that holds the resources trusts the target domain and then removing SID filtering on the external trust.)

∙?If you do not have a forest trust in place, you establish external trusts between the source and target domains. You then have to remove SID filtering on the external trusts. 

For more information about this process, see Migrating Accounts While Using SID History, later in this guide.

∙?Migrate all users, groups, and resources to the target domain in one step. For more information about this process, see Migrating Accounts While Using SID History, later in this guide.

∙?Migrate user accounts without using SID history for resource access, but translate security for all resources before the migration process to ensure resource access. For more information about migrating accounts without using SID history, see Migrating Accounts Without Using SID History, later in this guide.

To determine which account migration process is best for your organization, you must first determine if you can disable SID filtering and migrate accounts while using SID history for resource access. You can safely do this if the administrators of the source domain fully trust the administrators of the target domain. You might disable SID filtering if one of the following conditions applies:

∙?The administrators of the trusting domain are the administrators of the trusted domain.

∙?The administrators of the trusting domain trust the administrators of the trusted domain and are confident that they have secured the domain appropriately.

If you disable SID filtering, you remove the security boundary between forests, which otherwise provides data and service isolation between the forests. For example, an administrator in the target domain who has service administrator rights or an individual who has physical access to a domain controller can modify the SID history of an account to include the SID of a domain administrator in the source domain. When the user account for which the SID history has been modified logs on to the target domain, it presents valid domain administrator credentials for, and can obtain access to, resources in the source domain.

For this reason, if you do not trust the administrators in the target domain or do not believe that the domain controllers in the target domain are physically secure, enable SID filtering between your source and target domains, and migrate user accounts without using SID history for resource access.

The following illustration shows the decision process involved in determining which migration process is appropriate for your organization.

Using SID History to Preserve Resource Access

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

The best practice for granting access to resources is to use global groups to arrange users, and domain local groups to protect resources. Place global groups into a domain local group to grant the members of the global group access to the resource. A global group can only contain members from its own domain. When a user is migrated between domains, any global groups to which the user belongs must also be migrated. This ensures that users can continue to access resources that are protected by discretionary access control lists (DACLs) referring to global groups. After migrating an account and maintaining the security identifier (SID) history of the source domain account, when a user logs on to the target domain, both the new SID and the original SID from the SID history attribute are added to the access token of the user. These SIDs determine the local group memberships of the user. The SIDs of the groups of which the user is a member are then added to the access token, together with the SID history of those groups. 

Resources within the source and target domains resolve their access control lists (ACLs) to SIDs and then check for matches between their ACLs and the access token when granting or denying access. If the SID or the SID history matches, access to the resource is granted or denied, according to the access specified in the ACL. If the resource is in the source domain and you have not run security translation, it uses the SID history of the user account to grant access. 

You can also preserve the original SID for global groups and universal groups in the SID history of the global group or universal group in the target domain. Because local group memberships are based on SIDs, when you migrate the SID to the SID history of the global group or universal group in the target domain, the local group memberships of the global group or universal group are preserved automatically. 

SID history is used for the following:

∙?Roaming user profile access 

∙?Certification authority access

∙?Software installation access

∙?Resource access 

If you are not using SID history for resource access, you still have to migrate SID history to facilitate access to those items.

Using SID Filtering When Migrating User Accounts

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

For a domain-to-domain trust, security identifier (SID) filtering does not allow for the use of SIDs from outside the trusted domain to enable access to any resource within the trusting domain. For a forest-to-forest trust, SID filtering does not allow for the use of SIDs from any domain outside the trusted forest to enable access to any resource within any domain in the trusting forest.  

You can enable the SID of a user in a different forest to access a resource within a forest that has SID filtering enabled by translating security on the resource to include the user SID in the permission list.

SID filtering is applied by default when a forest trust is established between two forest root domains. Also, SID filtering is enabled by default when external trusts are established between domain controllers that are running Windows 2000 Service Pack 4 (SP4) or later. This prevents potential security attacks by an administrator in a different forest.

Because SID filtering does not apply to authentication within a domain, it is also possible to allow access to resources by means of SID history, if the resource and the account are in the same domain. To allow users or groups to access a resource by using SID history, the forest in which the resource is located must trust the forest in which the account is located.

For more information about SID-history-based attacks and SID filtering, see Configuring SID Filtering Settings (http://go.microsoft.com/fwlink/?LinkId=73446). 

Assigning Object Locations and Roles

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Create an object assignment table that lists the roles and locations for all the objects that you are migrating. Create one table for account objects, such as users, groups, and service accounts, and one table for resource objects, such as workstations, profiles, and domain controllers. In your tables, list the source and target locations for all objects to be migrated.

Before you create your account object assignment table, determine whether the domain organizational unit (OU) structures for the source and target domains are the same. If they are not the same, you must identify the source and target OU in your object assignment tables.

For a worksheet to assist you in creating an account object assignment table, see "User and Group Object Assignment Table" (DSSREER_1.doc) in the Job_Aids_Designing_and_Deploying_Directory_and_Security_Services download of the Job Aids for Windows Server 2003 Deployment Kit (http://go.microsoft.com/fwlink?LinkId=14384). 

The following illustration shows an example of an object assignment table for users and groups.

To create a resource object assignment table, identify the source and target OU for each object and note the physical location and role in the target domain. For a worksheet to assist you in creating a resource object assignment table, see "Resource Object Assignment Table" (DSSREER_2.doc) in the Job_Aids_Designing_and_Deploying_Directory_and_Security_Services download of the Job Aids for Windows Server 2003 Deployment Kit (http://go.microsoft.com/fwlink?LinkId=14384).

The following illustration shows an example of a resource object assignment table.

Developing a Test Plan for Your Migration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

The Active Directory Migration Tool does not include a test migration option. However, you can develop a test plan to systematically test each object after it is migrated to the new environment and identify and correct any problems that might occur. Testing to verify that your migration is successful helps ensure that users who are migrated from the source to the target domain are able to log on, access resources based on group membership, and access resources based on user credentials. Testing also helps ensure that users are able to access the resources that you migrate. 

After your testing is complete, you can proceed with migrating small pilot groups and then gradually increase the size of each batch of migration objects in your production environment. 

Use the following process to test the migration of your account object and resource objects:

1.    Create a test user in the source domain. Include this test user with your migrations.

2.    Join that user to the appropriate global groups to enable resource access.

3.    Log on to the source domain as the test user, and verify that you can access resources as appropriate.

4.    After you migrate the user account, translate the user profile, and migrate the workstation of the user, log on to the target domain as the test user, and verify that the user has retained all necessary access and functionality. For example, you might test to verify that: 

∙?The user can log on successfully.

∙?The user has access to all appropriate resources, such as file and print shares; access to services such as messaging; and access to line-of-business (LOB) applications. It is especially important to test access to internally developed applications that access database servers.

∙?The user profile was successfully translated, and the user retains desktop settings, desktop appearance, shortcuts, and access to the My Documents folder. Also, verify that applications appear in and start from the Start menu.

You cannot migrate every user property when you migrate user accounts. For more information about user properties that cannot be migrated, see Migrate User Accounts, later in this guide.

After you migrate resources, log on as the test user in the target domain, and verify that you can access resources as appropriate.

If any steps in the test process fail, identify the source of the problem, and determine whether you can correct the problem before the object has to be accessible in the target domain. If you cannot correct the problem before access to the object is required, roll back to your original configuration to ensure access to the user or resource object. For more information about creating a rollback plan, see Creating a Rollback Plan, later in this guide.

As part of your test plan, create a migration test matrix. Complete a test matrix for each step that you complete in the migration process. For example, if you migrate 10 batches of users, complete the test matrix 10 times, once for each batch that you migrate. If you migrate 10 member servers, complete the test matrix for each of the 10 servers.

For a worksheet to assist you in creating a test matrix, see Migration Test Matrix (DSSREER_3.doc) in the Job_Aids_Designing_and_Deploying_Directory_and_Security_Services download of the Job Aids for Windows Server 2003 Deployment Kit (http://go.microsoft.com/fwlink?LinkId=14384).

The following illustration shows an example of a completed migration test matrix.

Creating a Rollback Plan

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Reduce the risk of disrupting end users in your organization by establishing a rollback plan. In general, it is possible to isolate and resolve any problems that occur during each phase of the migration. However, it is important to analyze potential risks and identify the levels of user impact and downtime that might necessitate rolling back the migration. You might be required to roll back your migration if any of the following occur:

∙?Users cannot log on to their accounts after migration.

∙?Users cannot access resources after migration.

∙?User migration is incomplete; for example, passwords did not migrate.

∙?User migration was successful, but user workstation migration or local profile translation failed.

If user impact or downtime reaches a level that you have defined as unacceptable in your organization, you can implement your rollback plan and continue to operate in your premigration environment. Because the source domain remains intact during the restructure, you can restore the original environment by completing a few key steps.

To roll back to the premigration environment after migrating account objects:

1.    Enable the user accounts in the source domain (if you disabled the accounts during the migration process).

2.    Notify the users to log off from the target domain.

3.    Notify the users to log on to the source domain.

4.    Verify that users can access resources.

5.    Verify that the logon scripts and user profiles for users work as configured in the source domain.

The rollback process for resource objects is similar to that for account objects. To roll back to the premigration environment after migrating resource objects:

1.    Change the domain membership for the server or workstation to the source domain.

2.    Restart the server or workstation.

3.    Log on as a user and verify that you can access the resource.   

Note 

If you have to modify objects, such as member servers or domain controllers, to migrate them to the target domain, back up all the data before you make the modifications and perform the migration.

Managing Users, Groups, and User Profiles

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

You must define how the objects that you are migrating are to be administered during the interforest restructure process. By establishing administrative procedures for migration objects, you can preserve the objects both in the source domain and the target domain. Consequently, you can fall back to the premigration environment if the restructure process is not successful. 

Plan for the administration and management of the following types of account migration objects:

∙?User accounts, including security identifiers (SIDs)

∙?Global group membership

∙?User profiles

Administering user accounts

During the migration process, user accounts exist in both the source and the target domains. Administer changes to user accounts in the domain in which the user object is active. Continue to administer changes to group memberships in the source domain while the migration is taking place. Use the Migrate and merge conflicting objects option in the Active Directory Migration Tool (ADMT) to remigrate user accounts as often as necessary during the migration process. This ensures that changes that are made to the account in the source domain are propagated to the account in the target domain. This operation merges the existing account and the new account so that administration of the object can continue in the source domain for the duration of the migration process.

The Migrate and merge conflicting objects option applies the following guidelines when an account is migrated:

∙?If you change an attribute in the target domain and it is not used in the source domain, it is not overwritten with the NULL value from the source domain.

∙?If you change an attribute in the target domain and it is used in the source domain, it is overwritten with the value from the source domain.

∙?If the user has group memberships, the memberships are merged from the source memberships and the target memberships.

If this is not the desired behavior, you can configure ADMT to exclude attributes from being migrated, so that attributes in the target domain are retained.

For example, suppose that after migrating a user, you set attributes on the new user object in the target domain, such as a telephone number or office number. You remigrate the user by using the Migrate and merge conflicting objects option in ADMT, and the new information is retained in the target domain. If you changed the group memberships for the user in the source domain, the changes are propagated to the target domain when you perform the remigration.

Some attributes are excluded from the migration. These attributes include the following:

∙?Attributes that are always excluded by the system

∙?Attributes that are in the system attribute exclusion list

∙?Attributes that are configured by the administrator to be excluded

Attributes that are always excluded by the system

Some attributes are always excluded from the migration by ADMT and cannot be configured to be migrated. This protects system-owned attributes. These attributes include the following:

∙?Object globally unique identifier (GUID)

∙?SIDs (Although SIDs can be added to the SID history of the object in the target domain.)

∙?LegacyExchangeDN

∙?objectSid

∙?sAMAccountName

∙?Rid

∙?pwdLastSet

∙?userPassword

∙?member

∙?userPrincipalName

∙?manager

∙?managedBy

∙?isCriticalSystemObject

∙?legacyExchangeDN

∙?lastLogonTimestamp

∙?dNSHostName

∙?msDS-AuthenticatedAtDC

System attribute exclusion list

The first time that you run an ADMT user migration, ADMT generates a system attribute exclusion list, which it stores in its database. The system attribute exclusion list contains two attributes by default: mail and proxyAddresses. ADMT also reads the schema in the target domain, and adds any attributes to the list that are not part of the base schema. Attributes in this list are excluded from migration operations even if the attribute is not specified in the attribute exclusion list. An administrator can change the system attribute exclusion list only by using a script. This protects attributes that are important in order for server-based applications, such as Microsoft Exchange, to work. If the target domain schema is further extended after ADMT has generated the list, administrators must manually add the new attributes to the list, unless they are certain that copying the values of these attributes from the source domain will not interfere with server-based applications. For more information about creating a script to exclude system attributes, see article 937537 (http://go.microsoft.com/fwlink/?LinkId=207024) in the Microsoft Knowledge Base.

Attribute exclusion list

Administrators can define a list of attributes that are excluded from each migration. This is called an attribute exclusion list. By default, when using the ADMT console, state information for attributes that are configured to be excluded is stored in the user interface (UI) and included in the exclusion list for the next migration. Scripting and command-line attributes do not have state information. Therefore, they are not stored in the UI. These attributes must be added to the attribute exclusion list for each migration operation, either by means of the attribute name or by means of an option file.

Administering global groups

Continue to administer the groups in the source domain during the migration process. Remigrate groups as often as necessary by using the Migrate and merge conflicting objects option in ADMT. This ensures that changes made to group memberships in the source domain are propagated to the groups in the target domain.

Planning for a user profile migration

User profiles store user data and information about the desktop settings of the user. User profiles can either be roaming or local. The migration process is different for local and for roaming profiles.

Profile translation is one type of security translation, and profiles are translated during the migration process. If you perform security translation in add mode, the SIDs in the target and the source domains both have access to the profile. Therefore, if you have to roll back to the source environment, the SID in the source domain can use the profile. If you perform security translation in replace mode, you must retranslate the profile by using a SID mapping file (undoing the security translation) to roll back to the source environment.

Important 

If you have to roll back to your original configuration, notify users that profile changes made in the target domain are not reflected in the source domain.

Some organizations might choose not to migrate user profiles. Other organizations might choose to replace users’ workstations during the user account migration process, and use a tool such as the User State Migration Tool (USMT) to migrate user data and settings to the users' new computers. The following table summarizes the migration requirements for user profiles.

Type	Description	Migration Requirements
Roaming profiles	User profiles are stored centrally on servers. Profiles are available to the user, regardless of the workstation in use.	If you are migrating roaming profiles that are used on Windows Vista or later, prepare the roaming profiles for migration. For more information, see Preparing for migration of roaming profiles with computers that run Windows Vista and later versions of Windows. During user account migration, select Translate roaming profiles on the User Options page in the User Account Migration Wizard. Then, translate local user profiles for a batch of users immediately after you migrate those users.
Local profiles	User profiles are stored locally on the workstation. When a user logs on to another workstation, a unique local user profile is created.	Translate local profiles as a separate step from the user account migration process. Select User profiles  option on the Translate Objects page of the Security Translation Wizard. Translate local user profiles for a batch of users immediately after migrating those users.
Profiles not managed	Same as local profiles.	Users lose their existing profiles when their user accounts are migrated.
Hardware refresh	User state information is stored locally on the workstation.	Migrate as a separate step from the user account migration. Migrate the profiles to the user’s new computer by means of a tool such as USMT.

Preparing for migration of roaming profiles with computers that run Windows Vista and later versions of Windows

A roaming profile location is configured for a domain user account, and specified in the following way:

\\host.name.fqdn\ProfileShare\<profilename>

Typically <profilename> is replaced with %username%. Thus the actual location of a roaming profile for user RoamUserX is:

\\host.name.fqdn\ProfileShare\RoamUserX

The roaming profile folder (in this example, RoamUserX) is created at the time of first logon for RoamUserX, and the actual profile data is stored within that folder.

Beginning with Windows Vista, a change was made to profiles that made them incompatible with previous versions of Windows. To differentiate the new profiles, a .V2 extension was added to all roaming profiles for users on computers running Windows Vista and later.

The location of a roaming profile for the same user RoamUserX for a computer that runs Windows Vista or later is:

\\host.name.fqdn\ProfileShare\RoamUserX.V2

This version can co-exist with a roaming profile for an earlier version of Windows. 

ADMT distinguishes the two different profile folder names. 

In order to migrate a roaming profile folder using ADMT, the default access control list of the folder needs to be modified. By default, when a user logs on and the roaming profile folder and contents are created, the <profilename> or <profilename>.V2 folders are given the following ACLs: 

∙?SYSTEM – Full Control

∙?user_name - Full Control

∙?Owner = user_name

Therefore, only the owner of the profile, and the local system on which the share resides, are able to access the <profilename> or <profilename>.V2 folder. When the folder is assigned those default permissions, ADMT cannot access the folder for security translation.

To configure the folder permissions in order to allow ADMT to migrate the roaming profile, you can enable a Group Policy setting for the domain:

Computer Configuration\Policies\Administrative Templates\System\User Profiles\Add the Administrators security group to the roaming user profiles

If this setting enabled and propagated before the first logon of the user (before the roaming profile is created), then the roaming profile directory will have an added permission that grants Full Control to members of the Administrators group of the share host (host.name.fqdn in this example).

After this setting is enabled, migrations can be performed as long as the user who runs ADMT is included in the Administrators group of the share.

The user who runs ADMT user needs Full Control access on the roaming profile folders. To achieve that, you can try one of the following options:

1.    

2.    Create a script (for example, using Windows PowerShell) that performs that following:

a.    Executes as SYSTEM on the share computer (host.name.fqdn in the example)

b.    Adds the Administrators security group to the ACL set of the profile folders – propagating to all subfolders and files

c.    Adds the Administrators security group with Full Control to the ACL set of the profile folders and have the permission inherited to all subfolders and files. 

3.    Create a script (for example, using Windows PowerShell) that performs that following:

a.    Runs in the context of each roaming user (for example, as a logon task).

b.    Adds the Administrators security group with Full Control to the ACL set of the profile folders and have the permission inherited to all subfolders and files.

Creating an End-User Communication Plan

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Develop a plan to inform all affected users about the upcoming account migration, to ensure that they understand their responsibilities, the impact of the migration, and who to contact for help and support.

Before you begin the user migration process, send a notice to all users who are scheduled to be migrated. Because you typically migrate users in batches of approximately 100 users at a time, it is also helpful to send a final notice to the users in each batch two to three days before their batch is scheduled. If your organization maintains an intranet, publish the account migration schedule and the information that is contained in the user mail on an easily accessible Web page.

Include the following information in your end-user communication.

General information

Alert users to the fact that their user accounts are scheduled to be migrated to a new domain. Point users to a Web page or internal resource where they can find additional information and view a migration schedule.

Inform users of their new domain name. Be sure to let them know that their account passwords will not change. Let users know that the original domain account will be disabled immediately following the migration and the disabled account will be deleted after a specified period of time. This is not necessary if the users log on with user principal names (UPNs).

Impact

Make sure that users understand that when their account is migrated, they might be unable to access some resources, such as Web sites, shared folders, or resources that individuals in their group or division do not widely use.

Provide information to users about whom to contact for assistance in regaining access to required resources.

Logon status during migration

Make sure that users understand that during the migration process they will be unable to log on to the domain or access e-mail or other resources. Be sure to specify the period of time for which they will be unable to log on.

Premigration steps

Alert users to any steps that they must complete before the migration process begins. For example, they must decrypt files encrypted by means of Encrypting File System (EFS). Failure to decrypt encrypted files will result in loss of access to encrypted files following the migration.

Users must also ensure that their computers are connected to the network when their account is scheduled to be migrated.

Expected changes

Describe other changes that users can expect to experience after the migration, such as changes in use of smart cards, secure e-mail, or instant messaging, if applicable.

Scheduling and support information

Provide information about where users can go to find more information For example, they can visit an internal Web site where you post information about the migration. Also, provide information about whom to contact if a user has a conflict with the date scheduled for the migration.

Preparing the Source and Target Domains

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Before you begin to migrate your accounts from the source domain to the target domain, you have to prepare the source and target domains for the migration. The following illustration shows the tasks that are required to prepare the domains for the interforest domain restructure process. 

Installing 128-Bit High Encryption Software

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

The computer on which the Active Directory Migration Tool (ADMT) is installed requires 128-bit high encryption. This encryption is standard on computers that are running Windows 2000 Server Service Pack 3 (SP3) or later. 

Establishing Required Trusts for Your Migration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Before you can migrate accounts and resources from a source domain to a target domain in a different Active Directory forest, you must ensure that the appropriate trusts exist between the forests. Trust relationships between the forests that you are restructuring makes it possible for the Active Directory Migration Tool (ADMT) to migrate users and service accounts and translate local user profiles from the source domains to the target domains. In addition, depending on how trust relationships are configured, users in the source domain can access resources in the target domain. Moreover, users in the target domains can access resources in the source domain that have not yet been migrated.

To migrate users and global groups, you must establish a one-way trust between the source domain and the target domain, so that the source domain trusts the target domain.

To migrate resources or translate local profiles, you must do one of the following:

∙?Create a one-way trust between the source domain and the target domain.

∙?Create a two-way trust between source and target domains.

For more information about creating trusts, see Creating Domain and Forest Trusts (http://go.microsoft.com/fwlink/?LinkId=77381).

Establishing Migration Accounts for Your Migration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

To migrate accounts and resources between forests, you must establish migration accounts and assign the appropriate credentials to those accounts. The Active Directory Migration Tool (ADMT) uses the migration accounts to migrate the objects that you identify. Because ADMT requires only a limited set of credentials, creating separate migration accounts helps you to simplify administration. If the migration tasks for your organization are distributed across more than one group, it is helpful to create a migration account for each group involved in performing the migration.

To simplify administration, create a single account in the source domain and a single account in the target domain for all objects, with the required credentials to modify the objects, such as users, managed service accounts, global groups, and local profiles, to be migrated by that account. For example, a migration account that you use to migrate user accounts along with the security identifier (SID) history, global groups along with SID history, computers, and user profiles has local administrator or domain administrator credentials in the source domain. The migration account also has delegated permission on the user, managed service account, group, and computer organizational units (OUs) in the target domain, with the extended right to migrate SID history on the user OU. The user must be a local administrator on the computer in the target domain on which ADMT is installed. A migration account that you use to migrate workstations and domain controllers must have local administrator or source domain administrator credentials on the workstations or the account must have source domain administrator credentials on the domain controller, or both.

In the target domain, it is necessary to use an account that has delegated permissions on the computer OU and the user OU. You might want to use a separate account for the migration of workstations if this migration process is delegated to administrators that are in the same location as the workstations.

The following table lists the credentials that are required in the source and target domains for different migration objects.

Migration object	Credentials necessary in source domain	Credentials necessary in target domain
User/managed service account/group without SID history	Delegated Read all user information permission on the user OU or group OU and domain administrator credential	Delegated Create, delete, and manage user accounts, Create, delete, and manage groups, and Modify the membership of a group for the user OU or the group OU and local administrator on the computer where ADMT is installed.
User/managed service account/group with SID history	Delegated Read all user information permission on the user OU or group OU and domain administrator credential	Delegated permission on the user OU or the group OU, extended permission to migrate SID history, and local administrator on the computer on which ADMT is installed.
Computer	Domain administrator or administrator in the source domain and on each computer	Delegated permission on the computer OU and local administrator on the computer on which ADMT is installed. Note  If the computer has a managed service account installed, you need to supply credentials that have permission to update the security descriptor of the managed service account in the target domain.
Profile	Local administrator or domain administrator	Delegated permission on the user OU and local administrator on the computer on which ADMT is installed. Note  You might need to complete additional preparation steps if you migrate roaming profiles for computers that run Windows Vista or later. For more information, see Preparing for migration of roaming profiles with computers that run Windows Vista and later versions of Windows.

The following procedures provide examples for creating groups or accounts to migrate accounts and resources. Procedures differ according to whether a one-way trust or a two-way trust exists The procedure for creating migration groups when a one-way trust exists is more complex than the procedure for when a two-way trust exists. This is because, with a one-way trust, you must add the migration group to the local Administrators group on local workstations. 

The sample procedure for creating migration groups when a one-way trust exists involves creating separate groups for migrating accounts and resources. However, you can combine acct_migrators and res_migrators into one group, if you do not need to separate them to delegate different sets of permissions.

To create an account migration group when a one-way trust exists in which the source domain trusts the target domain

1.    In the target domain, create a global group called acct_migrators. 2.    In the target domain, add the acct_migrators group to the Domain Admins group, or delegate administration of OUs that are targets for account migration to this group. 3.    If you are migrating SID history, and you did not place the acct_migrators group in the Domain Admins group, grant the acct_migrators group the Migrate SID History extended permission on the target domain object. To do this, follow these steps:  a.    Start Active Directory Users and Computers, right-click the domain object, and then click Properties. b.    Click the Security tab, click Add, and then select acct_migrators. If the Security tab does not appear, in Active Directory Users and Computers, click View, and then click Advanced Features. c.    In Permissions for acct_migrators, click Allow for the Migrate SID History permission. 4.    In the source domain, add the acct_migrators group to the Builtin\Administrators group. 5.    On each computer on which you plan to translate local profiles, add the acct_migrators group to the local Administrators group.

To create a resource migration group when a one-way trust exists in which the source domain trusts the target domain

1.    In the target domain, create a global group called res_migrators. 2.    In the target domain, add the res_migrators group to the Domain Admins group, or delegate administration of OUs that are targets for resource migration to this group. 3.    In the source domain, add the res_migrators group to the Administrators group. 4.    On each computer that you plan to migrate or on which you plan to perform security translation, add the res_migrators group to the local Administrators group.

To create a resource migration account when a two-way trust exists between the source and target domains

1.    In the source domain, create an account called res_migrator. 2.    In the source domain, add the res_migrator account to the Domain Admins group. (The Domain Admins group is a member of the local Administrators group on every computer in the domain by default. Therefore, you do not have to add it to the local Administrators group on every computer.) 3.    In the target domain, delegate permissions on OUs that are targets for resource migration to the res_migrator account.

ADMT also includes database administration roles that you can use to assign a subset of database permissions to users who perform specific migration tasks. The database administration roles and the migration tasks that they can perform are listed in the following table. 

Role	Migration task
Account migrators	Account migrations tasks, such as user and group migration.
Resource migrators	Resource migration tasks, such as computer migrations and security translation. Account migrators also hold the role of resource migrators.
Data readers	Queries against that database. Account migrators and resource migrators also hold the role of data readers.

Users who are assigned the role of SQL Server sysadmin hold all ADMT database administration roles. They have the credentials to do the following:

∙?Display database roles and users who hold those roles 

∙?Add groups or users to roles

∙?Remove groups or users from roles 

By default, the local Administrators group is assigned the role of sysadmin and can perform all ADMT database functions. 

Configuring the Source and Target Domains for SID History Migration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

You can manually configure the source and target domains to migrate the security identifier (SID) history before you begin an interforest migration, or you can allow the Active Directory Migration Tool (ADMT) to configure the domains automatically the first time that it runs. 

To configure the source and target domains manually, complete the following procedures: 

∙?Create a local group in the source domain to support auditing.

∙?Enable TCP/IP client support on the source domain primary domain controller (PDC) emulator.

Note 

If you are migrating from a domain with domain controllers that run Windows Server 2003 or later to another domain with domain controllers that run Windows Server 2003 or later, the TcpipClientSupport registry entry does not have to be modified.

∙?Enable auditing of account management in the source and target domains. For Windows Server 2008 and later, you need to also enable auditing for directory service access in order to migrate users with SID history between forests. 

To create a local group in the source domain to support auditing

∙?In the source domain, create a local group called SourceDomain$$$, where SourceDomain is the NetBIOS name of your source domain, for example, Boston$$$. Do not add members to this group; if you do, SID history migration will fail.

To enable TCP/IP client support on the source domain PDC emulator

1.    On the domain controller in the source domain that holds the PDC emulator operations master (also known as flexible single master operations or FSMO) role, click Start, and then click Run. 2.    In Open, type regedit, and then click OK. Caution  Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after you make changes. 3.    In Registry Editor, navigate to the following registry subkey:  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA 4.    Modify the registry entry TcpipClientSupport, of data type REG_DWORD, by setting the value to 1. 5.    Close Registry Editor, and then restart the computer.

To enable auditing in Windows Server 2008 and later domains

1.    Log on as an administrator to any domain controller in the target domain. 2.    Click Start, point to All Programs, point to Administrative Tools, and then click Group Policy Management. 3.    Navigate to the following node: Forest | Domains | Domain | Domain Controllers | Default Domain Controllers Policy 4.    Right-click Default Domain Controllers Policy and click Edit.  5.    In Group Policy Management Editor, in the console tree, navigate to the following node: Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | Audit Policy 6.    In the details pane, right-click Audit account management, and then click Properties.  7.    Click Define these policy settings, and then click Success and Failure.  8.    Click Apply, and then click OK. 9.    In the details pane, right-click Audit directory service access and then click Properties.  10.    Click Define these policy settings and then click Success.  11.    Click Apply, and then click OK. 12.    If the changes need to be immediately reflected on the domain controller, open an elevated command prompt and type gpupdate /force. 13.    Repeat steps 1 through 12 in the source domain.

Configuring the Target Domain OU Structure for Administration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

The Active Directory design team creates the organizational unit (OU) structure for the target domain. This team also defines the groups that are responsible for the administration of each OU and the membership of each group. You can use that information and the following procedure to configure the target domain for administration. 

To configure the target domain OU structure for administration

1.    Log on as an administrator to any domain controller in the target domain. 2.    Start Active Directory Users and Computers, and then create the OU structure that your design team specified. 3.    Create administrative groups, and assign users to these groups. 4.    Delegate the administration of the OU structure to groups as defined by your design team.

Installing ADMT in the Target Domain

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

ADMT requires a SQL Server database instance to be previously installed. You can run any version of SQL Server.

∙?Installing ADMT

∙?Detach an Existing Database File from a Previous Version of ADMT and SQL Server

∙?Reconfiguring a Database Installation with Admtdb.exe

∙?Reuse an Existing ADMT Database from a Previous Installation

Installing ADMT

ADMT can be downloaded from the Microsoft Connect (http://go.microsoft.com/fwlink/?LinkId=401534) site. It requires a preconfigured instance of SQL Server for its underlying data store. If you use SQL Server Express, the ADMT console must be installed and run locally on the server that hosts the SQL Server Express database instance. If you use a full version of SQL Server, you can install and run the ADMT console on a remote computer, and you can run multiple ADMT consoles on different remote computers.

The rest of this section covers the following installation issues:

∙?Prerequisites for installing ADMT

∙?Install ADMT

Prerequisites for installing ADMT

Before you install ADMT, complete the following prerequisite tasks:

∙?In Control Panel, use Add or Remove Programs to remove all previous versions of ADMT. 

Although ADMT does not support an upgrade from a previous version, you can reuse an existing database from a previous ADMT installation, unless it is a database from ADMT v2 or ADMT v1. For more information, see Reuse an existing ADMT database from a previous installation. 

∙?ADMT must not be installed on a server that runs Server Core or a read-only domain controller (RODC).

∙?Configure a SQL Server database installation with an ADMT instance. You can either download and install SQL Server Express locally or create a database instance for ADMT from an existing SQL Server database.

For more information about creating an ADMT instance on an existing SQL Server database, see Install ADMT by Reconfiguring a Database Installation with Admtdb.exe.

Install ADMT

Download SQL Server Express, or create a new database instance on an existing SQL Server installation to use with ADMT. During the SQL Server installation, select Windows Authentication Mode. After you install SQL Server, use the following procedure to install ADMT.

Membership in Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To install ADMT

1.    In the ADMT download package, double-click admtsetup32.exe. 2.    On the Welcome page, ensure that the recommendations are completed, and then click Next. 3.    On the License Agreement page, click I Agree, and then click Next. 4.    On the Database Selection page, type the server\instance.  The requirement to type the server name also applies to a local database instance. You can type a dot (“.”) to indicate the local server. By default, the SQL Server Express instance is named SQLEXPRESS. For example, to use a default SQL Server Express instance on the local server, type .\SQLEXPRESS. 5.    If you chose a SQL Express installation and a database file ADMT.mdf is not in the default data location %windir%\ADMT\Data, the Database Import page appears. Otherwise, ADMT Setup automatically attaches to that database file, and the Summary page appears. On the Database Import page, if you do not need to import data, click No, do not import data from an existing database (Default). If you need to import data from a previous ADMT installation, click Yes, import data from an existing ADMT v3.0 or ADMT v3.1 database, and then, to navigate to the existing database file location, click Browse. Before you can import the data from an existing database, you have to detach the database file from SQL Server by using SQL Server commands. For more information, see Detach an existing database file from a previous version of ADMT and SQL Server.  When you are finished, click Next. 6.    On the Summary page, review the results of the installation, and then click Finish.

Detach an Existing Database File from a Previous Version of ADMT and SQL Server

If you use SQL Server Express, the database is automatically detached when you remove ADMT. The detached SQL Server Express database can be reused as part of another ADMT installation later. In this case, ADMT automatically attaches to the existing database that you specify during installation. 

You can detach the ADMT database file from a full SQL Server instance if you have another application that you want to attach to the same database. For example, if you plan to move from a full SQL Server installation to SQL Server Express, or if you have an ADMT database file from an earlier installation that you have attached to SQL Server management tools, it needs to be detached from that database before it can be consumed by ADMT.

To detach a database, you can use the SQL stored procedure: 

sp_detach_db [ @dbname = ] 'dbname'

For more information about this stored procedure call, see SQL Server documentation. For more information about how to use SQL Server Management Studio to detach the database, see How to: Detach a Database (SQL Server Management Studio (http://go.microsoft.com/fwlink/?LinkId=183994).

Reconfiguring a Database Installation with Admtdb.exe

If you experience problems with database configuration during installation, or if you specified SQL Server Express during the ADMT installation but want to switch to SQL Server (or vice versa) after installation, you can use Admtdb.exe. The command-line syntax for Admtdb.exe is in the following table.

You can run Admtdb.exe from an elevated command prompt on any server that can target the server computer that is running SQL Server to create the ADMT instance on that server computer.

Syntax	Description
admtdb create /{s|server}: "Server\instance"	Installs a new ADMT database or prepares an empty database.  The /server parameter specifies the name of the SQL Server and instance to connect to for the purpose of creating the database. This is a required parameter.
admtdb upgrade /s|server: Server\Instance	Upgrades a previous version of an ADMT v3.0 or ADMT v3.1 database. The /server parameter, which is required, specifies the name of the SQL Server and instance to connect to for the purpose of upgrading the ADMT v3.0 or ADMT v3.1 database. Note  Before you upgrade the ADMT database, first open the ADMT console to verify that it is compatible with the database.
admtdb attach [/{a|attach}: "v3x database path"	Attaches an existing ADMT database to the local SQL Server Express instance. The /attach parameter, which is required, specifies the path to a detached Admt.mdf database file.

To see Help for all Admtdb.exe command-line options, at the command prompt, type admtdb /?.

If you began the migration by using a local SQL Server Express database and then configured a remote instance of a SQL Server database, and you need to switch back to using a local SQL Server Express database, complete the following procedure. In this case, the ADMT database file is already attached to the SQL Express instance. Therefore, there is no need to explicitly reattach it. 

If you began the migration by using SQL Server and you want to switch to SQL Server Express, see Reuse an existing ADMT database from a previous installation. 

Membership in Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To reuse a local database after you configure a remote instance of a SQL Server database 

1.    On the local computer, click Start, point to Administrative Tools, and then click Services. 2.    In the Details pane, ensure that the service hosting the SQL Server Express instance is running and that the Startup Type is set to Automatic.  If the service is not started or if it is not set to start automatically at system startup, click Started, right-click the name of the service, and then click Properties. 3.    On the General tab, in the Startup Type list, click Automatic. 4.    Under Service Status, click Start, and then click OK. 5.    Close Services. 6.    At the command prompt, type the following commands: Note  The admtdb attach command is necessary only if you previously ran SQL commands to detach the local SQL Server Express instance.  admtdb attach /{s | Server}:”Local SQL Server Express instance”  admt config setdatabase /s:Server\Instance. You can now use the local database.

Reuse an Existing ADMT Database from a Previous Installation

If you want to use an existing (detached) database from an earlier ADMT installation with a local SQL Server instance, you can complete the following procedure.

Note 

Membership in Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477). 

To use an existing (detached) ADMT database with a local SQL Server instance 

1.    On the local computer, click Start, point to Administrative Tools, and then click Services. 2.    In the details pane, ensure that the service hosting the SQL Server Express instance is running and that the Startup Type is set to Automatic.  If the service is not started or if it is not set to start automatically at system startup, click Started, right-click the name of the service, and then click Properties. 3.    On the General tab, in the Startup Type list, click Automatic. 4.    Under Service Status, click Start, and then click OK. 5.    Close Services. 6.    At the command prompt, type the following commands: admtdb attach /{s | Server}:”Local SQL Server Express instance” /{a | Attach}:”Path to ADMT v3.x database file to attach" admt config setdatabase /s: server\instance You can now use the existing ADMT database with the local SQL Server instance. It is not necessary to run the ADMT installation wizard again. ADMT installation can be run only once. You can perform any subsequent database configuration changes by using the admtdb.exe and admt config setdatabase commands. To use the Password Export Server with the new ADMT installation, you need to generate a new encryption key. For more information, see Enabling Migration of Passwords.

Enabling Migration of Passwords

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

The Active Directory Migration Tool (ADMT) uses the Password Export Server service version 3.1 (PES v3.1) to help you migrate passwords when you perform an interforest migration. PES v3.1 can be downloaded from Microsoft Connect (http://go.microsoft.com/fwlink/?LinkId=401534), the same location where you can download ADMT. The PES service can be installed on any writable domain controller in the source domain that supports 128-bit encryption.

Note 

The PES service cannot be installed on read-only domain controllers (RODCs).

Because ADMT does not check all settings of the target domain password policy, users need to explicitly set their password after migration unless the Password never expires or Smartcard is required for interactive logon flags are set. 

The PES service installation in the source domain requires an encryption key. However, you must create the encryption key on the computer running the ADMT in the target domain. When you create the key, save it to a shared folder on your network or onto removable media so that you can copy it to the local drive of the source domain controller where the PES service is installed. Store it in a secure location that you can reformat after the migration is complete.

You can install the PES service after you install ADMT. The following procedures explain how to install and use the PES service on computers running Windows Server 2008 or later.

Membership in Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To create an encryption key

∙?At a command line, type the following command, and then press ENTER:  admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> /keypassword:{<password>|*} Value Description <SourceDomain> Specifies the name of the source domain in which the PES service is being installed. Can be specified as either the Domain Name System (DNS) or NetBIOS name. <KeyFilePath> Specifies the path to the location where the encrypted key is stored. {<password>|*} A password, which provides key encryption, is optional. To protect the shared key, type either the password or an asterisk (*) on the command line. The asterisk causes you to be prompted for a password that is not displayed on the screen.

After you create the encryption key, configure the PES service on a domain controller in the source domain.

ADMT provides the option to run the PES service under the Local System account or by using the credentials of an authenticated user in the target domain. We recommend that you run the PES service as an authenticated user in the target domain. This way, you do not have to add the Everyone group and the Anonymous Logon group to the Pre–Windows 2000 Compatible Access group.

Note 

If you run the PES service under the Local System account, ensure that the Pre–Windows 2000 Compatible Access group in the target domain contains the Everyone group and the Anonymous Logon group.

To configure the PES service in the source domain

1.    On the domain controller that runs the PES service in the source domain, insert the encryption key disk. 2.    Launch an elevated command window and run Pwdmig.msi. If you set a password during the key generation process on the domain controller in the target domain, provide the password that was given when the key was created, and then click Next. Wizard page Action Welcome to the ADMT Password Migration DLL Installation Wizard Click Next. Encryption File To install the ADMT Password Migration dynamic-link library (DLL), you must specify a file that contains a valid password encryption key for this source domain. The key file must be located on a local drive. You use the admt key command to generate the key files. For more information, see the previous procedure "To create an encryption key." Run the service as Specify the account that you want the PES service to run under. You can specify either of the following accounts: ∙?The local System account ∙?A specified user account Note  If you plan to run the PES service as an authenticated user account, specify the account in the format domain\user_name. Summary Click Finish to complete the PES service installation. Note  To use the password migration of ADMT, you must restart the server where you installed the PES service. 3.    After installation completes, restart the domain controller. 4.    After the domain controller restarts, to start the PES service, point to Start, point to All Programs, point to Administrative Tools, and then click Services.  5.    In the details pane, right-click Password Export Server Service, and then click Start. Note  Run the PES service only when you migrate passwords. Stop the PES service after you complete the password migration.

Initializing ADMT by Running a Test Migration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Start the Active Directory Migration Tool (ADMT) by running a test migration of a global group, and select the option named Migrate Group SIDs to target domain. In order to migrate security identifier (SID) history, you need to complete the preparation tasks as described in Configuring the Source and Target Domains for SID History Migration. If you did not previously configure the source and target domains to migrate the SID history, ADMT prompts you and provides an option to have the following tasks completed automatically.

∙?Creates a local group, source_domain$$$, in the source domain, which is used to audit SID history operations. Do not add members to this group; if you do, SID history migration will fail.

∙?Enables audit policies in the source and target domains.

Warning 

ADMT does not automatically enable auditing for directory service access, which is required in order to migrate SID history to or from a domain that has domain controllers that run Windows Server 2008 or later. 

Use the following procedure to initialize ADMT.

To initialize ADMT by running a test migration of a global group

1.    In the ADMT console, use the Group Account Migration Wizard by completing the steps in the following table. Accept default settings when no information is specified. Wizard page Action Domain Selection Under Source, in the Domain drop-down list, type or select the NetBIOS or Domain Name System (DNS) name of the source domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller. Under Target, in the Domain drop-down list, type or select the NetBIOS or DNS name of the target domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller, and then click Next. Group Selection Click Select groups from domain, and then click Next. On the Group Selection page, click Add to select the groups in the source domain that you want to migrate, click OK, and then click Next. Or  Click Read objects from an include file, and then click Next. Type the location of the include file, and then click Next. Organizational Unit Selection Type the name of the OU, or click Browse. In the Browse for Container dialog box, find the container in the target domain that you want to move the global groups into, and then click OK. Group Options Select the Migrate Group SIDs to target domain check box. Make sure that all other options are not selected. User Account Type the user name, password, and domain of an account that has administrative rights in the source domain. Conflict Management Click Do not migrate source object if a conflict is detected in the target domain. 2.    When the wizard has finished running, click View Log, and then review the migration log for any errors.

Identifying Service Accounts for Your Migration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

This topic explains how to identify service accounts that the Active Directory Migration Tool (ADMT) will migrate to the target domain. A service account is a user account that provides a security context for applications and that is granted permission to log on as a service. 

ADMT does not migrate services that run in the context of the Local System account because they are migrated when the computer is migrated. However, services that run in the context of a user account must be updated on the computer after you have completed the account migration process. ADMT also cannot migrate the Local Service or Network Service accounts because they are well-known accounts that always exist in domains.

Identifying Service Accounts

The process of identifying, migrating, and updating services that run in the context of user accounts involves three steps. First, the administrator starts ADMT from the target Active Directory domain and runs the Service Account Migration Wizard. Second, the Service Account Migration Wizard sends an agent to a specified computer and identifies (but does not migrate) all of the services on the computer that are running in the context of a user account. Third, which can occur later in the migration process, the accounts are migrated when other user accounts are migrated with the User Account Migration Wizard.

The Service Account Migration Wizard scans an administrator-defined list of servers for services that are configured to use a domain account to authenticate. The accounts are then flagged as service accounts in the ADMT database. The password is never migrated when a service account is migrated. Instead, ADMT uses a clear-text representation of the password to configure the services after the service account migration. An encrypted version of the password is then stored in the password.txt file in the ADMT installation folder.

An administrator of a workstation or server can install any service and configure the service to use any domain account. If a malicious user who has administrator privileges configures a service to authenticate without a correct password (such as a password that does not meet complexity requirements), the service will not start. After the service account is migrated, ADMT configures the service on the workstation or the server to use the new password, and the service will now start using the user account in the target domain.

Therefore, you should include in the Service Account Migration Wizard only those servers that trusted administrators manage. Do not use the wizard to detect service accounts on computers that trusted administrators do not manage, such as workstations.

Dispatch agents to all servers that trusted administrators manage in the domain to ensure that you do not overlook any service accounts. If you miss a service account that shares an account with a service that has already been migrated, ADMT cannot synchronize the service accounts. You must manually change the password for the service account and then reset the service account password on each server that is running that service.

When the accounts that the Service Account Migration Wizard identifies in the ADMT database as running in the context of a user account are migrated to the target domain, ADMT grants each account the right to log on as a service. If the service account is assigned rights by means of its membership in a group, the Security Translation Wizard updates the account to assign those rights. For more information about running the Security Translation Wizard, see Transitioning Service Accounts in Your Migration later in this guide.

You can identify service accounts by using the ADMT snap-in, the ADMT command-line option, or a script.

To identify service accounts by using the ADMT snap-in

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 2.    In the ADMT snap-in, click Action, and then click Service Account Migration Wizard. 3.    Complete the Service Account Migration Wizard by using the information in the following table. Wizard page Action Domain Selection Under Source, in the Domain drop-down list, type or select the NetBIOS or Domain Name System (DNS) name of the source domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller. Under Target, in the Domain drop-down list, type or select the NetBIOS or DNS name of the target domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller, and then click Next. Update Information Click Yes, update the information. Computer Selection Option Click Select computers from domain, and then click Next. On the Service Account Selection page, click Add to select the accounts in the source domain that you want to migrate, click OK, and then click Next. Or  Click Read objects from an include file, and then click Next. Type the location of the include file, and then click Next. Agent Dialog In Agent Actions, select Run pre-check and agent operation, and then click Start. A message will appear in the Agent Summary when the agent operations are complete. After the agent operations finish, click Close. Service Account Information Select any user accounts that do not have to be marked as service accounts in the ADMT database, and then click Skip/Include to mark the accounts as Skip. Completing the Service Account Migration Wizard Review your selections, and then click Finish.

The wizard connects to the selected computers and then sends an agent to check every service on the remote computers. The Service Account Information page lists the services that are running in the context of a user account and the name of that user account. ADMT notes in its database that these user accounts have to be migrated as service accounts. If you do not want a user account to be migrated as a service account, select the account, and then click Skip/Include to change the status from Include to Skip.

You use Update SCM to update the Service Control Manager with the new information. Unless you have a failure in reaching a computer to update the service, the Update SCM button is not available. If you have a problem updating a service account after the account was identified and migrated, ensure that the computer that you are trying to reach is available, and then restart the Service Account Migration Wizard. 

In the wizard, click Update SCM to try to update the service. If you ran the Service Account Migration Wizard previously and the Update SCM button is not available, examine the ADMT log files to determine the cause of the problem. After you correct the problem and the agent can connect successfully, the Update SCM button becomes available.

To identify service accounts by using the ADMT command-line option

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 2.    At the command line, type the following command, and then press ENTER:  ADMT SERVICE /N "<computer_name1>" "<computer_name2>" /SD:" <source_domain>" /TD:" <target_domain>" Where <computer_name1> and <computer_name2> are the names of computers in the source domain that run service accounts. As an alternative, you can include parameters in an option file that is specified at the command line as follows: ADMT SERVICE /N "<computer_name1>" "<computer_name2>" /O:" <option_file>.txt" The following table lists the common parameters that are used for the identification of service accounts, along with the command-line parameter and option file equivalents. Values Command-line syntax Option file syntax <Source domain> /SD:"source_domain" SourceDomain="source_domain" <Target domain> /TD:"target_domain" TargetDomain="target_domain" 3.    Review the results that are displayed on the screen for any errors.

To identify service accounts by using a script

∙?Create a script that incorporates ADMT commands and options for identifying service accounts by using the following sample script. Copy the script to Notepad, and save the file with a .wsf file name extension in the same folder as the AdmtConstants.vbs file. <Job id="IdentifyingServiceAccounts" > <Script language="VBScript"  src="AdmtConstants.vbs" /> <Script language="VBScript" >   Option Explicit   Dim objMigration   Dim objServiceAccountEnumeration   '   'Create instance of ADMT migration objects.   '   Set objMigration = CreateObject("ADMT.Migration" )   Set objServiceAccountEnumeration = _  objMigration.CreateServiceAccountEnumeration   '   'Specify general migration options.   '   objMigration.SourceDomain = "source domain"    '   'Enumerate service accounts on specified computers.   '   objServiceAccountEnumeration.Enumerate admtData, _  Array("computer name1" ,"computer name2" )   Set objServiceAccountEnumeration = Nothing   Set objMigration = Nothing </Script> </Job>

Migrating Accounts

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

The process of migrating account objects from a source domain to a target domain in another Active Directory forest involves first migrating service accounts and then migrating global groups. After the groups are in place in the target domain, you can migrate users according to the process that you selected, either while using the security identifier (SID) history for resource access or without using SID history for resource access. When the account object migration process is complete, you can instruct users from the source domain to log on to the target domain. The following illustration shows the process for migrating accounts between domains in different forests. 

Transitioning Service Accounts in Your Migration

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Begin the process of migrating objects by migrating service accounts that run as domain user accounts. For information about identifying service accounts for migration, see Transitioning Service Accounts in Your Migration. This topic does not apply to standalone managed service accounts. Standalone managed service accounts can be migrated using the Managed Service Account Migration Wizard and the Computer Migration Wizard. Group managed service accounts cannot be migrated. 

To transition service accounts, use the Active Directory Migration Tool (ADMT) to complete the following tasks:

∙?Migrate the service accounts from the source domain to the target domain.

∙?Modify the services on each server in the source domain so that the services use the service account in the target domain instead of in the source domain.

You can transition service accounts by using the ADMT snap-in, the ADMT command-line option, or a script.

To transition service accounts by using the ADMT snap-in

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 2.    In the ADMT snap-in, click Action, and then click User Account Migration Wizard. 3.    Complete the User Account Migration Wizard by using the information in the following table. Wizard page Action Domain Selection Under Source, in the Domain drop-down list, type or select the NetBIOS or Domain Name System (DNS) name of the source domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller. Under Target, in the Domain drop-down list, type or select the NetBIOS or DNS name of the target domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller, and then click Next. User Selection Click Select users from domain, and then click Next. On the User Selection page, click Add to select the accounts in the source domain that you want to migrate, click OK, and then click Next. Or  Click Read objects from an include file, and then click Next. Type the location of the include file, and then click Next. Organizational Unit Selection Click Browse. In Browse for Container, locate the source domain, select the container for the service accounts, and then click OK. Password Options Click Generate complex passwords. Note  When you transition service accounts by using the User Account Migration Wizard, a complex password is generated automatically, regardless of the option that is selected on this wizard page. Even if Do not update passwords for existing users is selected, a complex password is generated. Account Transition Options Click Enable target accounts. Select the Migrate user SIDs to target domains check box. User Account Type the user name, password, and domain of a user account that has administrative credentials. User Options Select the Update user rights check box. Ensure that no other settings are selected, including Migrate associated user groups.  Conflict Management Click Do not migrate source object if a conflict is detected in the target domain. Service Account Information Click Migrate all service accounts and update SCM for items marked include. If you are also migrating other user accounts that are not service accounts, this wizard page tells you that you have selected some accounts that are marked as service accounts in the ADMT database. By default, the accounts are marked as Include. To change the status of the account, select the account, and then click Skip/Include. Click Next to migrate the accounts. 4.    When the wizard has finished running, click View Log, and review the migration log for any errors. 5.    Start Active Directory Users and Computers, navigate to the organizational unit (OU) that you created for service accounts, and then verify that the service accounts exist in the target domain OU. 6.    Confirm that each application for which the service account was relocated continues to function correctly.

To transition service accounts by using the ADMT command-line option

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 2.    At the command line, type the following command, and then press ENTER:  ADMT USER /N "<server_name1>" "<server_name2>" /SD:" <source_domain>" /TD:" <target_domain>" /TO:" <target_OU>" /MSS:YES Where Server_name1 and Server_name2 are the names of servers in the source domain that run service accounts. As an alternative, you can include parameters in an option file that is specified at the command line, as follows: ADMT USER /N "<server_name1>" "<server_name2>" /O: "<option_file>.txt" The following table lists the common parameters that are used for transitioning service accounts, along with the command-line parameter and option file equivalents. Parameters Command-line syntax Option file syntax <Source domain> /SD:"source_domain" SourceDomain="source_domain" <Target domain> /TD:"target_domain" TargetDomain="target_domain" <Target OU> location /TO:"target_OU" TargetOU="target_OU" Disable accounts /DOT:ENABLETARGET (default) DisableOption=ENABLETARGET (default) Migrate password /PO:COMPLEX (default) PasswordOption=COMPLEX Migrate user SIDs = YES /MSS:YES MigrateSIDs=YES Update user rights=YES /UUR:YES UpdateUserRights=YES Conflict management  /CO:IGNORE (default) ConflictOptions=IGNORE (default) 3.    Review the results that appear on the screen for any errors. 4.    Open Active Directory Users and Computers and locate the target service account OU. Verify that the service accounts exist in the target domain OU.

To transition service accounts by using a script

∙?Prepare a script that incorporates ADMT commands and options for transitioning service accounts by using the following sample script. Copy the script to Notepad, and save the file with a .wsf file name extension in the same folder as the AdmtConstants.vbs file. <Job id=" TransitioningServiceAccountsBetweenForests" > <Script language=" VBScript"  src="AdmtConstants.vbs" /> <Script language="VBScript" >   Option Explicit   Dim objMigration   Dim objUserMigration   '   'Create instance of ADMT migration objects.   '   Set objMigration = CreateObject("ADMT.Migration" )   Set objUserMigration = objMigration.CreateUserMigration   '   'Specify general migration options.   '   objMigration.SourceDomain = "source domain"    objMigration.SourceOu = "source container"    objMigration.TargetDomain = "target domain"    objMigration.TargetOu = "target container"    objMigration.ConflictOptions = admtIgnoreConflicting   '   'Specify user migration specific options.   '   objUserMigration.MigrateSIDs = True   objUserMigration.UpdateUserRights = True   objUserMigration.MigrateServiceAccounts = True   '   'Migrate specified service accounts.   '   objUserMigration.Migrate admtData, _  Array("service account name1", "service account name2")   Set objUserMigration = Nothing   Set objMigration = Nothing </Script> </Job>

Migrating Global Groups

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

To preserve the memberships of global groups, you must migrate global groups before you migrate users. 

Note 

Do not migrate global groups during peak work hours. The global group migration process can consume a large amount of network resources and resources on the domain controller in the target domain. 

Global group migration involves performing the following steps: 

1.    The administrator selects global group objects in the source domain. 

2.    A new global group object is created in the target domain, and a new primary security identifier (SID) is created for the object in the target domain. 

3.    To preserve resource access, the Active Directory Migration Tool (ADMT) adds the SID of the global group in the source domain to the SID history attribute of the new global group in the target domain. 

After the migration, events are logged in both the source and the target domain. 

Note 

If the user account migration process takes place over an extended period of time, you might have to remigrate global groups from the source to the target domain. The objective is to propagate membership changes that are made in the source domain before the migration process is complete. For more information about remigrating global groups, see Remigrating All Global Groups After All Batches Are Migrated, later in this guide.

You can migrate global groups by using the ADMT snap-in, the ADMT command-line option, or a script.

To migrate global groups by using the ADMT snap-in

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 2.    Use the Group Account Migration Wizard by performing the steps in the following table. Wizard page Action Domain Selection Under Source, in the Domain drop-down list, type or select the NetBIOS or Domain Name System (DNS) name of the source domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller. Under Target, in the Domain drop-down list, type or select the NetBIOS or DNS name of the target domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller, and then click Next. Group Selection Click Select groups from domain, and then click Next. On the Group Selection page, click Add to select the groups in the source domain that you want to migrate, click OK, and then click Next. Or  Click Read objects from an include file, and then click Next. Type the location of the include file, and then click Next. Organizational Unit Selection Type the name of the organizational unit (OU), or click Browse. In the Browse for Container dialog box, find the container in the target domain that you want to move the global groups into, and then click OK. Group Options Click Migrate Group SIDs to target domain. Make sure that all other options are not selected. User Account Type the user name, password, and domain of an account that has administrative rights in the source domain. Conflict Management Click Do not migrate source object if a conflict is detected in the target domain. 3.    When the wizard has finished running, click View Log, and review the migration log for any errors. 4.    Open the Active Directory Users and Computers snap-in, and then locate the target OU. Verify that the global groups exist in the target domain OU.

To migrate global groups by using the ADMT command line option

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 2.    At the command line, type the ADMT Group command with the appropriate parameters, and then press ENTER: ADMT GROUP /N "<group_name1>" "<group_name2>" /SD:" <source_domain>" /TD:" <target domain>" /TO:" <target OU>" /MSS:YES As an alternative, you can include parameters in an option file that is specified at the command line as follows: ADMT GROUP /N "<group_name1>" "<group_name2>" /O: "<option_file>.txt" The following table lists the common parameters that are used for migrating global groups, along with the command-line parameter and option file equivalents. Parameters Command-line syntax Option file syntax <Source domain> /SD:"source_domain" SourceDomain="source_domain" <Source OU> location /SO:"source_OU" SourceOU="source_OU" <Target domain> /TD:"target_domain" TargetDomain="target_domain" <Target OU> location /TO:"target_OU" TargetOU="target_OU" Migrate GG SIDs /MSS:YES MigrateSIDs=YES Conflict management /CO:IGNORE (default) ConflictOptions=IGNORE 3.    Review the results that appear on the screen for any errors. 4.    Open the Active Directory Users and Computers snap-in and locate the target OU. Verify that the global groups exist in the target domain OU.

To migrate global groups by using a script

∙?Prepare a script that incorporates ADMT commands and options for migrating global groups by using the following sample script. Copy the script to Notepad, and save the file with a .wsf file name extension in the same folder as the AdmtConstants.vbs file. <Job id=" MigratingGlobalGroupsBetweenForests" > <Script language="VBScript"  src="AdmtConstants.vbs" /> <Script language="VBScript" >   Option Explicit   Dim objMigration   Dim objGroupMigration   '   'Create instance of ADMT migration objects.   '   Set objMigration = CreateObject("ADMT.Migration" )   Set objGroupMigration = objMigration.CreateGroupMigration   '   'Specify general migration options.   '   objMigration.SourceDomain = "source domain"     objMigration.SourceOu = "source container"    objMigration.TargetDomain = "target domain"    objMigration.TargetOu = "target container"    '   'Specify group migration specific options.   '   objGroupMigration.MigrateSIDs = True   '   'Migrate specified group objects.   '   objGroupMigration.Migrate admtData, Array("group name1" ,"group name2" )   Set objGroupMigration = Nothing   Set objMigration = Nothing </Script> </Job>

Migrating Accounts While Using SID History

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

To migrate accounts while using the security identifier (SID) history, first migrate all the user accounts—but do not enable them in the target domain—to prepopulate the target domain and allow migration of user profiles. After all the user accounts are successfully migrated, begin migrating users in batches by migrating first the user profile, then the workstation, and then the user account. Before you migrate all user accounts, ensure that you have created test accounts that you can include in each batch to verify the success of the migration for that batch. 

You cannot migrate every user property when you migrate user accounts. For example, Protected Storage (Pstore) contents for Windows NT 4.0 workstations, including Encrypting File System (EFS) private keys, are not migrated by the Active Directory Migration Tool (ADMT) when you migrate user accounts. To migrate Pstore contents, you must export and import keys during the migration process. 

For clients that are running Windows 2000 Server or later, data that is protected by the Data Protection API (DPAPI) is also not migrated. DPAPI helps protect the following items:

∙?Web page credentials (for example, passwords)

∙?File share credentials

∙?Private keys that are associated with EFS, Secure/Multipurpose Internet Mail Extensions (S/MIME), and other certificates

∙?Program data that is protected by using the CryptProtectData() function

For this reason, it is important to test user migrations. Use your test migration account to identify any properties that did not migrate, and update user configurations in the target domain accordingly.

Complete the following steps to migrate user accounts to the target domain:

1.    Migrate standalone managed service accounts. Standalone managed service accounts must be migrated before computers. Group managed service accounts cannot be migrated. 

2.    Migrate all the user accounts with the account enabled in the source domain, disabled in the target domain, with complex password selected, and with no attributes migrated.

3.    Translate local user profiles for a batch of users.

4.    Migrate workstations in batches that correspond to the user account batches.

5.    Before you migrate the batch of user accounts, verify that local profile and workstation migration succeeded for all users in the batch. Do not migrate any user account for which profile or workstation migration failed. This will result in users overwriting their existing profiles when they log on to the target domain.

6.    Remigrate user accounts in batches with the account set to expire in the source domain in seven days, the target account enabled, with password migration selected, and all attributes migrated.

7.    After each batch, remigrate all global groups to update any group membership changes.

8.    Notify users in the batch to log on to the target domain.

9.    After all users are migrated, run a final global group migration to update any group membership changes.

Migrating user accounts in batches helps you to track the accounts that have been migrated and to test the success of each migration step. If the organizational unit (OU) structure for the target domain is the same as the OU structure for the source domain, migrate groups of users based on OU. If the OU structures are not the same, select an alternative way to group users based on the structure of your organization. For example, you might migrate users by business unit or by floor to enable you to consolidate help desk resources.

If you plan to retain your source domain OU structure, migrate the OUs along with the users that they contain. For example, if your source domain has a functional OU structure, and the target domain does not have an OU structure, migrate OUs from the source domain.

If you created a new OU structure in the target domain, migrate batches of users without the OUs. For example, if your source environment was a Windows NT 4.0 domain that you upgraded to a Windows Server 2003 domain, the source domain might not have an existing OU structure; therefore, you can migrate users without migrating OUs.

For more information about creating an OU structure, see Designing Organizational Units for Delegation of Administration (http://go.microsoft.com/fwlink/?LinkId=76628).

Until you migrate all user and group accounts, continue to administer global group membership in the source domain. To support a rollback strategy, manually synchronize any changes that you make to users in the target domain with the existing user accounts in the source domain. For more information about administering users and groups during the interforest restructure process, see Managing Users, Groups, and User Profiles, earlier in this guide.

If you are migrating OUs when you migrate user accounts, migrate the groups that belong to those OUs to the target domain OU during the user account migration process. When you migrate global groups by using the global group migration process, they are placed in the target OU in the target domain. If you migrate OUs from the source to the target domain, select the option to move the global groups to the target domain at the same time. This way, the groups are moved from the target OU that they were placed in during the initial global group migration to the OU in which they belong.

Using ADMT to migrate user accounts preserves group memberships. Because global groups can contain only members from the domain in which the group is located, when users are migrated to a new domain, the user accounts in the target domain cannot be members of the global groups in the source domain. As part of the migration process, ADMT identifies the global groups in the source domain that the user accounts belong to, and then determines whether the global groups have been migrated. If ADMT identifies global groups in the target domain that the migrated users belonged to in the source domain, the tool adds the users to the appropriate global groups in the target domain.

Using ADMT to migrate user accounts also preserves user passwords. After the user accounts are migrated to and enabled in the target domain, the users can log on to the target domain by using their original passwords. After they log on, the users are prompted to change the password.

If the user account migration process is successful but the password migration process fails, ADMT creates a new complex password for the user account in the target domain. By default, ADMT stores new complex passwords in the C:\Program Files\Active Directory Migration Tool\Logs\Password.txt file.

If you have a Group Policy setting on the target domain that does not allow blank passwords (the Default Domain Policy/Computer Configuration/Security Settings/Account Policies/Password Policy/Minimum password length setting is set to any number other than zero), password migration will fail for any user who has a blank password. ADMT generates a complex password for that user, and writes an error to the error log.

Establish a method for notifying users who have been assigned new passwords. For example, you can create a script to send an e-mail message to users to notify them of their new passwords.

The following illustration shows the steps involved in migrating accounts if you are using SID history for resource access.

Migrating Managed Service Accounts

A standalone managed service account is a domain account object that is available in the Active Directory schema beginning with Windows Server 2008 R2. A standalone managed service account can be installed on computers that run Windows 7 or Windows Server 2008 R2 or later. 

Note 

Group managed service accounts cannot be migrated by using ADMT. 

The process for identifying and migrating managed service accounts using ADMT involves two steps:

1.    Use the Managed Service Account Migration Wizard or admt managedserviceaccount command line tool to migrate managed service account objects to the target domain, as explained in this topic. 

2.    Use the Computer Migration Wizard or admt computer command line tool to migrate the computers that host the managed service accounts. For more information about migrating computers as part of an interforest migration, see Remigrating User Accounts and Migrating Workstations in Batches. For more information about migrating computers as part of an intraforest migration, see Migrate Workstations and Member Servers. 

The managed service accounts that were migrated in the previous step and that were originally installed on the migrated computers are identified during the computer migration. After the computer migration is complete, the managed service accounts are re-installed on the computer in the target domain (unless you request to skip them). If you have run security translation on the member servers that have resources that grant permission to the managed service accounts, the accounts have the same permissions for resource access in the target domain as they had in the source domain.

Important 

If you are migrating managed service accounts between domains within the same forest, run security translation on the member servers in the source domain that have resources that grant permission to the managed service accounts. Security translation is not normally necessary during an intraforest migration because a SID is moved with an account. But managed service accounts that are migrated between domains in the same forest are copied. A new account is created in the target domain and the account properties (excluding SID) are copied from the source domain. Therefore, you need to run security translation. 

If the resources in the source domain that grant permission to a managed service account are hosted on the same computer as the managed service account, then you should select security translation on the appropriate resources (Files and folders, Local groups, and so on) on the Translate Objects page of the Computer Migration Wizard. If the resources are on other computers that are not being migrated, then you need to run the Security Translation Wizard on those computers and on the Security Translation Options page, select Previously migrated objects or explicitly provide the MSA accounts in a SID mapping file. For more information about translation security, see Translating Security on Your Member Servers.

To migrate managed service accounts by using the ADMT snap-in

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 2.    In the ADMT snap-in, click Action, and then click Managed Service Account Migration Wizard. 3.    Complete the Managed Service Account Migration Wizard by using the information in the following table. Wizard page Action Domain Selection Under Source, in the Domain drop-down list, type or select the NetBIOS or Domain Name System (DNS) name of the source domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller. Under Target, in the Domain drop-down list, type or select the NetBIOS or DNS name of the target domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller, and then click Next. Managed Service account Selection Option Click Select managed service accounts from domain to migrate managed service accounts from the domain by using either the object selection dialog box or an include file. This option is best if you want to migrate all managed service accounts from the source domain. Or Click Provide computers to be queried for any installed managed service accounts and then click Next. On the Managed Service Account Selection page, click Add to select the computer accounts in the source domain that you want to query for managed service accounts, click OK, and then click Next. This option is preferred if you want to migrate only managed service accounts that are installed on specific computers. Each computer that you provide may have multiple managed service accounts installed. You can choose a combination of these options by proceeding back and forth within the wizard. For example, you can provide computers to be queried and add the managed service accounts that are installed on those computers to the list of accounts to be migrated. Then you can click Back in the wizard to return to this page and select additional managed service accounts from the domain or from an include file.  Managed Service account Selection Option This page appears only if you select managed service accounts from the domain. Click Select managed service accounts from domain, and then click Next. On the Managed Service Account Selection page, click Add to select the accounts in the source domain that you want to migrate, click OK, and then click Next. Or  Click Read objects from an include file, and then click Next. Type the location of the include file, and then click Next. Organizational Unit Selection Click Browse to specify a location for the migrated accounts and then click Next. Managed Service Account Options Select the Update account rights check box Select the Fix accounts’ group memberships check box If the account is being migrated to a different forest, select the Migrate account SIDs to the target domain check box. This option is not available for an intraforest migration. Click Next. Type the user name, password and domain of an account that has administrative credentials in the source domain, and click Next. Completing the Managed Service Account Migration Wizard Review your selections, and then click Finish. 4.    When the wizard has finished running, click View Log, and then review the migration log for any errors. 5.    Start Active Directory Users and Computers, and then verify that the managed server accounts exist in the appropriate OU in the target domain.

To migrate managed service accounts by using the ADMT command-line option

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 2.    At the command line, type the following command, and then press ENTER:  ADMT MANAGEDSERVICEACCOUNT /N "<managed service account1_name>" "<managed service account2_name>" /IF:NO /SD:"<source_domain>" /TD:"<target_domain>" /UUR:YES /FGM:YES /MSS:YES Where <managed service account1_name> and <managed service account2_name> are the names of managed service accounts in the source domain. As an alternative, you can include parameters in an option file that is specified at the command line as follows: ADMT MANAGEDSERVICEACCOUNT /N "<managed service account1_name>" "<managed service account2_name>" /O:"<option_file>.txt" The following table lists the common parameters that are used for the migrating managed service accounts, along with the command-line parameter and option file equivalents. Values Command-line syntax Option file syntax Interforest migration /IF:No  Intraforest=No <Source domain> /SD:"source_domain" SourceDomain="source_domain" <Target domain> /TD:"target_domain" TargetDomain="target_domain" Update account rights /UUR:Yes UpdateUserRights=Yes Update accounts’ group membership /FGM:Yes FixGroupMembership=Yes Migrate account SIDs Note  You can migrate SIDs for managed service accounts only between forests. An error is returned if you use this parameter during an intraforest migration. /MSS:Yes MigrateSIDs=Yes 3.    Review the results that are displayed on the screen for any errors.

For managed service accounts that are hosted on member computers in the source domain, you can include the member computer when you perform computer migration and the managed service account will be installed on the member computer in the target domain after the computer is migrated. 

Migrating All User Accounts

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Begin the user account migration process by migrating all users. This helps you translate local profiles and ensure that users continue to have the appropriate resource access after the migration.

Note 

Built-in accounts (such as Administrators, Users, and Power Users) cannot be Active Directory Migration Tool (ADMT) migration objects. Because built-in account security identifiers (SIDs) are identical in every domain, migrating these accounts to a target domain results in duplicate SIDs in a single domain. Every SID in a domain must be unique. Well-known accounts (such as Domain Admins and Domain Users) also cannot be ADMT migration objects.

The ADMT user account migration process includes the following steps:

1.    ADMT reads the attributes of the source user objects.

2.    ADMT creates a new user object in the target domain and a new primary SID for the new user account.

3.    ADMT adds the original SID of the user account to the SID history attribute of the new user account.

4.    ADMT migrates the password for the user account.

5.    If ADMT identifies global groups in the target domain that the migrated users belonged to in the source domain, the tool adds the users to the appropriate global groups in the target domain.

During the migration, audit events are logged in both the source and the target domains. ADMT excludes some system attributes by design. For more information see Managing Users, Groups, and User Profiles.

You can migrate user accounts by using the ADMT snap-in, by using the ADMT command-line option, or by using a script. If you are migrating user accounts that have authentication mechanism assurance enabled, use an include file. In the include file, specify the original user principal names (UPNs) from the source domain as the target UPNs so that you can keep the authentication mechanism assurance working. For more information about using an include file, see Use an Include File.

Important 

When you start a user migration with SID history from the command line or from a script, you must perform the migration on a domain controller in the target domain. It is recommended that you use a full version of SQL Server when you install ADMT on a domain controller.

To migrate the current batch of users by using the ADMT snap-in

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 2.    Use the User Account Migration Wizard by performing the steps in the following table. Wizard page Action Domain Selection Under Source, in the Domain drop-down list, type or select the NetBIOS or Domain Name System (DNS) name of the source domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller. Under Target, in the Domain drop-down list, type or select the NetBIOS or DNS name of the target domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller, and then click Next. User Selection Click Select users from domain, and then click Next. On the User Selection page, click Add to select the users in the source domain that you want to migrate in the current batch, click OK, and then click Next. Or  Click Read objects from an include file, and then click Next. Type the location of the include file, and then click Next. Organizational Unit Selection Ensure that ADMT lists the correct target OU. If it is not correct, type the correct OU, or click Browse. In the Browse for Container dialog box, locate the target domain and OU, and then click OK. Password Options Click Do not update passwords for existing users. Click Generate complex passwords. Account Transition Options In Target Account State:, click Disable target accounts. In Source Account Disabling Options:, click Days until source accounts expire:, and then type the numbers of days you want to keep the source account. A value of seven is commonly used. Select the Migrate user SIDs to target domains check box. User Account Type the user name, password, and domain of a user account that has administrative credentials in the source domain. User Options Select the Translate roaming profiles check box. Clear the Update user rights check box. Clear the Migrate associated user groups check box. Select the Fix users’ group memberships check box. Object Property Exclusion Clear the Exclude specific object properties from migration check box. Conflict Management Click Do not migrate source object if a conflict is detected in the target domain. Ensure that the Before merging remove user rights for existing target accounts and Move merged objects to specified target Organizational Unit check boxes are not selected. 3.    When the wizard has finished running, click View Log, and then review the migration log for any errors. 4.    Start Active Directory Users and Computers, and then verify that the user accounts exist in the appropriate OU in the target domain.

To migrate user accounts by using the ADMT command-line option

1.    On a domain controller in the target domain on which ADMT is installed, log on by using the ADMT account migration account. Important  When you start a user migration with SID history from the command line, you must perform the migration on a domain controller in the target domain. 2.    At the command line, type the ADMT User command with the appropriate parameters, and then press ENTER.  ADMT USER /N "<user_name1>" "<user_name2>"  /SD:" <source_domain>" /TD:" <target_domain>" /TO:"<target_OU>" /MSS:YES /TRP:YES /UUR:NO As an alternative, you can include parameters in an option file that is specified at the command line as follows: ADMT USER /N "<user_name1>" "<user_name2>"  /O "<option_file>.txt" The following table lists the common parameters that are used for migrating user accounts, along with the command-line parameter and option file equivalents. Parameters Command-line syntax Option file syntax <Source domain> /SD:"source_domain" SourceDomain="source_domain" <Target domain> /TD:"target_domain" TargetDomain="target_domain" <Target OU> location /TO:"target_OU" TargetOU="target_OU" Migrate SIDs /MSS:YES MigrateSIDs=YES Disable option /DOT:DISABLETARGET DISABLEOPTION=DISABLETARGET Source expiration /SEP:7 SOURCEEXPIRATION=7 Conflict management /CO:IGNORE (default) ConflictOptions=IGNORE Translate roaming profile /TRP:YES (default) TranslateRoamingProfile=YES Update user rights /UUR:NO UpdateUserRights=NO Password options /PO:COMPLEX PasswordOption=COMPLEX 3.    Review the results that are displayed on the screen for any errors. 4.    Open Active Directory Users and Computers and locate the target OU. Verify that the users exist in the target OU.

To migrate user accounts by using a script

∙?Prepare a script that incorporates ADMT commands and options for migrating users by using the following sample script. Copy the script to Notepad, and save the file with a .wsf file name extension in the same folder as the AdmtConstants.vbs file. In your script, specify the source and target container names in the relative canonical format. For example, if the container is a child OU named Sales and its parent OU is named West, specify West/Sales as the container name. For more information, see TemplateScripts.vbs in the ADMT installation folder. <Job id=" MigratingAllUserAccountsBetweenForests" > <Script language="VBScript"  src="AdmtConstants.vbs" /> <Script language="VBScript" >   Option Explicit   Dim objMigration   Dim objUserMigration   '   'Create instance of ADMT migration objects.   '   Set objMigration = CreateObject("ADMT.Migration" )   Set objUserMigration = objMigration.CreateUserMigration   '   'Specify general migration options.   '   objMigration.SourceDomain = "source domain"    objMigration.SourceOu = "source container"    objMigration.TargetDomain = "target domain"    objMigration.TargetOu = "target container"    objMigration.PasswordOption = admtComplexPassword   objMigration.ConflictOptions = admtIgnoreConflicting   '   'Specify user migration specific options.   '   objUserMigration.MigrateSIDs = True   objUserMigration.TranslateRoamingProfile = True   objUserMigration.UpdateUserRights = False   objUserMigration.FixGroupMembership = True   objUserMigration.MigrateServiceAccounts = False   '   'Migrate specified user objects.   '   objUserMigration.Migrate admtData, Array("user name1" , "user name2" )   Set objUserMigration = Nothing   Set objMigration = Nothing </Script> </Job>

Remigrating User Accounts and Migrating Workstations in Batches

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Remigrating user accounts and workstations in batches helps you track the migration process. For each batch of users, first translate local user profiles, and then migrate workstations. Verify that the profile and workstation migration succeeded, and then migrate the user accounts. Remigrate global groups after each batch. For more information, see Remigrating All Global Groups After All Batches Are Migrated, later in this guide.

Translating local user profiles

The Active Directory Migration Tool (ADMT) translates profiles for supported computer migration objects. For a list of which operating systems are supported for computer migration objects for different versions of ADMT, see Active Directory Migration Tool versions and supported environments. 

User profiles are stored locally on the workstation. When a user logs on to another workstation, he or she must create a new, unique local user profile. Translate the local user profiles for the first batch of users immediately after migrating all user accounts.

Local profiles are translated in replace mode because if you perform the profile translation in add mode, certain aspects of software installation that use Group Policy software deployment might not work. Any application that is packaged with Windows Installer version 2.0 (which is included on workstations running Windows 2000 Server Service Pack 3 (SP3) or Service Pack 4 (SP4) and Windows XP Service Pack 1 (SP1) or Service Pack 2 (SP2), as well as in many common software packages) might not function after the profile is translated. For example, the application executable files might not be removed after the last user removed the application. When the ADMT Security Translation Wizard is translating local profiles in replace mode, it reverts to add mode if a profile is locked. This might result in a successful profile translation. However, application installations might not function after the profile is translated.

Note 

The night before you notify the users to log on by using their new accounts in the target domain, translate the local user profiles. Translating profiles the night before ensures that the new user profile reflects the most current user settings.

You can translate local user profiles by using the ADMT snap-in, the ADMT command-line option, or a script.

To translate local user profiles by using the ADMT snap-in

1.    For each workstation in the source domain that you migrate, add the ADMT resource migration account to the local Administrators group. 2.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 3.    Use the Security Translation Wizard by performing the steps in the following table. Wizard page Action Security Translation Options Click Previously migrated objects. Domain Selection Under Source, in the Domain drop-down list, type or select the NetBIOS or Domain Name System (DNS) name of the source domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller. Under Target, in the Domain drop-down list, type or select the NetBIOS or DNS name of the target domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller, and then click Next. Computer Selection Option Click Select computers from domain, and then click Next. On the Computer Selection page, click Add to select the computers in the source domain for which you want to translate security, click OK, and then click Next. Or  Click Read objects from an include file, and then click Next. Type the location of the include file, and then click Next. Translate Objects Click User Profiles. Security Translation Options Click Replace. ADMT Agent Dialog Select Run pre-check and agent operation, and then click Start. 4.    Review the results that are displayed on the screen for any errors. After the wizard completes, click View Migration Log to see the list of computers, completion status, and the path to the log file for each computer. If an error is reported for a computer, you will have to refer to the log file on that computer to review any problems with local groups. The log file for each computer is named MigrationTaskID.log and is stored in the Windows\ADMT\Logs\Agents folder.

To translate local user profiles by using the ADMT command-line option

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT account migration account. 2.    At the command line, type the ADMT Security command with the appropriate parameters, and then press ENTER. ADMT SECURITY /N "<computer_name1>" "<computer_name2>"  /SD:" <source_domain>" /TD:" <target_domain>" /TO:" <target_OU>" /TOT:Replace /TUP:YES As an alternative, you can include parameters in an option file that is specified at the command line as follows: ADMT SECURITY /N "<computer_name1>" "<computer_name2>" /O "<option_file>.txt" The following table lists the common parameters that are used for migrating user accounts, along with the command-line parameter and option file equivalents. Parameters Command-line syntax Option file syntax <Source domain> /SD:"source_domain" SourceDomain="source_domain" <Target domain> /TD:"target_domain" TargetDomain="target_domain" Security translation options  /TOT:REPLACE TranslateOption=REPLACE Modify local user profile security /TUP:YES TranslateUserProfiles=YES 3.    Review the results that are displayed on the screen for any errors. After the wizard completes, click View Migration Log to see the list of computers, completion status, and the path to the log file for each computer. If an error is reported for a computer, you will have to refer to the log file on that computer to review any problems with local groups. The log file for each computer is named MigrationTaskID.log and is stored in the Windows\ADMT\Logs\Agents folder.

To translate local user profiles by using a script

∙?Prepare a script that incorporates ADMT commands and options for translating local user profiles by using the following sample script. Copy the script to Notepad, and save the file with a .wsf file name extension in the same folder as the AdmtConstants.vbs file. <Job id=" TranslatingLocalProfilesBetweenForests" > <Script language="VBScript"  src="AdmtConstants.vbs" /> <Script language="VBScript" >   Option Explicit   Dim objMigration   Dim objSecurityTranslation   '   'Create instance of ADMT migration objects.   '   Set objMigration = CreateObject("ADMT.Migration" )   Set objSecurityTranslation = objMigration.CreateSecurityTranslation   '   'Specify general migration options.   '   objMigration.SourceDomain = "source domain"    objMigration.TargetDomain = "target domain"    objMigration.TargetOu = "Computers"    '   'Specify security translation specific options.   '   objSecurityTranslation.TranslationOption = admtTranslateReplace   objSecurityTranslation.TranslateUserProfiles = True   '   'Perform security translation on specified computer objects.   '   objSecurityTranslation.Translate admtData, _  Array("computer name1" ,"computer name2" )   Set objSecurityTranslation = Nothing   Set objMigration = Nothing </Script> </Job>

Migrating workstations in batches

After you migrate a batch of local user profiles, migrate the corresponding batch of user workstations. When you migrate a workstation between domains, the Security Accounts Manager (SAM) database is migrated along with the computer. Accounts in the local SAM database (such as local groups) that are used to enable access to resources always move with the computer. Therefore, these accounts do not have to be migrated. 

If a workstation has managed service accounts installed and those accounts have been previously migrated, ADMT provides an option to reinstall the migrated managed service account on the migrated computer and update Service Control Manager. So that ADMT can perform this operation, the account performing the computer migration needs permissions to modify the security descriptor of the migrated managed service account.

Note 

Use a low value for the RestartDelay parameter to restart workstations immediately after joining them to the target domain, or as soon as possible thereafter. Resources that are not restarted after migration are in an indeterminate state.

You can migrate workstations and member servers by using the AMDT snap-in, ADMT command-line option, or a script.

To migrate workstations by using the ADMT snap-in

1.    On the computer in the target domain on which you installed ADMT, log on by using the ADMT resource migration account. 2.    Use the Computer Migration Wizard by performing the steps in the following table. Wizard page Action Domain Selection Under Source, in the Domain drop-down list, type or select the NetBIOS or Domain Name System (DNS) name of the source domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller. Under Target, in the Domain drop-down list, type or select the NetBIOS or DNS name of the target domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller, and then click Next. Computer Selection Click Select computers from domain, and then click Next. On the Computer Selection page, click Add to select the computers in the source domain that you want to migrate, click OK, and then click Next. Or  Click Read objects from an include file, and then click Next. Type the location of the include file, and then click Next. Managed Service Account Information (appears if the computer has a managed service account installed) Select any managed service accounts that do not have to be installed on the migrated computer in the target domain, and then click Skip/Include to mark the accounts as Skip. Organizational Unit Selection Click Browse. In the Browse for Container dialog box, locate the target domain Computers container or the appropriate OU, and then click OK. Translate Objects Select the Local groups check box. Select the User rights check box. Security Translation Options Click Add. Computer Options In the Minutes before computer restart after wizard completion box, accept the default value of 5 minutes or type a different value. Object Property Exclusion To exclude certain object properties from the migration, select the Exclude specific object properties from migration check box, select the object properties that you want to exclude and move them to Excluded Properties, and then click Next. Conflict Management Click Do not migrate source object if a conflict is detected in the target domain. ADMT Agent Dialog Select Run pre-check and agent operation, and then click Start. 3.    Review the results that are displayed on the screen for any errors. After the wizard completes, click View Migration Log to see the list of computers, completion status, and the path to the log file for each computer. If an error is reported for a computer, you will have to refer to the log file on that computer to review any problems with local groups. The log file for each computer is named MigrationTaskID.log and is stored in the Windows\ADMT\Logs\Agents folder. 4.    Open Active Directory Users and Computers, and verify that the workstations exist in the appropriate OU in the target domain.

To migrate workstations by using the ADMT command-line option

1.    On the computer in the target domain on which ADMT is installed, log on by using the ADMT resource migration account. 2.    At the command line, type the ADMT Computer command with the appropriate parameters, and then press ENTER. ADMT COMPUTER /N "<computer_name1>" "<computer_name2>" /SD:"<source_domain>" /TD:"<target_domain>" /TO:"<target_OU>" [/M: “<managed service account name1>” “<managed service account name2>”] [/UALLMSA:Yes] /RDL:5 As an alternative, you can include parameters in an option file that is specified at the command line as follows: ADMT COMPUTER /N "<computer_name1>" "<computer_name2>" /O:" <option_file>.txt" The following table lists the common parameters that are used for workstation migration, along with the command-line parameter and option file equivalents. Parameters Command-line syntax Option file syntax <Source domain> /SD:"source_domain" SourceDomain="source_domain" <Source OU> location /SO:"source_OU" SourceOU="source_OU" <Target domain> /TD:"target_domain" TargetDomain="target_domain" Update all managed service accounts /UALLMSA: YES UpdateAllManagedServiceAccounts=Yes