Exchange Server 2019 ist die aktuelle Version der E-Mail-Messaging Plattform für die Installation in der lokalten IT-Infrastruktur (aka On-Premises). Als lokale Infrastruktur gilt auch die Nutzung von Exchange Server 2019 auf virtualisiserten Serversystemen in Microsoft Azure. Bei Microsoft handelt sich, technisch gesehen, nur um ein ausgelagertes Rechenzentrum. Als wirkliche Alternative zu einem eigenen Betrieb von Exchange Server 2019 steht Ihnen Exchange Online, als Bestandteil des Software-as-a-Service Angebotes von Office 365, zur Verfügung.

Der Betrieb von Exchange Server 2019, die hybride Verbindung zwischen einer lokalen Exchange Organisation und Exchange Online oder die alleinige Nutzung von Exchange Online erfordern eine detaillierte Planung und Vorbereitung. 

Auf dieser Seite finden Sie die wichtigsten Referenz-Links zu Online Ressourcen von Microsoft und anderen Quellen, um das für Sie richtige Exchange Produkt zu installieren, einzurichten und zu betreiben.

Planung einer Exchange Organisation

Wie einleitend schon ausgeführt, kann Exchange grundsätzlich in vier unterschiedlichen Architekturmodellen betrieben werden, die ihre ganz individuellen Vor- und Nachteile bieten. Diese sind:

• Exchange Online (SaaS)
  Hierbei wird Exchange als integraler Bestandteile des SaaS-Angebotes von Office 365 verwendet. Sie nutzen  hierbei immer die aktuellste Version von Exchange Server.
   
• Exchange Hybrid
  Hierbei werden eine lokale Exchange Organisation und Exchange Online parallel betrieben und sind bidirektional miteinander verbunden. Beide Umgebungen können mit der jeweils anderen Umgebung kommunizieren und auf Inhalte.
   
• Exchange Server in Azure (IaaS)
  Hier agiert Azure als Erweiterung Ihrer internen IT-Infrastruktur. Sie betreiben in Azure virtuelle Serversysteme und betreiben dort Exchange Server Systeme. Diese Systeme können auch in einer Hybrid-Anbindung mit Exchange Online betrieben werden. 
   
• Exchange On-Premises
  Dies entspricht einer klassischen Exchange Organisation mit Exchange Server Systemen, die Sie auf Ihren eigenen Serversystemen, virtualisiert oder physikalisch, betreiben.

IT-Responsibility	Exchange Online	Exchange Hybrid	Azure IaaS	On-Premises
Data Governance und Rechtemanagement
Client Endpunkte
Benutzerkonten- und Zugriffsverwaltung
Identitäten und Active Directory Infrastruktur
Netzwerk
Applikationen
Betriebssystem
Physikalische Host-Systeme
Physikalisches Netzwerk
Physikalische Rechenzentren

 = kontrolliert durch Microsoft
 = kontrolliert durch Kunden

• Exchange Server-Unterstützbarkeitsmatrix
• Exchange Server build numbers and release dates
• Exchange-Processor Query Tool: PowerShell Edition
• Exchange Server 2016 Role Requirements Calculator
• Processor Query Tool v1.1
• Outlook license requirements for Exchange features
• Modern public folder deployment best practices

Installation

• Exchange Server 2019 Installationsvoraussetzungen
  Unterstützt sind immer jeweils das aktuelle CU und die beiden vorherigen CUs)
  • Übersicht der Voraussetzungen
  • Visual C++ Redistributable Packages for Visual Studio 2013
  • Microsoft .NET Framework 4.7.2 (Offline-Installer) (RTM, CU1, CU2, CU3)
  • Microsoft .NET Framework 4.8 (Offline-Installer) (CU2 +)
  • Microsoft Unified Communications Managed API 
    • Bestandteil des Exchange Server 2019 Installationsmediums

• Exchange Server 2016 Installationsvoraussetzungen
  Unterstützt sind immer jeweils das aktuelle CU und die beiden vorherigen CUs)
   
  • Übersicht der Voraussetzungen
  • Visual C++ Redistributable for Visual Studio 2012
  • Visual C++ Redistributable Packages for Visual Studio 2013
  • Microsoft .NET Framework 4.5.2 (Offline-Installer)
  • Microsoft .NET Framework 4.6.1 (Offline Installer) (CU2 - CU7)
    • Hotfix-Rollup 3146715 für.NET Framework 4.6 und 4.6.1 in Windows (Windows Server 2012R2)
  • How to temporarily block installation of the .NET Framework 4.7 
  • Microsoft .NET Framework 4.7.1 (Offline Installer) (CU8, CU9, CI10, CU11, CU12)
  • Microsoft .NET Framework 4.7.2 (Offline-Installer) (CU11, CU12, CU13, CU14)
  • Microsoft .NET Framework 4.8 (Offline-Installer) (CU13 +)
  • Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
    • Exchange Server 2019 ISO beinhaltet einen angepassten UCMA-Installer
       

Betrieb

Der Betrieb und die vollständige Verwaltung von Exchange Server erfordern die Verwendung der Exchange Management Shell (EMS). Mit Hilfe des browserbasierten Exchange Admin Center (EAC) können Sie Gelegenheitsaufgaben durchführen. Dies gilt für Exchange Server 2019 ebenso wie für Exchange Online.

• Exchange PowerShell auf Microsoft Docs
• Exchange Online PowerShell Modul mit MFA (Click-to-Run Installation, erfordert für den ausführenden Rechner eine direkte Verbindung ins Internet)
• Sammlung an PowerShell-Skripten für Exchange Server und Exchange Online
• Exchange Server 2019 - Das Handbuch für Administratoren
   
• Exchange Berechtigungen
• Exchange Empfängerobjekte
• Clients und mobile Geräte
• Nachrichtenfluss und Transport-Pipeline
• E-Mail-Adressen und Adressbücher
• Hohe Verfügbarkeit und Ausfallsicherheit

Exchange Online

• Exchange Online Protection IP Addresses

Hybrid Betrieb

• Exchange Hybrid Deployments
• Hybrid Deployment Procedures

Administration

