Manchmal beginnt ein „kleines“ Problem mit einem einzigen Server, der nach der Installation eines Windows-Updates nicht mehr sauber startet, und endet in einer mehrstündigen Reise durch Cluster-Internas, Active Manager, AD-Replikation und am Ende sogar mit einem Verdacht gegen die Endpoint-Security-Lösung. Genau das ist mir kürzlich bei einem Kunden passiert, den ich hier anonymisiert als fiktive „Varuna Group“ mit der Domäne varunagroup.de beschreibe. Alle Server- und IP-Angaben sind ebenfalls fiktiv.
Ausgangslage
Die Umgebung: eine klassische Zwei-Knoten-Database-Availability-Group, IP-los konfiguriert, mit File-Share-Witness. Zwei Mailbox-Server, hier EX01.varunagroup.de und EX02.varunagroup.de, in der DAG DAGVAR01. Die meisten Postfächer der Varuna Group sind bereits in Exchange Online. In der On-Premises-Umgebung verblieben sind im Wesentlichen das Journal-Postfach und ein paar Hybrid-Restfunktionen. Die Hauptaufgabe der Exchange Server besteht in der Bereitstellung des hybriden Nachrichtenflusses zwischen der lokalen Exchange Organisation und Exchange Online. Die Zustellung von E-Mails für Exchange Online-Postfächer war selbst nicht gestört.
Im August 2026 wurde auf beiden Exchange Servern das reguläre Windows-Update installiert. Zumindest wurde dies angenommen. Die Update-Installation schlug auf EX01 fehl. Und nach dem Neustart ließ sich der Cluster-Dienst auf diesem Server nicht mehr starten.
Symptom 1: Clusterdienst startet nicht (Event ID 7024)
Der erste Blick ins Eventlog zeigte:
Event 7000 / 7024, Service Control Manager
The Cluster Service service failed to start due to the following error:
The system cannot find the file specified.
Das bekannte Muster nach gescheiterten Update-Installationen ist, dass die lokale Cluster-Datenbank (C:\Windows\Cluster\CLUSDB) fehlt oder beschädigt ist, weil die Update-Installation während eines Schreibvorgangs abgebrochen wurde. Zu diesem Zeitpunkt arbeitete der zweite Knoten, EX02, weiterhin fehlerfrei und übernahm die gesamte Last.
Lösungsansatz: Da EX02 stabil lief, war der beste Weg, EX01 zunächst aus dem Cluster zu entfernen und später wieder hinzuzufügen, anstatt an der beschädigten lokalen Datenbank zu arbeiten. Der von Microsoft empfohlene Ansatz besteht darin, Exchange-DAG-Cmdlets zu verwenden, statt der Cluster-Cmdlets.
Stop-DatabaseAvailabilityGroup -Identity DAGVAR01 -MailboxServer EX01 -ConfigurationOnly
Wichtig dabei ist, dass : -ConfigurationOnly nur die AD/DAG-Konfiguration bereinigt, den Server jedoch weder aus dem Cluster noch aus der Serverliste der DAG entfernt..
Der Versuch, den Server mithilfe des oben genannten Cmdlets erfolgreich aus der DAG zu entfernen, war leider erfolglos. Get-DatabaseAvailabilityGroup -Status warf danach weiterhin RPC-Fehler für den „toten“ Server.
Der eigentliche Cluster-Evict musste separat erfolgen:
Remove-ClusterNode -Name EX01 -Force
DIe Bereinigung der Datenbankkopien sowie die DAG-Mitgliedschaft selbst wurden über die dafür vorgesehenen Cmdlets bereinigt.
Remove-MailboxDatabaseCopy -Identity "DBVAR01\EX01"
Remove-DatabaseAvailabilityGroupServer -Identity DAGVAR01 -MailboxServer EX01
Bei einer IP-losen DAG liefert Get-ClusterQuorum -Cluster <DAGName> oder ähnliche Cmdlets mit explizitem -Cluster-Parameter oft irreführende Fehler, weil kein Cluster-Name-Object mit IP existiert. Ohne den Parameter, also im lokalen Kontext des Servers asugeführt, funktionieren die Abfragen zuverlässiger.
Symptom 2: Automount Consensus schlägt fehl (FSW Boot Time Mismatch)
Nachdem EX01 aus der DAG entfernt worden war, verweigerte Active Manager auf EX02 praktisch jede Operation, von der Statusabfrage bis hin zum simplen Dismount-Database.
Error: Automount consensus not reached (Reason: FSW boot time did not match
(FSW-Remote: 2026-08-13T22:54:18Z FSW-Reg: 0001-01-01T00:00:00))
Für den File Share Witness (FSW) wird ein lokal in der Cluster-Registry hinterlegter Zeitstempel des File Share Witness-ZUgriffs mit dem tatsächlichen Wert der FSW-Lock-Datei verglichen. Nach der Reduktion von zwei auf einen Node stimmte dieser Wert nicht mehr überein. Oder anders gesagt, der Wert in der Registry entsprach dem Wert einer Neuinitialisierung.
Ein einfacher Offline/Online-Zyklus der Witness-Ressource half nicht.
Stop-ClusterResource -Name "File Share Witness (\\fsw.varunagroup.de\DAGVAR01.varunagroup.de)"
Start-ClusterResource -Name "File Share Witness (\\fsw.varunagroup.de\DAGVAR01.varunagroup.de)"
Auch eine Neukonfiguration der Witness-Einstellungen über Exchange änderte nur die Fehlermeldung („An empty FSW boot time was passed in — unsafe to allow mounting!„), löste das eigentliche Problem aber nicht. Die Datenbanken wurden nicht mehr eingebunden.
Konsequenz
Um den produktiven Betrieb nicht weiter zu gefährden, wurde EX02 aus der DAG entfernt und als Standalone-Mailbox-Server weiterbetrieben.
Set-DatabaseAvailabilityGroup -Identity DAGVAR01 -DatacenterActivationMode Off
Remove-DatabaseAvailabilityGroupServer -Identity DAGVAR01 -MailboxServer EX02
Mount-Database DBVAR01
Mount-Database DBVAR02
Ohne Cluster-/DAG-Abhängigkeit konnten beide Datenbanken sofort und ohne Fehler eingebunden werden.
Symptom 3: Volle Journaling-Queue durch Store-Thread-Limit
Während der DAG nicht verfügbar war, staute sich die Journaling-Queue auf über 30.000 Nachrichten auf. Nach dem erfolgreichen Mount der Datenbanken lief die Queue jedoch nicht sofort leer, sondern die Zustellung an die Journal-Mailbox schlug weiterhin fehl.
432 4.3.2 STOREDRV.Deliver; recipient thread limit exceeded
Das ist kein Routing-Problem, sondern eine bewusste Selbstschutz-Drosselung des Information Stores. Er begrenzt die Anzahl gleichzeitiger Zustellthreads pro Empfänger. Bei einer derart großen Nachstau-Menge erreicht ein einzelnes Postfach sofort wieder das Limit.
Ergebnis
Eigentlich war kein Eingriff nötig, da sich die Queue in Wellen von selbst abbaut. Wir haben es uns doch erlaubt, den Wert MaxConcurrentMailboxDeliveries des Transportdienstes zu erhöhen. Da dieser Wert jedoch für alle Postfächer gilt, ist es eine Ausweichung des Exchange Server-Selbstschutzes.
Warum haben wir uns für diese Anpassung entschieden?
Da sich nur wenige Postfächer On-Premises befinden, ist das Risiko einer höheren Zustelllast tragbar.
Der Abbau der Warteschlange dauerte ca. 45 Minuten.
Der Neuaufbau der DAG – und ein Verdachtsmoment
Nachdem EX01 clusterseitig bereinigt war (unter anderem musste das Failover-Clustering-Feature auf EX01 komplett deinstalliert und neu installiert werden, da die Basisstruktur für den Cluster-Dienst nach dem Umbenennen des defekten Cluster-Ordners fehlte), wurde die DAG neu aufgebaut. Hierbei wurde das bestehende DAG-Objekt verwendet.
Add-DatabaseAvailabilityGroupServer -Identity DAGVAR01 -MailboxServer EX02
Add-DatabaseAvailabilityGroupServer -Identity DAGVAR01 -MailboxServer EX01
Add-MailboxDatabaseCopy -Identity DBVAR01 -MailboxServer EX01
Add-MailboxDatabaseCopy -Identity DBVAR02 -MailboxServer EX01
Ein wichtiger Punkt zur Einordnung
Sämtliche dieser Wiederherstellungsschritte, vom ersten stabilen Get-DatabaseAvailabilityGroup -Status ohne Automount-Fehler bis zum erfolgreichen Seeding der Kopien auf EX01. ließen sich erst durchführen, nachdem die Endpoint-Security-Lösung (in dieser Umgebung SentinelOne) auf beiden Servern deaktiviert wurde. Das ist ein reiner Indizienbeweis, kein belastbarer technischer Nachweis. Es gibt keine protokollierte, eindeutig zuordenbare Blockierung durch den EDR-Agenten, die die konkrete Fehlerursache (leerer FSW-Boot-Time-Wert, RPC-Fehler 0x6d9 beim Zugriff auf die Cluster-API) direkt erklärt. Auffällig war lediglich, dass Process Monitor von Sysinternals bei aktivem Agenten nicht startbar war, was eine weitere Verifikation erschwerte.
Nach Abschluss der Wiederherstellung wurden gemeinsam mit dem Security-Team die AV-Ausnahmen für Cluster- und Exchange-Prozesse geprüft und ergänzt, bevor der Endpunktschutz kontrolliert wieder aktiviert wurde. Die Umgebung wird seither gezielt beobachtet, um zu prüfen, ob sich das Automount-Problem oder andere Herausforderungen erneut zeigen.
Unabhängig vom Ausgang dieser Beobachtung gilt, dass korrekt konfigurierte AV-/EDR-Ausnahmen für Exchange- und Cluster-Prozesse, -Pfade und -Dienste keine Kür sind, sondern eine zwingende Voraussetzung für einen stabilen Betrieb eines Exchange-Servers. Die einschlägigen Microsoft-Empfehlungen für Exchange-Server-Ausnahmen sollten bei jedem Rollout und nach jedem Wechsel der Security-Lösung erneut gegengecheckt werden, inklusive Verhaltens- bzw. AMSI-basierter Scan-Engines, die über reine Datei-Exclusions hinausgehen.
Fazit
Ein einzelnes fehlgeschlagenes Update kann eine Kette von Folgefehlern auslösen, die auf den ersten Blick nichts miteinander zu tun haben.
- Cluster-Datenbank
- Quorum-Mechanismus
- vergessene Wartungsflags (ja, die spielten auch mit)
- überlastete Journaling-Queue
Der Schlüssel zur Lösung lag darin, jedes Symptom einzeln sauber zu isolieren, EMS-Wege konsequent gegenüber direkten Cluster-Eingriffen zu bevorzugen und am Ende auch unbequeme Fragen zur eigenen Security-Infrastruktur nicht zu scheuen.
Wie bereits erwähnt, funktioniert die Exchange-Umgebung aktuell wieder. Aber es bleibt der fade Beigeschmack, nicht alle Störungsphänomene einwandfrei entdeckt zu haben.
PS: Während des Troubleshootings kam noch ein Nebenschauplatz hinzu, der es wert ist, kurz erwähnt zu werden: Im Rahmen einer separaten Aufräumaktion wurden zwei Domain Controller aus einem Testnetz der Varuna Group entfernt (demotet). Für die Exchange-Server selbst blieben beide DCs bis zur Demotion netzwerktechnisch erreichbar, sie konnten allerdings schon länger keine funktionierende AD-Replikation mehr durchführen. Erschwerend kam hinzu, dass beide DCs organisatorisch derselben AD-Site zugeordnet waren wie die produktiven Domain Controller, wodurch sie im Site-Kontext zunächst wie vollwertige, aktuelle Replikationspartner wirkten. Das war zwar am Ende nicht ursächlich für die DAG-Probleme, hat die Fehlersuche aber zwischenzeitlich zusätzlich verkompliziert, weil eine AD-Replikationsstörung als weitere mögliche Fehlerquelle mit auf dem Tisch lag und erst ausgeschlossen werden musste.
