Verwaltung von Exchange Server: Patches, Überwachung und der Weg in die Zukunft

Exchange Server befindet sich heute in einer anderen Lage als noch vor einem Jahr. Microsoft hat den Support für Exchange Server 2016 und 2019 am 14. Oktober 2025 eingestellt, und die darauf folgende sechsmonatige Übergangsphase mit erweiterten Sicherheitsupdates ist im April 2026 abgelaufen. Unternehmen, die noch eine dieser Versionen nutzen, ohne auf die Exchange Server Subscription Edition (SE) umgestiegen zu sein, arbeiten nun auf einer nicht mehr unterstützten Infrastruktur, für die keine Sicherheitsupdates mehr verfügbar sind und für die es keinen Weg zum allgemeinen Support gibt.

Für MSPs und IT-Teams, die Exchange-Umgebungen verwalten, verändert dies die Betriebslage erheblich. Die Frage lautet nicht mehr, wie man Exchange 2016 oder 2019 auf unbestimmte Zeit mit Patches versorgt. Vielmehr geht es darum, wie man Exchange SE im Produktionsbetrieb korrekt verwaltet und wie man den Übergang zu Microsoft 365 Exchange Online für jene Umgebungen plant, in denen ein lokales Exchange-System keinen Sinn mehr macht. Datto, Teil der Kaseya-Familie, unterstützt MSPs seit über 15 Jahren beim Schutz von Microsoft-Umgebungen – sowohl vor Ort als auch in der Cloud. Dieser Leitfaden stützt sich auf diese umfassende operative Erfahrung und erläutert, was in jeder Phase tatsächlich erforderlich ist.

Die Exchange Server-Landschaft im Jahr 2026: Was hat sich verändert?

Der Support für Exchange Server 2016 und 2019 endete am 14. Oktober 2025. Microsoft bot ein einmaliges, sechsmonatiges ESU-Programm an, das ausschließlich kritische und wichtige Sicherheitspatches umfasste, jedoch keinen allgemeinen Support beinhaltete; dieses Programm lief bis April 2026.

Ab Mai 2026 betreiben alle Organisationen, die weiterhin Exchange Server 2016 oder 2019 ohne ESU-Abonnement nutzen, eine nicht mehr unterstützte und ungepatchte Messaging-Infrastruktur. Microsoft hat zudem angekündigt, dass für veraltete lokale Exchange-Konfigurationen, die eine Verbindung zu Exchange Online herstellen, möglicherweise SMTP-Drosselungen eingeführt werden – eine Maßnahme, die bereits für Exchange 2013 und frühere Versionen gilt. Der Druck zur Umstellung ist real und nimmt weiter zu.

Die Exchange Server Subscription Edition (SE) ist das derzeit von Microsoft unterstützte lokale Exchange-Produkt, dessen Support mindestens bis zum 31. Dezember 2035 bestätigt ist. Für Updates ist eine aktive Software Assurance erforderlich, und es wird ein Abonnementmodell mit häufigeren Update-Zyklen als bei früheren Versionen eingeführt. Für Unternehmen mit einem echten Bedarf an lokalen Lösungen ist die SE die richtige Wahl. Für alle anderen ist Microsoft 365 Exchange Online der strategisch richtige Weg.

Exchange Server SE: das neue Wartungsmodell

Exchange Server SE verändert die Art und Weise, wie Updates bereitgestellt und angewendet werden. Der vierteljährliche Rhythmus für kumulative Updates bleibt bestehen, doch SE führt eine engere Integration mit Windows Server und der Entra ID-Authentifizierung ein, wobei Kerberos für die Server-zu-Server-Authentifizierung ältere Authentifizierungsmechanismen ersetzt. CU1 für Exchange Server SE ist für das erste Halbjahr 2026 geplant.

