Das Überwachen und beheben die Verwendung des ausgelagerten Poolspeichers in Exchange Server 2003 oder in Exchange 2000 Server

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 912376 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

die Größe oder Anzahl von Client-Zugriffstoken der einschränkende Faktor die Anzahl der Clients, die ein Server mit Microsoft Exchange Server unterstützt sein. Dieser Artikel beschreibt Zuteilung von Sicherheitstokens auf einem Exchange-Server Clientverbindungen unterstützen. Darüber hinaus enthält dieser Artikel Vorschläge zum Überwachen und Steuern der token Speicher.

Jede Zugriffstoken erfordert einige Microsoft Windows Kernel-Speicher. Die variiert je nach verschiedenen Faktoren ab. Die Gruppenmitgliedschaft ist einer der wichtigsten Faktoren. Die Größe des im direkten Verhältnis der Anzahl der Gruppenmitgliedschaften token erhöht wird.

Skripts, die dieser Artikel enthält zeigen eine Möglichkeit zum Zählen der Sicherheitstokens und Generieren von Statistiken über die Anzahl der Sicherheitsgruppen, die Benutzer angehören. Diese Informationen können Sie die Größe im Speicher des Zugangs-Token zu schätzen, die mit dieser Benutzer verknüpft sind helfen

EINFÜHRUNG

Dieser Artikel beschreibt die proaktiv verwalten und verringern die Verwendung des ausgelagerten Poolspeichers, der von Client-Verbindungen zu einem Exchange verwendet wird-Server. Sie können die Verwendung von ausgelagerten Pool reduzieren, indem Steuern der Größe und Anzahl der Zugangs-Token. Hotfix 912480 reduziert direkt die Anzahl von Client-Zugriffstoken, die von einem Client verwendet werden, wenn Sie auf Microsoft Exchange Server 2003 Service Pack 2 (SP2) eine Verbindung herstellt. Die restlichen Artikel beschreibt, wie die Größe des Zugriffstokens zu reduzieren. Dieser Artikel beschreibt darüber hinaus andere Methoden, die Sie steuern, verteilen und Optimieren von Clientverbindungen im Kontext des Zugangs-Token verwenden können.

Ein Hotfix für Exchange 2003 SP2 ist verfügbar, um die Client-Token zu optimieren. Dieser Hotfix kann token Speicherverbrauch verringern, die MAPI-Clients von bis zu Drittel verknüpft ist. Sie sollten diesen Hotfix anwenden, nur wenn ausgelagerten Poolspeicher auftreten Speicher Generator Probleme, die durch Zuweisungen token. Weitere Informationen zu Hotfix 912480 finden Sie im folgenden Artikel der Microsoft Knowledge Base:
912480Ein Exchange Server 2003-Server, die viele Outlook-Client-Sitzungen hostet möglicherweise der ausgelagerten Poolspeicher ausgeht.

Weitere Informationen

Zugriffstoken

Wenn ein Windows-Konto versucht, eine gesicherte Windows zugreifen Ressource, ein Zugriffstoken wird erstellt. Das Zugriffstoken wird zum Bestimmen, ob Zugriff gewährt werden soll und wie viel Zugriff gewährt werden soll. Token werden vom Server erstellt, die die Ressource befindet. Der Server sendet die entsprechenden Domänencontroller um token Informationen zu erhalten.

Das Zugriffstoken besteht aus mehreren Teilen von Informationen, insbesondere die Sicherheitskennungen (SIDs) für das Benutzerkonto und für die Sicherheitsgruppen zu denen das Benutzerkonto gehört. Nachdem ein Benutzer auf einem Server authentifiziert hat, werden die entsprechenden SIDs, die der Benutzer und Gruppenmitgliedschaften des Benutzers zugeordnet sind in einem Zugriffstoken eingefügt. Eine SID ist eine Zeichenfolge aus Zahlen, die ein Sicherheitsprinzipal Windows oder eine Sicherheitsgruppe eindeutig identifiziert. Weitere Informationen finden Sie das Dokument "Security Identifiers Technical Reference". Dieses Dokument anzeigen möchten, die folgende Microsoft-Website:
http://technet2.microsoft.com/windowsserver/en/library/a320b892-f678-490d-adf0-fb97984c2bd71033.mspx
SIDs sind keine weitere geheimen als Anmeldenamen. SIDs sind eindeutige numerische Bezeichner, die Objektnamen zugeordnet sind. Die SID Ressourceneinheiten die für die Lebensdauer einer Active Directory-Objekt. Daher kann die SID verwendet werden, um ein Objekt unabhängig von, ob andere Objektattribute ändern conclusively zu identifizieren.

