John Rodriguez entführt uns in die Welt der Exchange Troubleshooting Tools

Für alle welche sich bereits mit Exchange 2007 auseinandergesetzt haben, ein sehr Interessanter Vortrag und Überblick über die vorhandenen Möglichkeiten einen Exchange Server zu Troubleshooten.

Die zwei besten Kundenfehler zu denen John gerufen wurde:

1. Kunde hat ein Exchange Problem - Fehler ist bereits gefunden

Ein Exchange Server macht jeden Tag um 08:00 extrem auf sich aufmerksam. Soll also bedeuten die Benutzer machen die IT aufmerksam das alles extrem zäh ist. Der lokale Administrator vor Ort hat das Problem bereits analysiert und ist zum Entschluss gekommen dass es ein I/O Problem ist welches die schlechte Performance verursacht.

Trotzdem wird John hinzugezogen um das Problem genauer zu analysieren. Der Administrator teilt ihm dann mit, dass er das Problem bereits kennt und auch im Performance Monitor nachstellen kann. Gesagt getan, beide sind um ab ca. 07:45 vor perfmon und beobachten die Last der Festplatten. Die Uhr schlägt 8 und die I/O Zeiten gehen massiv nach oben.

John glaubt jedoch nicht dass Exchange daran Schuld ist und überwacht noch weitere Prozesse. Hierbei stellt er fest dass auch die RAM-Auslastung um 08:00 extrem ansteigt. Was ist als passiert?

Durch den Anstieg des Arbeitsspeichers hat Exchange Speicher freigegeben und muss somit mehr auf den Disken arbeiten. Gleichzeitig wurde jedoch immer wenige Arbeitsspeicher freu und der Server beginnt auch noch zum Auslagern auf die Disk. (Somit wäre auch der die langsame I/O Zeit erklärt). Problem war, dass genau um diese Zeit eine Anwendung auf dem Server gestartet wurde welche sehr viel RAM benötigt.

Sie sehen, kein Exchange Problem an sich, doch für die Benutzer funktioniert trotzdem das Mailsystem nicht korrekt.

Übrigens, interessante Aussage von John:

Die Benutzer sind das Weltweit größte Monitoring-System

Dem kann ich nur zustimmen. Egal wie gut ein Monitoring System ist, vermutlich die ersten sind immer die Benutzer die es entdecken. Mal von proaktiven Monitoring (zB Ausfall einer Festplatte in einem RAID-Verbund) abgesehen.

2. Der /3GB Switch und der unwissende Admin

John fragte das Publikum ob Sie den /3GIG Switch kennen. Ich habe nun absichtlich "/3GIG" Switch geschrieben, denn so hat er es auch gesagt. Kurz darauf korrigiert er sich selbst und sagte: Es heißt "/3GB" Switch, also /3GEBE Switch und nicht /3GIG Switch. Warum?

Er war bei einem Kunden und fragte ob der "3/GIG" Switch aktiv sei. Der Admin beantwortete die Frage mit einem klaren "Ja". Nach kurzer Analyse kam er zu dem Entschluss dass der Switch doch nicht aktiv sei. Er sah in der Boot.ini nach und fand dann den Eintrag. Und nun raten Sie mal was dort eingetragen war? Wollen Sie die Lösung noch hören?

Ja genau, der Kunde hatte /3GIG und nicht korrekterweise /3GB dort eingetragen...

So ist es, nur das "Field" weiß wie es geht. :-)

John hat uns auch noch einige Tools vorgestellt:

ExTRA ist eines davon: Microsoft Exchange Troubleshooting Assistant v1.1

Oder kannten Sie den in der Testphase befindlichen Exchange Remote Connectivity Analyzer

Auf Codeplex finden Sie einen sehr guten Viewer: Sie kennen .blg Dateien? Das sind jene Dateien die der Performance-Monitor aufzeichnet. Diese können Sie nun als HTML-Report ansehen: Performance Analysis of Logs (PAL) Tool

Übrigens: Ein wichtiger Satz der für alle Fehler gilt den John auch extra erwähnt hat:

Bevor Sie mit dem Troubleshooten beginnen, sehen Sie im Eventlog von Windows nach. Dort finden Sie die ersten Anhaltspunkte um den Fehler genauer zu analysieren!

Dem kann ich nur zustimmen!

Beitrag erstellt von: Peter Forster, MVP Virtual Machine