Exchange NOTFALL - Hohe Serverlast

Auf dieser Seite finden Sie Informationen, wie Sie einer plötzlichen sehr hohen Last auf ihrem Server auf die Spurkommen können. Das Wissen um das "woher kommt die Last" ist der erste Ansatz zum Abstellen der Ursache.

Symptome

Zu den große Problemen eines Exchange Administrators gehören Situationen, in denen der Exchange Server anscheinend etwas tut aber nicht das, was man von ihm erwartet. Es scheint so, als ob sich das System mehr mit sich selbst beschäftigen würde also mit der Abarbeitung von Anfragen der Anwender. Das kann sich durch folgenden Symptome zeigen:

  • Hohe CPU-Last
  • Datenbankgröße explodiert
  • Hohe Festplattenaktivität verbunden mit "langsamer" gefühlter Performance
  • Protokolldateien schreiben die Festplatte voll
  • Client bekommt das Fenster "Daten werden abgerufen"
    (Siehe auch Outlook Daten werden abgerufen)

Ehe wir nun für jedes Symptom die entsprechenden Maßnahmen durchgehen erkläre ich ihnen die Werkzeuge, die einem Exchange Administrator so zur Verfügung stehen

Werkzeuge

Folgende Hilfsmittel haben sich für die Fehlersuche als sehr hilfreich herausgestellt:

  • Nachrichtentracking (Exchange Lieferumfang)
    Wenn Sie den Verdacht haben, dass eine Mail "im Kreis läuft, eine Regel ein Ping Pong produziert oder ein Anwender ihr System als Relay missbraucht, dann ist das Nachrichtentracking eine Anlaufstelle, dieses Fehlverhalten zu analysieren. Zwar kann man mit  den Bordmitteln erst einmal nur den Weg einer Nachricht verfolgen, aber oft reicht schon der Blick in das Verzeichnis mit dem Messagetracking. Dort liegen in der Regel 14 Dateien und allein die Größe der Dateien ist ein Hinweis, ob sich das Volumen noch im Rahmen der normalen bewegt
  • SMTP-Tracking (Windows System, per Default OFF)
    Nicht alle Nachrichten gehen "durch" das Exchange Routing, sondern einige werden schon durch den SMTP-Dienst verarbeitet.
  • HTTP/POP3/IMAP4-TRACKING (Windows und Exchange, per Default OFF)
    Auch diese Protokolle helfen mit, besonders aktive Clients zu erkennen und deren Verhalten zu beobachten.
  • NetMon, WireShark und Packetyzerrr
    Diese Programme sind eigentlich "Netzwerkmonitore" mit denen man in die einzelnen Pakete reinschauen kann. Aber allein für statistische Datenerhebungen sind diese Programme ebenfalls nützlich, da Sie alle Kommunikationspartner samt der Anzahl der Pakete aufzeichnen und mehr oder minder nett grafisch anzeigen. Mein Favorit ist hier href="../tools/packetyzer.htPacketyzer. So können Sie bei einem noch laufenden Server vielleicht "besonders" aktive Clients ermitteln.
  • ExMon (Microsoft, Freeware, Addon)
    Diese Programm wird auf dem Exchange Server gestartet und zeigt vor allem auch die Aktivität der MAPI-Clients an, die anders nur sehr schwer zu ermitteln sind. Diese Programm hat mir schon oft geholfen, wenn Anwender etwas "unfreundlich" mit dem Server umgegangen sind, z.B.: massenhaft Daten exportieren oder importieren oder Regel oder Synchronisation sich "daneben" benehmen.
  • ProcessXP (Sysinternals)
    Der Windows Taskmanager ist keine echte Hilfe bei der Analyse von hohen CPU-Belastungen. Bessere Arbeit leistet hier der Process Explorer von Sysinternals,  mit dem Sie sogar bis auf Threadebene herunter gehen können.
  • Perfmon
    Analog dazu können Sie mit PERMON durchaus aussagekräftige Ergebnisse erhalten und Verhalten analysieren. Allerdings ist es hier natürlich von Vorteil, wenn Sie die Daten für den "Normalbetrieb" können. Ein deutlicher Fingerzeig Richtung MOM2005. Aber auch so können Sie natürlich z.B.: die Verbindungen des SMTP-Servers oder die RPC-Aufrufe des Informationsspeichers anzeigen lassen.
  • Filemon (Sysinternals)
    Manchmal ist es aber gar nicht der Exchange Server sondern ein anderer Prozess. Dann ist Filemon ein Hilfsmittel, da Sie damit die einzelnen Dateizugriffe ermitteln können. Leider ist das nur eine lange Liste, in der natürlich auch die Exchange Datenbanken einen großen Anteil haben, aber mit etwas Erfahrung können Sie auch Filtern und sich den "Rest" anschauen. Interessant ist hier z.B.: TEMP aber auch die SMTP-Warteschlange etc. Ein anderer Weg für Dateiaktivitäten zu ermitteln ist  natürlich wieder mit Perfmon und der I/O-Aktivität pro Prozess möglich

