Kumulative Updates für Microsoft Exchange Server 2016 einspielen

Ein weiterer Schritt bei den Vorbereitungen betrifft die Schema­erweiterung des Active Directory. Auch vor der Installation von Exchange-Updates kann es erforderlich sein, das AD-Schema anzupassen. Hierzu bietet folgende Seite weitergehende Informationen.

Eine Änderung des AD-Schemas ist dem obigen Link zufolge vom Cumulative Update (CU) 3 auf das aktuelle CU4 nicht notwendig. Das kann bei anderen CUs jedoch erforderlich sein.

Für die Schema­erweiterung des Active Directory würde man in einer Eingabe­auf­forderung im Installations­verzeichnis des herunter­geladenen Updates folgende Befehle eingeben:

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

Falls Sie mehrere Domain Controller im Einsatz haben, dann muss die Replizierung der Schema­erweiterung abgewartet werden.

Der Benutzer, welcher das Update auf dem Exchange Server durchführt, sollte über entsprechenden Berechtigungen verfügen. Für die AD-Schema­erweiterung muss er Mitglied der Gruppe Schema-Admins und Organisations-Admins sein.

Installation des CU in einer Testumgebung

Im Allgemeinen empfiehlt es sich natürlich, Updates erst einmal auf einem Testsystem zu installieren und abzuwarten, was passiert. Die Konfiguration der Testumgebung sollte dabei mit jener des Produktiv­systems nahezu identisch sein.

In Zeiten der Virtualisierung kann eine solche Testinstallation leicht über das Klonen von VMs hergestellt werden. Läuft das System nach dem Update nicht mehr stabil, dann wird man das Update natürlich nicht auf der produktiven Umgebung einspielen.

Zudem sollte natürlich geprüft werden, ob das Update beispielsweise mit dem Mail-Archiv, der Backup-Software oder der Antivirenlösung kompatibel ist.

Zusätzliche Vorbereitungen

Bevor nun mit dem Update begonnen werden kann, empfiehlt es sich, ein Backup nicht nur vom Exchange Server, sondern auch gleich vom Domain Controller zu erstellen. Sollte irgendetwas schiefgehen, so kann man zumindest den letzten funktionierenden Stand wiederherstellen.

Für alle, die einen Load Balancer (bei mir ist es ein Citrix Netscaler) einsetzen, sei an dieser Stelle noch erwähnt, dass der zu aktualisierende Server aus dem Verbund heraus­genommen werden sollte. Ansonsten versucht der Load Balancer weiterhin, E-Mails an den Server, welcher gerade aktualisiert wird, zuzustellen. Nachdem er diese aber nicht verarbeiten kann, werden die Nachrichten nicht zugestellt und der Absender erhält eine Fehlermeldung.

Zum Schluss sollte noch ein Blick auf die Datenbanken geworfen werden. Hier ist es wichtig, darauf zu achten, welche Datenbanken gemountet sind und ob der Index in Ordnung ist. Über die Exchange Management Shell (als Administrator ausführen) wird dies mit folgendem Befehl geprüft:

Get-MailboxDatabaseCopyStatus

Ist hier alles in Ordnung sind die Vorbereitungen nun abgeschlossen und es kann ernst werden. Ich selbst empfehle, die Updates immer in einer angekündigten Downtime durchzuführen. Vor und nach dem Update sollten Sie das Eventlog auf etwaige Fehler prüfen.

Server in den Wartungsmodus versetzen

In unserem Beispiel haben wir einen Domain Controller und zwei Exchange Server, welche sich in einer DAG befinden. Zuerst versetze ich den zu aktualisierenden Exchange Server in den Wartungsmodus. Die Datenbanken werden dabei auf den anderen in der DAG vorhandenen Exchange Server geschwenkt. Die Benutzer sollten davon im Normalfall nichts mitbekommen.

