Exchange Online Throttling and Limits FAQ

What are the throttling settings for Microsoft Exchange Online as part of Microsoft Office 365? Before I answer this question, let me give you bit of background information. Microsoft Exchange includes bandwidth throttling to help manage server access. This supports service quality and consistent performance. The throttling components of Exchange Online are especially important, given that network resources in the datacenters are optimized for the broad set of customers that use the service. So, to properly engineer solutions that work with Exchange Online, you will need to account for the Exchange Online throttling settings.

We are specifically focused on throttling of Exchange Web Services (EWS) and MAPI with RPC over HTTP (as used by Microsoft Outlook) and with hard limits set by the Exchange Online system. Any mention of specific setting values were obtained for the service version 14.0.100.0. You will want to have your tenant admin obtain and confirm setting values.

Note   An on-premise Microsoft Exchange deployment may have a different throttling policy. Administrators can modify throttling settings for Microsoft Exchange on-premises. Administrators cannot configure throttling policies for Exchange Online.

What is the impact of exceeding throttling budgets?

Exchange throttling is based on the amount of Active Directory, Exchange store, and other resources a client consumes. A budget is allocated to each client to limit the resources a particular user consumes. This budget is recharged every minute.

EWS clients can exceed their budgets by sending too many concurrent requests, or by requesting too many resources on the server. When this occurs, additional requests are queued until one of two things happen:

• The application is under budget. The request is then processed and the client experiences an increase in latency.
• The request has been queued for more than 60 seconds, after which time the server sends an error response to the application.

When MAPI clients exceed their budgets, additional requests are returned with an error, until the application is under budget. There is no queuing of requests.

How do I get throttling settings?

Tenant administrators can view throttling settings by using Remote PowerShell and the Get-ThrottlingPolicy cmdlet. For information about how to connect Remote PowerShell for your tenant, see Install and Configure Windows PowerShell and Connect Windows PowerShell to the Service on Microsoft TechNet.

Use the Get-ThrottlingPolicy cmdlet (without arguments) to get all the throttling policy settings. Throttling policies might change to enhance service performance, so you should confirm throttling policies. We suggest that you make your client applications configurable to adjust for potential changes in throttling policy for Exchange Online. Additionally, because Exchange Online and Exchange on-premises might have different throttling policies, you may want to account for this when you design your client applications.

What are the common throttling settings?

The following throttling settings are common to both EWS and MAPI (RPC over HTTP) clients:

• MessageRateLimit – Identifies the maximum number of messages that can be sent per minute. This is configured to count sent messages on a per IP address basis.
• RecipientRateLimit – Identifies the maximum number of recipients that a sender can send to in a 24-hour period.
• ForwardeeLimit – Identifies the maximum number of recipients that can be configured for Inbox rules when the user account is using the forward or redirect action.

What are the MAPI with RPC over HTTP throttling settings?

The prefix RCA in the MAPI RPC/HTTP settings represents RPC Client Access. The following throttling settings are specific to MAPI RPC over HTTP:

• RCAMaxConcurrency – Identifies the maximum number of concurrent connections that can be maintained by MAPI RPC/HTTP clients (such as Microsoft Outlook) at any one time. Attempts to open more than the maximum number of connections will fail. Existing connections will remain unaffected. Active Directory calls count toward the number of concurrent connections. 
• RCAPercentTimeInAD – Identifies the maximum amount of time that can be spent by a Client Access server when accessing Active Directory resources on behalf of a client, per minute. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the result by 60 seconds. For example, an RCAPercentTimeInAD throttling value of 5 results in a throttling threshold of 3 seconds (5/100 * 60 seconds).
• RCAPercentTimeInCAS – Identifies how much time all concurrent MAPI RPC/HTTP connections can consume on the Client Access server per minute. This is calculated on a per user basis. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the results by 60 seconds. For example, an RCAPercentTimeInCAS throttling value of 205 results in a throttling threshold of 123 seconds (205/100 * 60 seconds). If the setting is 123 seconds, two concurrent MAPI RPC/HTTP connections can be open on a Client Access server for a full 60 seconds, thus using up 120 seconds per minute. A third connection can only use the remaining 3 seconds per minute, assuming all three connections occur concurrently and are initiated at the same time. 
• RCAPercentTImeInMailboxRPC – Identifies how much time all concurrent MAPI RPC/HTTP connections can consume for accessing the mailbox per minute. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the results by 60 seconds. For example, an RCAPercentTimeInMailboxRPC throttling value of 200 results in a throttling threshold of 120 seconds (200/100 * 60 seconds). This means that two connections can consume 60 seconds per minute (120 seconds total per minute) as long as there are no other connections.

