PRTG - Exchange CAS User

Wenn Sie PRTG noch nicht können, dann sollten Sie sich das Programm auf jeden Fall anschauen. Selbst die Freeware mit 10 Sensoren und 60Sek Mindestabfrageinvervall ist für die folgende Aufgabenstellung super geeignet. Wer mag kann aber auch MRTG, RRDTool oder andere Werkzeuge nutzen. Da sich viele Administratoren aber mit eigenen Skripten schwer tun, ist PRTG als GUI-Lösung mit einem eigenen Skript sehr einfach produktiv zu bringen.

Aufgabestellung

Da betreiben meine Kunden mehrere CAS-Server in einem CAS-Array und genau genommen wissen wir gar nicht, wie viele Clientzugriffe darauf verteilt werden. Natürlich sind diese Daten per Performance Counter auszulesen aber einen passenden Sensor, der die Daten von mehreren CAS-Servern ein einem Diagramm kann ich mit Bordmitteln von PRTG meines Wissens nicht anzeigen.

Allerdings ist das Auslesen von Performance-Countern per PowerShell sehr einfache. Die Zahlen können mit PRT z.B.: alle 60 Sekunden erhoben werden.

Da es sich bei dem Sensor um ein Skript handelt, ist natürlich eine Weiterentwicklung möglich. Denkbar wäre die Filterung auf bestimmte Spezialpostfächer (Support, Vertrieb) oder die Trennung nach Systemmessages (PF Replikation), Trennung nach SameServer, SameSite, SameOrg, Internet oder andere Kennzeichen. Die Anwendungsfälle sind beinahe grenzenlos.

Performance-Counter per PowerShell

Es gibt sehr gute Anleitungen zum Auslesen von Performance Countern per PowerShell. Entsprechende Links habe ich am Ende angefügt. Hier die wesentlichen Codezeilen, um die Werte von Exchange 2010 Servern auszulesen:

foreach ($server in $serverlist){
	$RPC = (Get-Counter "\MSExchange RpcClientAccess\User Count" -ComputerName $server).CounterSamples[0].CookedValue
	$OWA = (Get-Counter "\MSExchange OWA\Current unique users" -ComputerName $server).CounterSamples[0].CookedValue
	$EAS = (Get-Counter "\MSExchange ActiveSync\Ping Commands Pending" -ComputerName $server).CounterSamples[0].CookedValue
}

Natürlich muss dieser Teil in einem Code eingebettet werden, die z.B. per Parameter die Servernamen annehmen und eine für PRTG geeignete Ausgabe erzeugen. Das ist aber nicht weiter schwer. Geht es ja nur um die Ausgabe als XML-Struktur. Da hier rein Windows Performance Counter genutzt werden, verwendet das Skript keine Exchange Snapins und ist entsprechend sparsam und schnell.

Einrichtung

Ich habe ihnen den Beispielcode hier zum Download bereit gestellt

prtg-excasuser.ps1
Nach dem Download die Extension ändern und im Explorer die Datei "unblocken"  (Da Download aus dem Internet)

Die Einrichtung ist schnell erzählt.

  1. Kopieren der PS1 nach C:\Program Files(x86)\prtg\custom sensors\exexml
    In diesem Verzeichnis sucht die Probe nach den Skripten. Beachten Sie, dass das Skript auf dem Server installiert werden muss, auf dem die Probe dieses Skript aufruft.
  2. Optional Anlegen eines neuen Device
    Sensoren werden immer einem Device zugeordnet. Auf der Ebene des Device kann dann auch der Benutzername und das Kennwort angegeben werden, mit dem das Skript später gestartet wird. Ich lege daher in der Regel ein Device mit dem Namen des CAS-Servers oder CAS-Array an, unter dem dann die Exchange Skripte und das Dienstkonto zugeordnet sind.
  3. Anlegen eines neuen Sensors (Exe/Script Advanced)
    Unter dem Device lege ich dann einen neuen Sensor vom Typ "Exe/Script Advanced" an, der die folgenden wesentlichen Werte hat.

    Wichtig ist hier die Auswahl des Skript aber auch die Angabe mit welchen Anmeldeinformationen das Skript gestartet wird und wie oft es ausgeführt werden soll. Als "LocalSystem" funktioniert das Skript nur, wenn die Probe direkt auf einem Exchange Server aktiv ist bzw. der Computer Mitglied der "Exchange Server" ist.

Und dann heißt es warten bis die ersten Zahlen "kommen". In der Übersicht sollten Sie als erstes sehen, wann der Sensor das letzte mal gelaufen ist und welche Werte beim letzten Lauf ermittelt wurden:

Hier ist schon an einem CAS-Server gut zu sehen, wie Tagsüber die MAPI-Verbindungen (RPC) deutlich höher sind. Die ActiveSync-Verbindungen hingegen sind fast durchweg auf dem gleichen Niveau während nur eine geringe einstellige Anzahl OWA-Verbindungen genutzt werden.

Weiterentwicklungen und Einschränkungen

Aktuell sind keine großen Veränderungen an dem Skript geplant

Weitere Links