• Add-Ins
  • Specify the administrators and users who can install and manage add-ins for Outlook
  • Add-ins for Outlook in Exchange Online
  • Manage deployment of Office 365 add-ins in the Microsoft 365 admin center

Präsentationen

Migrationswege zu Exchange Server 2019

Exchange Server 2019 MetaCache Datenbank und BIgFunnel

Viel Spaß mit Exchange Server 2019 und Exchange Online.

Sie benötigen Hilfe bei der Planung und Installation Ihrer Exchange Server Installation? Sie haben Fragen über Ihre bestehende Exchange Server Infrastruktur und möchten Exchange Online implementieren? Kontaktieren Sie uns per E-Mail info@granikos.eu oder besuchen Sie unsere Webseite http://www.granikos.eu

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.

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.

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.

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

• Microsoft Exchange Server 2010 Transport Server Role Architecture Diagrams
• Message size and recipient limits in Exchange Server
• DNS and Report Types
• Exchange 2016 + 2019 Mail Flow with Ports

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.

Warum gibt es die Preferred Architecture?

Exchange Server ist ein sehr tolerantes Produkt und lässt sich in unterschiedlichste IT-Infrastruktur-Varianten installieren. Einige der möglichen Infrastruktur-Varianten sind gut geeignet für den Betrieb von Exchange Server, andere leider weniger gut. Daher ist es immens wichtig, bei der Planung einer Exchange Server Umgebung die notwendige Sorgfalt walten zu lassen.

Basis für die Planung einer Exchange Server Implementierung ist der Hauptgrundsatz für moderne Exchange Server Versionen:

Dieser Hauptgrundsatz wird, wie die Erfahunrg zeigt, leider allzu häufig ignoriert. Dieser Ignoranz wird in vielen Fällen dadurch Vorschub geleistet, dass Hard- und Software-Hersteller ihre ganz eigenen Hochverfügbarkeitslösung (HA) verkaufen möchten. Zu diesen Lösungen gehören sowohl HA-Funktionen von Hypervisor-Plattformen, aber auch, und dies viel häufiger, HA-Lösungsansätze von Storageanbietern.

Die Standardisierung einer Plattform wird nicht dadurch erreicht, indem eine unnötig komplexe Infrastruktur zum Standard erklärt wird, sondern das eine möglichst einfache Implementierung der Exchange Server Plattform zum Standard gemacht wird.

Unzählige Supportanfragen bei der Exchange Produktgruppe (PG) haben die Preferred Architecture Empfehlung über die Jahre reifen lassen. Sie ist daher keine spontan entstandene Empfehlung. Sie ist entstanden aus den Anforderungen und Kenntnisgewinnen im täglichen Betrieb der hochverfügbaren Cloudinfrastruktur von Exchange Online.

Sicherlich werden Sie nun einwenden, dass Sie keine Cloud-Plattform betreiben möchten. Sie dürfen nicht vergessen, dass eine moderne Exchange Server Version hochverfügbar betrieben werden möchte. Vergessen Sie daher nicht den Hauptgrundsatz für moderne Exchange Server Versionen ab Version 2013.

Auf der Microsoft Ignite Konferenz 2017 wurde in zahlreichen Vorträgen auf die Preferred Architecture Bezug genommen. Man konnte dem Eindruck erliegen, dass hier missioniert werden sollte. Am letzten Tag der Konferenz haben Boris Lokhvitsky und Robert Gillies eine sehr interessante Session zur richtigen Implementierung von Exchange Server gehalten. Hierbei wurde auch betrachtet, welche technischen Mindestanforderungen für eine Exchange Server Implementierung gelten und wie eine optimale Betriebsumgebung aussieht. Ein optimaler Betrieb einer On-Premises Implementierung folgt der Preferred Architecture. Ist dies nicht möglich sollte man sich für einen Wechsel zu Exchange Online entscheiden.

Das nachfolgende Diagramm verdeutlicht die unterschiedlichen Design-Optionen für eine Messaging-Plattform auf Basis von Exchange Server 2016.

Was bedeutet das nun im Detail für eine erfolgreiche Exchange Server Implementierung?

• Standardisiert
  Exchange Online bietet eine standardisierte Nutzung von Exchange Server Funktionen im Rahmen des Software-as-a-Service Angebotes von Office 365. Hierbei nutzen Sie nur die Funktionen von Exchange und haben keinerlei direkten Zugriff auf die Server Systeme. Die gesamte Verwaltung des Betriebssystems und das Patchen von Exchange Server führt Microsoft für Sie durch. Sie können sich so ganz auf die Konfiguration Ihrer Exchange Online Organisation oder aber den Hybrid-Verbund mit Ihrer lokalen Exchange Organisation konzentrieren.
   
• Strukturiert
  Die strukturierte Implementierung einer Exchange Server Plattform folgt der Preferred Architecture der Exchange Produktgruppe oder der Product Line Architecture, basierend auf den Empfehlungen und Erkenntnissen von Microsoft Architekten. Eine solche Implementierung ist, ebenso wie die Nutzung von Exchange Online, als Lösung für einen optimalen Betrieb anzusehen. Wie sich die Preferred Architecture im Detail darstellt wird weiter unten beschrieben.
   
• Empfohlen
  Eine On-Premises Exchange Server Implementierung, die den Best Practices folgt, weicht in signifikanten Punkten von der Preferred Architecture ab und bietet trotzdem einen sicheren und stabilen Betrieb. Eine solche Abweichung ist z.B. der Betrieb auf einem Hypervisor, jedoch unter Anwendung der Betriebsparameter für den Betrieb von Exchange Server auf physikalischen Systemen (Stichwort: feste Ressourcenzuweisung). Der Exchange Server Best Practices Analyzer ist eine Click-To-Run Applikation, die direkt aus dem Exchange Admin Center einer On-Premises Implementierung heraus aufgerufen werden kann. Alternativ kann hierzu auch das Exchange Analyzer Script von Paul Cunningham aus der TechNet Gallery verwendet werden.
   