Jede geschützte Ressource auf einem Server verfügt über eine discretionary Access Control List () zugeordnet. Die DACL Listet die SIDs, die gewährt oder verweigert Zugriff auf die Ressource.

Wenn ein Benutzer versucht, eine gesicherte Ressource zuzugreifen, wird die Liste der SIDs im Zugriffstoken des Benutzers zur Liste der SIDs in der DACL der Ressource verglichen. Wenn eine SID im Token eine SID in der DACL der Ressource übereinstimmt, wird der entsprechende Zugriff gewährt. Sie können nicht die Anzahl der Sicherheitsgruppen zuverlässig feststellen, zu denen ein Benutzerkonto gehört durch zählen der Anzahl der Gruppen, die auf die Eigenschaft Mitglied von des Benutzerobjekts aufgelistet sind. Dies ist aufgrund der folgenden vier Faktoren:
  • Gruppenschachtelung

    In Domänen im einheitlichen Modus Microsoft Windows 2000 oder Windows Server 2003 funktionsfähig Modus Domänen kann Gruppen in Domänen im gemischten Modus mehr flexibler als geschachtelte handeln. Wenn eine Gruppe zum Token des Benutzers hinzugefügt wird, werden auch die SIDs von verschachtelten Gruppen hinzugefügt.
  • universelle Gruppenmitgliedschaft

    Wenn der Benutzer Kontodomäne im gemischten Modus ist, werden universelle Gruppen nicht zum Zugriffstoken hinzugefügt. Sobald die Domäne, die das Konto angehört, in einheitlichen Modus oder eine Windows Server 2003-Funktionsmodi konvertiert wird, werden universelle Gruppenmitgliedschaften zum Token hinzugefügt.
  • SIDHistory

    Konten, die von Microsoft Windows NT 4.0-Domänen oder andere Active Directory-Domänen migriert werden möglicherweise viele Gruppenmitgliedschaften in die SIDHistory-Attribute. Weitere Informationen zu SIDHistory der folgenden Microsoft-Website:
    http://technet.microsoft.com/en-us/library/Bb727125.aspx
    SIDHistory ist nur für Domänen mit Benutzerkonten, die bereits im einheitlichen Modus von Windows 2000 oder in Windows Server 2003-Funktionsmodi sind verfügbar. Wenn der Benutzer Kontodomäne im gemischten Modus ist, werden Gruppen von SIDHistory ignoriert. In der Praxis sollten diese Gruppen nicht vorhanden.
  • lokale Gruppen einer Domäne

    Wenn in einem Modus Windows 2000 pur oder Windows Server 2003 funktionsfähig Modus-Domäne eine gesicherte Ressource gehostet wird, werden domänenlokale Gruppen in der Ressourcendomäne zu der das Benutzerkonto gehört zum Token hinzugefügt. Genommen Sie an, dass ein Benutzer in Domäne A Zugriff auf eine Ressource in Domäne b versucht Im einheitlichen Windows 2000-Modus oder in Windows Server 2003-Funktionsmodi werden alle lokalen Domänengruppen in Domäne B zu der der Benutzer gehört dem Zugriffstoken hinzugefügt. Domänenlokale Gruppen in Domäne A, der der Benutzer angehört, werden nicht auf das Token hinzugefügt, die von einem Server in Domäne b generiert wird Dies ist da lokale Domäne von Domäne A irrelevant sind zur Domäne Gruppen b

Token Kopien

Zugriffstoken des Benutzers wird auf dem Server im ausgelagerten Kernel-Speicher gespeichert. Jederzeit werden es wahrscheinlich mehrere Kopien jeder Benutzertoken im Speicher werden. Z. B. Wenn ein Client eine Freigabe auf einem Windows Server 2003-basierten Server mithilfe des Befehls NET USE zugeordnet, zwei Kopien des Zugriffstoken des Benutzers auf dem Server unterstützt diese Verbindung verbleiben.

