Office 365 for IT Pros

Transcription

1

2 Office 365 for IT Pros Fourth edition Performing a Cutover migration to Exchange Online Published by Tony Redmond, Paul Cunningham, Michael Van Horenbeeck, and Ståle Hansen. Copyright by Tony Redmond, Paul Cunningham, Michael Van Horenbeeck, and Ståle Hansen. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means without the written permission of the authors. The example companies, organizations, products, domain names, addresses, logos, people, places and event depicted herein are fictitious. No association with any real company, organization, people, domain name, address, logo, person, place, or event is intended or should be inferred. The book expresses the views and opinions of the authors. The information presented in the book is provided without any express, statutory, or implied warranties. The authors cannot be held liable for any damages caused or alleged to be caused either directly or indirectly by this book. Although the authors are members of Microsoft s Most Valuable Professional (MVP) program, the content of this book solely represents their views and opinions about Office 365 and any other technologies mentioned in the text and is not endorsed in any way by Microsoft Corporation. Please be respectful of the rights of the authors and do not make copies of this ebook available to others. This information supplements the content presented Office 365 for IT Pros, available from

3 Contents Introduction... 4 Preparing for a Cutover Migration... 4 Adding Domain Names to Office Enabling Outlook Anywhere... 5 Configuring a Migration Service Account and Permissions... 7 Preparing Recipients... 7 Starting the Cutover Migration... 7 Creating the Migration Batch... 7 Monitor the Migration Progress... 8 Configuring Client Software and Devices Removing the Migration Batch Completing the Migration... 14

4 Introduction A cutover migration migrates all the existing mailboxes, contacts, and distribution groups (except for dynamic distribution groups) from an on-premises Exchange organization into Exchange Online. Cutover migrations do not include public folders. An overview of the cutover migration process, along with the pros and cons of this migration method, can be found in Chapter 7. Before you begin a cutover migration, read through the overview and the complete migration process so that you can understand the steps involved, any limitations, and to identify any areas in which a cutover migration might be unsuitable for your migration project. Preparing for a Cutover Migration Let s take a closer look at the steps for a cutover migration. The scenario used in this example is an Exchange 2007 on-premises organization called Not Real University. We'll begin with a demonstration of how to prepare the Office 365 tenant for a cutover migration. Adding Domain Names to Office 365 Naturally you need to sign up for an Office 365 tenant before you can perform a cutover migration. Set up the new tenant, and follow the steps to add the SMTP domains for your organization as accepted domains for the Office 365 organization as well. For example, here are the accepted domains for an Exchange 2007 on-premises organization retrieved by running the Get-AcceptedDomain cmdlet. [PS] C:\>Get-AcceptedDomain Name DomainName DomainType Default notrealuniversity.com notrealuniversity.com Authori... True Log in to the Office 365 administration portal and navigate to Settings and then Domains. Click the Add domain button to add your domains, as shown in Figure 1. Figure 1: Adding domains to Office 365 As you run the wizard to add a domain, the wizard will provide you with a domain validation record to add to your external DNS zone, which proves that you own the domain. As discussed in chapter 7, I recommend using the TXT record so that you do not cause any issues with your mail flow by adding an MX record at this stage. There's also the question of whether to host your DNS in Office 365, or to host and control your own DNS records separately (Figure 2). For most organizations that already have a public DNS zone and DNS hosting

5 provider, and who are comfortable making DNS changes themselves, the prospect of moving the zone to Office 365 offers no advantages. For the remainder of this example scenario it will be assumed that we'll be managing our own DNS records. Figure 2 Choosing DNS hosting for your domain. Microsoft then checks your domain for the DNS records that are needed for Office 365 services to work. For a new domain, or domain that you're already using with an on-premises, most if not all those DNS records won't exist in the zone. At this stage, do not make any changes to your DNS records. Instead, select the option to skip this step (Figure 3). Figure 3 Don't add any DNS records to your zone yet. Real World: Until the full list of required records is added to the DNS zone for your domain Office 365 will warn you that there are Possible service issues with your domain. You can ignore this warning until you ve completed adding all the DNS records later. Enabling Outlook Anywhere In this example, the on-premises Exchange 2007 server is already enabled for Outlook Anywhere using the hostname of mail.notrealuniversity.com, and a valid third-party SSL certificate is already installed on the server. [PS] C:\> Get-ClientAccessServer Format-List Name,OutlookAnywhereEnabled

