立即与支持人员聊天
与支持团队交流

On Demand Migration for Email Current - User Guide

Introduction Preparing Migrations Test and Pilot Migrations Configuring and Running Migrations Post Migration Third Party Assessments and Certifications Glossary

Preparing Your Target Email Service for Migration

Before you do any migrations, you need to configure your target email service.

On Demand Migration for Email currently supports migrating content to the following target email services:

Microsoft 365

Required Permissions

Note: If you use end-user credentials for migration, you do not need to create an administrator account.

If you do not use the Use Modern Authentication option, your administrator account must have an Enterprise Microsoft 365 license and must be assigned to a Role-Based Access Control group that has Application Impersonation rights. By default, the ApplicationImpersonation role is not assigned to this group, which means the first step is to sign in as an organization administrator to the Microsoft 365 portal (http://portal.microsoftonline.com) and add this role to either an existing role group or to a new role group that you create. See Exchange Online documentation for more information on creating role groups and assigning rights.

It is recommended that you create a new role group named "Migration Impersonation" and assign the ApplicationImpersonation role to it.

Role groups are created in the Role Groups page of the Microsoft 365 portal. After logging in, go to the Options menu, select See All Options.... Then from the Options: Manage Myself menu, select My Organization. Lastly, select the Roles & Auditing item and click New.

  • You can use Modern Authentication to connect to Microsoft 365. The Use Modern Authentication option lets you grant consent to ODME instead of providing Administrative credentials with Application Impersonation rights. When the Use Modern Authentication option is enabled, the Forwarding section in a plan’s Options page contains additional fields where you need to specify the credentials of the account which has the permissions to modify forwarding settings. The Use Modern Authentication option is enabled for any newly created plan by default.

    Note: The Use Modern Authentication option is supported for connections to the Microsoft 365 Worldwide. The option is not supported for connections to the Microsoft 365 hosted in the Germany, China or US Government environments (Microsoft 365 GCC High).

    When connecting to your Microsoft 365 server in the Migration Settings screen, it is recommended you select the auto-discovery option, which uses your login credentials to automatically obtain the server name during a migration. You can also enter the name of your Microsoft 365 server manually as it appears in the address bar when you log in as an administrator to your account.

    Note: If using the auto-discovery option, you need to have the proper DNS settings in place. See Exchange Online documentation for more information.

    To perform mail forwarding, the administrator account must be assigned the "Recipient Management" role. See the section Setting Up Mail Routing for more information.

    Provisioning

    Before creating new user accounts on your Microsoft 365 server, consider how these new accounts should be managed in the future and what implications this will have on mail routing. Mail routing is discussed in the Mail Routing section of the help.

    Account that is used to migrate Microsoft 365 F1 users must have Application Impersonation rights. If you have only end-user credentials, Migration of Microsoft 365 F1 users is not supported.

    If you are migrating from on-premises Exchange server, you should consider using the directory synchronization tools that will push your local Active Directory users over to the Microsoft 365 server. For more details about how to convert mail-enabled users created by Microsoft directory synchronization tool to mailbox-enabled users, please see the following article https://msdn.microsoft.com/en-us/library/azure/hh967617.aspx.

    If you are migrating from G Suite, you will need to create users manually using the bulk import in the Administrator control panel or use PowerShell cmdlets, for more help with PowerShell, See Exchange Online documentation.

    Upgrade Throttling Policies

    In order to minimize Microsoft 365 throttling impact to migration and to raise the overall migration throughput, we highly recommend to upgrade your Microsoft 365 tenant throttling policies. Please contact Microsoft support with the request to raise the limits for the following throttling parameters to 'Unlimited':

    • EwsMaxBurst
    • EwsRechargeRate
    • EwsCutoffBalance

    The upgrade can be done for the time of your migration only.

    Disable In-Place Hold and Litigation Hold

    In order to prevent the excessive growth of Recoverable Items folder which can lead to its size quota exceeding and consequent migration stop, we highly recommend to turn off In-Place Hold and Litigation Hold for every migrated mailbox for the time of migration.

    Why do I need to do it?

    If a user who is placed on In-Place Hold or Litigation Hold modifies specific properties of a mailbox item, a copy of the original mailbox item is created before the changed item is written. The original copy is saved in the Recoverable Items folder. This process is known as "copy-on-write" page protection. The "copy-on-write" page protection applies to items residing in any mailbox folder.

    Due to supported mail systems heterogeneity, ODME creates messages in a staged manner to ensure content fidelity. In case of a message with several attachments, the number of stages is not less than a number of attachments. First, the empty message is created, then the attachments are uploaded one by one. For each of this stage or action, the copy of a message is put into the Recoverable Items folder. It leads to excessive growth of the Recoverable Items folder as the automatic purging of this folder is disabled when a mailbox is in the In-Place Hold and Litigation Hold state.

    Please refer to Microsoft KB article for details: https://technet.microsoft.com/en-us/library/ee364755.aspx#hold.

    • Microsoft Exchange 2010/2013/2016/2019

    Enabling Application Impersonation Rights

    To migrate data to Exchange 2010/2013/2016/2019, your administrator accounts must have Application Impersonation rights, which means that the accounts must be assigned to a Role-Based Access Control group that has Application Impersonation rights. Because no groups have Application Impersonation rights by default, you need to add Application Impersonation rights to an existing group or create a new group. You have to do this using the Exchange Management Shell with PowerShell cmdlets. The cmdlets to run can be found at https://msdn.microsoft.com/en-us/library/bb204095(v=exchg.140).aspx.

    To create a role group for impersonation, use the PowerShell cmdlets from the article above.To create the Impersonation role and assigning a user to that role, use the following procedure.

    1. Logon to your Exchange server, or to a machine that has the Exchange Administration tools installed on it as an Exchange administrator.
    2. Run Exchange Management Shell.
    3. Run the cmdlet to create the management role group and assign the ApplicationImpersonation role to that group, and then assign the user you want to use as a migration administrator.

    In the following example, we are using the user migAdmin@example.com.

    New-RoleGroup -Name MigrationImpersonation -Roles ApplicationImpersonation -Members migAdmin@example.com

    You can add multiple users using commas to separate each user.

    Accessing the Mail Server

    Make sure that Outlook Web Access (OWA) is accessible from the internet. Quest On Demand Migration for Email uses Exchange Web Services (EWS) to access your mail server from the internet. The OWA server name can be used for accessing your Exchange server with EWS. If you are not using HTTPS for OWA, you will need to enter the full URL for your EWS service which follows the format http://servername/EWS/Exchange.asmx.

    You can find the URL for your EWS server using PowerShell. From the Exchange Management Shell, execute the following command:

    Get-WebServicesVirtualDirectory | Select name, *url* | fl

    The EWS server URL will be returned in the ExternalUrl value. To access the mailboxes slated for migration, the migrator needs to have an account with the ApplicationImpersonation role.

    Provisioning

    Before creating new user accounts on your on-premises Exchange 2010/2013/2016/2019 server, consider how these new accounts should be managed in the future and what implications this will have on mail routing. Mail routing is discussed in the Mail Routing section of the help.

    If you are migrating from an on-premises Exchange server, go to the Microsoft TechNet library located on https://technet.microsoft.com/en-us/library/aa995902.aspx and follow the upgrade instructions specific your version of Exchange under the "Planning and Deployment" section.

    If you are migrating from G Suite, you must create users manually either by using the bulk import in the Exchange Management Console or by using PowerShell cmdlets. For more help with bulk account creation, see the instructions for importing CSV files on https://technet.microsoft.com/en-us/library/dd347665.aspx, and how to add mailboxes on https://technet.microsoft.com/en-us/library/aa997663.aspx. To see how PowerShell cmdlets work together, go to https://social.technet.microsoft.com/Forums/exchange/en-US/480078a8-e017-44d1-8ce5-13c87e0a660b/exchange-2010-importcsv-to-create-new-users-and-include-their-passwords?forum=exchange2010.

    Upgrade Throttling Policies

    In order to minimize Exchange throttling impact to migration and to raise the overall migration throughput, we highly recommend to upgrade your throttling policies. Please raise the limits for the following throttling parameters to 'Unlimited' or to the highest possible values:

    Microsoft Exchange 2013/2016/2019

    • EwsMaxConcurrency
    • EwsMaxBurst
    • EwsRechargeRate
    • EwsCutoffBalance

    Microsoft Exchange 2010

    • EWSPercentTimeInMailboxRPC
    • EWSPercentTimeInCAS
    • EWSPercentTimeInAD

    We recommend to create a custom throttling policy and assign it to all the administrator accounts used for your migration.

    The upgrade can be done for the time of your migration only.

    Disable In-Place Hold and Litigation Hold

    In order to prevent the excessive growth of Recoverable Items folder which can lead to its size quota exceeding and consequent migration stop, we highly recommend to turn off In-Place Hold (not applicable to Exchange 2010) and Litigation Hold for every migrated mailbox for the time of migration.

    Why do I need to do it?

    If a user who is placed on In-Place Hold or Litigation Hold modifies specific properties of a mailbox item, a copy of the original mailbox item is created before the changed item is written. The original copy is saved in the Recoverable Items folder. This process is known as "copy-on-write" page protection. The "copy-on-write" page protection applies to items residing in any mailbox folder.

    Due to heterogeneity of mail systems, ODME creates messages in a staged manner to ensure content fidelity. In case of a message with several attachments, the number of stages is not less than a number of attachments. First, the empty message is created, then the attachments are uploaded one by one. For each of this stage or action, the copy of a message is put into the Recoverable Items folder. It leads to the excessive growth of the Recoverable Items folder as the automatic purging of this folder is disabled when a mailbox is in the In-Place Hold and Litigation Hold state.

    Please refer to the following Microsoft KB articles:

    Test and Pilot Migrations

    Any full scale migration should be preceded by test and pilot migrations, to confirm that your migration processes and procedures will accommodate the organization requirements.

    • A test migration uses real users and real data in a segregated test environment, or dummy users and dummy data in your live production environment.
    • A pilot migration uses a small portion of real users and real data in the live production environment.

    In either case - a test or pilot migration - the data to be migrated should be a representative sample of the production data, and the test or pilot migration should be run with the Quest applications set for the same configuration and process options that you intend to use for the production migration. it is recommended to select test or pilot users whose usage and data types make them representative of the total user population. Then run the migration for those users, just as you have defined the process in your migration planning. When the migration is completed, review application log file for errors and warnings, if any. See Viewing Migration Reports section for more information.

    Quest recommends that you use both test and pilot migrations:

    1. Perform one or more test migrations in a separate test environment, migrating test copies of real users and their real data. The separate test environment ensures that no test process will affect the data or configurations of your production environment. If a test exposes any problems under migration, you can make amendments and then repeat the test by simply dumping the test environment and recreating it from scratch.
    2. When you are confident that your test migrations have sufficiently refined your planned migration, perform a pilot migration for 20 or 30 users to verify if your planned migration is satisfactory for your "real world."

     

    相关文档

    The document was helpful.

    选择评级

    I easily found the information I needed.

    选择评级