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:
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:
|
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.
|
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.
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.
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':
The upgrade can be done for the time of your migration only.
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.
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.
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.
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.
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.
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
Microsoft Exchange 2010
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.
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:
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.
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:
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center