Throttling PowerShell command usage in Exchange 2010

Throttling PowerShell command usage in Exchange 2010



Administrative actions are based on PowerShell. Some administrative actions, like running large scripts, can be resource intensive. Throttling PowerShell can help lessen the strain on a server's performance.


Exchange's Web services (EWS) rely on remote shell sessions. Because of this, throttling PowerShell can help prevent a user from overloading Exchange by performing concurrent actions through multiple browsers.


Exchange Server 2010 provides several different parameters you can use to throttle PowerShell command usage. One such parameter is PowerShellMaxConcurrency. This parameter can be tricky because its function varies depending on the context.


When a user establishes a remote shell, the PowerShellMaxConcurrency parameter defines the maximum number of simultaneous remote shell sessions that a user can have open. This parameter may also be applied to EWS. In this case, the parameter controls the maximum number of cmdlets that a user can simultaneously run.


Where PowerShell throttling and throttling policy parameters differ

Unlike the PercentTimeIn parameter, PowerShell throttling parameters don't automatically assume that you want to throttle commands based on percentages of a minute. Instead, you must explicitly define your desired throttling time period by assigning a period of time (in seconds) to the PowerShellMaxCmdletsTimePeriod parameter. After doing this, you can control the maximum number of PowerShell cmdlets that are allowed to run within the designated period by assigning a value to the PowerShellMaxCmdlets parameter.

One PowerShell throttling parameter that I recommend avoiding is PowerShellMaxCmdletQueueDepth, which controls the total number of PowerShell cmdlets that can be simultaneously queued. Using this parameter can have several side effects.


Modifying the PowerShellMaxCmdletQueueDepth parameter affects PowerShellMaxCmdlets and PowerShellMaxConcurrency settings, both of which already skew cmdlet depth. The PoweShellMaxConcurrency parameter limits the number of concurrent remote shell sessions that a user can have open, so it also limits the number of simultaneous cmdlets that can run. The parameter can also limit the number of browser sessions that a user can have open.


When you're using the PowerShellMaxCmdletQueueDepth parameter, it has the same effect as decreasing the PowerShellMaxConcurrency setting by two. If you do decide to use this parameter, Microsoft recommends that you set its value to at least three times the value of the PowerShellMaxConcurrency parameter.


Note: Throttling the PowerShellMaxCmdletQueueDepth won't affect the Exchange Control Panel or EWS.