What are the Exchange Web Services throttling settings?

The following throttling settings are specific to Exchange Web Services:

• EWSFastSearchTimeoutInSeconds – Identifies how long an Exchange Search (indexed search) request will continue until it times out.
• EWSFindCountLimit – Identifies the maximum number of search results in concurrent requests. For more information, see Throttling Policies and the EWS FindCountLimit. We suggest that searches all be paged and that the page size not exceed 1000 results.
• EWSMaxConcurrency – Identifies the maximum number of concurrent connections that can be maintained by EWS clients at any one time. Attempts to open more than the maximum number of connections will fail. Existing connections will remain unaffected. Active Directory calls count toward the number of concurrent connections. 
• EWSMaxSubscriptions – Identifies the maximum number of push, pull, or streaming notification subscriptions. If a server has too many notification subscriptions, it will start returning server busy errors. The server starts to return errors when the number of open connections reaches approximately 20 for a user. The charges for EWSMaxSubscription are calculated as follows:
  • Client – charged against the caller, also called the mailbox owner.
  • Intra-forest ExchangeImpersonation – charged against the caller.
  • Server-to-Server – charged against the underlying effective caller.
• EWSPercentTimeInAD – Identifies the maximum amount of time that can be spent by a Client Access server when accessing Active Directory resources on behalf of a client account, per minute. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the result by 60 seconds. For example, a EWSPercentTimeInAD throttling value of 50 results in a throttling threshold of 30 seconds (50/100 * 60 seconds).
• EWSPercentTimeInCAS – Identifies how much time all concurrent EWS connections can consume on the Client Access server per minute. This is calculated on a per user basis. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the results by 60 seconds. For example, a EWSPercentTimeInCAS throttling value of 90 results in a throttling threshold of 54 seconds (90/100 * 60 seconds).
• EWSPercentTimeInMailboxRPC – Identifies how much time all concurrent EWS connections can consume while accessing a mailbox via RPC requests, per minute. This is calculated on a per-user basis. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the results by 60 seconds. For example, a EWSPercentTimeInMailboxRPC throttling value of 60 results in a throttling threshold of 36 seconds (60/100 * 60 seconds). This means that a single connection can consume 36 seconds per minute as long as there are no other connections. Two connections that started at the same time can only consume 18 seconds each per minute. This is based on a threshold setting of 60.

For more information about EWS throttling policy, see EWS Best Practices: Understanding Throttling Policies.

What are the specific Exchange Web Services limits?

The following are the specific EWS throttling limits:

• maxAllowedContentLength (IIS7) – Identifies the maximum accepted content length of HTTP requests. This maximum length is 35,000,000 bytes, which translates to 25 MB of base64-encoded data.
• maxReceivedMessageSize (WCF) – Identifies the maximum message size that is accepted by EWS. This maximum message size is 35,000,000 bytes, which translates to 25 MB of base64-encoded data.

Note   The values for this limit differ for an on-premise Exchange 2010 deployment. In the initial release version of Exchange 2010, the message size limit is 10 MB. In Exchange 2010 Service Pack 1 (SP1), the message size limit is 35 MB.

• maxRequestLength (ASP.Net) – Not used.

Technorati Tags: Exchange Online,Throttling,EWS,Exchange Web Services,MAPI

• Anonymous
  October 19, 2011
  Administrators cannot configure throttling policies for Exchange Online. On one hand this makes total sense to not allow customers change the throttling settings in Exchange Online so that MS could have predictable load levels. On the other hand higher bandwidth may be required for migration purposes, which is a one-time project. I expect corresponding settngs may be changed by MS for a customer upon request, but this would require contacting support. I have an enhancement proposal: allow customer to change specific throttling settings for just one specific account. Use case: I want to run a migration and use third-party (not native migration-batch) tools for that. Those tools use an ms online administrator account to connect to Exchange Online. If there was a powershell cmdlet allowing to set higher throttling settings for this specific account, that would be great. Of course, throttling setting limits need to be defined for this account as well, but they can be considerably higher than the ones for generic users just using services. This would allow to:

1. Still have predictable load levels.
2. Eliminate the need for contacting support to do migration.

• Anonymous
  September 19, 2012
  The Get-ThrottlingPolicy commandlet is not available on office 365 online

• Anonymous
  September 19, 2012
  The Get-ThrottlingPolicy commandlet is not available on office 365 online. So the statement "Use the Get-ThrottlingPolicy cmdlet (without arguments) to get all the throttling policy settings" will not work for Office 365 domains. It is a pity that MS has not specified this anywhere and people spent hours setting up the environments just to figure out this doesn't work. I lost the time, don't want any one else to lose it again.

