Comment faire pour surveiller et dépanner l'utilisation de mémoire en pool paginée dans Exchange Server 2003 ou Exchange 2000 Server

Traductions disponibles Traductions disponibles
Numéro d'article: 912376 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

la taille ou le nombre de jetons d'accès client peut être le facteur limitant le nombre de clients qui un serveur qui exécute Microsoft Exchange Server peut prendre en charge. Cet article explique comment les jetons de sécurité sont alloués sur un serveur Exchange pour prendre en charge les connexions client. En outre, cet article contient suggestions pour surveiller et contrôler l'utilisation de mémoire jeton.

Chaque jeton d'accès nécessite une mémoire du noyau Microsoft Windows. Le montant varie en fonction de plusieurs facteurs. Appartenance au groupe est un des facteurs plus importants. La taille de la augmente jeton dans proportion directe au nombre d'appartenances aux groupes.

Les scripts de cet article montrent permet de compter les jetons de sécurité et de générer des statistiques sur le nombre de groupes de sécurité auquel appartiennent les utilisateurs Exchange.
Ces informations peuvent aider estimer la taille en mémoire les jetons d'accès sont associés à ces utilisateurs.

INTRODUCTION

Cet article explique comment gérer proactive et réduire l'utilisation de mémoire en pool paginée utilisée par les connexions client à Exchange serveur. Vous pouvez réduire l'utilisation de mémoire en pool paginé en contrôlant la taille et le nombre de jetons d'accès. Correctif 912480 directement réduit le nombre de jetons d'accès client sont utilisés par un client lorsqu'il établit une connexion vers Microsoft Exchange Server 2003 Service Pack 2 (SP2). La suite de cet article décrit comment réduire la taille du jeton d'accès. En outre, cet article décrit les autres méthodes que vous pouvez utiliser pour contrôler, distribuer et optimiser les connexions client dans le contexte de jetons d'accès.

Un correctif pour Exchange 2003 SP2 est disponible pour optimiser l'utilisation de jetons de client. Ce correctif peut réduire la consommation de mémoire jeton lié à des clients MAPI par un tiers de. Vous devez appliquer ce correctif uniquement si vous rencontrez pool paginé mémoire l'épuisement problèmes provoqués par jeton ventilations. Pour plus d'informations sur le correctif 912480, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
912480 Un serveur Exchange Server 2003 qui héberge plusieurs sessions de client Outlook peut exécuter en dehors du mémoire paginée du pool

Plus d'informations

Jetons d'accès

Lorsqu'un compte Windows tente d'accéder un Windows sécurisé ressource, un jeton d'accès est construite. Le jeton d'accès est utilisé pour déterminer si l'accès doit être accordé et le niveau d'accès doit être accordée. Les jetons sont créés par le serveur qui héberge la ressource. Le serveur interroge les contrôleurs de domaine approprié pour obtenir les informations du jetons.

Le jeton d'accès se compose de plusieurs éléments d'informations, plus particulièrement les identificateurs de sécurité (SID) pour le compte d'utilisateur et pour les groupes de sécurité auxquels appartient le compte d'utilisateur. Après qu'un utilisateur s'authentifie sur un serveur, les SID appropriés associés à l'utilisateur et appartenance aux groupes l'utilisateur sont placés dans un jeton d'accès. Un SID est une chaîne de nombres qui identifie une entité de sécurité Windows ou un groupe de sécurité. Pour plus d'informations, consultez le document « sécurité identificateurs référence technique ». Pour afficher ce document, reportez-vous au site de Web Microsoft suivant :
http://technet2.microsoft.com/windowsserver/en/library/a320b892-f678-490d-adf0-fb97984c2bd71033.mspx
SID ne sont aucun secret plus que les noms d'ouverture de session. SID sont des identificateurs numériques uniques associés à des noms d'objet. Le SID reste la même pour la durée de vie d'un objet Active Directory. Par conséquent, le SID peut servir à conclusively identifier un objet indépendamment de la modifier si d'autres attributs d'objet.

Chaque ressource sécurisée sur un serveur a une liste de contrôle d'accès discrétionnaire (DACL) associée. Le DACL répertorie le SID qui sont ou refuser l'accès à la ressource.