Die Regeln für die Reihenfolge der Updates, die für Exchange 2016 und 2019 galten, gelten weiterhin: Kumulative Updates müssen vor Sicherheitsupdates installiert sein, und einige Sicherheitsupdates setzen einen bestimmten CU-Stand als Voraussetzung voraus. Dies ist keine Patch-Umgebung, die man einmal einrichtet und dann vergessen kann. Jeder Update-Zyklus erfordert eine Kompatibilitätsprüfung, die Bereitstellung in einer Testumgebung vor der Einführung in der Produktionsumgebung sowie die Planung von Wartungsfenstern, da die meisten Exchange Server-Updates einen Neustart des Dienstes erfordern, der den E-Mail-Verkehr unterbricht.

In hybriden Exchange-Umgebungen, in denen während der Migration oder für die dauerhafte Nutzung hybrider Identitäten ein lokal installiertes Exchange-System neben Exchange Online betrieben wird, ist die Verwendung der aktuellen Cumulative Update (CU) zwingend erforderlich. Microsoft hat in der Vergangenheit die Hybridverbindung von veralteten Exchange-Versionen eingeschränkt oder blockiert, und SE-Umgebungen im Hybridmodus müssen auf dem neuesten Stand sein, um die Integration aufrechtzuerhalten.

Patch-Management für Exchange Server SE

Ein effektives Patch-Management für Exchange Server SE erfolgt auf zwei parallelen Ebenen.

Der erste Bereich befasst sich mit der zugrunde liegenden Windows Server-Plattform: Betriebssystem-Patches, Sicherheitsupdates und die Wartungsaufgaben, die für jede Windows Server-Rolle gelten. Datto RMM verwaltet diese Ebene durch eine automatisierte, richtlinienbasierte Patch-Bereitstellung, einschließlich Compliance-Berichten, die den Patch-Status in der gesamten Umgebung anzeigen, sowie geplanten Wartungsfenstern, die verhindern, dass Bereitstellungen während der Geschäftszeiten erfolgen. Geräte außerhalb des Netzwerks, einschließlich Exchange-Server, auf die über VPN oder an Remote-Standorten zugegriffen wird, werden über den Datto RMM-Agenten abgedeckt, ohne dass Änderungen am Netzwerk erforderlich sind.

Der zweite Schritt ist Exchange-spezifisch und erfordert besondere Sorgfalt. Für Exchange-kumulative Updates und Sicherheitsupdates ist Folgendes erforderlich:

1. Überprüfung der Kompatibilität mit der aktuellen Version von Exchange SE vor der Bereitstellung

2. Eine Staging-Umgebung, die die Produktionsumgebung widerspiegelt, mit einem Testlauf vor jeder Änderung in der Produktion

3. Ein dokumentiertes Wartungsfenster, in dem der Neustart des Dienstes zu einem Zeitpunkt mit geringen Auswirkungen geplant ist

4. Überprüfung der Datenbankkonsistenz nach größeren Updates, um sicherzustellen, dass die Postfachdatenbanken ordnungsgemäß eingebunden wurden und der E-Mail-Verkehr wieder korrekt funktioniert

5. Das Rollback-Verfahren wurde dokumentiert und getestet, bevor die Änderung vorgenommen wurde

IT Glue, die Dokumentationsplattform von Kaseya, ist der Ort, an dem die Standardarbeitsanweisung für das Patchen von Exchange hinterlegt ist. Wenn der Prozess dort dokumentiert ist, wird er einheitlich befolgt, unabhängig davon, welcher Techniker ihn ausführt. Genau diese Einheitlichkeit verhindert den Fehlerfall „Wir haben die gleichen Schritte befolgt, aber ein anderes Ergebnis erzielt“, der auftritt, wenn das Patchen von Exchange auf dem institutionellen Gedächtnis statt auf einer dokumentierten Vorgehensweise beruht.

Ein Beispiel aus der Praxis, das das Risiko verdeutlicht: Ein MSP betreut 15 Kunden, von denen drei Exchange Server SE einsetzen. Der „Patch Tuesday“ steht an. Der Techniker installiert das Sicherheitsupdate auf dem ersten Kundenrechner gemäß dem üblichen Windows Server-Vorgehen, ohne die Voraussetzungen für das Exchange CU zu überprüfen. Das Update wird installiert, verursacht jedoch ein Problem mit dem Transportdienst, da die Exchange CU zwei Versionen hinterherhinkt. Die Diagnose dieses Problems dauert vier Stunden. Mit einem dokumentierten und getesteten Verfahren, das als ersten Schritt eine Überprüfung des CU-Levels vorsieht, tritt das Problem gar nicht erst auf.

