ADMT Guide: Migrating and Restructuring Active Directory Domains
Published: 4-March-2012Author: Sandesh Vidhate
Abstract
This guide explains how we use the Active Directory Migration Tool version 3.1 (ADMT v3.1) or ADMT v 3.2 to migrate users, groups, 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. Also for this activity we required a two way trust between source forest & target forest. After establishing trust we need add Administrator from both domain to each other Domain Admin group.
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 accounts SIDs are identical in every domain. Therefore, built-in accounts cannot be migration objects.
Checklist: Performing an Interforest Migration
Applies to: Active Directory Migration Tool 3.1 (ADMT 3.1) and ADMT 3.2Migrating 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 2008, Windows Server 2003, Windows Vista (without Service Pack 1), Windows XP, and Microsoft Windows 2000 (using ADMT 3.1) to a target domain with domain controllers running Windows Server 2008 R2
or Windows Server 2008, first set the following registry key on the
target domain controllers:NoteThis registry key does not need to be
set to migrate computers that run Windows Server 2008 R2, Windows 7,
or Windows Vista SP1.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 Known Issues for Installing and Removing AD DS (http://go.microsoft.com/fwlink/?LinkId=119321). |
| 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 2008 R2, Windows Server 2008, Windows Server 2003, Windows 7, Windows Vista, or Windows XP. 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 DomainPlanning 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 DomainPlanning 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 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 managed service accounts. | Migrating Accounts While Using SID HistoryMigrating Managed Service AccountsMigrating 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 ServersDecommissioning the Source Domain |
Interforest Active Directory Domain Restructure
Applies to: Active Directory Migration Tool 3.1 (ADMT 3.1) and ADMT 3.2Restructuring 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.
Process for Restructuring Active Directory Domains Between Forests
Applies to: Active Directory Migration Tool 3.1 (ADMT 3.1) and ADMT 3.2Restructuring 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.
Installing ADMT v3.2
ADMT v3.2 requires a preconfigured instance of SQL Server for its underlying data store. You should use SQL Server Express. When you use one of the following versions of SQL Server Express, ADMT installation enforces the following service pack requirements:SQL Server 2005 Express must be installed with Service Pack 3 (SP3) or later.
SQL Server 2008 Express must be installed with Service Pack 1 (SP1) or later.
| Note |
As an option, you can use full versions of SQL Server 2005 or SQL Server 2008. In this case, you can install and run the ADMT console on a remote computer, and you can run multiple ADMT consoles on different remote computers. If you use a full version of SQL Server, ADMT installation does not enforce any service pack requirements.
The rest of this section covers the following installation issues:
Prerequisites for installing ADMT v3.2
Before you install ADMT v3.2, complete the following prerequisite tasks: In Control Panel, use Add or Remove Programs to remove all versions of ADMT earlier than ADMT v3.2.
Although ADMT v3.2 does not support an upgrade from a previous version of ADMT, 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.
Install or upgrade a server computer (preferably a member server) in either your source or target domain environment as necessary to run Windows Server 2008 R2.
Although you can use ADMT v3.2 to migrate accounts and resources from Active Directory environments that have a domain functional level of Windows Server 2003 or later, you can install ADMT v3.2 only on a server running Windows Server 2008 R2.
In addition to running Windows Server 2008 R2, the server computer that you use to install ADMT v3.2 must not be installed under the Server Core installation option or be running as 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.
To install ADMT v3.2
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.
Enabling Migration of Passwords
***Applies to: Active Directory Migration Tool 3.1 (ADMT 3.1) and 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. Both ADMT v3.1 and ADMT v3.2 use Password Export Server (PES) version 3.1. Download PES v3.1 from the Microsoft Download Center. For x86-based computers, see Password Export Server version 3.1 (x86) (http://go.microsoft.com/fwlink/?LinkId=147652). For 64-bit computers, see Password Export Server version 3.1 (x64) (http://go.microsoft.com/fwlink/?LinkId=147653). The PES service can be installed on any writable domain controller in the source domain that supports 128-bit encryption.
| Note |
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 R2 or Windows Server 2008.
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>|*}ADMTKEY Example:admt key /option:create /sourcedomain:sourcedomain.local /keyfile:c: /keypassword:yourpassword
|
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 |
| 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.
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.
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. |
Migrating All User Accounts
Applies to: Active Directory Migration Tool 3.1 (ADMT 3.1) and ADMT 3.2Begin 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 |
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.
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 |
| 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.
4. Start Active Directory Users and Computers, and then verify that the user accounts exist in the appropriate OU in the target domain. |
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 |
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.
4. Open Active Directory Users and Computers, and verify that the workstations exist in the appropriate OU in the target domain. |
No comments:
Post a Comment