Export (0) Print
Expand All

Understanding Client Throttling Policies

Applies to: Exchange Server 2010

Topic Last Modified: 2009-11-17

Microsoft Exchange Server 2010 uses client throttling policies to manage the performance of your Exchange organization. To do this, Exchange tracks the resources that each user consumes and enforces connection bandwidth limits, as necessary.

Among other things, client throttling helps you make sure that:

  • Users aren't intentionally taxing the system.
  • Users aren't unintentionally taxing the system.
  • Users of various connectivity methods are sharing resources proportionally.

Contents

Default and Non-Default Policies

Understanding Policy Parameters

Exchange Management Shell Commands and Parameters

Common Uses for Throttling Policies

Throttling Performance Counters

Although there's a default client throttling policy that's generally sufficient to manage the load placed on your Exchange system, you can customize the default policy or add additional policies based on the needs of your organization.

If you're hosting multiple tenants in your Exchange organization, you can define an acceptable load for each user of a tenant. Similarly, if you're an on-premise organization, you can define an acceptable load on a user-by-user basis. Through policies, Exchange evaluates how each user uses the system and ensures that the resulting per-user load falls within acceptable boundaries as defined by the user's policy. The client throttling system tracks system usage on a per-user basis and uses the throttling policy associated with that user to determine if throttling should occur.

When an Exchange organization is created, a default throttling policy is automatically created that implicitly governs all users within that organization.

In Exchange 2010 Enterprise installations, there's a single default throttling policy called First Organization. In the Outlook Live service installations, each tenant has its own default throttling policy.

You manage throttling policy settings through the Exchange Management Shell using the Get-ThrottlingPolicy, Set-ThrottlingPolicy, New-ThrottlingPolicy, and Remove-ThrottlingPolicy cmdlets.

The acceptable load of a throttling policy is defined by the cmdlet parameter values on that throttling policy. The component types covered by throttling policies are as follows:

  • Microsoft Exchange ActiveSync
  • Exchange Web Services
  • IMAP
  • Outlook Web App
  • POP
  • Windows PowerShell

All these component types have policy parameters that work similarly, except for the Windows PowerShell component type.

The common component types are governed by four policy parameters: <Component Acronym>MaxConcurrency, <Component Acronym>PercentTimeInAD, <Component Acronym>PercentTimeInCAS, and -<Component Acronym>PercentTimeInMailboxRPC. The parameter names are prefixed by the component type acronym. The following table lists the component type acronyms that are used for the parameters in the throttling policy cmdlets.

Component type acronyms that are used in throttling policy cmdlets

Component Acronym Description Example

EAS

Exchange ActiveSync

In the parameter EASPercentTimeInCAS, the component acronym EAS represents the Exchange ActiveSync component.

EWS

Exchange Web Services

In the parameter EWSPercentTimeInCAS, the component acronym EWS represents the Exchange Web Services component.

OWA

Outlook Web App

In the parameter OWAPercentTimeInCAS, the component acronym OWA represents the Outlook Web App component.

IMAP

IMAP4

In the parameter IMAPPercentTimeInCAS, the component acronym IMAP represents the IMAP4 component.

POP

POP3

In the parameter POPPercentTimeInCAS, the component acronym POP represents the POP3 component.

Dd297964.note(en-us,EXCHG.140).gifNote:
Unified Messaging users are considered Exchange Web Services users and their connections to the Exchange server are throttled by Exchange Web Services parameters such as EWSMaxConcurrency, EWSPercentTimeInAD, EWSPercentTimeInCAS, and EWSPercentTimeInMailboxRPC.

Return to top

The value for a MaxConcurrency policy parameter indicates how many concurrent connections a specified user can have against an Exchange server at one time. A connection is held from the moment a request is received until a response is sent in its entirety to the requestor. If users try to make more concurrent requests than their policy allows, the new connection attempt fails. However, the existing connections remain valid. <Component Acronym>MaxConcurrency has a valid range from 0 through 100 inclusive. To indicate that <Component Acronym>MaxConcurrency should be unthrottled (no limit), this value should be set to $null.

Dd297964.important(en-us,EXCHG.140).gifImportant:
Don't set throttling policy parameters to $null unless you have a business need to do so. Unthrottled users aren't limited in their ability to intentionally or inadvertently place a high load on the server.