Überwachung von Exchange Server: die wichtigsten Überprüfungen

Die Überwachung von Exchange Server umfasst mehrere verschiedene Ebenen, und wenn auch nur eine davon außer Acht gelassen wird, führt dies in der Regel zu einem Vorfall, der eigentlich früher hätte erkannt werden können.

Richtwerte für den Serverzustand. CPU-, Speicher- und Festplattenauslastung auf dem Exchange-Server selbst. Exchange ist ressourcenintensiv, und das Anwachsen der Festplattenkapazität durch Transaktionsprotokolle ist eine häufige Ursache für Probleme, die sich eher schleichend als plötzlich bemerkbar machen. Warnschwellenwerte sollten so festgelegt werden, dass eine Benachrichtigung erfolgt, bevor die Auslastung kritisch wird, und nicht erst, wenn dies bereits der Fall ist.

Verfügbarkeit und Zustand der Datenbanken. In DAG-Konfigurationen (Database Availability Group) sollten die Postfachdatenbanken ordnungsgemäß eingebunden sein und korrekt replizieren. Dabei spielen die Wachstumstrends der Datenbankgröße eine wichtige Rolle: Eine Datenbank, die im Vergleich zu ihrem Ausgangswert ungewöhnlich schnell wächst, deutet oft auf ein Problem mit der Datenaufbewahrungsrichtlinie oder ein außer Kontrolle geratenes Postfach hin.

Länge der E-Mail-Warteschlange. Eine anhaltend lange oder immer länger werdende E-Mail-Warteschlange ist eines der deutlichsten Frühwarnzeichen für ein Zustellungsproblem. Kurzzeitige Spitzen sind normal. Eine Warteschlange, die über mehrere Stunden hinweg wächst, ohne dass sich die Situation verbessert, deutet auf ein Problem mit dem Transportdienst, eine Verbindungsstörung zum Smart Host oder einen Zertifikatsfehler hin, der nachgelagerte Fehler bei der TLS-Aushandlung verursacht.

Ablauf von Zertifikaten. Dies ist die häufigste vermeidbare Ursache für Störungen im Exchange-Betrieb. Abgelaufene Zertifikate unterbrechen die Outlook-Verbindung, den OWA-Zugriff und den E-Mail-Verkehr, der auf TLS basiert. Exchange verwendet mehrere Zertifikate: das standardmäßige selbstsignierte Zertifikat, das zugewiesene Transportzertifikat sowie etwaige externe SSL-Zertifikate für die Client-Verbindung, wobei jedes Zertifikat seinen eigenen Ablaufzeitpunkt hat. Die automatisierte Überwachung des Zertifikatsablaufs in Datto RMM mit Warnmeldungen 60, 30 und 14 Tage vor Ablauf verhindert diesen Ausfall vollständig. Die Behebung ist kostengünstig und dauert nur wenige Minuten. Wenn der Vorfall unbeaufsichtigt auftritt, dauert die Diagnose in der Regel Stunden, da das Symptom (Clients können keine Verbindung herstellen) nicht offensichtlich auf ein Zertifikat als Ursache hindeutet.

Dienststatus. Die zentralen Exchange-Dienste – Transport, Mailbox und Clientzugriff – sollten auf unerwartete Ausfälle überwacht werden. Automatisierte Neustartverfahren für Ausfälle, deren Behebung als sicher gilt, verkürzen die Zeitspanne zwischen Erkennung und Behebung; Ausfälle, die nach dem Neustart erneut auftreten, erfordern jedoch eine manuelle Untersuchung.

Muster in Ereignisprotokollen. Die Windows-Ereignisprotokolle auf Exchange-Servern enthalten Frühwarnsignale für Datenbankprobleme, Authentifizierungsfehler und Replikationsprobleme in DAG-Umgebungen. Durch die Überwachung bestimmter Exchange-Ereignis-IDs – anstatt zu versuchen, alle Ereignisse zu überwachen – bleibt die Anzahl der Warnmeldungen überschaubar, während die wirklich wichtigen Signale erfasst werden.

