Quest OnDemand Migration for Email 1.3.0 User Guide
2012 Quest Software, Inc. ALL RIGHTS RESERVED. This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser's personal use without the written permission of Quest Software, Inc. The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document. If you have any questions regarding your potential use of this material, contact: Quest Software World Headquarters LEGAL Dept 5 Polaris Way Aliso Viejo, CA 92656 email: legal@quest.com Refer to our web site (www.quest.com) for regional and international office information. Trademarks Quest, Quest Software, the Quest Software logo, Simplicity at Work, and Quest OnDemand Migration for Email are trademarks and registered trademarks of Quest Software, Inc. For a complete list of Quest Software's trademarks, see http://www.quest.com/legal/trademarks.aspx. Other trademarks are property of their respective owners.
Table of Contents Preface...vii About This Guide... viii About Quest Software, Inc.... viii Contact Quest Software... viii Contact Quest Support...ix Introduction...11 Welcome... 12 Overview of The Migration Process... 12 Preparing a Migration... 14 Configuring and Running a Migration... 14 Post Migration... 15 Preparing for a Migration...11 Plan Your Migration... 12 Choose a Migration Type... 12 Mail Routing... 12 Deciding How to Configure Your Shared Address Space... 12 Source Email Service... 13 Initial Target Mail Hosts... 18 Create Target Mailboxes... 19 Prepare Your Source Email Service for Migration... 20 Google Apps... 20 Sun ONE/iPlanet... 20 Novell GroupWise... 21 Microsoft Exchange 2000/2003... 22 Microsoft Exchange 2007/2010... 23
iv Quest OnDemand Migration for Email 1.3.0 User Guide Microsoft BPOS... 25 Microsoft Live@edu... 26 Microsoft Office 365... 27 Prepare Your Target Email Service for Migration... 28 Microsoft Office 365... 28 Microsoft Exchange 2010... 29 Microsoft Live@edu... 30 Configuring and Running Migrations... 33 Creating a Migration Plan... 34 Migration Dashboard... 34 Copying Migration Plans... 34 Connecting to Email Services... 36 Connecting to the Source Email Service... 36 Google Apps... 37 Sun ONE/iPlanet... 37 Novell GroupWise... 37 Microsoft Exchange 2000/2003... 38 Microsoft Exchange 2007/2010... 38 Microsoft BPOS... 39 Microsoft Live@edu... 40 Microsoft Office 365... 40 Connecting to the Target Email Service... 41 Microsoft Office 365... 41 Microsoft Exchange 2010... 42 Microsoft Live@edu... 42 Validating Connections... 43 Google Apps... 43 Sun ONE/iPlanet... 44 Novell GroupWise... 45 Microsoft Exchange 2000/2003... 46 Microsoft Exchange 2007/2010... 47 Microsoft Live@Edu... 49 Microsoft Office 365... 49 Importing Mailboxes... 50
Table of Contents v Selecting Migration Options...51 Known Limitations...53 General...53 GroupWise...53 Office 365...53 Migrating...53 Running a Migration...54 Post Migration...55 Viewing Migration Reports...56 Notify and Train Users...56 Glossary...57 Index...59
vi Quest OnDemand Migration for Email 1.3.0 User Guide
Preface Contents About This Guide About Quest Software, Inc. Contact Quest Software Contact Quest Support
viii Quest OnDemand Migration for Email 1.3.0 User Guide About This Guide This guide provides detailed instructions on using Quest OnDemand Migration for Email to migrate mailbox items from one email service to another. It also addresses migration-related topics such as provisioning and mail routing. This guide is available online and as a downloadable pdf at http://documents.quest.com/productsaz.aspx. This site provides robust search capabilities that allow you to search across all related documents, including release notes (also available at: http://support.quest.com). About Quest Software, Inc. Established in 1987, Quest Software (Nasdaq: QSFT) provides simple and innovative IT management solutions that enable more than 100,000 global customers to save time and money across physical and virtual environments. Quest products solve complex IT challenges ranging from database management, data protection, identity and access management, monitoring, user workspace management to Windows management. For more information, visit www.quest.com. Contact Quest Software Phone Email Mail Web site 949.754.8000 (United States and Canada) info@quest.com Quest Software, Inc. World Headquarters 5 Polaris Way Aliso Viejo, CA 92656 USA www.quest.com Please refer to our web site for regional and international office information.
Preface ix Contact Quest Support Quest Support is available to customers who have a trial version of a Quest product or who have purchased a Quest product and have a valid maintenance contract. Quest Support provides unlimited 24x7 access to SupportLink, our self-service portal. Visit SupportLink at http://support.quest.com. From SupportLink, you can do the following: Retrieve thousands of solutions from our online Knowledgebase Download the latest releases and service packs Create, update and review Support cases View the Global Support Guide for a detailed explanation of support programs, online services, contact information, and policy and procedures. The guide is available at http:/ /support.quest.com/pdfs/global Support Guide.pdf.
x Quest OnDemand Migration for Email 1.3.0 User Guide
Introduction Contents Welcome Overview of The Migration Process
12 Quest OnDemand Migration for Email 1.3.0 User Guide Welcome OnDemand Migration for Email (ODME) securely migrates data to Office 365, Live@edu, on-premises Exchange or hosted Exchange email platforms without requiring organizations to install or maintain any software for the move. From a single console, you can migrate multiple mailboxes simultaneously, including data such as email, calendar, contacts, and tasks. Overview of The Migration Process This chapter is designed to give new OnDemand Migration for Email users an overview of each step in the migration process, which can be divided into three general stages: 1 Preparing a Migration These steps are performed before logging in to OnDemand Migration for Email and include preparing your source and target email services for a migration. 2 Configuring and Running a Migration These steps involve connecting to your source and target email services, importing mailboxes, selecting which items to migrate, and then running a migration. 3 Post-Migration These steps are optional and are performed after a migration. They include viewing reports and training users on the new mail system.
Introduction 13 The illustration below shows the stages of the migration process and the order in which each step should be performed.
14 Quest OnDemand Migration for Email 1.3.0 User Guide Preparing a Migration Before running a migration with OnDemand Migration for Email, you should consider carefully which migration strategy best suits your needs. Then, if you haven t already done so, you should create the target mailboxes in the target email service and (optionally) implement a mail routing strategy. Lastly, you should configure your source and target email service to ensure that OnDemand Migration for Email can connect to each one and execute a migration. 1 Choose a Migration Strategy Depending on various factors, you can choose to perform either a one-time, big bang migration (cutover) or perform several staged migrations (co-existence). Choosing the right strategy will minimize migration errors and make it easier for users to transition into the new mail system. 2 Create Target Mailboxes Create the target mailboxes in the target email service. OnDemand Migration for Email does not create them for you. 3 Setup Mail Routing Implement a mail routing strategy that will enable users to send and receive mail from both internal and external sources. 4 Prepare the Source and Target Email Service Configure your source and target email services to allow OnDemand Migration for Email to connect to them and run a migration. Configuring and Running a Migration After you have performed all the necessary preparatory steps, you are ready to login to OnDemand Migration for Email and setup and run your migration. 1 Name the Migration Plan Assign a name to the migrations plan under which you will configure and run the migration. 2 Connect to the Source and Target Email Service Specify server locations and the administrator account credentials for both your source and target email services. 3 Import Mailboxes Upload a list of all the mailboxes to be migrated. 4 Select Mailbox Items and Migration Filters Specify which mailbox items you want to migrate and (optionally) any filter parameters. 5 Migrate Initiate your migration and monitor it in the cloud.
Introduction 15 Post Migration After you run a migration, there remain additional activities you may perform. 1 Review Migration Reports Review and correct any errors identified in the migration reports and re-migrate as needed. 2 Notify and Train Users Notify users of the migration and provide information on how to access the new mail system. This step may include training users on the new system as needed.
16 Quest OnDemand Migration for Email 1.3.0 User Guide
Preparing for a Migration Contents Plan Your Migration Create Target Mailboxes Prepare Your Source Email Service for Migration Prepare Your Target Email Service for Migration
12 Quest OnDemand Migration for Email 1.3.0 User Guide Plan Your Migration To ensure your migration runs as smoothly as possible, you should first decide the type of migration you want to perform and then decide which mail routing strategy to implement. Choose a Migration Type You can perform either a one-time, big bang migration (cutover) OR several staged groups (co-existence). You may want to choose a cutover approach if you have a small number of users and you want to move everyone all at once to reduce the amount of administrative overhead. If your users are very savvy and won t require a lot of training on the new target domain client, this is also a good option. Inform users that they may not have all their old email right away. A staged migration with co-existence is a good option if you need to train your users on the new mail system. This minimizes the number of users calling the helpdesk. It also allows you to schedule training sessions and migrations together, managing expectations for both your IT staff and your end-users. Mail Routing Before migrating or creating mailboxes, you need to implement a mail routing strategy that will enable users to send and receive mail from both internal and external sources. There are different strategies to do this depending on how you want mail directed to and from the internet. Note This task can be performed before or after you migrate. Deciding How to Configure Your Shared Address Space During the co-existence period of on-premises mail and hosted mail, you need to decide which system will initially receive the email traffic for your organization. To make the best decision for your organization, please review the Microsoft documentation associated with your target email service: For Exchange 2010, click here. For Live@edu, click here. For Office 365, click here.
Preparing for a Migration 13 Source Email Service Refer to the sections below for mail routing instructions specific to your source email service. Exchange 2000/2003 Exchange 2007/2010 Google Apps Office 365 (Cloud Relay) BPOS (Cloud Relay) Note For information on setting up mail routing for Live@edu, Sun ONE/iPlanet, or Novell GroupWise source email services, refer to documentation provided by those products. Exchange 2000/2003 When migrating from on-premises Exchange you can't use the Microsoft directory synchronization solution. If you have used the MS directory synchronization, it is not possible to mailbox-enable the users that it has created in Office 365. The Microsoft directory synchronization also limits you to using the Microsoft migration tools. If you need a directory synchronization solution, please see Quest One Quick Connect for Cloud Services. Your DNS MX records will already be set to deliver mail to your Exchange server. For Exchange to forward mail, you need to set the targetaddress for the mailboxes that now reside on your new mail system to a subdomain that exists, and configure Exchange to route to target mail system. To set forwarding so that email from an existing Exchange user is routed to the Exchange user that has been migrated to the target system, make sure the Active Directory object has the attribute targetaddress set to the appropriate value. This value needs to be in the form of TargetUsername@ForwardingSubDomain where: TargetUsername is the user's Target userid. ForwardingSubDomain is a secondary domain that you have set up in the Target system. For your Exchange 2000/2003 server to route mail to your new mail system, you need to create a send connector that routes mail bound for the forwarding subdomain. To do this create a send connector using Exchange System Manager. To create and configure
14 Quest OnDemand Migration for Email 1.3.0 User Guide the send connector, also known as an SMTP connector, follow these steps (from http:// support.microsoft.com/kb/265293): 1 Start Exchange System Manager. 2 Expand the Administrative Groups container. 3 Click the administrative group that you want to work with, and then expand it. 4 Expand the Routing Groups container. 5 Click the routing group that you want to work with, and then expand it. 6 Click the Connectors container. Right-click the Connectors container and click New. 7 Click SMTP Connector. 8 On the General tab, enter a name for the connector. 9 Do one of the following: Use DNS or forward to a smart host if you are relaying through an Internet service provider send-mail server). Use the IP address of the smart host in square brackets if you are forwarding to a smart host. 10 Under Local Bridgeheads, do the following: a b c Click Add. Add the server that becomes the bridgehead server for the routing group. Designate an SMTP virtual server as a bridgehead server for the SMTP connector. This can be either the server that you are working on or another server in the same routing group. Alternatively, this duty can be shared by multiple servers. Tip 11 Do the following: a You can configure an SMTP virtual server to use a TCP (Listening) port that differs from the default SMTP port 25. You must make sure that the SMTP virtual server that you select as a local bridgehead for the SMTP connector has a TCP (Listening) port that equals 25. When you do this, the SMTP virtual server can be reached by other SMTP virtual servers that have the default TCP (Outgoing) port 25. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 274842 How to change SMTP port 25 to another port in Microsoft Exchange Server Click the Address Space tab.
Preparing for a Migration 15 b c d e Under Connector Scope, click either Entire Organization or Routing Group. As in earlier versions of Exchange Server, when you configure the Internet Mail Service, click Add, click SMTP, and then click OK. Accept the default (*) unless you require outbound e-mail domain restriction, and leave the cost as 1. If you have accepted the default of (*), you should never select the Allow messages to be relayed to these domains option. Selecting the Allow messages to be relayed to these domains option would open your server for relay to the world. This option should be for secure domain to domain connections only. 12 If you have chosen forward all mail to a smart host, do the following: a b Click the Advanced tab. Select the Outbound Security option, and then select an appropriate authentication method for your relay host. The default is Anonymous Access. Anonymous is the method that must be used if you are forwarding to an ISP, unless you have made prior arrangements with the ISP for another security level. If you are forwarding to your own server or to another server outside your environment, work with the administrator of that server to select the appropriate security level for both servers. You can add more than one smart host in this box by using the following format: [IP];[IP];[IP];[IP] 13 Click OK to exit Outbound Security. 14 Click OK to exit the Advanced tab. 15 Click OK to exit the SMTP connector. 16 Restart the Microsoft Exchange Routing Engine service and the SMTP service for these changes to take effect. Exchange 2007/2010 When migrating from on-premises Exchange you can't use the Microsoft directory synchronization solution. If you have used the MS directory synchronization, it is not possible to mailbox-enable the users that it has created in Office 365. The Microsoft directory synchronization also limits you to using the Microsoft migration tools. If you
16 Quest OnDemand Migration for Email 1.3.0 User Guide need a directory synchronization solution, please see Quest One Quick Connect for Cloud Services. Your DNS MX records will already be set to deliver mail to your Exchange server. For Exchange to forward mail, you need to set the targetaddress for the mailboxes that now reside on your new mail system to a subdomain that exists, and configure Exchange to route to target mail system. You can do this by using the Exchange PowerShell Set- Mailbox cmdlet. In the Exchange Management Shell, use the following command: Set-Mailbox -Identity SourceMailbox -TargetSmtpAddress TargetUsername@ForwardingSubDomain Where: SourceMailbox is the user's SMTP address in the source system. TargetUsername is the user's Target userid. ForwardingSubDomain is a secondary domain that you have set up in the Target domain. For the forwarded mail to get sent to your target system, you will need to create a new send connector to handle the forwarding domain. By using a send connector you do not need to expose this forwarding domain in your DNS. You can create a send connector in the Exchange Management Console, or you can use PowerShell in the Exchange Management Shell. To create the send connector with PowerShell, use the New- SendConnector cmdlet. The following is a simple usage of the send connector, your target system may require TLS or authentication to forward mail. You can change the Name parameter to something that better describes your connector. New-SendConnector -Name ForwardToTarget -AddressSpaces ForwardingSubDomain - DNSRoutingEnabled $false Google Apps To migrate data from Google Apps, you need to get your OAuth consumer key and consumer secret from the Google Apps administration control panel. Once you login to your Google Apps administrator control panel, navigate to the Advanced Tools tab and click the link Manage OAuth domain key in the Authentication section. This brings up the Manage OAuth domain key page. Here you will see the OAuth consumer key with the value of the domain name of your Google Apps domain, and a checkbox labeled Enable this consumer key. Check this option so the consumer key is enabled. There is also the OAuth consumer secret. You need both the key and the secret in the OnDemand Migration for Email Connections screen.
Preparing for a Migration 17 Office 365 (Cloud Relay) Caution The scenario described in this topic isn't supported in Microsoft Office 365 Beta for enterprises. According to the current Microsoft documentation: Update your MX record so that all mail destined for your domain will be routed to your new mail server. The instructions from Microsoft found here talk about how to route mail to the cloud. You will need to just update the MX records to redirect SMTP traffic to your Edge transport server. You can learn more about the edge transport server here The Office 365 mail routing page also provides instructions for different DNS providers. Since you have decided to route all mail to you new domain first, you also need to make sure your Primary domain is a Shared Domain. This will let any email addressed to mailboxes deleted from your Office 365 server to be routed to your new mail server. In order to forward any new mail to your new mail system that is routed to Office 365, you will need to use the Office 365 PowerShell cmdlet to set forwarding on your Office 365 mailboxes. Setting routing on individual mailboxes will ensure that any mail sent by existing Office 365 users is properly forwarded to the user s new mailbox. Once you have migrated the content from Office 365, you can safely remove the mailbox and allow the server to properly forward mail to the user s new mailbox. BPOS (Cloud Relay) According to the current Microsoft documentation: Update your MX record so that all mail destined for your domain will be routed to your new mail server. The instructions from Microsoft found here talk about how to route mail to the cloud. You will need to just update the MX records to redirect SMTP traffic to your Edge transport server. You can learn more about the edge transport server here. The BPOS mail routing page also provides instructions for different DNS providers. Since you have decided to route all mail to you new domain first, you also need to make sure your Primary domain is a Shared Domain. This will let any email addressed to mailboxes deleted from your BPOS server to be routed to your new mail server. In order to forward any new mail to your new mail system that is routed to BPOS, you will need to use the BPOS PowerShell cmdlet to set forwarding on your BPOS mailboxes. Setting routing on individual mailboxes will ensure that any mail sent by existing BPOS users is properly forwarded to the user s new mailbox. Once you have
18 Quest OnDemand Migration for Email 1.3.0 User Guide migrated the content from BPOS, you can safely remove the mailbox and allow the server to properly forward mail to the user s new mailbox. Live@edu (Cloud Relay) According to the current Microsoft documentation: Update your MX record so that all mail destined for your domain will be routed to your new mail server. The instructions from Microsoft found here talk about how to route mail to the cloud. You will need to just update the MX records to redirect SMTP traffic to your Edge transport server. You can learn more about the edge transport server here. The Live@edu mail routing page also provides instructions for different DNS providers. Since you have decided to route all mail to you new domain first, you also need to make sure your Primary domain is a Shared Domain. This will let any email addressed to mailboxes deleted from your Live@edu server to be routed to your new mail server. In order to forward any new mail to your new mail system that is routed to Live@edu, you will need to use the Live@edu PowerShell cmdlet to set forwarding on your Live@edu mailboxes. Setting routing on individual mailboxes will ensure that any mail sent by existing Live@edu users is properly forwarded to the user s new mailbox. Once you have migrated the content from Live@edu, you can safely remove the mailbox and allow the server to properly forward mail to the user s new mailbox. Initial Target Mail Hosts Refer to the sections below for mail routing instructions specific to your target email service. Live@edu Office 365 Exchange 2010 Live@edu Local System (On-Premises Relay) You will need to prove domain ownership to enable your Live@edu service. Microsoft provides two options: one option is to create an MX record, which you should not choose, and the second option is to create the CNAME record as directed here. Next, create a subdomain to route mail to Live@edu so you can create users with forwarding addresses during the transition period. A subdomain is also known as an Accepted Domain and that needs to be created so mailboxes on the Live@edu server
Preparing for a Migration 19 can have an alias that contains the subdomain address. Learn more about Accepted domains here. More details and step-by-step instructions from Microsoft can be found here. Live@edu (Outlook Live Relay) Update your MX record so that all mail destined for your domain will be routed to Live@edu by following the instructions from Microsoft found here. The above page also provides instructions for different DNS providers. Since you are routing all mail to Live@edu first, you also need to make sure that your Primary domain is a Shared Domain. This allows any email addressed to mailboxes not yet on your Live@edu server to be routed to your on-premises mail server. Please note that as soon as you create a mailbox on the Live@edu server, all mail will immediately be delivered to the Live@edu mailbox and no longer be delivered to the on-premises mailbox. Office 365 For a local Office 365 (On-Premises Relay) system, you will need to prove domain ownership to enable your Office 365 service. Microsoft provides two options: one option is to create an MX record, which you should not choose, and the second option is to create the CNAME record as directed here. Next, create a subdomain to route mail to Office 365 so you can create users with forwarding addresses during the transition period. A subdomain is also known as an Accepted Domain and that needs to be created so mailboxes on the Office 365 server can have an alias that contains the subdomain address. Learn more about Accepted domains here. More details and step-by-step instructions from Microsoft can be found here. Exchange 2010 For a local Exchange 2010 On-Premises Relay system, please review the information here. Create Target Mailboxes The next task in migrating mailboxes from a source email service is to create the target mailboxes they will be migrated to in the target email service. OnDemand Migration for Email does not create them for you. The procedure for creating mailboxes varies
20 Quest OnDemand Migration for Email 1.3.0 User Guide between email systems, and you should refer to the documentation provided with your system for particular instructions. Prepare Your Source Email Service for Migration Quest OnDemand Migration for Email currently supports migrating content from the following email services: Google Apps Sun ONE/iPlanet Novell GroupWise Microsoft Exchange 2000/2003 Microsoft Exchange 2007/2010 Microsoft BPOS Microsoft Live@edu Microsoft Office 365 Google Apps To migrate data from Google Apps, you will need to get the OAuth private key to enter account information in the Migration Settings tab. Google uses OAuth to authenticate. Your OAuth consumer key and secret are available on the Advanced Tools page of your Google Apps account. Make sure the OAuth key is enabled and the Two-legged OAuth access control is enabled to allow access to all APIs. Click here to learn more about OAuth. Sun ONE/iPlanet Quest OnDemand Migration for Email uses IMAP to migrate messages and folders from your Sun ONE/iPlanet server to an Office 365 or Live@edu 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
Preparing for a Migration 21 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 OnDemand 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 Office365 and Live@edu, only 10 mailboxes can be migrated at a time per each administrative account configured for the Office365 and Live@edu 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 Each mailbox can be migrated 5 times with a 25 GB limit per mailbox Novell GroupWise OnDemand Migration for Email supports migrations from Novell GroupWise 7.0.3 and higher. 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: Use an existing API Key Use Novell ConsoleOne to create the key 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.
22 Quest OnDemand Migration for Email 1.3.0 User Guide 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. 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. 5 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. 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. In the US, use the following IP addresses: 65.52.0.206 and 65.52.8.218 In Europe, use the following IP addresses: 65.52.74.141 and 65.52.75.177 2 Test the connection to GroupWise and test SOAP with a browser. If the GroupWise page is displayed, it is working correctly. Microsoft Exchange 2000/2003 To migrate data from Exchange 2000/2003, make sure that Outlook Web Access (OWA) is accessible from the internet. Quest OnDemand Migration for Email uses WebDAV to access your mail server from the internet. Typically the URL for accessing Exchange via WebDAV is the same as your OWA url. It follows the format: https://servername/ exchange.
Preparing for a Migration 23 To access the mailboxes slated for migration, the domain credentials for the Exchange 2000/2003 server must have Receive As permission to all mailboxes. To grant Receive As permission for your migration administrative user, do the following: 1 Start Exchange System Manager and locate the Mailbox store under Administrative Groups. 2 Right-click the Mailbox store, click Properties, and then click the Security tab. 3 In the top pane, click the account that you are logged on as, and in the bottom pane, select the Receive As check box to grant this permission to that account. 4 Click OK. This account now has full permissions to log on to the mailbox store and to export or import messages for every mailbox. 5 Grant Receive As permission to the migration administrator account on all the mailbox stores which you are migrating. Caution The migration administrator account MUST NOT be a member of the Domain Administrators or Enterprise Administrators groups. These groups have explicit denies for the Receive As permission. Microsoft Exchange 2007/2010 Enabling Application Impersonation Rights To migrate data from Exchange 2007/2010 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 -
24 Quest OnDemand Migration for Email 1.3.0 User Guide Identity User1 select-object).identity -extendedright ms-exch-epi- Impersonation} Note For more information, refer to the instructions provided by Microsoft here. For Exchange 2010, 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 here. To create a role group for impersonation, use the PowerShell cmdlets from the article 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 Go to Start All Programs Microsoft Exchange Server 2010 Exchange Management Console. 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, make sure that Outlook Web Access (OWA) is accessible from the internet. Quest OnDemand 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.
Preparing for a Migration 25 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 here 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 server must be configured to support auto-discovery before you can use it to obtain the server URL. Click here for more information on the autodiscover service in Exchange 2007. Click here for information on Exchange 2010. If entering the server URL manually, enter the name of your Exchange 2007/2010 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. Microsoft BPOS To migrate data from BPOS, your administrator account must have access to the users mailboxes. To accomplish this, you will need to download and install the Microsoft Online Services Migration Tools toolkit. For instructions on how to download and install these tools, click here. After installing the tools, you need to: 1 Open a PowerShell command prompt and add the PowerShell snapin for these tools using the command Add-PSSnapin Microsoft.Exchange.Transporter to add the snapin into the current PowerShell session. 2 Use the Add-MSOnlineMailPermission cmdlet to grant the appropriate admin user(s) GrantFullAccess rights to the target account. You have to do this for every target mailbox in your Office 365 domain. Instructions to help you do this can be found here. It is recommended you select the auto-discovery option in the Migration Settings screen when specifying the URL of your BPOS server. Auto-discovery uses your login
26 Quest OnDemand Migration for Email 1.3.0 User Guide credentials to automatically obtain the server name during a migration. You can also enter the name of your Live@edu server manually as it appears in the address bar when you log in as an administrator to your account. When connecting to your BPOS 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 BPOS 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. Click here for more information. Each mailbox can be migrated 5 times with a 25 GB limit per mailbox. Also, for each administrator account, you can migrate a total of 10 mailboxes. If you need to migrate more than 10 mailboxes concurrently, you can create additional administrator accounts on the source email service with corresponding accounts on the target email service by clicking the Add additional credentials button. For each pair of administrator accounts you create, you can migrate 10 additional mailboxes. You can create a total of 5 pairs of administrator accounts, which means you can migrate a total of 50 mailboxes at one time. Note To migrate more than 10 mailboxes between email services, each administrator account you create on the source email service must be paired with a corresponding account on the target email service. For example, if you create 3 accounts on the source email service but only 2 accounts on the target email service, you will be able to migrate a total of 20 mailboxes from the source to the target email service, not 30. Microsoft Live@edu To migrate data from Live@edu, your administrator account must have Application Impersonation rights, which means the account must be assigned to a Role-Based Access Control group that has Application Impersonation rights. By default, no groups have Application Impersonation rights, which means the first step is to sign in as an organization administrator to the Live@edu portal (http://outlook.com) and either add this right either to an existing role group or to a new role group that you create. Click here for more information on creating role groups and assigning rights. It is recommended that you create a new role group named Migration Impersonation and add the Application Impersonation right to it.
Preparing for a Migration 27 Role groups are created in the Role Groups page of the Live@edu 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 When connecting to your Live@edu 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 Live@edu 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. Click here for more information. Microsoft Office 365 To migrate data from Office 365, your administrator account must have Application Impersonation rights, which means the account must be assigned to a Role-Based Access Control group that has Application Impersonation rights. By default, no groups have Application Impersonation rights, which means the first step is to sign in as an organization administrator to the Office 365 portal (http://portal.microsoftonline.com) and either add this right either to an existing role group or to a new role group that you create. Click here for more information on creating role groups and assigning rights. It is recommended that you create a new role group named Migration Impersonation and add the Application Impersonation right to it. Role groups are created in the Role Groups page of the Office 36 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 When connecting to your Office 36 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 Office 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. Click here for more information.
28 Quest OnDemand Migration for Email 1.3.0 User Guide Prepare Your Target Email Service for Migration Before you do any migrations, you need to configure your target email service. OnDemand Migration for Email currently supports migrating content to the following target email services: Microsoft Office 365 Microsoft Exchange 2010 Microsoft Live@edu Microsoft Office 365 Enabling Application Impersonation Rights To migrate data to Office 365, your administrator accounts must have Application Impersonation rights, which means 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, the first step is to sign in as an organization administrator to the Office 365 portal (http://portal.microsoftonline.com) and either add this right to an existing role group or to a new role group that you create. Click here for more information on creating roles and assigning rights. It is recommended that you create a new role group named Migration Impersonation and add the Application Impersonation right to it. You create a role group in the Office 365 portal in the Role Groups page. From 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. Provisioning Before creating new user accounts on your Office 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. 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 Office 365 server. Click here for more information. If you are migrating from Google Apps, 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, click here.
Preparing for a Migration 29 Microsoft Exchange 2010 Enabling Application Impersonation Rights To migrate data to Exchange 2010, your administrator accounts must have Application Impersonation rights, which means 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 here. To create a role group for impersonation, use the PowerShell cmdlets from the article 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 Go to Start All Programs Microsoft Exchange Server 2010 Exchange Management Console. 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 OnDemand 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
30 Quest OnDemand Migration for Email 1.3.0 User Guide 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 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 here and follow the upgrade instructions specific your version of Exchange under the Planning and Deployment section. If you are migrating from Google Apps, 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 here, and how to add mailboxes here. To see how PowerShell cmdlets work together, go here. Microsoft Live@edu Enabling Application Impersonation Rights To migrate data to Live@edu, your administrator accounts must have Application Impersonation rights, which means 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, the first step is to sign in as an organization administrator to the Live@edu portal (http://outlook.com) and either add this right to an existing role group or to a new role group that you create. Click here for more information on creating roles and assigning rights. It is recommended that you create a new role group named Migration Impersonation and add the Application Impersonation right to it. You create a role group in the Live@edu portal in the Role Groups page. From 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. Provisioning Before creating new Live@edu user accounts, consider how these new accounts should be managed in the future and what implications this will have on mail routing. See the Mail Routing reference topic for more information.
Preparing for a Migration 31 If you are migrating from on-premises Exchange you should consider using Outlook Live Directory Synchronization (OLSync). For more information, click here. If you are migrating from Google Apps, 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, click here.
32 Quest OnDemand Migration for Email 1.3.0 User Guide
Configuring and Running Migrations Contents Creating a Migration Plan Connecting to Email Services Importing Mailboxes Selecting Migration Options Known Limitations Migrating
34 Quest OnDemand Migration for Email 1.3.0 User Guide Creating a Migration Plan A migration plan saves in a reusable format all the configuration details of a migration, including its connection properties, source and target mailboxes, and optional parameters. When you first login into to OnDemand Migration for Email, you are prompted to specify a name for your first migration plan. You can copy migration plans and then edit those copies to create other migration plans. This spares you the task of specifying the same set of values if you want to run multiple migrations that share certain configuration details and mailboxes. For example: If certain mailboxes fail to migrate when you first run a migration, you can quickly create a new migration plan which only includes the mailboxes that failed to migrate the first time If you are planning to migrate a large number of mailboxes, you can divide the workload into more manageable segments or among different migrators If you want to migrate more than 50 mailboxes concurrently, you can create multiple migration plans with different administrator accounts and run them simultaneously Migration Dashboard Migration plans are viewed and managed in the Migration Dashboard, which you open by clicking the Migration Dashboard link in the breadcrumb bar. The Migration Dashboard displays the configuration settings of each migration plan and includes links pointing to the Connections, Mailboxes, Options, and Migrate tabs. To edit a migration plan, click the appropriate link to open the tab you want, make your changes, and then save the migration plan. Copying Migration Plans To copy a migration plan: 1 Do one of the following: Open the Migration Dashboard and click Copy. Open the Migrate tab and click Copy Migration Plan. 2 Specify a name for the copied migration plan.
Configuring and Running Migrations 35 By default, all the configuration details and mailboxes of the original migration plan are selected to be copied. 3 De-select the configuration details you do not want to copy and de-select the migration status of any mailbox you do not want to include in the new migration plan. For example, if you want to create a migration plan that only includes mailboxes that failed to migrate in the original migration plan, you would keep the same connection properties and options and de-select all the mailbox statuses except Failed. 4 Click Copy 5 Edit the new migration plan as needed.
36 Quest OnDemand Migration for Email 1.3.0 User Guide Connecting to Email Services To set up a migration, you must specify the connection properties for your source email service and target email service. This is done in the Connections tab. When connecting to email services, be aware of the following: Each mailbox in a source email service can be migrated 5 times with a 25 GB limit per mailbox. For each Microsoft-based email service, you can migrate a total of 10 mailboxes concurrently per administrator (Google Apps, Sun ONE/iPlanet, and GroupWise have no such limitation). If you need to migrate more than 10 mailboxes concurrently either from or to a Microsoft-based email service, create additional administrator accounts by clicking the Add Additional Credential button (If both the source and target email service are Microsoft-based, you must create additional accounts for each). For each account you can migrate 10 additional mailboxes, and each account must have the same permissions as the primary account. You can create a total of 5 administrator accounts for each email service per migration plan, which means you can migrate a total of 50 mailboxes at one time. To migrate more than 50 mailboxes simultaneously, create additional migration plans with different administrator accounts. Note To migrate more than 10 mailboxes between email services, each administrator account you create on the source email service must be paired with a corresponding account on the target email service. For example, if you create 3 accounts on the source email service but only 2 accounts on the target email service, you will be able to migrate a total of 20 mailboxes from the source to the target email service, not 30. Connecting to the Source Email Service Refer to the sections below for instructions specific to your source email service. Google Apps Sun ONE/iPlanet Novell GroupWise Microsoft Exchange 2000/2003 Microsoft Exchange 2007/2010 Microsoft BPOS
Configuring and Running Migrations 37 Microsoft Live@edu Microsoft Office 365 Google Apps Specify the following values to connect to your Google Apps source email service: Google Domain The domain name of the Google administrator account. Consumer Key and Consumer Secret The details for the source Google server can be found by logging in as an administrator to your Google Apps account. Sun ONE/iPlanet Specify the following values to connect to your Source ONE/iPlanet source email service: Server Name Enter the location of the Sun ONE/iPlanet server as appears in the address bar when you log in as an administrator to your account. Port Enter the Sun ONE/iPlanet server port number. Use SSL If your server does not support SSL, all mailbox data will be transmitted non-encrypted. Use SSL connections if possible to secure your data. Admin User Name and Password The name and password of the administrator account. To migrate data from Sun ONE/iPlanet, your administrator account must have FullAccess rights to all mailboxes. Novell GroupWise Note When connecting to your GroupWise source email service, be aware of the following: OnDemand Migration for Email supports GroupWise 7.0.3 and higher Certain mailbox items cannot be migrated or are migrated with limitations. For more information, see Known Limitations on page 53. Specify the following values to connect to the GroupWise source email service: Server Name The name of the GroupWise Server running the Post Office Agent (POA) that hosts the SOAP services (in the format server.example.com).
38 Quest OnDemand Migration for Email 1.3.0 User Guide The mailboxes to be migrated must be reachable from this POA. If you are using SSL, select the Use SSL option. Use SSL Select this option If you are using SSL and enter the name of your GroupWise server manually in SSL format (server.example.com) Port The Web Service port number App Name The value from the Name field that you specified when creating your trusted key in ConsoleOne. OnDemand Migration for Email uses the GroupWise Trusted Key API to access the mailboxes that are migrated. To grant ODME access to all your GroupWise mailboxes you need to create a Trusted API key using Console One, or by downloading the Trusted API key generation tool by clicking here. 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. API Key The value of the trusted key found in the file created when you generated the Trusted Application key using ConsoleOne. Microsoft Exchange 2000/2003 Specify the following values to connect to your Exchange 2000/2003 source email service: Server URL The Exchange 2000/2003 URL must be properly formatted, beginning with "http://" or "https://" and ending with "/exchange" (e.g., http:// mail.example.com/exchange). To access the mailboxes slated for migration, the migrator needs to have an account with permissions to all the mailboxes. User Name and Password The name and password of the administrator account. The user name is the samaccountname. To access the mailboxes slated for migration, the migrator needs to have an account with permissions to all the mailboxes. Domain The domain name of the Exchange account Microsoft Exchange 2007/2010 Specify the following values to connect to your Exchange 2007/2010 source email service:
Configuring and Running Migrations 39 Server URL You can enter the URL of the Exchange 2007/2010 server manually, or you can use the auto-discovery option. If you are not using HTTPS for Outlook Web Access (OWA), enter the full URL for your EWS service, e.g., http://servername/ews/service.asmx. If you are using SSL, enter the name of your Exchange 2007/2010 server manually (e.g., exchange.example.com). Note If your server does not support SSL, all mailbox data will be transmitted nonencrypted. Use SSL connections if possible to secure your data Use auto-discovery Use auto-discovery to obtain the server URL. During a migration, this option uses the specified user name and password to retrieve the server URL that hosts your Exchange Web Services (EWS) server for the given mailbox. If you are having problems with auto-discovery, you can test your external connectivity using a free tool from Microsoft. The following website can be used to validate if your services are working properly. Please go to https:// www.testexchangeconnectivity.com to test your Exchange connectivity. Admin User Name and Password The name and password of the administrator account. The Admin User Name value is the account's UPN or domain credentials (e.g., domain\username). For more information about UPNs and how to determine which domain you are using for your users, please see Active Directory naming on the Microsoft Technet site. Microsoft BPOS Specify the following values to connect to your BPOS source email service: Server Name Enter the name of the BPOS server as it appears in the address bar when you log in as an administrator to your account or use the auto-discovery option. Use auto-discovery Use auto-discovery to obtain the name of your BPOS server. If you are having problems with auto-discovery, you can test your external connectivity using a free tool from Microsoft. The following website can be used to validate if your services are working properly. Please go to https:// www.testexchangeconnectivity.com to test your Exchange connectivity. Admin Name and Password The name and password of the administrator account
40 Quest OnDemand Migration for Email 1.3.0 User Guide To migrate data from BPOS, your administrator account must have FullAccess rights to all mailboxes, which means the account must be assigned rights using the BPOS PowerShell cmdlets that you can download from Microsoft. Microsoft Live@edu Specify the following values to connect to your Live@edu source email service: Server Name You can enter the name of the Live@edu server as it appears in the address bar when you log in as an administrator to your account, or you can use the auto-discovery option. Use auto-discovery It is recommended that you use auto-discovery to obtain the name of your Live@edu server. Auto-discovery uses your login credentials to automatically obtain the server name during a migration. With auto-discovery, OnDemand Migration for Email connects directly to the Live@edu auto-discovery endpoints, meaning that you don't have to configure your DNS to take advantage of auto-discovery. You do need to make sure that all your mailboxes exist in Live@edu before migrating data into them. Note For more information about DNS records and how they impact Live@edu, please see the article: Create DNS Records for Live@edu. Admin User Name and Password The name and password of the administrator account. To migrate data from Live@edu, your administrator account must have Application Impersonation rights, which means the account must be assigned to a Role-Based Access Control group that has Application Impersonation rights. For more information, see Prepare Your Source Email Service for Migration on page 20. Microsoft Office 365 Specify the following values to connect to the Office 365 source email service: Server Name You can enter the name of the Office 365 server as it appears in the address bar when you log in as an administrator to your account, or you can use the auto-discovery option.the name of the Office 365server. Use auto-discovery It is recommended that you use auto-discovery to obtain the name of your Office 365 server. Auto-discovery uses your login credentials to automatically obtain the server name during a migration. With auto-discovery, OnDemand Migration for Email
Configuring and Running Migrations 41 connects directly to the Office 365 auto-discovery endpoints, meaning that you don't have to configure your DNS to take advantage of auto-discovery. You do need to make sure that all your mailboxes exist in Office 365 before migrating data into them. Admin User Name and Password The name and password of the administrator account. To migrate data to Office 365, your administrator account must have Application Impersonation rights, which means the account must be assigned to a Role-Based Access Control group that has Application Impersonation rights. For more information, see Prepare Your Source Email Service for Migration on page 20. Connecting to the Target Email Service Refer to the sections below for instructions specific to your target server. Microsoft Office 365 Microsoft Exchange 2010 Microsoft Live@edu Microsoft Office 365 Specify the following values to connect to the Office 365 source email service: Server Name You can enter the name of the Office 365 server as it appears in the address bar when you log in as an administrator to your account, or you can use the auto-discovery option. Use auto-discovery It is recommended that you use auto-discovery to obtain the name of your Office 365 server. Auto-discovery uses your login credentials to automatically obtain the server name during a migration. With auto-discovery, OnDemand Migration for Email connects directly to the Office 365 auto-discovery endpoints, meaning that you don't have to configure your DNS to take advantage of auto-discovery. You do need to make sure that all your mailboxes exist in Office 365 before migrating data into them. Admin User Name and Password The name and password of the administrator account. To migrate data to Office 365, your administrator account must have Application Impersonation rights, which means the account must be assigned to a Role-Based
42 Quest OnDemand Migration for Email 1.3.0 User Guide Access Control group that has Application Impersonation rights. For more information, see Prepare Your Target Email Service for Migration on page 28. Microsoft Exchange 2010 Specify the following values to connect to your Exchange 2010 target email service: Server URL You can enter the URL of the Exchange 2010 server manually, or you can use the auto-discovery option. If you are not using HTTPS for Outlook Web Access (OWA), enter the full URL for your EWS service, e.g., http://servername/ews/service.asmx. If you are using SSL, enter the name of your Exchange 2010 server manually (e.g., exchange.example.com). Note If your server does not support SSL, all mailbox data will be transmitted nonencrypted. Use SSL connections if possible to secure your data Use auto-discovery Use auto-discovery to obtain the server URL. During a migration, this option uses the specified user name and password to retrieve the server URL that hosts your Exchange Web Services (EWS) server for the given mailbox. If you are having problems with auto-discovery, you can test your external connectivity using a free tool from Microsoft. The following website can be used to validate if your services are working properly. Please go to https:// www.testexchangeconnectivity.com to test your Exchange connectivity. Admin User Name and Password The name and password of the administrator account. The Admin User Name value is the account's UPN or domain credentials (e.g., domain\username). For more information about UPNs and how to determine which domain you are using for your users, please see Active Directory naming on the Microsoft Technet site. Microsoft Live@edu Specify the following values to connect to your Live@edu source email service: Server Name You can enter the name of the Live@edu server as it appears in the address bar when you log in as an administrator to your account, or you can use the auto-discovery option. Use auto-discovery It is recommended that you use auto-discovery to obtain the name of your Live@edu server.
Configuring and Running Migrations 43 Auto-discovery uses your login credentials to automatically obtain the server name during a migration. With auto-discovery, OnDemand Migration for Email connects directly to the Live@edu auto-discovery endpoints, meaning that you don't have to configure your DNS to take advantage of auto-discovery. You do need to make sure that all your mailboxes exist in Live@edu before migrating data into them. Note For more information about DNS records and how they impact Live@edu, please see the article: Create DNS Records for Live@edu. Admin User Name and Password The name and password of the administrator account. To migrate data to Live@edu, your administrator account must have Application Impersonation rights, which means the account must be assigned to a Role-Based Access Control group that has Application Impersonation rights. For more information, see Prepare Your Target Email Service for Migration on page 28. Validating Connections After entering the connection properties of a source or target email service, click Test Connection. OnDemand Migration for Email then prompts you to enter the name of a source or target mailbox and uses the login credentials you specified to connect to that mailbox. Depending on your type of source and target email service, different connection errors may be reported. Refer to the sections below for validation errors specific to your email platform: Google Apps Sun ONE/iPlanet Novell GroupWise Microsoft Exchange 2000/2003 Microsoft Exchange 2007/2010 Microsoft Live@Edu Microsoft Office 365 Google Apps OnDemand Migration for Email connects to the url http://www.google.com/a/ example.com (example.com is from the Google Domain setting above). If that page
44 Quest OnDemand Migration for Email 1.3.0 User Guide exists as a Google Apps domain, the next step is to connect to the Google Apps server using the OAuth Consumer Key and Consumer Secret and then open the test mailbox. Error The test mailbox doesn't exist, or the Consumer Key/Secret are incorrect. Description/Resolution You may see the following error when you test the connection: Invalid Mailbox (Unable to retrieve folders). Failed to connect to IMAP server. When this happens make sure your Consumer Secret and Key has been entered correctly. Also verify that your test mailbox exists, and your spelling is correct. Sun ONE/iPlanet Error The test mailbox doesn't exist. Description/Resolution You may see the following error when you test the connection: There was a problem testing your connection. Please try again. Verify that the mailbox name does exist in SunONE/ iplanet and that you have spelled the name correctly.
Configuring and Running Migrations 45 Error Server name is incorrect, or firewall is blocking access. Description/Resolution You may see the following error when you test the connection: Failed to connect sunone.example.com IMAP server. Check that your server name is spelled correctly and that your firewall is open to the OnDemand Email Migration for Email IP addresses to port 7191. For the US, OnDemand Migration for Email is hosted on the following IP addresses: 65.52.0.206 65.52.8.218 65.52.0.86 For EU customers, the IP addresses are: 65.52.74.141 65.52.75.177 65.52.73.234 Novell GroupWise Error The test mailbox doesn't exist. Description/Resolution You may see the following error when you test the connection: Invalid Mailbox Name: test.mailbox Code= D101, Description= User not on post office. Verify that the mailbox name does exist in GroupWise and that you have spelled the name correctly.
46 Quest OnDemand Migration for Email 1.3.0 User Guide Error Server name is incorrect, or firewall is blocking access. Description/Resolution You may see the following error when you test the connection: Cannot find server. Server:groupwise.example.com, Port:7191. Check that your server name is spelled correctly and that your firewall is open to the OnDemand Email Migration for Email IP addresses to port 7191. For the US, OnDemand Migration for Email is hosted on the following IP addresses: 65.52.0.206 65.52.8.218 65.52.0.86 For EU customers, the IP addresses are: 65.52.74.141 65.52.75.177 65.52.73.234 Microsoft Exchange 2000/2003 OnDemand Migration for Email uses WebDAV to connect to your on premises server from the cloud. To validate your server settings, the application connects to your Exchange Outlook Web Access server using port 443 (https) or port 80 (http) and the administrator credentials you provided in the server configuration.
Configuring and Running Migrations 47 After the validation routine has connected to your Exchange server it opens the mailbox that you specified. Error Firewall blocking access Migration administrator account doesn't have sufficient rights, or test mailbox doesn't exist Description/Resolution Your firewall is blocking the OnDemand Migration for Email application. To ensure your data can be migrated, open the appropriate port for the OnDemand Migration for Email application to connect to your server. For the US, OnDemand Migration for Email is hosted on the following IP addresses: 65.52.0.206 65.52.8.218 65.52.0.86 For EU customers, the IP addresses are: 65.52.74.141 65.52.75.177 65.52.73.234 You may see the following error when you test the connection: Unable to connect to server. Mailbox test.mailbox may not exist on the Exchange server, or you may not have permissions to read the mailbox. When this happens make sure your administrator account has been configured according to the preparing your Exchange 2000/2003 server section. Verify that your test mailbox exists, and your spelling is correct. Microsoft Exchange 2007/2010 OnDemand Migration for Email uses Exchange Web Services (EWS) to connect to your on premises server from the cloud. To validate your server settings, the application connects to your Exchange server using port 443 (https) or port 80 (http) and the administrator credentials you provided in the server configuration.
48 Quest OnDemand Migration for Email 1.3.0 User Guide If you enter a Server URL value that does contain http:// or https://, https:// will be prepended to the URL. It is recommended that you use the servername, but if you require http:// access, you should enter http://servername as the value for Server URL. After the validation routine has connected to your Exchange server it opens the mailbox that you specified. Error Firewall blocking access Migration administrator account doesn't have sufficient rights, or test mailbox doesn't exist Description/Resolution Your firewall is blocking the OnDemand Migration for Email application. To ensure your data can be migrated, open the appropriate port for the OnDemand Migration for Email application to connect to your server. For the US, OnDemand Migration for Email is hosted on the following IP addresses: 65.52.0.206 65.52.8.218 65.52.0.86 For EU customers, the IP addresses are: 65.52.74.141 65.52.75.177 65.52.73.234 You may see one of the following errors when you test the connection: Invalid Mailbox (Unable to retrieve folders). Invalid Mailbox (Unable to retrieve folders). The Autodiscover service returned an error. When this happens make sure your administrator account has been configured as described in the section, Microsoft Exchange 2007/2010 on page 23. Also verify that your test mailbox exists, and your spelling is correct.
Configuring and Running Migrations 49 Microsoft Live@Edu When entering connection properties for Live@Edu, it is recommended that you select the Use auto-discovery option. Entering the Server Name manually may cause errors when migrating many mailboxes. Error Migration administrator account doesn't have sufficient rights, or test mailbox doesn't exist Description/Resolution You may see one of the following errors when you test the connection: Invalid Mailbox (Unable to retrieve folders). Invalid Mailbox (Unable to retrieve folders). The Autodiscover service returned an error. When this happens make sure your administrator account has been configured as described in the section, Microsoft Live@edu on page 26. Also verify that your test mailbox exists, and your spelling is correct. Microsoft Office 365 When entering connection properties for Office 365, it is recommended that you select the Use auto-discovery option for your server. Entering the Server Name manually may cause errors when migrating many mailboxes. Error Migration administrator account doesn't have sufficient rights, or test mailbox doesn't exist Description/Resolution You may see one of the following errors when you test the connection: Invalid Mailbox (Unable to retrieve folders). Invalid Mailbox (Unable to retrieve folders). The Autodiscover service returned an error. When this happens make sure your administrator account has been configured as described in the section, Microsoft Office 365 on page 27. Also verify that your test mailbox exists, and your spelling is correct.
50 Quest OnDemand Migration for Email 1.3.0 User Guide Importing Mailboxes After connecting your source and target email services, the next step is to specify which mailboxes to migrate. This is done in the Mailboxes tab. Note If you haven t already done so, set up the mailbox accounts in the target email service. OnDemand Migration for Email does not create target mailboxes during a migration. To import mailboxes: 1 Create a text file which lists each mailbox to be migrated on a separate line. If you want to migrate to a target mailbox that has a different name than the source mailbox, specify the name of the target mailbox in a tab-separated column after the source mailbox. The format of each entry depends on the source or target server type, as shown in the following examples: Exchange 2000 Source The import file entry for an Exchange 2000 source mailbox must be the alias from the email address corresponding to the default SMTP policy. psmith bjones [tab] Bill.Jones Exchange 2003 Source The import file entry for an Exchange 2003 source mailbox can be the same alias used for Exchange 2000, or it can be the primary SMTP address. psmith psmith@example.com bjones [tab] Bill.Jones bjones@mail.com [tab] Bill.Jones Exchange 2007/2010, Live@edu, and Office 365 Source and Target The import file entry for an Exchange 2007/2010, Live@edu, Office 365 source and target mailboxes should be the full SMTP address. If, however, the domain name for the SMTP address matches the domain name on the admin credential, then it can be omitted. psmith@example.com bjones@example.com [tab] Bill.Jones@example.com
Configuring and Running Migrations 51 Other Server Types In this example the first source mailbox does not map to a new account name, but the second source mailbox does. Psmith Bjones [tab] Bill.Jones 2 Click the Mailboxes tab. 3 Click Choose File (Chrome) or Browse (IE and Firefox) and select the text file. 4 Click Import. OnDemand Migration for Email imports the file and displays the list of source and target mailboxes. If any entries are improperly formatted, the file will not be imported and you must correct any errors identified. If you need to modify your migration plan, edit your source text file and then re-import. The entire list will be updated to the contents of your text file. Selecting Migration Options In the Option tab, you can specify which mailbox items (email, contacts, calendar appointments, and tasks) you want to exclude from the migration. Also, you can exclude email that was not sent or received before, after, or within a specified date range. You can also opt to exclude email in the Junk, Deleted and Sent folders as well as folders you specify. To select items to migrate: 1 Click the Options tab. By default, OnDemand Migration for Email migrates all email and all supported mailbox items. 2 De-select any type of mailbox item you want to exclude from the migration, including Email, Contacts, Calendar, or Tasks. Caution OnDemand Migration for Email does not support migrating the following: Tasks from Google Apps Documents and task invites from GroupWise Contacts, calendars, and tasks from Sun ONE/iPlanet
52 Quest OnDemand Migration for Email 1.3.0 User Guide 3 If you want to exclude email that was not sent or received before, after, or within specific dates, select the option(s) and use the Calendar tool to select the dates you want. 4 If you want to exclude email in Junk, Deleted and Sent folders, select those options. Caution Migrating Deleted Items and Junk Email could significantly increase migration time 5 If you want to exclude email in specific folders, enter the fully qualified path for each folder you want to exclude with each folder specified on a separate line (e.g., Inbox/Private ). When you exclude a folder, any subfolders it contains are also excluded from the migration. Note For GroupWise, if you want to exclude the "View by..." folders, you need to add them to the Exclude Specific Folders field. These folders include: View by Tasklist options View by Panels options View by Discussion Threads options View by Details options View by Calendar options
Configuring and Running Migrations 53 Known Limitations Due to the differences between email service platforms, certain mailbox items either cannot be migrated or are migrated in a limited fashion. Migrating General Rules in source email service platforms that govern the recurrence of meeting invitations do not correspond precisely with similar rules in Exchange. This means that the dates of meeting invitations may be incorrectly represented in the Outlook calendar after being migrated to Exchange GroupWise In GroupWise 7, contact web page addresses are not migrated. In GroupWise 7, contact comments are not migrated. With all other supported versions, contact comments are merged into Outlook contact notes. Mailboxes that have bare attachments (documents in the mailbox that are not part of the message) do not migrate Old tasks migrate with incorrect due dates and certain tasks may migrate one day early. Outlook contacts only display three GroupWise contact email addresses. If there is a primary email address then it becomes the first email address listed. Outlook contacts only display one GroupWise contact IM address. If there is a primary IM address then it becomes the only IM address. Office 365 We are unable to support Office365/Exchange 2010 hybrid deployments. If your Office 365 configuration utilizes a shared domain configuration the On Demand Migrator for Email is not able to locate your mailboxes.
54 Quest OnDemand Migration for Email 1.3.0 User Guide After you have connected to your source and target email services, imported the mailboxes you want to migrate, and optionally, selected what mailbox items to exclude from the migration, you are ready to run the migration. Running a Migration To run a migration: 1 Do one of the following: Open the Migration Dashboard. Open the Migrate tab. The Migrate tab lists all the mailboxes that have been imported (up to 5000). 2 Optionally, make any changes to the migration settings as summarized in the in Migration Dashboard or in the Migration Checklist of the Migrate tab. The migration plans in the Migration Dashboard and the Migration Checklist in the Migrate tab display links pointing to the Connections, Mailboxes and Options tabs. Click a link to return to the tab and make the changes you want. Note The Migration Checklist displays the IP addresses of the ODME web services used to run the migration (which are distinct from the web services used to validate connections to the source and target email services). The system administrator should verify that no firewall rules exist that will prevent the ODME web services identified by the IP addresses from running a migration. 3 Click Start Migration. During the migration, each mailbox displays what percentage of the mailbox has been migrated. At the bottom a colored progress bar indicates the overall status of the migration. When the migration is complete, the number of mailboxes that were successfully migrated and the number that failed to migrate are displayed in the Migration Status. 4 Optionally, to view migration log entries for a single mailbox, click the name of the mailbox.
Post Migration Contents Viewing Migration Reports Notify and Train Users
56 Quest OnDemand Migration for Email 1.3.0 User Guide Viewing Migration Reports On Demand Migration for Email provides both a general Migration Summary report and more detailed reports for each migration. These reports are accessed by clicking Reports in the Migration Dashboard. The Migration Summary report displays the following information: The date of the first successful migration The total number of successfully migrated mailboxes The total amount of migrated data in MB The total number of migrated mailbox items (messages, contacts, distribution lists, appointments, and tasks) The Migration Details report displays information about each migration that completed during a particular month, including the completion date and time, the source and target mailbox, and the result (a successful migration is where 90% or more of the items migrated successfully). To run a Migration Details report: 1 Select the Migration Details option. 2 Select the month in which the migrations you want to view completed. For each migration, Migration Details reports also include a link to download the migration audit log entry to a text file. 3 Optionally, click the Download link for a particular migration to view the audit log. Additional information about each migration in a Migration Details report is available as a downloadable csv file. 4 Optionally, click Download Additional Details to view additional information about each migration. Notify and Train Users After successfully migrating mailboxes, you should notify users of the migration and provide information on how to access the new mail system. This step is performed outside of OnDemand Migration for Email and may include training users on the new system as needed.
Glossary This glossary provides definitions of many of the terms commonly used in OnDemand Migration for Email. Admin Credentials The login information (username/password) of an account that has the required rights to access all mailbox data. The rights assigned to this account will vary based on the Source Email Service or Target Email Service configured for the migration. Email Service Collection of settings that define a mailbox store. This may include host name, port and protocol information, but in some cases it is only necessary to define the type of service (i.e. Google Apps). Alternatives: Environment, Connection, Service, Migration Path Item An object within a mailbox that may be migrated. This is typically one of an Email, Contact, Appointment, Distribution List. Migration A single pass through a Source Mailbox moving all the Items selected to migrate to the Target Mailbox. Migration Collection A group of Migration Jobs that are all executed together in one sequence. Alternatives: Project, Batch Migration Options Collection of settings that define the data to be migrated. This includes item type (Email, Contacts, Calendar, Tasks), filters (migrate items received before or after
58 Quest OnDemand Migration for Email 1.3.0 User Guide specified date, exclude folders, etc.), and may be extended to cover additional settings like custom properties on mail items. Alternatives: Migration Items, Filters Migration Job Mapping between a Source Mailbox and a Target Mailbox. Source Email Service The email service platform from which mailbox items are migrated. Source Mailbox Mailbox that has been selected to migrate to the Target Email Service. Successful Migration Any Migration where 90% or more of the items are migrated successfully. Target Email Service The future location for mailboxes after they are migrated, either Office 365, Live@edu or Exchange 2010. Target Mailbox Mailbox that exists on the Target Email Service and will hold all of the data from the Source Mailbox after the migration is complete.
Index B BPOS connecting to source email services 39 preparing source email services 25 C connecting to source email services 36 BPOS 39 Exchange 2000/2003 38 Exchange 2007/2010 38 Google Apps 40 GroupWise 37 Live@edu 40 Office 365 40 Sun ONE/iPlanet 37 connecting to target email services 41 Exchange 2010 42 Live@edu 42 Office 365 43 contact Quest Software viii creating additional accounts 36 E Exchange 2000/2003 connecting to source email services 38 mail routing 13 preparing source email services 22 validating connections 46 Exchange 2007/2010 connecting to source email services 38 mail routing 15 preparing source email services 23 validating connections 47 Exchange 2010 connecting to target email services 42 mail routing 19 preparing target email services 29 provisioning 30 G Google Apps connecting to source email services 40 mail routing 16 preparing source email services 20 validating connections 43 GroupWise connecting to source email services 37 preparing source email services 21 validating connections 45 I importing mailboxes 49 L Live@edu connecting to source email services 40 connecting to target email services 42
60 Quest OnDemand Migration for Email 1.3.0 User Guide M mail routing 18 preparing source email services 26 preparing target email services 30 provisioning 30 validating connections 49 mail routing 12 Exchange 2000/2003 13 Exchange 2007/2010 15 Exchange 2010 19 Google Apps 16 Live@edu 18 Office 365 19 mailboxes importing 49 selecting items to migrate 51 migrating running a migration 54 selecting mailbox items 51 Migration Dashboard 34 migration plans copying 34 creating 34 O Office 365 connecting to source email services 40 connecting to target email services 43 mail routing 19 preparing source email services 27 preparing target email services 28 provisioning 28 validating connections 49 P preparing source email services BPOS 25 Exchange 2000/2003 22 Exchange 2007/2010 23 Google Apps 20 GroupWise 21 Live@edu 26 Office 365 27 Sun ONE/iPlanet 20 preparing target email services Exchange 2010 29 Live@edu 30 Office 365 28 provisioning Exchange 2010 30 Live@edu 30 Office 365 28 Q Quest Software contact viii R running a migration 54 S Sun ONE/iPlanet connecting to source email services 37 preparing source email services 20 validating connections 44 V validating connections 43 Exchange 2000/2003 46 Exchange 2007/2010 47 Google Apps 43 GroupWise 45 Live@edu 49 Office 365 49 Sun ONE/iPlanet 44