none
Service Account Throttling Policy setting question RRS feed

  • Question

  • Hello -

    This is a question about the throttling policy setting called IsServiceAccount. Here's all we've been able to locate about what this setting does:

    From https://technet.microsoft.com/en-us/library/Dd298094(v=EXCHG.150).aspx , Set-ThrottlingPolicy, “Parameters” section:

    "The IsServiceAccount switch specifies whether you want the user accounts associated with this policy to be moderated by the per-user thresholds specified by this policy, and also by additional throttling based on the health of system resources, such as overall CPU usage.

    This value is set to $false by default.

    You may want to set this value to $true if you intend to associate this policy with user accounts that require higher throttling limits. An account that might require higher throttling limits is a service account that performs a lot of non-interactive work (for example, service accounts that perform IMAP mailbox migrations or nightly Windows PowerShell tasks). By setting the IsServiceAccount switch to $true, work done by these accounts is moderated by the higher user throttling settings that you configure using the user throttling policy, but is slowed if resources start getting unhealthy."

    Our application uses a service account and impersonation to subscribe to streaming events. We're working on the service account throttling requirements and are not sure whether this one is relevant. We've tested with it set to both TRUE and FALSE and haven't seen any difference in the way the connections get throttled. I suspect we aren't loading the test system enough, but need more granular information about the mechanics of the setting to proceed. Could you direct us to more detail about exactly what this setting does when enabled? What does "start getting unhealthy" mean? How do we trigger the implied slowing? How much are the relevant budgets downsized?

    Your attention is greatly appreciated!

    Robert

     

    Wednesday, September 9, 2015 7:44 PM

Answers

  • In 2013 they introduced the Burst Rates in EWS (and other protocols) eg EwsMaxBurst to improve the throttling allocations over 2010 so the algorithms that determine wether you will be throttled are going to vary between 2010 and 2013.

    >>Exch2013 doesn't have the ability to set the CPU throttling start point.

    But as part of the Server Health and Workload management the CPU usage is being monitored and you will throttled if your application was to starts causing high CPU utilization. IsServiceAccount should give your application additional throttling resources within the constraints of the health of the underlying server (I think this is designed for an application that was doing Migrations where because your have a constant stream of request you would likely to over spend the Burst budgets). I haven't seen any better documentation on IsServiceAccount other then what you have pointed to, I think the best approach would be to test it yourself in a lab eg see what happens when two different users with different polices when you start to generate a lot of load on the server eg One of the Microsoft engineers have released on tool to do this https://ewsrelentless.codeplex.com/  

    Once you get into Exchange Online your options are very limited you can't configure any of the throttling setting so making your application live within the default allocation is a good design goal.

    Cheers
    Glen


    • Edited by Glen ScalesMVP Friday, September 11, 2015 7:07 AM
    • Marked as answer by OldRobP Monday, September 14, 2015 8:13 PM
    Friday, September 11, 2015 7:06 AM

All replies

  • >> What does "start getting unhealthy"

    Wow that doco needs some editing, I think they are referring the health of the CAS server eg if your application was to start causing high CPU utilization on a CAS server then you would be throttled based on the impact your having on the CAS health. The amount of throttling is supposed to be proportion to the effect the application is having this is explained more in https://msdn.microsoft.com/en-us/library/office/jj945066(v=exchg.150).aspx

    If you have Streaming application and you use Impersonation then its unlikely that you hit any throttling issues with streaming. Where your more likely to run into throttling is if you where to start processing a lot of items in a small amount of time (or say you received an email with 5000 recipients and tried to resolve all those recipient's in one batch etc). A good way to look at the effect of throttling is have a look at the CASLogs (eg \Microsoft\Exchange Server\V..\Logging) and you can see how your application is impacting on the throttling budgets.

    Cheers
    Glen  

    Thursday, September 10, 2015 5:32 AM
  • Hi Glen --

    Thanks so much for the quick reply. Some background -- our customer base is quite wide, so we are interested in 2010, 2013 and  also coexistence environments, though at the moment we're focusing on 2013. Our test environment is an Exchange 2007/2010/2013 coexistence environment. As part of this investigation I dumped the throttling policies from the Exch2013 CAS server and from the exch2013 CAS server and did a side-by-side comparison. After re-reading your references and comparing the throttling policy dumps I think I can refine the question better.

    The Exch2010 dump showed a default policy, a global policy and a user-created policy

    The Exch2013 dump showed  a global policy and a user-created policy and also a copy of the 2 exch2010 policies modified as follows (I assume this is  normal when a clean exch2013 system is deployed into an existing exch2010 environment):

    added:

    ThrottlingPolicyScope
    IsServiceAccount
    IsLegacyDefault

    deleted:

    CPUStartPercent

    My conclusions:

    IsServiceAccount is an Exchange 2013 policy setting. The information you pointed me to is mainly about the  CPUStartPercent parameter, which is an Exchange 2010 setting. Exch2010 doesn't have the ability to specify whether a policy applies to a service account or not, Exch2013 doesn't have the ability to set the CPU throttling start point.

    So. If I create 2 throttling policies that are identical except that one has the IsServiceAccount =TRUE and the other has IsServiceAccount = FALSE and both are contributing equally to a resource-intense environment, how is the account associated with one policy throttled differently than the account associated with the other policy?

    Again, your attention is greatly appreciated!

    Robert

    Thursday, September 10, 2015 8:00 PM
  • In 2013 they introduced the Burst Rates in EWS (and other protocols) eg EwsMaxBurst to improve the throttling allocations over 2010 so the algorithms that determine wether you will be throttled are going to vary between 2010 and 2013.

    >>Exch2013 doesn't have the ability to set the CPU throttling start point.

    But as part of the Server Health and Workload management the CPU usage is being monitored and you will throttled if your application was to starts causing high CPU utilization. IsServiceAccount should give your application additional throttling resources within the constraints of the health of the underlying server (I think this is designed for an application that was doing Migrations where because your have a constant stream of request you would likely to over spend the Burst budgets). I haven't seen any better documentation on IsServiceAccount other then what you have pointed to, I think the best approach would be to test it yourself in a lab eg see what happens when two different users with different polices when you start to generate a lot of load on the server eg One of the Microsoft engineers have released on tool to do this https://ewsrelentless.codeplex.com/  

    Once you get into Exchange Online your options are very limited you can't configure any of the throttling setting so making your application live within the default allocation is a good design goal.

    Cheers
    Glen


    • Edited by Glen ScalesMVP Friday, September 11, 2015 7:07 AM
    • Marked as answer by OldRobP Monday, September 14, 2015 8:13 PM
    Friday, September 11, 2015 7:06 AM
  • Hi Glen --

    Thanks so much for the time and detail --  our product uses both streaming notifications and impersonated finditem type queries for often quite large numbers of users and mail items, which as I understand it now covers the whole spectrum of EWS throttling opportunities (as our customers have been reporting <grin>). Now that I have a better understanding of the differences between 2010 and 2013 throttling the IsServiceAccount setting is starting to make sense, especially if, as you suggest, it tells the system that the account is not a "user" per se and to be a little more forgiving of certain over-budget conditions. 

    I think this question is answered -- some adjustments to our load testing need to be made, but the results will be much less ambiguous now.  Thanks for suggesting the tool, but it doesn't support impersonation, so we'll have to pass on it for this issue. And thanks also for the heads-up re: Exchange Online. We were thinking that was probably going to be a whole new bag of snakes.  

    Oh yes -- I still have a lingering question about throttle policy scopes and inheritance, but will post a new question for that. 

    Best Regards,

    Robert

    Friday, September 11, 2015 10:33 PM