6 Name : EX2007SRV OutlookAnywhereEnabled : True [PS] C:\>Get-OutlookAnywhere Format-List ServerName,ClientAuthenticatioNmethod,ExternalHostname ServerName : EX2007SRV ClientAuthenticationMethod : Ntlm ExternalHostname : mail.notrealuniversity.com To test the Exchange configuration, we can use the Exchange Remote Connectivity Analyzer to perform an Outlook Connectivity test (Figure 4). Figure 4: Microsoft Remote Connectivity Advisor This test will validate that both Autodiscover and Outlook Anywhere are working correctly for the on-premises organization, which is important for Office 365 to be able to detect and connect to your on-premises server during the migration process. It will also validate that the expected firewall ports are open and NATing to the Exchange server. Figure 5: A successful test with the Remote Connectivity Advisor Real World: It is common to see a Test Successful with Warnings result from the Remote Connectivity Analyzer due to the use of an SSL certificate that will require clients to have downloaded the root CA updates from Windows Update.

7 Configuring a Migration Service Account and Permissions For cutover migrations, the Office 365 migration service needs a set of user credentials to connect to your onpremises organization and access mailboxes. The steps for creating a migration service account are covered in Chapter 7. Preparing Recipients As discussed in Chapter 7, many preparation and review tasks are recommended for the recipients in your onpremises organization before beginning the migration: Reduce the migration load by reviewing large mailboxes, and large mailbox items Review shared mailboxes Review the sender authentication setting for mail-enabled groups Pre-provision a security group in Exchange Online for each mail-enabled security group that exists in the on-premises environment Clean up stale delegates and managers Disable Unified Messaging Starting the Cutover Migration With all the preparation tasks complete you can create the migration batch and begin the initial synchronization of mailbox contents. Creating the Migration Batch Log in to the Exchange Administration Center using your tenant administrator account and navigate to Recipients, and then Migration. Click the icon to create a new migration batch, selecting Migrate to Exchange Online (Figure 6). Figure 6: Create a new migration batch Select Cutover migration from the list of migration types. Enter the address of an on-premises mailbox user, and then the username and password for the migration service account you created earlier. Autodiscover will automatically detect the Outlook Anywhere settings to use. You can also click on More options and verify

8 that the mailbox permissions type is set to match the access type you granted to the service account earlier (Figure 7). Figure 7: Validating the mailbox permissions Give the migration batch a name. Since there is only one migration batch for a cutover migration you don t need to put much thought into a descriptive name. Finally, enter at least one recipient to receive reports for the migration batch. This can be a recipient in the on-premises Exchange organization or an external address if you choose (Figure 8). Figure 8: Nominating an account to receive the migration report Choose whether to start the batch manually or automatically (i.e., immediately) and click New to complete the wizard. The cutover migration batch has no impact on the end users while it is synchronizing mailbox contents, but you might want to wait for an evening or weekend before you start it if you have specific timing for the migration in mind. Monitor the Migration Progress You can monitor the progress of the migration by selecting the migration batch and clicking the link to View details (Figure 9).

9 Figure 9: Monitoring the migration batch job Be patient, as the initial provisioning can take several minutes, and the initial synchronization can take days or weeks depending on the amount of mailbox data to be migrated. You may notice that not all mailboxes are processed simultaneously. The limits for simultaneous processing vary, but you can expect 100 mailboxes to be processed at a time. Figure 10: Viewing details of the migration job If you do experience failures you may need to review your preparation steps again, such as verifying that there are no stale delegate or manager entries. At any stage, you can stop and then start the migration batch to allow it to retry a previously failed item. You can also check the progress of the migration batch in PowerShell. The first step is to connect a PowerShell session to Exchange Online, which can be achieved using a convenient PowerShell function such as Connect- EXOnline You can learn more about connecting to Exchange Online with PowerShell in Chapter 5. After connecting to Exchange Online with PowerShell run the following command to see the status of each mailbox being migrated.

