-->
- Exchange 365 Whitelist
- Exchange 365
- Exchange 365 Powershell
- Office Exchange 365 Login
- Exchange 365 Credit Card Search
- Exchange 365 Admin Portal
- Exchange Server is only a mail server and calendaring server. Even user can get Exchange server as a part of an Office 365 plan. When user deploy Exchange account, email messages are delivered and saved in Exchange Server mailbox.
- The Exchange Online PowerShell V2 module (abbreviated as the EXO V2 module) uses modern authentication and works with multi-factor authentication (MFA) for connecting to all Exchange-related PowerShell environments in Microsoft 365: Exchange Online PowerShell, Security & Compliance PowerShell, and standalone Exchange Online Protection (EOP) PowerShell.
- In the Microsoft 365 or Office 365 service, unlike in on-premises Exchange 2010, the migration queue and the service resources allocated for migrations are shared among tenants. This sharing affects how move requests are handled in each stage of the move process. There are two types of move requests in Microsoft 365 and Office 365.
Important
The improved Microsoft 365 security center is now available. This new experience brings Defender for Endpoint, Defender for Office 365, Microsoft 365 Defender, and more into the Microsoft 365 security center. Learn what's new.
Hosted Exchange 2016 and Office 365 Provider mindSHIFT Online offers Microsoft Exchange hosting, Office 365, Dedicated & Shared Exchange Server 2013, hosted email, and SharePoint Hosting. Enterprise, Business, and Individual plans all to meet your needs. Dec 04, 2018 Office 365 mailbox may have multiple SMTP addresses and receive mail sent to any of the secondary addresses but Exchange Online always uses the primary SMTP address for sending messages. ChooseFrom 365 application allows Office 365 users to send a message with any of their own SMTP addresses as the From address.
Applies to
Exchange Online Protection (EOP) is the cloud-based filtering service that helps protect your organization against spam and malware. EOP is included in all Microsoft 365 organizations with Exchange Online mailboxes. However, EOP is also available in the following on-premises scenarios:
In a standalone scenario: EOP provides cloud-based email protection for your on-premises Exchange organization or for any other on-premises SMTP email solution.
In a hybrid deployment: EOP can be configured to protect your email environment and control mail routing when you have a mix of on-premises and cloud mailboxes.
In these scenarios, EOP can simplify the management of your email environment and alleviate many of the burdens that come with maintaining on-premises hardware and software.
The rest of this topic explains how EOP works in standalone and hybrid environments.
How EOP works
To understand how EOP works, it helps to see how it processes incoming email:
When an incoming message enters EOP, it initially passes through connection filtering, which checks the sender's reputation. The majority of spam is stopped at this point and rejected by EOP. For more information, see Configure connection filtering.
Then the message is inspected for signs of malware. If malware is found in the message or the attachment(s) the message is routed to an admin only quarantine store. You can learn more about configuring anti-malware here.
Messages continue through policy filtering, where they are evaluated against custom mail flow rules (also known as transport rules) that you create or enforce from a template. For example, you can have a rule that sends a notification to a manager when mail arrives from a specific sender. Data loss prevention (DLP) checks also happen at this point (Exchange Enterprise CAL with Services).
Next, the message passes through content filtering (also known as Anti-spam). A message that this filter determines to be spam or phish can be sent to quarantine, or a user's Junk Email folder, among other options. For more information see Configure anti-spam policies and Configure anti-phishing policies.
Any message that passes all of these protection layers successfully is delivered to the recipient.
For more information, see Order and precedence of email protection.
EOP plans and features for on-premises email organizations
The available EOP subscription plans are:
EOP standalone: You enroll in EOP to protect your on-premises email organization.
EOP features in Exchange Online: Any subscription that includes Exchange Online (standalone or as part of Microsoft 365) uses EOP to protect your Exchange Online mailboxes.
Exchange Enterprise CAL with Services: If you have an on-premises Exchange organization where you've purchased additional Exchange Enterprise CAL with Services licenses, EOP is part of the included services.
For information about requirements, important limits, and feature availability across all EOP subscription plans, see the Exchange Online Protection service description.
Note
If you have an Office 365 E3 subscription it includes EOP. For steps to set up EOP security feature in your subscription, and information on the added security a Microsoft Defender for Office 365 subscription can give you, see protect against threats. The recommended settings for EOP feature for setup can be found in the Recommendations article, where EOP settings are specifically called out.
Setting up EOP for on-premises email organizations
Setting up EOP can be simple, especially in the case of a small organization with a handful of compliance rules. However, if you have a large organization with multiple domains, custom compliance rules, or hybrid mail flow, set up can take more planning and time.
If you've already purchased EOP, see Set up your EOP service to ensure that you complete all the steps necessary to configure EOP to protect your messaging environment.
EOP datacenters
EOP runs on a worldwide network of datacenters that are designed to provide the best availability. For example, if a datacenter becomes unavailable, email messages are automatically routed to another datacenter without any interruption in service. Servers in each datacenter accept messages on your behalf, providing a layer of separation between your organization and the internet, thereby reducing load on your servers. Through this highly available network, Microsoft can ensure that email reaches your organization in a timely manner.
EOP performs load balancing between datacenters but only within a region. If you're provisioned in one region all your messages will be processed using the mail routing for that region. The following list shows the how regional mail routing works for the EOP datacenters:
In Europe, the Middle East, and Africa (EMEA), all Exchange Online mailboxes are located in EMEA datacenters, and all messages are routed through EMEA datacenters for EOP filtering.
In Asia-Pacific (APAC), all Exchange Online mailboxes are located in APAC datacenters, and messages are currently routed through APAC datacenters for EOP filtering.
In the Americas, services are distributed in the following locations:
South America: Exchange Online mailboxes are located in datacenters in Brazil and Chile. All messages are routed through local datacenters for EOP filtering. Quarantined messages are stored in the datacenter where the tenant is located.
Canada: Exchange Online mailboxes are located in datacenters in Canada. All messages are routed through local datacenters for EOP filtering. Quarantined messages are stored in the datacenter where the tenant is located.
United States: Exchange Online mailboxes are located in U.S. datacenters. All messages are routed through local datacenters for EOP filtering. Quarantined messages are stored in the datacenter where the tenant is located.
For the Government Community Cloud (GCC), all Exchange Online mailboxes are located in U.S. datacenters and all messages are routed through U.S. datacenters for EOP filtering.
EOP Help for admins
The Help content for EOP administrators consists of the following top-level categories:
Configure EOP, Day 1, for Microsoft Defender for Office 365 admins: Configuring EOP protection and detection tools at the core of Microsoft Defender for Office 365.
EOP features: Provides a list of features that are available in EOP.
Set up your EOP service: Provides steps for setting up your EOP service, and links to additional information.
Switch to EOP from Google Postini, the Barracuda Spam and Virus Firewall, or Cisco IronPort: Describes the process for switching to EOP from another email protection product.
Manage recipients in standalone EOP: Describes how to manage mail users and groups in EOP.
Mail flow in EOP: Describes how to configure custom mail flow scenarios using connectors, how to manage domains associated with the service, and how to enable the Directory Based Edge Blocking (DBEB) feature.
Best practices for configuring EOP: Describes recommended configuration settings and considerations for after you set up and provision your service.
Auditing reports in standalone EOP: Describes how to use auditing reports to track configuration changes to the service.
Anti-spam and anti-malware protection in EOP: Describes spam filtering and malware filtering and shows how to customize them to best meet the needs of your organization. Also describes tasks that administrators and end users can perform on quarantined messages.
Reporting and message trace in Exchange Online Protection: Describes the reports and troubleshooting tools that are available.
Exchange admin center in standalone EOP: Describes how to access and navigate through the Exchange admin center (EAC) management interface in order to manage your EOP service.
Exchange Online Protection PowerShell: Provides information about remote PowerShell, which lets you manage your EOP service from the command line.
Help and support for EOP Provides information about obtaining help and technical support.
There are many paths to migrate data from an on-premises email organization to Microsoft 365 or Office 365. When planning a migration to Microsoft 365 or Office 365, a common question is about how to improve the performance of data migration and optimize migration velocity.
Note
The performance information listed in this topic doesn't apply to Microsoft 365 or Office 365 service for dedicated subscription plans. For more information about Dedicated Plans, see Microsoft 365 and Office 365 Dedicated Plans Service Descriptions.
Overview of migrating email to Microsoft 365 or Office 365
Microsoft 365 or Office 365 supports several methods to migrate email, calendar, and contact data from your existing messaging environment to Microsoft 365 or Office 365 as described in Ways to migrate multiple email accounts to Microsoft 365 or Office 365.
For more information about Microsoft 365 or Office 365 networking and performance, see Network planning and performance tuning for Microsoft 365 or Office 365.
Frequently used migration methods
| Migration method | Description | Resources |
|---|---|---|
| Internet Message Access Protocol (IMAP) migration | You can use the Exchange admin center or Exchange Online PowerShell to migrate the contents of users' mailboxes from an IMAP messaging system to their Microsoft 365 or Office 365 mailboxes. This includes migrating your mailboxes from other hosted email services, such as Gmail or Yahoo Mail. | Migrate your IMAP mailboxes to Microsoft 365 or Office 365 |
| Cutover migration | Using a cutover migration, you migrate all on-premises mailboxes to Microsoft 365 or Office 365 over a few days. Use cutover migration if you plan to move your entire email organization to Microsoft 365 or Office 365 and manage user accounts in Microsoft 365 or Office 365. You can migrate a maximum of 2,000 mailboxes from your on-premises Exchange organization to Microsoft 365 or Office 365 using a cutover migration. The recommended number of mailboxes, however, is 150. Performance suffers with numbers higher than that. The mail contacts and distribution groups in your on-premises Exchange organization are also migrated. | Cutover migration to Microsoft 365 or Office 365 |
| Staged migration | You use a staged migration if you plan to eventually migrate all your organization's mailboxes to Microsoft 365 or Office 365. Using a staged migration, you migrate batches of on-premises mailboxes to Microsoft 365 or Office 365 over the course of a few weeks or months. | What you need to know about a staged email migration to Microsoft 365 or Office 365 |
| Hybrid deployment | A hybrid deployment offers organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Exchange organization to the cloud. A hybrid deployment provides the seamless look and feel of a single Exchange organization between an on-premises Exchange organization and Exchange Online in Microsoft 365 or Office 365. In addition, a hybrid deployment can serve as an intermediate step to moving completely to a Microsoft 365 or Office 365 organization. | Mail migration advisor Exchange Deployment Assistant for Exchange on-premises 2013/2016/2019 Exchange Server 2013 hybrid deployments Minimal Hybrid Configuration |
| Third-party migration | There are many tools available from third parties. They use distinctive protocols and approaches to conduct email migrations from email platforms like IBM Lotus Notes and Novell GroupWise. | Here are some third-party migration tools and partners that can assist with Exchange migrations from third-party platforms: Binary Tree: Provider of cross-platform messaging migration and coexistence software, with products that provide for the analysis of and the coexistence and migration between on-premises and online enterprise messaging and collaboration environments based on IBM Lotus Notes and Domino and Exchange and SharePoint. BitTitan: Provider of migration solutions to Microsoft 365 or Office 365. CodeTwo: Provider of Microsoft 365 and Office 365 migration solutions. Migrate mailboxes and public folders from any on-premises Exchange and email from IMAP (Gmail, IBM Notes, etc.) to the cloud or perform tenant to tenant migrations. Transfer all data at once or in batches and automate the entire migration process, with zero downtime. Quadrotech: Provider of migration solutions to Microsoft 365 or Office 365. Quest: Provider of migration solutions from Exchange, Microsoft 365, Office 365, Gmail, GroupWise, Notes, POP/IMAP, Zimbra, Sun ONE/iPlanet, PSTs and email archives to Microsoft 365 or Office 365 and Exchange. Quest solutions synchronize mailboxes, public folders and calendar information while maintaining coexistence throughout the migration. Transvault: Provider of Cloud Office migration solutions to Microsoft 365 from Exchange and Notes. Transvault supports 23 different sources for migration and has products which deliver any size of project, complex email archive migrations and PST management. The enterprise migration solutions are secure, compliant, efficient and user-focused, and can be run both on-premises and in the Cloud. SkyKick: Provider of automated migration solutions to move on-premises Exchange, Gmail, POP3, IMAP, Lotus Notes to Microsoft 365 or Office 365. The end-to-end migration tools help partners with the sales, planning, migration, management, and onsite phases of the migration project. BCC Collaboration Company: Helping companies by supporting their collaboration migration strategy. Best in class supplier of migration tools based on Domino platform, for migrating to Microsoft Exchange, Microsoft 365, and Office 365. |
Performance for migration methods
The following sections compare mailbox migration workloads and the observed performance results for the different migration methods for migrating mailboxes and mailbox data to Microsoft 365 or Office 365. These results are based on internal testing and actual customer migrations to Microsoft 365 or Office 365.
Important
Because of differences in how migrations are performed and when they're performed, your actual migration velocity may vary.
Customer migration workloads
The following table describes the different workloads involved in a typical migration, and the challenges and options for each.
| Workload | Notes |
|---|---|
| Onboarding (Migrating to Microsoft 365 or Office 365) | Microsoft offers data migration capability and tools for customers to use to migrate their data from Exchange Server on-premises to Exchange Online in Microsoft 365 or Office 365. There are a number of methods for migrating mailboxes and mailbox data, starting with Cutover migrations and Staged migrations, which are based on merge and sync moves, and which are described earlier in this article. The other main migration method involves hybrid moves, which is currently the most common method. You can decide exactly when you'd like to migrate to Microsoft 365, based on your business needs. |
| Multi-Geo | Multinational companies with offices around the world often have a need to store their employee data at-rest in specific regions, in order to meet their data residency requirements. Multi-Geo enables a single Microsoft 365 or Office 365 organization to span across multiple Microsoft 365 or Office 365 datacenter geographies (geos), which gives you the ability to store Exchange data, at-rest, on a per-user basis, in your chosen geos. For more details, see Get enterprise-grade global data location controls with Multi-Geo. |
| Encryption | Service Encryption with Customer Key is a feature that allows a customer to provision and manage the root keys that are used to encrypt data at-rest at the application layer in Microsoft 365 or Office 365. For a mailbox to become encrypted the first time, a mailbox move is required. For more details, see Service encryption with Customer Key. |
| GoLocal | Microsoft continues to open new datacenters in new regions, or geos. Existing customers, when eligible, can request to have their customer data from their original datacenter moved to a new geo. The period of time in which you can make this request is usually one or two years, depending on the overall demand on the service. Note that this period of time during which you can request to have your customer data moved becomes shorter once a datacenter (DC) for the new geo launches (at that point you have approximately three to six months to request a move). Details are available in Moving core data to new Microsoft 365 datacenter geos. |
When mailboxes are migrated within Microsoft 365 data centers, every mailbox move or bulk-mailbox move requires time for the operation to complete. There are a number of factors, such as Microsoft 365 service activity, that can affect exactly how much time. The service is designed to throttle discretionary workloads like mailbox moves, to ensure that the service runs optimally for all users. You can still expect mailbox moves to be processed, however, depending on the service's discretionary resource availability. More details about resource throttling can be found in this blog post.
Estimated migration times
Exchange 365 Whitelist
To help you plan your migration, the following tables present guidelines about when to expect bulk mailbox migrations or individual migrations to complete. These estimates are based on a data analysis of previous customer migrations. Because every environment is unique, your exact migration velocity may vary.
Mailbox migration duration based on mailbox size profiles:
- Onboarding / PSTImport
| Mailbox size (GB) | 50th percentile duration (days) | 90th percentile duration (days) |
|---|---|---|
| < 1 | 1 | 7 |
| 1 - 10 | 1 | 7 |
| 10 - 50 | 3 | 14 |
| 50 - 100 | 3 | 30 |
| 100 - 200 | 8 | 45 |
| > 200 | Not supported | Not supported |
- Multi-Geo / GoLocal / Encryption
| Mailbox size (GB) | 50th percentile duration (days) | 90th percentile duration (days) |
|---|---|---|
| < 1 | 1 | 7 |
| 1 - 10 | 1 | 10 |
| 10 - 50 | 3 | 30 |
| 50 - 100 | 15 | 45 |
| 100 - 200 | 30 | 60 |
| > 200 | Not supported | Not supported |
Migration duration to complete 90% of mailbox moves based on tenant size profiles:
| Tenant size (number of mailboxes) | Duration (days) | May take up to this many days |
|---|---|---|
| < 1,000 | 5 | 14 |
| 1,000 - 5,000 | 10 | 30 |
| 5,000 - 10,000 | 20 | 45 |
| 10,000 - 50,000 | 30 | 60 |
| 50,000 - 100,000 | 45 | 90 |
| > 1000,000 | 60 | 180 |
Note
Some outlier mailboxes would take longer to complete based on the mailbox profile. Also, if a tenant has larger mailboxes on average, this can also contribute to the extended duration of migration.
Migration performance factors
Email migration has several common factors that can affect migration performance.
Common migration performance factors
The following table provides a list of common factors that affect migration performance. More details are covered in the sections describing the individual migration methods.
Exchange 365
| Factor | Description | Example |
|---|---|---|
| Data source | 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. | Gmail limits how much data can be extracted during a specific period of time. |
| Data type and density | Because of the unique nature of a customer's business, the type and mix of mail items within mailboxes vary greatly. | 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. |
| Migration 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 service for hybrid deployments or for client PC non-hybrid migrations. |
| Migration engine | The data migration engine responsible for pulling data from the source server converts data, if necessary. The engine then transmits the data over the network and injects the data into the Microsoft 365 or Office 365 mailbox. mailbox. | MRSProxy service has its own capabilities and limitations. |
| On-premises network appliances | 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. |
| Microsoft 365 or Office 365 service | Microsoft 365 and Office 365 have 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. |
Network performance factors
This section describes best practices for improving network performance during migration. The discussion is general because the biggest impact on network performance during migration is related to third-party hardware and Internet service providers (ISPs).
Use the Exchange Analyzer to get a deeper understanding of your network connectivity with Microsoft 365 or Office 365. To run the Exchange Analyzer tests in Support and Recovery Assistant, go to Advanced Diagnostics > Exchange Online > Check Exchange Online network connectivity > Yes. Read About the Microsoft Support and Recovery Assistant to learn more about Support and Recovery Assistant.
| Factor | Description | Best practices |
|---|---|---|
| Network capacity | The amount of time it takes to migrate mailboxes to Microsoft 365 or Office 365 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 to 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 datacenter gateway servers. Identify other loads on your network (for example, backup utilities and scheduled maintenance) that can affect your network capacity. |
| Network 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. |
| Network delays | Intrusion detection functionality configured on a network firewall often causes significant network delays and affects migration performance. Migrating data to Microsoft 365 or Office 365 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 datacenters in different geographical locations. Depending on the customer's ISP, migration performance may vary. | Evaluate network delays to all potential Microsoft datacenters 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 datacenter servers to your allow list, or bypass all migration-related traffic from your network firewall. For more information about the Microsoft 365 or Office 365 IP ranges, see Microsoft 365 and Office 365 URLs and IP address ranges. |
Exchange 365 Powershell
For a deeper analysis of migrations within your environment, check out our move analysis blog post. The post includes a script to help you analyze move requests.
Microsoft 365 and Office 365 throttling
Microsoft 365 and Office 365 use various throttling mechanisms to help ensure security and service availability. The following three types of throttling can affect migration performance:
- User throttling
- Migration-service throttling
- Resource health-based throttling
Note
The three types of Microsoft 365 and Office 365 throttling don't affect all migration methods.
Microsoft 365 and Office 365 user throttling
User throttling affects most third-party migration tools and the client-uploading migration method. These migration methods use client access protocols, such as the Remote Procedure Call (RPC) over HTTP Protocol, to migrate mailbox data to Microsoft 365 or Office 365 mailboxes. These tools are used to migrate data from platforms such as IBM Lotus Domino and Novell GroupWise.
User throttling is the most restrictive throttling method in Microsoft 365 and Office 365. Because user throttling is set up to work against an individual end user, any application-level usage will easily exceed the throttling policy and result in slower data migration.
Microsoft 365 and Office 365 migration-service throttling
Migration-service throttling affects all Microsoft 365 or Office 365 migration tools. Migration-service throttling manages migration concurrency and service resource allocation for Microsoft 365 or Office 365 migration solutions.
Migration-service throttling affects migrations performed by using the following migration methods:
- IMAP migration
- Cutover Exchange migration
- Staged Exchange migration
- Hybrid migrations (MRSProxy service-based moves in a hybrid environment)
Important
The aforementioned migration methods are not affected by user throttling.
An example of migration-service throttling is controlling the number of mailboxes that are migrated simultaneously during simple Exchange migrations and IMAP migrations. The default value is 10. This means that a maximum of 10 mailboxes from all migration batches are migrated at any particular time. You can increase the number of concurrent mailbox migrations for a migration batch in either the Exchange Control Panel or Windows PowerShell. To learn more about how to optimize this setting, see Manage migration batches in Microsoft 365 or Office 365.
Microsoft 365 or Office 365 resource health-based throttling
All migration methods are subject to the governance of availability throttling. Microsoft 365 or Office 365 service throttling, however, doesn't affect Microsoft 365 or Office 365 migrations as much as the other types of throttling described previously.
Resource health-based throttling is the least aggressive throttling method. It occurs to prevent a service availability issue that could affect end users and critical service operations.
Before performance of the service degrades to the point where end-user performance could be impacted, hybrid migrations will be stalled until performance is recovered and the service returns to a level below the throttling threshold.
The following are examples from an Exchange migration statistics report. They show the entries logged when the service-throttling threshold is exceeded.
Solution and practice:
If you experience a similar situation, wait for the Microsoft 365 or Office 365 resources to become available.
Performance factors and best practices for non-hybrid deployment migrations
This section describes factors that affect migrations using the IMAP, cutover, or staged migration methods. It also identifies best practices to improve migration performance.
Factor 1: Data source
The following table describes the impact on migration by the source servers in your current email organization and the best practices for mitigating the impact on migration.
| Checklist | Description | Best practices |
|---|---|---|
| System performance | Data extraction is an intensive task. The source system needs to have sufficient resources, such as CPU time and memory, to provide optimal migration performance. During migration, the source system is often close to full capacity in terms of the regular end-user workload. If system resources are inadequate, the additional workload that results from migration can affect end users. | Monitor system performance during a pilot migration test. If the system is busy, we recommend avoiding an aggressive migration schedule for the specific system because of potential migration slowness and service availability issues. If possible, enhance the source system performance by adding hardware resources and reduce the load on the system by moving tasks and users to other servers that aren't involved in the migration. For more information, see: • Exchange 2013 Server Health and Performance • Understanding Exchange 2010 Performance • Exchange 2007: Monitoring Mailbox Servers When migrating from an on-premises Exchange organization where there are multiple mailbox servers, we recommend that you create a migration-user list that is evenly distributed across multiple mailbox servers. Based on individual server performance, the list can be further fine-tuned to maximize throughput. For example, if server A has 50 percent more resource availability than server B, it's reasonable to have 50 percent more users from server A in the same migration batch. Similar practices can be applied to other source systems. Perform migrations when servers have maximum resource availability such as after hours or on weekends and holidays. |
| Back-end tasks | Other back-end tasks that are running during migration time. Because it's a best practice to perform migration after business hours, it's common that migrations conflict with maintenance tasks (such as data backup) running on your on-premises servers. | Review other system tasks that might be running during migration. We recommend that you perform data migration when no other resource-intensive tasks are running. Note: For customers using on-premises Exchange, the common back-end tasks are backup solutions and Exchange store maintenance. |
| Throttling policy | It's a common practice to protect email systems with a throttling policy that sets a specific limit on how fast and how much data can be extracted from the system during a certain amount of time. | Verify what throttling policy is deployed for your email system. For example, Google Mail limits how much data can be extracted in a certain time period. Depending on the version, Exchange has policies that restrict IMAP access to the on-premises mail server (used by IMAP migrations) and RPC over HTTP Protocol access (used by cutover Exchange migrations and staged Exchange migrations). To check the throttling settings in an Exchange 2013 organization, run the Get-ThrottlingPolicy cmdlet. For more information, see Exchange Workload Management. For more information about IMAP throttling, see Migrate your IMAP mailboxes to Microsoft 365 or Office 365 For more information about RPC over HTTP Protocol throttling, see: • Exchange 2013 Workload Management • Exchange 2010: Understanding Client Throttling Policies • Exchange 2007: Understanding Client Throttling |
Factor 2: Migration server
IMAP, cutover, and staged migrations are cloud-initiated and 'In Progress'
Queued move requests: This status specifies that the move has been queued and is waiting to be picked up by the Exchange Mailbox Replication Service. For Exchange 2003 move requests, users can still access their mailboxes at this stage.
Two factors influence which request will be picked up by the Mailbox Replication Service:
Priority: Queued move requests with a higher priority are picked up before lower-priority move requests. This helps ensure that customer-migration move requests always get processed before datacenter internal move requests.
Position in the queue: If move requests have the same priority, the earlier the request gets into the queue, the earlier it will be picked up by the Mailbox Replication Service. Because there might be multiple customers performing mailbox migrations at the same time, it's normal that new move requests remain in the queue before they're processed.
Often, the time that mailbox requests wait in the queue before being processed isn't considered during migration planning. This results in customers not being allocated enough time to complete all planned migrations.
- In-progress move requests: This status specifies that the move is still in progress. If this is an online mailbox move, the user will still be able to access the mailbox. For offline mailbox moves, the user's mailbox will be unavailable.
After the mailbox move request has a status of 'In Progress,' the priority no longer matters and a new move request won't be processed until an existing 'In Progress' move request is completed, even if the new move request has a higher priority.
Best practices
Planning: As previously mentioned, because Exchange 2003 users lose access during a hybrid migration, Exchange 2003 customers are usually more concerned about when to schedule migrations and how long they will take.
When planning how many mailboxes to migrate during a specific time period, consider the following:
Include the amount of time the move request waits in the queue. Use the following to calculate this:
(total number of mailboxes to migrate) = ((total time) - (average queue time)) * (migration throughput)
where the migration throughput equals the total number of mailboxes that can be migrated per hour.
Office Exchange 365 Login
For example, assume you have a six-hour window to migrate mailboxes. If the average queue time is one hour and you have a migration throughput of 100 mailboxes per hour, you can migrate 500 mailboxes in the six-hour time frame: 500 = (6 - 1) * 100.
- Start the migration sooner than initially planned to mitigate time in the queue. When mailboxes are queued, Exchange 2003 users can still access their mailboxes.
Determine queue time: The queue time is always changing because Microsoft doesn't manage customers' migration schedules.
To determine the potential queue time, a customer can try to schedule a test move several hours before the actual migration starts. Then, based on the observed amount of time the request is in the queue, the customer can better estimate when to start the migration and how many mailboxes can be moved in a specific period of time.
Exchange 365 Credit Card Search
For example, if a test migration was completed four hours before the start of a planned migration. The customer determines the queue time for the test migration was about one hour. Then, the customer should consider starting the migration one hour earlier than originally planned to make sure there is enough time to complete all migrations.
Third-party tools for Microsoft 365 or Office 365 migrations
Third-party tools are mostly used in migration scenarios that don't involve Exchange, such as those from Google Mail, IBM Lotus, Domino, and Novell GroupWise. This section focuses on the migration protocols used by third-party migration tools, rather than on the actual products and migration tools. The following table provides a list of factors that apply to third-party tools for Microsoft 365 or Office 365 migration scenarios.
Important
For issues with data consistency or integrity after performing a migration using third-party tools, please contact the vendor who provided the tool for support.
Factor 1: Data source
| Checklist | Description | Best practices |
|---|---|---|
| System performance | Data extraction is an intensive task. The source system must have sufficient resources, such as CPU time and memory, to provide optimal migration performance. During migration, the source system is often close to full capacity in terms of the regular end-user workload. If system resources are inadequate, the additional workload that results from migration can affect end users. | Monitor system performance during a pilot migration test. If the system is busy, we recommend avoiding an aggressive migration schedule for the specific system because of potential migration slowness and service availability issues. If possible, enhance the source system performance by adding hardware resources and by reducing the load on the system. The system load can be reduced by moving tasks and users to other servers that aren't part of the migration. For more information, see: • Exchange 2013 Server Health and Performance • Understanding Exchange 2010 Performance • Exchange 2007: Monitoring Mailbox Servers When migrating from an on-premises Exchange organization where there are multiple mailbox servers, we recommend that you create a migration user list that's evenly distributed across multiple mailbox servers. Based on individual server performance, the list can be further fine-tuned to maximize throughput. For example, if server A has 50 percent more resource availability than server B, it is reasonable to have 50 percent more users from server A in the same migration batch. A similar practice can be applied to other source systems. Perform migration when the system has maximum resource availability, such as after hours or on weekends and holidays. |
| Back-end tasks | Other back-end tasks usually run during migration time. Because it's a best practice to perform migration after business hours, it's common that migrations conflict with other maintenance tasks running on your on-premises servers, such as data backup. | Review other system tasks that are running during migration. We recommend that you create a clean time window just for data migration, when there are no other resource-heavy tasks. For Exchange on-premises customers, the common tasks are backup solutions. For more information, see Exchange Store Maintenance. |
| Throttling policy | It's a common practice to protect email systems with a throttling policy, which sets a specific limit on how fast and how much data can be extracted from the system within a certain amount of time and by using a specific migration method. | Verify what throttling policy is deployed for your email system. For example, Google Mail limits how much data can be extracted in a certain time period. Depending on the version, Exchange has policies that restrict IMAP access to the on-premises mail server (used by IMAP migrations) and RPC over HTTP Protocol access (used by cutover Exchange migrations and staged Exchange migrations). For more information about IMAP throttling, see Tips for optimizing IMAP migrations. For more information about RPC over HTTP Protocol throttling, see: • Exchange 2013 Workload Management • Exchange 2010: Understanding Client Throttling Policies • Exchange 2007: Understanding Client Throttling For more information about how to configure Exchange Web Services throttling, see Exchange 2010: Understanding Client Throttling Policies. |
Factor 2: Migration server
Most third-party tools for Microsoft 365 or Office 365 migrations are client initiated and push data to Microsoft 365 or Office 365. These tools typically require a migration server. Factors such as system performance, back-end tasks, and throttling policies for the source servers apply to these migration servers.
Note
Some third-party migration solutions are hosted on the internet as cloud-based services and don't require an on-premises migration server.
Solution and practice:
To improve migration performance when using a migration server, apply the same best practices as the ones described in the Factor 1: Data source section.
Factor 3: Migration engine
For third-party migration tools, the most common protocols used are Exchange Web Services and RPC over HTTP Protocol.
Exchange Web Services:
Exchange Web Services is the recommended protocol to use for migrating to Microsoft 365 or Office 365 because it supports large data batches and has better service-oriented throttling. In Microsoft 365 or Office 365, when used in impersonation mode, migrations using Exchange Web Services don't consume the user's budgeted amount of Microsoft 365 or Office 365 Exchange Web Services resources, consuming instead a copy of the budgeted resources:
All Exchange Web Services impersonating calls made by the same administrator account are calculated separately from the budget applied to this administrator account.
For each impersonation session, a shadow copy of the actual user's budget is created. All migrations for this particular session will consume this shadow copy.
Throttling under impersonation is isolated to each user migration session.
Exchange Web Services throttling policy can be temporarily changed in the tenant (for a duration of 30, 60, or 90 days) to allow migration to complete. This can be requested from the Help section of the Microsoft 365 admin center.
Best practices:
Migration performance for customers using third-party migration tools that use EWA impersonation competes with Exchange Web Services-based migrations and service resource usage by other tenants. Therefore, migration performance will vary.
Whenever possible, customers should use third-party migration tools that use Exchange Web Services impersonation because it's usually faster and more efficient than using client protocols such as RPC over HTTP Protocol.
RPC over HTTP Protocol:
Many traditional migration solutions use the RPC over HTTP Protocol. This method is completely based on a client access model such as that of Outlook, and scalability and performance are limited because the Microsoft 365 or Office 365 service throttles access on the assumption that usage is by a user instead of by an application.
Best practices:
For migration tools that use RPC over HTTP Protocol, it's a common practice to increase migration throughput by adding more migration servers and using multiple Microsoft 365 or Office 365 administrative user accounts. This practice can gain data injection parallelism and achieve higher data throughput because each administrative user is subject to Microsoft 365 and Office 365 user throttling. We have received reports that many enterprise customers had to set up more than 40 migration servers to obtain 20-30 GB/hour of migration throughput.
In a migration tool development phase, it's critical to consider the number of RPC operations needed to migrate a message. To illustrate this, we have collected logs captured by Microsoft 365 or Office 365 services for two third-party migration solutions (developed by third-party companies) used by customers to migrate mailboxes to Microsoft 365 or Office 365. We compared two migration solutions developed by third-party companies. We compared the migration of two mailboxes for each migration solution, and we also compared them to uploading a .pst file in Outlook. Here are the results.
| Method | Mailbox size | Item count | Time to migrate | Total RPC transactions | Average client latency (ms) | AvgCasRPCProcessingTime (ms) |
|---|---|---|---|---|---|---|
| Solution A (mailbox 1) | 376.9 MB | 4,115 | 4:24:33 | 132,040 | 48.4395 | 18.0807 |
| Solution A (mailbox 2) | 249.3 MB | 12,779 | 10:50:50 | 423,188 | 44.1678 | 4.8444 |
| Solution B (mailbox 1) | 618.1 MB | 4,322 | 1:54:58 | 12,196 | 37.2931 | 8.3441 |
| Solution B (mailbox 2) | 56.7 MB | 2,748 | 0:47:08 | 5,806 | 42.1930 | 7.4439 |
| Outlook | 201.9MB | 3,297 | 0:29:47 | 15,775 | 36.9987 | 5.6447 |
Note
the client and service process times are similar, but solution A takes a lot more RPC operations to migrate data. Because each operation consumes client-latency time and server-process time, solution A is much slower to migrate the same amount of data compared to Solution B and to Outlook.
Factor 4: Network
Best practice:
For third-party migration solutions that use the RPC over HTTP Protocol, here's a good way to measure potential migration performance:
From the migration server, connect to the Microsoft 365 or Office 365 mailbox with Outlook by using RPC over HTTP Protocol. Make sure that you aren't connecting by using cached mode.
Import a large .pst file with sample data to the Microsoft 365 or Office 365 mailbox.
Measure migration performance by timing how long it takes to upload the .pst file. The migration throughput should be similar to what customers can get from a third-party migration tool that uses RPC over HTTP Protocol, given no other constraints. There's overhead during an actual migration, so the throughput might be slightly different.
Factor 5: Microsoft 365 and Office 365 service
Exchange 365 Admin Portal
Microsoft 365 and Office 365 resource health-based throttling affects migrations using third-party migration tools. See Microsoft 365 and Office 365 resource health-based throttling for more details.