Jede Clientanwendung, die mit einem Exchange-Server verbunden ist wahrscheinlich mehrere Kopien von das Benutzertoken, abhängig von der Anwendung und deren Konfiguration zu erzeugen.

Eine begrenzte Menge an ausgelagertem Poolspeicher ist verfügbar. Daher ist eine Beschränkung für die Anzahl der Clientverbindungen, die ein Server gleichzeitig verwalten kann. Auf einem Windows-basierten Server, der mehr als 1 Gigabyte (GB) physischem Speicher installiert hat, ist der maximale ausgelagerte Poolspeicher Speicher über 350 Megabyte (MB). Dieser Betrag kann durch die Speicheroptimierung zugunsten von anderen Ressourcen, die in kürzeren Supply möglicherweise reduziert werden.

Optimierungsempfehlungen Speicher einen umfangreichen Exchange-Server setzen die Verwendung der / 3 GB boot.ini-Schalters. Dadurch wird den maximale ausgelagerten Poolspeicher auf weniger als 250 MB reduziert. In diesem Kontext ist ein umfangreicher Exchange-Server eine Hosts Tausende von Postfächern und die mehr als 1 GB RAM verfügt.

Wenn Sie nicht die / 3 GB Schalter, ist es wahrscheinlich, dass Exchange Server-Dienste in regelmäßigen Abständen neu gestartet werden, um virtuellen Speicher defragmentieren müssen. Handelspartner deaktivieren ausgelagerten Kernel-Speicher für zusätzliche Anwendungsspeicher ist sinnvoll Kompromiss. Diese Abwägung bedeutet jedoch, dass Sie die Verwendung von ausgelagerten Pool genauer überwachen müssen. Weitere Informationen für Exchange Server-Speicheroptimierung finden Sie im folgenden Artikel der Microsoft Knowledge Base:
815372Optimieren der Speichernutzung in Exchange Server 2003
Finden Sie außerdem im Abschnitt "Ruling out Speicher-Bound Problems" "Troubleshooting Exchange Server 2003 Performance" weißen Papier. Sie finden dieses Whitepaper auf der folgenden Website von Microsoft:
http://technet.microsoft.com/en-us/library/4b012bda-8711-4617-9239-f3527de884a3.aspx
Client-Token sind in der Regel der größte einzelne Consumer ausgelagerten Poolspeicher auf einem Exchange-Server. Wenn das durchschnittliche Benutzertoken groß ist, ist Auslagerungsspeicher Speicherverbrauch wahrscheinlich eine wichtige Engpass für Exchange Server-Skalierbarkeit.

Wie Sie token-Größe berechnen

Zugriff token-Größe in Bytes kann mithilfe der folgenden Formel geschätzt werden:
[Anzahl der Benutzerrechte 12 X] + [token Aufwand] + [44 X Anzahl der Gruppenmitgliedschaften] = token-Größe in Bytes
  • Benutzerrechte umfassen Rechte wie "Lokal anmelden"oder "auf diesen Computer vom Netzwerk aus zugreifen". Die nur Benutzerrechte, die ein Zugriffstoken hinzugefügt werden, sind diese Benutzerrechte, die auf dem Server konfiguriert sind, die eine gesicherte Ressource hostet. Die meisten Exchange Server-Benutzer werden wahrscheinlich nur zwei oder drei Benutzerrechte auf dem Exchange-Server verfügen. Administratoren müssen eventuell Dutzende von Benutzerrechten. Jedes Benutzerrecht erfordert 12 Byte zum Speichern in das Token.
  • Aufwand Token enthält mehrere Felder wie die token Quelle, die Ablaufzeit und die Identitätswechselinformationen. Für einen typischen Domäne-Benutzer, der kein spezieller Zugriff oder Einschränkungen hat, ist Token Aufwand wahrscheinlich zwischen 400 und 500 Byte liegen. 500 Bytes für Benutzerrechte und Token Aufwand schätzen ist normalerweise mehr als ausreichend.
  • Jede Gruppenmitgliedschaft hinzugefügt Token zusammen mit einer zusätzlichen 16 Bytes zugeordneten Attribute und Informationen die Gruppen-SID. Die mögliche Maximalgröße für eine SID ist 68 Byte. Es ist jedoch selten für eine SID dieser Größe sein. In Windows Server 2003 und früheren Versionen von Windows ist der typische SID für einen Benutzer oder eine Gruppe 28 Bytes Länge. Daher fügt jede Sicherheitsgruppe, die i. d. r. ein Benutzer angehört, 44 Byte hinzu token-Größe des Benutzers.

