Background Information for Restructuring Active Directory Domains Between Forests
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
The migration of domain objects between forests is a nondestructive process. The source and target domain environments exist simultaneously during the migration; therefore, you have the option to roll back to the source environment if necessary. The Active Directory Migration Tool (ADMT) version 2 enables you 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, and users, groups, and resources can be moved independently of each other.
Before you begin to restructure Active Directory domains between forests, you must be familiar with the account and resource migration process, Windows Server 2003 functional levels, and ADMT.
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 can take place between forests or within 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 restructuring 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 security identifiers (SIDs) are identical in every domain and therefore built-in accounts cannot be migration objects.
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 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 need to perform additional tasks to ensure resource access, unless you are using SID filtering between the forests.
If you are using Microsoft® Exchange Server version 5.5, use the ADMT Exchange Server Migration Wizard to translate security on the mailboxes for migrated users. If you are using Exchange 2000 servers, ADMT does not provide tools for mailbox migration. In this case, plan to migrate mailboxes first by using the Exchange 2000 mailbox migration tool and then migrate user accounts.
If you are using Group Policy to manage folder redirection or software distribution, you need to 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, then ADMT cannot determine which remote access to assign to the user.
If you are using Group Policy to manage folder redirection, then 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 containing 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:
Translate security on client computers to update the Offline Files.
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, then 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, then users cannot access the redirected folder because folder redirection will check ownership of the redirected folder and will fail. You must then translate security on the redirected folder on the server.
Because some software installation (.msi) packages require access to the original source for operations such as repair and remove, if you are using Group Policy to manage software installation, then you need to 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 SAM database and are moved when you move the server. You do not have to reconfigure access control lists (ACLs) to enable users to access resources after the migration.
In Active Directory, domain controllers can be migrated between domains. To do this, you must remove Active Directory from the domain controller, migrate it as a member server to the target domain, and then reinstall Active Directory. If you have deployed any domain controllers in the target domain that are running Windows Server 2003, then you can only reinstall Active Directory on the migrated server if the server is running Windows Server 2003 or if the forest and domain are operating at the Windows 2000 functional level.
For more information about functional levels, see "Enabling Advanced Windows Server 2003 Active Directory Features” in this book.
Functional Levels
Functional levels in Windows Server 2003 identify the level of functionality that the domain controllers running different Windows operating system versions of Active Directory can use, such as schema compatibility and replication functionality. The functional level of a domain or forest defines the set of Windows operating systems that can run on the domain controllers in that domain or forest. The functional level of a domain or forest also defines the additional Windows Server 2003 Active Directory features that are available in that domain or forest.
All target domains to which you migrate objects when restructuring Windows Server 2003 domains between forests must be operating at the Windows 2000 native mode or Windows Server 2003 functional level.
Active Directory Migration Tool
ADMT version 2 enables you to copy objects between Active Directory forests. ADMT includes wizards that automate migration tasks such as copying users, groups, service accounts, and computers; migrating trusts; and performing security translation.
When you use the ADMT tool to perform an interforest restructure, ADMT copies the accounts that are migrated, so that when the accounts are created in the target domain, they continue to exist in the source domain. The primary SIDs for the accounts can be migrated to the SID history in the target domain.
ADMT is available on the Windows Server 2003 operating system CD, in the Admigration.msi file in the \i386\admt directory.
You can perform ADMT tasks by using the ADMT console, by using a command-line procedure, or by using a script. When running ADMT from 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 Listing 11.1 to assist you in creating option files.
Listing 11.1 lists all common options that apply to several migration tasks. Each type of migration task has a section listing options specific to that task. The section name corresponds to the task name when executing the ADMT command-line tool. Items can be commented out with a semicolon. In the following list, the default values are commented out.
When running ADMT at the command line, you do not need to include an option in your command if you want to accept the default value. In this chapter, however, tables 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 where you are accepting the default value.
Listing 11.1 ADMT Option File Reference
[Migration]
;TestMigration=No
;IntraForest=No
SourceDomain=" source_domain_name"
;SourceOu=" source_ou_path"
TargetDomain=" target_domain_name"
TargetOu=" target_ou_path"
;RenameOption=Dont
;RenamePrefixOrSuffix=""
;PasswordOption=Complex
;PasswordServer=""
;PasswordFile=""
;ConflictOptions=Ignore
;ConflictPrefixOrSuffix=""
;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"
For a file that contains the ADMT options, see "ADMT Option File Reference" (DSSRENT_3.txt) on the Microsoft® Window® Server 2003 Deployment Kit companion CD (or see "ADMT Option File Reference" on the Web at https://www.microsoft.com/reskit).
When running ADMT at the command line, it is often more efficient to use an include file to list the users, groups, or computers that will be migrated. For example, to migrate a small number of computers, you might type each computer name at the command line, using the /N option as follows:
ADMT COMPUTER /N "computer_name1" "computer_name2" /SD:"source_domain" /TD:"target_domain" /TO:"target_OU"
Computer_name1 and computer_name2 are the names of computers in the source domain that you are migrating in this batch.
If you have a large number of users, groups, or computers to migrate, you can list them in an include file. For example, to create an include file for a batch of computers, create a plain text file and list the computer names, each on a separate line. Then specify the include file name with the /F option, as follows:
ADMT COMPUTER /F "includefile_name" /SD:"source_domain" /TD:"target_domain" /TO:"target_OU"
ADMT supports the use of American National Standards Institute (ANSI) or standard Unicode files for option files and include files.
To specify names of users, groups, or computers, use one of the following conventions:
The SAM account name. Note that to specify a computer name in this format, you must append a $ to the computer name. For example, to specify a computer with the name Workstation01, use Workstation01$.
The Windows NT account name. This includes the domain name and the SAM account name. For example, the Windows NT account name of a computer named Workstation01 that is in the Asia domain is Asia\ Workstation01$.
The relative distinguished name (also known as RDN). For example, cn= Workstation01.
The canonical name. This can be specified as DNS domain name/ou_path/object_name, or ou_path/object_name; for example, Asia.trccorp.treyresearch.net/Computers/ Workstation01 or Computers/Workstation01.
For a complete list of all available ADMT options and syntax, run ADMT and select Help from the menu.
The sample scripts provided in this chapter reference the symbolic constants that are defined in the AdmtConstants.vbs file. Listing 11.2 shows the ADMT constants VBScript file.
Listing 11.2 ADMT Scripting Constants
Option Explicit
'----------------------------------------------------------------------------
' ADMT Scripting Constants
'----------------------------------------------------------------------------
' RenameOption constants
Const admtDoNotRename = 0
Const admtRenameWithPrefix = 1
Const admtRenameWithSuffix = 2
' PasswordOption constants
Const admtPasswordFromName = 0
Const admtComplexPassword = 1
Const admtCopyPassword = 2
' ConflictOptions constants
Const admtIgnoreConflicting = &H0000
Const admtReplaceConflicting = &H0001
Const admtRenameConflictingWithPrefix = &H0002
Const admtRenameConflictingWithSuffix = &H0003
Const admtRemoveExistingUserRights = &H0010
Const admtRemoveExistingMembers = &H0020
Const admtMoveReplacedAccounts = &H0040
' DisableOption constants
Const admtEnableTarget = 0
Const admtDisableSource = 1
Const admtDisableTarget = 2
Const admtTargetSameAsSource = 4
' 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
For a script file that contains the ADMT scripting constants, see "ADMT Scripting Constants" (AdmtConstants.vbs) on the Windows Server 2003 Deployment Kit companion CD (or see "ADMT Scripting Constants" on the Web at https://www.microsoft.com/reskit).