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.

Viele Umgebungen haben unterschiedliche Zertifikate zwischen intern (Default Web Site) und extern am Netscaler/WAP oder Firewall. Hier musste ich einige Schritte gehen um passende öffentliche Zertifikate für eine valide Zertifikatskette nach intern zu kaufen/erzeugen und zu binden.
NTLMv1 war zum Glück gar kein Thema mehr.

Bitte konfiguriert eure Exchange Server/Umgebungen immer mit gleichen URLs (intern = extern) für alle virtuellen Verzeichnisse, das hätte es mir auf jeden Fall einfacher gemacht.
Hybrid-Konfigurationen sind auch kein Thema gewesen, da ich immer die Classic-Variante eingerichtet habe.
Hier und da musste ich noch das SSL-Abladen am Outlook-Anywhere deaktivieren aber das war es dann auch schon.

Ihr hoffe ihr habt eure Umgebungen gut im Griff.

Bei Fragen, fragen!

Wie immer berichte ich in diesem Artikel nur von meinen persönlichen Erfahrungen und Erkenntnissen.
Es handelt sich hierbei um keine offizielle Anleitung von Microsoft.
Ein nachhandeln geschieht auf eigene Gefahr.

Tatsächlich sind diese Einstellungen seit 2009 verfügbar und ein Thema von Windows IIS, wird aber jetzt zwingend benötigt, um Sicherheitslücken zu schließen.

Das Flussdiagramm stellt einmal dar, wie der Weg zum schließen der Lücken aussieht.

Hier nun aufgelistet die Einschränkungen:

• Extended Protection kann nicht auf Exchange Server 2013-Servern (Grundsätzlich aber ab Exchange Server 2013 CU23 möglich) aktiviert werden, die über öffentliche Ordner in der Koexistenzumgebung verfügen.
  • Hier werden die Public Folder sonst nicht mehr bei den Endbenutzern erscheinen
• Extended Protection kann nicht auf Exchange Server 2016 CU22 oder Exchange Server 2019 CU11 oder früher aktiviert werden, die die Public Folder Hierarchie hosten.
  • Läuft nur ab 2016 CU23 und 2019 CU12
• Extended Protection funktioniert nicht auf Hybridservern mit der Modern Hybridkonfiguration
  • Features wie Postfachmigration und Frei/Gebucht-Informationen werden unterbrochen
• NTLMv1 wird nicht unterstützt (sollte möglichst sowieso nicht mehr genutzt werden!) Anleitung
  • Nutzt ein Client dennoch NTLMv1, wird er ständig mit Passwortabfragen bombadiert
• SSL-Offload-Szenarien werden nicht unterstützt
  • Die Extended Protection schlägt aufgrund der SSL-Beendigung während des SSL-Offloads fehl. Um Extended Protection in Ihrer Exchange-Umgebung zu aktivieren, verwenden Sie kein SSL-Offloading mit Ihrem Load Balancer.
• Die TLS-Konfiguration
  • Konsistente TLS-Versionen:
    • Überprüfen Sie, dass alle Exchange-Server im Unternehmen die gleiche TLS-Version verwenden. Wenn beispielsweise ein Server TLS 1.2 verwendet, müssen alle anderen Server ebenfalls auf TLS 1.2 konfiguriert sein.
    • Abweichungen in den TLS-Versionen zwischen den Servern können zu Verbindungsproblemen mit den Clients führen und sollten vermieden werden.
  • SchUseStrongCrypto-Registrierungswert:
    • Setzen Sie den Wert des SchUseStrongCrypto-Registrierungswerts auf 1 auf allen Exchange-Servern innerhalb der Organisation.
    • Falls dieser Wert nicht explizit auf 1 festgelegt ist, kann der Standardwert je nach verwendeter .NET-Version interpretiert werden, was zu unerwünschten Konfigurationen führen kann.
  • SystemDefaultTlsVersions-Registrierungswert:
    • Stellen Sie sicher, dass der SystemDefaultTlsVersions-Registrierungswert ebenfalls explizit auf 1 festgelegt ist.
    • Wenn diese Werte nicht wie erwartet festgelegt sind, kann dies zu TLS-Konflikten führen, die wiederum zu Problemen bei der Clientkonnektivität führen.
• Softwarekompatibilität von Drittanbietern
  • Testen Sie Produkte von Drittanbietern in Ihrer Exchange Server-Umgebung, um sicherzustellen, dass sie ordnungsgemäß funktionieren, wenn der erweiterte Schutz aktiviert ist. Ich habe zum Beispiel Antivirenlösungen gesehen, die Verbindungen über einen Proxy senden, um Clientcomputer zu schützen, aber dies verhindert die Kommunikation mit dem Exchange-Server und sollte deaktiviert werden.

SSL-Bridging funktioniert, sofern im Exchange und Load-Balancer das gleiche Zertifikat verwendet wird.

SSL-Offloading für Outlook Anywhere ist standardmäßig aktiviert und muss deaktiviert werden, indem Sie die folgenden Schritte ausführen:

Set-OutlookAnywhere -Identity "EXCH1\rpc (Default Web Site)" -SSLOffloading $false

Sind all diese Einschränkungen geprüft und abgestimmt, kann die Extended Protection via Skript-Unterstützung aktiviert werden.

ExchangeExtendedProtectionManagement.ps1 ist ein Skript zur Automatisierung der Extended Protection des Windows-Authentifizierungsmoduls auf Exchange-Servern. Stellen Sie vor der Konfiguration sicher, dass die TLS-Einstellungen auf allen Servern, auf denen Sie den erweiterten Schutz aktivieren möchten, und auf dem Server, auf dem der Extended Protection bereits aktiviert ist, identisch sind, und dass die erforderlichen anderen Voraussetzungen gegeben sind.

Folgend eine Auflistung mit Beispiel Codezeilen zum ausführen:

PS C:\> .\ExchangeExtendedProtectionManagement.ps1

Einfache Ausführung über alle Server der Organisation.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames <Array_of_Server_Names>

Ausführen für nur bestimmte Server.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -SkipExchangeServerNames <Array_of_Server_Names>

Ausführen für alle Server außer …

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -FindExchangeServerIPAddresses -OutputFilePath "C:\temp\ExchangeIPs.txt"

Export einer Liste aller Exchange Server IPs in der Organisation.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -RollbackType "RestoreIISAppConfig"

Wiederherstellen der IIS-Einstellungen zuvor.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection

Aktuelle Einstellungen anzeigen.

Hier noch alle Parameter mit Erläuterung.

Offizieller Microsoft Artikel: Link