Exchange überwacht sich selbst – und niemand schaut zu

Ihr kennt diesen Moment: Das Monitoring-Dashboard zeigt keine Warnungen. Alles grün. Kein Alert, kein Ticket. Und trotzdem meldet sich jemand aus der Fachabteilung, weil seit einer Stunde keine E-Mails ankommen.

Dieses grüne Dashboard kommt allerdings nicht direkt von Exchange. Managed Availability, also Exchanges internes Überwachungs- und Selbstheilungssystem, bringt kein eigenes Dashboard mit. Managed Availability arbeitet im Hintergrund, leise und ohne euch aktiv zu informieren. Was ihr in eurer Monitoring-Lösung als grünen Status seht, ist immer eine Interpretation der Daten, die Managed Availability nach außen liefert. Und genau diese Interpretation kann vollständiger wirken, als sie tatsächlich ist.

So arbeitet Managed Availability im Hintergrund

Managed Availability wurde mit Exchange Server 2013 eingeführt und ist seitdem fester Bestandteil jeder Exchange-Installation. Die Idee dahinter ist sinnvoll: Exchange beobachtet sich selbst, erkennt Probleme und behebt sie, wenn möglich, automatisch, bevor Nutzende etwas davon mitbekommen.

Technisch setzt Managed Availability dafür auf drei Bausteine.

• Probes – aktive Tests, die Exchange regelmäßig gegen sich selbst ausführt: Ist ein Webdienst erreichbar? Funktioniert eine Datenbankverbindung? Antwortet ein SMTP-Endpoint?
• Monitors – Auswertungskomponenten, die Probe-Ergebnisse aggregieren und daraus einen übergeordneten Gesundheitszustand ableiten, organisiert in sogenannte Health Sets wie OWA, ActiveSync oder Mailflow.
• Responder – Aktionskomponenten, die ausgelöst werden, wenn ein Monitor einen kritischen Zustand meldet. Sie sind das ausführende Organ der Selbstheilung.

All das geschieht automatisch, ohne Ankündigung, ohne aktive Benachrichtigung. Managed Availability schreibt ihre Aktionen ins Ereignisprotokoll – das war es. Kein Alert, keine E-Mail, kein Push. Wer nicht aktiv auf das ManagedAvailability-Operational-Log schaut, erfährt von einer Responder-Aktion oft erst dann, wenn jemand fragt, warum der IIS heute Nacht neu gestartet wurde.

HealthMailboxen zeigen, dass Managed Availability aktiv ist

Einen konkreten Hinweis auf die Arbeitsweise von Managed Availability findet ihr direkt in euren Postfachdatenbanken: Systempostfächer mit Namen wie HealthMailbox-…, automatisch angelegt von Managed Availability, nicht von euch. Diese Postfächer sind die Werkzeuge der Probes. Managed Availabilitymeldet sich dort an, verschickt Testnachrichten, liest sie aus, prüft Kalenderoperationen.

Genau hier liegt die entscheidende Einschränkung. Ein Probe, der über eine HealthMailbox läuft, prüft, ob Exchange intern mit sich selbst kommunizieren kann. Das passiert mit Systemkonten, unter optimalen internen Netzwerkbedingungen und ohne externe Authentifizierungsabläufe. Ein solcher Test sagt aber nicht, ob sich eine reale Person mit ihrem Account von außen in OWA anmelden kann. Zwischen diesen beiden Aussagen liegt genau die Lücke, die externes Monitoring schließen muss.

Was das grüne Dashboard euch nicht sagt

Managed Availability überwacht, was Exchange selbst kontrolliert. Alles außerhalb dieser Grenze liegt im toten Winkel. Ein grüner Status auf eurem Monitoring-Dashboard bedeutet daher nicht:

• dass Nutzende sich tatsächlich bei OWA anmelden können
• dass der Mailflow in alle Richtungen funktioniert, inklusive der Hybridverbindung zu Exchange Online
• dass ein TLS-Zertifikat auf dem vorgelagerten Load Balancer noch gültig ist
• dass Autodiscover für externe Clients erreichbar ist
• dass die DAG-Replikation zwischen allen Mitgliedern konsistent läuft
• dass ein Zertifikat in zwei Wochen abläuft