Token Speicherzuordnung

Ist ein Token weniger als 4 Kilobyte (KB), ist der Kernelspeicher, die für Sie reserviert ist genau was für das Token halten erforderlich ist. Betrachten Sie beispielsweise einen typischen Benutzer, der 30 Sicherheitsgruppen angehört. Indem Sie die Formel, die erwähnt wird im Abschnitt "Berechnen der token-Größe" verwenden, werden Zugriffstoken des Benutzers über 1,820 Byte (44 Bytes x 30 Gruppen + 500 Aufwand Bytes = 1,820).

Aber wenn ein Token auch etwas größer als 4 KB (4.096 Bytes) ist, wird die Speichermenge, die pro Exemplar zugewiesen zu genau 8 KB (8192 Byte) springen. Ein Token auch etwas größer als 8 KB ist, springt die Speicherzuordnung auf genau 12 KB. Jedes Mal, dass die Größe der token eines diese kritischen 4-KB-Grenzen schneidet besteht daher ein plötzlicher springen in der Verwendung von ausgelagertem Poolspeicher.

Im Allgemeinen ein Benutzer, der mehr als 80 Sicherheitsgruppen angehört werden in der Nähe oder gehen über die 4-KB-Begrenzung. Deshalb wird der Benutzer ein 8-KB-Token erforderlich. Wenn ein Benutzer zu mehr als 170 Gruppen gehört, ist das Token wahrscheinlich benötigen 12 KB usw..

Das folgende Beispiel veranschaulicht, wie wichtig es zu überwachen und steuern durchschnittliche Client token-Größe ist. Betrachten Sie ein Exchange 2003 Service Pack 2 auf dem alle Clients Microsoft Outlook 2003 im zwischengespeicherten Modus verwendet. Ein typischer Client zwischengespeicherten Modus bewirkt, dass sieben oder acht Kopien seiner Token, das auf einem Computer mit Windows Server 2003 generiert werden. Wenn das durchschnittliche Clienttoken genau 4 KB ist, erfordert jede zwischengespeicherten Modus-Client bis zu 32 KB ausgelagerten Poolspeicher.

Hinweis: Der im Abschnitt "Einführung" beschriebenen Hotfix für Microsoft Exchange Information Store Service kann die Anzahl von token Kopien für jeden Benutzer im zwischengespeicherten Modus um vier oder fünf anstelle von sieben oder acht reduzieren. Dieser Hotfix wird in Microsoft Exchange Server 2003 Service Pack 3 enthalten sein.

Wenn der Server mithilfe von konfiguriert ist die / 3GB wechseln, werden über 250 MB ausgelagerten Poolspeicher auf dem Server zugewiesen. Es wird empfohlen, dass der typische Auslagerungsspeicher Verbrauch für den Server nicht mehr als 200 MB sein sollte. Sie müssen über genügend Arbeitsspeicher für Spitzen in der Serverlast reservieren. Wenn ausgelagerten Poolspeicher Verbrauch in der Regel mehr als 220 MB ist, sollten Sie die Last auf dem Server nicht verringern sofortige Maßnahmen ergreifen.

Wird vorausgesetzt, dass 150 MB ausgelagerten Poolspeicher für Exchange Server-Client Token verfügbar ist. Wenn jeder Clienttoken 4 KB ist, kann der Server bequem mehrere 4.500 gleichzeitige Outlook im zwischengespeicherten Modus Benutzer unterstützen, bevor token verwenden einen Engpass wird. Beachten Sie, dass Hotfix 912480 Anwenden dieser Maximalwert 7,300 Zwischenspeichermodus Benutzer erhöhen würde. Wenn token-Größe waren zu 8 KB springen, würde die maximale Anzahl von Clients mit der Hälfte, unabhängig davon, ob Hotfix 912480 angewendet wurde reduziert.