Umstellung auf Microsoft 365: Planung des Übergangs

Für die meisten Unternehmen, die Exchange Server lokal betreiben, ist die Migration zu Exchange Online die strategische Ausrichtung. Die Funktionen von Microsoft 365 haben in den meisten Anwendungsfällen das Niveau von lokalem Exchange erreicht, und der operative Aufwand für den Betrieb und die Aktualisierung von Exchange Server vor Ort bringt im Vergleich zu einem verwalteten Clouddienst selten einen entsprechenden geschäftlichen Nutzen.

Die Komponenten der Migrationsplanung, die in der Regel den Zeitplan und den Aufwand bestimmen:

Verzeichnissynchronisierung. Azure Active Directory Connect (jetzt Microsoft Entra Connect) übernimmt die Identitätssynchronisierung zwischen dem lokalen Active Directory und Entra ID. In Hybridbereitstellungen ist dies in der Regel bereits eingerichtet. Für Organisationen, die ganz von vorne beginnen, ist die Konfiguration von Entra Connect der erste Schritt, von dem alles Weitere abhängt.

Koexistenz von E-Mail-Systemen. Während der Migration befinden sich einige Postfächer gleichzeitig lokal und andere in Exchange Online. Der E-Mail-Verkehr zwischen beiden Systemen muss reibungslos funktionieren. Dazu müssen die Hybridkonfiguration und die Konnektoren korrekt eingerichtet sein, bevor mit der Migration der Postfächer begonnen wird.

Öffentliche Ordner. Unternehmen mit älteren Strukturen für öffentliche Ordner stehen bei den meisten Exchange-Migrationen vor der größten Herausforderung. Moderne öffentliche Ordner, die mit Exchange 2013 eingeführt wurden, lassen sich reibungsloser migrieren als ältere öffentliche Ordner, doch in jedem Fall erfordert diese Komponente einen eigenen Bestandsaufnahme-, Planungs- und Testzyklus.

Stilllegung der lokalen Infrastruktur. Exchange Server kann nach Abschluss der Migration nicht einfach deinstalliert werden. Die lokale Exchange-Infrastruktur muss ordnungsgemäß stillgelegt werden. Dies geschieht anhand einer dokumentierten Vorgehensweise, bei der die Exchange-Rollen in der richtigen Reihenfolge entfernt, Active Directory-Attribute bereinigt und sichergestellt wird, dass keine verbleibenden Dienste oder Anwendungen von den lokalen Exchange-Endpunkten abhängig sind, bevor diese abgeschaltet werden.

Überlegungen zu Lizenzierung und Compliance. Unternehmen in regulierten Branchen, insbesondere im Gesundheitswesen und im Finanzdienstleistungssektor, unterliegen möglicherweise Anforderungen hinsichtlich des Datenstandorts oder der Aufbewahrungsfristen, die sich auf die Konfiguration von Microsoft 365 auswirken und die Migrationsplanung zeitaufwändiger machen. Diese sollten vor Beginn der Migration ermittelt werden und nicht erst währenddessen zutage treten.

Sicherheit von Exchange Online nach der Migration

Eine weit verbreitete Annahme bei der Migration zu Microsoft 365 ist, dass die Verantwortung von Microsoft für die Plattform bedeutet, dass die Daten geschützt sind. Das ist jedoch nicht der Fall – zumindest nicht in dem Sinne, wie Unternehmen dies normalerweise meinen, wenn sie von Datensicherung sprechen.

Microsoft gewährleistet die Verfügbarkeit der Dienste und die Ausfallsicherheit der Infrastruktur, bietet jedoch keine langfristige Sicherung von Postfachdaten mit granularer Wiederherstellung zu einem bestimmten Zeitpunkt. Werden Daten gelöscht – sei es versehentlich, vorsätzlich oder durch einen Ransomware-Angriff auf Cloud-Umgebungen –, reichen die nativen Aufbewahrungstools von Microsoft je nach Konfiguration der Aufbewahrungsrichtlinien und dem Zeitpunkt der Löschung möglicherweise nicht aus, um diese wiederherzustellen.