10 [PS] C:\> Get-MigrationUser Get-MigrationUserStatistics Select identity,status,percentage* Format-Table AutoSize Continue to monitor the progress of the migration at regular intervals, or simply wait for the notification to arrive to let you know when initial synchronization has completed. If you look at the list of users in the Office 365 admin portal, or the list of mailboxes in the Exchange Administration Center, you will notice that it is populated with all of the users you are migrating to Office 365. At this stage the mailboxes are fully functional and users could login to services such as Outlook Web App, but new is not being delivered to those mailboxes until you change the MX records for the domain to point to Office 365. This gives you total control over when the final cutover will occur. In the meantime, your users should continue to connect to their on-premises mailboxes and use them as normal. When the initial synchronization is complete, you ll receive an notification to let you know the results (Figure 11). Now you can begin the final cutover tasks. These include: Changing MX records to point to Office 365 Configuring Autodiscover to point to Office 365 Running a final synchronization of mailboxes Figure 11: Results of a migration batch You will need to communicate this change to your end users and advise them of what they need to do (e.g., log out of Outlook for the cutover period) as well as any user experiences that will change (e.g., the Office 365 OWA interface looks very different to Exchange 2010 and earlier). Finally, you need to provide users with their login credentials for their new Office 365 accounts. Like anything to do with credentials, this should be done in a secure manner. Note: Providing users with their Office 365 credentials before the cutover time allows them to login to the Office 365 portal and set their password to one that they will remember. However, if you do this make sure you clearly communicate to your users that they should not use their Office 365 mailbox to send or receive yet. The scheduling of the cutover will really depend on the size and complexity of your business. Whether you choose to do it during a business day, one evening during the week, or over the weekend, if planning and communication is in good order the cutover should go well. Because multiple DNS changes are required to enable the switchover to Office 365, it is strongly recommended to review your existing DNS records first (Figure 12).

11 Figure 12: Reviewing DNS records The value for TTL (time to live) is important here. This indicates to DNS servers and clients how long they should cache the value of the DNS record. Until the TTL has expired a DNS server will continue to answer queries for your records with the old, cached value instead of the new value. In other words, the TTL is approximately how long you can expect to wait before a change to your Autodiscover or MX records takes effect, which means new will still deliver to your on-premises Exchange server for that period. Real World: A common approach is to lower the TTL value to something very short, such as 5 minutes (300 seconds). If this is done a day or two before the planned cutover time, then it improves the likelihood that the change to the Autodiscover and MX records will take effect much quicker. For details on the steps required to update MX and Autodiscover records in DNS, refer to Chapter 7. Configuring Client Software and Devices It s time to connect your end users to their new Office 365 mailboxes. Remember that the user accounts in Office 365 are separate to their on-premises Active Directory user accounts, and will have different passwords. You must distribute the passwords to your end users so that they can configure their software and devices to connect to their Office 365 mailboxes. For Outlook users, when a new profile is created Autodiscover will direct them to Exchange Online and they will be prompted to enter their Office 365 credentials. Ticking the box to remember the credentials will improve their user experience by not constantly re-prompting them for the credential with every new connection (Figure 13).

12 Figure 13: Entering credentials You can read more about configuring and managing clients and devices in Chapter 6. Removing the Migration Batch When the cutover migration is completed, you can remove the migration batch job. Before you remove the job, you should ensure that all your end users are able to connect to Office 365, or at least ensure that none of them have connected to the on-premises Exchange server since the last incremental synchronization occurred. One way to verify this is to use the Get-MailboxStatistics cmdlet in the Exchange Management Shell. For example: [PS] C:\> Get-MailboxStatistics select DisplayName,LastLogonTime,LastLoggedOnUserAccount Sort LastLogonTime The output (Figure 14) will show the last logon time for each mailbox, sorted in order of the last logon timestamp, and will also display the name of the user account that was responsible for the last logon. Figure 14: Viewing the output of Get-MailboxStatistics

13 In the example above you can see that Alan Reid has logged on to his mailbox more recently than the migration service account. This indicates that his Outlook or mobile device may still be configured to connect to the on-premises server. It may also mean that there are unsynchronized messages in his mailbox, for example new sent items that have not yet been copied to Office 365. That is an example of something that should be followed up before removing the migration batch. Another method to check that the migration batch can be removed is to check the last sync time for the mailboxes. You can check this in the Exchange Administration Center for Office 365 in the Recipients section under Migration. Review the last synced time for the migration batch (Figure 15) to confirm that at least one incremental synchronization has occurred since you changed the MX records to point to Office 365 and reconfigured all the end users Outlook profiles and mobile devices. Figure 15: Checking the status of a migration batch If you need to manually force another incremental synchronization click Resume (Figure 16). Figure 16: Resuming a migration batch job When you re ready to remove the migration batch, click Delete (Figure 17).

14 Figure 17: Removing the migration batch job Completing the Migration After the migration batch job has moved all the user mailboxes to Office 365, there are some further steps to complete the cutover migration project. Convert shared mailboxes Remove restrictions from distribution groups Assign licenses to Office 365 users Decommission on-premises servers