An import list is a text file listing accounts to be migrated with Migration Manager and the attribute values for each account. If you are going to perform a one-time migration and plan to migrate all users and groups at once, an import list is not necessary. However, import lists should be used when migrating large environments (over 2,500 users). It makes the migration process more manageable, more accurate, and much more efficient. In addition, using import lists can help you easily track migration activities by site, region, location, or any other criteria set up during the planning phase.
You can use import lists to modify target object attributes. To easily create an import list, when creating a new migration session in Migration Manager, use the Import/Export functionality. Migration Manager allows you export information about the accounts from the selected OU and save it in a plain text, tab-delimited format. You also can select what attributes to export. Then you can open the file in Excel, modify the attribute values, and import the list back. The modified attribute values will be applied to the target objects during migration.
Import lists can also be used for account renaming. For example, you may want the names in the target to meet new corporate standards. To assign the target account different name on the fly (this can be a name, or sAMAccountName), you can simply add a new column to the exported list right after the first column and populate it with the new object names (name or sAMAccountName). The new names are applied to the newly-created target objects during migration.
NOTE: Microsoft operates with a virtual attribute 'name,' which is the common name (attribute: cn) for some object classes, such as user, group, and computer. For other object classes, the name may be different. For example, for the organizational unit object class, the virtual attribute 'name' takes the value of the attribute ou.
The following is an example of a file for renaming:
sAMAccountName sAMAccountName description
JSmith JohnSmith Sales_Department
TBroun TomBroun IT_Department
Another approach to account renaming is to determine which names in the source domain are non-standard and change them before migration. To list account names, estimate the number of non-standard names and decide which ones must be changed, you can use the General User Information report in Quest Reporter or export the information from the source domain into a tab-delimited file using third-party tools.
You can also use this method to merge source and target accounts that have different names. To do this, create the import list containing at least two columns, source SAMAccountName and target SAMAccountName, and specify the actual names for the source and target accounts in the columns. Using such an import list in Migration Manager later will cause source and target accounts be matched by their SAMAccountNames and merged.
When you migrate a group from source to target, the target group membership should also be updated. This means that the user and group objects in the target domain corresponding to the user and group objects in the source domain that are members of the source group should also be added to the target group membership list. Since group membership is a list of so-called linked attributes, this process is called link resolving.
Examples of linked attributes are:
Migration Manager resolves links when you migrate or synchronize objects. However, if the objects that should be added to the target group membership (attribute: member) or set as a manager (attribute: manager) for other objects do not exist in the target domain (have not been migrated yet), group membership and manager information will not be updated for such objects. Such objects will be placed into the unresolved links queue. To resolve the links in the future when all group members are migrated to the target, you can either re-migrate and merge groups or run full resynchronization.
To make sure that all the links (group membership, Manager, Managed by, etc.) will be successfully resolved from the beginning without the need to run full resynchronization later, we recommend you migrate group members first and then migrate a group or migrate a group and its members together in the same session.
NOTE: DSA cannot synchronize groups with more than 5000 members. Even if you are using Microsoft Windows Server 2003 Forest mode or higher, as recommended by Microsoft, use primary group membership to ensure correct synchronization of large groups.
If you are running a number of subsequent migrations with ongoing directory synchronization (for example, migrating domain A to domain B and then migrating domain B to domain C), you should use different service attributes for the domain pairs A–B and B-C.
The attributes that can be used as the service attributes must meet the following criteria:
Normally, you can use any extension attributes that are not used by Migration Manager for Exchange and not used to store any other information in the enterprise.