Exchange-Ausfälle nach den Windows-Server-Updates vom Oktober 2026: MapiExceptionMdbOffline (ec=1142)

Seit dem Patchday vom 13. Oktober 2026 fallen Exchange-Server nach rund 24 Stunden Laufzeit aus: Clients verlieren die Verbindung zum Postfach, OWA meldet MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142), Mails bleiben in den Warteschlangen liegen, und in DAGs replizieren die Datenbankkopien nicht mehr. Microsoft hat die Ankündigung der Oktober-Exchange-SUs am 15. Oktober 2026 um einen Hinweis ergänzt: Auslöser sind die Oktober-Updates für Windows Server, die Installation des Exchange-SUs ist für das Problem nicht erforderlich. Einen Fix oder offiziellen Workaround gibt es noch nicht (Stand 16. Oktober 2026).

Symptome

Die bisher berichteten Symptome:

• OWA schlägt mit MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142) fehl; im Application Log steht Event ID 1006.
• Outlook-Clients verlieren die Verbindung zum Postfach.
• Mails werden weder intern noch extern zugestellt, die Transport-Warteschlangen wachsen.
• In DAGs replizieren die Datenbankkopien nicht mehr; Switchover beim Wechsel in den Wartungsmodus schlagen laut Leserberichten bei Born fehl.
• Das Exchange Admin Center zeigt die Datenbanken trotzdem als gemountet an (Frankys Web).

Der Fehler tritt nicht direkt nach der Installation auf, sondern laut Berichten nach etwa 22 bis 30 Stunden Laufzeit. Ein Neustart des Servers stellt den Betrieb wieder her, der Ausfall wiederholt sich aber nach ungefähr derselben Zeit. In Kommentaren bei Born wird beobachtet, dass sich der Postfach-Replikationsdienst während oder nach den Datenbank-Wartungsaufgaben beendet und die MdbOffline-Fehler danach einsetzen; bestätigt ist das nicht.

Betroffene Updates

Microsoft nennt im Nachtrag zur Exchange-Ankündigung diese kumulativen Windows-Updates:

Am selben Patchday sind auch die Exchange-SUs (Exchange SE: KB5128895, «SU11») und kumulative Updates für das .NET Framework erschienen. Auf einem betroffenen Exchange SE unter Windows Server 2019 waren diese drei Pakete installiert:

• Security Update For Exchange Server Subscription Edition (KB5128895)
• 2026-10 Cumulative Update for .NET Framework 3.5, 4.7.2 and 4.8 for Windows Server 2019 for x64 (KB5128923)
• 2026-10 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5126651)

Microsoft erwähnt das .NET-Update im Nachtrag nicht. Leser bei Born berichten aber von Ausfällen mit der Kombination aus Windows- und .NET-Update (dort KB5128928 unter Windows Server 2022) und von einem Server mit KB5126651 und Exchange-SU, jedoch ohne .NET-Update, der nach über 24 Stunden noch lief. Ob das .NET-Update beteiligt ist, ist damit offen.

Zum Exchange-SU: In Foren und Kommentaren heisst es, die Lage bessere sich, wenn das Exchange SU11 installiert ist. Das lässt sich nicht bestätigen; die Ausfälle traten auch auf einem Server mit SU11 auf. Umgekehrt berichten mehrere Administratoren von Ausfällen ohne installiertes Exchange-SU, was zu Microsofts Aussage passt. Das Exchange-SU schliesst sechs Schwachstellen, darunter eine kritische Remote-Code-Execution über eine präparierte E-Mail; Details im Artikel zum Oktober-SU. Es zurückzuhalten, behebt das Problem nicht.

Stand prüfen

Ermitteln Sie zuerst auf jedem Exchange-Server, welche der Oktober-Updates installiert sind:

$kbs = "KB5126646", "KB5126655", "KB5126651", "KB5126868", "KB5128923"
Get-HotFix -Id $kbs -ErrorAction SilentlyContinue |
  Select-Object PSComputerName, HotFixID, InstalledOn

