Prior to migrating local and global groups you should use the Group Mapping and Merging Wizard to map source groups to corresponding groups in the destination domain. The Group Mapping and Merging Wizard also enables the merging of group members from multiple groups in the source domain to a group in the destination domain. You can use the Test The Migration Settings And Migrate Later option, which enables you to verify that the group mapping and/or merging will occur successfully once implemented.
The information used by the Group Mapping and Merging Wizard to specify group mapping between the source and destination domains is ignored if the group is migrated to the destination domain. If the group was originally mapped from a group in the source domain to a group in the destination domain, this mapping will be redirected to the group in the destination domain.
Tip
The Default Domain Policy rights assigned to groups in a Windows 2000 source domain are ignored by the migration process.
During the migration process, ADMT handles local groups differently than global groups. When a source domain is using shared local groups to provide access permissions to resources, the Group Account Migration Wizard should be used to migrate the shared local groups to the destination domain.
When migrating local groups to a new domain, if the group members are being migrated as part of the process, the members are automatically added to the new local group in the destination domain. In cases in which the member belongs to a domain that is trusted by the destination and source domains, it is identified by its source domain SID, and when the member already belongs to the destination domain, it is added using its destination domain SID. In cases in which the name of the group member is not in the destination domain, nor in any domain that it trusts, the user name will not be added to the migrated local group as a member.
Migrating groups prior to migrating users from one domain to another is a good idea. Global groups are restricted to having members that exist within the (current) domain. As a result, if you migrate users from a source domain to a destination domain and groups have not yet been migrated, the migrated users cannot be part of a group that is in the source domain. They can be part of a group only in the destination domain; thus, they cannot be part of their original group. Once the groups are migrated, group membership will be restored, yet it leaves a window of opportunity for users to attempt to log on prior to the group membership being reconstructed.
Migrating the global groups from the source domain to the destination domain prior to migrating the users creates the corresponding groups in the destination domain and provides for continuity of group membership throughout the migration process. As in the migration of users, when the groups are migrated to the destination domain, they receive the SID from the new domain, and the SID from the source domain is appended to the SID history for the group.
Tip
Windows 2000 global groups migrate as universal
Migrating global groups from a Windows 2000 Native-mode domain results in those groups being established in the destination domain as universal groups (this is done to support members from the Windows 2000 domain that have yet to be migrated).
To migrate the global group accounts (and optionally the users they contain), run the Group Account Migration Wizard on the Action menu in ADMT.
The migration process for group accounts follows these steps:
Choose whether to migrate or test The Group Account Migration Wizard starts by letting you choose whether you simply want to test the effects of migrating to groups (as ADMT is currently configured). As shown in the screen on the following page, both the Test The Migration Settings And Migrate Later option and the Migrate Now option are available—if you have not yet run a migration test on migrating the global groups, you should do this prior to selecting the Migrate Now option.
Specify source and target domains You are next prompted to specify the source of the migration information (the source domain) and the domain to which you want the information to be transferred (the target domain). The set of recognized domains is available to be selected from the drop-down list, or you can enter the name of the domain to be used in the migration (as shown in the following screen).
Network connectivity between source and destination domains is essential to the migration process. If you enter the name of a domain that ADMT cannot locate, it displays the error message, "The network path was not found (Error code 53), domain =" with the domain name appended to the end of the error message.
When migrating Windows 2000 or Windows Server 2003 groups, verify that you can PING the Domain Name System (DNS) name of the remote domain controller. When migrating Windows NT 4 groups, you can use the NET USE command line to verify connection to the remote primary domain controller (PDC).
Tip
Ensure user account exists in source domain
The user account that is running the migration tool must exist in the source domain and must be a member of the Domain Admins group in the source domain. If you do not have a corresponding user account in the source domain with the correct group membership, you will receive an access denied error.
Choose groups to migrate You must select the groups that you want to migrate from the source domain to your destination domain. Click Add, click Advanced, and then click Find Now to see a list of groups available to be migrated. Select the groups to migrate, and click OK two times for the groups to be added to the Groups Selected list.
Don't include built-in groups, such as Domain Admins or Domain Users, because they can't be migrated. For example, if you select Domain Users as shown in the following screen, it causes a migration error. To remove the group from the list, select it and then click Remove.
Choose target organizational unit Next you are prompted to select the organizational unit (OU) to which you want to migrate the groups (as shown in the screen on the following page). This is a significant decision, because the policies that are applied to this OU are immediately applied to the groups you are migrating.
Although selecting the target OU is an easy thing to do in the dialog box, the decisions behind the selection of the OU to which you migrate these groups require substantial consideration.
Specify group information to migrate The Group Options dialog box (as shown in the following screen) allows you to control a variety of factors about which information is migrated.
Select the Update User Rights option essentially to migrate the assigned user rights in the source domain over to the destination domain (this is the default option for Windows NT 4, but is not selected by default when migrating from Windows 2000).
You can also instruct the wizard to copy over the members of the group (by selecting the Copy Group Members option) at the same time it copies over the group to the destination domain. This option is not selected by default. If not selected, it results in a group created in the destination domain.
If you choose to have the wizard migrate over the users with the group, you also have the option to compare groups in the source and destination domains that have previously been migrated and to update information that has changed since the last migration. To do this, select the Update Previously Migrated Objects option. This is particularly useful in a migration scenario that is being done over an extended period of time because it allows you to migrate the information repeatedly until you're ready to decommission the source domains.
In general, if you're migrating users from one domain to another, you normally want them to be added to any groups in the destination domain to which they belonged in the source domain. To add all migrated users to corresponding groups in the destination domain, select the Fix Membership Of Group option (which is selected by default).
To provide user accounts with the SID history (which provides the users the capability to continue to access resources whose ACLs are dependent upon the SIDs from the previous domain), you must select the Migrate Group SIDs To Target Domain option (which is the default for Windows NT 4 but is not selected by default when migrating from Windows 2000).
In addition, you have the option to determine how the migrated accounts are named. By default, the Do Not Rename Accounts option is selected, and yet if needed, you can specify either a prefix or a suffix to be added to the account names. If a conflict between a migrated account and an existing account occurs, the settings in the Naming Conflicts dialog box determine how the account is named.
To migrate SIDs, the following conditions must exist:
Auditing must be enabled—If auditing is not enabled on the source domain PDC, you are informed of this and are prompted to enable it if you want to be able to migrate SIDs to the destination domain.
A <domain>$$$ group must exist—The logical group <domain>$$$ must exist on the source domain PDC; if it doesn't exist, you are prompted to create it.
A registry key must be added—A registry key called TcpipClientSupport must be implemented on the source domain PDC; if it doesn't exist, you are prompted to create it.
Once you have the wizard set these changes, it prompts you to reboot the source domain PDC to ensure that the changes are implemented.
Provide administrative credentials for migrating SID histories When migrating from a Windows NT 4 source domain, you are prompted to supply the credentials required to migrate the group accounts (the user account must be a member of the Domain Admins group).
Specify object properties to migrate When you are migrating from a Windows 2000 or Windows Server 2003 domain, you can select the properties of the object to include or exclude during the migration (as shown in the following screen). All of the available properties are included by default for each of the objects (group, user, and, in the case of Windows Server 2003, InetOrgPerson).
Specify how naming conflicts are handled You can configure how the wizard handles naming conflicts during the migration (see the following screen). You can select the Ignore Conflicting Accounts And Don't Migrate option to move accounts that do not conflict with an existing account, or you can opt to replace or rename the migrated accounts. If you select the Replace Conflicting Accounts option, you can remove the existing user rights, remove the user accounts from the group, and move the existing accounts to another OU.
Set password migration options The password complexity level specified in the destination domain might exceed the actual password complexity of the user passwords stored in the source domain (especially for Windows NT 4 domains). In the Group Member Password Options dialog box (see the following screen), you can require complex passwords, reset the password to be the same as the user name, or migrate the existing passwords. You can also specify where to store the password file.
Select account transition options Next you must decide how to handle source and destination (target) versions of group accounts in the Group Member Transition Options dialog box (as shown in the following screen).
In the Target Account State section, you can enable or disable target accounts or set the target accounts to mirror the state of the account in the source domain (by default, target accounts are enabled). In the Source Account Disabling Options section, you can choose to disable the source accounts immediately or specify a predefined period of time (in days) to wait before disabling the source accounts. You can also choose to translate roaming profiles of the users in the source domain and migrate the profiles.
After you have selected the group migration options, they are summarized in the Task Description window of the final dialog box before the group migration is performed. Read these items to verify that they reflect what you want to do. For example, the Changes Will Not Be Written line indicates that this migration is running in Test mode and will not actually perform the requested changes.
When you click Finish, a progress dialog box is displayed that allows you to set the refresh rate for displaying the migration progress.
Once the migration has completed, the Progress dialog box displays the summary totals and the View Log button is enabled, allowing you to review the migration log for any errors. When you click View Log, the migration log is displayed in Notepad.
The migration log begins by listing the process configuration information as follows:
2004-08-27 00:02:23 Active Directory Migration Tool, Starting... 2004-08-27 00:02:23 Starting Account Replicator. 2004-08-27 00:02:23 Account MigrationWriteChanges:No NETMAGES CPANDI CopyUsers:Yes CopyGlobalGroups:Yes CopyLocalGroups:Yes CopyComputers:No StrongPwd:All
The migration log continues by listing each group and user processed and reports the results and specifies any errors or warnings. You can use the Notepad search functionality to identify the actions taken for a specific group or user. This information is stored as Migration.log in the Program FilesActive Directory Migration ToolLogs folder.