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:

• Exchange 2016 – AD- und Domain-Vorbereitung
• Exchange 2019 – AD- und Domain-Vorbereitung

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:

1. mmc öffnen → Snap-In „Active Directory-Schema“ hinzufügen
2. Rechtsklick auf Active Directory-Schema → Change Domain Controller
3. Ziel-DC wählen → Operation Master → Change

Durchführung

1. PowerShell als Administrator auf dem Schema-Master öffnen
2. Auf das ISO-Laufwerk wechseln (z. B. D:):

D:

3. Befehle nacheinander ausführen:

.\setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
.\setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

Zum Lizenz-Schalter: Microsoft akzeptiert zwei Varianten – _DiagnosticDataON oder _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 /replsummary lä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. PendingFileRenameOperations kann 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:

1. Offline-Installer herunterladen (z. B. .NET 4.8)
2. Als Administrator ausführen, Lizenz akzeptieren, installieren
3. Laufzeit bis zu 60 Minuten, wirkt teils eingefroren
4. Neustart zwingend
5. 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. /DoNotEnableEP nur nutzen, wenn dokumentierte Kompatibilitätsgründe vorliegen (z. B. bestimmte Loadbalancer-/Hybrid-Szenarien).

CU-Installation starten

1. Administrative PowerShell öffnen
2. Zum ISO-Laufwerk navigieren
3. Installation starten:

.\Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

Wichtig: setup.exe muss 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.