Présentation des stratégies de limitation du client

S'applique à : Exchange Server 2010

Dernière rubrique modifiée : 2009-11-17

Microsoft Exchange Server 2010 utilise les stratégies de limitation de clients pour gérer la performance de votre organisation Exchange. Pour ce faire, Exchange assure le suivi des ressources utilisées par chaque utilisateur et impose des limites de bande passante pour les connexions, le cas échéant.

Entre autres, la limitation de clients vous aide à vous assurer que :

• Les utilisateurs ne sollicitent pas intentionnellement le système.
• Les utilisateurs ne sollicitent pas involontairement le système.
• Les utilisateurs de différentes méthodes de connectivité partagent proportionnellement des ressources.

Contenu de cette rubrique

Stratégies par défaut et stratégies non définies par défaut

Présentation des paramètres de stratégie

Commandes et paramètres de l’environnement de ligne de commande Exchange Management Shell

Tâches courantes de gestion de stratégie de limitation

Compteurs de performance de limitation

Stratégies par défaut et stratégies non définies par défaut

Bien qu’une stratégie de limitation de clients par défaut soit généralement suffisante pour gérer la charge placée sur votre système Exchange, vous pouvez personnaliser la stratégie par défaut ou ajouter des stratégies supplémentaires en fonction des besoins de votre organisation.

Si vous hébergez plusieurs clients dans votre organisation Exchange, vous pouvez définir une charge acceptable pour chaque utilisateur d’un client. De même, si vous êtes une organisation locale, vous pouvez définir une charge acceptable pour chaque utilisateur. Par le biais des stratégies, Exchange évalue la manière dont chaque utilisateur emploie le système et garantit que la charge par utilisateur se trouve dans les limites acceptables définies par la stratégie de l’utilisateur. Le système de limitation de client effectue un suivi de l’usage par utilisateur et se sert de la stratégie de limitation associée à cet utilisateur pour déterminer s’il faut une limitation ou non.

Lors de la création d’une organisation Exchange, une stratégie de limitation par défaut est automatiquement créée et elle gouverne implicitement tous les utilisateurs de cette organisation.

Les installations Exchange 2010 Entreprise comportent une stratégie de limitation par défaut unique appelée Première organisation. Dans les installations de service Outlook Live, chaque client a sa propre stratégie de limitation.

Présentation des paramètres de stratégie

Vous gérez les paramètres de la stratégie de limitation par le biais de l’environnement de ligne de commande Exchange Management Shell, à l’aide des cmdlets Get-ThrottlingPolicy, Set-ThrottlingPolicy, New-ThrottlingPolicy, et Remove-ThrottlingPolicy

La charge acceptable de la stratégie de limitation est définie par les valeurs du paramètre de la cmdlet dans cette stratégie de limitation. Les types de composants couverts par ces stratégies de limitation sont les suivants :

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

Tous ces types de composants ont des paramètres de stratégie au fonctionnement similaire, sauf le type de composant Windows PowerShell.

Les composants les plus courants sont régis par quatre paramètres de stratégie : <Component Acronym>MaxConcurrency, <Component Acronym>PercentTimeInAD, <Component Acronym>PercentTimeInCAS et -<Component Acronym>PercentTimeInMailboxRPC. Les noms des paramètres sont précédés de l’acronyme correspondant au type du composant. Le tableau suivant répertorie les acronymes des types de composants utilisés pour les paramètres des cmdlets de la stratégie de limitation.

Acronymes des types de composants utilisés dans les cmdlets de la stratégie de limitation

Acronyme du composant	Description	Exemple
EAS	Exchange ActiveSync	Dans le paramètre EASPercentTimeInCAS, l’acronyme du composant EAS représente le composant Exchange ActiveSync.
EWS	Services Web Exchange	Dans le paramètre EWSPercentTimeInCAS, l’acronyme du composant EWS représente le composant Services Web Exchange.
OWA	Outlook Web App	Dans le paramètre OWAPercentTimeInCAS, l’acronyme du composant OWA représente le composant Outlook Web App.
IMAP	IMAP4	Dans le paramètre IMAPPercentTimeInCAS, l’acronyme du composant IMAP représente le composant IMAP4.
POP	POP3	Dans le paramètre POPPercentTimeInCAS, l’acronyme du composant POP représente le composant POP3.