Lorsqu'un utilisateur tente d'accéder à une ressource sécurisée, la liste d'identifiants de sécurité dans le jeton de l'utilisateur l'accès est comparée à la liste de SID dans la DACL de la ressource. Si un SID dans le jeton correspond à un SID dans la DACL de la ressource, accès approprié est accordé. Vous ne pouvez pas fiable déterminer le nombre de groupes de sécurité auxquels un compte d'utilisateur appartient en comptant le nombre de groupes répertoriés sur la propriété de membre de l'objet utilisateur. Ceci est dû les quatre facteurs suivants :
  • Imbrication de groupe

    Dans domaines en mode natif Microsoft Windows 2000 ou Windows Server 2003 mode fonctionnel domaines, groupes peuvent être imbriqués manière plus flexible que dans les domaines en mode mixte. Lorsqu'un groupe est ajouté au jeton d'un utilisateur, les SID des groupes imbriqués sont également ajoutés.
  • appartenance au groupe universel

    Si le domaine de compte utilisateur est en mode mixte, les groupes universels ne sont pas ajoutés au jeton d'accès. Dès que le domaine auquel appartient le compte est converti en mode natif ou un des modes fonctionnels Windows Server 2003, les appartenances aux groupes universels sont ajoutés au jeton.
  • SIDHistory

    Comptes qui sont migrées à partir de domaines Microsoft Windows NT 4.0 ou autres domaines Active Directory peuvent avoir plusieurs appartenances de groupe dans leurs attributs SIDHistory. Pour plus savoir SIDHistory, reportez-vous au adresse site Web de Microsoft à l'adresse suivante :
    http://technet.microsoft.com/en-us/library/Bb727125.aspx
    SIDHistory est disponible uniquement pour les domaines de compte utilisateur qui sont déjà en mode natif Windows 2000 ou en mode fonctionnel Windows Server 2003. Si le domaine de compte utilisateur est en mode mixte, groupes de SIDHistory sont ignorées. Dans la pratique, ces groupes doivent existe pas.
  • les groupes locaux de domaine

    Si une ressource sécurisée est hébergée dans une en mode natif Windows 2000 ou le domaine de mode fonctionnel Windows Server 2003, les groupes locaux de domaine dans le domaine de ressources auquel appartient le compte d'utilisateur sont ajoutés au jeton. Par exemple, supposons que qu'un utilisateur dans un domaine tente d'accéder à une ressource dans domaine b. En mode natif Windows 2000 ou en mode fonctionnel Windows Server 2003, tous les groupes locaux de domaine dans Domaine B auquel appartient l'utilisateur sont ajoutés au jeton d'accès. Groupes locaux de domaine dans un domaine auquel appartient l'utilisateur ne seront pas ajoutés au jeton qui est généré par un serveur dans domaine b. C'est parce que domaine local groupes du domaine A sont non pertinentes au domaine b.

Copies jetons

Jeton d'accès un utilisateur est stocké sur le serveur dans la mémoire du noyau de pool paginé. À tout moment, il est probable seront plusieurs copies du jeton de chaque utilisateur dans la mémoire. Par exemple, si un client mappe un partage sur un serveur Windows Server 2003 en utilisant la commande NET USE , deux copies du jeton de l'utilisateur sont conservés sur le serveur pour prendre en charge cette connexion.

Chaque application client qui se connecte à un serveur Exchange est susceptible de générer des copies multiples du jeton utilisateur, selon l'application et sa configuration.

Il y a un montant finie de mémoire en pool paginé disponible. Par conséquent, il existe une limite au nombre de connexions client un serveur peut gérer en même temps. Sur un serveur Windows qui a plus de 1 gigaoctet (Go) de mémoire physique installé, la mémoire de réserve paginée maximale est environ 350 mégaoctets (Mo). Ce montant peut être réduit en mémoire réglant en faveur d'autres ressources qui peuvent être dans offre plus court.

Recommandations de réglage de mémoire pour un serveur Exchange à grande échelle incluent l'utilisation de la /3 GB commutateur boot.ini. Ceci réduit la mémoire paginée maximale à moins de 250 Mo. Dans ce contexte, un serveur Exchange à grande échelle est un qui héberge des milliers de boîtes aux lettres et qui a plus de 1 Go de RAM installée.

