This content is part of the Essential Guide: The essential guide to PowerShell in Exchange

Why throttling PowerShell in Exchange 2010 is a good idea

Did you know that you can restrict PowerShell use in Exchange 2010 to improve server performance? Get the details on setting PowerShell limits in your environment.

Client throttling policies are designed to prevent server resource deprivation, but your users may also be unknowingly affecting server performance. The parameters discussed in this tip will help you achieve tighter control over PowerShell usage and avoid performance problems that may result from users who establish multiple sessions with your Exchange 2010 servers.

Many throttling policy parameters are based on the PercentTimeIn parameter, which is one way to control the percentage of time that a particular resource is used. When creating policies based on the PercentTimeIn parameter, you must use a component acronym like OWA or POP in front of the PercentTimeIn parameter. A resource acronym like AD or CAS must then follow that parameter. For example, OwaPercentTimeInAD regulates the amount of time that OWA can spend accessing the Active Directory. But PercentTimeIn isn't the only parameter you can use.

Another option is the MaxConcurrency parameter.The MaxConcurrency parameter controls the maximum number of simultaneous connections that a user can have to an Exchange server. I recommend using the MaxConcurrency parameter because the PercentTimeInparameter is session-based. For example, let's say you want to limit users to using a resource 50% of the time. To do so, you'd set the PercentTimeIn parameter for said resource to 50. This tells Exchange that for every minute that elapses, the user may only spend 30 seconds consuming the specified resource.

When you use the MaxConcurrency parameter you must still use a component acronym; but you don't have to specify a resource attribute. Therefore, if you want to regulate a user's maximum concurrency for OWA, you would use OwaMaxConcurrency.

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.

About the author: Brien M. Posey, MCSE, is a seven-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at

Do you have comments on this tip?  Let us know.

Dig Deeper on Exchange Server setup and troubleshooting