Exchange 2016 Update Checkliste

Die Checkliste kann mit wenigen Anpassungen auch mit Exchange 2013 und 2019 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 / NET-Framework

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.

Eigene Seite zu den Exchange Patch Healthscripts.
Exchange Patch Healthskript

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

MB2

EDGE

Schema und Organization-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 aber durch das Setup kommen natürlich zumindest die Exchange Setup Umgebung auf das System.

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 Server 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 Healtchcheck.htm 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.

  • File-AV pausieren
  • Monitoring pausieren
  • Backup pausieren

 

Exchange Vorarbeiten

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
  • Optional kann das Features „Desktop Experience“ entfernt werden. CU4 und höher benötigen es nicht mehr.

 

.NET Update

Einige Exchange Updates erfordern eine Mindestversion des .NET Framework. Wer kontinuierlich aktualisiert, findet ein CU, welches sowohl das aktuelle als auch nächste Framework unterstützt. Wenn Sie mehrere CUs überspringen, dann ist ein direktes Update möglich, wenn Sie zuerst das NET Update machen und den Start von Exchange verhindern, bis das aktuelle CU installiert ist.

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 sollten Sie noch schnell "Windows Updates" bemühen, denn oft kommen noch Sicherheitsupdates für das gerade installierte .NET Framework.

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

 

Reboot

Wenn ein Neustart nicht schon aufgrund der Windows Updates oder .NET Updates erfolgt ist, sollten Sie vor der Installation des Exchange Updates, Hotfix o.ä. den Server einmal durchstarten. Es ist nicht zwingend aber die Erfahrung hat gezeigt, dass das Setup dann weniger Probleme hat.

 

Exchange 2016 CU/Update installieren

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

Achtung: Starten Sie das Setup nicht über "Windows Update" sondern immer aus einer als Administrator gestarteten Shell

So haben Sie eine GUI, die bei Fehlern und Warnungen hilft und vor allem scheitert das Setup nicht an fehlenden Berechtigungen. Windows Update läuft als "LocalSystem" und kann so z.B. nicht die Funktion DomainAD, PrepareDomain, PrepareSchema durchführen, die bei einigen Updates erforderlich sind.

  • Exchange 2016 Setup starten.
.\Setup.exe /m:Upgrade /IAcceptExchangeServerLicenseTerms
  • ggfls. Installation weiterer UM-Language Packs.
.\Setup.EXE /AddUMLanguagePack:de-DE /s: C:\install\EX2016\CU5-UM /IAcceptExchangeServerLicenseTerms

Seit dem Hafnium: Exploit und Pwn2Own 2021 sollten Sie auch das aktuellste Security Update für das CU prüfen.

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 installieren.

 

Neustart

Nicht immer fordert Sie das Setup zu einem Neustart des Servers auf. Aber auch hier hat die Praxis gezeigt, dass es ratsam ist. Nicht dass beim späteren Neustart Überraschungen zu erwarten sind.

 

Nacharbeiten pro Server

  • Manuelle Anpassungen nachziehen (Speziell OWA Customizing)
  • File-AV 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-ReplicationHealth | Get-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-Commandlets 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.

 

Zusatzaufgabe Edge-Server

Die Exchange Edge Rolle steht in der Regel in einer DMZ und ist weder Mitglied in ihrem Active Directory noch hat er eine offene Verbindung zum internen Netzwerk. Das führt unter anderem dazu, dass in der Exchange Server Übersicht die Version der Edge-Server nicht aktualisiert wird.

Das Problem können Sie über eine einen erneuten Import der Edge-Subscription nach der Installation des Updates auf dem Edge Server lösen.

Folgender Befehl exportiert auf dem Edge Server die aktuelle Konfiguration samt der Version in eine XML-Datei:

New-EdgeSubscription -FileName "c:\EdgeServerSubscription.xml"

Diese so erzeugte Datei übertragen Sie dann wieder auf einen Frontend Server und importieren diese dort.

[byte[]]$Temp = Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0
New-EdgeSubscription -FileData $Temp -Site "ADSiteName"

Sie müssen die bestehende Subscription nicht entfernen.

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.

Reparatur

Es kann natürlich immer sein, dass trotz der intensivsten Bereitung und umsichtigen Installation etwas schief läuft. Exchange arbeitet intern mit "Watermarks", d.h. jeder Installationsbaustein wird mit einem Marker versehen. Wenn die Installation abbricht, z.B. Stromausfall, Bluescreen, übereifriger Virenschutz, Malware o.ä., dann starte Sie einfach erneut das Setup. Wenn alles gut geht, sollte das Setup die vorherige angefangene Installation erkennen und nach dem letzten erfolgreichen Baustein wieder aufsetzen.

Meinst funktioniert das auch problemlos aber manchmal halt eben auch nicht. Selbst wenn Sie vorher den Server gebootet, 3rd-Party-Tools beendet und viele andere Blockaden gelöst haben, kann auch während der Installation immer etwas dazwischen kommen.

Mein erster Bick gilt dann natürlich den Protokolldateien der letzten Installation, in die Exchange sehr ausführlich seine Aktionen niederschreibt. Vielleicht finde ich einen Hinweis auf den Abbruch, so dass ich nicht erneut auf den gleichen Fehler laufen. Suchen Sie einfach nach den zuletzt geänderten Dateien in "C:\ExchangeServerSetupLog".

Wenn das Setup nicht von sich aus eine Reparaturinstallation machen, dann können Sie dies auch manuell als Administrator starten.

Setup /m:upgrade /IAcceptExchangeServerLicenseTerms

Wenn vorab die Installation des Schemas oder des DomainPrep schiefgelaufen ist, können Sie diese Schritte natürlich auch manuell ausführen. Sie können diese Aktionen auch wiederholen, da sie nur fehlende Einstellungen wieder zurecht rücken:

Setup /PrepareAd /IAcceptExchangeServerLicenseTerms
Setup /PrepareAllDomains /IAcceptExchangeServerLicenseTerms 

Ansonsten gibt es von Microsoft einen eigenen Artikel zu Problemen bei der Installation

Weitere Links