Si vous n'utilisez pas le /3 GB commutateur, il est probable que services du serveur Exchange devront être redémarré régulièrement pour défragmenter la mémoire virtuelle. Commercial désactivé la mémoire de noyau paginée du pool de mémoire d'application supplémentaire est un compromis souhaitable. Toutefois, ce compromis signifie que vous devez surveiller plus étroitement l'utilisation de mémoire paginée du pool. Pour plus d'informations sur le réglage de mémoire pour Exchange Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
815372 Comment faire pour optimiser l'utilisation de mémoire dans Exchange Server 2003
En outre, consultez la section "Problèmes de Ruling absence liée de la mémoire" de la feuille « résolution des problèmes Server 2003 performances d'Exchange » blanc. Pour afficher ce livre blanc, reportez-vous au site de Web Microsoft suivant :
http://technet.microsoft.com/en-us/library/4b012bda-8711-4617-9239-f3527de884a3.aspx
Les jetons de client sont généralement le plus gros consommateur unique de mémoire en pool paginée sur un serveur Exchange. Si le jeton utilisateur moyen est importante, la consommation de mémoire paginée est susceptible de devenir un goulot d'étranglement important pour l'évolutivité de Exchange Server.

Comment calculer la taille de jeton

Taille de jeton Accès en octets peut être estimée à l'aide la formule suivante :
[numéro x 12 des droits d'utilisateur] + [jeton surcharge] + [44 x nombre d'appartenances aux groupes] = jeton taille en octets
  • Droits d'utilisateur incluent des droits tels que « ouvrir une session localement » ou « accéder à cet ordinateur depuis le réseau ». Les droits d'utilisateur uniquement qui sont ajoutés à un jeton d'accès sont ces droits de l'utilisateur sont configurés sur le serveur qui héberge une ressource sécurisée. La plupart des utilisateurs Exchange Server sont susceptibles de disposer des droits d'utilisateur uniquement deux ou trois sur le serveur Exchange. Les administrateurs peut-être dizaines de droits d'utilisateur. Chaque droit utilisateur nécessite 12 octets à stocker dans le jeton.
  • Jeton de surcharge inclut plusieurs champs comme le jeton source, délai d'expiration et les informations de l'emprunt d'identité. Pour un utilisateur standard domaine qui n'a pas accès spécial ni de restrictions, jeton de surcharge est probablement entre 400 et 500 octets. En général, estimation 500 octets pour les droits d'utilisateur et jeton de surcharge est plus suffisante.
  • Chaque appartenance au groupe ajoute le groupe SID au jeton avec 16 octets supplémentaires pour les attributs associés et d'informations. La taille maximale possible pour un SID est 68 octets. Toutefois, il est rare pour un SID ce importante. Dans Windows Server 2003 et dans les versions antérieures de Windows, le SID typique pour un utilisateur ou un groupe est 28 octets de longueur. Par conséquent, chaque sécurité groupe auquel un utilisateur appartient en règle générale ajoute 44 octets à taille de jeton de l'utilisateur.

Allocation de mémoire jeton

Si un jeton est inférieure à 4 kilo-octets (Ko), la quantité de mémoire du noyau qui est allouée pour qu'il est exactement ce qui est nécessaire pour contenir le jeton. Par exemple, imaginez un utilisateur standard appartenant aux groupes de sécurité 30. À l'aide de la formule qui est mentionnée dans la section « Comment faire pour calculer la taille du jeton », jeton de l'utilisateur ce serez environ 1,820 octets (groupes 44 octets x 30 + 500 octets généraux = 1,820).

Mais si un jeton est encore légèrement supérieur à 4 Ko (4 096 octets), la quantité de mémoire est alloué par copie atteindre exactement 8 Ko (8,192 octets). Si un jeton est encore légèrement supérieur à 8 Ko, l'allocation de mémoire est accédez à exactement 12 Ko. Par conséquent, chaque fois que la taille de jeton coupe une des ces limites de 4 Ko critiques, est un lien soudain dans l'utilisation de mémoire paginée du pool.

En règle générale, un utilisateur appartenant aux groupes de sécurité plus de 80 sera près ou risque de dépasser la limite de 4 Ko. Par conséquent, l'utilisateur requiert un jeton de 8 Ko. Si un utilisateur appartient à plus de 170 groupes, le jeton est susceptible de nécessitent Ko 12 et ainsi de suite.

L'exemple suivant illustre l'importance est à moniteur et contrôle taille jeton client moyen. Envisagez un Exchange 2003 Service Pack 2 serveur sur lequel tous les clients utiliser Microsoft Office Outlook 2003 en mode mis en cache. Un client en mode mis en cache typique provoque sept ou huit des copies de son jeton doit être généré sur un ordinateur Windows Server 2003. Si le jeton client moyen est exactement 4 Ko, chaque client en mode mis en cache requiert jusqu'à 32 Ko de mémoire paginée du pool.