Hinweis: Wenn Outlook 2003 im Onlinemodus ausgeführt wird, in der Regel werden drei oder vier token Kopien für jeden Client unabhängig davon, ob Hotfix 912480 angewendet wurde.

Ausfallsymptome des Kernelspeichers

Wenn Kernel Speicherressourcen nahe erschöpft wird, wird der Server wird langsam oder zusätzlichen Anforderungen und Verbindungen ablehnt. Anwendungen können plötzlich fehlschlagen. Verbindungsversuche mit dem betroffenen Server können außerdem Fehler 1450, "Nicht genügend Systemressourcen". zurück. In extremen Fällen kann der Server ein Fehlermeldung auf einen blauen Bildschirm angezeigt und nicht mehr reagiert.

Darüber hinaus wird möglicherweise die folgenden Ereignisse im Systemprotokoll protokolliert.

Ereignis-ID: 2019
Quelle: SRV
Beschreibung: Der Server konnte keinen ausgelagerten Poolspeicher reservieren da der Pool leer war.

Ereignis-ID: 2020
Quelle: SRV
Beschreibung: Der Server konnte nicht aus dem ausgelagerten Pool reservieren, da der Pool leer war.

Ereignis-ID: 2000
Quelle: SRV
Beschreibung: Der Server Aufruf eines Systemdienstes ist unerwartet fehlgeschlagen.

Wenn ein ausgelagerten Pool Speichermangel flüchtig ist, wird der Server wahrscheinlich wiederherstellen. Anwendungen können temporäre Engpässe des Arbeitsspeichers etwas gegen sein. Jedoch kann keine Anwendung kontinuierlich ausgeführt, wenn kritische Ressourcenanforderungen nicht erfüllt werden. Auslagerungsspeicher-Speichermangel sehr lange dauert, ist es wahrscheinlich, cascading Engpässe auszulösen. In einem solchen Fall wird der Server möglicherweise neu gestartet werden, um es wieder funktionsfähig machen verfügen.

Standard Belastung sollte ungefähr 50 MB verfügbaren ausgelagerten Poolspeicher vorhanden sein. Wenn Sie weniger als 30 MB freier Speicherplatz verfügen, sollten Sie die Last auf dem Server nicht verringern sofortige Maßnahmen ergreifen.

Ausgelagerten Poolspeicher wird statisch zugewiesen, während Windows starten. Der Pool kann nicht ohne Neukonfiguration und Neustarten des Servers erhöht werden. Die Größe des verfügbaren ausgelagerten Arbeitsspeichers hängt von mehreren Faktoren ab. Diesen Faktoren zählen Boot-Schalter wie z. B. / USERVA und / 3GB , Registrierungseinstellungen und physischem RAM.

Wie Sie die Größe der Zugriffstoken der Benutzer zu reduzieren

Die folgenden drei Strategien können um token-Größe zu reduzieren:
  • Verringern Sie die Anzahl von Sicherheitsgruppen zu denen jeder Benutzer gehört.
  • Hosten Sie Exchange-Servern in einer anderen Domäne der Benutzer, die den Exchange-Servern eine Verbindung herstellen.

    Diese Strategie kann Verkleinern des Benutzertoken durch Entfernen von lokalen Domänengruppen für die Domäne des Benutzerkontos aus dem Token, das die der Exchange-Server angezeigt wird. Dies funktioniert, da lokale Domänengruppen aus einer Domäne nicht im Token gespeichert, die auf einem Server in einer anderen Domäne generiert wird.
  • Wenn Sie können konvertieren Sie Sicherheitsgruppen in Verteilergruppen.

    Token-Größe wird nicht durch Mitgliedschaft in Sicherheitsgruppen, erhöht Verteilergruppen. Benutzer können zu Tausenden von Verteilergruppen gehören, die token-Größe nicht betroffen. Wenn eine Gruppe nicht verwendet werden wird, verweigern oder Erteilen von Zugriffsberechtigungen für Ressourcen sollte es eine Verteilergruppe nicht in einer Sicherheitsgruppe sein.

