End2End Exchange Latenz

Dieses Skript funktioniert nur mit Exchange 2003 und Outlook 2003, da die erforderliche Schnittstelle erst mit Exchange 2003 per WMI erreichbar und in Exchange 2007 nicht mehr vorhanden ist.

Seit Exchange 2010 SP1 gibt es ein ähnliches Commandlet
Get-StoreUsageStatistics
http://technet.microsoft.com/en-us/library/dd876852.aspx

Auf der Seite Ende zu Ende Monitoring habe ich beschrieben, dass ein einfaches Überwachen von Performance Countern  und des Eventlogs nicht alles ist, um die Leistung eines Servers zu überwachen. Für eine komplette Überwachung und Bewertung der Leistung müssen auch Teste her, die die Antwortzeit beim Client entweder selbst messen oder Messwerte des Clients einsammeln.

Outlook 2003 ist nun der erste Client, welcher mit jeder Anfrage an den Server die benötigte Zeit der vorherigen Anfrage wieder an den Server zurückmeldet und Exchange 2003 stellt eben diese Zahl in einem WMI-Counter bereit. Es war also nur eine Frage der Zeit, bi sich ein passenden VBScript erstellt habe, welches sich auf diesen WMI-Counter registriert und jede Meldung des Servers erhält, gegen Grenzwerte prüft und bei Bedarf eben auch alarmiert.

So funktioniert das Skript

Sicher kann man diese Lösung auch mit C++ oder C# schreiben und als EXE oder sogar Dienst kompilieren. Aber so arg viel langsamer ist ein VBScript auch nicht und es ist auf jeden Server schnell mit Notepad angepasst. Der Schlüssel des Skripts sind folgende Zeilen. Die erste bindet sich ganz normal an WMI an, während die zweite Zeile einen Notification-Event auf die "Exchange_Logon"-Tabelle legt.

Set objSWbemServices = GetObject("winmgmts:{impersonationLevel=impersonate}!"&_
                               "\\srv01\root\MicrosoftExchangeV2")
Set objEventSource = objSWbemServices.ExecNotificationQuery( &_
              "SELECT * FROM __InstanceOperationEvent       "&_
              "WITHIN 10 WHERE TargetInstance ISA 'Exchange_Logon' ")
Set objEventObject = objEventSource.NextEvent()
intlatency = objEventObject.targetinstance.Latency

An der dritten Zeile bleibt das Skript dann ohne weitere CPU-Last stehen, bis eben so ein Event auftritt, welcher in der Folge auszuwerten ist. Mich interessiert nur due Latency, welche ich mit aus dem Event entsprechend hole. Nun will ich ja nicht jeden Messwert der Clients melden und muss aber auch Rücksicht auf unterschiedliche Clients nehmen. Einige sind ja im gleichen LAN und andere könnten ja per VPN von unterwegs arbeiten. Statische Grenzwerte (z.B. bei Überschreitung von 200ms) wären also fehl am Platz.

Aus dem Grund pflegt das Skript ein Dictionary, in dem für jede Kombination aus IP-Adresse, Username, MailboxDN eben ein Mittelwert der letzten Latenzzeiten mitgeführt werden. Nur wenn dann ein Messwert eben aus der Reihe ist, dann wird dieser Vorgang im Eventlog protokolliert.

Zur Sicherheit beendet sich das Skript nach der Verarbeitung von 500 Events von alleine. So kann man sicher sein, dass das Skript nicht permanent läuft und Sie können die Einflüsse auf die Performance erst mal sehen. Diese Abbruchlogik hatte ich mal bei der Anwendung über eine langsame VPN-Verbindung per RDP gebraucht, wo ich ein Skript per CTRL-C nicht abbrechen konnte, da die Aktualisierung des Bildschirms schon die Bandbreite aufgebraucht hat. Diese Logik kann man natürlich einfach außer Kraft setzen.

Download und Anwendung

Das Skript erfordert, dass Sie es mit einem Benutzer starten, welcher sich per WMI mit dem Server verbinden kann. Ich habe es selbst immer als lokaler Administrator auf dem Exchange Server selbst ausgeführt und nicht remote über das LAN.

Kein öffentlicher Download
Das Skript ist in der aktuellen Form nicht "Endkundentauglich", sondern muss noch weitere Tests und Anpassungen erhalten, ehe es zum Download bereitgestellt wird. Es hilft mir aktuell bei Exchange 2003 Servern mit diffusem Performancebild eine Fehlermöglichkeit auszuschließen. Es kann aber nur als Teil einer Gesamtbetrachtung gesehen werden.
Informationen, warum diese Skripte nicht öffentlich sind, finden Sie auf nicht public.

Weitere Links

Keywords:End2End Monitoring