note Le correctif de service de banque d'informations Microsoft Exchange qui est décrit dans la section « Introduction » peut réduisez le nombre de copies de jetons pour chaque utilisateur en mode mis en cache pour quatre ou cinq au lieu de 7 ou 8. Ce correctif est prévu pour être inclus dans Microsoft Exchange Server 2003 Service Pack 3.

Si le serveur est configuré à l'aide de la /3 GB basculer, il sera 250 Mo de mémoire de réserve paginée allouée sur le serveur. Nous vous recommandons que la consommation de pool paginé standard pour le serveur doit être plus de 200 Mo. Vous devez réserver suffisamment de mémoire pour les pics dans la charge du serveur. Si la mémoire de réserve consommation est généralement plus de Mo 220 paginée, vous devez prendre suit immédiatement pour réduire la charge sur le serveur.

Supposons que 150 Mo de mémoire paginée du pool est disponible pour les jetons de client Exchange Server. Si chaque jeton client est 4 Ko, le serveur peut prendre en affichée au mieux charge plus de 4,500 Outlook en mode mis en cache utilisateurs simultanés avant utilisation jeton deviendra un goulot d'étranglement. Notez qu'appliquer le correctif 912480 augmenterait ce maximum à 7,300 utilisateurs en mode mis en cache. Si taille jeton est pour passer à 8 Ko, le nombre maximal de clients s'être diminuée moitié, indépendamment de si le correctif 912480 a été appliqué.

note Si Outlook 2003 est exécuté en mode en ligne, généralement figurera trois ou quatre copies jetons pour chaque client indépendamment de si le correctif 912480 a été appliqué.

Les symptômes de l'épuisement de la mémoire du noyau

Si les noyau mémoire ressources sont près d'être épuisée, le serveur est lent ou refuse les demandes supplémentaires et des connexions. Applications peuvent échouer subitement. En outre, tente de se connecter au serveur affecté peut renvoyer erreur 1450, « ressources système insuffisantes ». Dans les cas extrêmes, le serveur peut afficher un message d'erreur sur un écran bleu et cesser de répondre.

En outre, les événements suivants peuvent être enregistrés dans le journal système :

L'ID d'événement : 2019
Source : SRV
Description : le serveur a pas pu allouer à partir du système non paginée du pool car la liste est vide.

L'ID d'événement : 2020
Source : SRV
Description : le serveur n'a pas pu allouer de la mémoire paginée de système car celui-ci est vide.

L'ID d'événement : 2000
Source : SRV
Description : le serveur Échec appel à un service système inattendu.

Si un manque de mémoire paginée est temporaire, le serveur est probablement récupérer. Applications peuvent être un peu résister à temporaires pénuries de mémoire. Cependant, aucune application ne peut exécuter indéfiniment si les demandes de ressource critique ne sont pas satisfaites. Si le manque de mémoire paginée dure très long, il est probable déclencher des goulots d'étranglement en cascade. Dans ce cas, le serveur devrez probablement être redémarré pour rendre fonctionnel nouveau.

Sous charge standard, il doit disposer d'environ 50 Mo de mémoire en pool paginée disponible. Si vous avez libres moins de 30 mégaoctets, vous devez prendre suit immédiatement pour réduire la charge sur le serveur.

Mémoire paginée est allouée statiquement pendant Windows démarrage. Le pool ne peut pas être augmenté sans reconfigurer et redémarrer le serveur. La quantité de mémoire en pool paginée disponible dépend de plusieurs facteurs. Ces facteurs incluent les commutateurs de démarrage comme /Userva et /3 GB , les paramètres du Registre et RAM physique.

Comment réduire la taille de jetons d'accès utilisateur

Vous pouvez utiliser les trois stratégies suivantes pour réduire la taille de jeton :
  • Réduire le nombre de groupes de sécurité auxquels appartient chaque utilisateur.
  • Héberger des serveurs Exchange dans un autre domaine que les utilisateurs qui se connectent aux serveurs Exchange.

    Cette stratégie peut réduire la taille de jetons utilisateur en suppression jointes groupes locaux de domaine pour le domaine de compte utilisateur à partir du jeton qui vous est présenté sur le serveur Exchange. Ceci fonctionne parce que les groupes locaux de domaine d'un domaine ne sont pas conservés dans le jeton qui est généré sur un serveur dans un autre domaine.
  • Lorsque vous pouvez convertir les groupes de sécurité en groupes de distribution.

    Taille de jeton est augmenté d'appartenance aux groupes de sécurité, pas les groupes de distribution. Les utilisateurs peuvent appartenir à des milliers de groupes de distribution qui n'affectent pas la taille de jeton. Si un groupe n'est pas en cours utilisé pour refuser ou accorder l'accès à des ressources, elle doit être un groupe de distribution, pas un groupe de sécurité.

