This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Migration Approach Query

Current Environment
Source = Account forest with external forest trust to Target forest.  No Exchange currently (was decommissioned)
Target = Resource forest containing linked mailboxes (Exchange 2010) and disabled AD accounts with AEA (linked master account) set
 
Planned "End State" Environment
Source = Domain/forest will be decommissioned
Target = Previously disabled resource accounts will be enabled and used to authenticate users.  Mailboxes will remain with users.  Users will be provided with new machines which are members of the target domain and login with target accounts using target mailboxes.
 
Planned Migration Steps
1. Perform migration of AD group object using migration sessions and import files
2. Perform migration of AD user objects using migration sessions and import files ensuring accounts are matched to the existing target disabled accounts.  Continue to leave source accounts enabled and target disabled.
*  At this point users are continuing to work as is without any interruption *
3. Perform AD processing of all objects leaving source account permissions in place
4. Perform Exchange processing of all mailboxes leaving source account permissions in place
*  Again, at this point users are continuing to work as is without any interruption *
5. Start migration of Batch 1 of the users
 (a) Enable batch 1 disabled accounts in target using Set-User -Identity 'mailbox name' -LinkedMasterAccount $null  as per KB35991
 (b) Provide batch 1 users with new machine in target domain
 (c) Batch 1 users login to new machine in target domain with target account, create Outlook profile etc
6. Start migration of Batch 2 and repeat previous steps
7. On completion of migration of all batches perform ADPW and EPW to remove source account and clean up
 
I would like to understand if my proposed timing of the ADPW and EPW processing is right and if possible is there any specific pointers around the configuration of the wizards?
 
Thanks  Mark
  • I changed the order slightly and dropped steps not directly related to Quest processed.

    1. Perform migration of AD objects using migration sessions and import files ensuring accounts are matched to the existing target disabled accounts.
    2. Perform migration of AD group object using migration sessions and import files
    3. Enabled Directory Sync with all inscope objects (matched from step 1/2) to maintain target objects and group membership changes during phased migration
    4. Perform AD processing of all objects appending permissions in scope objects.
    5. Perform Exchange processing of all mailboxes appending permissions across all mailboxes and public folders (if they exist)
    6. Start migration of Batch 1 of the users
      1. Execute a Migration Session, enable target users. This will unlink the linked mailbox object, and set it to user mailbox.
        Note: sidhistory should be applied during this Migration session. It is not supported by Exchange for sidhistory to be present while the mailbox is linked.
    7. Start migration of Batch 2
    8. On completion of all migration batches, perform ADPW and EPW to replace all permissions across all in-scope objects, mailboxes and public folders (if they exist)

    Because you are using a phased migration approach, permissions in AD and EX change be changed post step 3/4 and prior to step 7. The "Replace" mode of step 7 combined with sid history address this gap.  

  • Thanks Jeff. I do have a follow up question regarding the source objects if you wouldn't mind reviewing?

    The source user objects have various "legacy" attributes from a previous non qmm migration (native mailbox move) For example the following are present:

    mail
    mailnickname
    msExchMailboxGuid
    Various other msExch* attributes
    proxyAdresses
    targetAddress

    The values in these attributes are no longer relevant and could be incorrect therefore we would like to skip them during the migration sessions.

    We plan to perform the migration over a short period so was planning to just perform migration sessions and not Directory Sync. Changes in the source will be minimal.

    I am aware of two KB articles with attached XML custom add-ins which will skip all attributes. We are considering using these to tightly control which attributes are migrated - Would you consider this to be the best way to prevent the above attributes from synchronising during a migration session?

    I understand some of the attributes are considered "critical" (mail, mailnickname, proxyadresses, targetaddress) and therefore are greyed out in the migration session skip options. Would the XML file still skip these attributes or is there an easier/better way!? If so would the AD version of the XML file be the correct version to use?

    Kind Regards

  • Correct me if I am wrong, but for this migration there is no Exchange migration at all? Of if that is the case, there is no reason for the Exchange parts of the tool to be installed. When not installed, and you do not touch the Exchange tab on the directory sync, that will stop all of the critical Exchange attributes from sync’ing through. Then to be safe, you can use the Skip Attributes UI in the sync settings to skip any other exchnage attributes you are concerned about.

    Skip_all.xml will skip almost everything, where the Skip Attributes UI will let you pick and choose.
  • Hi Jeff, That is correct this is just an AD migration. Mailboxes are already in the target (where they will stay) and linked to the source accounts. The source domain will be decommissioned therefore group/users will be migrated together with LOB apps and file/print.

    If I understand correctly we will still perform AD and EPW processing as you previously described?

    I will remove and reinstall just the AD components.

    Thank You
  • Removing all and reinstalling just the AD bits is more effort then is required. just remove the Exchange bits if they are installed. The mapping data is in the AD LDS data base and stored in the project (upped more node on the left)

    ADPW and EPW are part of the AD bits and license. Exchange bits are only needed if you are migrating Exchange mailboxes and PFs.

     

    If I understand correctly we will still perform AD and EPW processing as you previously described?

    Yes, same process as above. 

  • Thanks for your reply.

    During testing I have noticed that the "LinkedMasterAccount" property of the get-mailbox command of the linked mailboxes is now showing Targetdomain\targetusername following the initial Exchange and AD Processing step. (I have just completed step 5 detailed above)

    Prior to this is was showing sourcedomain\sourceusername as expected due to it being a linked mailbox. Target accounts are still disabled.

    The mailboxes are still showing as linked and appear to be functional. Dual ACL's are present when viewing full mailbox, send as, client permssions etc. SID History has not yet been applied.

    I just want to verify if this is expected behaviour.
  • Yes, That can be a state. IIRC you would have configured ADPW or EPW to not change/update the MSExchMasterAccountSid. So while it works now, any new delegation will have only the Target Sid stamped.

     

    It is step 6 that will unlink the mailbox and set it to a user mailbox

    1. Start migration of Batch 1 of the users
      1. Execute a Migration Session, enable target users. This will unlink the linked mailbox object, and set it to user mailbox.

    Note: sidhistory should be applied during this Migration session. It is not supported by Exchange for sidhistory to be present while the mailbox is linked.

  • Thank you for the update.

    I actually ran ADPW with the default settings. I have reviewed the settings but I cannot see any option which will prevent it from updating the MSExchMasterAccountSid. Do you have any details about which setting I could select?

    If not I guess it would not be an issue if we only have a short migration period and we are aware that new delegations will only have the target sid stamped.

    I did locate an event in the ADPW logs:

    Replace msExchMasterAccountSid value from xxxx to xxxx of "Object DN"