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.
|
Caution: This powerful account must be maintained closely and should be deleted after the project is complete. It is recommended that this account be owned by one individual and one backup individual (or as few individuals as possible.) |
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.
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:
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:
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.
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:
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:
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.
© ALL RIGHTS RESERVED. Nutzungsbedingungen Datenschutz Cookie Preference Center