In diesem Artikel hatte ich bereits ein kleines Script vorgestellt, welches die Exchange HealthCheck URLs prüft. Da ich in meiner privaten Umgebung PRTG für das Monitoring verwende, habe ich für die HealthCheck URLs einen eigenen Sensor verwendet. Zwar bringt PRTG eine ganze Reihe Sensoren für Exchange Server mit, allerdings muss ich aufgrund der Limitierung von 100 Sensoren für die kostenfreie Version mit meinen Sensoren haushalten. Daher der eigene Sensor, der die HealthCheck URLs als Kanäle innerhalb eines Sensors darstellt.
Für PRTG Benutzer gibt es den Sensor hier zum Download:
ExchangeHealthChecks
Einbindung des Sensors in PRTG
Zuerst muss der PowerShell Sensor in der Sensorverzeichnis von PRTG kopiert werden, normalerweise befindet sich das Verzeichnis unter folgendem Pfad:
C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML
Jetzt kann dem Exchange Server ein neuer Sensor hinzugefügt werden, da das Script nur die HealthCheck URLs prüft, müssen es nicht zwingend dem Exchange Server direkt zugeordnet werden, auch jedes andere Gerät kann den Sensor verwenden. In diesem Beispiel wird der Sensor direkt für den Exchange Server anagelegt:
Als Sensortyp muss “Programm/Script (Erweitert)” ausgewählt werden:
Dem neuen Sensor kann jetzt ein Name zugeordnet werden. Unter dem Punkt “Programm/Script” ist nun das PowerShell Script auswählbar, welches zuerst in das Sensorverzeichnis kopiert wurde. Im Feld “Parameter” wird angegeben, welcher Exchange Server geprüft werden soll. Das Script verarbeitet hier nur einen Exchange Server, für mehrere Exchange Server, müssen mehrere Sensoren angelegt, oder das Script entsprechend angepasst werden:
Nach kurzer Zeit sollte der Sensor die ersten Daten liefern, der Wert 200 entspricht dabei “HTTP Status Code 200” (alles ok). Ein anderer HTTP Status Code sorgt für einen Fehler.
Die einzelnen Kanäle können noch angepasst werden. Beispielsweise die “Einheit” auf “HTTP Response” umgestellt werden:
In diesem Beispiel ist ein Kanal des Sensors im Status Fehler, dies deutet auf Probleme mit Outlook Anywhere hin:
Wenn gewünscht, kann in den Sensoreinstellungen noch der primäre Kanal verändert werden, in der Standardeinstellung wird “OWA” genutzt:
Nächster Punkt auf meiner ToDo Liste: PRTG und Sophos UTM Webserver Protection.
Hallo Frank,
ich erhalte den Fehler: XML: Das zurückgelieferte XML entspricht nicht dem erwarteten Schema. (Code: PE233)
Ich habe deine Anleitung 1:1 befolgt.
Ich habe auch schon ein paar Dinge aus dem Kommentarverlauf ausgetestet:
– Das Script wird von der Powershell von verschiedenen Rechnern korrekt ausgeführt (u.A. vom PRTG Server)
– Das generierte XML sieht nach den Beispielen von PRTG i.O. aus
– Statuscodes der URLs sind korrekt eingetragen.
Nur PRTG scheint das XML nicht zu gefallen.
PRTG-Version: 19.2.50.2842 x64
Hier ist die Ausgabe von dem Script ausgeführt auf dem PRTG-Server:
PS C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML> .\ExchangeHealthChecks.ps1
OWA Healthcheck
200
10
1
ECP Healthcheck
200
10
1
Outlook Anywhere Healthcheck
200
10
1
EWS Healthcheck
200
10
1
MAPI Healthcheck
200
10
1
OAB Healthcheck
200
10
1
ActiveSync Healthcheck
200
10
1
Autodiscover Healthcheck
200
10
1
Gruß,
Theo
https://dirkpaessler.blog/2019/01/28/pe233-and-pe231-error-with-a-powershell-script-for-a-custom-xml-sensor-for-prtg/
Falls die Abfrage nicht über den Namen des Servers gemacht werden kann, sondern nur über IP, hilft folgendes, um Zertifikatsmeldungen zu ignorieren (Einfügen nach Zeile 8):
add-type @“
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
„@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
$AllProtocols = [System.Net.SecurityProtocolType]’Ssl3,Tls,Tls11,Tls12′
[System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols
Hallo,
bei mir läuft das prima.
Nur ab und zu ist OWA Check als Fehler drin beim nächsten mal ist alles wieder OK.
Abruf Intervall alle 5-10min.
jemand eine Idee?
Gruß Frank
Aber gerne, anbei der Link zum Screenshot.
https://picload.org/view/rwgirwcw/26-07-_2017_09-32-22.jpg.html
Gruß Peter
Danke Peter,
das XML sieht auf dem ersten Blick OK aus, jedoch liefert es den Statuscode 0, hier müsste bei Erreichbarkeit eigentlich 200 stehen. Du könntest das Script Zeile für Zeile ausführen und die Variablen prüfen, damit sollte sich das Problem feststellen lassen. Schreib mir bei Bedarf einfach eine Mail, ich antworte dann nach meinem Urlaub :-)
Gruß, Frank
Hi,
Bei mir bleiben die Rot. Wenn ich die Seiten aufrufe bekomme ich die 200 angezeigt.
Irgendeine Idee?
Hi Frank,
ja ich bekomme eine folgende XML zurück.. auf dem PRTG-Server.
PS C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML> C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\ExchangeHealthChecks.ps1
OWA Healthcheck
0
10
1
ECP Healthcheck
0
10
1
Outlook Anywhere Healthcheck
0
10
1
EWS Healthcheck
0
10
1
MAPI Healthcheck
0
10
1
OAB Healthcheck
0
10
1
ActiveSync Healthcheck
0
10
1
Autodiscover Healthcheck
0
10
1
Gruß Peter
Hallo Peter,
könntest du mir einen Screenshot oder die Ausgabe per Mail schicken, die XML Tags gehen sonst verloren.
Gruß, Frank
Hallo,
auf welcher Hardware läuft denn bei Dir Privat PRTG?
Ich habe bei mir daheim einen Microserver Gen 8 mit 3x Server 2012 R2 (DC, FS, Exchange 2016) im Einsatz und würde jetzt auch gerne die Überwachung einführen.
Installiere ich das Programm am besten auf den DC oder den FS oder wo wäre der PRTG am besten aufgehoben?
Gruss,
Michael
Hi Michael,
ich habe PRTG als eigene VM laufen, 2 Cores 3 GB RAM, wobei 3 GB RAM schon fast zu viel sind, mit 2 GB würde die VM auch laufen. Wahrscheinlich auch mit 1 Core. Die VM läuft auf ESXi, Hardware ist ein Core i7 6700 mit 32 GB RAM.
Gruß, Frank
Hallo Peter,
Parameter ist da der korrekte interne FQDN angegeben?
Gruß Frank.F
Hi Frank,
ich erhalte in PRTG folgende Meldung:, bin 1:1 deiner Anleitung nachgegangen.
Letzte Meldung:
XML: Structural error in xml file, 1 open items. — JSON: Das zurückgelieferte JSON entspricht nicht der erwarteten Struktur (Access violation at address 0594F9A8. Execution of address 0594F9A8). (Code: PE231)
Gruß Peter
Hallo Peter,
ich schaue mir das noch einmal an. Hast du das Script mal direkt aus der PowerShell aufgerufen? Bekommst du dann ein XML zurück?
Gruß, Frank
Hallo Franky,
bin auf deine Sensoren für die Sophos UTM gespannt. Wir Monitoren z.b. die REDs via SSH-Ping.
Grüße
Uwe