• Unterstützt
  Eine unterstützte Implementierung von Exchange Server weicht in zahlreichen Punkten von der Preferred Architecture ab, bewegt sich aber immer noch im durch Microsoft unterstützten Betrieb. Solch ein unterstützter Betrieb folgt den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen. Diese Art der Implementierung ist als absolutes Mindestmaß anzusehen.
   
• Funktioniert (irgendwie)
  Natürlich kann man Exchange Server auch irgendwie zum Laufen bringen. Dies ist die letzte Kategorie. In diese Kategorie fallen Einzelserver Implementierungen unter Verwendung von redundanten Speichersystemen oder der grundsätzlich Betrieb von Exchange Server mit nicht unterstützten Speichersystemen (siehe Exchange Server Speicherkonfigurationsoptionen). In diesem Bereich fallen aber auch Exchange Server Implementierung auf AWS oder Microsoft Azure ohne Premium Storage. Ihre produktive Exchange Server Plattform sollte nicht zu dieser letzten Kategorie gehören, da Sie ansonsten ein unnötig hohes Betriebsrisiko eingehen.

Was ist die Preferred Architecture?

Was ist nun die viel zitierte Preferred Architecture und was bedeutet sie für eine erfolgreiche On-Premises Implementierung und den sicheren Betrieb von Exchange Server.

Die Preferred Architecture ist kein starres Gebilde. Vielmehr passt sie sich regelmäßig den technischen Gegebenheiten an. Zuletzt wurde z.B. die Empfehlung für den maximalen Arbeitsspeicher je Server von 96GB auf 192GB angehoben.

Nachfolgend werden die vier Bereiche der Preferred Architecture beschrieben. Ich empfehle aber dringend, immer auf den aktualisierten EHLO Blog Artikel Bezug zu nehmen und sich noch einmal mit der Exchange Server 2016 Architektur vertraut zu machen.

Die Preferred Architecture gliedert sich in die folgenden vier Bereiche:

• Namensraum-Design
• Rechenzentrumsdesign
• Server-Design
• DAG-Design

Namensraum-Design

Der Exchange Namensraum (Namespace) beschreibt die DNS Hostnamen, die erforderlich sind, damit sich Clients (z.B. Outlook, Browser oder mobile Endgeräte) mit den Exchange Servern verbinden können. Im Rahmen des Data Center Designs (s.u.) wird davon ausgegangen, dass diese Verbindungen auf zwei Standorte verteilt werden. 

Bei der Planung der Exchange Server Namensräume (Namespaces) unterscheidet man zwischen gebundenen (bound) und ungebundenen (unbound) Namensräumen für Exchange Server in zwei Rechenzentren.

Bei einem gebundenen Namensraum besitzt jedes Rechenzentrum einen eindeutigen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen erfolgen somit immer zu dem Rechenzentrum, in dem sich auch die aktive Datenbankkopie des angefragten Benutzerpostfaches befindet.

Bei einem ungebunden Namensraum verfügen die Rechenzentren über keine eigenen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen werden bei jeder Anfrage durch den Load Balancer in eines der beiden Rechenzentren geleitet. Eine Ausnahme bilden hier die Office Online Server (OOS), die immer einen gebundenen Namensraum erfordern.

Das nachfolgende Beispiel für eine Preferred Architecture Namespace Design benötigt vier Namen:

1. AutoDiscover Endpunkt: autodiscover.varunagroup.de
2. Client Endpunkt für alle Exchange Dienste: mail.varunagroup.de
3. Office Online Server Endpunkt Rechenzentrum A: oos-a.varunagroup.de
4. Office Online Server Endpunkt Rechenzentrum B: oos-b.varunagroup.de

Rechenzentrumsdesign

Eine hochverfügbare und ausfallsichere Architektur erfordert den Betrieb von mindestens zwei Rechenzentren. Ob es sich nun um vollwertige und eigenständige Rechenzentren oder um lokale Serverräume in getrennten Brandabschnitte im gleichen Gebäude handelt, lasse ich hier bewusst offen. Die Anforderungen zur Verfügbarkeit von IT-Basisdiensten hängen schließlich nicht nur von einer Exchange Server Implementierung ab.

Eine wichtige Anforderung ergibt sich aber für den Betrieb des Active Directory in der Preferred Architecture.

Der über zwei Rechenzentren gestreckte Betrieb einer einzelnen Active Directory Site wird zwar technisch unterstützt, für die Preferred Architecture ist es aber empfohlen, dass jedes Rechenzentrum in einer eigenen Active Directory Site abgebildet wird. Die Gründe dafür sind:

• Die Funktionen für einen ausfallsicheren Betrieb des E-Mail Transports mit Shadow Redundancy und Saftety Net
• Der Active Directory Design Empfehlung folgend müssen Netzwerkesegmente mit einer Gesamtlaufzeit von mehr als 10ms in separaten Active Directory Site platziert werden

Server-Design

In der Preferred Architecture werden alle Exchange Server mit Postfachrolle als physikalische Systeme betrieben. Die Hauptgründe hierfür sind:

• Jeder Server ist für eine 80% Auslastung bei größtmöglichem Ausfallszenario berechnet
• Virtualisierung stellt eine zusätzliche Komplexität im Falle einer Wiederherstellung dar, die keinerlei Vorteil bringt (siehe auch Hauptgrundsatz von Exchange Server)

Die physikalischen Server, die für eine Preferred Architecture Implementierung verwendet werden, haben keine allzu besonderen Anforderungen. Solch ein Standard-Server besteht aus:

• 2HE Server, Dual-Sockel mit 20-24 Prozessorkernen
• Maximal 192GB Arbeitsspeicher
• Festplattencontroller mit Batterie-abgesichertem Schreib-Cache
• 12 oder mehr Festplatteneinschübe im Servergehäuse

Die weiteren Konfigurationen des Servers sind:

• Einzelner RAID1 Verbund aus zwei Festplatten für das Betriebssystem, Exchange Server Installation, Protokolldateien und Transportdatenbanken
• Alle weiteren SAS Festplatten sind als JBOD konfiguriert
• Dateisystem für Datenlaufwerke ist ReFS
• Schutz der Daten durch BitLocker Festplattenverschlüsselung
• Absicherung gegen Festplattenausfall durch DAG AutoReseed