Wie Sie die Anzahl der Zugangs-Token im Arbeitsspeicher auf dem Server zu reduzieren

Sobald Sie die typische token-Größe auf praktische Minimum reduziert haben, ist die nächste Schritt die Anzahl der gleichzeitigen Verbindungen zu verwalten, die an den Server vorgenommen werden. Sie können die Anzahl der gleichzeitigen Verbindungen verwalten, indem mithilfe der folgenden Methoden:
  • Beschränken Sie nicht autorisierte Clients und Anwendungen.

    Jeder Client kann mehrere Verbindungen zum Server herstellen. Außerdem, verschiedene Clients unterschiedliche Anzahl von Verbindungen auf Grundlage einer Vielzahl von Faktoren. Nicht auch eine vollständige Liste aller Clients möglicherweise, die auf dem Server verbinden. Benutzer können Outlook-add-ins installieren, die zusätzliche Verbindungen. Entwickler können Anwendungen führen Sie, dass viele Verbindungen oder, nicht herunter Verbindungen, wenn Sie fertig sind. Daher sollten Sie analysieren, was Arten von Clients zu dem Server herstellen und welche Auswirkungen Sie auf Kernel-Speicherauslastung haben. Weitere Informationen finden Sie Abschnitt "token Zuweisung Größen anzeigen".
  • Entfernen Sie den Informationsspeicher für Öffentliche Ordner vom Server. Leiten Sie anschließend Clients auf Öffentliche Ordner auf einem anderen Server.

    Diese Aktion beseitigt für Öffentliche Ordnerverbindungen, die von Clients hergestellt werden.
  • Entfernen Sie bestimmte Öffentliche Ordner, die für viele Clientverbindungen.

    Gute Kandidaten für das Entfernen der Schedule+ Frei/Gebucht werden Ordner und das Offlineadressbuch. Clients stellen zusätzliche Verbindungen zu diesen Ordnern beim Planen von Terminen oder downloaden das Adressbuch.
  • Fügen Sie Replikate des stark Zugriff auf Öffentliche Ordner, die Anzahl der Clients zu verteilen, die auf mehreren Servern eine Verbindung zu Ihnen herstellen.
  • Installieren Sie dedizierten Öffentlichen Ordner-Server alle öffentlichen Ordner-Verbindungen von Postfachservern beseitigen.
  • Gleichmäßiges Verteilen von starker Verbindung Benutzer über mehrere Server hinweg. Dunkles Verbindung Benutzer sind wahrscheinlich Personen mit mehreren Computern oder Geräten und Personen, die Benutzer mobiler Geräte sind.
  • Verteilen Sie Benutzer umfangreiche Sicherheitstokens über mehrere Server.
  • Installieren Sie Hotfix 912480 für die token Optimierung. Weitere Informationen zu Hotfix 912480 finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    912480Ein Exchange Server 2003-Server, die viele Outlook-Client-Sitzungen hostet möglicherweise der ausgelagerten Poolspeicher ausgeht.

Überwachen der ausgelagerten Poolspeicher auf einem Exchange-server

Im Allgemeinen sollten Sie 50 MB freien ausgelagerten Poolspeicher verfügbar unter typischen Server Bedingungen geladen haben. Darüber hinaus sollten Sie die maximale Auslastung 30 MB verfügen.

Es ist leicht zu ermitteln, wie viel ausgelagerten Poolspeicher derzeit verwendet wird. Windows Task-Manager zeigt ausgelagerten Pool Verwendung in den Kernel-Speicher -Bereich auf der Registerkarte Leistung . Sie können auch die Verwendung von ausgelagerten Pool Zeit mit der Indikator Speicher\Auslagerungsseiten: Bytes im Windows-Systemmonitor überwachen.

Ein Exchange-Server, Verwendung konfiguriert ist, die / 3GB Startparameters haben eine maximale ausgelagerte Poolspeicher möglich Speicher Größe von über 250 MB. Dieser Server wird außerdem nicht-ausgelagerten-Pool-Memory maximal 128 MB verfügen. Ohne die / 3GB zu wechseln, die Höchstwerte sind 350 MB für den ausgelagerten Pool und 256 MB für nicht ausgelagerten Poolspeicher.