Comment réduire le nombre de jetons d'accès dans la mémoire sur le serveur

Comme une fois comme vous avez réduit la taille jeton standard au minimum pratique, l'étape suivante consiste à gérer le nombre de connexions simultanées effectuées sur le serveur. Vous pouvez gérer le nombre de connexions simultanées à l'aide des méthodes suivantes :
  • Limiter les clients non autorisés et les applications.

    Chaque client peut faire plusieurs connexions au serveur. En outre, les différents clients Assurez-vous différents nombres de connexions basées sur un large éventail de facteurs. Vous ne pouvez même pas une liste complète des tous les clients se connecter au serveur. Les utilisateurs peuvent installer Outlook des compléments qui rendent les autres connexions. Les développeurs peuvent exécuter des applications qui apporter plusieurs connexions ou qui n'arrête pas connexions lorsque qu'ils ont terminé. Par conséquent, vous devez analyser types de clients connecter au serveur et quels types d'effets ils avoir sur l'utilisation de la mémoire du noyau. Pour plus d'informations, reportez-vous à la section « Comment faire pour afficher les tailles de jeton allocation ».
  • Supprimer la banque de dossiers publics du serveur. Ensuite, directement aux dossiers publics sur un autre serveur clients.

    Cette action supprime les connexions de dossiers publics qui sont effectuées par les clients.
  • Supprimer les dossiers publics spécifiques qui compte de nombreuses connexions client.

    Bons candidats pour la suppression sont Schedule + disponible/occupé dossier et le Carnet d'adresses en mode hors connexion. Clients doivent effectuer des connexions à ces dossiers lorsqu'ils planifier des rendez-vous ou télécharger le carnet d'adresses.
  • Ajouter des réplicas de dossiers publics largement accessibles pour distribuer le nombre de clients qui se connectent à leur sur plusieurs serveurs.
  • Installer serveurs de dossiers publics dédié afin d'éliminer toutes les connexions de dossiers publics à partir de serveurs de boîtes aux lettres.
  • Distribuer aux utilisateurs épais-connexion uniformément sur plusieurs serveurs. Épais-connexion les utilisateurs sont susceptibles d'être ceux qui disposent de plusieurs ordinateurs ou périphériques et ceux qui sont les utilisateurs mobiles.
  • Distribuer des utilisateurs de jetons de sécurité volumineux sur plusieurs serveurs.
  • Appliquer le correctif 912480 pour une optimisation jeton. Pour plus d'informations sur le correctif 912480, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
    912480 Un serveur Exchange Server 2003 qui héberge plusieurs sessions de client Outlook peut exécuter en dehors du mémoire paginée du pool

Comment faire pour surveiller mémoire en pool paginée sur un serveur Exchange

En règle générale, vous devez avoir 50 Mo de mémoire de pool paginé gratuit disponible sous serveur typique charger conditions. En outre, vous devez avoir 30 Mo d'espace libre sous des charges maximales.

Il est facile de déterminer la quantité de mémoire paginée est actuellement utilisé. Affiche le Gestionnaire des tâches Windows paginée Utilisation du pool dans la zone mémoire du noyau sur l'onglet performances . Vous pouvez également surveiller l'utilisation de mémoire paginée du pool avec le temps en le compteur Octets de réserve Memory\Pool dans le Moniteur système Windows.

Un serveur Exchange qui est configuré pour utiliser le /3 GB commutateur de démarrage aura une taille de mémoire maximale de réserve paginée possible de 250 Mo environ. En outre, ce serveur va avoir un non paginée-pool-mémoire maximum de 128 Mo. Sans le /3 GB basculer, la maximale est 350 Mo de mémoire de pool paginé et 256 Mo de mémoire de réserve non paginée.

Par conséquent, une typique change à grande échelle serveur doit utiliser plus de 200 Mo de paginée mémoire en pool conditions standard. Utilisation de mémoire paginée de plus de 220 Mo nécessite une attention immédiate.

Si vous êtes dans ces limites, et le serveur est signalement des erreurs liées à l'épuisement de mémoire de pool paginé, il est probable que l'allocation de mémoire paginée initial est inférieure que prévu. Cela peut être provoqué par exigences matérielles, par les pilotes de périphérique, ou en réglant mémoire qui réduit initiale paginé allocation de mémoire pool encore plus. Configurations de mémoire volumineuse, par exemple, plus de 4 Go de RAM physique, sont la cause courante de ce problème.