DAG-Design

Um eine optimale Nutzung der Systemressourcen im ungebundenen Namensraummodell zu gewährleisten, werden die aktiven Kopien der Datenbanken gleichmäßig (symmetrisch) über alle Mitgliedsserver der Database Availability Group (DAG) verteilt. Die maximal 16 Mitgliedsserver einer DAG werden ebenfalls symmetrisch, mit einer geraden Anzahl an Servern je Rechenzentrum über alle Rechenzentren verteilt.

Durch mehr Mitgliedsservern in einer DAG wird eine bessere Redundanz und Nutzung der Ressourcen sichergestellt. Die Preferred Architecture sieht vor, dass eine DAG aus mindestens acht Mitgliedsservern besteht. Bei einem steigenden Ressourcenbedarf wird die DAG um weitere Mitgliedsserver erweitert. 

DAG Netzwerkdesign

In der Preferred Architecture benötigt Exchange Server für einen sicheren Betrieb nur eine einzelne Netzwerkschnittstelle. Diese Netzwerkschnittstelle wird ohne Teaming betrieben. Diese vereinfachte Netzwerkanforderung erleichtert den Betrieb und auch die Wiederherstellung im absoluten Fehlerfall. Eine separate Heartbeat-Netzwerkschnittstelle für die Cluster-Kommunikation ist nicht erforderlich.

Witness Server

Der Witness Server einer DAG gewährleistet das korrekte Verhalten der DAG bei einem automatischen Failover, sollte es zu einem Ausfall eines Rechenzentrums kommen. Im Idealfall wird der Witness Server an einem dritten Standort in einer anderen Active Directory Site platziert. Sollte kein dritter Standort zur Verfügung stehen, so kann der Witness Server auch in Microsoft Azure betrieben werden.

Zusammenfassung

Was ist nun die richtige Exchange Server Architektur?

Wenn Sie der Preferred Architecture (Blauer Kreis) oder aber der Best Practice Empfehlung (Lila Kreis) folgen, können Sie einen sicheren Betrieb der E-Mail Plattform in Ihrem Unternehmen gewährleisten, ohne unnötige technische Risiken einzugehen. Jenseits einer Nutzung von Exchange Online stellen diesen beiden Design-Optionen das Optimum für einen zuverlässigen Betrieb dar. Je weiter Sie sich von der Preferred Architecture für Exchange Server entfernen, um so mehr steigt das Betriebsrisiko.

Wenn Sie den vollmundigen Produktversprechen von Drittherstellern für Speicherlösungen oder anderen faszinierenden Lösungen zur Hochverfügbarkeit von Exchange Server folgen, so verabschieden SIe sich in eine individuelle "funktioniert irgendwie" Implementierung. Tritt bei solch einer Implementierung ein Fehlerfall auf, so liegt das Problem nicht beim Produkt Exchange Server. Die Erfahrung hat leider gezeigt, dass in solchen Fällen immer von Unzulänglichkeiten in der Implementierung abgelenkt wird.

Als absolute Mindestempfehlung gilt eine Exchange Server Implementierung, die den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen folgt.

Abkürzungen

• PA | Preferred Architecture
• PLA | Product Line Architecture

Links

• The Exchange 2016 Preferred Architecture
• Introducing the Microsoft Product Line Architecture
• Exchange Server 2016 Architecture
• BRK3158 - Do Exchange Right Or Move to Office 365

Viel Spaß beim Betrieb von Exchange Server.

Was bedeutet Exchange Server Hybrid?

Eine lokale Exchange Organisation eines Unternehmens kann mit Exchange Online, einer der Kernbestandteile von Microsoft 365, verbunden werden. Diese Verbindung erfolgt durch die sog. Hybrid-Konfiguration und ist eine besondere Vertrauensstellung zwischen zwei technisch getrennten Exchange Umgebungen.

Diese besondere Vertrauensstellung zwischen der lokalen Exchange Organisation und Exchange Online ist notwendig, damit E-Mail- und System-Nachrichten, die zwischen beiden Umgebungen unsgetauscht werden, als interne E-Mail-Nachrichten erkannt und verarbeitet werden. Nur so ist es möglich, die korrekte Funktion aller Exchange Komponenten, unabhängig vom Bereitstellungsort der Benutzerpostfächer, zu gewährleisten.

Welche Vorteile ein Exchange Hybrid-Betrieb für die Exchange Umgebung in Ihrem Unternehmen hat, erfahren Sie in diesem Microsoft Docs Artikel.

Das folgende Schaubild verdeutlicht die Hybrid-Konfiguration und die besondere Vertrauensstellung (gepunktete grüne Linie).

Eine Exchange Hybrid-Konfiguration richten Sie mit Hilfe des Hybrid Confguration Wizard (HCW) ein. Während der HCW-Einrichtung müssen Sie sich für eine der zur Verfügung stehenden Möglichkeiten für den Hybrid-Betrieb entscheiden.

Welche Optionen für den Hybrid-Betrieb gibt es?

Für den Hybrid-Betrieb einer lokalen Exchange Organisation mit Exchange Online gibt es mehrere Möglichkeiten. Wir unterscheiden zwei grundlegende Betriebsvarianten, den klassischen und den modernen Hybrid-Betrieb. Für diese beiden Varianten stehen je bis zu drei Betriebsmodi zur Verfügung.

Das folgende Schaubild verdeutlich die unterschiedlichen Betriebsmodi für die beiden Betriebsvarianten einer Hybrid-Konfiguration.

Nun stellt sich automatisch die Frage, welchen Betriebsmodus soll ich für Hybrid-Konfiguration meiner Exchange Organisation verwenden?

Schauen wir uns zuerst an, welche technischen Voraussetzungen die beiden Betriebsvarianten haben.

Klassischer Hybrid-Betrieb

Der klassische Hybrid-Betrieb erfordert, dass interne Exchange Server aus dem Internet über das Protokoll HTTPS erreichbar sind. Über diese Verbindung erfolgt die Kommunikation von Exchange Online zur internen Exchange Organisation für Hybrid-Funktionen. Damit einher geht die Anforderung für eine aus dem Internet erreichbare IP-Adresse und die Verwendung eines offiziellen TLS-Zertifkates.