Außerdem ist Managed Availability kein Frühwarnsystem. Sie reagiert auf Zustände, die bereits eingetreten sind, nicht auf Trends, die sich langsam ankündigen. Steigende Queue-Längen oder wachsender Ressourcendruck werden erst eskaliert, wenn ein Probe tatsächlich fehlschlägt. Wenn ihr früher eingreifen wollt, braucht ihr zusätzliche Metriken.

System-Monitoring ist kein Exchange-Monitoring

Viele Organisationen glauben, ihre Exchange-Umgebung sei überwacht, weil ein Monitoring-Agent auf dem Server läuft. Was dieser Agent in der Regel macht, ist Infrastruktur-Monitoring: Ist der Server erreichbar? Wie hoch ist die CPU-Last? Wie voll sind die Laufwerke? Wie viele Nachrichten liegen in der Warteschlange? Das sind nützliche Metriken. Aber sie sagen nichts darüber aus, ob Exchange als Anwendung tatsächlich funktioniert.

Der Blick auf Managed Availability und die Exchange Health Sets fehlt dabei fast immer. In der Praxis prüft der Agent vielleicht per Eventlog-Auswertung, ob bestimmte kritische Ereignisse eingetragen wurden. Vielleicht kontrolliert er noch, ob die Postfachdatenbanken eingebunden sind. Damit endet dann oft schon das Exchange-Monitoring.

MA und ihre Health Sets bleiben dabei häufig außen vor. Kein Check, ob ein Health Set auf Degraded oder Unhealthy steht. Kein Blick in das ManagedAvailability-Operational-Log. Kein Test, ob Probes systematisch fehlschlagen. Viele klassische Monitoring-Lösungen beziehen diese Informationen nicht automatisch ein oder werten sie nur am Rand aus.

Das Ergebnis kann ein falsches Sicherheitsgefühl sein. Der Agent meldet grün, weil die Infrastruktur steht. MA meldet intern möglicherweise längst einen degradierten Zustand und hat bereits begonnen, Responder auszuführen. Beides kann parallel laufen, ohne dass die eine Seite von der anderen weiß. Wer nur auf ein generisches Infrastruktur-Dashboard schaut, sieht davon unter Umständen nichts.

Wenn die Selbstheilung zum Problem wird

Der riskanteste Aspekt von Managed Availability ist nicht nur, was sie übersieht. Spannend wird es vor allem dann, wenn sie aktiv wird. Responder führen automatisierte Aktionen aus, und deren Auswirkungen könnt ihr je nach Situation sehr deutlich spüren.

• Neustart eines Application Pools – Kaum sichtbar. Die erste Person, die danach OWA öffnet, wartet kurz auf den ASP.NET-Warmup. Für Admins ohne gezieltes App-Pool-Monitoring bleibt dieser Eingriff unsichtbar.
• Neustart von IIS – Spürbar. Aktive OWA-Sessions brechen ab, Autodiscover-Anfragen schlagen kurzzeitig fehl, ActiveSync-Clients verlieren ihre Verbindung.
• Neustart von Exchange-Transportdiensten – Betrifft den Mailflow direkt. Nachrichten im Zustellungsprozess werden verzögert, Verbindungen zu Smarthost oder Exchange Online kurzzeitig unterbrochen.
• Vollständiger Server-Neustart nach Bug-Check – Die gravierendste Aktion. In einer gut konfigurierten DAG-Umgebung übernimmt ein anderes Mitglied die Datenbanken, und Nutzende bemerken allenfalls eine kurze Unterbrechung. In Single-Server- oder Dual-Server-Umgebungen ohne vollständige DAG bedeutet das eine vollständige Mailflow-Unterbrechung, ohne vorherige Warnung, ohne die Möglichkeit einzugreifen.

Besonders tückisch ist das Szenario eines falsch ausgelösten Probes: Ein vorübergehender Netzwerk-Timeout oder eine kurze Ressourcenspitze lässt einen Probe fehlschlagen. Managed Availability interpretiert das als kritischen Zustand, startet IIS oder den gesamten Server neu. Das ursprüngliche Problem, etwa ein instabiles Netzwerksegment, bleibt unberührt. Der Neustart war eine Reaktion auf ein Symptom, nicht auf die Ursache.

Server-Neustarts durch Bug-Check hinterlassen Spuren im Windows System Event Log. Event ID 41 (Quelle: Kernel-Power) dokumentiert den unerwarteten Neustart, Event ID 6008 (Quelle: EventLog) den nachfolgenden unordentlichen Systemstart. Wenn ihr diese Ereignisse nicht aktiv überwacht, bleibt ein nächtlicher Neustart manchmal unbemerkt.