The value for a PercentTimeInCAS, PercentTimeInAD, or PercentTimeInMailboxRPC policy parameter indicates what percentage of a minute can be spent:

  • Running Client Access server code (<Component Acronym>PercentTimeInCAS)
  • Running LDAP requests (<Component Acronym>PercentTimeInAD)
  • Running mailbox RPC requests (<Component Acronym>PercentTimeInMailboxRPC)

A value of 100 indicates that for every one-minute window, the process can spend 60 seconds of that time consuming the resource in question. Although, it appears that a process would never encounter throttling with a value set to 100, you have to consider the effect of concurrent requests. If a process makes two concurrent requests that spend 60 seconds each running code on the Client Access server, the process has effectively used 120 seconds in a 60 second window, thus representing a <Component Acronym>PercentTimeInCAS value of 200 percent.

To indicate that PercentTimeInCAS, PercentTimeInAD, and PercentTimeInMailboxRPC should be unthrottled (no limit), this value should be set to $null.

Dd297964.important(en-us,EXCHG.140).gifImportant:
Don't set throttling policy parameters to $null unless you have a business need to do so. Users aren't limited in their ability to intentionally or inadvertently place a high load on the server.

It's important to note that <Component Acronym>PercentTimeInCAS is an overlapping superset of <Component Acronym>PercentTimeInAD and <Component Acronym>PercentTimeInMailboxRPC. This means that the expenditure in Client Access server processing time will always be larger than the expenditures in <Component Acronym>PercentTimeInAD and <Component Acronym>PercentTimeInMailboxRPC. This is because for the Exchange component to make an Active Directory or RPC call, it must already be running Client Access server code. In addition, the expenditure in processing time for <Component Acronym>PercentTimeInCAS doesn't stop while LDAP or RPC calls are being made. Even though the request might be synchronously waiting for a response from Active Directory or the Exchange store, the process is still consuming a thread on the server and therefore should continue being charged for that usage. As a result, the <Component Acronym>PercentTimeInCAS value must be set to a value larger than both <Component Acronym>PercentTimeInAD and <Component Acronym>PercentTimeInMailboxRPC.

Return to top

This section discusses the following Windows PowerShell parameters:

  • PowerShellMaxConcurrency
  • PowerShellMaxCmdlets
  • PowerShellMaxCmdletsTimePeriod
  • PowerShellMaxCmdletQueueDepth

In the context of remote Shell, the PowerShellMaxConcurrency parameter defines the maximum number of remote Shell sessions that a remote Shell user can have open at the same time. In the context of Web services, the PowerShellMaxConcurrency parameter defines the number of concurrent cmdlets that a user can have running at the same time. This value doesn't necessarily match the number of browsers opened by the user.

The PowerShellMaxCmdlets parameter defines the number of cmdlets that can be run per time period without being throttled. This parameter directly depends on the value defined by the PowerShellMaxCmdletsTimePeriod parameter. Both values should be set at the same time.

The PowerShellMaxCmdletsTimePeriod parameter defines the time period, in seconds, that a user can run the number of cmdlets defined by the PowerShellMaxCmdlets parameter.

The PowerShellMaxCmdletQueueDepth parameter defines the number of operations that a user can run at the same time. This value directly affects the behavior of the PowerShellMaxCmdlets and PowerShellMaxConcurrency parameters. For example, the PowerShellMaxConcurrency parameter will use up at least two of the operations defined by the PowerShellMaxCmdletQueueDepth parameter, but additional operations will also be counted against the throttling limit each time the cmdlet is run. The number of operations that count toward the throttling limit depends on the cmdlets that are run. We recommend that the value for the PowerShellMaxCmdletQueueDepth parameter be at least three times larger than the value of the PowerShellMaxConcurrency parameter. This parameter won't affect operations that are run using the Exchange Control Panel or operations that are run through Exchange Web Services.

The Exchange Management Shell enables you to modify and view the client throttling policy settings using the cmdlets described in the following table.

Cmdlets for managing client throttling policies on a Client Access server

Cmdlet name Description

New-ThrottlingPolicy

This cmdlet creates a new throttling policy.

Remove-ThrottlingPolicy

This cmdlet removes a throttling policy.

Get-ThrottlingPolicy

This cmdlet lets you view the settings of a throttling policy.

Set-ThrottlingPolicy

This cmdlet modifies all available settings for a throttling policy.