Moderner Hybrid-Betrieb

Der moderne Hybrid-Betrieb erfordert keinerlei eingehende HTTPS-Verbindung von Exchange Online zur internen Exchange Organisation. 

Die Verbindung zwischen der lokalen Exchange Organisation und Exchange Online erfolgt über den Exchange Hybrid Agent. Die Software für den Exchange Hybrid Agent ist als Dienst auf einem Server installiert und verbindet sich über eine ausgehende HTTPS-Verbindung mit Exchange Online. Die Konfiguration durch den HCW steuert hierbei das Verhalten von Exchange Online. Mit Blick auf den Hybrid-Betrieb von Exchange ist dies die bevorzugte und schnellste Betriebsvariante, da keinerlei zusätzliche Komponenten für eingehende HTTPS-Verbindungen benötigt werden. Wenn Ihr Unternehmen jedoch Microsoft Teams verwenden möchte und weiterhin Postfächer von Teams-Anwendern auf lokalen Exchange Servern betrieben werden sollen, können Sie diese Betriebsvariante nicht nutzen. Microsoft Teams unterstützt für dieses Betriebsszenario nur den klassischen Hybrid-Betrieb.

Klassicher und Moderner Hybrid-Betrieb

• Beide Betriebsvarianten benötigen für den hybriden Nachrichtenfluss ein- und ausgehende SMTP-Verbindungen zwischen der lokalen Exchange Organisation und Exchange Online.
   
• Beide Betriebsvarianten erfordern ausgehende HTTPS-Verbindungen zu Exchange Online von den internen Exchange Server Systemen.

Für welches Betriebs- und Migrationsszenario passen die fünf Betriebsmodi?

		Vollwertige, klassische Hybrid-Konfiguration mit direkter Veröffentlichung der Exchange Organisation ins Internet (SMTP/HTTPS) Dauerhafter Hybrid-Betrieb Postfächer On-Premises und in Exchange Online
		Hybrid-Konfiguration, inkl. Azure AD Connect, zum einmaligen Verschieben aller Postfächer zu Exchange Online Temporärer Hybrid-Betrieb über wenige Monate Ziel: Migration aller Postfächer zu Exchange Online
		Hybrid-Konfiguration, inkl. Azure AD Connect Express Setup, zum einmaligen Verschieben aller Postfächer zu Exchange Online Temporärer Hybrid-Betrieb über wenige Tage oder Wochen Ziel: Migration aller Postfächer zu Exchange Online
		Vollwertige, klassische Hybrid-Konfiguration für neue Konfigurationen mit Hilfe des Exchange Hybrid-Agenten, jedoch mit Funktionseinschränken Dauerhafter Hybrid-Betrieb Postfächer On-Premises und in Exchange Online
		Hybrid-Konfiguration, inkl. Azure AD Connect, zum einmaligen Verschieben aller Postfächer zu Exchange Online mit Hilfe des Exchange Hybrid-Agenten Temporärer Hybrid-Betrieb über wenige Monate MIgration aller Postfächer zu Exchange Online

Herausforderungen

Die Implementierung eines Hybrid-Betriebes stellt Ihr Unternehmen vor technische Herausforderungen. Daher muss die Einrichtung des hybriden Exchange Betriebes gut geplant werden.

Für den klassischen Hybrid-Betrieb benötigen Sie externe IP-Adressen für die beiden Protokolle HTTPS und SMTP, während für den modernen Hybrid-Betrieb nur eine IP-Adresse für das Protokoll SMTP benötigt wird. Ebenso benötigen Sie TLS-Zertifikate. Für den Nachrichtenfluss zwischen der lokalen Exchange Organisation und Exchange Online empfehle ich, ein separates TLS-Zertifikat zu verwenden, das nicht für das E-Mail-Internet-Gateway verwendet wird. 

Die Absicherung der internen Exchange Server vor direkten Zugriffen aus dem Internet hat höchste Priorität. Sichern Sie den E-Mail-Nachrichtenfluss der hybriden Verbindung zwischen der lokalen Exchange Organisation und Exchange Online mit Exchange Edge-Servern ab. Der HTTPS-Zugriff zu den internen Exchange Server von Exchange Online wird über Reverse-Proxies abgesichert.

Bei einem dauerhaften Hybrid-Betrieb ist die lokale Exchange Organisation für die Verwaltung der zu Exchange Online verschobenen Exchange-Objekte zuständig. Im Zusammenspiel mit dem lokalen Active Directory bleibt sie die Source of Authority (SOA). Aus diesem Grund benötigen Sie mindestens einen verbleibenden lokalen Exchange Server, der als sog. Koexistenz-Server betrieben wird. Hierzu sollten Sie einen System mit Exchange Server 2016 oder Exchange Server 2019 verwenden.

Fazit

Mit einer Auswahl von zwei Betriebsvarianten und insgesamt fünf Betriebsmodi fällt es nicht leicht, die passende Wahl zu treffen. Die wichtigste Frage, die Sie sich zuerst stellen müssen ist, wie soll die Bereitstellung von Exchange Funktionen in Zukunft für das Unternehmen aussehen und welche Anforderungen hat das Unternehmen im Hinblick auf die Absicherung von E-Mail-Nachrichten? Sind Anwender-Postfächer in der lokalen Exchange Organisation bereitgestellt und in Ihrem Unternehmen soll Microsoft Teams genutzt werden, so ist die klassische Voll-Hybrid-Variante die einzige Option.

Die größte Flexibilität erreichen Sie mit dem klassischen Hybrid-Betrieb, jedoch ist dies auch die Variante mit den meisten Anforderungen zur Einrichtung und den dauerhaften Betrieb.

Mit dem modernen Hybrid-Betrieb erreichen Sie schnell eine Hybrid-Konfiguration und können zügig Postfächer zu Exchange Online migrieren. Bei Nutzung von Microsoft Teams und Anwender-Postfächern in der lokalen Exchange Organisation ist dies jedoch keine Option. 

Links