Schritte zur Ursachenfindung

Um Ursachen zu finden, müssen Sie was tun und je nach "Schwere" ihres Exchange Servers können Sie noch was tun. Ich unterscheide hier folgende Fälle:

  • Hohe Belastung aber kaum Betriebsstörung
    In dem Fall bemerken die Anwender nur wenig und nur ihnen fällt etwas auf, z.B.: hohe CPU-Last oder schnell abnehmender Platz auf der Festplatte. Entscheiden Sie, ob Sie den Zustand nun einfach nur "passiv" untersuchen möchten und Änderungen außerhalb der Kernarbeitszeit verlegen.
  • Hohe Belastung mit Betriebsstörung aber Administration möglich
    Wenn die Anwender sich aber über starke Einbußen oder gar Ausfälle klagen, dann müssen Sie aktiv werden. Solange Sie aber auf dem Server selbst noch Aktionen ausführen können, sollten Sie diese Chance nutzen und erst einmal" beobachten".
  • Server reagiert sehr träge
    In der Situation können Sie meist nicht mehr viel machen und die Anwender auch nicht. Wenn Sie etwas Geduld mitbringen, kann es aber sinnvoll sein, hier zumindest mal den Taskmanager mit "CTRL-SHIFT-ESC" zu starten, um vielleicht doch etwas zu sehen.
  • Server reagiert überhaupt nicht mehr
    Tja dann ist Hilfe schwer. Vielleicht haben Sie aber noch eine Chance, indem Sie entweder aus der Ferne einige Diente beenden oder vielleicht einfach nur das Netzwerkkabel ziehen. Wenn die Ursache wirklich ein Zugriff über das Netzwerk ist , dann könnte es sein, dass sich der Server doch wieder fängt und Sie weiter analysieren können

Auf jeden Fall sollten Sie den Server nicht einfach ausschalten oder herunterfahren, weil nach einem Neustart meist das Problem wieder für einige Zeit weg ist aber Sie keinen Schritt näher der Lösung sind. Also schauen wir mal, was man "tun" kann.

Symptom und Aktion

Auch wenn es sehr schwer ist eine "Schritt für Schritt"-Anleitung für jeden Fall zu schreiben,  so möchte ich doch versuchen, ein paar Hinweise all denen zu geben, die gar nicht weiter wissen. Sie sollten aber immer sich daran erinnern, dass ein Telefonat mit einem qualifizierten Spezialisten bei Microsoft oder einer Partnerfirma weniger kostet als ein kompletter Datenverlust oder der Vertrauensverlust bei den Mitarbeitern und Firmeninhabern.

Symptom mögliche Aktion

Hohe CPU-Last

Eine hohe CPU-Belastung würde jeder Administrator eines Großrechners freudig begrüßen, da hier oft nach CPU-Zyklen abgerechnet wird und eine CPU ohne Arbeit teuer brachliegendes Kapital ist. Bei PCs hingegen ist eine CPU auf 100% fast immer ein Zeichen einer Fehlfunktion oder zumindest eines temporären Engpasses. Natürlich kann ein langsamer Server auch stundenlang auf 100% laufen ohne dass jemandem dies auffällt da Windows auch eine Priorisierung von Prozessen erlaubt. Sie glauben gar nicht wie viele Exchange Server noch mit einem Pentium 200 "gehen".

