Die Beispielwerte (wordpress-ibr4-*, jryy_, abow.info, IP 72.61.92.170) stammen aus dem realen Umzug. Passe sie an deinen Stack an.

Ziel

WordPress läuft im vorhandenen Docker-Stack, ist über https://abow.info öffentlich erreichbar, Zertifikat von Let’s Encrypt – ohne Datenverlust.

Mentales Modell (vorab verstehen, spart 2 Stunden)

• Named Volume: Der WP-Container mountet …/<volume>/_data → /var/www/html. Deine Files müssen in _data liegen, nicht daneben. Und: _data niemals löschen – ein Named Volume braucht diesen Ordner, sonst startet der Container nicht.
• Die wp-config.php erzeugt das offizielle Image selbst – aber nur, wenn keine existiert, und zwar aus den WORDPRESS_*-ENV-Variablen. Eine mitgebrachte Strato-wp-config.php wird nicht überschrieben.
• DB-Verbindung geht über den Service-Namen (db), nie localhost/rdbms.strato.de.
• Traefik im Host-Mode routet nicht über das Docker-Netz, sondern über einen festen veröffentlichten Port des Containers.

Schritt 0: Stack inspizieren

ssh root@DEINE_VPS_IP

docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"

Du suchst den WP- und den DB-Container (hier wordpress-ibr4-wordpress-1 / wordpress-ibr4-db-1, DB-Image mysql:8) und den Reverse Proxy (traefik-traefik-1). Projektpfad und Volume finden:

docker inspect wordpress-ibr4-wordpress-1 \
  --format '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}'
# -> z.B. /docker/wordpress-ibr4

docker inspect wordpress-ibr4-wordpress-1 \
  --format '{{ range .Mounts }}{{ .Name }} | {{ .Source }} -> {{ .Destination }}{{ println }}{{ end }}'
# -> wordpress-ibr4_wordpress | …/_data -> /var/www/html

DB-Zugangsdaten + Prefix aus den Containern (nur ansehen):

docker exec wordpress-ibr4-wordpress-1 env | grep -i WORDPRESS_DB
docker exec wordpress-ibr4-db-1          env | grep -iE 'MYSQL_DATABASE|MYSQL_USER'

Schritt 1: Files an die richtige Stelle (_data)

Liegen deine Strato-Files in einem Ordner neben _data (z. B. _app), sieht WordPress sie nicht. Ist _data nur die nackte Standard-Installation, deine echte Seite aber in _app, machst du _app zum Live-Verzeichnis:

cd /var/lib/docker/volumes/wordpress-ibr4_wordpress
# Falls _data noch die Default-Files enthaelt: sichern statt loeschen
mv _app  _data

# Core vollstaendig? (muessen existieren)
ls _data/wp-admin _data/wp-includes _data/wp-load.php

Falle: _data zu löschen killt den Mountpunkt → Error response from daemon: open …/_data: no such file or directory. Immer umbenennen, nie löschen.

Schritt 2: Alte Strato-wp-config raus, ENV-Prefix korrekt setzen

Die mitgebrachte wp-config.php zeigt noch auf Strato:

grep -E "table_prefix|DB_HOST|DB_NAME|DB_USER" _data/wp-config.php
# define('DB_HOST','rdbms.strato.de');  <- muss weg
# $table_prefix = 'jryy_';              <- Prefix merken!

Prefix merken (hier jryy_) und die alte Config wegsichern, damit das Image neu generiert:

mv _data/wp-config.php _data/wp-config.php.strato-bak

Jetzt den Table-Prefix in die Compose – und zwar im environment:-Block des wordpress-Service (nicht beim db-Service!). Häufigster Fehler: Zeile landet bei den MYSQL_*-Variablen und greift nie.

services:
  wordpress:
    environment:
      - WORDPRESS_DB_HOST=db
      - WORDPRESS_DB_NAME=wordpress
      - WORDPRESS_DB_USER=wordpress
      - WORDPRESS_DB_PASSWORD=${MYSQL_PASSWORD}
      - WORDPRESS_TABLE_PREFIX=jryy_          # <- HIER, beim wordpress-Service