Remarque :
Les utilisateurs de messagerie unifiée sont considérés comme des utilisateurs des Services Web Exchange et leurs connexions au serveur Exchange sont limitées en bande passante par les paramètres des Services Web Exchange tels que EWSMaxConcurrency, EWSPercentTimeInAD, EWSPercentTimeInCAS, et EWSPercentTimeInMailboxRPC.

Retour au début

MaxConcurrency

La valeur d’un paramètre de stratégie MaxConcurrency indique le nombre de connexions simultanées qu’un utilisateur précis peut avoir sur un serveur Exchange à la fois. Une connexion est suspendue depuis la réception d’une demande jusqu’à l’envoi de la réponse complète au demandeur. Si des utilisateurs essaient d’envoyer simultanément plus de demandes simultanées que ne l’autorise la stratégie, la nouvelle tentative de connexion échouera. Cependant, les connexions existantes sont toujours valides. <Component Acronym>MaxConcurrency a une plage valide de 0 à 100 compris. Cette valeur doit être paramétrée sur $null pour indiquer que <Component Acronym>MaxConcurrency ne doit pas être limité.

Important :
Ne réglez pas les paramètres de stratégie de limitation sur $null à moins d’en avoir besoin. Les utilisateurs qui ne sont pas limités peuvent donc placer intentionnellement ou par inadvertance une charge importante sur le serveur.

PercentTimeInCAS PercentTimeInAD et PercentTimeInMailboxRPC

La valeur d’un paramètre de stratégie PercentTimeInCAS, PercentTimeInAD, ou PercentTimeInMailboxRPC indique quel pourcentage d’une minute peut être utilisé :

• Exécution du code de serveur d’accès au client (<Component Acronym>PercentTimeInCAS)
• Requêtes LDAP en cours d’exécution (<Component Acronym>PercentTimeInAD)
• Demandes RPC de boîte aux lettres en cours d’exécution (<Component Acronym>PercentTimeInMailboxRPC)

La valeur 100 indique que pour chaque intervalle d’une minute, le processus peut passer 60 secondes de ce temps à consommer la ressource en question. Même s’il semble qu’un processus ne rencontre jamais de limitation avec une valeur paramétrée sur 100, vous devez prendre en compte l’effet de requêtes simultanées. Si un processus fait deux requêtes simultanées qui prennent 60 secondes chacune pour exécuter le code sur le serveur d’accès au client, le processus a en réalité utilisé 120 secondes dans un laps de temps de 60 secondes, représentant ainsi une valeur <Component Acronym>PercentTimeInCAS de 200 %.

Cette valeur doit être paramétrée sur $null pour indiquer que PercentTimeInCAS, PercentTimeInAD, et PercentTimeInMailboxRPC ne doivent pas être limités.

Important :
Ne réglez pas les paramètres de stratégie de limitation sur $null à moins d’en avoir besoin. Les utilisateurs ne sont pas limités dans leur possibilité de placer intentionnellement ou par inadvertance une charge importante sur le serveur.

Il est important de noter que <Component Acronym>PercentTimeInCAS est un sur-ensemble de chevauchement de <Component Acronym>PercentTimeInAD et <Component Acronym>PercentTimeInMailboxRPC. Cela signifie que la dépense dans le temps de traitement du serveur d’accès client sera toujours plus élevée que les dépenses dans <Component Acronym>PercentTimeInAD et <Component Acronym>PercentTimeInMailboxRPC. Cela vient du fait que le composant Exchange doit déjà être en train d’exécuter le code de serveur d’accès client pour faire un Active Directory ou un appel RPC. En outre, la dépense de temps de traitement de <Component Acronym>PercentTimeInCAS ne s’arrête pas pendant les appels LDAP ou RPC. Même si la demande peut être en attente synchronisée d’une réponse de la banque Active Directory ou Exchange, le processus consomme toujours une thread sur le serveur et doit donc continuer de payer les frais pour cet usage. Par conséquent, la valeur <Component Acronym>PercentTimeInCAS doit être paramétrée à un niveau plus élevé que <Component Acronym>PercentTimeInAD et <Component Acronym>PercentTimeInMailboxRPC.

Retour au début