Über die Exchange Management Shell wird der Exchange Server mit folgenden Befehlen in den Wartungsmodus versetzt:

Set-MailboxServer "EX01" ` -DatabaseCopyActivationDisabledAndMoveNow $True Set-ServerComponentState -Identity "EX01" ` -Component HubTransport -State Draining -Requester Maintenance Suspend-ClusterNode -Name "EX01" Set-MailboxServer -Identity "EX01" ` -DatabaseCopyAutoActivationPolicy Blocked Set-ServerComponentState "EX01" -Component ServerWideOffline ` -State InActive -Requester Maintenance

Wenn Sie jetzt nochmal den Befehl Get-MailboxDatabaseCopyStatus ausführen, dann sehen Sie, dass auf unserem EX01 keine Datenbank mehr gemountet ist. Alternativ kann man dies auch über die Web-Konsole des Exchange Servers anzeigen.

An dieser Stelle sei evtl. noch kurz erwähnt, dass Sie nicht zu ungeduldig sein sollten. Gerade bei größeren Umgebungen kann es einen Moment dauern, bis alle Datenbank geschwenkt werden.

Updates installieren

Der Exchange Server ist nun offline. Bevor ich das Cumulative Update einspiele, installiere ich vorab immer noch die normalen Windows-Updates. Dies bietet sich an, da der Exchange sich ohnehin im Wartungsmodus befindet und neu gestartet werden muss.

Das Cumulative Update starte ich aus dem Installationsverzeichnis über die Setup.exe.

Folgende Benachrichtigung ist ok, da ich den Exchange Server diesbezüglich noch nicht konfiguriert habe.

Nach dem Update muss der Exchange Server natürlich wieder aus dem Wartungsmodus genommen werden. Dies geht mit folgenden Befehlen:

Set-MailboxServer -Identity "EX01" ` -DatabaseCopyAutoActivationPolicy Unrestricted Resume-ClusterNode -Name "EX01" Set-ServerComponentState -Identity "EX01" ` -Component HubTransport -State Active -Requester Maintenance Set-MailboxServer -Identity "EX01" ` -DatabaseCopyActivationDisabledAndMoveNow $False Set-ServerComponentState "EX01" -Component ServerWideOffline ` -State Active -Requester Maintenance

Die Datenbanken sollten jetzt wieder zurück auf dem EX01 geschwenkt worden sein.

Zwischenzeitlich haben Sie, solange der zweite Exchange Server in der DAG nicht aktualisiert wurde, zwei unterschiedliche Versionen des Mail-Servers laufen. Die Version bzw. Build-Nummer sieht man entweder in der Exchange Management Konsole oder per PowerShell.

Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion

Nachdem der Exchange Server wieder online ist, sollte dieser im Load Balancer wieder in den Verbund aufgenommen werden, damit er wieder von der Außenwelt angesprochen werden kann.

Update weiterer Knoten

Das Update lässt sich nun auch auf den zweiten Exchange Server anwenden. Wichtig: Prüfen Sie nach dem Update nochmal das Eventlog auf eventuelle Fehler.

Wenn keine Testumgebung vorhanden ist, dann bietet es sich an, zwischen den Updates einen Tag zu warten und zu schauen, wie sich der Exchange Server mit dem neuen Update verhält. Manche Fehler können auch in einer Teststellung nicht hervorgerufen werden, diese werden erst in Live-Betrieb sichtbar.

Troubleshooting

Auf einem meiner beiden Exchange Server wollte sich das Setup des CU4 einfach nicht starten lassen. Nach dem Klicken auf die Setup.exe passierte bis auf das kurze Aufflackern des schwarzen Fensters gar nichts.

Als ich dann das Installations­medium des CU3 nochmals einlegte und dort das Setup startete, wurde mir gemeldet, dass die Installation beschädigt bzw. unvollständig sei. Ich ließ also erst das Setup des CU3 nochmals durchlaufen, um den Fehler zu beheben.