Um eine Aussage wie "die CPU hat eine Hohe Last" zu treffen, sollten Sie schon vorab ein paar Tage einfach ihre "normale" CPU-Last z.B. mit Perfmon beobachten.

Trotzdem ist natürlich bei einer unerwarteten hohen CPU-Last der erste Blick der Windows Taskmanager (Schnellstart über CTRL-SHIFT-ESC).

Hier lassen sich sehr schnell die Prozesse und ihre aktuelle CPU-Belastung anzeigen. Wenn Sie dann noch die Sortierung nach der CPU-Belastung ausrichten, dann sollten Sie sehr schnell den fraglichen Prozess finden, welcher die hohe Last produziert. Nur sieht man nicht wirklich viel mehr. Detaillierter werden die Ergebnisse mit dem Process Explorer (Sysinternals), welcher sogar auf die einzelnen Thread herunter gehen kann und auch deren zeitlichen Verlauf einews einzelnen Prozesses anzeigen. Hier am Beispiel des Leerlaufprozesses

Wenn Sie den fraglichen Prozess gefunden haben, müssen Sie anhand des Namens natürlich auch das Programm zurück schließen. In Verbindung mit Exchange sind folgende Prozesse zu sehen:

  • STORE
    Das ist der Informationsspeicherdienst. Das Herz von Exchange.
  • EMSMTA
    Dieser Prozess überträgt Nachrichten per X.400 und den alten EDK-Gateways (Viele Faxserver nutzen noch diesen Weg)
  • EXMGMT
    Exchange Management Prozess. Erlaubt u.a. die Abfrage des Nachrichtentracking per WMI aus der Ferne.
  • MAD
    Exchange Systemaufsicht. Erstellt u.a. Adressbücher, betreibt den RUS etc.
  • EVENTS
    Der Exchange Ereignisdienst (Siehe auch Exchange Skripting), welche Skripte auf dem Server startet.
  • SRSMAIN
    Der Exchange SRS ist nur in einer gemischten Umgebung vorhanden (Exchange 5.5)
  • MSSEARCH
    Indexdienst, der auch in Exchange den Index für die Volltextsuche erstellt und pflegt.
  • INETINFO und W3WP
    IIS Admin Dienst und der WWW-Worker Prozess. Letztlich eine Komponente des Webservers, der Exchange bei OWA unterstützt aber auch bei der Verwaltung der öffentlichen Ordner (WebDAV). Auch der IMAP4 und POP3-Prozess sind Bestandteil des IISADMIN. Aber auch das Exchange Routing ist hier untergekommen.

Auf einem Exchange Server sind aber sehr oft noch andere Dienste wie z.B.: ein Blackberry Server, Virenscanner, Datensicherung und MOM-Agent installiert, die Verursacher einer hohen CPU-Last sind.

Eine Anweisung, wie Sie diese hohe Last eingrenzen, kann ich leider nicht geben, da die Ursachen vielfältig sind. Das kann eine korrupte Mail ebenso sein, wie ein Amok laufender Virenscanner oder Backupprozess.

Datenbankgröße "explodiert";;

Normalerweise haben Exchange Datenbanken die Angewohnheit immer größer zu werden. Das liegt in der Natur der Sache, da jeden Tag neue Nachrichten geschrieben und empfangen werden und die meisten Personen diese natürlich nicht löschen, sondern aufbewahren. Das ist auch nicht schlimm, solange es eine normale Verwendung ist und die Datenbanken "geplant" langsam wachsen. Aber es gibt Situationen, bei denen die Datenbank quasi explosionsartig wächst und an eine der Obergrenzen stößt:
  • Festplatte voll
    Gerade ältere Server sind eher "klein", so dass eine Datenbank dann eben die Festplattenpartition bis auf wenige Bytes voll schreibt. (Siehe auch Exchange NOTFALL - Festplatte voll)
  • 16/18/75 GB Limit Erreicht
    Das andere Limit ist beim Standard Server vorhanden, dessen Datenbank nicht bis 8 TB wachsen darf. (Siehe Exchange NOTFALL - 16 Gigabyte Limit)

