Thomas Stensitzki is a leading technology consultant focusing on the Microsoft messaging and collaboration technologies and the owner of Granikos GmbH & Co. KG.
He is an MVP for Office Apps & Services since 2018.
Thomas is an MCT Regional Lead for Germany and delivers Microsoft Learning training courses for Office 365, Microsoft Teams, and Exchange Server.
He holds Master certifications as Microsoft Certified Solutions Master Messaging and as Microsoft Certified Master for Exchange Server 2010. His experience makes him a subject matter expert for any messaging topic related to Microsoft Exchange, Exchange Online, Office 365, and Hybrid configurations.
Podcast #MVPbuzzChat with Thomas Stensitzki
Follow Thomas on LinkedIn or Twitter
His sessions: https://sessionize.com/thomas-stensitzki
MVP Blog: https://blogs.msmvps.com/thomastechtalk Personal blog: http://justcantgetenough.granikos.eu Personal website: http://www.stensitzki.de Thomas' Tech Talk: youtube.com/ThomasStensitzki
Contact Thomas at thomas@mcsmemail.de
Exchange Server besteht aus zwei Kernkomponenten. Zum einen ist es die Bereitstellung von Postfächern, mit all den benötigten Client-Zugriffsprotokollen und Postfach-Funktionen. Die zweite Komponente ist der Nachrichtenfluss, also der Empfang, die Verarbeitung und der Versand von E-Mail-Nachrichten.
Was sich so einfach und trivial anhört, ist ein zentraler und komplexer Baustein in der Exchange Architektur. In diesem Artikel versuche ich ein wenig Licht ins Dunkel des Exchange Nachrichtenflusses zu bringen. Lassen Sie uns mit einem kurzen Rückblick auf die Exchange Server Architektur beginnen.
Wer sich den Nachrichtenfluss von Exchange Server anschaut, muss sich immer den Funktionsaufbau eines Exchange Servers und die empfohlene Implementierung im Rahmen der Preferred Architecture (PA) in Erinnerung rufen. In der PA wird Exchange Server immer in einer Konfiguration aus mehreren Exchange Servern, die als Datenbankverfügbarkeitsgruppe (DAG) zusammengefasst sind, betrieben. Hierdurch wird eine hochverfügbare Bereitstellung von Postfachfunktionen und Nachrichtentransport erreicht.
Jeder Exchange Server besteht aus einer Frontend- und Backend-Komponente. Eingehende Verbindungen von Drittsystemen erfolgen immer über die Exchange Frontend-Komponenten. Die Kommunikation mit den Backend-Komponenten erfolgt im Regelfall nur Exchange-intern.
Das folgende Diagramm zeigt den schematischen Aufbau der Verbindungen in einer DAG.
Die Konfigurationen für den Nachrichtenfluss unterteilen sich in organisationsweite und serverbezogene Einstellungen. Die organisationsweiten Einstellungen gelten, wie der Name es schon sagt, für die gesamte Exchange Organisation, ganz unabhängig davon wie viele Exchange Server oder DAGs Sie betreiben. Ob und wie ein Exchange Server diese Einstellungen verarbeiten kann, hängt von der Produktversion ab. Diese Einstellungen sind vollständig in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Sendekonnektoren.
Serverbezogene Einstellungen wirken sich nur für ein bestimmtes Serversystem aus. Diese Einstellungen werden hauptsächlich ebenfalls in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Empfangskonnektoren. Einige wenige Einstellungen werden jedoch auch in der lokalen Systemregistrierung gespeichert.
Für den sicheren und stabilen Betrieb von Exchange Server ist eine funktionierende Active Directory Replikation unerlässlich. Hierzu gehört auch eine korrekte Konfiguration der Active Directory Sites. Sie ist gerade in größeren Exchange Organisationen unerlässlich.
Ebenso wichtig ist die korrekte und einheitliche Konfiguration der TLS-Einstellungen auf allen Exchange Servern. Ohne solch eine Konfiguration ist nicht sichergestellt, dass verschlüsselte Verbindungen durch die Empfangs- und Sendekonnektoren aufgebaut werden können. Exchange Server vertraut hier auf die Konfiguration des lokalen Windows Server Betriebssystems und die Bereitstellung gültiger TLS-Zertifikate.
Kommen wir nun zum eigentlichen Thema, dem Exchange Nachrichtenfluss und beginnen mit dem Empfang von E-Mail-Nachrichten.
Exchange Server nehmen eingehende E-Mail-Nachrichten über unterschiedliche Wege entgegen. Der bekannteste Weg ist der Empfang über das Protokoll SMTP. Ein Exchange Server unterscheidet hierbei drei unterschiedliche Quelltypen. Im Frontend-Transport erfolgt die Annahme von Verbindungen anderer Server über den Standard TCP-Port 25. Zu den Servern, die sich über diesen Standard SMTP-Port verbinden, zählen:
Diese Verbindungen erfolgen über den Default Frontend Konnektor, der in seiner Standardkonfiguration nur Nachrichten, die an bekannte Empfänger eigener Domänen entgegennimmt. Die Zustellung von Applikationsnachrichten an externe Empfänger erfordert die Erstellung eines separaten Frontend-Empfangskonnektor.
Zusätzlich zu den Empfangskonnektoren stehen zwei weitere Wege über das lokale Dateisystem des Exchange Servers zur Verfügung, das Pickup- und Replay-Verzeichnis. Beide Verzeichnisse werden vom Backend-Transportdienst, den Sie aus früheren Exchange Versionen sicher noch als Hub-Transport kennen, permanent überwacht und sobald eine Datei dort abgelegt ist, wird sie aufgenommen und verarbeitet. Das Pickup-Verzeichnis dient der Ablage von neuen E-Mail-Nachrichten durch Applikationen. Das Replay-Verzeichnis können Sie nutzen, um Nachrichten, die Sie aus einer Warteschlange exportiert und entfernt haben, erneut in die Verarbeitung zu übergeben.
Zum Schutz vor unberechtigten Verbindungen verwendet Exchange Server unterschiedliche Formen der Authentifizierung. Ergänzend verfügen die Eingangswege über eine Header-Firewall, mit der unberechtigte Informationen aus einer E-Mail-Nachricht herausgefiltert werden.
Der Frontend-Transport verfügt über keine komplexe Business-Logik. Daher ist es wichtig, das Zusammenspiel zwischen Frontend-Transport und Transportdiensten im Backend zu verstehen und sich immer wieder in Erinnerung zu rufen, wenn es zu Problemen kommt. Der Empfangskonnektor im Frontend-Transport nimmt die Verbindung entgegen und führt die Authentifizierung durch. Anschließend wird eine Proxyverbindung zum Transportdienst per TCP-Port 2525 aufgebaut. Hierbei entscheidet nun die Konfiguration Ihrer Exchange Umgebung darüber, wie diese Proxyverbindung erfolgt. Bei einem Einzelserverbetrieb erfolgt die Verbindung zum Transportdienst des gleichen Servers. In einer DAG-Konfiguration wählt der Frontend-Transport den Transportdienst des DAG-Mitgliedservers aus, auf dem in diesem Moment die Datenbankkopie mit dem Postfach des Empfängers aktiv eingebunden ist.
Das folgende Diagramm zeigt das Zusammenspiel zwischen Frontend und Backend beim Empfang von Nachrichten per SMTP.
Beim Empfang einer Nachricht per SMTP versucht Exchange Server die Nachricht ausfallsicher entgegenzunehmen. Zu diesem Zweck erstellt Exchange Server eine Kopie der empfangenen Nachricht und speichert sie als Schattenkopie im Transportdienst eines anderen Exchange Servers. Erst nach dem erfolgreichen Speichern der Schattenkopie und der Speicherung in der lokalen Warteschlange des Backend-Transportdienstes, meldet der empfangende Exchange Server dem sendenden Server eine OK-Meldung.
Auf einem Exchange Server können mehrere Empfangskonnektoren für den gleichen Port konfiguriert werden. Wenn Sie weitere Konnektoren für den gleichen Port erstellen, müssen Sie festlegen, wie Exchange Server einen Konnektor auswählen soll. Am einfachsten ist hier die Konfiguration der IP-Adressen des absendenden Systems als Remote IP-Adresse am Konnektor.
Im Backend des Exchange Servers befinden sich zwei Transportdienste. Der wichtigste Dienst ist der Transportdienst, den manche von Ihnen sicher noch als Hub-Transport aus älteren Versionen von Exchange Server kennen. Diesen Dienst schauen wir uns im nächsten Abschnitt einmal genauer an. Der zweite Dienst ist der Postfachtransportdienst. Dieser Dienst hat die Aufgabe, eingehende Nachrichten in Postfächern lokal eingebundener Datenbanken zu speichern und Nachrichten, die versendet werden sollen, aus Postfächern lokaler Datenbanken zu lesen und zur weiteren Verarbeitung an den Transportdienst zu übermitteln. Diesen Dienst beschreibe ich in einem zukünftigen Artikel.
Der einfach erscheinende Empfang einer E-Mail-Nachricht ist, aus Gründen der Nachrichtensicherheit und zum Schutz vor dem Ausfall eines Systems, eine komplexe Aufgabe. Nach dem Empfang der Nachricht muss sie verarbeitet werden.
Die gesamte Verarbeitung von E-Mail-Nachrichten erfolgt im Transportdienst und ist Warteschlangen-basiert, mit der Betonung auf „Warte“. Eine empfangene E-Mail-Nachricht wird in der Submission-Warteschlange gespeichert und wartet dort darauf, zur sog. Kategorisierung aufgegriffen zu werden. In der Categorizer-Komponente erfolgt die Hauptarbeit des Transportdienstes. Zu den Aufgaben gehören:
Nach der Verarbeitung im Categorizer ist die Nachricht bereit zur weiteren Zustellung und wird hierzu in einer passenden Warteschlange gespeichert. Der Transportdienst legt für jedes Zustellungsziel eine separate Warteschlange an. Dies ist der Grund, warum Sie immer eine unterschiedliche Anzahl an Warteschlangen auf einem Exchange Server sehen. Die Warteschlangen gliedern sich in unterschiedliche Kategorien:
Zur Speicherung der Warteschlangen verwendet der Transportdienst auf jedem Exchange Server eine eigene Datenbank. In dieser Datenbank werden alle Nachrichten mit ihrem jeweiligen Verarbeitungs- und Zustellungsstatus gespeichert. Der Transportdienst kümmert sich eigenständig um den Funktionsstatus der Datenbank. Kommt es zu einem nicht behebbaren Fehler, wir eine komplett neue Datenbank erstellt und die korrupte Datenbank in einen neuen Ordner verschoben.
Das folgende Schaubild zeigt die Hauptkomponenten zur Verarbeitung von E-Mail-Nachrichten im Exchange Transportdienst.
Leider steht uns für die aktuelle Version Exchange Server kein detailliertes Diagramm des Transportdienstes offiziell zur Verfügung. Im Microsoft Download Center steht das Diagramm von Exchange Server 2010 zur Verfügung und bietet einen guten konzeptionellen Überblick über den Transportdienst. Achten Sie auf die Unterschiede zu modernen Exchange Server Versionen.
Anwender leben in der Illusion, dass die Zustellung von E-Mail-Nachrichten eine einfache Sache ist und haben meist kein Verständnis für eine verzögerte Zustellung von Nachrichten. In Zeiten von Gigabit-Leitungen und schier unerschöpflicher Computer-Ressourcen hat man sich daran gewöhnt, dass Nachrichten nahezu in Echtzeit übertragen werden.
Einen wesentlichen Beitrag zu einer schnellen und fehlerfreien Verarbeitung leistet das korrekte Routing einer E-Mail-Nachricht. Damit eine Nachricht von Exchange Server fehlerfrei verarbeitet und zugestellt werden kann, ist eine fehlerfreie Active Directory Gesamtstruktur unerlässlich. Die im Exchange Transportdienst aktiven Routing-Agenten arbeiten mit den Informationen, die im Active Directory gespeichert sind. Dies sind u.a.:
Beim Routing einer Nachricht spielt auch die Nachrichtengröße eine Rolle. Exchange zieht mehrere Konfigurationen zu maximalen Nachrichtengröße in Betracht, um so zu bewerten, ob die Nachricht auch wirklich zugestellt werden kann. Kann eine Nachricht nicht zugestellt werden, erhält der Absender einen sog. Non-Delivery Report (NDR). Der Transportdienst betrachtet für die Ermittlung der erlaubten Nachrichtengröße die Konfigurationen auf Organisationsebene, die aller Sende- und Empfangskonnektoren der internen Verbindungsstrecke und die Einstellungen des Zielpostfaches.
Sendekonnektoren arbeiten die Nachrichten in den Warteschlangen ab und versuchen das jeweilige Zielsystem mit den Konnektoreinstellungen zu erreichen. Eine korrekte DNS-Namensauflösung ist der Schlüssel zu einer fehlerfreifunktionierenden Exchange Infrastruktur. Die interne Namensauflösung ist selten eine Fehlerquelle. Anderes sieht es aus, wenn es um die DNS-Auflösung externer Domänen geht. Stellen Sie sicher, dass Ihre Exchange Server auch externe Domänen effizient und sicher auflösen können, um einen fehlerfreien Nachrichtenfluss mit externen Empfängern zu gewährleisten.
Kommt es beim Versuch einer Zustellung zu einem Fehler, wird der Fehler in der Warteschlange festgehalten. Im Regelfall erkennen Sie Zustellfehler am Anwachsen einer oder mehrerer Warteschlangen. Die Überwachung der Warteschlangengröße ist unerlässlich für einen stabilen Betrieb der Exchange Organisation.
Bedenken Sie, dass die Datenbank des Transportdienstes im Installationspfad eines Exchange Servers platziert ist. Wenn Ihre Exchange Server eine hohe Anzahl von Nachrichten verarbeiten muss, sollten Sie die Datenbank auf einem separaten und ausreichend dimensionierten Laufwerk platzieren.
Der Exchange Server Nachrichtenfluss ist, wenn man unter die Motorhaube schaut, ein komplexes Gebilde. Mit einem richtig konfigurierten Active Directory sind keine Probleme beim Betrieb von Exchange Server zu erwarten. Die Herausforderungen für den Exchange Nachrichtenfluss beginnen mit der Anpassung der Exchange Konfiguration.
Gerade im Hinblick auf die Konfiguration von zusätzlichen Empfangskonnektoren müssen Sie sich immer fragen, ob Sie einen neuen Konnektor wirklich benötigen. Das Troubleshooting des Exchange Nachrichtenflusses ist nicht schwierig, jedoch zeitaufwendig. Gerade in Exchange Umgebungen, die seit einigen Jahren betrieben werden und mehrere Exchange Versionen gesehen haben, besteht ein Risiko, dass veraltete Einträge in der Konfigurationspartition den Betrieb stören. Gleiches gilt für die Exchange Empfängerobjekte. Eine regelmäßige Pflege vermeidet Störungen im Nachrichtenfluss.
Der tägliche Betrieb Ihrer Exchange Organisation wird durch ein proaktives Monitoring, in dem nicht nur der Nachrichtenfluss überwacht wird, einfacher. Neben der Überwachung der Warteschlangen, empfehle ich auch die Überwachung der Transportdienste selbst. Exchange Server verfügt mit der Funktion der Managed Availability zwar über eine integrierte Monitoring Lösung mit automatischen Recovery-Aktionen, jedoch möchten Sie sicher nicht von automatisch neustartenden Diensten überrascht werden.
Viel Spaß mit Exchange Server.
Mailscape 365 - Überwachung von Hybrid Exchange und Office 365: Viele Unternehmen verwenden eine lokale Exchange Organisation und Exchange Online in einer Hybrid-Konfiguration, um die Anforderungen ihrer Mitarbeiter zu erfüllen. Der Betrieb einer hybriden Exchange Organisation seine ganz eigenen Herausforderungen für das Monitoring der Dienstverfügbarkeiten. Beginnen Sie noch heute einen unverbindlichen 14-Tage Test von Mailscape 365.
Als IT-Berater sieht man manchmal Dinge, die es eigentlich gar nicht geben darf.
In diesem Fall geht es um das eine Exchange Server 2016 Installation auf einem Windows Server 2019 Betriebssystem. Diese Kombination ist nicht unterstützt. Die Exchange Server Unterstützungsmatrix gibt hier eine klare Antwort.
Aber der Reihe nach.
Gefunden wurde diese nicht unterstützte Kombination, als der Kunde eine Aktualisierung von Exchange Server 2016 CU12 auf CU19 durchführen wollte. Das System selbst ist als Koexistenz-Server für eine Active Directory Umgebung mit hybriden Identitäten in Nutzung. Zusätzloich wird das System für den hybriden Nachrichtenfluss zwischen einer lokalen Lotus Notes Umgebung und als SMTP-Relay für interne Applikationen und Multifunktionsgeräte verwendet.
Da Exchange Server 2016 CU12 auf diesem System bereits seit Mitte 2019 in Betrieb ist, habe ich keine Gedanken daran verschwendet, mir die lokale Betriebssystemversion genauer anzuschauen. Der Fokus lag auf der Installation der Voraussetzungen für Exchange Server 2016 CU19.
Bei der Ausführung der Installatiin von CU19 per Kommandozeile wurde das Problem sichtbar. Die Installationsroutine teile zum Abschluss der Prüfungen der Installationsvoraussetzungen mit, das das lokale Betriebssystem eine nicht unterstützte Version ist. Ein genauer Blick in die EInstellungen zeigte:
Get-WmiObject Win32_OperatingSystem | Select Caption, OSArchitecture, Version, BuildNumber | FL Caption : Microsoft Windows Server 2019 Standard OSArchitecture : 64-Bit Version : 10.0.17763 BuildNumber : 17763
Damit kam die Installation von Exchange Server 2016 CU19 auf diesem System zum Ende.
Ein Blick in das Exchange Server Setup-Protokoll zeigte deutlich, dass Exchange Server 2016 CU12 installiert wurde:
********************************************** Starting Microsoft Exchange Server 2016 Setup ********************************************** Local time zone: (UTC+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien. Operating system version: Microsoft Windows NT 6.2.9200.0. Setup version: 15.1.1713.5.
Stutzig machten jedoch die letzten Einträge in der Protkolldatei.
Ending processing Write-ExchangeSetupLog CurrentResult launcherbase.maincore:90: 1 CurrentResult console.startmain:52: 1 CurrentResult SetupLauncherHelper.loadassembly:452: 1 Setup von Exchange Server wurde nicht abgeschlossen. Weitere Details finden Sie im Protokoll 'ExchangeSetup.log' im Ordner '<SystemDrive>:\ExchangeSetupLogs'. CurrentResult main.run:235: 1 CurrentResult setupbase.maincore:396: 1 End of Setup
Die gesamte Protokolldatei enthielt keinerlei Einträge über eine erfolgreiche Installation von Exchange Server 2016. Hier hatte jemand, wie auch immer, eine unvollständig installierte Exchange Server 2016 Installation in Betrieb genommen.
Das System arbeitete in der Koexistenz mit Lotus Notes. Um den einfachen Weg bei der Relay-Konifguration zu gehen, wurde der Adressraum * als akzeptierte Domäne vom Typ ExternalRelay erstellt.
Die Lösung war in diesem Fall sehr einfach. Da das Ziel die Nutzuing eines Exchange Server 2016 mit kostenfreier Koexistenz-Lizensierung was, wurde ein neues Windows Server 2016 System provisioniert. Auf diesem System wurde dann Exchange Server 2016 CU19 installiert und im Rahmen der Hybrid-Konfiguration durch den Hybrid Configuration Wizard installiert.
Zusätzlich wurden die Einstellungen des zusätzlich benötigten Relay-Konnektors für die Koexistenz mit Lotus Notes und die internen Applikationen angepasst, um den Anforderungen für einen sicheren Betrieb von Exchange Server gerecht zu werden. Die akzeptierte Domäne * wurde entfernt.
Nach dem Umzug aller Funktionen auf das neue System und der Migration der Systempostfächer wurde das fehlerhafte System deinstalliert und aus der Exchange Organisation entfernt.
Bevor ich darauf eingehe, was die Funktionen der Managed Availability von Exchange Server sind, müssen wir uns zuerst die Architektur von Exchange Server in Erinnerung rufen.
Exchange Server ist für eine hochverfügbare und ausfallsichere Bereitstellung von Postfachdiensten und Nachrichtentransport entwickelt worden. Die Basis hierfür sind die Datenbankverfügbarkeitsgruppen (DAG), Shadow Redundancy, SafetyNet und weitere Komponenten. Ebenso spielen ein korrektes Active Directory Site Design und eine Implementierung entsprechend der Exchange Server Preferred Architecture eine wichtige Rolle.
Sie können Exchange Server in einer Einzelserver-Installation betreiben, jedoch ist dies nicht das optimale Betriebsszenario für Exchange. Es ist, als würden Sie einen Sportwagen mit angezogener Handbremse fahren.
Exchange Server ist für den Betrieb einer DAG mit mehreren Servern entworfen worden. Für die Sicherstellung der Ausfallsicherheit und der Hochverfügbarkeit kommt nun die Funktion der Managed Availability ins Spiel.
Die Funktion Managed Availability ist Bestandteil der Exchange Server Funktionen zur Hochverfügbarkeit (HA) und ist ein Exchange-internes Überwachungssystem für Exchange Funktionalitäten, das automatisch Aktionen zur Sicherstellung einer positiven Anwendererfahrung auslöst.
Hierbei wird die Erreichbarkeit der einzelnen Verbindungsendpunkte für Anwender getestet. Diese Funktionstests werden kontinuierlich ausgeführt. Um diese Tests durchführen zu können, nutzt Exchange Server spezielle Postfächer, die sog. Health Mailboxen. Diese Postfächer und die dazugehörigen Benutzerkonten sind in vollständiger Kontrolle von Exchange Server. Jede Postfachdatenbank einer modernen Exchange Server Version verfügt über individuelle Health Mailboxen für die Managed Availability. Weitere Endpunkte, die nicht von Exchange bereitgestellt, aber von jedem Exchange Server benötigt werden, sind die Domain Controller und DNS-Server. Auch diese Endpunkte werden durch die Managed Availability getestet.
Ebenso wird die Antwortzeit der einzelnen Endpunkte durch die Managed Availability gemessen. Diese Antwortzeiten (Latenz) sind ein Indikator dafür, ob ein Verbindungsendpunkt die Performance bietet, um Anwendern eine gute Erfahrung zu bieten.
Zusätzlich zur Erreichbarkeit und der Latenz der Client-Endpunkte wird auch die Funktionalität getestet. Als Beispiel sei hier die korrekte Indizierung einer E-Mail-Nachricht, nach dem Empfang im Postfach einer Health Mailbox, genannt. Hierdurch stellt die Managed Availability fest, ob die Suche im Postfach fehlerfrei funktioniert.
Ist nun ein Endpunkt nicht erreichbar, sind die Antwortzeiten eines Endpunktes zu lang oder treten bei einem Funktionstest Fehler auf, löst die Managed Availability automatisch Aktionen aus, um eigenständig wieder einen optimalen Betriebszustand zu erreichen.
Die Kernkomponenten der Managed Availability sind der Exchange Health Manager Service und der Exchange Health Manager Worker Prozess. Der Health Manager Service hat die Aufgabe, den Health Manager Worker Prozess zu steuern und zu kontrollieren. So wird sichergestellt, dass ein Fehler bei der Ausführung des Worker Prozesses nicht zu einer grundsätzlichen Störung der Managed Availability führt.
Die Managed Availability verwendet Proben, um Informationen über einzelne Komponenten zu sammeln und Messungen durchzuführen. Ein Exchange Server verfügt über hunderte von Proben, die in einzeln definierten Intervallen ausgeführt werden. Den Status der Proben, und damit auch des Servers, können Sie im Rahmen der Health-Cmdlets abfragen.
Die gesammelten Informationen und Messungen werden von der Monitoring-Komponente ausgewertet. In dieser Komponente ist die Business-Logik implementiert, um Informationen und Messungen auszuwerten. Sollte das Monitoring ein Problem feststellen, entscheidet die Responder-Definition darüber, ob eine Administrator-Eskalation oder eine direkte Responder-Aktion ausgelöst wird.
Das folgende Schaubild verdeutlicht den Aufbau der Managed Availability Komponente mit Probe Engine, Monitor und Responder.
Unter einer Administrator-Eskalation dürfen Sie sich nun keine direkte Benachrichtigung der Exchange Administratoren vorstellen. Es wird ein entsprechender Eintrag in der Ereignisprotokollierung vorgenommen, den Sie mit einem System-Monitoring Tool überwachen müssen.
Wesentlich interessanter sind die automatischen Aktionen, die ein Responder ausführt. Kommt es z.B. bei der Prüfung von Outlook on the Web zu einem fehlerhaften Verhalten, durchlaufen die Responder-Aktionen mehrere Stufen, um wieder eine einwandfreie Exchange Funktion herzustellen. Als erste Reaktion wird der OWA-Applikationspool des betroffenen Exchange Servers neu gestartet. Hilft dieser Neustart des Applikationspools nicht, so führt die Managed Availability einen Neustart des W3SVC-Dienstes durch. Verbessert sich das Fehlerbild von Outlook on the Web nicht, führt die Managed Availability einen Neustart des Servers durch. Dieser Neustart des Servers wird allerdings nicht als regulärer Neustart durchgeführt, sondern per Bug-Check als harter Neustart.
Wenn Sie sich auf einem Exchange Server per Remote Desktop anmelden und einen Dialog erhalten, dass der letzte Shutdown unerwartet durchgeführt wurde, sollten Sie auf jeden Fall die Einträge der Managed Availability in den Crimson Channel Ereignisprotokollen prüfen.
Exchange Server unterstützt für einige der Proben die Möglichkeit einer Anpassung der Konfiguration. Diese Anpassung erfolgt als lokale oder globale Managed Availability Overrides. Lokale Overrides gelten für einen Server, während globale Overrides sich auf mehrere Server auswirken.
Der entscheidende Vorteil der Managed Availability ist, dass Exchange Server sich selbst überwacht und so selbständig für eine hochverfügbare Bereitstellung der Exchange Funktionalitäten sorgt. Dies kann die Managed Availability aber nur, wenn Sie eine Exchange DAG Umgebung betreiben und den Implementierungsempfehlungen der Exchange Produktgruppe folgen. Moderne Exchange Server Versionen wurden dazu entwickelt, eigenständig die Hochverfügbarkeit der Applikation sicherzustellen. Exchange Server kennt andere HA-Komponenten Ihrer IT-Infrastruktur nicht und verlässt sich auch nicht auf diese. Moderne Exchange Server Version ab Version 2013 können mit Standard-Hardware und Standard-Speichermedien betrieben werden. Die Managed Availability sorgt im Zusammenspiel mit den HA-Funktionen einer Datenbankverfügbarkeitsgruppe für eine hochverfügbare Bereitstellung von Exchange Funktionen.
Fehler treten nie während der regulären Arbeitszeiten von Exchange Administratoren auf. Probleme und Fehler haben naturgemäß die Eigenart, nachts und an Wochenenden einzutreten. Wenn Sie einen ruhigen Schlaf bevorzugen, ist die Managed Availability genau das Mittel der Wahl.
Das Blog Cumulative Update für Januar 2021 (CU0121) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Microsoft Teams und Azure des Monats Januar 2021 zusammen.
Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.
Sie denken über einen vollständigen Wechsel zu Microsoft 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.
Sie möchten mehr über Exchange Server 2019 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop. Bis dahin, werfen Sie doch einen Blick in das Microsoft Exchange Server 2019: Das Handbuch für Administratoren.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu
Exchange Server vNEXT ist nichts anderes als der Platzhaltername für die nächste Version von Exchange Server, die als Nachfolgeversion von Exchange Server 2019 veröffentlicht werden wird, da der finale Produktname noch nicht feststeht.
Nach der Veröffentlichung von Exchange Server 2019 gab es immer wieder Spekulationen, ob dies nun die letzte Exchange Server Version ist und damit das Ende von lokalen Exchange Server Editionen eingeläutet wurde. Während der Microsoft Ignite 2020 Konferenz hat Greg Taylor die Vision für Exchange Server vNEXT vorgestellt und damit den Spekulationen ein Ende gesetzt.
Die Veröffentlichung von Exchange Server vNEXT ist für das zweite Halbjahr 2021 angekündigt und wird nun die letzte On-Premises Version von Exchange Server sein. Welche technologischen Neuerungen Exchange Server vNEXT für Anwender bieten wird, ist zum jetzigen Zeitpunkt noch unklar.
Die wichtigste Änderung, die uns mit Exchange Server vNEXT treffen wird, ist die Änderung des Lizensierungsmodells. Mit der nächsten Version von Exchange Server erfolgt ein Wechseln zu einer Abonnement-basierten Lizensierung. Wie die Lizensierungsbedingungen im Detail aussehen werden und wie sich die neue Lizensierung preislich darstellen wird, ist aktuell noch nicht bekannt. Mit dem Wechsel zu einem Abonnement-Modell werden Kunden auf jeden Fall thematisch an die Abonnement-Modelle der Microsoft-Cloud-Dienste herangeführt.
Zum ersten Mal in der Geschichte von Exchange Server, ermöglicht Exchange Server vNEXT eine direkte Aktualisierung einer Exchange Server Installation. Diese In-Place-Aktualisierung ist jedoch nur für Exchange Server 2019 vorgesehen. Wenn Sie planen, auch in Zukunft weiterhin Exchange Server in einer lokalen IT-Infrastruktur einzusetzen, ist nun die Zeit gekommen, auf Exchange Server 2019 zu wechseln. Nur so profitieren Sie von einer einfachen Aktualisierung auf Exchange Server vNEXT. Die Möglichkeit zur In-Place Aktualisierung ist jedoch zeitlich beschränkt. Ab dem Zeitpunkt der Veröffentlichung von Exchange Server vNEXT beginnt das zweijährige Zeitfenster, in dem ein In-Place Upgrade eines Exchange Server 2019 Systems, mit aktuellem kumulativem Update, möglich sein wird.
Mit der Änderung des Lizensierungsmodells ändert sich auch die Bereitstellung von Produktaktualisierungen und dem Zugang zum Produktsupport für Exchange Server vNEXT. Sie erhalten zukünftige Softwareaktualisierungen und Support nur, wenn Sie über ein aktives Abonnement für Exchange Server vNEXT verfügen.
Exchange Server vNEXT erlaubt einen Koexistenzbetrieb mit allen modernen Exchange Server Versionen ab Version 2013. Dies ist eine Abweichung von früheren N-2 Voraussetzungen, als nur die jeweils aktuelle Produktversion und die jeweils beiden Vorversionen in einer Koexistenz betrieben werden konnten.
Da sich Exchange Server 2013 und 2016 bereits in der erweiterten Supportphase befinden, ist es Zeit, sich Gedanken über eine Migrationsstrategie zu machen. Je nach Ausgangssituation und geplantem Betriebsszenario einer lokalen Exchange Organisation, ergeben sich unterschiedliche Optionen.
Exchange Server 2016 befindet sich zwar seit dem 13. Oktober 2020 in der erweiterten Supportphase, jedoch ist diese die passende Produktversion, um einen reinen Verwaltungsserver für eine Hybrid-Konfiguration zu betreiben. Im Rahmen Ihres Microsoft 365 Abonnements können Sie eine kostenlose Lizenz zum Betrieb des Koexistenz-Servers erhalten. Für Exchange Server 2019 steht diese Option nicht zur Verfügung, da diese Produktversion immer eine kostenpflichtige Lizenz erfordert.
Die Daten für die Supportzeiträume von Exchange Server 2019 haben eine wichtige Änderung erfahren. Für Exchange Server 2019 war nie eine fünfjährige Phase für den erweiterten Support geplant. Exchange Server 2016 und 2019 hatten schon immer den 14. Oktober 2025 als finales Supportende. Das Ende des Mainstream-Supports für Exchange Server 2019 wurde vom 1. September 2024 auf den 9. Januar 2024 vorgezogen.
Das folgende Diagramm verdeutlicht noch einmal die Supportzeiträume moderner Exchange Server Versionen und das Zeitfenster für ein mögliches In-Place-Upgrade auf Exchange Server vNEXT.
Die Ankündigung von Exchange Server vNEXT gibt Exchange Administratoren Zuversicht und Planungssicherheit für den Betrieb einer lokalen Exchange Server Organisation. Jedoch ändern sich durch neue Lizensierungsmodelle die Voraussetzungen für den Betrieb. Wenn Sie die Anforderung nach einer hochverfügbaren Bereitstellung von Exchange Server Funktionen haben, gibt es zwei Möglichkeiten:
Für welchen Weg Sie sich auch entscheiden, Exchange Server blickt auf mehr als 25 Jahre Erfahrung in der Bereitstellung einer soliden Messaging-Plattform zurück.