Office 365 Migration Performance & Server Requirements

Transcription

1 Solutions for the Modern Workforce Office 365 Migration Performance & Server Requirements Understanding Migration Performance There are many factors that can affect performance when migrating to Office 365, including upstream bandwidth, internal network factors, workstation speed, disk speed and available memory. The size of users mailboxes and the number of messages in them also affects performance. In order to get the best possible performance the first thing to ensure is that the migration servers and all connections to and from them are as fast as possible. When migrating to Office 365, performance is always limited by upstream bandwidth at the Microsoft datacenter where the 365 tenancy is located. CloudBearing uses the EWS API (Exchange Web Services) to interface to Exchange Online. Microsoft restricts the number of simultaneous connections and throttles the throughput. Usually the best way to obtain optimal performance, after making sure all local factors are as favorable as possible, is to migrate many users simultaneously. Migrating one user (if the rate is limited for that user) can often take as long as migrating ten users. It is therefore advisable to migrate as many users as possible simultaneously. The number of users that can be migrated simultaneously can be affected somewhat by local bandwidth restrictions. For example, if there is limited upstream bandwidth, then in this case it can make sense to limit the number of simultaneous users that are migrated. If bandwidth is high, then migrating many simultaneous users is highly recommended to achieve the best throughput. An upper limit of simultaneous users is suggested. With higher numbers performance can be adversely affected by CPU and memory usage.

2 To migrate more than 20 simultaneous users, we recommend setting up multiple migration servers, each processing many users. This way CPU and memory is only an issue per-server and very large numbers can be migrated at one time, providing bandwidth is high. The best way to determine performance for your site is to perform a pilot migration with a representative number of users and examine performance. Often a migration of just one user may be carried out to ensure that mails, appointments and contacts are migrated correctly, but this alone does not give a true indication of the performance that can be obtained from migrating many users simultaneously. When the performance from your site has been established, a full migration plan can be established. Migration Performance Factors FACTOR DESCRIPTION EXAMPLE DATA SOURCE DATA TYPE AND DENSITY The device or service that hosts the data to be migrated. Many limitations might apply to the data source because of hardware specifications, end-user workload, and back-end maintenance tasks. Because of the unique nature of a customer s business, the type and mix of mail items within mailboxes vary greatly. Google Mail limits how much data can be extracted during a specific period of time. One 4-GB mailbox with 400 items, each with 10 megabytes (MB) of attachments, will migrate faster than one 4-GB mailbox with 100,000 smaller items. SERVER Many migration solutions use a "jump box" type of migration server or workstation to complete the migration. Customers often use a low-performance virtual machine to host the MRSProxy for hybrid deployments or a client PC non-hybrid migrations. ENGINE The data migration engine that is responsible for pulling data from the source server converts data if necessary, transmits the data over the network, and injects the data into the Exchange Online mailbox. Microsoft Exchange Mailbox Replication Service (MRS) has its own capabilities and limitations. ON-PREMISES APPLICATIONS The end-to-end network performance from the data source to Exchange Online client access servers affects migration performance. Firewall configuration and specifications on the on-premises organization. OFFICE 365 SERVICE Office 365 has built-in support and features to manage the migration workload. The user throttling policy has default settings and limits the overall maximum data transfer rate.

3 FACTOR DESCRIPTION EXAMPLE CAPACITY The amount of time it takes to migrate mailboxes to Exchange Online is determined by the available and maximum capacity of your network. Identify your available network capacity and determine the maximum upload capacity. Contact your ISP to confirm your allocated bandwidth and get details about restrictions, such as the total amount of data that can be transferred in a specific period of time. Use tools to evaluate your actual network capacity. Make sure you test the end-to-end flow of data, from your on-premises data source to the Microsoft data center gateway servers. Identify other loads on your network (for example, backup utilities and scheduled maintenance) that can affect your network capacity. STABILITY A fast network doesn t always result in fast migrations. If the network isn t stable, data transfer takes longer because of error correction. Depending on the migration type, error correction can significantly affect migration performance. Network hardware and driver issues often cause network stability problems. Work with your hardware vendors to understand your network devices and apply the vendor s latest recommended drivers and software updates. DELAYS Intrusion detection functionality configured on a network firewall often causes significant network delays and affects migration performance. Migrating data to Exchange Online mailboxes relies on your Internet connection. Internet delays affect overall migration performance. Also, users in the same company might have cloud mailboxes that reside in data centers in different geographical locations. Depending on the customer's ISP, there might be varying migration performance. Evaluate network delays to all potential Microsoft data centers to help ensure that the result is consistent. (This also helps ensure a consistent experience for end users). Work with your ISP to address Internet-related issues. Add IP addresses for Microsoft data center servers to your allow list, or bypass all migration-related traffic from you network firewall. For more information about the Office 365 IP ranges, see Office 365 URLs and IP address ranges. Evaluating Network Performance The Office 365 Network Analysis Tool is deployed to help analyze network-related issues prior to deploying Office 365 services. North America: EMEA: APAC:

