Die Installation eines Exchange Cumulative Updates ist keine simple Routineaufgabe – es sind zahlreiche Aspekte zu beachten. Die Rückmeldung während der Installation ist oft spärlich; es kann durchaus minutenlang so aussehen, als passiere nichts. Solange das Setup-Fenster noch reagiert, besteht in der Regel kein Grund zur Sorge.
Diese Dokumentation basiert auf der Installation eines CU auf dem eigenständigen Exchange-Server exch01.domain.tld, der vorab mit allen aktuellen Windows-Updates versorgt wurde. Die zugrunde liegende Umgebung ist ein Multi-AD-Forest mit Child-Domain – also deutlich komplexer als eine Single-Forest-/Single-Domain-Struktur.
⚠️ Wichtig vorab (Stand: Juni 2026): Exchange 2016/2019 sind End of Support
Exchange Server 2016 und 2019 haben am 14. Oktober 2025 das Support-Ende erreicht. Es gibt seitdem keine regulären Sicherheitsupdates, Bugfixes oder technischen Support mehr. Wer noch im Programm der Extended Security Updates (ESU) ist, erhält Updates nur noch bis April 2026 – das ist ausdrücklich nur ein Übergang, keine Dauerlösung.
Die einzige weiterhin unterstützte On-Prem-Variante ist Exchange Server Subscription Edition (SE). Exchange SE RTM ist code-identisch mit Exchange 2019 CU15; SE CU1 kam in H1/2026, SE CU2 folgt in H2/2026 und blockt dann die Koexistenz mit 2016/2019.
Konsequenz für dieses Thema: Reine CU-Installationen auf 2016/2019 sind heute fast nur noch im Rahmen einer In-Place-Migration nach SE relevant (2019 CU14/CU15 → SE) oder mit aktivem ESU. Der hier beschriebene Ablauf gilt aber technisch unverändert auch für Exchange Server SE – Modern Servicing bedeutet lediglich: Es ist immer nur das aktuellste CU supported (kein „N-1″ mehr).
Voraussetzungen
Passende Berechtigungen
Für das Update wird ein Benutzerkonto benötigt, das Mitglied in folgenden Gruppen ist:
- Organization Management
- Organisations-Admins (Enterprise Admins)
- Schema-Admins
Nur damit ist sichergestellt, dass alle Änderungen am Active-Directory-Schema und an der Exchange-Organisation durchgeführt werden können. Fehlen die Rechte, schlägt die Installation fehl – und die Ursache lässt sich oft nur mit gezielter Log-Recherche nachvollziehen.
In seltenen Konstellationen (wie z. B. bei domain.tld) ist die Gruppe Organisations-Admins nicht automatisch Mitglied der Domänen-Admins jeder betroffenen Domäne. Dann muss PrepareDomain zwingend mit einem Benutzer aus der Domänen-Admins-Gruppe der jeweiligen Domäne ausgeführt werden.
Vorbereitung der Arbeiten
Je nach Umgebung unterscheiden sich die Vorbereitungsschritte. Vieles lässt sich aber schon im Vorfeld erledigen.
Übersicht der Exchange-Server erfassen
Erstelle vorab eine Übersicht aller Exchange-Server inklusive Dienstestatus, Build-Versionen und ggf. Rollenverteilung. Das dokumentiert den IST-Zustand sauber und hilft im Fehlerfall enorm.
💡 Tipp: Microsoft empfiehlt offiziell den Exchange Server Health Checker (PowerShell-Skript), um vorab zu sehen, welche CUs/SUs/manuellen Schritte ausstehen. Den IST-Zustand kannst du außerdem mit dem unten verlinkten Pre-Flight-Skript einsammeln.
Beginn der Arbeiten kommunizieren
Vor dem Start der Wartung den Kunden/Service Owner rechtzeitig informieren, damit Einschränkungen bekannt und eingeplant sind.
Exchange-Version ermitteln
Zuerst feststellen, welche Version aktuell läuft – per Exchange Management Shell oder EAC.
Get-ExchangeServer | Select-Object Name, AdminDisplayVersion | Format-Table
Beispielausgabe:
Name AdminDisplayVersion
---- -------------------
EXCH01 Version 15.1 (Build 2044.4)
EXCH02 Version 15.1 (Build 2044.4)
Die Build-Nummer ordnest du über die Microsoft-Liste der konkreten CU-Version zu: 👉 Exchange Build Numbers and Release Dates (Microsoft Learn)
Build-Logik kurz erklärt:
15.0.x= Exchange 2013,15.1.x= Exchange 2016,15.2.x= Exchange 2019 / Exchange SE. Im Beispiel entspricht 15.1.2044.4 dem Exchange 2016 CU17.
CU-Version der Setup-Datei prüfen
Welche Version ein vorhandenes Setup-Paket enthält:
Get-Command Exsetup.exe | ForEach-Object { $_.FileVersionInfo }
Download der aktuellen CU/SE-Version
Aktuelle Pakete (Exchange SE bzw. die letzten ESU-fähigen SUs für 2016/2019) gibt es bei Microsoft. Nutze zur Pfadbestimmung den Exchange Update Wizard, der dir abhängig von Quell- und Ziel-CU die genauen Schritte ausgibt.
Besonderheit: UM Language Pack
ℹ️ Hinweis: Unified Messaging (UM) wurde mit Exchange 2019 entfernt und ist in Exchange SE nicht mehr vorhanden. Dieser Abschnitt ist daher nur noch für Exchange 2016 relevant.
Falls UM eingesetzt wird, ist ggf. ein UM Language Pack installiert (z. B. für Voicemail-Ansagen). Es muss nach dem CU-Update in passender Version neu installiert werden und erscheint in der Systemsteuerung unter Programme und Features.
Prüfen, ob ein Language Pack aktiv ist:
Get-UMService | Select-Object Name, Languages
Wird nur {en-US} ausgegeben, ist kein zusätzliches Sprachpaket installiert.
.NET Framework-Version ermitteln
Am einfachsten per PowerShell (als Administrator):
(Get-ItemProperty "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").Release
Beispielausgabe:
528049
Der Release-Wert lässt sich der Microsoft-Tabelle zuordnen – 528049 = .NET 4.8: 👉 How to determine which .NET Framework versions are installed
Kurzreferenz Release-Werte:
528040/528049/528449= .NET 4.8 ·533320/533325= .NET 4.8.1. Exchange SE benötigt .NET 4.8 (auf Windows Server 2025 ist 4.8.1 systemseitig dabei).
Kompatibilität von CU und .NET Framework
Mit diesen Infos prüfst du anhand der Supportability Matrix, ob die installierte .NET-Version zum geplanten CU passt. Ist das nicht der Fall, muss .NET vor dem CU aktualisiert werden.
👉 Exchange Server Supportability Matrix (Microsoft Learn)
In unserem Beispiel: .NET 4.8 wird bereits ab Exchange 2016 CU13 unterstützt – ein .NET-Update ist hier nicht erforderlich.
Active Directory Schema-Version prüfen
Vor dem CU prüfen, ob das AD-Schema bereits die erforderliche Version hat.
Exchange Schema Version:
$sc = (Get-ADRootDSE).SchemaNamingContext
$ob = "CN=ms-Exch-Schema-Version-Pt," + $sc
Write-Output "RangeUpper: $((Get-ADObject $ob -Properties rangeUpper).rangeUpper)"
Exchange Object Version (Domain):
$dc = (Get-ADRootDSE).DefaultNamingContext
$ob = "CN=Microsoft Exchange System Objects," + $dc
Write-Output "ObjectVersion (Default): $((Get-ADObject $ob -Properties objectVersion).objectVersion)"
Exchange Object Version (Forest):
$cc = (Get-ADRootDSE).ConfigurationNamingContext
$fl = "(objectClass=msExchOrganizationContainer)"
Write-Output "ObjectVersion (Configuration): $((Get-ADObject -LDAPFilter $fl -SearchBase $cc -Properties objectVersion).objectVersion)"
Hinweis: Die ObjectVersion (Configuration) wird in manchen Umgebungen erst nach dem erfolgreichen Update des ersten Exchange-Servers erhöht.
Beispielausgabe:
RangeUpper: 15332
ObjectVersion (Default): 13237
ObjectVersion (Configuration): 16217
Die jeweils erforderlichen Soll-Werte je CU stehen hier:
In unserem Fall muss das Schema erweitert werden, da das neue CU eine höhere Schema-Version voraussetzt.
💡 Tipp: Alle obigen Abfragen plus Dienstestatus, FSMO, .NET und Transport Agents erledigt das verlinkte Pre-Flight-Skript in einem Rutsch (read-only).
Schema Master ermitteln
Für das Schema-Upgrade muss bekannt sein, welcher DC die Schema-Master-Rolle hält. Das Upgrade sollte im Vorfeld des CU erfolgen.
Variante 1 – CMD:
netdom query fsmo
Variante 2 – PowerShell:
Get-ADForest | Select-Object SchemaMaster
Schema-Erweiterung des Active Directory
Die Installations-ISO des CUs wird auf dem DC mit der Schema-Master-Rolle eingebunden (im Beispiel rootdc01.domain.tld).
Alternativ auf einem anderen DC in der gleichen AD-Site wie der Exchange-Server. Bei Bedarf die FSMO-Rolle temporär verschieben:
mmcöffnen → Snap-In „Active Directory-Schema“ hinzufügen- Rechtsklick auf Active Directory-Schema → Change Domain Controller
- Ziel-DC wählen → Operation Master → Change
Durchführung
- PowerShell als Administrator auf dem Schema-Master öffnen
- Auf das ISO-Laufwerk wechseln (z. B.
D:):
D:
- Befehle nacheinander ausführen:
.\setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
.\setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
Zum Lizenz-Schalter: Microsoft akzeptiert zwei Varianten –
_DiagnosticDataONoder_DiagnosticDataOFF. Der Unterschied ist ausschließlich, ob optionale Diagnosedaten an Microsoft gesendet werden. Funktional ist die Installation identisch. Tipp: Innerhalb einer Wartung konsistent denselben Schalter verwenden, um Verwirrung in den Logs zu vermeiden.
Komplexe Umgebungen mit mehreren Domänen
Gibt es Exchange-Server in weiteren Domänen:
.\setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
Schlägt PrepareAllDomains mangels Domain-Adminrechten fehl, jede Domäne einzeln vorbereiten:
.\setup.exe /PrepareDomain:<domain.tld> /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
Abschluss der AD-Vorbereitung
Danach ist das AD auf dem aktuellen Stand. Die ISO kann vom DC wieder ausgehängt werden.
Hinweis: Vor dem Start der Exchange-Installation die AD-Replikation abwarten – meist reichen ca. 15 Minuten, je nach Umgebung mehr. Mit
repadmin /replsummarylässt sich der Replikationsstand prüfen.
Problem: „Ein Neustart einer vorangegangenen Installation steht noch aus“
Vor dem Setup kann diese Meldung kommen:
Ein Neustart einer vorangegangenen Installation steht noch aus. Starten Sie das System neu, und führen Sie Setup erneut aus.
Das Setup wird abgebrochen. Details im Log:
<SystemDrive>:\ExchangeSetupLogs\ExchangeSetup.log
Lösungsmöglichkeiten
- Variante 1 (empfohlen): Server einmal neu starten, Setup erneut ausführen.
- Variante 2 (nur wenn Reboot nicht hilft): Den Registry-Wert prüfen:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager → PendingFileRenameOperations
⚠️ Korrektur/Warnung (wichtig!): Diesen Wert nicht blind löschen.
PendingFileRenameOperationskann mehrere legitime ausstehende Umbenennungen enthalten, die Windows beim nächsten Boot erledigen will. Werden die gelöscht, können laufende Updates inkonsistent werden.Besser: Erst den Inhalt ansehen (
Get-ItemProperty ... -Name PendingFileRenameOperations), den Wert exportieren/sichern, und nur wenn dort ausschließlich irrelevante Reste stehen, gezielt entfernen. In 95 % der Fälle löst ein simpler Reboot das Problem sauber.
Weitere Infos: 🔗 FrankysWeb – „Ein Neustart steht noch aus“
Sonderanpassungen an der Konfiguration
Individuelle Konfigurationsänderungen (z. B. an web.config) können durch ein CU überschrieben werden. Diese vorab dokumentieren/exportieren und nach dem Update prüfen und ggf. erneut setzen.
Abhängige Drittherstellersoftware
In produktiven Umgebungen ist oft Drittsoftware aktiv (Signaturen, Archivierung, Security). Solche Komponenten können durch ein CU beeinträchtigt werden, vor allem wenn Exchange-DLLs ersetzt werden.
Prüfen, ob sich Software in den Mailflow einklinkt:
Get-TransportAgent
Beispielausgabe:
Name Enabled Priority
---- ------- --------
Exclaimer Auto Responder Agent True 1
Hier ist der Exclaimer Auto Responder Routing Agent aktiv (laut Hersteller keine Maßnahmen nach CU nötig). Anders z. B. bei CI-Mail Policy – die muss nach jedem CU neu installiert werden.
Empfehlung: Vor dem Update die Dritthersteller-Doku prüfen oder beim Hersteller anfragen, ob nach einem CU Maßnahmen nötig sind.
Vorbereitung vor dem Update
Kundenkommunikation
Falls noch nicht erfolgt: Kunde vor Beginn informieren, besonders bei Produktivsystemen.
Kein Snapshot!
Ein Snapshot (Hyper-V/VMware) ist nicht sinnvoll – das CU ändert nicht nur Exchange, sondern auch das AD-Schema. Ein Snapshot-Rollback führt zu inkonsistenten Zuständen. Es gibt kein Rollback – nur den Weg nach vorn.
Technische Vorbereitung
Status der Exchange-Dienste dokumentieren
IST-Zustand festhalten:
- Dienste (Screenshot oder PowerShell):
Test-ServiceHealth - Komponentenstatus:
Get-ServerComponentState <Servername>
Hintergrund: CU-/Hotfix-Installationen setzen Dienste/Komponenten oft auf „Deaktiviert“. Eine saubere Rückdokumentation ist entscheidend.
Zugriffe reduzieren
- Benutzersitzungen abmelden (alle außer Admin).
- Offene PowerShell-Sitzungen beenden:
Get-Process *powershell* | Stop-Process -Id <Prozess-ID>
Virenscanner deaktivieren
- AV (z. B. Bitdefender) deaktivieren (bei Bitdefender: Shift + Rechtsklick > Poweruser).
- Andere Lösungen nach Herstelleranleitung.
- Geht keine Deaktivierung: dokumentieren und fortfahren.
Backup pausieren
- Laufende Backup-Jobs pausieren/deaktivieren – das CU beinhaltet mehrere Neustarts; Sicherungen können den Prozess stören oder beschädigte Backups erzeugen.
Installation des .NET Framework Updates (falls erforderlich)
Im Beispiel nicht nötig – der Vollständigkeit halber:
- Offline-Installer herunterladen (z. B. .NET 4.8)
- Als Administrator ausführen, Lizenz akzeptieren, installieren
- Laufzeit bis zu 60 Minuten, wirkt teils eingefroren
- Neustart zwingend
- Danach über Windows Update verfügbare .NET-Sicherheitsupdates nachziehen
IIS URL Rewrite Module (bei bestimmten CUs)
Seit dem CU vom September 2021 gibt es einen sicherheitsrelevanten „Not-Aus-Schalter“. Dafür ist vorab das IIS URL Rewrite Module nötig:
👉 Microsoft URL Rewrite Module
Installation dauert nur wenige Minuten und sollte vor dem CU erfolgen, falls das CU diese Abhängigkeit mitbringt.
Installation des Cumulative Updates (CU)
Vor der Installation den Exchange Server einmal neu starten, um sauber zu starten.
ISO-Datei einbinden
Die CU-ISO per Doppelklick einbinden – sie erscheint als virtuelles Laufwerk.
Wichtiger Hinweis: Extended Protection
Mit aktuellen CUs wird Extended Protection (EP) automatisch aktiviert. 👉 Exchange Extended Protection (Microsoft Learn)
Soll EP nicht aktiviert werden:
.\Setup.exe /Update /DoNotEnableEP /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
⚠️ EP ist eine Sicherheitsfunktion und sollte im Normalfall aktiviert bleiben.
/DoNotEnableEPnur nutzen, wenn dokumentierte Kompatibilitätsgründe vorliegen (z. B. bestimmte Loadbalancer-/Hybrid-Szenarien).
CU-Installation starten
- Administrative PowerShell öffnen
- Zum ISO-Laufwerk navigieren
- Installation starten:
.\Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
Wichtig:
setup.exemuss als Administrator laufen, sonst drohen inkonsistentes Verhalten oder ein defekter Exchange-Server.
Während der Installation
- Die Installation kann mehrfach längere Zeit „hängen“ – das ist normal.
- Alle Exchange-Dienste sind gestoppt – das Monitoring sollte das erkennen (ggf. Wartungsfenster setzen).
- Häufige Fehlerursache: Backup-Software startet automatisch → Backup-Jobs vorab stoppen!
Neustart nach dem CU-Update
Nach der Installation ist ein Neustart zwingend. Er kann ungewöhnlich lange dauern – teils bis zu einer Stunde, bis alle Dienste laufen.
Nacharbeiten nach dem CU-Update
Sonderanpassungen prüfen und ggf. erneut setzen
web.config-Anpassungen u. Ä. jetzt prüfen und bei Bedarf erneut vornehmen – CUs überschreiben solche Änderungen.
Arbeiten nach dem Neustart
1. Dienste & Konfiguration
Exchange-Dienste gestartet und in erwarteter Konfiguration? → Abgleich mit Vorher-Screenshot.
2. Komponentenstatus
Get-ServerComponentState <Servername>
→ Abgleich mit dokumentiertem Zustand.
3. Datenbankstatus
Im EAC → Servers → Databases prüfen, ob alle Datenbanken eingebunden/bereitgestellt sind. (PowerShell: Get-MailboxDatabaseCopyStatus.)
4. Mailflow testen
Test eingehend und ausgehend (z. B. Admin sendet an Techniker, erhält Antwort).
5. OWA / Outlook-Zugriff prüfen
OWA mit Testnutzer testen, wenn möglich Outlook-Konnektivität prüfen.
6. Monitoring prüfen
Alles wieder „grün“? CPU-Last direkt nach Neustart erhöht ist normal – nach 30–60 Minuten sollte sie sich stabilisieren.
7. Ereignisprotokolle prüfen
Anwendungs-/System-Eventlogs filtern (Kritisch/Fehler/Warnung). Kurz nach dem Neustart sind manche Fehler normal und verschwinden wieder.
Letzte Schritte nach dem CU-Update
Prüfung mit Test-ServiceHealth
Test-ServiceHealth
Alle erforderlichen Dienste sollten „Running“ zeigen.
💡 Microsoft empfiehlt, nach dem Update erneut den Exchange Health Checker laufen zu lassen, um offene Folgeaktionen zu erkennen.
Reaktivierung des Virenscanners
Falls manuell deaktiviert und nicht automatisch zurück: AV wieder aktivieren.
Backup fortsetzen
Pausierten Backup-Job fortsetzen (Rechtsklick → Fortsetzen).
Prüfung der erfolgreichen Installation
Get-ExchangeServer | Select-Object Name, AdminDisplayVersion | Format-Table
Beispielausgabe:
Name AdminDisplayVersion
---- -------------------
EXCH04 Version 15.1 (Build 2044.4)
EXCH05 Version 15.1 (Build 2176.2)
Die Build-Nummer muss der Zielversion entsprechen (siehe Microsoft Build-Liste).
Abschluss
- Information kommunizieren (intern an Service Owner, extern an Kunde/Ansprechpartner).
- Installationsdateien bereinigen (ISO und extrahierte Dateien löschen, Papierkorb leeren).
Bonus: Pre-Flight-Skript
Das begleitende PowerShell-Skript PS_Exchange_CU_PreFlight_Check.ps1 sammelt den kompletten IST-Zustand (Versionen, Dienste, ComponentState, AD-Schema, FSMO, .NET, Transport Agents, Pending-Reboot) read-only in eine Textdatei – ideal für die Vorher-/Nachher-Dokumentation.
