Reference Materials for Migration 8.15 - Tips and Tricks

Administrative Accounts

Migration Manager requires administrative access to the source and target domains and Exchange organizations involved in migration. Administrative access is also required to the console machine on which Migration Manager is installed.

When you install Migration Manager, create domain pairs, install synchronization agents, or create synchronization jobs, make sure you specify an administrative account that has the required privileges. The required permissions are listed in the Migration Manager—System Requirements and Access Rights document.

You can create and use different administrative accounts for different components; however, due to Migration Manager’s distributed architecture, the best practice is to create a single administrative account, grant this account all necessary permissions, and use it for all migration activities. This greatly simplifies project management and minimizes the number of issues related to the lack of permissions.

Refer to the Appendices section of the Migration Manager—System Requirements and Access Rights document for the guidelines on creating a single administrative account and granting required permissions.

How Many Projects to Have

Migration Manager allows you to configure a separate directory synchronization job for each pair of source and target domains. With Migration Manager you can also split your source forest or Exchange organization or merge a number of forests or Exchange organizations into one target.

The best practice is to use a single migration project for all your migration activities, for the following reasons:

• Because you can work with only one project at a time from the console, configuring all the domain pairs, synchronization jobs, synchronization agents, and so on is easier if you use a single project.
• The project database is the central storage for the object mapping information that is used during resource processing to translate rights and permissions. Using multiple projects requires you to update resources separately for each project for which you have to update rights, permissions, local group membership, etc.
• You can delegate rights to perform migration tasks (such as configuring domain pairs, migrating accounts, and updating resources) to different persons and migration teams. A single project helps you track who has what rights (roles) in the project more easily. For more information about delegation, refer to the Delegating Migration Activities topic.

Delegating Migration Activities

When you install Migration Manager and create a migration project, the account used to create the project is granted the Full Admin right over the project. This account is then able to delegate certain rights within the project to the other administrators to perform their specific migration tasks.

Using Migration Manager, you can delegate the following migration tasks to the other administrators:

• Account migration
• Resource update

Delegating account migration is useful when you want the actual account migration to be done by the other persons but you do not want these persons to know the administrative credentials to access the source and target domains. You can also limit the scope of the delegated migration to certain OUs in the source and target domains. For more information on delegated migration, refer to the Quest Migration Manager for Active Directory—User Guide.

Delegating resource updating tasks to other administrators is useful when you cannot get administrative access to computers located in remote sites or resource domains. Running resource update locally is also useful if computers to be updated are located across slow WAN connections. In such cases, you can delegate the resource updating tasks to the remote site or to other domain administrators who have the required level of access and are located within an area of good connectivity to the computers to be updated.

When you delegate resource processing, we recommend you use resource processing task setups rather than INI files. Refer to the Step 3. Process Distributed Resources topic for more details.

Testing

It is recommended that you test the migration strategies using an environment that mirrors production as closely as possible. This is critical for testing scalability. After thorough testing, begin the pilot phase and then full deployment.

Creating a Test Environment

Migration strategies and activities should be tested in a lab that closely resembles your current production environment, including resources, servers, applications, legacy design, and bandwidth. So that you can completely run through your migration scenarios, we recommend you create a copy of your live Active Directory and Exchange in the test lab. This can be done by doing any of the following:

• Move one of your live domain controllers into the isolated network that will become your test lab and assign it the PDC-emulator role. You may want to create an additional domain controller in production and then use it for testing purposes in the lab. Note that you will also have to seize all FSMO roles to this domain controller and make it a Global Catalog as well after you moved it into the isolated network.
• Create an image of your live domain controllers and Exchange servers using third-party tools and restore the image to another box with a similar hardware configuration in the lab.
• Export the source Active Directory into a CSV or LDIF file using third-party tools (such as CSVDE, LDIFDE, or LDAPBrowser) and import it into the test environment.
• Restore the directory data from backup into the test environment.

Test the Third-party Applications

All third-party applications running in the source environment (such as ERP systems, fax software, and meta-directory services) must be tested to prove that:

• The applications will function correctly in the target environment if you move the server they are running on to the target domain and re-assign permissions for target user accounts.
• Migrated users will still be able to work with the applications after permissions have been processed for target user accounts.

Depending on the results, you will need to decide whether to move the server running the application to target or to re-deploy the application there. In either case, additional planning is needed.

We recommend you contact each third-party software vendor to verify that they support the migration process or ask them to provide a migration procedure.

Test the Specific Hardware Update Procedures

It is recommended that you test all update procedures for your specific hardware devices (such as Network Attached Storage and Storage Area Network devices) in a test lab prior to starting resource update in the production environment.