Commandes et paramètres de l’environnement de ligne de commande Exchange Management Shell

Cette section aborde les paramètres Windows PowerShell suivants :

• PowerShellMaxConcurrency
• PowerShellMaxCmdlets
• PowerShellMaxCmdletsTimePeriod
• PowerShellMaxCmdletQueueDepth

PowerShellMaxConcurrency

Dans le contexte d’une gestion à distance de l’environnement de ligne de commande, le paramètre PowerShellMaxConcurrency définit le nombre maximal de sessions Gestion à distance de l’environnement de ligne de commande qu’un utilisateur Gestion à distance de l’environnement de ligne de commande peut ouvrir simultanément. Dans le cadre des Services Web, le paramètre PowerShellMaxConcurrency définit le nombre de cmdlets qu’un utilisateur peut exécuter simultanément. Cette valeur ne correspond pas nécessairement au nombre de navigateurs ouverts par l’utilisateur.

PowerShellMaxCmdlets

Le paramètre PowerShellMaxCmdlets définit le nombre de cmdlets qu’il est possible d’exécuter pendant un laps de temps donné avant d’être limités. Ce paramètre dépend directement de la valeur définie par le paramètre PowerShellMaxCmdletsTimePeriod. Ces deux valeurs doivent être définies en même temps.

PowerShellMaxCmdletsTimePeriod

Le paramètre PowerShellMaxCmdletsTimePeriod définit la période, en secondes, au cours de laquelle un utilisateur peut exécuter un nombre de cmdlets défini par le paramètre PowerShellMaxCmdlets.

PowerShellMaxCmdletQueueDepth

Le paramètre PowerShellMaxCmdletQueueDepth définit le nombre d’opérations qu’un utilisateur peut exécuter simultanément. Cette valeur affecte directement le comportement des paramètres PowerShellMaxCmdlets et PowerShellMaxConcurrency. Par exemple, le paramètre PowerShellMaxConcurrency utilisera au moins deux des opérations définies par le paramètre PowerShellMaxCmdletQueueDepth mais des opérations supplémentaires seront également comptées par rapport au seuil de limitation à chaque exécution de cmdlet. Le nombre d’opérations comptant pour la limitation dépend des cmdlets exécutées. Il est recommandé que la valeur du paramètre PowerShellMaxCmdletQueueDepth soit trois fois supérieure à celle du paramètre PowerShellMaxConcurrency. Ce paramètre n’affectera pas les opérations exécutées à partir du Panneau de configuration  Exchange ou les opérations exécutées par les services Web Exchange.

Gestion des stratégies de limitation de clients

L’environnement de ligne de commande Exchange Management Shell permet de modifier et d’afficher les paramètres de stratégie de limitation de clients à l’aide des cmdlets présentées dans le tableau suivant.

Cmdlets de gestion des stratégies de limitation de clients sur un serveur d’accès au client

Nom de la cmdlet	Description
New-ThrottlingPolicy	Cette cmdlet crée une nouvelle stratégie de limitation.
Remove-ThrottlingPolicy	Cette cmdlet supprime une stratégie de limitation.
Get-ThrottlingPolicy	Cette cmdlet vous permet de visualiser les paramètres d’une stratégie de limitation.
Set-ThrottlingPolicy	Cette cmdlet modifie tous les paramètres disponibles pour une stratégie de limitation.

Remarque :
Pour associer une stratégie de limitation à un utilisateur unique ou à un groupe d’utilisateurs, utilisez le paramètre ThrottlingPolicy avec les cmdlets New-Mailbox et Set-Mailbox.

Gestion des paramètres de stratégie de limitation de clients par utilisateur

Vous pouvez utiliser le paramètre ThrottlingPolicy des cmdlets Set-Mailbox et New-Mailbox de l’environnement de ligne de commande Exchange Management Shell pour associer les stratégies de limitation de client à un utilisateur ou à un groupe d’utilisateurs en modifiant les propriétés de leur boîte aux lettres. Pour plus d’informations, consultez les rubriques Set-Mailbox et New-Mailbox.

Retour au début

Tâches courantes de gestion de stratégie de limitation

Voici quelques méthodes que vous pouvez utiliser pour gérer les stratégies de limitation de clients.

Extraction de la stratégie de limitation par défaut