• Anonymous
  November 28, 2012
  The comment has been removed

• Anonymous
  November 29, 2012
  @Shafdat_ali, I suggest you post your question with additional information to the Exchange development forum. I'd expect you will get answer sooner that way. social.technet.microsoft.com/.../threads With regards, Michael Mainer Microsoft Corporation

• Anonymous
  November 29, 2012
  @Regarding throttling policy cmdlets and Exchange Online. Yes, it is true that the throttling policy cmdlets were removed from Exchange Online. I've raised this as a concern with the product team. With regards, Michael Mainer Microsoft Corporation

• Anonymous
  January 23, 2013
  This was a very informative post with exactly the answer I was looking for. Unforunately we are using Exchange Online which limits what I can do but information is power. Thank you very much for this. Kris

• Anonymous
  March 24, 2013
  Michael, I heard Office 365 Wave 15 throttling has gotten more severe. For example, powershell sessions limit on per tenant basis was introduced. When could we expect an update to this article to reflect Wave 15 changes? Thanks!

• Anonymous
  April 30, 2013
  Michael, I want to move my office to cloud-based Amicus Cloud which works great with Outlook 2010.  I currently have Microsoft 365 which I would also keep.  However, I've gotten feedback from several law firms that say it literally takes "minutes" for an appointment to post sometimes using Amicus with Office 365 due to this throttling issue.  Any updates on this?

• Anonymous
  April 30, 2013
  @Jay Foster Creating an appointment would not come close to reaching a throttling limit. I'd have to know what their cloud service does before I could comment on it. With regards, Michael Mainer

• Anonymous
  July 08, 2013
  Any way to see what the current tenant/organization throttling policy is?

• Anonymous
  July 28, 2013
  a) What causes this? b) What are the default values for the various PowerShell throttling parameters when using Office365? c) Is there any transparency in Office365 to see the current state of throttling, or any other tools that can assist us? d) Are the throttling parameters per user, per machine, or what?

• Anonymous
  July 29, 2013
  Brilliant...!!

• Anonymous
  January 09, 2014
  The comment has been removed

• Anonymous
  January 10, 2014
  Hello Justin, This sounds like unexpected behavior on the part of Exchange. I'm sorry that I cannot offer you a solution to this scenario. I suggest you open a case for Exchange Developer Messaging support.. support.microsoft.com/.../en-us. In case you have a premier contract, you can use https://premier.microsoft.com/. You may want to try the forums. With regards, MIchael Mainer Microsoft

• Anonymous
  September 25, 2014
  For migration purposes, if you have more than 1,000 mailboxes you can open a support case with the Exchange Online support team to have the throttling budgets increased for you. http://blog.mohsinabbas.com

• Anonymous
  October 20, 2015
  Hi, I am seeing strange Outlook behavior when sending emails. If I FTP a 10MB file it takes around 20sec to download/upload. If I send the file as an attachment using Outlook and Office365 it takes around 5mins to leave my OUTBOX, it appears roughly 5sec later in my OWA INBOX and then roughly 20sec in my OUTLOOK INBOX (so download similar to FTP)... if I attached the file into an OWA email it takes 1min24sec to attach, and then around 20sec to appear in my OUTLOOK INBOX once sent from OWA (again matching the FTP speed)... so the question is why the delay (which appears to be throttled) in sending from OUTLOOK to OFFICE365? I have run the MS OFFICE365 SUPPORT AND RECOVERY ASSISTANT, disabled COM addins, etc etc and also tested outside our firewall, no change. Would appreciate any direction.... Regards, Stefan

• Anonymous
  October 27, 2015
  Please update this blog or pull it from MSDN.  It is was published in 2011 and is outdated.

• Anonymous
  September 20, 2016
  I also found this information about Throttling Policy in EAS which is relevant also.The ‘Error 503’ Throttle Header, 'X-MS-ASThrottle: CommandFrequency' means “too many commands”, and it applies to “how quickly the device is hitting the server in general (across all commands)”. The default value for CommandFrequency is block after “400 commands in 10 minutes”, and block for “20 minutes”. Source: https://social.msdn.microsoft.com/Forums/en-US/3658aca8-36fd-4058-9d43-10f48c3f7d3b/what-does-commandfrequency-mean-with-respect-to-eas-throttling?forum=os_exchangeprotocols

• Anonymous
  November 28, 2016
  I am getting office 356 throttling with a 503 after just a single sync command. The command took a minute to return and came back with a 503 with throttling headers. It is working perfectly on dozens of accounts, but not this one. Any ideas why this could be?