Alert Fatigue macht Monitoring schnell wertlos

Wer die Grenzen von Managed Availability erkennt, ist versucht, die Lösung in mehr Monitoring zu suchen. Mehr Metriken, mehr Schwellenwerte, mehr Alerts. Das ist verständlich, aber gefährlich, wenn dabei ein Prinzip verloren geht: Ein Monitoring-System, das zu viel meldet, wird nicht mehr ernst genommen.

Alert Fatigue ist kein Komfortproblem. Sie ist ein echtes Betriebsrisiko. Das Muster kennt ihr vermutlich: Eine Monitoring-Lösung wird eingerichtet, anfangs sorgfältig konfiguriert, dann wächst die Umgebung, Schwellenwerte passen nicht mehr, und mit der Zeit produziert das System täglich Dutzende von Meldungen. Die meisten davon sind False Positives, ausgelöst durch schlecht kalibrierte Grenzwerte oder Checks, die nie an die reale Umgebung angepasst wurden.

Admins entwickeln Strategien, um mit diesem Rauschen umzugehen. Alert-Mails wandern in Ordner, die nur noch sporadisch geöffnet werden. Tickets werden automatisch geschlossen. Die Schwelle, ab der ein Alert als relevant eingestuft wird, steigt immer weiter. Bis an dem Tag, an dem ein echter Ausfall als weiterer False Positive behandelt wird.

Gutes Monitoring meldet nicht alles, sondern das Richtige. Dafür braucht ihr kalibrierte Schwellenwerte, eindeutige Prioritäten und klare Eskalationspfade. Alert Fatigue lässt sich in den Griff bekommen, aber nur, wenn ihr sie als strukturelles Problem behandelt und aktiv angeht.

Gutes Monitoring schließt die Lücken

Ein vollständigeres Exchange-Monitoring sollte deshalb nicht nur Serverwerte sammeln, sondern den Dienst aus Sicht der Nutzenden prüfen. Dazu gehören synthetische Transaktionen, die den tatsächlichen Nutzungspfad simulieren: Anmeldung an OWA inklusive Authentifizierung, Mailflow-Tests über relevante Transportstrecken sowie Protokollchecks für MAPI, EWS, ActiveSync und Autodiscover. Entscheidend ist nicht nur, ob ein interner MA-Probe erfolgreich war, sondern ob Exchange so funktioniert, wie Nutzende es im Alltag erwarten.

Genauso wichtig sind Metriken, die Managed Availability nicht vollständig abdeckt: Zertifikatslaufzeiten, DAG-Replikationsstatus, Queue-Health, hybride Verbindungsqualität, externe Erreichbarkeit und der Status von Exchange Online. Gute Monitoring-Lösungen führen diese Informationen in einer verständlichen Sicht zusammen und melden nicht einfach alles, sondern die relevanten Abweichungen rechtzeitig und nachvollziehbar.

ENow ist ein Beispiel für eine Lösung, die diesen Ansatz verfolgt und Exchange-Umgebungen mit synthetischen Tests, Protokollprüfungen und zentraler Sicht auf hybride Szenarien überwacht. Wichtig ist aber weniger der Produktname als das Prinzip: Exchange-Monitoring muss die Perspektive der Nutzenden, die internen Managed Availability-Zustände und die Infrastrukturmetriken sinnvoll zusammenbringen.

Grün ist eine Farbe, kein Beweis

Managed Availability ist eine nützliche Funktion. Sie macht Exchange resilienter, reagiert automatisch auf bestimmte Fehlerzustände und entlastet Admins bei typischen Betriebsproblemen. Aber sie ist kein Monitoring im vollständigen Sinne, und sie ersetzt keine externe Überwachungslösung.

Wenn das Dashboard grün zeigt, bedeutet das nur, dass eure Monitoring-Lösung aus den verfügbaren MA-Daten keinen kritischen Zustand abgeleitet hat. Es beweist nicht, dass Exchange aus Sicht der Nutzenden funktioniert. Wer diesen Unterschied kennt, trifft bessere Entscheidungen über seine Monitoring-Strategie.

Im nächsten Artikel dieser Serie schauen wir uns Alert Fatigue genauer an: Wie entsteht sie, woran erkennt ihr sie in eurer Umgebung, und wie kommt ihr wieder zu einem Monitoring, dem ihr tatsächlich vertrauen könnt.