Dd297964.note(en-us,EXCHG.140).gifNote:
To associate a throttling policy with a single user or a group of users, use the ThrottlingPolicy parameter with the New-Mailbox and Set-Mailbox cmdlets.

You can use the ThrottlingPolicy parameter of the Set-Mailbox and New-Mailbox cmdlets in the Exchange Management Shell to associate client throttling policies with a user or a group of users by modifying properties on their mailbox. For more information, see Set-Mailbox and New-Mailbox.

Return to top

The following are some ways you can manage client throttling policies.

By default, client throttling policies have the IsDefault parameter set to true. You can retrieve the default throttling policy using the where-object filter. The following example shows how to retrieve the default throttling policy.

Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}

You can set throttling policies on a per-user basis. Therefore, you may want to retrieve the policy governing a specific user. You can obtain the ThrottlingPolicy parameter from the mailbox of the user you're interested in and pass it to the Get-ThrottlingPolicy cmdlet. In the following example, the mailbox of a user named Tony Smith is used.

$policy = $null;
$policyLink = (Get-Mailbox tonysmith).ThrottlingPolicy;
if ($policyLink -eq $null)
{ 
    $policy = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}
}
else
{
    $policy = $policyLink | Get-ThrottlingPolicy;

To create a new, non-default throttling policy, run the New-ThrottlingPolicy cmdlet and set the parameters you want. Any parameters that you omit will inherit the values from the default throttling policy. The following example creates a new throttling policy, ClientThrottlingPolicy2. The new policy has nearly the same settings as the default throttling policy. The difference is that the new non-default throttling policy, ClientThrottlingPolicy2, sets EWSPercentTimeInCAS to 80 and turns off EWSPercentTimeInAD throttling.

New-ThrottlingPolicy -Name ClientThrottlingPolicy2 -EWSPercentTimeInCAS 80 -EWSPercentTimeInAD $null;

To assign a non-default throttling policy to a user, use the Set-Mailbox cmdlet, as follows.

$b = Get-ThrottlingPolicy ClientThrottlingPolicy2;
Set-Mailbox -Identity tonysmith -ThrottlingPolicy $b;

If a user is governed by a non-default throttling policy and you want the user to use the default policy, you might think you can make this change by setting the ThrottlingPolicy parameter to $null. Unfortunately, setting the ThrottlingPolicy parameter to $null doesn't modify the Mailbox object. To make the default throttling policy apply to the user, you must explicitly set the default throttling policy for that user by using the following command.

$policy = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}
Set-Mailbox -Identity tonysmith -ThrottlingPolicy $policy;

If you want to learn which users are governed by a specific throttling policy, run the Get-Mailbox cmdlet and filter the throttling policy identity as shown in the following example. In this example, $policy is the policy for which you are filtering.

Get-Mailbox | where-object {$_.ThrottlingPolicy -eq $policy.Identity}

You can only remove throttling policies that are non-default policies and aren't associated with any mailboxes. To do this, run the Remove-ThrottlingPolicy cmdlet and pass the identity of the throttling policy, using the following command.

Remove-ThrottlingPolicy ClientThrottlingPolicy2

If you have a throttling policy associated with users, you must first reassign those users to another policy, and then you can remove the policy you want to remove. The following example shows how to do this.

$policy = Get-ThrottlingPolicy ClientThrottlingPolicy2;
$mailboxes = Get-Mailbox | where-object {$_.ThrottlingPolicy -eq $policy.Identity};
$defaultPolicy = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true};
foreach ($mailbox in $mailboxes)
{
Set-Mailbox -Identity $mailbox.Identity -ThrottlingPolicy $defaultPolicy;
}
Remove-ThrottlingPolicy ClientThrottlingPolicy2;

You modify an existing throttling policy (including the default) by running the Set-ThrottlingPolicy cmdlet and specifying which parameters to change. For example, to change the EWSMaxConcurrency parameter value for the default throttling policy to 4, you could use the following command.

$a = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}
$a | Set-ThrottlingPolicy -EWSMaxConcurrency 4

Because throttling helps govern the overall usage of Exchange components on an Exchange server, it's often useful to examine how throttling is affecting the system. Exchange offers a set of throttling performance counters per process. An Exchange process such as Outlook Web App will have its own set of counters, for example, and Exchange Web Services will have its own set. In the Windows Performance tool, these counters are called instances.

Return to top

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft