In a project where user accounts are migrated first, target users will need access to their source mailboxes in the same way it was setup on the source. That way no business processes in organization are interrupted during the migration. For example Administrative assistants will still need access to resource mailboxes to administer meeting requests or access to individuals Outlook Calendars to manage appointments. How can this be provisioned for the target migrated users?
Please refer to the resolution section for detailed explanation.
There could be two possible scenarios:
SCENARIO 1
Relying on SID History attribute of migrated users.
If users are migrated with SID History then target users will have source users SID associated with them. It will allow working under the same security context in the source domain provided that SID filtering is disabled like described in Quest KB 14246 - https://support.quest.com/SUPPORT/index?page=solution&id=SOL14246
Target users will be able to access their source mailboxes as well as all the other Outlook resources like other peoples Calendars or any other Outlook folders, additional mailboxes configured to be opened on their MAPI profiles.
SCENARIO 2
Setting target accounts as Associated External Accounts (AEA) on the source disabled accounts.
This can be done as follows per SOL22253:
"Source accounts are getting disabled upon migration. Target accounts need to access source mailboxes. Under this scenario Migration session needs to be performed with the option "Enable Target Accounts" and "Disable Source Accounts". This will automatically set Associated External Account (msExchMasterAccountSID) attribute on every disabled account on the source to correspond to the matching target account."
It will provide access to users own source mailboxes only. In order for target users to receive exactly the same level of access the source users had, including being able to open other user's mailbox Calendars and folders, the following needs to be done:
- Run ADPW (Active Directory Processing Wizard) with ONLY the Process Exchange 2000 directory permissions against SOURCE domain to update directory permissions.
- Run Exchange 2000 Processing Wizard in order to provide access to other users mailbox folders, such as shared Calendars (for example where access to other users was set in Outlook on the folder properties| Permissions TAB).
IMPORTANT:
1. Running Exchange 2000 Processing Wizard to update MAPI permissions on the source Exchange side while some migrated source accounts are still enabled and AEA is not set will cause “corruption” of MAPI permissions. NT USER: TARGET\User_T will show up on the MAPI level Permissions dialog for every corresponding User_S from the source. Any further modifications to the permissions in Outlook will give an error: “The modified permissions could not be saved. The client operation failed.” (For example this can occur if all users were synchronized first, then migration session performed for just subset of users disabling their source accounts properly and setting AEA to the target users. Running the Exchange Processing Wizard (EPW) in such scenario would also update Exchange permissions corresponding to the source enabled accounts with no AEA set, making Exchange unable to resolve such SIDs to the source user and showing NT USER: TARGET\User_T instead). The following Microsoft article describes how to fix this problem (323611): - http://support.microsoft.com/kb/323611/en-us
Therefore if the EPW mapping file contains more than just migrated users with their source accounts properly disabled and AEA set, Exchange 2000 Processing Wizard needs to be run every time the next bunch of users were migrated with the appropriate user selection that limits the processing scope. All Objects need to be selected under "Select Objects TAB" on Exchange 2000 Processing Wizard Properties and only migrated users under “Select Objects to process Resources” on the saved processing task configuration (also known as Custom Map). This will make EPW to process permissions for ALL Exchange resources but only replace SIDs corresponding to the user pairs defined by Custom Map (users with AEA set properly).
2. Running EPW here is critical for MAPI permissions to be synchronized properly by QMM mail sync agents. After user is disabled his Exchange permissions are reflected as NT User: Domain\UserSID. Such users cannot be matched by QMM (Quest Migration Manager) for Exchange permissions sync logic and therefore skipped. This Microsoft KB article has very good explanation of why Exchange Information store treats disabled users permissions in such away: - XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts - http://support.microsoft.com/kb/316047
Disabled account permissions are calculated by using the msExchMasterAccountSID value, instead of the actual SID value of the placeholder account.
So disabled AD account scenario is considered by MS Exchange as a case where Foreign Security Principal (FSP) now becomes mailbox owner, and correspondingly when calculating and displaying permissions, Exchange can no longer resolve to the disabled account itself. However running EPW updates MAPI permissions properly to the target SID which is then properly resolved by Exchange because this SID is also reflected as AEA. After that QMM mail sync agents have no problems synchronizing MAPI permissions inside such mailboxes.
Please also read the following Quest KB 22253 when considering setting AEA (Associated External Accounts) on source disabled users: - https://support.quest.com/SUPPORT/index?page=solution&id=SOL22253
