On Demand Migration for Email Current

On Demand Migration for Email Current - User Guide

Selecting Items to Migrate Filtering Mailbox Folders Migrating Delegate Access Permissions Migrating Folder Permissions Migrating Rules Setting Up Mail Forwarding Managing Google Throttling Updating Outlook Client Profiles Limiting Concurrent Migrations Setting User Notifications

Known Issues and Limitations

Known Limitations

General Client Profile Updating Utility Microsoft Exchange Microsoft 365 POP/Windows Live Hotmail IMAP G Suite Zimbra

Known Issues

Running Migration Migration Concurrency Remigration

Post Migration

Viewing Migration Reports

Executive Summary Report Migration Summary Report Billing Summary Report Migration Details Report Per Mailbox Statistics Report

Notify and Train Users

Third Party Assessments and Certifications Glossary

Preparing Your Source Email Service for Migration

Quest On Demand Migration for Email currently supports migrating content from the following email services:

G Suite

Note: Make sure that the is no limit on the number of messages in an IMAP folder. For that, in Google Settings, click the Forwarding and POP/IMAP tab and check that the Do not limit the number of messages in an IMAP folder (default) option is selected. Otherwise, not all mail items will be migrated.

Connecting to a G Suite source email service from ODME is a two-stage process based on the OAuth 2 protocol. First, users sign in to G Suite directly from ODME with an super administrator account. Once this account has been verified, users then configure API settings in the Google Admin Console to grant ODME web client application access.

For detailed instructions, see G Suite.

Sun ONE/iPlanet

Quest On Demand Migration for Email uses IMAP to migrate messages and folders from your Sun ONE/iPlanet server to an Microsoft 365 server. The migration engine connects to your on-premises or hosted Sun ONE/iPlanet server as the user you provide that can impersonate all the users in your organization using proxy authentication. To do this, the administrator account needs to be a member of the Domain Administrators group.

Sun ONE/iPlanet uses an LDAP directory to hold the user information for the messaging server. Typically, the users for your domain are located in an organizational unit (OU) labeled People and Groups which should be a peer to the People OU. The Domain Administrators group should exist in the Groups OU. Verify that the user that you want to use is listed in the uniqueMember attribute. The value in this attribute will be the distinguished name of the user.

Only email is migrated by On Demand Migration for Email from the Sun ONE/iPlanet Messaging Server. Folder structures are maintained including empty folders. Read and Unread flags for messages are maintained for the migration of each user. Because of throttling of Microsoft 365, only 27 mailboxes can be migrated at a time per each administrative account configured for the Microsoft 365 servers.

Note: The Sun ONE mail server has undergone several brand name changes. It may also be known as the following:

iPlanet Messaging Server
Sun ONE Messaging Server
Sun Java System Messaging Server
Oracle Communications Messaging Exchange Server

Microsoft Exchange 2007/2010/2013/2016/2019

Note: To enable the CPUU integration feature on the source Exchange Server 2007, you should turn on and configure the WebDAV API access for your Exchange Server 2007. For more details, please see Updating Outlook Client Profiles.

Enabling Application Impersonation Rights

To migrate data from Exchange 2007/2010/2013/2016/2019 you need to enable Application Impersonation for the migration administrator account. This allows the migration administrator to impersonate all users on all your client access servers.

There are two separate procedures for enabling Application Impersonation rights. For Exchange 2007, do the following:

Open the Exchange Management Console.
Run the Add-ADPermission cmdlet to add the impersonation permissions on the server for the identified user.

The following example shows you how to set the impersonation permissions on all Client Access servers in an Exchange organization.

Get-ExchangeServer | where {$_.IsClientAccessServer -eq $TRUE} | ForEach-Object {Add-ADPermission -Identity $_.distinguishedname -User (Get-User -Identity User1 | select-object).identity -extendedRight ms-Exch-EPI-Impersonation}

Note: For more information, refer to the instructions provided by Microsoft on https://msdn.microsoft.com/en-us/library/bb204095(v=exchg.80).aspx.

For Exchange 2010/2013/2016/2019, you will use role based access controls, and create a role group that has Application Impersonation rights.
The instructions for Exchange 2010 can be found on https://msdn.microsoft.com/en-us/library/bb204095(v=exchg.140).aspx. For more details about how to configure impersonation in versions of Exchange starting from Exchange 2013, see https://msdn.microsoft.com/en-us/library/office/dn722376(v=exchg.150).aspx.

To create a role group for impersonation, use the PowerShell cmdlets from the articles above. The following is a step by step guide for creating the impersonation role and assigning a user to that role.

Logon to your Exchange server, or to a machine that has the Exchange Administration tools installed on it as an Exchange administrator.
Run Exchange Management Shell.
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

To migrate data from Exchange 2007/2010/2013/2016/2019, 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.

Specifying Administrator Credentials

When specifying the administrator credentials in the Migration settings screen, the Admin value is the account's UPN or Windows domain login (domain\samAccountName). Click https://technet.microsoft.com/en-us/library/cc756018(WS.10).aspx for more information about adding additional domains for UPNs.

It is recommended that you use auto-discovery to obtain the server URL. During a migration, this option uses the specified UPN and password to retrieve the server URL that hosts EWS for the given mailbox. You can also enter the server URL manually.

Note: Your Exchange 2007/2010/2013/2016/2019 server must be configured to support auto-discovery before you can use it to obtain the server URL. Click https://technet.microsoft.com/en-us/library/bb201695(EXCHG.80).aspx for more information on the autodiscover service in Exchange 2007. Click https://technet.microsoft.com/en-us/library/bb201695.aspx for information on Exchange 2010 or https://technet.microsoft.com/en-us/library/bb124251(v=exchg.150).aspx for information on Exchange 2013, 2016, and 2019.

If entering the server URL manually, enter the name of your Exchange 2007/2010/2013/2016/2019 server in SSL format (e.g., exchange.example.com). If your server does not support SSL, enter the fully qualified URL for Exchange Web Services (e.g., http://exchange.example.com/EWS/Exchange.asmx).

Note: If your server does not support SSL, all mailbox data will be transmitted non-encrypted. Use SSL connections if possible to secure your data. ODME supports self-signed SSL certificates. For information on generating a properly formatted self-signed SSL certificate, see

Using Self-Signed SSL Certificates.

Upgrade Throttling Policies (Microsoft Exchange 2010/2013/2016/2019)

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':

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 admin accounts used for your migration.

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

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.