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!

IMPORTANT: The Get-ThrottlingPolicy and Get-ThrottlingPolicyAssociation cmdlets are not available with Exchange Online. In a previous post, Exchange Online Throttling and Limits FAQ, I stated that those cmdlets were available. That information was true when it was posted. These cmdlets are currently only available with Exchange Server.

Are there any ways to programatically fetch the throttling settings for Exchange Online using a API. If no APi then any other method, I read that The Get-ThrottlingPolicy and Get-ThrottlingPolicyAssociation cmdlets, are they still applicable?