shop high quality replique rolex.

discover the luxury rolex imitacion online watch store.

replica watches are the best qulity online.

swiss replica watches owns a high factor within throughout the world watch business sector.

richard mille fakes are the perfect mix between italian design and swiss technology at the service of the passion for the sea.

de-DEen-GB
rss

Granikos Technology Blog

You find the English version of this post at ENow's ESE Blog: Exchange Monitoring: What is Exchange Mail Flow

 

Logo Exchange Server 2019 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.

 

Die Exchange Server Architektur

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.

Diagramm Exchange Server Nachrichtfluss

 

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.

 

Der Empfang von 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:

  • Externe E-Mail-Server fremder E-Mail-Domänen, die E-Mail-Nachrichten über das Internet an Ihren Exchange Server senden
  • Interne Applikationsserver, die E-Mail-Nachrichten an interne und externe Empfänger senden und einen Exchange Server als sog. Relay-Server verwenden
  • Andere interne Exchange Server anderer Produktversionen oder Exchange Server, die in anderen Active Directory Sites platziert sind

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.

Diagramm Exchange Nachrichtenfluss - Detailstufe 2

 

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 Verarbeitung von Nachrichten

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:

  • Auflösung der Empfängeradressen
  • Entscheidung über das Routing der Nachricht, auf Basis der in diesem Moment geltenden Topologie-Informationen
  • Konvertierung des Nachrichteninhaltes
  • Aufteilung der Nachricht in weitere Nachrichten
    • Aufteilung der Nachricht an mehrere Empfänger
    • Auflösung der Empfänger einer adressierten Verteilerliste
  • Paketierung der Nachricht oder Nachrichten zur Zustellung
  • Erstellung von Delivery Status Notifications (DSN)

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:

  • Lokale Zustellung an eine aktive Postfachdatenbankkopie, die das Postfach des Empfängers beinhaltet
  • Remote Zustellung an eine aktive Postfachdatenbankkopie in der gleichen DAG, die das Postfach des Empfängers beinhaltet
  • Remote Zustellung an einen beliebigen Mitgliedsserver einer anderen DAG zur weiteren Zustellung an Postfächer in dieser DAG
  • Zustellung an einen konfigurierten Exchange Server eines Sendekonnektors eines Zieladressraumes
  • Zustellung an Remote-Domänen über einen definierten Smarthost
  • Zustellung an Remote-Domänen mit DNS-basierter MX-Auflösung für die Ziel-Domäne

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.

Diagramm 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.

 

Das Routing von Nachrichten

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.:

  • Adressen von Exchange Empfängerobjekten
    • Inkonsistente, fehlerhafte Einträge und identische Einträge an mehreren Objekten sind eine häufige Fehlerquelle
    • Verwaiste Objekte von E-Mail-aktivierten Öffentlichen Ordner gehören ebenso zu den Fehlerquellen
  • Konfiguration der Exchange Organisation
    • Verwaiste Server- und Konnektoreinstellungen durch nicht korrekt durchgeführte Deinstallationen können zu Fehlern und Verzögerungen beim Routing führen
  • Active Directory Site-Konfiguration
    • Eine fehlerhafte Konfiguration der AD-Sites kann zu Fehlern bei der Zustellung und bei der Nutzung von Schattenkopien führen

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.

 

Der Versand von Nachrichten

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.

 

Zusammenfassung

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.

 

Links

 

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.

Weiterlesen »

Logo Exchange Server 2019Als 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.

 

Das aktuelle System

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

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.

 

Viel Spaß mit Exchange Server.

 

 

 

Weiterlesen »
You can read the English version of this post at ENow's ESE blog: What is Managed Availability and how do you take advantage of it?

 

Logo Exchange Server 2019Bevor 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.

 

Was ist Managed Availability

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.

 

Wie funktioniert Managed Availability?

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.

Diagramm Übersicht Managed Availability

 

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.

 

Welchen Vorteil bietet die Managed Availability?

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.

 

Links

 

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.

Weiterlesen »

Photo by Max DeRoin from PexelsDas Blog Cumulative Update für Januar 2021 (CU0121) fasst interessante Themen rund um Cloud SicherheitExchange ServerOffice 365, Microsoft Teams und Azure des Monats Januar 2021 zusammen.

Allgemein

 

Logo Exchange Server 2019Exchange Server

 

Logo Office 365Microsoft 365 | OneDrive | Exchange Online | and more

 

Logo Microsoft TeamsMicrosoft Teams

 

Logo Microsoft AzureMicrosoft Azure

 

Cloud | Cloud Sicherheit

 

Logo Microsoft LearnMicrosoft Training

 

Schule | Lernen

 

Microsoft Docs | Tech Community | Knowledge Base

 

Logo Skype for BusinessSkype for Business Server | Communications

 

Replay

 

Podcast Empfehlungen

 

Tools

 

 


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

 

Weiterlesen »

Logo Exchange Server 2019Exchange 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.

Änderung des Lizensierungsmodells

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.

In-Place Update

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.

Produktaktualisierungen und technischer Support

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.

 

Migrationswege

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.

Diagramm Exchange Server vNEXT

 

Zusammenfassung

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:

  1. Migrieren Sie Ihre lokale Exchange Organisation schnellstmöglich auf Exchange Server 2019, um auf Exchange Server vNEXT vorbereitet zu sein und folgen Sie der Preferred Architecture beim Design der Umgebung.
  2. Migrieren Sie Ihre lokale Exchange Organisation zu Exchange Online und nutzen Sie die erweiterten Funktionen, die Ihnen im Zusammenspiel mit den weiteren Microsoft 365 Diensten zur Verfügung stehen.

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.

 

Links

 

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.

Weiterlesen »
0123movie.net