Eine sehr große Datenbank hat aber auch noch den Nachteil, dass die Datensicherung viel mehr Zeit und Bandmaterial benötigt und die Handhabung schwerer wird. Daher müssen Sie natürlich wissen, was in der Datenbank enthalten ist und wie Sie diese Daten wieder beseitigen können.

Wenn ihre Datenbank noch läuft, dann ist der Blick mit dem Exchange System Manager natürlich der einfachste Weg die Größe der einzelnen Postfächer zu betrachten und die Ausreißer zu erkennen und zu ermahnen. Die Inhalte selbst können die Anwender selbst oder auch Sie als Administrator auf dem Server z.B.: mit EXMERGE extrahieren und auf dem Server löschen.  Damit werden aber nur Speicherseiten in der Datenbank freigegeben. Die Datenbank selbst wird erst durch ein Offline Defragmentierung (siehe Exchange Datenbank defragmentieren) kleiner. Ehe Sie nun aber sofort defragmentieren, sollten Sie eventuell eine Nacht abwarten, bis Exchange die online Defragmentierung durchgeführt hat. Im Eventlog finden Sie dann nämlich sehr einfach den freien Speicherplatz, den Sie durch eine Defragmentierung gewinnen können. Es wäre nicht das erste mal, dass die Hoffnung auf ein Defrag in Ernüchterung umgeschlagen ist.

Zukünftig sollten Sie mit Postfachbeschränkungen als "Schutzmaßnahme" arbeiten, d.h. damit ein Benutzer durch absichtliche oder unabsichtliche Fehlbedienung nicht einen ganzen Server stört. Seit Exchange 2003 SP2 ist es auch möglich, dass Sie als Administrator per Registrierung eine Obergrenze festlegen. Das ist besonders wichtig, wenn Exchange nicht alleine auf dem Server läuft und daher eine Datenbank besser herunter gefahren wird, als den Server komplett voll zu schreiben und damit andere Dienste in Mitleidenschaft zieht. Aber auch hier sollten Sie sich eine Überwachung (z.B. MOM2005) überlegen, da Exchange entsprechende Warnungen in das Eventlog schreibt.

Ist die Datenbank allerdings schon "herunter" gefahren, so ist guter Rat teuer. Es ist nämlich gar nicht so einfach, eine Datenbank von Ballast zu befreien, die nicht mehr gestartet wird. Hier haben Sie je nach Version vier Optionen

  • Festplattenplatz addieren
    Ist die Datenbank gestoppt, weil die Festplatte voll ist, dann können Sie die Datenbank natürlich bei ausreichend Platz wieder starten. Manchmal reicht es schon, einige andere Daten auf der Festplatte zu komprimieren, temporär auszulagern oder zu löschen. Wenn dies nicht reicht, könnten Sie oftmals seine große externe Festplatte per USB oder Firewire anbinden und die Datenbank dorthin verschieben und starten.
  • Exchange 2003 SP2 Limit erhöhen
    Wenn die Datenbank aufgrund der administrativen Limit von Exchange 2003 SP2 beendet wurde, dann können Sie natürlich einfach in der Registrierung diese Grenze etwas höher stellen und die Datenbank wieder online nehmen.
  • Enterprise Version oder SP2
    Vielleicht haben Sie aber noch Exchange 2003 SP1 oder früher und ihre Datenbank ist bei 16 GB beendet worden. Dann können Sie bei Exchange 2003 natürlich das Service Pack 2 installieren. Bei Exchange 2000 ist ein Update auf Exchange 2003 oder ein Update auf den Exchange 2000 Enterprise Server möglich, um die Datenbank wieder starten zu können.
  • Restore und partielles Roll-Forward
    Wenn all das nicht möglich ist, dann könnten Sie die Datenbank natürlich löschen und vom Backup zurückholen. Wenn Sie dann noch alle Transaktionsprotokolle haben und z.B.: die letzten davon entfernen, können Sie ein Rollforward bis zu einigen MB vor dem Shutdown erreichen. Allerdings ist dieser Weg sehr steinig, da Sie die letzten Mails verlieren und natürlich auch beim Restore und den Folgeaktionen nichts schief gehen darf. Das ist also sicher die schlechteste Option.
  • ESEUTIL
    Mit Exchange 5.5 gab es eine Version von ESEUTIL, um offline aus der Datenbank Nachrichten mit bestimmen Inhalten zu löschen. Dazu muss man natürlich wissen welche das sind und diese Lösung hat damals primär dabei geholfen, Exchange Server mit Virenbefall ("I love you") zu bereinigen. Eine so bereinigte Datenbank kann man natürlich noch defragmentieren und damit wieder etwas verkleinern. Ich weiß aktuell nicht mal, ob diese Funktion bei Exchange 2000/2003 überhaupt noch vorhanden ist und führe Sie daher nur der Vollständigkeit halber an.
  • PowerControls 4 oder Recovery Storage Group
    Es gibt Programme, die eine Datenbank "offline" ohne Exchange öffnen und Inhalte extrahieren können. Sie könnten daher einfach eine "leere" Datenbank anlegen und die Mitarbeiter weiter arbeiten lassen. Die Inhalte könnten Sie dann über eine Recovery Storage Group von einem anderen Server nachträglich einspielen. Sicher eher eine Lösung, wenn Sie sehr schnell wieder Mails senden und empfangen können müssen und Altdaten nicht sofort wieder erforderlich sind.