4 Network Performance Factors Performance by Migration Method METHOD OFFICE 365 USER THROTTLING OFFICE SERVICE THROTTLING OFFICE 365 RESOURCE HEALTH-BASED THROTTLING OBSERVED AVERAGE THROUGHOUT PER HOUR AND PER CLIENT (IF APPLICABLE) IMAP GB (100 concurrency) CUTOVER GB (100 concurrency) STAGED GB (100 concurrency) HYBRID GB per onpremises Exchange 2013 or 2010 CAS (MRS Proxy) with 20 concurrent moves* THIRD PARTY MAPI 4-12 GB (20 concurrency)*** 3RD PARTY EWS 5-10 GB (20 concurrency)**

5 CLIENT UPLOADING (FROM OUTLOOK PST) 0.5 GB * Observed single mailbox move throughput is in the GB/hour range. More concurrent mailbox migrations can be used to achieve higher data migration rates. For example, with 50 concurrent moves, the overall throughput will be in the GB/hour range. Single mailbox move throughput will slow down when the on-premises CAS (MRSProxy) server is at hardware capacity. Consider adding more servers to increase migration velocity. ** Observed single EWS migration throughput is in the GB/hour range. More concurrent migrations can be used to achieve higher data migration rates. For example, with 100 concurrent migrations, the overall throughput will be in the GB/hour range. Single EWS migration throughput will slow down when on-premises servers or the network is at capacity. *** Observed single MAPI migration throughput is in the GB/hour range. More concurrent migrations can be used to achieve higher data migration rates. Single MAPI migration throughput will slow down when on-premises servers or the network is at capacity. Migration Server Requirements Server Specifications Windows 2008 R2 Standard or 2012/R2 Standard 2.0Ghz or higher Intel Core 2 (Dual Processor) 4 GB RAM or Higher 100 GB Disk Space Determining the Number of Migrations Servers and Time Migration Time Window Amount of Mail Data Migration Performance Factors* Network Capacity* Use the following formula to ballpark initial migration window: Time = Source Size / Servers (Migration Throughput x Concurrent Migrations) Migration Throughput for Third Party EWS Migrations expect.2-.5gb/hour Concurrent Migrations range from mailboxes per migration server Office 365 Tenant Requirements address and password of a Global Administrator Enable Application Impersonation Role Server Software Microsoft.NET Framework version 3.5/4.5 PowerShell 2.0/ Antivirus Exclusions needed at a minimum, recommended AV to be disabled during migration -Ensure ports 80 and 443 are unfiltered -Ensure the process "*ExportWorker.exe" (should be exchangeexportworker.exe but may have an alternate name) is not scanned -Ensure the process "*ImportWorker.exe" (should be exchangeimportworker.exe but may have an alternate name) is not scanned Sample Run Times due to multiple variables, you can see from a run of three concurrent migration servers running just over 1100 mailboxes the data throughputs can vary: Three Migration Servers: 1) Migration Server One: a. 481 mailboxes b. 108GB Exported and 104GB Imported (4GB of content which was either corrupt or over the 35MB message limit) c. Total Time: 2 days 20 hours 16 minutes 2) Migration Server Two: a. 495 Mailboxes (366 users failed with no destination mailbox or invalid credentials to source mailbox) b. 40GB Exported and 40GB Imported c. Total Time: 20 hours 15 minutes 3) Migration Server Three: a. 308 mailboxes (114 users failed with no destination mailbox or invalid credentials to source mailbox) b. 128GB Exported and 128GB Imported c. Total Time: 3 days 10 hours and 4 minutes

6 CloudBearing Observations When Migrating from GroupWise to Office 365 1) Before any migration, first run GWCHECK and verify the two tests listed below. This will help ensure any problematic mailboxes are able to migrate smoothly. a. Analyze/Fix Databases b. Structural Rebuild c. More information on this tool can be found: 2) For Linux based GroupWise installs, use the Domain Path versus the Domain DN during the migration. a. Also ensure the user for migration has access to the WPHOST.DB domain path location. 3) Ensure the correct language is specified for the Client on the Migration workstation (i.e.: English) to ensure contact details will migrate. When Migrating from Lotus Notes to Office 365 1) It is recommended to perform a cut over migration due to complexity of bulk forwarding addresses in Lotus Notes 2) Lotus Notes Administrator should have full access to all mailboxes. This will prevent any issues when exporting mail from a user s mailbox. 3) It s recommended to manually import contacts into Office 365 by exporting them from Lotus Notes and then importing them using Outlook once the user has been migrated. 4) Users must sync their local contacts and calendar to the Lotus Notes server prior to being migrated so that their contacts and calendar are migrated with the mailbox. 5) Encrypted mailboxes and archives should be decrypted by users before migration When Migrating from Google Apps to Office 365 Google API throttle restriction occur when going beyond 200 concurrent mailbox migrations. Further information on Google Apps Settings API Limits and Quotas can be found in the More Information section. Google may lock your account for 24 hours if they consider that too much data has been retrieved from their servers in a given amount of time. Also, Google Apps imposes a hard limit of 1 item per second when migrating from Google Apps. When migrated from Google Apps to Office 365, labels in Gmail are translated into Folders in Office 365 More Information on Migration Performance *See Migration Factors Section *Network Capacity Section