Chaque octet de RAM physique installée sur un serveur nécessite une mémoire du noyau pour adresse et le gérer. La mémoire plus RAM est installée, l'espace d'adressage du noyau plus doit être réservée pour celui-ci. Espace d'adressage peut être emprunté de mémoire en pool paginée pour satisfaire cette demande.

Nous vous recommandons de ne pas installer plus de 4 Go de RAM physique sur un serveur dédié à Exchange Server 2003. Exchange Server rendra une utilisation efficace de 4 Go de mémoire vive (RAM). Toutefois, Exchange Server ne pas bénéficier de RAM supplémentaire même si elle est disponible. Serveurs qui prennent en charge la fonctionnalité de mémoire ajouter importants peuvent également provoquer réductions significatives de la disponibilité de mémoire paginée du pool. Même si plus de 4 Go de mémoire vive (RAM) sont installés, espace d'adressage peut être réservé pour la quantité maximale théorique de hot-add RAM qui a pu être installé.

Vous pouvez utiliser un débogueur du noyau pour afficher la taille de mémoire paginée du pool initial et autres allocations de mémoire du noyau.

important Commandes pouvant être utilisées pendant un session de débogage du noyau peuvent provoquer le système instable ou cesser. Nous vous recommandons arrêter tous les services Exchange Server avant de vous lancer un session de débogage du noyau et que vous redémarrez le serveur après la session.

Configuration d'un noyau traditionnel session pour Windows 2000 de débogage peut constituer une tâche assez complexe. Cette tâche nécessite généralement un ordinateur supplémentaire, câblage spécialisées et un redémarrage du serveur.

Sinon, l'utilitaire LiveKD de Sysinternals peut être utilisé pour démarrer un session à partir de la console du serveur de débogage du noyau. LiveKD ne nécessite pas de redémarrage du serveur. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
894067 L'outil Performance n'affiche pas correctement les entrées de tables de pages système libres disponibles dans Windows Server 2003
Pour Windows Server 2003, le débogueur de noyau KD prend en charge le débogage directement depuis la console serveur sans préparation spéciale ou de matériel. Pour obtenir les outils de débogage pour Windows, reportez-vous au site de Web Microsoft suivant :
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Démarrer le débogueur à l'aide la commande KD.EXE - KL . Ensuite, exécutez la ! vm commande pour afficher la mémoire paginée maximale. Par exemple, exécutez les commandes suivantes :
KD.EXE - KL
!VM

Comment afficher les tailles de jeton allocation

Outlook n'est pas le uniquement client pouvant se connecter à Exchange Server base de données. Compléments Outlook, moteurs de recherche bureau qui incluent les messages rechercher fonctionnalité, clients, de messagerie instantanée et des applications personnalisées peuvent toutes les connexions supplémentaires, provoquer la génération d'autres copies de jetons.

Vous pouvez vérifier l'effet d'un client ou une application à l'aide de l'utilitaire Poolmon.exe dans un environnement de laboratoire. Pour ce faire, procédez comme suit :
  1. Générer un laboratoire isolé Exchange organisation.
  2. Installez Poolmon sur le serveur Exchange. Pour plus d'informations sur la façon de configurer Poolmon.exe, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
    177415 Comment faire pour utiliser Analyseur de pool de mémoire (Poolmon.exe) pour résoudre la mémoire du noyau fuites
  3. Exécutez Poolmon.exe avec la /iToke commutateur ( Poolmon /iToke ). Notez que la /iToke paramètre est sensible à la casse. Cela configurera Poolmon.exe pour afficher uniquement les allocations de jetons. Vous pouvez également utiliser cette commande sur un serveur de production pour afficher totale allocations jetons en temps réel.
  4. Configurer un compte d'utilisateur Active Directory semblable à l'utilisateur d'Exchange Server standard dans votre environnement. C'est-à-dire, configurer un compte d'utilisateur possédant un nombre équivalent d'appartenances aux groupes de sécurité, un profil d'autorisations similaires, etc..
  5. Ouvrez une session sur Exchange Server en tant qu'utilisateur test qui possède les applications client et les configurations que vous souhaitez tester. Attendez quelques minutes après l'ouverture de session pour l'application client à charger complètement et se stabiliser.
  6. Quittez l'application client lorsque vous notez la modification en les jetons octets Poolmon.exe. Vous devrez peut-être faire ce plusieurs fois pour obtenir une lecture précise du nombre d'octets sont libérées lorsque vous quittez le client. Autres allocations de jetons ne peuvent être créées ou détruites en même temps au cours du test.
