On Demand Migration for Email Current - User Guide

Introduction Preparing Migrations Test and Pilot Migrations Configuring and Running Migrations Post Migration Glossary

G Suite

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

Sun ONE/iPlanet

Quest On Demand Migration for Email uses IMAP to migrate messages and folders from your Sun ONE/iPlanet server to an Office 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 Office 365, only 27 mailboxes can be migrated at a time per each administrative account configured for the Office 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

Novell GroupWise

Novell GroupWise

On Demand Migration for Email supports migrations from Novell GroupWise 7.0.4, 8.0.3, 12.0.2, 2014, 2014 R2 and 18.

 

Note: When preparing your Novell GroupWise source email service, the GroupWise Post Office Agent (POA) should be set to restart automatically.

Create the Trusted Application Key

To migrate data from GroupWise, you need a Trusted Application Key. Options for obtaining this key include:

If your organization is running GroupWise 7, you have to download the generation tool, as your version of Console One does not support creating Trusted API keys. To create a Trusted Application Key in ConsoleOne, complete the following instructions:

  1. Select the GroupWise System node on the left-hand pane of ConsoleOne.
  2. Go to the Tools menu and select GroupWise System Operations |Trusted Applications.
  3. On the Configure Trusted Applications screen, click Create.
  4. On the Edit Trusted Application screen, enter the following information:
    • Name - The application name.
    • Description - An explanation of the application name.
    • Requires SSL - SSL is not required, but it is the recommended encryption protocol so that data transmitted over the internet is protected. Check the Requires SSL box to use SSL.

 

Note: ODME supports self-signed SSL certificates. For information on generating a properly formatted self-signed SSL certificate, see Using Self-Signed SSL Certificates.

  • Location for key file - Path to the destination folder to hold the generated key.
  • Name of key file - The filename of the key file without the directory path.
  1. Click OK.

Note the location of this file as you will use the information later to configure your migration.

Configure SSL and the GroupWise Web Service (SOAP)

GroupWise SOAP provides server-side access to Novell GroupWise data through a protocol. To use ConsoleOne to configure SSL settings for SOAP, please see the following article: How to configure SSL settings for SOAP in GroupWise Mobile server.

 

Note: There is a known bug in GroupWise 7.0.4 that results in (500) Internal Server Errors when trying to access SOAP. Additional information is outlined in Novell forums here. The fix is to install the following update: http://download.novell.com/Download?buildid=hJh0x5bhIIQ.

Configure Cloud Access to the GroupWise Server

To configure Cloud access to the GroupWise Server, complete the following steps:

  1. Open the corporate firewall to allow the SOAP information through.

    To obtain the current Cloud Service IP addresses, open the About box from the ODME home page:

  2. Test the connection to GroupWise and test SOAP with a browser.

If the GroupWise page is displayed, it is working correctly.

Microsoft Exchange 2007/2010/2013/2016/2019

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:

  1. Open the Exchange Management Console.
  2. 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.

  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

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.

Related Documents