Eine typische umfangreiche Exchange-Server nicht mehr als 200 MB verwenden soll ausgelagerten daher Speicher-Pool unter typischen Bedingungen. Ausgelagerten Speicherverwendung von mehr als 220 MB erfordert sofortige Aufmerksamkeit.

Wenn Sie innerhalb dieser Grenzen sind, und der Server meldet Fehler, die sich auf ausgelagerten Speicher-Generator beziehen, ist es wahrscheinlich, dass die anfängliche Auslagerungsspeicher Speicherzuordnung kleiner als erwartet. Dies kann durch Hardware Anforderungen von Gerätetreibern, verursacht werden oder durch Speicheroptimierung anfänglichen verringert ausgelagerten Pool Speicherreservierung noch mehr. Großer Arbeitsspeicherkonfigurationen, z. B. mehr als 4 GB physischen Arbeitsspeicher sind die häufigste Ursache für dieses Problem.

Jedes Byte des physischen ARBEITSSPEICHERS, der auf einem Server installiert ist erfordert einige Kernelspeicher und ihn zu verwalten. Je mehr RAM, die installiert ist, der weitere Kernel-Adressraum für Sie reserviert werden muss. Adressraum möglicherweise aus dem ausgelagerten Poolspeicher um diese Anforderung zu erfüllen haben.

Wir empfehlen, dass Sie nicht mehr als 4 GB physischen Speicher auf einem Server installieren, die für Exchange Server 2003 dediziert ist. Exchange Server wird die effiziente Verwendung von bis zu 4 GB RAM festlegen. Jedoch wird Exchange Server keine zusätzlichen Arbeitsspeicher nutzen auch wenn es verfügbar ist. Server, die das Hot Add Memory-Feature unterstützen, können erhebliche Reduzierungen auch die Verfügbarkeit von ausgelagertem Poolspeicher verursacht werden. Auch wenn mehr als 4 GB RAM installiert ist, möglicherweise Adressraum für die theoretische maximale Größe des Hot-add Arbeitsspeicher reserviert werden, die installiert werden konnte.

Einen Kernel-Debugger können Sie die Größe des anfänglichen ausgelagerten Pool und andere Kernel-Speicherzuordnungen anzeigen.

wichtig Befehle, die während einer Debugsitzung Kernel verwendet werden können, können bewirken, dass das System instabil werden oder nicht mehr. Es wird empfohlen, alle Exchange Server-Dienste vor initiieren Sie einen Kernel Debugsitzung zu beenden und Neustart des Servers nach der Sitzung.

Einrichten von einem herkömmlichen Kernel Debugsitzung für Windows 2000 kann eine komplexe Aufgabe sein. Dieser Task erfordert normalerweise eine zusätzliche Computer spezielle Verkabelung und ein Neustart des Servers.

Alternativ kann LiveKD-Dienstprogramm von Sysinternals verwendet werden, um einen Debugsitzung in der Serverkonsole Kernel zu starten. LiveKD erfordert keinen Neustart des Servers. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
894067Das Tool Leistung nicht genau verfügbaren Free System Page Table-Einträge in Windows Server 2003 angezeigt
Für Windows Server 2003 unterstützt KD Kernel-Debugger das Debuggen direkt in der Serverkonsole ohne besondere Vorbereitung oder Hardware. Um die Debugtools für Windows zu erhalten, die folgende Microsoft-Website:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Starten Sie den Debugger mithilfe des Befehls KD.EXE - KL . Führen Sie dann die ! Vm Befehl, um den maximalen ausgelagerten Poolspeicher anzuzeigen. Führen Sie z. B. die folgenden Befehle:
KD.EXE - KL
VM!

Zum Anzeigen von token Zuweisung Größen

Outlook ist nicht im nur-Client, die eine Verbindung zu einem Exchange herstellen, können Server-Datenbank. Outlook-add-ins, desktop Suchmaschinen, die e-Mail suchen-Funktionen, instant messaging-Clients und benutzerdefinierte Anwendungen können alle zusätzliche Verbindungen und führen Sie die Generierung von token zusätzliche Kopien.

