Exchange 2016 Update Checkliste

Die Checkliste kann mit wenigen Anpassungen auch mit Exchange 2013 genutzt werden.

Für die Installation ein Exchange Updates ist eine Checkliste sinnvoll, um das Update möglichst reibungslos und ohne Ausfälle durchführen zu können. Gerade in Umgebungen mit Loadbalancer und DAGs ist Verfügbarkeit ein wichtiges Ziel. Mit einem strukturierten Vorgehen sollten die meisten Anwender nicht einmal bemerken, wenn die Server nacheinander aktualisiert werden. Voraussetzung ist natürlich, dass Loadbalancer so konfiguriert sind, dass Sie eine geplanten Wartung erkennen und den Server nicht weiter benutzen und dass die Präferenzen und Verteilung Datenbanken so konfiguriert ist, dass diese sinnvoll auf andere Server umgewechselt werden können.

Basiswissen Exchange 2016 Updates

Mittlerweile sollte es sich herumgesprochen haben, dass "Cumulative Updates" nichts mehr mit den früheren Patches zu tun haben, sondern quasi immer "Vollinstallationen" sind. Sie können das aktuellste CU nutzen, um einen neuen Exchange Server zu installieren oder einen bestehenden Server zu aktualisieren. In der Regel binden Sie das CU als ISO-Image ein und starten das Exchange Setup. Ein paar Dinge sind dabei aber zu beachten

Sonderfall MSCORSW

Für die Installation von CU5 ist z.B. das .NET Framework 4.6.2 erforderlich. Wenn dies noch nicht installiert ist, dann muss dies vorab erfolgen und erfordert einen Neustart. Nach dem Neustart ist das Setup aber noch nicht fertig, denn im Hintergrund ist die ".NET Runtime Optimization" aktiv. dahinter verbirgt sich ein Dienst, der als "MSCORSE.EXE" bekannt ist und installierten Code für die vorhandene Plattform "optimiert". Das passiert wie geschrieben im Hintergrund und ohne die Applikation zu stören. Die CPU-Last ist etwas höher und das System erscheint träger. Aber das Exchange Setup prüft die Arbeit dieser Komponente und solange der Prozess noch aktiv ist, kann das Setup nicht starten. Hier ist etwas Geduld gefragt. Starten Sie das Setup einfach einige Minuten später noch einmal.

Sonderfall WMI-Dienst

Ein zweite Hürde kann der WMI-Dienst sein. Das Exchange Setup deaktiviert den Dienst und versucht diesen dann auch zu beenden. Bei CU5 passiert dies etwa bei"9%" des Setup-Prozess. Wenn ihr Setup hier länger hängen bleibt, dann könnte es sein, dass das Dienst sich eben aktuell nicht beenden lässt. Vielleicht wird er gerade von ihrer Monitoring-Lösung zur Abfrage von Systemdaten genutzt. Sie können warten, bis das Setup abbricht und dann den Server neustarten. Da der Dienst vom Setup auf "deaktiviert" gesetzt wurde, bliebt er nach dem Neustart ungestartet. Wenn der Dienst auf "stopping" steht, dann können Sie mit etwas Erfahrung können Sie auch den entsprechenden Prozess über den Taskmanager unter Services ermitteln:

Über die Prozess-ID können Sie den Prozess dann finden und beenden.

Offiziell wird dieser Weg natürlich nirgends beschrieben und dürfte daher auch als "unsupported" gelten.

Vorarbeiten

Es klingt trivial aber laden sie vorher alle erforderlichen Installationsdateien auf den Server herunter, ggfls. Sie sollten diese entpackt oder als ISO-Datei in VMs eingebunden werden. Eine Installation über UNC-Pfade ist nicht zu empfehlen. Lesen Sie das README und die Systemvoraussetzungen durch und prüfen Sie Drittprodukte auf Kompatibilität. Insbesondere systemnahe Dienste (Backup, Antivirus) als auch produktspezifische Programme (Archiv, Blackberry, MDM, Compliance, Disclaimer)

  • Prüfen Sie, dass die letzten Datensicherungen (Exchange, AD) ohne Fehler gelaufen sind.
  • Planen Sie die Reihenfolge gemäß „Outside IN“, d.h. zuerst die Frontend Server mit Internet.
  • Stellen Sie einen Change ein und informieren Sie Kollegen und Helpdesk über die geplante Wartung

