Delegating Migration Tasks
Migration Manager allows administrators to delegate specific tasks to trusted persons responsible for particular stages of migration. For example, you can delegate the rights to manage the migration within a specified pair of domains to the administrators of those domains, or you can delegate the rights to process a specific server to the server administrator.
The trusted person will have the appropriate access to the objects that he or she is granted rights to only and will not have the opportunity to perform any actions with other objects.
The delegation is performed by assigning a role that defines a level of permissions to a person within a migration project. Only accounts that have Full Admin role over an object can delegate the rights over that object to another account.
Table 1. Roles that can be assigned to a trusted person within a migration project.
| Tree Node Object | Available Roles |
|---|---|
| Migration project |
Full Admin—Can create and configure any objects (domain pairs, directory synchronization jobs, migration sessions, delegated migrations, resource processing tasks, etc.) and perform any task within the project. Reader—Can view objects within the project and their settings, except domain pairs and Exchange stores in the synchronization settings, but cannot perform any migration tasks or change the configuration. |
| Directory migration |
Domain Pair Creator—Can create domain pairs. This person automatically gets the Full Admin role over the domain pairs he or she creates and therefore is able to change settings of the domain pairs later. |
| Domain pair |
Full Admin—Can change any settings on a domain pair (such as credentials used to connect to each domain), and can also configure the directory synchronization between the domains, create and run migration sessions, and delegate the migration to other trusted persons. Reader—Cannot view or change settings of the domain pair, and cannot perform any migration tasks. |
| Delegated migration | Migration Admin—Can run migration sessions within the delegated migration job. This person can migrate objects from and to only those containers specified in the delegated migration job. He or she cannot see the credentials used to connect to the source and target domain or change the object processing custom add-in or the migration agent, but can see which custom add-in and agent are used. |
| Tasks | Task Creator—Can create resource processing tasks. This person is automatically assigned Full Admin role to the tasks he or she creates and therefore can change the task settings later and run the task. |
| Resource processing task | Resource Admin—Can run the resource processing task and change its settings. However, this person cannot change the re-permissioning options or perform undo or cleanup. |
|
|
NOTE: Only a domain pair’s Full Admins are granted access to the domain pair’s sub-nodes (synchronization, migration, and other manually created delegated migration jobs) and migration sessions. |
To delegate the rights to perform a migration task:
- In Migration Manager, right-click the tree node object and select Delegate on the shortcut menu.
- Specify the account to which you want to delegate the task.
- Select the level of permissions for that account from the Role list.
- Click Add Account. This will add the account to the Delegated accounts list.
- Click OK.
To revoke permissions, complete the following steps:
- In Migration Manager, right-click the tree node object and select Delegate on the shortcut menu.
- In the Delegated accounts list, select the account you want to revoke the rights from and click Revoke.
NOTE: Refer to the Delegating Account Migration topic of this guide for more details about delegating account migration tasks.
- Click OK.
Pre-migration Activities
Before you start directory migration, analyze the existing directory. This includes identifying required hardware and software upgrades, possible naming conflicts in the case of directory merges, and for an inter-forest migration, comparing and unifying the source and target forest schemas. You can use Quest Reporter to obtain detailed information about the existing Active Directory configuration, hardware and software inventory, etc.
You can optionally set up the target Active Directory forest, administrative accounts, and organizational units before migration. For more information about environment preparation, refer to the Migration Manager Installation Guide.
|
|
NOTE: The RC4 encryption (Rivest Cipher 4 or RC4-HMAC) is an element of Microsoft Kerberos authentication that Quest migration products require to sync Active Directory passwords between Source and Target environments. Disabling the use of the RC4 protocol enabled makes password syncing between environments impossible. Beginning on November 8, 2022 Microsoft recommended an out of band (OOB) patch be employed to set AES as the default encryption type. The enabling and disabling use of the RC4 encryption protocol has potential impact beyond the function of password syncing of Quest migration tooling and should be considered carefully. |
Exchange Migration Considerations
The following information is relevant to migration projects that involve both Active Directory and Exchange migration. Due to the tight integration of Exchange and Active Directory, some Exchange-specific decisions need to be made before even starting Active Directory migration.
There are four choices regarding the kind of users that will exist in the target domain after Active Directory migration:
- Users without mail options
- Mail-enabled users
- Mail-enabled users for Native Move
- Mailbox-enabled users
For Exchange migration, you need to have mail-enabled users, mail-enabled users for Native Move or mailbox-enabled users. For a smooth Exchange migration experience down the road, decide in advance which option will work for you. This choice is important for selecting the mailbox migration method.
Mail-enabled users are required if there are plans to include the users in the GAL without performing fully-fledged Exchange migration for them
Mail-enabled users for Native Move are required if you are plan to move mailboxes using the Native Move job.
Mailbox-enabled users are required if there are plans to:
- Move mailboxes using the Mailbox Synchronization job
- Move mailboxes using the Legacy Mailbox Synchronization job
- Set up calendar coexistence (with or without mailbox migration) using Calendar Synchronization jobs
- Set up calendar coexistence (with or without mailbox migration) using Legacy Calendar Synchronization jobs
To make an informed decision, discuss this with your Exchange migration operator. For details and guidelines, refer to the Mailbox Migration Process topic in the Migration Manager for Exchange User Guide.
The relevant Exchange options are specified during Active Directory Synchronization configuration. For details, see the Step 5: Specify Exchange Optionssection of the Configuring the Synchronization Job topic.
Domain Pairs
All migration activities are performed between source and target domain pairs. You should configure the pairs of source and target domains that will be involved in the migration and directory synchronization processes. The subsequent sections discuss how to create and configure the domain pairs: