Exporter (0) Imprimer
Développer tout
Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Présentation des stratégies de limitation du client

Exchange 2010
 

S’applique à : Exchange Server 2010 SP3, Exchange Server 2010 SP2

Dernière rubrique modifiée : 2012-11-30

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.

Dans Exchange Server 2010 SP1, toutes les stratégies de limitation de client sont activées par défaut. Si des problèmes surviennent éventuellement en raison de ces stratégies, vous pouvez désactiver la limitation de client. Pour ce faire, définissez tous les paramètres de stratégie sur $Null.

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égie de secours

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. Bien que la 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 l’intermédiaire des stratégies, Exchange évalue l’utilisation du système par chaque utilisateur et garantit que la charge par utilisateur qui en résulte reste dans des limites acceptables, telles que définies par la stratégie de l’utilisateur. Le système de limitation de client effectue le suivi de l’utilisation du système au niveau de chaque utilisateur et recourt à la stratégie de limitation associée à l’utilisateur donné pour déterminer si la limitation doit intervenir.

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

Le cadre de limitation est conçu pour protéger les ressources Exchange. Par conséquent, en cas d’altération ou d’absence de la stratégie non par défaut, la stratégie de limitation se reportera en premier sur la stratégie de limitation par défaut de l’organisation. Cependant, si la stratégie par défaut est altérée ou absente, la stratégie de limitation se reporte sur la stratégie de secours. Comme la stratégie de secours est incorporée dans Exchange, le risque de défaillance est moins grand.

La stratégie de secours est également appliquée aux compte authentifiés, comme les comptes d’ordinateur, les contacts inter-forêts et les comptes Active Directory sans boîtes aux lettres. Ces comptes auront les valeurs de stratégie de secours attribuées. Comme ces comptes utilisent la stratégie de secours, il est impossible de modifier les valeurs de la stratégie.

La stratégie de secours utilise les valeurs suivantes :

 

Type d’accès

MaxConcurrency

PercentTimeinAD

PercentTimeinCAS

PercentTimeinRPC

Autre

Anonyme

1

$null

$null

$null

EAS

10

$null

$null

$null

10 (maxDevices)
$null ($ MaxDeviceDeletesPerMonth

EWS

10

50

90

60

5000 (maxSubscription)
60 (fastSearchTimeout) 1000 (findCountLimit)

IMAP

$null

$null

$null

$null

OWA

5

30

150

150

POP

20

$null

$null

$null

PowerShell

18

$null (maxTenantConcurrency)
$null (maxCmdletsTime$null (MaxCmdlets)
Période)
$null (ExchangeMaxCmdlets)
$null (maxCmdletQueueDepth)
$null (maxDestructiveCmdlets)
$null (maxDestructiveCMdletsTimePeriod)

RCA

2000

5

205

200

CPA

20

205

200

Général

$null (MessageRateLimit)
$null (RecipientRateLimit)
$null (ForwardeeLimit)
$null (cpuStartPercent)

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

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.

noteRemarque :
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.

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

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 à 2147483647 compris. Cette valeur doit être paramétrée sur $null pour indiquer que <Component Acronym>MaxConcurrency ne doit pas être limité.

importantImportant :
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.

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.

importantImportant :
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 appel 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. La valeur <Component Acronym>PercentTimeInCAS doit donc être définie sur une valeur supérieure à la valeur <Component Acronym>PercentTimeInAD et à la valeur<Component Acronym>PercentTimeInMailboxRPC.

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

Cette section aborde les paramètres Windows PowerShell suivants :

  • PowerShellMaxConcurrency

  • PowerShellMaxCmdlets

  • PowerShellMaxCmdletsTimePeriod

  • PowerShellMaxCmdletQueueDepth

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.

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.

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.

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.

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

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.

Pour afficher la syntaxe et les paramètres de ces cmdlets, consultez les rubriques New-ThrottlingPolicy, Remove-ThrottlingPolicy, Get-ThrottlingPolicy et Set-ThrottlingPolicy.

Vous pouvez associer une stratégie de limitation à un objet spécifique. L’objet peut être un utilisateur doté d’une boîte aux lettres, un utilisateur sans boîte aux lettres, un contact ou un compte d’ordinateur. Pour connaître la syntaxe et les paramètres de ces cmdlets, consultez les rubriques Get-ThrottlingPolicyAssociation et Set-ThrottlingPolicyAssociation.

noteRemarque :
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.

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.

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

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

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}

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

Stratégies par défaut et stratégies non définies 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;

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;

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

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}

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;

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

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

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.

Par défaut, la journalisation de la limitation est désactivée pour le service d’accès au client RPC. Vous ne verrez donc pas d’informations de limitation dans les journaux d’accès au client RPC. Pour activer la journalisation de la limitation, procédez comme suit :

  1. Ouvrez le fichier suivant dans un éditeur de texte, par exemple le Bloc-notes : C:\Program Files\Microsoft\Exchange Server\V14\Bin Microsoft.Exchange.RpcClientAccess.Service.exe.config

  2. Dans le fichier, recherchez la section <add key="LoggingTag" value="ConnectDisconnect, Logon, Failures, ApplicationData, Warnings" />.

  3. Entrez Throttling dans la chaîne séparée par des virgules. Par exemple, entrez Throttling dans la chaîne pour qu’elle ressemble à : <add key="LoggingTag" value="ConnectDisconnect, Logon, Failures, ApplicationData, Warnings, Throttling" />.

    Enregistrez et fermez le fichier.

  4. Redémarrez le serveur d’accès au client RPC.

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

 © 2010 Microsoft Corporation. Tous droits réservés.
Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft. Tous droits réservés.