Schritt 3: Container neu erzeugen und Prefix effektiv prüfen

docker compose up -d allein startet einen laufenden Container nicht neu – dann läuft der Entrypoint nicht und die wp-config.php wird nicht geschrieben. Daher --force-recreate:

cd /docker/wordpress-ibr4
docker compose up -d --force-recreate wordpress

Jetzt nicht nur grep (das offizielle Image schreibt getenv_docker('…','wp_') mit Fallback). Den aufgelösten Wert prüfen:

docker exec wordpress-ibr4-wordpress-1 \
  php -r 'require "/var/www/html/wp-config.php"; echo DB_HOST.PHP_EOL.DB_NAME.PHP_EOL.$table_prefix.PHP_EOL;'

Zielausgabe:

db
wordpress
jryy_

Kommt wp_ statt jryy_: Die ENV-Zeile steht im falschen Service-Block oder die alte wp-config.php existiert noch. Beides fixen, --force-recreate wiederholen. Effektiv-Check mit docker exec … env | grep WORDPRESS_TABLE_PREFIX zeigt, ob die Variable im Container überhaupt ankommt.

Schritt 4: Datenbank importieren

docker exec -i … < dump.sql liest die Datei vom Host und pipet sie in den Container – der Pfad im Container ist egal, nur der Host-Pfad muss stimmen. Passwort kommt aus der Container-ENV, du tippst nichts:

docker exec -i wordpress-ibr4-db-1 \
  sh -c 'exec mysql -uwordpress -p"$MYSQL_PASSWORD" wordpress' \
  < /var/lib/docker/volumes/wordpress-ibr4_wordpress/dbs12659889.sql

Falle ERROR 1050 … Table already exists: In der DB liegen schon Tabellen (Reste der Default-Installation oder ein abgebrochener Import). Schema einmal komplett leeren, dann neu importieren:

docker exec wordpress-ibr4-db-1 sh -c '
  exec mysql -uwordpress -p"$MYSQL_PASSWORD" -N -e "
    SET FOREIGN_KEY_CHECKS=0; SET GROUP_CONCAT_MAX_LEN=1000000;
    SELECT IFNULL(CONCAT(\"DROP TABLE IF EXISTS \", GROUP_CONCAT(\"\`\",table_name,\"\`\"), \";\"), \"SELECT 1;\")
    FROM information_schema.tables WHERE table_schema=\"wordpress\";
  " wordpress' \
| docker exec -i wordpress-ibr4-db-1 sh -c 'exec mysql -uwordpress -p"$MYSQL_PASSWORD" wordpress'

Danach SHOW TABLES; muss leer sein → Import wiederholen.

Rechte setzen und verifizieren (Prefix beachten – hier jryy_):

docker exec wordpress-ibr4-wordpress-1 chown -R www-data:www-data /var/www/html

docker exec wordpress-ibr4-db-1 \
  sh -c 'exec mysql -uwordpress -p"$MYSQL_PASSWORD" wordpress \
  -e "SELECT option_name,option_value FROM jryy_options WHERE option_name IN (\"siteurl\",\"home\");"'

docker exec wordpress-ibr4-wordpress-1 \
  php -r 'require "/var/www/html/wp-load.php"; echo "WP ".$GLOBALS["wp_version"]." | ".get_option("blogname").PHP_EOL;'

Erwartung: deine siteurl/home und WP-Version + Blogname.

Schritt 5: URLs (nur bei Domain-/Protokollwechsel)

Stehen siteurl/home bereits korrekt (z. B. https://abow.info), ist nichts zu tun – diesen Schritt überspringen. Andernfalls serialisierungssicher mit WP-CLI ersetzen, nie per rohem SQL:

docker compose exec wordpress bash -c '
  curl -sO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
  php wp-cli.phar search-replace "http://alt.tld" "https://abow.info" --all-tables --allow-root --dry-run'

Sieht der Probelauf gut aus → --dry-run weglassen.

Schritt 6: HTTPS hinter Traefik

Traefik terminiert TLS und spricht intern per HTTP mit WordPress. Ohne Hinweis baut WordPress Redirect-Loops / Mixed-Content. Per ENV in den wordpress-Service (die $$ sind Absicht – Compose würde einfaches $ als Variable interpretieren):

      - WORDPRESS_CONFIG_EXTRA=if (isset($$_SERVER['HTTP_X_FORWARDED_PROTO']) && $$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $$_SERVER['HTTPS'] = 'on'; }

Schritt 7: Traefik-Routing im Host-Mode

Prüfen, wie Traefik tickt:

docker inspect traefik-traefik-1 --format '{{ json .Config.Cmd }}'
# -> providers.docker=true, entrypoints web:80 / websecure:443,
#    HTTP->HTTPS-Redirect, certresolver "letsencrypt" (HTTP-Challenge)

docker inspect traefik-traefik-1 \
  --format '{{ range $n,$v := .NetworkSettings.Networks }}{{ $n }} {{ end }}'
# -> host   (= Host-Mode!)

Host-Mode-Konsequenzen (das ist die größte Falle):

• docker network connect ist nicht möglich (Container im Host-Namespace).
• Traefik erreicht den WP-Container nur über einen festen, veröffentlichten Port auf 127.0.0.1.
• Im Label statt loadbalancer.server.port → loadbalancer.server.url mit der festen URL.

Daher in der Compose den WP-Port fix mappen (nicht dynamisch "80", das vergibt Docker zufällig):

    ports:
      - "127.0.0.1:8081:80"

Und die Labels auf Service-Ebene (gleiche Einrückung wie environment:/volumes:, nur einmal labels: pro Service!):

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.abow.rule=Host(`abow.info`)"
      - "traefik.http.routers.abow.entrypoints=websecure"
      - "traefik.http.routers.abow.tls=true"
      - "traefik.http.routers.abow.tls.certresolver=letsencrypt"
      - "traefik.http.services.abow.loadbalancer.server.url=http://127.0.0.1:8081"

YAML-Fallen: labels: darf nicht unter volumes: verschachtelt sein und nicht doppelt vorkommen (mapping key "labels" already defined). Nach jeder Änderung validieren:

docker compose config >/dev/null && echo "YAML OK" || echo "YAML kaputt"

Anwenden und intern testen (ohne auf DNS/Zertifikat zu warten):

docker compose up -d wordpress

curl -s -I http://127.0.0.1:8081/ | head -1            # WordPress direkt: 200/301
curl -s -I -H "Host: abow.info" http://127.0.0.1/ | head -1   # ueber Traefik

HTTP/1.1 308 Permanent Redirect beim zweiten Befehl = Traefik kennt den abow-Router und leitet auf HTTPS um. Routing steht.

Schritt 8: DNS umstellen → Zertifikat kommt automatisch

Das Let’s-Encrypt-Zertifikat (HTTP-Challenge) zieht erst, wenn die Domain öffentlich auf den VPS zeigt. Beim DNS-Anbieter für abow.info:

Vorher testen ohne DNS-Wartezeit: per Windows-hosts-Datei abow.info → VPS-IP (PowerShell-Skript unten). Browser-Zertifikatswarnung ist dabei normal, bis das echte Zert gezogen ist.

Nach Propagation prüfen:

dig +short abow.info                                   # -> 72.61.92.170
curl -sI https://abow.info | head -3                   # -> HTTP/2 200
echo | openssl s_client -connect abow.info:443 -servername abow.info 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates        # Issuer: Let's Encrypt

HTTP/2 200 ohne TLS-Fehler = live mit gültigem Zertifikat.

Schritt 9: Nacharbeiten & Aufräumen

# In WordPress: Einstellungen -> Permalinks -> ohne Aenderung speichern (Rewrites/.htaccess)

# Backups/Reste entfernen
rm -rf /var/lib/docker/volumes/wordpress-ibr4_wordpress/_data_OLD
rm -f  /var/lib/docker/volumes/wordpress-ibr4_wordpress/_data/wp-config.php.*-bak*
rm -f  /docker/wordpress-ibr4/docker-compose.yml.bak*

• DB-Passwort rotieren, falls es irgendwo im Klartext aufgetaucht ist.
• Strato-Dump nach erfolgreicher Kontrolle sichern/löschen.

PowerShell: Vorab-Test per hosts-Datei

<#
.NOTES
    Name:        PS_Hosts_Preview_VPS
    Author:      Andreas Bowitz
    Version:     0.2
    LastUpdated: 2026-Jun-03

.SYNOPSIS
    Setzt temporär einen hosts-Eintrag, um eine Domain vor der DNS-Umstellung
    auf die neue VPS-IP zeigen zu lassen (lokaler Test vom Windows-Client).
#>

$VpsIP  = "72.61.92.170"
$Domain = "abow.info"

$HostsFile = "$env:WINDIR\System32\drivers\etc\hosts"
$Entry     = "$VpsIP`t$Domain"

if (-not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()
    ).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    Write-Warning "Bitte PowerShell als Administrator starten."; return
}
if ((Get-Content $HostsFile) -match [Regex]::Escape($Domain)) {
    Write-Host "Eintrag fuer '$Domain' existiert bereits." -ForegroundColor Yellow
} else {
    Add-Content -Path $HostsFile -Value $Entry
    Write-Host "Hinzugefuegt: $Entry" -ForegroundColor Green
}
ipconfig /flushdns | Out-Null
Write-Host "Test: https://$Domain  (Zert-Warnung bis echtem DNS normal). Danach Zeile wieder entfernen." -ForegroundColor Cyan

Bash: Import-Helfer (auf dem VPS)

#!/usr/bin/env bash
# .NOTES
#   Name:        migrate_strato_to_docker
#   Author:      Andreas Bowitz
#   Version:     0.2
#   LastUpdated: 2026-Jun-03
#   Zweck:       DB-Dump in den db-Container importieren + Rechte setzen.
#                Im Compose-Projektverzeichnis ausfuehren.
set -euo pipefail

DB_CONTAINER="wordpress-ibr4-db-1"
WP_CONTAINER="wordpress-ibr4-wordpress-1"
DB_NAME="wordpress"
PREFIX="jryy_"
DUMP="${1:?Pfad zum SQL-Dump angeben}"

echo ">> Pruefe, ob Tabellen existieren ..."
COUNT=$(docker exec "$DB_CONTAINER" sh -c \
  "exec mysql -uwordpress -p\"\$MYSQL_PASSWORD\" -N -e \
   'SELECT COUNT(*) FROM information_schema.tables WHERE table_schema=\"$DB_NAME\";'")
if [ "$COUNT" -gt 0 ]; then
  echo "!! $COUNT Tabellen vorhanden. Erst leeren (manuell), dann erneut starten." ; exit 1
fi

echo ">> Importiere '$DUMP' ..."
docker exec -i "$DB_CONTAINER" \
  sh -c 'exec mysql -uwordpress -p"$MYSQL_PASSWORD" '"$DB_NAME" < "$DUMP"

echo ">> Rechte setzen ..."
docker exec "$WP_CONTAINER" chown -R www-data:www-data /var/www/html

echo ">> Kontrolle ..."
docker exec "$DB_CONTAINER" sh -c \
  "exec mysql -uwordpress -p\"\$MYSQL_PASSWORD\" $DB_NAME \
   -e 'SELECT option_value FROM ${PREFIX}options WHERE option_name=\"siteurl\";'"
echo ">> Fertig."

Troubleshooting (gesammelte Stolperfallen)

Fazit: Auf einem Docker-VPS verlagert sich der Umzug komplett in die Shell. Die eigentliche Arbeit sind nicht die Standard-Schritte (Dump rein, Files rein), sondern die Eigenheiten der Umgebung: Named Volume = _data (nie löschen), WORDPRESS_TABLE_PREFIX beim richtigen Service plus --force-recreate, Effektiv-Prüfung mit php -r statt grep, und Traefik im Host-Mode mit festem Port und server.url. Wer diese vier Punkte kennt, zieht beim nächsten Mal in 20 Minuten um – ohne Hilfe.

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.