More throttling changes for Exchange Online

  • Article

In my last post, Exchange Online EWSMaxSubscriptions throttling budget calculation has been updated!, I wrote about a recent change to the EWSMaxSubscriptions throttling setting. Although useful, that information is just one part of the story. Now I’m here to fill you in on the rest.

We have made changes to the way that throttling budgets are counted for application impersonation calls. Now, the calls are charged against the target mailbox instead of the service account that makes the application impersonation calls. More specifically, the charges are counted against a copy of the target mailbox quota. This means that the impersonated service account access is not charged against the target mailbox account owner’s throttling budget. It is important to note that the copied budget is shared across all service accounts that are using application impersonation. This information is important when you are enabling many application impersonation scenarios against mailboxes. In summary, each throttling setting represents two budgets: one for the user account, and one for all service applications that use application impersonation against a specific user mailbox.

Here is a complete list of the throttling settings that have been updated with the new budget accounting:

  • EWSMaxConcurrency                    
  • EWSPercentTimeInAD                       
  • EWSPercentTimeInCAS                      
  • EWSPercentTimeInMailboxRPC     
  • EWSMaxSubscriptions                      
  • EWSFastSearchTimeoutInSeconds            
  • EWSFindCountLimit

I’d expect this to be welcome news. With that said, there is one exception to the change. The EWSMaxConcurrency setting limit does have some variation in how it is implemented for different types of connections. EWS streaming notifications have a separate budget from all other EWS client connections. For example, if EWSMaxConcurrency is set to the value of 10, it means that a user account (and all service applications using application impersonation) can have up 10 concurrent streaming notification subscriptions and 10 other concurrent EWS connections while targeting a single mailbox.

What does this mean for Exchange Online and streaming subscriptions? In short, this means that a service account can monitor up to 2000 mailboxes. Allow me to explain how this works. A service account application using application impersonation performs Subscribe operations using impersonation to set up subscriptions for each of the target mailboxes. Then, the service account application would bundle all the SubscriptionIds, up to 200 per GetStreamingEvents request, from all the mailboxes and include them in one GetStreamingEvents request. (NOTE: GetStreamingEvents and GetEvents operations do not have to use the impersonation header to get the notification events for the impersonated email messages. As long as the service account has a valid SubscriptionId, it can access the event notifications.) A service account can have at most 10 open GetStreamingEvents requests open at any one time. We recommend that there are no more than 200 SubscriptionIds in each GetStreamingEvents request. This effectively means that a single service account can monitor up to 2000 subscriptions, or 2000 mailboxes if you assume one subscription per mailbox. We expect that this should scale fairly well.

As with my last post, these changes have taken effect as of service mailbox versions 14.16.0135 and 14.15.0057.000 and later. These are customer-driven changes and we do appreciate the feedback. Code on!