• Exchange Server Hybridbereitstellungen
• Voraussetzungen für die Hybridbereitstellung
• Einschränkungen für den Exchange Hybrid Agent
• Tech Talk 3: Exchange Hybrid (Video)

Viel Spaß mit einem sicheren Exchange Online.

Troubleshooting der Kalender-App

Teams Backend AutoDiscover

Die Teams Backend Services nutzen AutoDiscover Version 2, um das Exchange Anwender-Postfach im Auftrag eines Teams-Clients zu finden. Dieser AutoDiscover V2 Aufruf ist aus Performancegründen ein anonymer Aufruf, um möglichst schnell die Exchange Ziel-URL für das gesuchte Postfach zu ermitteln. Wie bereits im ersten Teil erwähnt, wird erfolgt zuerst immer eine Abfrage gegen den AutoDiscover-Endpunkt von Exchange Online durchgeführt. Sollte sich das Postfach nicht in Exchange Online befinden, erhalten die Backend Services in einer Redirect-Antwort die Zieladresse der lokalen Exchange Organisation, um eine erneute AutoDiscover-Abfrage durchzuführen.

Hierbei werden folgende Schritte durchlaufen:

1. Die Teams Backend Services fragen den Exchange Online AutoDiscover-Endpunkt per AutoDiscover V2 JSON-Abfrage nach der URL für das EWS-Protokoll
   https://outlook.office365.com/autodiscover/autodiscover.json?Email=John.Doe@varunagroup.de&Protocol=EWS
    
2. Exchange Online prüft den Empfängertyp (RecipientType) der angefragten E-Mail-Adresse und gibt für den gefundenen Empfängertyp folgende Antworten:
   1. RecipientType: Mailbox
      https://outlook.office365.com/EWS/Exchange.asmx
      
      Das Postfach ist ein Exchange Online Postfach, somit sind keine weiteren Schritte notwendig.
      Die Teams Backend Services haben die notwendige Information, um auf das Postfach und den Kalender zuzugreifen.
       
   2. RecipientType: MailUser
      Exchange Online ermittelt den AutoDiscover-Endpunkt auf Basis des Attributes ExternalEmailAddress, in diesem Beispiel autodiscover.varunagroup.de
       
3. Exchange Online antwortet mit einem HTTP 302 Redirect zu autodiscover.varunagroup.de
    
4. Die Teams Backend Services fragen per AutoDiscover V2 JSON-Abfrage nach der URL für das Protokoll EWS
   https://autodiscover.varunagroup.de/autodiscover/autodiscover.json?Email=John.Doe@varunagroup.de&Protocol=EWS
    
5. On-Premises Exchange Server antwortet mit einer externen EWS URL eines virtuellen Exchange Web Services Verzeichnisses
   Beispiel: {"Protocol":"EWS","Url":"https://mail.varunagroup.de/EWS/Exchange.asmx"}
    
6. Die Teams Backend Services nutzen diese URL, um eine Verbindung zur On-Premises Exchange Organisation aufzubauen

Aber was passiert, nachdem die Teams Backend Services die URL für den Zugriff auf das lokale Postfach ermittelt haben? Es werden folgende Schritte durchgeführt:

• Zugriff auf die ermittelte EWS-URL der lokalen Exchange Organisation und Durchführung einer OAuth-Authentifizierung
• Die Teams Backend Service senden eine EWS-Kalenderanfrage an den EWS-Endpunkt
• Die Exchange Web Services antworten mit den Kalenderinformationen des Anwenderpostfaches
• Die Teams Backend Services geben die Kalenderdaten an die Kalender-App zur Nutzung im Teams-Client weiter

Wie Sie sehen, ist der Zugriff auf den Kalender eines Benutzerpostfaches in einer lokalen Exchange Organisation komplex. Hierbei kann es auch zu Fehlern kommen.

Wie können Sie nun für den AutoDiscover-Prozess und den Kalenderzugriff eine Fehleranalyse durchführen? Fangen wir mit AutoDiscover an.

Troubleshooting AutoDiscover

Da alle AutoDiscover- und weiteren Zugriffe aus den Teams Backend Services heraus erfolgen, sind Troubleshooting-Schritte auf dem lokalen Teams-Client nicht hilfreich.

AutoDiscover V2 ist ein anonymer Zugriff und ermöglicht so einen einfachen Selbsttest. Dies hilft Ihnen als IT-Administrator, um den Zugriff für ein Benutzerkonto zu prüfen, bei dem es zu einem Fehlverhalten kommt. Prüfen Sie das AutoDiscover Verhalten per PowerShell oder mit Hilfe eines Browsers.

Test per PowerShell

Invoke-RestMethod -Uri 'https://outlook.office365.com/autodiscover/autodiscover.json?Email= John.Doe@varunagroup.de&Protocol=EWS'

Invoke-RestMethod -Uri 'https://outlook.office365.com/autodiscover/autodiscover.json?Email= John.Doe@varunagroup.de&Protocol=REST'

Test per Browser

https://outlook.office365.com/autodiscover/autodiscover.json?Email=john.doe@varunagroup.de&Protocol=EWS
https://outlook.office365.com/autodiscover/autodiscover.json?Email=john.doe@varunagroup.de&Protocol=REST

Führen Sie zur erweiterten Fehleranalyse bei der Ausführung der HTTPS-Abfragen einen Fiddler-Trace durch. Der Trace hilft Ihnen, weitere mögliche Fehlerquellen zu identifizieren.

Kommt es bei der Ermittlung der AutoDiscover Informationen zu einem Fehler, bedeutet dies nicht automatisch, dass ein Problem vorliegt. Prüfen Sie folgende Punkte:

• Die Ausführung der Abfrage wird mit einer Zeitüberschreitung abgebrochen
  • Ist der HTTPS-Zugriff auf die Ihre Exchange Organisation auf den Remote -IP-Adressbereiche von Microsoft 365 eingeschränkt?
  • Haben die Exchange Server ein Performance-Problem und können nicht zeitnah antworten?
     
• Sie erhalten eine „User Not Found“-Meldung als Antwort
  • Ist das Benutzerkonto von der Azure AD Connect Synchronisierung ausgenommen und existiert nicht als „Mail User“-Objekt in Exchange Online?
     