Sie können die Auswirkungen von einem Client oder einer Anwendung überprüfen, indem das Dienstprogramm "Poolmon.exe" in einer Laborumgebung. Gehen Sie hierzu folgendermaßen vor:
  1. Generieren einer isolierten Labor Exchange-Organisation.
  2. Installieren Sie Poolmon auf dem Exchange-Server. Weitere Informationen zum Konfigurieren von Poolmon.exe finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    177415Wie Sie Memory Pool Monitor ("Poolmon.exe"), um die Kernel-Speicher zu beheben von Speicherverlusten
  3. Führen Sie Poolmon.exe mit der / iToke Schalter ( Poolmon /iToke ). Beachten Sie, dass die / iToke Parameter wird die Groß-und Kleinschreibung berücksichtigt. Dadurch wird Poolmon.exe anzuzeigenden nur token Zuweisungen konfiguriert. Dieser Befehl können auf einem Produktionsserver Sie auch insgesamt token Zuweisungen in Echtzeit anzeigen.
  4. Konfigurieren einer Active Directory-Benutzerkonto, die den typischen Exchange Server-Benutzer in Ihrer Umgebung ähnelt. Konfigurieren Sie, ein Benutzerkonto, der eine entsprechende Zahl eines Mitgliedschaften in Sicherheitsgruppen, ähnlich wie Berechtigungen Profil und usw. hat.
  5. Melden Sie sich auf Exchange Server als Test-Benutzer mit der Client-Anwendungen und Konfigurationen, die Sie testen möchten. Warten Sie einige Minuten nach der Anmeldung für die Clientanwendung vollständig geladen und stabilisieren.
  6. Beenden der Clientanwendung Sie die Änderung in der token Bytes Poolmon.exe feststellen. Möglicherweise möchten Sie diese mehrmals erhalten, eine genaue Lesen von wie viele Bytes freigegeben werden, wenn Sie den Client beenden. Anderen token Zuweisungen möglicherweise erstellt oder zerstört zur gleichen Zeit während des Tests.
Hinweis: Wenn Sie das Benutzerkonto ändern, müssen z. B. durch Hinzufügen oder löschen Mitgliedschaften in Sicherheitsgruppen, Sie das Konto aus Windows abmelden und melden wieder bevor diese Änderungen in das Zugriffstoken reflektiert werden.

Zum Überwachen der Gruppenmitgliedschaften

Die folgenden Skriptbeispiele enthalten Befehlszeilenparameter sowie Anweisungen am oberen Rand jedes Skript. Die Skripts in Editor einfügen können und dann als VBS-Dateien speichern. Speichern Sie die Dateien nicht als TXT-Dateien.
  • Das Skript Groups.vbs druckt Exchange Server Postfach-Benutzerkontonamen und die Sicherheitsgruppen, die Sie angehören. Darüber hinaus enthält der Ausdruck eine separate Spalte, die Gruppen von SIDHistory auflistet. Können Sie das Skript auf einem einzelnen Exchange-Server beschränken oder erhalten einen Bericht für mehrere Exchange-Server, indem Sie ein Platzhalterzeichen.

    Hinweis: Sie können ein Platzhalterzeichen (1) alle Zugriff auf Exchange-Servern. Sie müssen mindestens einen partiellen Servernamen angeben. Beispielsweise können Sie einer Zeichenfolge, die ähnelt der folgenden:
    EXCH - HQ *
  • Das Skript Groups_statistics.vbs bietet eine textbasierte Histogramm-Ansicht, die Sie anzeigt, wie viele Benutzer zu 50 Gruppen, Gruppen 60, 70 Gruppen usw. gehören. Dies hilft Ihnen, die wahrscheinlich durchschnittliche token-Größe für Benutzer zu bestimmen.
Finden Sie unter "How to token-Größe berechnen" und "Speicherreservierung Token" detaillierte Abschnitte Informationen über token Größen.

Skripts

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

Die in diesem Artikel erwähnten Fremdanbieterprodukte werden von einem Lieferanten hergestellt, der von Microsoft unabhängig ist. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Eigenschaften

Artikel-ID: 912376 - Geändert am: Freitag, 16. November 2007 - Version: 2.4
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Enterprise Server
  • Microsoft Exchange 2000 Server Standard Edition
Keywords: 
kbmt kbhowto kbinfo KB912376 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 912376
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

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