Sie sehen, dass es mit dem entsprechenden Wissen sehr viele Optionen gibt einen Exchange Server mit diesem Problem wieder in Gang zu bringen. Dennoch ist es natürlich besser, wenn diese Fall gar nicht erst eintritt. Daher prüfen Sie, ob Sie die administrativen Limits von Exchange 2003 SP2 und Postfachgrenzwerte einsetzen und ihren Server proaktiv überwachen.

Hohe Festplattenaktivität verbunden mit "langsamer" gefühlter Performance

Oft sehen Sie auf dem Server eine niedrige CPU-Last aber dennoch scheint der Server irgendwie "träge" zu sein und die Festplatten blinken und leuchten wie verrückt. Auch in diesem Fall ist eine Analyse möglich. Denn Festplatten sind nun mal Mechanik und der langsamste Teil eines Servers. Speziell Positionierung und Datenübertragung sind ein vielfaches langsamer, als CPU, Hauptspeicher und mittlerweile auch Netzwerk übertragen können. Ein langsames Festplattensubsystem ist daher oft der eigentliche Engpass in einem Server. Und solche einen Engpass kann man müssen und erkennen.

Die Lämpchen an den Festplatten sind hierzu überhaupt nicht geeignet, wenn würden diese wirklich nur beim Zugriff leuchte, dann wäre dies so kurz, dass unser menschliches Auge das nicht mal sehen würde. Es sieht ja auch nicht, dass jede Leuchtstoffröhre 100 Mal pro Sekunde kurz aus ist.

Das Hilfsmittel hier ist zu allererst Perfmon und hier die Counter für die Festplattenwarteschlange. Diese zeigen genau an, wie viele ausstehende Aktionen auf die Festplatte warten.

So können Sie gut erkennen, ob die Festplatten der Engpass sind. (Details siehe auch Exchange Sizing - Wie dimensioniere ich die Hardware ?)

Sollte sich herausstelle, dass wirklich die Festplatten beschäftigt sind, dann gilt das Interesse natürlich dem jeweiligen Dienst, welcher die Last erzeugt. Hier gibt es zwei Wege der Sache näher auf den Grund zu kommen.

  • Filemon (Sysinternals)
    Filemon protokolliert alle Dateizugriffe und erlaubt ihnen so zu sehen, welcher Prozess und welches Programm auf welche Dateien zugreift. Leider ist ist Ausgabe dann einfach eine "Liste" der Zugriffe. Eine statistische Auswertung oder Konsolidierung der Daten (Megabyte pro Prozess o.ä.) findet leider nicht statt. Daher ist die "Suche" natürlich etwas mühselig. Allerdings können Sie hier schon gut erkennen, welche Prozesse außer Exchange auf den Festplatten aktiv sind. Vielleicht ist es ja gerade ein Virenscanner, ein Backup oder der Windows Defender auf der Suche nach SpyWare
  • Perfmon (Windows)
    Aber auch der Performance Monitor erlaubt eine Annäherung an das Thema, da Windows für jeden Prozess auch die Anzahl und Menge der I/Os mitprotokolliert. Zwar fallen darunter auch andere Operationen wie Netzwerk und Gerätetreiber aber das Dateisystem macht hier natürlich einen gewichtigen Anteil aus

    Wenn Sie sich daher von allen Prozessen einfach die E/A-Daten anzeigen lassen, dann finden Sie zumindest die "aktivsten" Prozesse

