Understanding Client Throttling Policies

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

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.

In Exchange Server 2010 SP1, all client throttling policies are turned on by default. If you are experiencing problems that may be caused by these policies, you can turn off client throttling. To turn off client throttling, you can set all policy parameters to $Null.

Contents

Default and Non-Default Policies

Understanding Policy Parameters

Exchange Management Shell Commands and Parameters

Common Uses for Throttling Policies

Throttling Performance Counters

Fallback Policy

Default and Non-Default Policies

When an Exchange organization is created, a default throttling policy is automatically created that implicitly governs all users within that organization. Although the default client throttling policy is 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.

In Exchange 2010 Enterprise installations, there's a single default throttling policy called First Organization. In multi-tenant deployments, each tenant has its own default throttling policy.

Fallback Policy

The throttling framework is designed to protect Exchange resources. Therefore, if the non-default policy is corrupted or missing, the throttling policy will first fall back to the default throttling policy for the organization. However, if the default policy is corrupted or missing, the throttling policy falls back to the fallback policy. Because the fallback policy is embedded in Exchange, it’s less likely to fail.

The fallback policy is also applied to authenticated accounts, such as computer accounts, cross-forest contacts, and Active Directory accounts that do not have mailboxes. These accounts will have the fallback policy values assigned. Because these accounts use the fallback policy, the policy values cannot be modified.

The fallback policy uses the following values:

Return to top

Understanding Policy Parameters

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

Return to top

MaxConcurrency

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 2147483647 inclusive. To indicate that <Component Acronym>MaxConcurrency should be unthrottled (no limit), this value should be set to $null.

PercentTimeInCAS, PercentTimeInAD, and PercentTimeInMailboxRPC

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.

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 the <Component Acronym>PercentTimeInAD value and the <Component Acronym>PercentTimeInMailboxRPC value.

Return to top

Exchange Management Shell Commands and Parameters

This section discusses the following Windows PowerShell parameters:

• PowerShellMaxConcurrency

• PowerShellMaxCmdlets

• PowerShellMaxCmdletsTimePeriod

• PowerShellMaxCmdletQueueDepth

PowerShellMaxConcurrency

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.

PowerShellMaxCmdlets

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.

PowerShellMaxCmdletsTimePeriod

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

PowerShellMaxCmdletQueueDepth

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.

Return to top

Managing Client Throttling Policies

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

To view the syntax and parameters for these cmdlets, see New-ThrottlingPolicy, Remove-ThrottlingPolicy, Get-ThrottlingPolicy, and Set-ThrottlingPolicy.

You can associate a throttling policy with a specific object. The object can be a user with a mailbox, a user without a mailbox, a contact, or a computer account. For the syntax and parameters for these cmdlets, see Get-ThrottlingPolicyAssociation and Set-ThrottlingPolicyAssociation.

Managing Client Throttling Policy Settings on a Per-User Basis

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

Common Throttling Policy Management Tasks

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

Retrieving the Default Throttling Policy

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}

Retrieving the Throttling Policy That Governs a User

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 | ? {$_.IsDefault};
}
else
{
    $policy = $policyLink | Get-ThrottlingPolicy;
}

Return to top

Creating a New, Non-Default Throttling Policy

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;

Assigning a Non-Default Throttling Policy to a User

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;

Return to top

Finding All Users Governed by a Specific Throttling 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}

Removing Throttling Policies

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;

Return to top

Modifying Throttling Policies

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

Throttling Performance Counters

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.

Enable throttling logging in the RPC Client Access log

By default, throttling logging is disabled for the RPC client access service. Therefore, you will not see throttling information in the RPC Client Access logs. To enable throttling logging, follow these steps:

1. Open the following file in a text editor, such as Notepad: C:\Program Files\Microsoft\Exchange Server\V14\Bin Microsoft.Exchange.RpcClientAccess.Service.exe.config

2. In the file, locate the <add key="LoggingTag" value="ConnectDisconnect, Logon, Failures, ApplicationData, Warnings" /> section.

3. Type Throttling in the comma-separated string. For example, type Throttling in the string that resembles the following: <add key="LoggingTag" value="ConnectDisconnect, Logon, Failures, ApplicationData, Warnings, Throttling" />.

   Save and then close the file.

4. Restart the RPC Client Access service.

Return to top

 © 2010 Microsoft Corporation. All rights reserved.