Quest OnDemand Migration for User Guide

Transcription

1 Quest OnDemand Migration for User Guide

2 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 legal@quest.com Refer to our web site ( for regional and international office information. Trademarks Quest, Quest Software, the Quest Software logo, Simplicity at Work, and Quest OnDemand Migration for are trademarks and registered trademarks of Quest Software, Inc. For a complete list of Quest Software's trademarks, see Other trademarks are property of their respective owners.

3 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 Overview of The Migration Process Preparing a Migration Configuring and Running a Migration Post Migration Preparing for a Migration...11 Plan Your Migration Choose a Migration Type Mail Routing Deciding How to Configure Your Shared Address Space Source Service Initial Target Mail Hosts Create Target Mailboxes Prepare Your Source Service for Migration Google Apps Sun ONE/iPlanet Novell GroupWise Microsoft Exchange 2000/ Microsoft Exchange 2007/

4 iv Quest OnDemand Migration for User Guide Microsoft BPOS Microsoft 26 Microsoft Office Prepare Your Target Service for Migration Microsoft Office Microsoft Exchange Microsoft 30 Configuring and Running Migrations Creating a Migration Plan Migration Dashboard Copying Migration Plans Connecting to Services Connecting to the Source Service Google Apps Sun ONE/iPlanet Novell GroupWise Microsoft Exchange 2000/ Microsoft Exchange 2007/ Microsoft BPOS Microsoft Live@edu Microsoft Office Connecting to the Target Service Microsoft Office Microsoft Exchange Microsoft Live@edu Validating Connections Google Apps Sun ONE/iPlanet Novell GroupWise Microsoft Exchange 2000/ Microsoft Exchange 2007/ Microsoft Live@Edu Microsoft Office Importing Mailboxes... 50

5 Table of Contents v Selecting Migration Options...51 Known Limitations...53 General...53 GroupWise...53 Office Migrating...53 Running a Migration...54 Post Migration...55 Viewing Migration Reports...56 Notify and Train Users...56 Glossary...57 Index...59

6 vi Quest OnDemand Migration for User Guide

7 Preface Contents About This Guide About Quest Software, Inc. Contact Quest Software Contact Quest Support

8 viii Quest OnDemand Migration for User Guide About This Guide This guide provides detailed instructions on using Quest OnDemand Migration for to migrate mailbox items from one 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 This site provides robust search capabilities that allow you to search across all related documents, including release notes (also available at: 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 Contact Quest Software Phone Mail Web site (United States and Canada) info@quest.com Quest Software, Inc. World Headquarters 5 Polaris Way Aliso Viejo, CA USA Please refer to our web site for regional and international office information.

9 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 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 /support.quest.com/pdfs/global Support Guide.pdf.

10 x Quest OnDemand Migration for User Guide

11 Introduction Contents Welcome Overview of The Migration Process

12 12 Quest OnDemand Migration for User Guide Welcome OnDemand Migration for (ODME) securely migrates data to Office 365, on-premises Exchange or hosted Exchange 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 , calendar, contacts, and tasks. Overview of The Migration Process This chapter is designed to give new OnDemand Migration for 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 and include preparing your source and target services for a migration. 2 Configuring and Running a Migration These steps involve connecting to your source and target 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.

13 Introduction 13 The illustration below shows the stages of the migration process and the order in which each step should be performed.

14 14 Quest OnDemand Migration for User Guide Preparing a Migration Before running a migration with OnDemand Migration for , 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 service and (optionally) implement a mail routing strategy. Lastly, you should configure your source and target service to ensure that OnDemand Migration for 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 service. OnDemand Migration for 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 Service Configure your source and target services to allow OnDemand Migration for 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 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 Service Specify server locations and the administrator account credentials for both your source and target 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.

15 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 16 Quest OnDemand Migration for User Guide

17 Preparing for a Migration Contents Plan Your Migration Create Target Mailboxes Prepare Your Source Service for Migration Prepare Your Target Service for Migration

18 12 Quest OnDemand Migration for 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 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 traffic for your organization. To make the best decision for your organization, please review the Microsoft documentation associated with your target service: For Exchange 2010, click here. For Live@edu, click here. For Office 365, click here.

19 Preparing for a Migration 13 Source Service Refer to the sections below for mail routing instructions specific to your source 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 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 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

20 14 Quest OnDemand Migration for User Guide the send connector, also known as an SMTP connector, follow these steps (from 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: How to change SMTP port 25 to another port in Microsoft Exchange Server Click the Address Space tab.

21 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 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

22 16 Quest OnDemand Migration for 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 Sourc box -TargetSmtpAddress TargetUsername@ForwardingSubDomain Where: Sourc box 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 Connections screen.

23 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 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 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

24 18 Quest OnDemand Migration for 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 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 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

25 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 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 service is to create the target mailboxes they will be migrated to in the target service. OnDemand Migration for does not create them for you. The procedure for creating mailboxes varies

26 20 Quest OnDemand Migration for User Guide between systems, and you should refer to the documentation provided with your system for particular instructions. Prepare Your Source Service for Migration Quest OnDemand Migration for currently supports migrating content from the following services: Google Apps Sun ONE/iPlanet Novell GroupWise Microsoft Exchange 2000/2003 Microsoft Exchange 2007/2010 Microsoft BPOS Microsoft 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 uses IMAP to migrate messages and folders from your Sun ONE/iPlanet server to an Office 365 or 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

27 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 is migrated by OnDemand Migration for 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 supports migrations from Novell GroupWise and higher. Note When preparing your Novell Groupwise source 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.

28 22 Quest OnDemand Migration for 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: and In Europe, use the following IP addresses: and 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 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: exchange.

29 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 -

30 24 Quest OnDemand Migration for 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 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 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.

31 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 Click here for information on Exchange 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., 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-MSOnlin Permission 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

32 26 Quest OnDemand Migration for 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 service with corresponding accounts on the target 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 services, each administrator account you create on the source service must be paired with a corresponding account on the target service. For example, if you create 3 accounts on the source service but only 2 accounts on the target service, you will be able to migrate a total of 20 mailboxes from the source to the target 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 ( 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.

33 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 ( 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.

34 28 Quest OnDemand Migration for User Guide Prepare Your Target Service for Migration Before you do any migrations, you need to configure your target service. OnDemand Migration for currently supports migrating content to the following target services: Microsoft Office 365 Microsoft Exchange 2010 Microsoft 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 ( 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.

35 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 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 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

36 30 Quest OnDemand Migration for 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 Enabling Application Impersonation Rights To migrate data to 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 ( 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.

37 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.