Reihenfolge

Bei Exchange 2013 und früher war es wichtig die richtige "Reihenfolge" bei der Installation von Updates auf mehreren Servern einzuhalten. Man musste immer zuerst die "vorderen" Server zuerst aktualisieren, denn ein neuerer Server konnte die Zugriffe auf einen älteren Server weiterreichen. Exchange 2016 ist in der Hinsicht ziemlich unkritisch, da die "Frontend-Rolle" quasi nur noch HTTP-Proxy zum Backend ist, der dann die eigentliche Arbeit durchführt. Eine Versionsabhängigkeit ist hier nicht mehr gegeben. Microsoft unterscheidet ja gar nichts mehr wirklich nach "Frontend und Backend" sondern alle Server sind "gleich". Insofern kann ich in einer DAG ja auch nur noch einen Aktualisieren und nicht wirklich verhindern, dass Clientzugriffe zwischen Servern mit unterschiedlichen Patchständen erfolgen.

Ich würde dennoch zuerst die Server in dem Standort aktualisieren, welche von den Clients auch aus dem Internet angesprochen werden, wenn Sie überhaupt noch solch eine Konfiguration betreiben.

Zeitbedarf

Unterschätzen Sie diese Update-Prozedur nicht. Ich rechte durchaus mit 2-3 Stunden auf einem halbwegs flotten Server, denn sie installieren ja quasi nicht nur zweimal einen Exchange Server sondern dazwischen noch ein .NET-Framework und vermutlich noch einige andere Windows Updates.

Monitoring

Wenn mehrere Server “gepatched” werden, dann ist es sinnvoll für diesen besonderen Einsatzzweck ein eigenes Monitoring zu starten, welches einen Überblick über die Server und deren Funktion gibt. Ich habe mir dazu zwei Admin-Skripte gebaut, die neben dem vorhandenen Monitoring von mir gerne eingesetzt werden, damit auch meine eigene möglichst aktuelle Statusanzeige aller Server in einer DAG habe

Checkliste

Die folgende Checkliste ist während der letzten Installationen von CU5 auf verschiedenen Servern bei Kunden und Net at Work entstanden und wurde immer weiter verfeinert. Ich kann aber dennoch nicht garantieren, dass ich alle Aspekte erfasst habe. Die Installation eines Exchange Update ist zwar immer einfacher geworden aber bei Problemen sollten Sie schon etwas Erfahrung mit Exchange oder Rückgriff auf eine Eskalationsunterstützung haben.

Die Liste ist so aufgebaut, dass die die Spalten von oben nach unten durchgehen und dies für jeden Server wiederholen.

Aktivität

Global

MB1

MB 2

EDGE

Schema und Org-Updates

Das erste Setup erweitert ggfls. das Schema. Dies ist auf einem Computer in der Root-Domain mit Enterprise-Admin-Rechten auszuführen. Dies muss kein Exchange Server sein.

setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

 

 

 

Loadbalancer

Exchange 2016 ist "stateless" und daher kann ein Server im Loadbalancer eigentlich inaktiv geschaltet werden. Wenn der HLB die Healtchcheck.htm-Checks nutzt, dann brauchen Sie sonst nichts zu tun. Ansonsten müssen Sie auf dem HLB aktiv werden. Einige HLBs machen einen TCP-Check" gegen Port 443. Hier hilft es dann z.B. per Windows Firewall den Port 443 eingehend zu blocken. DAs ist unkritisch, da es bei Exchange 2016 nur die Frontend Web Seite stört aber nicht das Backend.

 

PowerShell Execution Policy

PowerShell Execution Policy setzen. (Default ist „RemoteSigned“)

set-ExecutionPolicy -ExecutionPolicy Unrestricted

 

Server in Maintenance setzen

Das Skript "StartDagServerMaintenance.ps1" funktioniert auf Exchange 2013/2016 nicht mehr. Sie müssen schon selbst die entsprechenden Schritte in einer Exchange PowerShell durchführen.