Wenn sie einen "guten" RAID-Controller haben, dann können Sie oftmals auch mit den dazugehörigen Hilfsprogrammen Informationen über dessen Betriebsdaten und die Belegung der Festplatten und BUS-Systeme erhalten. Auch hier kann ein Engpass vorhanden sein, z.B.: wenn Sie ein RAID5 mit 7 Festplatten auf einem SCSI-Bus betreiben und gerade ein Rebuild stattfindet. Lieber einmal mehr schauen. Vielleicht ist ihr Server nur deshalb so langsam, weil das Raid-Controller gerade einen Fehler korrigiert.

Es ist schon vorgekommen, dass auch ein Exchange Server nebenbei als "Dateiserver" dienen durfte. Kontrollieren Sie doch mal, welche Freigaben auf dem Server vorhanden sind und wer darauf gerade zugreift. Auch eine verzögerte Datensicherung kann manchmal tagsüber starten, wenn das defekte Band morgens repariert wird und der Job der Nacht dann erst lost startet.

Leider ist es ansonsten nicht einfach, mit Bordmitteln sehr viel tiefer in die Tätigkeit eines Servers vorzustoßen. Der hierfür sicherlich geeignete FILEMON ist leider nicht für die Ermittlung von Mengen geeignet und nur wenige werden dessen Ausgabe mit Excel oder dem LogParser geeignet umformatieren.

Protokolldateien schreiben die Festplatte voll

Viele Transaktionsprotokolle bedeuten, dass Informationen in die Datenbank geschrieben werden. Meist nimmt dann auch die Größe der Datenbank entsprechend zu. Wenn die Datenbank weiter wächst, dann könnte eine Regel oder ein Client die Ursache sein, die massenhaft Nachrichten an Empfänger in ihrer Datenbank sendet.

Hier können Sie über das Nachrichtentracking oder auch einfach die Anzeige der Postfachgrößen oftmals das fragliche Postfach erkennen. Ein schneller Blick dort hinein zeigt ihnen dann, was darin "los" ist.

Sie können temporär zur Fehlersuche auch einfach mal den SMTP-Dienst und den MTA beenden. Die Anwender können weiterhin arbeiten, nur werden keine Nachrichten mehr übermittelt. Wenn die Protokolldateien dann nicht mehr geschrieben werden, dann ist die Ursache in eine Mail zu suchen, die übertragen wird. Hier können Sie auch mit dem Nachrichtentracking nun auf Spurensuche gehen.

Ist nach dem Stoppen dieser Transportdienste aber immer noch keine Ruhe, dann liegt es wohl am Client, der z.B.: Daten importiert oder über Outlook repliziert. Nun ist es an der Zeit den urheber ausfindig zu machen. mit NetMon, WireShark und Packetyzer und natürlich mit ExMon können Sie auf dem Server versuchen, den Client zu finden, der ihren Server so stark belastet. Wenn Sie den Client gefunden haben können Sie den Anwender bitten ihnen seine aktuelle Tätigkeit zu beschreiben. Es passiert durchaus, dass der Anwender gar nicht bemerkt, dass er ein Problem verursacht. Er kann Outlook beenden, seinen PC herunterfahren oder einfach mal das Netzwerk abtrennen.  Wenn der PC nicht von ihnen erreichbar ist, dann können Sie als Administrator natürlich z.B.: den Leitweg zur IP-Adresse dieses PCs mit einem "ROUTE ADD"  verbiegen, so dass der PC nicht mehr arbeiten kann. Optional können Sie das Konto des Anwenders einfach deaktivieren, aber Sie sollten dazu die Seiteneffekt von Exchange 2000/2003 Disabled Account können. Der Anwender kann ohne weitere Vorkehrungen auch keine Mails mehr empfangen !

