Exchange Patch Status-Script

Wenn Sie eine DAG mit vielen Servern patche müssen, dann ist Zeit ein Faktor und ein Server muss erst wieder "bereit" sein ehe der nächste Server angefasst werden darf. Ein Skript hilft für einen Echtzeitstatus z.B. beim Patchen. Siehe auch Exchange 2016 Update Checkliste.

Überlegung

Normalerweise patchen Kunden ihre Exchange Server selbst. Aber da Net at Work auch immer häufiger bei Kunden so genannte "Managed Servcies" anbietet, d.h. auch den Betrieb für den Kunden übernimmt, kommen wir auch in die Pflicht selbst größere Farmen und Server zu patchen. Mit Exchange 2013/2016 ist das schon sehr schön geworden, da Exchange sich selbst "überprüft" und wenn der Loadbalancer richtig konfiguriert ist, dann muss man selbst dort nichts mehr übernehmen. Auf der anderen Seite gibt es die "Start-DAGMaintenance" und "Stop-DAGMaintenance"-Skript in der Form nicht mehr. man "braucht" sie eigentlich auch gar nicht mehr, denn mit wenigen PowerShell-Befehlen lässt sich ein Exchange 2013 und neuer Server in "Wartung" versetzen und auch wieder in Betrieb nehmen.

Dennoch habe ich schon gerne einen Überblick, welche meiner Server gerade "online" und welche eben in Wartung sind und dieser Status sollte fast "Realtime" sein. Ein klassisches Monitoring (SCOM. PRTG etc.) prüfen die Dienste in der Regel zyklisch mit einem größeren Zeitabstand. Zeit ist aber knapp je mehr Server man gerade aktualisiert und vielleicht sogar gleichzeitig "in Wartung " hat.

Wie prüfen?

Ich habe mir dann damit geholfen, mit zwei PowerShell-Skripten den Status von Exchange Servern sehr schnell und häufig zu kontrollieren. Da ich mich auf Exchange 2013 und 2016 beschränkt habe, stehen mir zwei verlässliche Quellen zur Verfügung:

  • ServerComponents (Siehe auch E2013 Troubleshooting)
    Exchange besteht aus mehreren Komponenten, für die Exchange selbst die Funktionsfähigkeit ermittelt und bewertet. Diese Komponenten werden im Falle der Wartung auch administrativ "Down" gesetzt und später wieder aktiviert. Dann sind Sie aber noch nicht "grün" bis Exchange geprüft hat, dass die Komponente auch wieder läuft.
  • HTTP-Healthcheck (Siehe auch E2013 Heathcheck)
    Eigentlich sind die Healthcheck.htm-URLs für die Steuerung der Loadbalancer gedacht. Ein Loadbalancer sollte diese URL regelmäßig abrufen und solange ein 200OK kommt, kann er weiterhin Anfragen von Clients an diesen Server senden. Ansonsten sollte er die Anfragen zu anderen Servern senden

Aus diesen beiden Informationen habe ich die folgenden Skripte erstellt.

Beide Skripte sind aber nicht für den 24x7 Betrieb gedacht, da sie schon auf dem Job-System eine höhere Last generieren. Aber sie helfen beim Patchen den Überblick zu behalten und am Ende die Bestätigung zu haben, dass das System zumindest nach Ansicht der “Managed Availability”-Funktion von Exchange wieder online ist.

Die Skripte starte ich als Admin auf einem PC und die Ausgabe sind HTML-Dateien, die auf diesem PC lokal gespeichert werden.

Show-HealthCheckStatus

Ich nutze dazu mein PowerShell-Skript “show-healthcheckstatus.ps1”, welches sehr schnell immer wieder die “healthcheck.htm” der Server abruft und den Erfolg auf der Konsole aber auch als HTML-Datei ausgibt. Diese kann mit jedem Browser auch über UNC-Pfade geöffnet und betrachtet werden.

Hinweis:
Diese URLs haben bis ca. Nov 2019 auch mit Exchange Online über die Url https://outlook.office365.com/owa/healthcheck.htm u.a. funktioniert. Seit ca Dez 2019 kommt hier aber immer nur ein 404-Fehler.

So sehe ich sehr gut den Status aller Server und der einzelnen Dienste dank der in Exchange eingebauten Funktion des E2013 Heathcheck. Ein “Auto Refresh” sorgt auch auf dem Client für ein “Reload”.

show-healthcheckstatus.2.0.ps1

Hinweis: Das Skript geht per HTTPS auf den FQDN des Servers. Wenn Sie "öffentliche Zertifikate" auf ihrem Server installiert haben, die den FQDN des Servers nicht enthalten, dann führt dies zu einer Zertifikatswarnung und das Skript funktioniert nicht.

In der Regel haben meine Kunden auf ihren Exchange Servern auch immer ein Zertifikat, welches den FQDN des Servers enthält. Das ist auch kein Problem, wenn man eine eigene PKI hat, die auch für "interne Namen" entsprechende Zertifikate ausstellt. Clients greifen in der Regel ja eh über einen Loadbalancer oder Reverse Proxy auf die Exchange Dienste zu und dort kann weiterhin ein öffentliches Zertifikat genutzt werden.

Show-ExComponentStatus

Das zweite Skript “show-excomponentstatus.ps1” ermittelt die Ausgabe der “ServerComponents”, welche beim Patchen dem Server sagen, ob der Server “online” darf oder nicht.

Auch dieses Skript hilft mir dabei, schnell einen aktuellen Überblick über meine DAG beim Patchen zu erhalten. Dies gilt umso mehr, wenn Sie für das eigentliche Update die Überwachungsfunktionen "pausieren" und daher eigentlich blind sind.

show-excomponentstatus.1.1.ps1

Status anzeigen

Beide Skripte legen die Statusberichte als einfache HTML-Datei ab. Der HTML-Code enthält einen "META REFRESH", damit ein Browser diese Seite immer wieder neu lädt.

Daher lasse ich die Skripte auch einen Zeitstempel mit einpflegen, damit Sie So einen Anhaltspunkt haben, wie alt die Daten schon sind.

Sie können die HTML-Datei dann einfach per Browser als lokale Datei oder auch per UNC-Pfad überall öffnen. Wenn Sie das Verzeichnis per IIS veröffentlichen, können Sie auch per HTTP die Daten abrufen. Ich kann also auf den verschiedenen Servern meine Befehle gemäß der Exchange 2016 Update Checkliste durchgehen und quasi von überall mit die Statusseiten anschauen, die auf einem PC irgendwo regelmäßig aktualisiert werden.

Weitere Links