# Server leerlaufen lassen, indem Transport gestoppt und Failover auf den Server beendet wird
Set-ServerComponentState `
   -identity $env:COMPUTERNAME `
   -Component ServerWideOffline `
   -State Draining `
   -Requester Maintenance
 
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport
 
Suspend-ClusterNode `
  -Name $env:COMPUTERNAME
 
# Verbliebene Datenbanken auf andere Server verschieben lassen
Set-MailboxServer `
  -identity $env:COMPUTERNAME  `
   -DatabaseCopyActivationDisabledAndMoveNow $true
 
# warten, bis alle Datenbanken geschenkt sind (durchaus einige Minuten)

Get-MailboxDatabaseCopyStatus `
  -server $env:COMPUTERNAME `
| Where {$_.Status -eq "Mounted"}

Danach deaktiviere ich die Services, damit der Srever auch wirklich nicht mehr nach einem Neustart online geht.

Server auf Inaktiv setzen
 
Set-ServerComponentState `
   -identity $env:COMPUTERNAME `
   -Component ServerWideOffline `
   -State Inactive `
   -Requester Maintenance
 
Redirect-Message `
   -Server $env:COMPUTERNAME `
   -Target <andererserverfqdn>
 
Verifizieren des Maintenance Mode
 
Get-ServerComponentState `
  -Identity $env:COMPUTERNAME
 
Check auf https://<serverfqdn>/owa/healthcheck.htm

Wenn Sie nicht meine beiden Monitoring-Skripte eingesetzt haben., dann sollten Sie am Ende kontrollieren, dass die HealtchChecks kein 200OK liefern.

Schließen Sie danach die Exchange PowerShell, damit diese die Exchange Updates nicht behindert.

 

Zusatzprogramme pausieren

Diverse Tools können Dateien sperren und das Update stören. Sie können aber auch Fehler verursachen, wenn die Services noch nicht komplett wieder bereitgestellt sind. Dies gilt auch für Dienste, die auf anderen Servern remote auf Exchange zugreifen und keinen Failover unterstützen.

  • FileAV pausieren
  • Monitoring pausieren
  • Backup pausieren

 

Exchange CU4 Setup

Zuerst müssen wir Exchange 2016 CU4 installieren, ehe wir das NET-Framework 4.6.2 installieren können. Sofern UM-Language Packs installiert sind, müssen diese erst runter.

  • Entfernen der alten UM Language Packs mit dem Setup es alten Updates
setup.exe /RemoveUMLanguagePack:de-DE 
  • Aktualisierung von Exchange
Setup.exe /m:Upgrade /IAcceptExchangeServerLicenseTerms
  • Die Installation von UM-Langaugepacks erspare ich mir bei diesem Zwischenschritt
  • Optional kann das Features „Desktop Experience“ entfernt werden. CU4 benötigt es nicht mehr.
  • Neustart Server

 

.NET 4.6.2 Update

Nun ist es an der Zeit das .NET Framework zu installieren.

Hinweis:
Wenn Sie über die Windows Firewall den Port 443 für den Loadbalancer geblockt haben, dann kontrollieren Sie nach der Installation des Framework, dass dies immer noch so ist. Anscheinend "fixt" das Setup genau solche eine Verbotsregel, indem die Checkbox bei "Domain" entfernt wird.

Danach ist ein Neustart des Servers erforderlich. Dies kann durchaus etwas länger dauern, da einige Updates beim Neustart eingespielt werden.

Die Installation von NET 4.6.2 Ist eine Voraussetzung für Exchange 2016 CU5 oder höher.

 

Exchange 2016 CU5 oder höher

Nachdem das .NET Framework aktuell ist, kann nun die aktuell Exchange 2016 CU-Version installiert werden

  • Exchange Installationsquellen mounten
    Ich nutze das ISO-Images von Microsoft als CD-Quelle
  • Exchange 2016 Setup starten
.\Setup.exe /m:Upgrade /IAcceptExchangeServerLicenseTerms
  • Installation weiterer UM-Language Packs
.\Setup.EXE /AddUMLanguagePack:de-DE /s: C:\install\EX2016\CU5-UM /IAcceptExchangeServerLicenseTerms

