In which situation can the Active Directory Processing Wizard be used?
Which domains should be selected and processed when using ADPW?
Active Directory Processing Wizard can be used:
1. To remove the SID history attribute, eg. when cleaning up the environment.
2. In cases when target user is still accessing the source mailbox using SID history, in this situation ADPW (Active Directory Processing Wizard) is executed against the source domain, it will grant permissions to the mailbox for target user.
Often ADPW is executed against the target domain
3. To reassign permissions in AD. For example, a source user has permission set on a specific OU, the user and the OU have been migrated. In this scenario ADPW will grant permissions to this OU in target for migrated target user.
4. In same scenario later ADPW can be used to clean up and remove all source users permissions. If this has not been done then (after the source has been collapsed or trust was broken) there will be many non-resolvable SID's.
5. If a source user has been added to a target group and the user has been migrated, then migrated user will not become a member of the target group. ADPW can resolve this (group membership option).
6. User has been migrated and created as disabled account and mail enabled. This user has an associated external account. Later the user has been enabled and the AEA has been removed, but target user did not automatically get permissions to its own mailbox. This is the most common scenario when ADPW has to be used, in such a scenario the usage of ADPW is almost a must (alternatively the MS tool NoMAS can be sued).
7. Permissions have been granted within Active Directory Users and Computers on the mailbox itself within the source domain. During directory synchronization to the target domain, these permissions are not translated to target permissions, therefore when viewing the rights on the target after the migration, the mailbox rights show as source objects, not target objects. The Active Directory Processing Wizard maybe used against the target domain, to update these permissions to the associated target accounts that were previously migrated. The same can be performed on source domain, changing the source mailbox permissions to target permissions.
Some of the listed below KB articles explain the mentioned scenarios more detailed :
SOL22866 - How to update permissions for migrated accounts on mailboxes? - https://support.quest.com/Search/SolutionDetail.aspx?id=SOL22866
SOL21942 - What is the best practice to perform a clean up after the migration is finished? - https://support.quest.com/Search/SolutionDetail.aspx?id=SOL21942
SOL13035 - Group membership is not automatically populated for target groups - migrated user is not added automatically to existing target group. - https://support.quest.com/Search/SolutionDetail.aspx?id=SOL13035
SOL12898 - When merging a source user with an existing target user and then choosing to UNDO the migration session, the SidHistory attribute is not removed from the target user. - https://support.quest.com/Search/SolutionDetail.aspx?id=SOL12898
SOL22590 - Setting AEA (Associated External Accounts) on the resource Exchange forest when migrating accounts domain. - https://support.quest.com/Search/SolutionDetail.aspx?id=SOL22590
SOL25117 - How can the target users maintain access to their source mailboxes and other user's Outlook folders such as the Calendar? - https://support.quest.com/Search/SolutionDetail.aspx?id=SOL25117
SOL39640 - When merging or replacing security descriptors (AD permissions) during migration session or directory synchronization, are the accounts added from the source or target domain? - https://support.quest.com/Search/SolutionDetail.aspx?id=SOL39640
SOL62760 - SID History attribute and how QMM and AD Processing Wizard are handling this attribute - https://support.quest.com/Search/SolutionDetail.aspx?id=SOL62760
Quest Migration Manager User Guide contains additional information, eg. the following part:
During migration, ACEs of the source security descriptor referencing to the source objects (source SIDs) are not translated to the target objects (target SIDs). To translate or cleanup the source objects' SIDs migrated to the target object's security descriptor use Active Directory Processing Wizard.
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center