note Si vous modifiez le compte d'utilisateur, tels qu'en ajoutant ou en supprimant appartenances aux groupes sécurité, vous devez déconnecter le compte à partir de Windows et vous connecter en avant que ces modifications seront répercutées dans le jeton d'accès.

Comment faire pour auditer les appartenances aux groupes

Les exemples de script suivants contiennent des paramètres de ligne de commande et les instructions en haut de chaque script. Vous pouvez coller les scripts dans le bloc-notes et les enregistrer en tant que fichiers .vbs. Ne pas enregistrer les fichiers en tant que fichiers .txt.
  • Le script Groups.vbs imprime les noms de compte d'Exchange Server boîte aux lettres utilisateur et les groupes de sécurité auquel ils appartiennent. En outre, l'impression contient une colonne distincte qui répertorie les groupes de SIDHistory. Vous pouvez limiter le script à un seul serveur Exchange ou obtenir un rapport de plusieurs serveurs Exchange à l'aide d'un caractère générique.

    note Vous ne pouvez pas utilisez un caractère générique (*) pour accéder à tous Exchange des serveurs. Vous devez fournir au moins un nom de serveur partielle. Par exemple, vous pouvez utiliser une chaîne qui est similaire syntaxe la suivante :
    EXCH - HQ - *
  • Le script Groups_statistics.vbs fournit une vue Histogramme basé sur du texte qui vous indique combien d'utilisateurs appartiennent à 50 groupes, groupes 60 70 groupes et ainsi de suite. Cela peut vous aider à déterminer la taille de jeton moyenne probable pour les utilisateurs.
Voir la « procédure pour calculer la taille du jeton » et « Token allocation de mémoire « sections pour détails informations sur la taille de jeton.

Les scripts

Groups.vbs
'==============================================================================
' NAME: Groups.vbs
' AUTHOR: Kyryl Perederiy, Microsoft IT, MACS Engineering
' DATE  : 12/15/2005
' COMMENT: The script runs through all mailbox enabled user objects in the 
' forest and calculates the number of security groups and groups in SID 
' history for each object. User objects can be filtered by Exchange home server.
' PARAMETERS: <output file> <GC Domain Controller> <Domain Naming Context> [<Exchange Server(s)>]
' EXAMPLE: CSCRIPT groups.vbs groups.tsv EXCH-DC-01 dc=root,dc=company,dc=com EXCH-MBX-*
' Version 1.0
'==========================================================================
On Error Resume Next
Set strArgs = WScript.Arguments
Set fso = CreateObject("Scripting.FileSystemObject")
Set fileStream = fso.OpenTextFile(strArgs(0), 2, True, TristateTrue)
fileStream.WriteLine "DN	Mail	Domain	Login	Server	GRP	SIDHISTORY"

Count=0
DCS = strArgs(1) ' Domain Controller
strDomainNC = strArgs(2) ' Domain Naming Context for the forest
strFilter = "(&(mail=*)(objectCategory=person)(objectClass=user)" &_
			"(msExchHomeServerName=*" & strArgs(3) & "))" 'Mail users search filter

Set oConnection = CreateObject("ADODB.Connection") ' Setup the ADO connection
Set Com = CreateObject("ADODB.Command")
oConnection.Provider = "ADsDSOObject"
oConnection.Open "ADs Provider"
Set Com.ActiveConnection = oConnection ' Create a command object on this connection
Com.CommandText = "<LDAP://" & DCS & ":3268/" & strDomainNC & ">;" &_
					strFilter & ";distinguishedName,mail,sAMAccountName," &_
					"msExchHomeServerName,SIDHistory,homeMDB;subtree"

' Set search preferences
Com.Properties("Page Size") = 1000
Com.Properties("Asynchronous") = True
Com.Properties("Timeout") = 120 ' seconds
set oRecordSet = Com.Execute

oRecordSet.MoveFirst