Wenn Sie mit EXMON und den anderen Werkzeugen aber keinen Client finden, der ihren Server belastet und auch das beenden des MTA und SMTP-Servers keine Hilfe bringt, dann scheint es sich um eine umfangreichere Problematik zu handeln, die ich hier nicht lösen kann. Sie können natürlich einfach mal den Informationsspeicher beenden und neu starten. Wenn die Clients alle in einem andren Subnetz sind, dann können Sie z.B.: mit

"ROUTE ADD Clientsubnetz Mask 255.x.x.x 1.2.3.4"

diese Netz "unerreichbar" machen und damit alle Clients aussperren ohne den Server selbst von seinen anderen Exchange Servern oder Domaincontrollern zu trennen.

Route ADD ist unter Windows 2008 und höher nicht mehr empfohlen. Nutzen Sie stattdessen netsh (IP routing commands  http://technet.microsoft.com/en-us/library/cc783403(WS.10).aspx)

netsh interface ipv4 add route 1.2.3.4/24 Interface=nicname nexthop=xx.xx.xx.xx store=persistent

Ein anderer häufiger Verdächtiger ist der Virenscanner. Es wäre nicht das erste Mal, dass diese Exchange stören, da Sie über die AVAPI-Schnittstelle ja jede Mail erhalten und bei Bedarf auch verändern. Oftmals  Ich kenne ihren Server nun nicht aber vielleicht hat jemand ja eine Regel auf dem Server, ein Exchange Event Skript oder einen globalen Event Sink eingerichtet.  Wohl dem der eine aktuelle Dokumentation hat.

Knifflig wird es, wenn ihnen in absehbarer Zeit der Festplattenplatz ausgeht oder Sie die Ursache nicht finden. Dann können sie Protokolldateien löschen, indem Sie mit ihrer Backupsoftware z.B.: ein Inkrementelles oder ein volles Backup fahren. Löschen Sie bitte nie Transaktionsprotokolle, solange die Datenbanken noch gestartet sind, da das Risiko einer Fehlbedienung sehr hoch ist. Transaktionsprotokolle löschen ist möglich, denn die Datenbanken beendet sind (Exchange beendet die Datenbanken ebenfalls automatisch, wenn der Platz zur Neige geht). Wenn Sie dann mit ESEUTIL sichergestellt haben, dass die Datenbank konsistent ist, können Sie alte Protokolldateien löschen. Temporär kann auch die umschaltung der Speichergruppe auf "Umlaufprotokollierung" (Circular Logging) den Notstand überbrücken.

Client bekommt das Fenster "Daten werden abgerufen"

Diese Fenster ist seit Outlook 2003 neu und zeigt dem Anwender an, dass eine RPC-Anfrage an den Server etwas länger als erwartet dauert. Dabei kann es sich um temporäre Spitzenlasten des Servers oder eine langsame Anbindung (Speziell über WAN) handeln (Tipp -> Outlook 2003 Cached Mode) Über Gruppenrichtlinien können Sie nun Outlook so einstellen, dass die Warnung nicht mehr nach einer Sekunde kommt, sondern später. Oft reicht das schon aus. Trotzdem sollten Sie ihren Server genauer untersuchen, ob er vielleicht doch an seiner Leistungsgrenze angekommen ist.

Ich hoffe Sie haben vielleicht den ein oder anderen Tipp zur Fehlersuche erhalten und ich wünsche ihnen eine erfolgreiche Suche. Ansonsten sollten Sie immer im Hinterkopf haben, dann für eine Fehlersuche eine gute Vorarbeit, z.B.: in Form einer Ist-Aufnahme der "normalen" Betriebsdaten, damit Sie überhaupt erkennen können, ob etwas nicht mehr normal ist, z.B. mit MOM2005. Auch die Installation entsprechender Tools auf "Vorrat" ist eine sinnvolle Vorarbeit, die Sie direkt nach der Installation des Server durchführen können.

Meine Empfehlung für Tools:
Windows Support Tools, Windows Ressource Kit, ExMON, FileMon, RegMon, Paketyzer, Process Explorer, WinDirStat, ExBPA

Weitere Links