Dieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(182.40000000000003, 55.00000000000001%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKB%3C/text%3E%3C/svg%3E)
Moin zusammen,
uns hat es heute Nacht nach den aktuellen Windows Updates eiskalt erwischt: Weder OWA noch die Outlook-Clients bekommen eine Verbindung zum Exchange.
Im IIS-Manager sieht es stark nach einem SSL Binding Failure auf der „Default Web Site“ oder dem „Exchange Back End“ aus. Kann es sein, dass das dämliche Update die Zertifikats-Bindings komplett zurückgesetzt oder gelöscht hat?
Wie gehen wir hier für den Restore am besten vor? Einfach im IIS das richtige Cert neu zuweisen und einen iisreset hinterherjagen, oder zerschießt uns das im laufenden Betrieb noch mehr, wenn wir das nicht über die Exchange PowerShell (EMS) machen?
Danke für schnelle Schützenhilfe, die Hütte brennt hier gerade etwas!
Eine leistungsstarke E-Mail-, Kalender- und Kollaborationsplattform, entwickelt von Microsoft für Unternehmenskommunikation und Datenmanagement.Verschiedene Themen, die nicht in bestimmte Kategorien passen.
Moin Katherine,
ja – ein defektes HTTPS-Binding, insbesondere auf 0.0.0.0:444, kann genau dieses Fehlerbild verursachen: OWA, ECP, EMS und die Outlook-Verbindungen fallen gleichzeitig aus. Aber bitte nicht einfach dasselbe Zertifikat auf beide Websites binden.
Der Sollzustand lautet:
| IIS-Site | Port | Zertifikat |
|---|---|---|
| Default Web Site | 443 | Öffentliches/produktives Exchange-Zertifikat mit Private Key |
| -------- | -------- | -------- |
| Default Web Site | 443 | Öffentliches/produktives Exchange-Zertifikat mit Private Key |
| Exchange Back End | 444 | Selbstsigniertes Zertifikat „Microsoft Exchange“ |
Nicht mit dem „Microsoft Exchange Server Auth Certificate“ verwechseln – das gehört nicht auf Port 444.
Zuerst prüfen:
Event 15021 beziehungsweise ein fehlendes/falsches Binding auf 0.0.0.0:444 wäre ein ziemlich eindeutiger Treffer. Microsoft beschreibt dieses Fehlerbild ausdrücklich bei fehlerhaften Exchange-Updates. Microsoft: Fix failed Exchange Server updates
Vor der Änderung kurz die IIS-Konfiguration sichern:
Dann:
Die Rückfrage zum Überschreiben des standardmäßigen SMTP-Zertifikats mit Nein beantworten und das neue Zertifikat anschließend auf Port 444 binden.
Erst danach IIS kontrolliert neu starten:
Das ist einem blinden iisreset vorzuziehen, ändert am notwendigen kurzen Ausfall aber nichts. Bei mehreren Exchange-Servern beziehungsweise Loadbalancing unbedingt nur einen Server nach dem anderen bearbeiten.
Falls die Bindings korrekt sind, aber HTTP 500 erscheint, spricht das eher für ein unvollständig installiertes Exchange-SU. Dann das exakt passende .msp erneut aus einer als Administrator gestarteten Eingabeaufforderung installieren und anschließend den Server neu starten. Prüft außerdem C:\ExchangeSetupLogs\ServiceControl.log, falls Exchange-Dienste nach dem Update deaktiviert geblieben sind.
Nach dem Restore:
Danach den aktuellen Microsoft-Exchange Health Checker laufen lassen.Moin Katherine,
ja – ein defektes HTTPS-Binding, insbesondere auf 0.0.0.0:444, kann genau dieses Fehlerbild verursachen: OWA, ECP, EMS und die Outlook-Verbindungen fallen gleichzeitig aus. Aber bitte nicht einfach dasselbe Zertifikat auf beide Websites binden.
Der Sollzustand lautet:
| IIS-Site | Port | Zertifikat |
|---|---|---|
| Default Web Site | 443 | Öffentliches/produktives Exchange-Zertifikat mit Private Key |
| Exchange Back End | 444 | Selbstsigniertes Zertifikat „Microsoft Exchange“ |
Nicht mit dem „Microsoft Exchange Server Auth Certificate“ verwechseln – das gehört nicht auf Port 444.
Zuerst prüfen:
Event 15021 beziehungsweise ein fehlendes/falsches Binding auf 0.0.0.0:444 wäre ein ziemlich eindeutiger Treffer. Microsoft beschreibt dieses Fehlerbild ausdrücklich bei fehlerhaften Exchange-Updates. Microsoft: Fix failed Exchange Server updates
Vor der Änderung kurz die IIS-Konfiguration sichern:
Dann:
Die Rückfrage zum Überschreiben des standardmäßigen SMTP-Zertifikats mit Nein beantworten und das neue Zertifikat anschließend auf Port 444 binden.
Erst danach IIS kontrolliert neu starten:
Das ist einem blinden iisreset vorzuziehen, ändert am notwendigen kurzen Ausfall aber nichts. Bei mehreren Exchange-Servern beziehungsweise Loadbalancing unbedingt nur einen Server nach dem anderen bearbeiten.
Falls die Bindings korrekt sind, aber HTTP 500 erscheint, spricht das eher für ein unvollständig installiertes Exchange-SU. Dann das exakt passende .msp erneut aus einer als Administrator gestarteten Eingabeaufforderung installieren und anschließend den Server neu starten. Prüft außerdem C:\ExchangeSetupLogs\ServiceControl.log, falls Exchange-Dienste nach dem Update deaktiviert geblieben sind.
Nach dem Restore:
Danach den aktuellen Microsoft-Exchange Health Checker laufen lassen.
Hallo Katherine,
Wenn das Problem unmittelbar nach den Windows-Updates begann, überprüfe die Zuweisung des Exchange-Zertifikats, bevor du Änderungen vornimmst. Verwenden Get-ExchangeCertificate Sie, um zu bestätigen, dass das korrekte Zertifikat dem IIS-Dienst zugewiesen ist, und wenn nötig mit Enable-ExchangeCertificate -Services IIS, dann führen Sie iisreset. Vermeiden Sie es, IIS-Bindungen direkt zu ändern, da Exchange-Zertifikate über die Exchange Management Shell verwaltet werden sollten. Wenn das Zertifikat bereits korrekt zugewiesen ist, überprüfen Sie den Event Viewer auf Fehler im Zusammenhang mit Schannel, HTTP.sys oder Exchange, um die Ursache zu identifizieren.
Harry.