While Not oRecordset.Eof

	Count=Count+1
	DN = oRecordset.Fields("distinguishedName").Value
	Mail = oRecordset.Fields("mail").Value
	Server = oRecordset.Fields("msExchHomeServerName").Value
	Server = Mid(Server,InStrRev(Server,"=")+1)
   	Domain = Split(DN,",DC=")
	Login = UCase(Domain(1)) & "\" & oRecordset.Fields("sAMAccountName").Value
	
	set oDirObject = GetObject("LDAP://" & DCS & "/" & replace(DN,"/","\/"))

	' tokenGroups is a computed attribute that contains the list of SIDs 
	' due to a transitive group membership expansion operation on a given user
	oDirObject.GetInfoEx ARRAY("tokengroups"),0 
	
	' Size of the array correspond to the number of groups
	GROUPS = ubound(oDirObject.GetEx("tokengroups"))+1

	If IsNull(oRecordSet.Fields("SIDHistory").Value ) Then 
		SIDHIST = "0" 
	Else 
		SIDHIST = ubound(oDirObject.GetEx("sidhistory"))
	End If

	WScript.Echo Count & CHR(9) & DN & CHR(9) & GROUPS
	fileStream.WriteLine _
		DN & CHR(9) &_
		Mail & CHR(9) &_
		UCase(Domain(1)) & CHR(9) &_
		Login & CHR(9) &_
		Server & CHR(9) &_
		GROUPS & CHR(9) &_
		SIDHIST & CHR(9)

	oRecordset.MoveNext

Wend

WScript.Echo "Total: " & Count & " users found on the server(s): " & strArgs(3)
Groups_statistics.vbs
'==========================================================================
' NAME: groups_statistics.vbs
' AUTHOR: Kyryl Perederiy, Microsoft IT, MACS Engineering
' DATE  : 12/15/2005
' COMMENT: The script runs through all mailbox enabled user objects in the 
' forest and calculates statistical distribution for group membership.
' PARAMETERS: <output file> <GC Domain Controller> <Domain Naming Context> [<ExchHomeServerName>]
' EXAMPLE: CSCRIPT groups_statistics.vbs groups_statistics.tsv EXCH-DC-01 dc=root,dc=company,dc=com EXCH-MBX-0*
' Version 1.0
'==========================================================================
On Error Resume Next
Dim GROUPS(100)
Set strArgs = WScript.Arguments
Set fso = CreateObject("Scripting.FileSystemObject")
Set fileStream = fso.OpenTextFile(strArgs(0), 2, True, TristateTrue)
fileStream.WriteLine "Groups" & CHR(9) & "Users"

Count=0
DCS = strArgs(1) ' Domain Controller
strDomainNC = strArgs(2) ' Domain Naming Context for the forest
strFilter = "(&(mail=*)(objectCategory=person)(objectClass=user)" &_
			"(msExchHomeServerName=*" & strArgs(3) & "))" 'Mail users search filter

Set oConnection = CreateObject("ADODB.Connection") ' Setup the ADO connection
Set Com = CreateObject("ADODB.Command")
oConnection.Provider = "ADsDSOObject"
oConnection.Open "ADs Provider"
Set Com.ActiveConnection = oConnection ' Create a command object on this connection
Com.CommandText = "<LDAP://" & DCS & ":3268/" & strDomainNC & ">;" &_
					strFilter & ";distinguishedName,sAMAccountName;subtree"

' Set search preferences.
Com.Properties("Page Size") = 1000
Com.Properties("Asynchronous") = True
Com.Properties("Timeout") = 120 'seconds
set oRecordSet = Com.Execute

oRecordSet.MoveFirst

While Not oRecordset.Eof

	Count=Count+1
	set oDirObject = GetObject("LDAP://" & strArgs(1) & "/" &_
		replace(oRecordset.Fields("distinguishedName").Value,"/","\/"))
	oDirObject.GetInfoEx ARRAY("tokengroups"),0
	GRP = ubound(oDirObject.GetEx("tokengroups"))+1
	GROUPS(Int(GRP/10)) = GROUPS(Int(GRP/10)) + 1
	WScript.Echo Count & CHR(9) & oRecordset.Fields("sAMAccountName").Value & CHR(9) & GRP
	oRecordset.MoveNext
Wend
WScript.Echo "Total: " & Count & " users found"
WScript.Echo "See " & strArgs(0) & " for details..."
For i=0 to 100
	fileStream.WriteLine i*10 & CHR(9) & GROUPS(i)
Next

Les produits tiers Cet article décrit sont mentionnés par des sociétés indépendantes de Microsoft. Microsoft garantit pas, ou implicite, concernant les performances ou la fiabilité de ces produits.

Propriétés

Numéro d'article: 912376 - Dernière mise à jour: vendredi 16 novembre 2007 - Version: 2.4
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Enterprise Server
  • Microsoft Exchange 2000 Server Standard Edition
Mots-clés : 
kbmt kbhowto kbinfo KB912376 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 912376
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com