Auch wenn Exchange es oft nicht fordert, ist ein Neustart durchaus ratsam. Allerdings reduziere ich die Neustarts gerne, indem ich hier noch schnell eventuell ausstehende Windows Updates installiere.

 

Nacharbeiten pro Server

  • Manuelle Anpassungen nachziehen (Speziell OWA Customizing)
  • FileAV reaktivieren
  • Monitoring reaktivieren
  • Backup reaktivieren

 

Maintenance Mode beenden

Starten Sie dazu auf dem Server wieder eine "Exchange Admin PowerShell". Auch das Skript "Stop-DagServerMaintenance.ps1" ist mit Exchange 2013/2016 obsolet und hilft nicht weiter. Geben Sie daher folgende Befehle ein:

# Komponenten wieder aktiv stellen
Set-ServerComponentState `
   -identity $env:COMPUTERNAME `
   -Component ServerWideOffline `
   -State Active `
   -Requester Maintenance
 
# Clusterknoten wieder aktivieren
Resume-ClusterNode `
   -Name $env:COMPUTERNAME
 
# verschiedene Checks durchfähren
Test-ServiceHealth | ft Role,RequiredServicesRunning
Test-ReplicationHealthGet-MailboxDatabaseCopyStatus

Durch die Reaktivierung der Dienste sollte Exchange wieder in den Regelbetrieb gehen. Der "Healtchcheck.htm"-Test sollte nun wieder ein 200OK melden. Alle Datenbanken sind aber noch passiv. Die Replikation und das LogShipping sollte aber wieder laufen. Das sollten Sie über die Test-Comandlets auch verifizieren. Wenn dem so ist, können Sie den Server auch wieder für die Bereitstellung von Datenbanken mit folgenden Befehlen freigeben:

# Server wieder online nehmen
Set-MailboxServer `
   -identity $env:COMPUTERNAME `			
   -DatabaseCopyAutoActivationPolicy Unrestricted `
   -DatabaseCopyActivationDisabledAndMoveNow $false
 
Get-ServerComponentState `
   -identity $env:COMPUTERNAME

Seit Exchange 2016 CU2 ist es nicht mehr erforderlich, die Datenbanken auf dem nun aktuellen Clusterknoten wieder zu aktivieren. Das macht Exchange ganz alleine. Sie können natürlich den Prozess weiterhin auf manuell anstoßen:

Cd "C:\Program Files\Microsoft\Exchange Server\V15\Scripts\"
.\RedistributeActiveDatabases.ps1 `
   -DagName E2016DAG1 `
   -BalanceDbsByActivationPreference `
   -confirm:$false

Seit Ex2016 CU2 wird das "Rückfallverhalten" über den Parameter „PreferenceMoveFrequency“ auf der DAG gesteuert. Er steht per Default auf einer Stunde

 

Loadbalancer

Sofern ihre Loadbalancer nicht alleine wieder über die "Healthcheck.htm"-Prüfung den jeweiligen Server in Betrieb genommen haben, müssen Sie die anfänglichen Einstellungen nun wieder aufheben.

 

Nacharbeiten

Nachdem alle Server aktualisiert sind, gibt es noch ein paar Dinge zu tun:

  • Backup
    Kontrollieren Sie, dass ihr Backup weiter läuft. Vielleicht wurden Jobs während der Wartung angehalten oder sogar abgebrochen und sollten nun wiederholt werden
  • Management Systeme aktualisieren
    Manchmal bringen Updates neue Funktionen mit die in das Monitoring aufgenommen werden sollten.
  • Dokumentation
    Haben Sie beim Update und dem damit verbundenen Wartungsfenster vielleicht noch einige Einstellungen optimiert?. Vergessen Sie nicht ihre Betriebsdokumentation entsprechend zu aktualisieren.
  • Abschlussmeldung an Helpdesk
    Zuletzt sollten Sie auch ihren Helpdesk und das Operating informieren, dass die Wartung hoffentlich erfolgreich abgeschlossen wurde und ab nun neue Fehler wieder genauer betrachtet werden müssen.

Weitere Links