• Die Antwort liefert eine nicht erwartete EWS oder REST URL
  • Das Anwenderpostfach ist ein lokales Postfach, als Antwort erhalten Sie aber
    https://outlook.office365.com/EWS/Exchange.asmx
    
    Der Anwender verfügt über ein zusätzliches Postfach in Exchange Online.
    Lösen Sie die Postfach-Situation auf.
     
  • Sie erhalten eine URL, die wie einer interne URL aussieht
    https://exch01.varunagroup.local/EWS/Exchange.asmx
    
    Das ExternalUrl-Attribut ist nicht auf allen Exchange Servern konfiguriert.
  • Sie nutzen gebundene Namensräume und das Anwenderpostfach ist in der AD-Site EMEA, sie erhalten aber die URL einer anderen AD-Site
    https://mail.apac.varunagroup.de/EWS/Exchange.asmx
    Erwartete URL: https://mail.emea.varunagroup.de/EWS/Exchange.asmx
    
    AutoDiscover V2 ist erst mit den kumulativen Updates von März 2021 "AD-Site aware". Ohne dieses Update für Exchange Server 2016 und 2019 antwortet AutoDiscover V2 mit eine zufällig gewählten URL.
     
• Die Namensauflösung für die Zieldomäne schlägt fehl
  • Es existiert kein DNS-Eintrag für AutoDiscover

Die nächsten Schritte zur Identifikation von Verbindungsproblemen führen uns schon zu den lokalen Exchange Servern. Mit einem lokalen Netzwerk-Trace können Sie feststellen, ob es zu TLS-Handshake Fehlern kommt. Bedenken Sie, dass Ihre Exchange Server System korrekt für TLS 1.2 konfiguriert sein müssen.

Gibt es keine Fehler beim TLS-Handshake, gilt es nun die Protokolldateien der Exchange Server zu prüfen. Die Prüfung der Protokolldateien ist auf den lokalen Exchange Servern erfordert mehrere Schritte. Je nach Größe Ihrer lokalen Exchange Organisation ist diese Prüfung beliebig komplex.

Das folgende Diagramm zeigt die beteiligten Exchange Server Komponenten eines einzelnen Exchange Servers für eingehende Verbindungen der Teams Backend Services zum Exchange Web Services Endpunkt.

Eine eingehende HTTPS-Verbindung wird durch die Frontend-Komponente eines Exchange Servers angenommen und anschließend als Proxy-Verbindung zu dem Exchange Server weiterverbunden, auf dem im Moment des Zugriffes die Postfachdatenbank mit dem Anwender-Postfach aktiv eingebunden ist. Prüfen Sie zuerst in IIS-Protokolldateien, ob die Verbindung durch die Internet Information Service angenommen wurde. Überprüfen Sie anschließend die Frontend- oder Backend-Protokolldateien des angesprochenen Exchange-Endpunktes, also AutoDiscover, EWS oder REST.

Zum Themenkomplex möglicher Verbindungsprobleme zwischen den Microsoft Backend Services und Exchange Server finden Sie zusätzliche Information in der Microsoft Online Dokumentation.

Troubleshooting Kalender-App

Nachdem Sie nun wissen, wie Sie den Fehlern im AutoDiscover-Prozess begegnen, ist es Zeit, einen Blick auf die Kalender-App zu werfen.

Wenn der Zugriff auf AutoDiscover fehlerfrei funktioniert, ist die Wahrscheinlichkeit groß, dass auch der Zugriff auf die Exchange Web Services funktioniert und damit auch die Kalender-App im Teams Client des angemeldeten Anwenderkontos.

Sollte der Kalender im Teams-Client nicht angezeigt werden, prüfen Sie folgende Punkte:

• Kann die per AutoDiscover ermittelte EWS-URL in der externen DNS-Zone der Domäne aufgelöst werden und ist sie aus dem Internet per HTTPS erreichbar?
  • Rufen Sie die Ziel-URL in einem Browser auf und führen Sie eine Fiddler-Trace durch
    Der EWS Endpunkt muss mit einem HTTP-Statuscode 401 antworten
     
• Prüfen Sie den Teams Kalenderzugriff mit Hilfe des Remote Connectivity Analyzer.
  
  
  • http://bit.ly/TeamsCalTest
     
• Prüfen Sie die OAuth-Authentifizierung
  • Hier hilft Ihnen das PowerShell Cmdlet Test-OAuthConnectivity
  • Prüfen Sie auch die ServicePrincipalNames, IntraOrganization- und AuthServer-Einstellungen

Links

• Exchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It
• My user has a mailbox both on-premises and in Exchange Online. Help!
• Configure OAuth authentication between Exchange and Exchange Online organizations

• Teil 1 - Wie interagieren Microsoft Teams und Exchange Server?
• Teil 2 - Troubleshooting der Kalender-App
• Teil 3 - Troubleshooting von Kalenderstellvertretungen und kalenderbasiertem Präsenzstatus

Abschaltung der Basic Authentication für Exchange Online

In ihrem Blogartikel Improving Security - Together hat die Exchange Produktgruppe angekündigt, die unsichere Authentifizierungsmethode Basic Authentication zum 13. Oktober 2020 nicht nur für die Exchange Web Services (EWS) abzuschalten, sondern zusätzlich auch für Exchange ActiveSync (EAS), POP, IMAP und Remote Exchange PowerShell.

Bei der Basic Authentication handelt es sich um eine in die Jahre gekommene Authentifizierungsmethode, die im Vergleich zu modernen Authentifizierungsmethoden Schwächen hat. Diese Schwächen führen dazu, dass diese Authentifizierungsmethode immer wieder von Angreifern verwendet wird, um unberechtigten Zugriff auf Ressourcen zu erlangen. Exchange Online und Azure AD sind, als globale Clouddienste, immens vielen Angriffen dieser Art ausgesetzt.

Mehr Sicherheit mit moderner Authentifizierung