Datto SaaS Protection neben Exchange Online auch SharePoint, OneDrive, Teams und die übrigen Anwendungen der Microsoft 365-Suite SaaS Protection . Die Lösung bietet drei tägliche Backups mit Point-in-Time-Wiederherstellung und ermöglicht es MSPs und IT-Teams, einzelne E-Mails, Kalendereinträge oder ganze Postfächer zu einem beliebigen Sicherungszeitpunkt wiederherzustellen – unabhängig von den nativen Aufbewahrungsrichtlinien von Microsoft.

Der neue einheitliche Wiederherstellungsworkflow, der auf der Kaseya Connect 2026 vorgestellt wurde, geht noch einen Schritt weiter, indem er die Wiederherstellung von Microsoft 365 Exchange und die Wiederherstellung von Entra ID-Objekten in einem einzigen operativen Workflow vereint und so die Wiederherstellungszeit bei identitätsbezogenen Vorfällen verkürzt.

Entdecken Sie Datto SaaS Protection Microsoft 365.

Die operative Rolle von Dokumentation und Automatisierung

Die Verwaltung von Exchange Server in großem Maßstab – sei es über mehrere Kundenumgebungen hinweg bei einem MSP oder innerhalb einer komplexen internen IT-Infrastruktur – scheitert, wenn sie sich auf das Wissen einzelner Techniker stützt, anstatt auf dokumentierte und automatisierte Prozesse.

Drei Bereiche, in denen Dokumentation Vorfälle direkt verhindert:

Das Verfahren zur Patch-Sequenzierung. In IT Glue dokumentiert IT Glue der Überprüfung der Voraussetzungen für die CU als erster Schritt, dem Staging-Test als obligatorischem Kontrollpunkt und dem Zeitplan für das Wartungsfenster als bestätigtem Feld, bevor die Bereitstellung beginnt. Wenn dieses Verfahren vorhanden ist und befolgt wird, treten keine Vorfälle mehr bei der Exchange-Patch-Installation auf, die durch das Überspringen einer Voraussetzung verursacht werden.

Das Zertifikatsverzeichnis. Alle Exchange-Zertifikate in allen verwalteten Umgebungen, einschließlich Ablaufdaten, Erneuerungsquellen und dem jeweils zugewiesenen Dienst, sind in IT Glue dokumentiert. In Kombination mit der automatisierten Ablaufüberwachung in Datto RMM werden dadurch zertifikatsbedingte Ausfälle aus der Liste der unerwarteten Ereignisse gestrichen.

Die Checkliste für die Stilllegung nach der Migration. Eine Schritt-für-Schritt-Anleitung zur ordnungsgemäßen Entfernung der lokalen Exchange-Infrastruktur – dokumentiert und getestet. Migrationsprojekte, die sauber durchgeführt und anschließend ordnungsgemäß stillgelegt werden, verhindern die Situation, in der „wir zwar migriert haben, aber immer noch ein Exchange-Server in der Ecke läuft“ – eine Situation, die fortlaufende Patch- und Überwachungsaufgaben ohne geschäftliche Rechtfertigung mit sich bringt.

Kaseya Intelligence, das auf der Grundlage von mehr als 1 Milliarde Helpdesk-Tickets, 3 Exabyte an Backup-Daten und 17 Millionen verwalteten Endpunkten trainiert wurde, erweitert diese Prozesse um eine autonome Ebene: Es geht nicht mehr nur darum, Patch-Empfehlungen zu generieren, sondern diese auch ohne manuellen Eingriff auszuführen und die Ergebnisse zu überprüfen. Für Exchange Server-Umgebungen bedeutet dies, dass unbehobene Sicherheitslücken und versäumte Backup-Überprüfungen erkannt und behoben werden, bevor sie zu Vorfällen führen. Entdecken Sie Kaseya Intelligence.