Par défaut, le paramètre IsDefault des stratégies de limitation de clients est défini sur True. Vous pouvez extraire la stratégie de limitation par défaut à l’aide du filtre where-object. L’exemple suivant montre comment extraire la stratégie de limitation par défaut.

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

Extraction de la stratégie de limitation gouvernant un utilisateur

Vous pouvez définir les stratégies de limitation par utilisateur. Par conséquent, vous souhaiterez peut-être extraire la stratégie régissant un utilisateur spécifique. Vous pouvez obtenir le paramètre ThrottlingPolicy à partir de la boîte aux lettres de l’utilisateur auquel vous vous intéressez et le transmettre à la cmdlet Get-ThrottlingPolicy. Dans l’exemple suivant, on utilise la boîte aux lettres d’un utilisateur nommé Tony Smith.

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

Création d’une nouvelle stratégie de limitation non définie par défaut

Pour créer une stratégie nouvelle non définie par défaut, exécutez la cmdlet New-ThrottlingPolicy et définissez les paramètres que vous souhaitez. Les paramètres que vous omettez hériteront des valeurs de la stratégie de limitation par défaut. L’exemple suivant crée une nouvelle stratégie de limitation, ClientThrottlingPolicy2. La nouvelle stratégie a presque les mêmes paramètres que la stratégie par défaut. La différence est que la nouvelle stratégie non définie par défaut, ClientThrottlingPolicy2, définit EWSPercentTimeInCAS sur 80 et désactive la limitation EWSPercentTimeInAD.

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

Affectation d’une stratégie de limitation non définie par défaut à un utilisateur

Utilisez la cmdlet Set-Mailbox de la manière suivante pour affecter une stratégie de limitation non définie par défaut à un utilisateur.

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

Si un utilisateur est régi par une stratégie de limitation non définie par défaut et que vous voulez que l’utilisateur emploie la stratégie par défaut, vous estimerez peut-être que vous pouvez effectuer ce changement en définissant le paramètre ThrottlingPolicy sur $null. Malheureusement, définir le paramètre ThrottlingPolicy à $null ne modifie pas l’objet Boîte aux lettres. Afin que la stratégie par défaut s’applique à l’utilisateur, vous devez clairement paramétrer la stratégie par défaut à cet utilisateur à l’aide de la commande suivante.

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

Recherche de tous les utilisateurs régis par une stratégie de limitation spécifique

Si vous voulez savoir quels sont les utilisateurs régis par une stratégie de limitation spécifique, exécutez la cmdlet Get-Mailbox et filtrez l’identité de la stratégie de limitation comme le montre l’exemple suivant. Dans cet exemple, $policy est la stratégie que vous filtrez.

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

Suppression de stratégies de limitation

Vous ne pouvez supprimer que les stratégies de limitation qui ne sont pas définies par défaut et qui ne sont associées à aucune boîte aux lettres. Pour cela, exécutez la cmdlet Remove-ThrottlingPolicy et transmettez l’identité de la stratégie à l’aide de la commande suivante.

Remove-ThrottlingPolicy ClientThrottlingPolicy2

Si vous avez une stratégie de limitation associée à des utilisateurs, vous devez d’abord réattribuer ces utilisateurs à une autre stratégie, puis vous pourrez ensuite supprimer la stratégie que vous souhaitez supprimer. L’exemple suivant montre comment effectuer cette opération.

$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;

Modification des stratégies de limitation

Vous pouvez modifier une stratégie de limitation existante (y compris une stratégie par défaut) en exécutant la cmdlet Set-ThrottlingPolicy et en indiquant les paramètres à modifier. Par exemple, pour modifier la valeur du paramètre EWSMaxConcurrency de la stratégie de limitation par défaut sur 4, vous pourriez exécuter la commande suivante.

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

Compteurs de performance de limitation

Comme la limitation contribue à régir l’utilisation générale des composants Exchange sur un serveur Exchange, il est souvent utile de considérer l’impact de la limitation sur le système. Exchange propose un ensemble de compteurs de performance de limitation par processus. Par exemple, un processus Exchange tel que Outlook Web App aura son propre ensemble de compteurs, de même pour les services Web Exchange. Dans l’outil de performance Windows, ces compteurs sont appelés des instances.

Retour au début