Die moderne Authentifizierung (Modern Auth), basierend auf OAuth 2.0, bietet im Zusammenspiel mit Multi-Faktor-Authentifizierung (MFA) einen umfassenderen Schutz für den Zugriff auf Exchange Online und andere Cloud-Ressourcen. Diese Art der Authentifizierung ist nicht neu, setzt sich für bestimmte Zugriffsarten aber nur langsam durch. Die Unterstützung für Modern Auth wird bereits seit Office 2013 unterstützt und ist seit Version 2016 nativ in das Produkt integriert.

Für mobile Endgeräte stellt sich die Situation etwas anders dar. In vielen Fällen erfolgt der Zugriff auf Exchange Online Postfächer mit nativen E-Mail-Clients der mobilen Endgeräte statt. Diese verwenden in den meisten Fällen das ActiveSync-Protokoll (EAS). EAS wiederum bedient sich standardmäßig der Basic Authentifizierung und ist daher für die Zukunft nicht mehr das passende Protokoll für den Zugriff auf Exchange Online. Hier ist Outlook Mobile (Android/iOS) die bessere Alternative. Mit Outlook Mobile haben Sie die Möglichkeit, die Authentifizierung der Benutzerkonten zusätzlich mit MFA abzusichern.

Für die Protokolle SMTP, POP und IMAP gibt es eine besondere Herausforderungen. Diese Protokolle unterstützen heute die moderne Authentifizierung (noch) nicht. Für den Zugriff auf Mitarbeiter-Postfächer stellt dies noch keine Problem dar, da dieser Zugriff immer über das Protokoll MAPIoverHTTP erfolgen sollte. Das eigentliche Problem sind all die anderen Applikationen, die Sie gegenwärtig für einen POP/IMAP-Postfachzugriff und SMTP-Mailversand über ein Exchange Online Postfach konfiguriert haben. Hierzu gehören z.B. Ticketsysteme, ERP-Lösungen oder individuell programmierte Line-of-Business-Applikationen (LOB).

Ähnlich sieht es für die Authentifizierung von PowerShell-Skripten aus, die auf einem Ihrer internen Skript-Server ausgeführt werden und Aktionen gegen Exchange Online ausführen. Für die direkte Anmeldung an die Exchange Online PowerShell mit Modern Auth können Sie bereits heute das Exchange Online PowerShell Modul mit MFA oder die Azure Cloud Shell verwenden.

Was muss ich tun?

Die Deaktivierung der Basic Authentication für Exchange Online hat direkte Auswirkungen auf die von Ihnen betreute IT-Infrastruktur. Um eine Unterbrechung im Zugriff auf Exchange Online-Ressourcen zu vermeiden, müssen Sie wissen, mit welchen Protokollen Anwender und Applikationen auf Exchange Online-Endpunkte zugreifen. Die Exchange Produktgruppe plant ein Software-Tool zur Auswertung bereitzustellen, dass Sie bei der Analyse der Zugriffsarten unterstützt.

Für den Zugriff auf Exchange Postfächer von Windows Desktops ist die Maßnahme einfach. Wenn Sie noch ältere Windows Desktop Betriebssystem im Unternehmen einsetzen, wechseln Sie auf Windows 10 als Standard-Betriebssystem und migrieren Sie die Office-Installation zu Office 2019 bzw. Office 365 ProPlus.

Nutzen Sie Outlook Mobile für den Zugriff auf Exchange Online Postfächer. Outlook Mobile lässt sich über die gängigen Mobile Device Management (MDM) Lösungen zentral auf mobile Endgeräte verteilen und konfigurieren. Mit Hilfe von Mobile Application Management (MAM) und Conditional Access können Sie die Sicherheit beim mobilen Zugriff auf Exchange Online Postfächer noch weiter erhöhen.

Für automatisierte PowerShell-Skripte wird die Anpassung auf Modern Auth schwieriger. Sie können für die Ausführung der Skripte in der lokalen IT-Infrastruktur das Exchange Online PowerShell Modul mit MFA implementieren. Hierbei müssen Sie allerdings bedenken, dass Skripte mit einer längeren Ausführungszeit in technische Probleme laufen werden. Wenn Ihre Skripte von Timeouts und Skriptverzögerungen, sog. Micro Delays, betroffen sind, müssen Sie die Strategie zur Skriptausführung überdenken und den Skript-Code anpassen. Eventuell ist es vorteilhafter, eine professionelle Softwarelösung zur Ausführung von Skripten einzusetzen, die Modern Auth nativ unterstützt. PowerShell-Skripte, die nur Aktionen gegen Exchange Online oder anderen Office 365 Endpunkten ausführen, können auch in Azure Automation betrieben werden.

Wichtig ist auch noch einmal der Hinweis, dass sich die Deaktivierung der Basic Authentifizierung auf Exchange Online bezieht. Die On-Premises Variante von Exchange Server 2019 ist davon nicht betroffen.

Fazit

Die Exchange Produktgruppe ist sich der Herausforderungen für die Kunden bewusst. Der Titel des Original-Artikels Improving Security - Together ist mit Bedacht gewählt. Ein besserer Schutz von Exchange Online Postfächern und Ressourcen ist nur möglich, wenn die Erhöhung der Sicherheit gemeinsam, also von Ihnen als Office 365 Kunde und der Exchange Produktgruppe, umgesetzt wird.

Bereiten Sie sich und Ihre IT-Infrastruktur rechtzeitig auf die Abschaltung der Basic Authentication vor. Erstellen Sie einen realistischen Zeitplan für die notwendigen Konfigurationen und Anpassungen, um spätestens im Juli 2020 die Umstellung abgeschlossen zu haben. Es hat sich schon immer bewährt, einen zeitliche Puffer einzuplanen.

Die Erhöhung der Sicherheit geht immer mit Komfortverlust einher. Dieser Komfortverlust ist jedoch zu verschmerzen, wenn man den Sicherheitsgewinn gegenüberstellt.

Links

• Building Zero Trust networks with Microsoft 365 
• Enable modern authentication in Exchange Online 
• Upcoming changes to Exchange Web Services (EWS) API for Office 365
• Connect to Exchange Online PowerShell using multi-factor authentication
• Azure Cloud Shell Now Supports Exchange Online

Viel Spaß mit Exchange Online!