Get-HotFix listet .NET-Updates nicht auf allen Systemen zuverlässig; im Zweifel zeigt der Updateverlauf in den Einstellungen den vollständigen Stand. Den Exchange-Build prüfen Sie in der Exchange Management Shell mit Get-ExchangeServer | Format-Table Name, AdminDisplayVersion und gleichen ihn mit den Exchange-Buildnummern ab.

Anschliessend den Zustand von Datenbanken, Kopien und Warteschlangen in der Exchange Management Shell:

Get-MailboxDatabaseCopyStatus -Server $env:COMPUTERNAME |
  Format-Table Name, Status, CopyQueueLength, ReplayQueueLength, ContentIndexState
Get-Queue | Where-Object MessageCount -gt 0 |
  Format-Table Identity, DeliveryType, Status, MessageCount, LastError
Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1006; StartTime=(Get-Date).AddDays(-2)} |
  Select-Object TimeCreated, ProviderName, Message

Event ID 1006 protokollieren mehrere Exchange-Komponenten; entscheidend ist der Eintrag mit der MdbOffline-Meldung im Text.

Vorgehen bis zum Fix

Microsoft untersucht das Problem nach eigener Aussage zusammen mit dem Windows-Team und nennt bisher weder Workaround noch Rollback. Für die Zwischenzeit:

1. Noch nicht aktualisierte Exchange-Server: Stellen Sie die Windows-Oktober-Updates (und das .NET-Update vom selben Tag) auf Exchange-Servern zurück, in WSUS, Intune oder der eigenen Updateverwaltung. Das ist eine Abwägung: Die Windows-Updates schliessen ebenfalls Sicherheitslücken. Exchange-Server, die aus dem Internet erreichbar sind, sollten Sie deshalb besonders eng begleiten.

2. Exchange-SU trotzdem installieren: Das Exchange-SU KB5128895 (bzw. die ESU-Pakete für 2016/2019) ist laut Microsoft nicht der Auslöser und schliesst eine kritische Lücke, die ohne Konto per E-Mail ausnutzbar ist.

3. Bereits betroffene Server: Ein Neustart stellt den Betrieb für rund einen Tag wieder her. Planen Sie kontrollierte Neustarts in einem Abstand von deutlich unter 22 Stunden, zum Beispiel jede Nacht, statt auf den nächsten Ausfall zu warten. Ein Neustart nur der Exchange-Dienste hilft laut Lesern bei Born ebenfalls vorübergehend; wie lange, ist nicht belegt.

4. DAG: Starten Sie die Mitglieder nacheinander neu und verschieben Sie die aktiven Datenbanken vorher auf einen frisch gestarteten Server. Prüfen Sie nach jedem Neustart mit Get-MailboxDatabaseCopyStatus, ob die Kopien wieder Healthy sind und die Queues abgebaut werden, bevor Sie den nächsten Server neu starten.

5. Warteschlangen überwachen: Behalten Sie Get-Queue und die Event ID 1006 im Blick, idealerweise mit einer Alarmierung, damit ein Ausfall nicht erst durch Benutzermeldungen auffällt.

6. Backup prüfen: Ein Leser bei Born meldet nach dem Ausfall einen fehlgeschlagenen VSS-Writer im Backup. Kontrollieren Sie die Sicherungen der letzten Nächte.

Zur Deinstallation der Windows-Updates: Seit 2021 liefert Microsoft das kumulative Update zusammen mit dem Servicing Stack Update als kombiniertes Paket aus. wusa /uninstall entfernt ein solches Paket nicht; dafür ist DISM /Online /Remove-Package mit dem Paketnamen aus DISM /Online /Get-Packages nötig. Microsoft hat die Deinstallation als Workaround nicht freigegeben, und Berichte über einen erfolgreichen Rollback mit anschliessend stabilem Betrieb liegen bisher nicht vor. Testen Sie das, wenn überhaupt, zuerst auf einem einzelnen Server.

Laut Frankys Web führt Microsoft das Problem bei den Windows-Updates noch nicht als Known Issue (Stand 16. Oktober 2026). Behalten Sie die Microsoft-Ankündigung im Blick; Microsoft führt Ergänzungen dort am Ende unter «Updates to this blog post». Dieser Artikel wird nachgeführt, sobald ein Fix oder ein offizieller Workaround vorliegt.