Wenn Sie versuchen, die Mitglieder einer E-Mail-aktivierten Sicherheitsgruppe im Exchange Admin Center bearbeiten und anschließend speichern möchten, kann es zu folgender Fehlermeldung kommen.
Eine E-Mail-aktivierte Sicherheitsgruppe erlaubt das selbständige Verlassen oder Beitreten durch Anwender nicht. Diese Funktion ist Verteilergruppen vorbehalten. Die Konfiguration dieser Einstellung ist im Exchange Admin Center für E-Mail-aktivierte Sicherheitsgruppen nicht möglich. Diese Einstellungen können nur per Exchange Management Shell durchgeführt werden.
Fragen Sie die Einstellungen der E-Mail-aktivierten Sicherheitsgruppe per PowerShell ab.
Get-Distributiongroup SECURITYGROUPNAME | FL Name, GroupType, RecipientTypeDetails,*Restriction
Wenn Sie dem Hinweis der Fehlermeldung folgen und nur einen der beiden Parameter zum Beitreten oder Verlassen einer E-Mail-aktivierten Sicherheitsgruppe per Exchange Management Shell auf Geschlossen (Closed) setzen, erhalten Sie ebenfalls eine Fehlermeldung.
Setzen Sie immer beide Parameter gleichzeitig.
Set-DistributionGroup SECURITYGROUPNAME -MemberJoinRestriction Closed -MemberDepartRestriction Closed
Nach dieser Anpassung der E-Mail-aktivierten Sicherheitsgruppe ist es wieder möglich, die Mitglieder der Sicherheitsgruppe über das Exchange Admin Center zu pflegen.
Dieser Fehler trat in einer Active Directory Umgebung auf, in der vorübergehend die Exchange Organisation in einer Split-Permission Konfiguration betrieben und wieder auf Shared-Permission zurückgestellt wurde.
Viel Spaß mit Exchange Server.
Manchmal ist es notwendig, das Offline Adressbuch (OAB) für den Outlook E-Mail Client manuell herunterzuladen.
Kommt es beim Herunterladen des OAB zu einem Fehler, in diesem Fall 0x80200051, wird durch den First-Line Support gerne zwischen dem Online- und dem Cached-Modus von Outlook hin und her gewechselt. Leider behebt dieses Vorgehen den Fehler nicht.
Nach dem erneuten Aktivieren des Cached-Modus, muss das OAB vollständig neu heruntergeladen werden. Leider ist im Outlook-Diaglog zum manuellen Download des OAB die Checkbox "Änderungen seit der letzten Übermittlung herunterladen" standardmäßig aktiv. Diese Option muss abgewählt werden, um einen vollständigen Download es OAB durchführen zu lassen.
Mit dieser Download-Einstellung kommt es nicht mehr zu einem Fehler.
Viel Spaß mit Outlook.
Wenn Sie Öffentliche Ordner alter Bauart (Legacy Public Folder) von Exchange Server 2010 zu modernen Öffentlichen Ordnern (Modern Public Folder) in Exchange Online migrieren, kann es bei der Synchronisation der Öffentlichen Ordner zu folgendem Fehler kommen:
Error: More than X mail public folders in Active Directory were not linked to any public folder during migration. Mail flow will stop working for these public folders after the migration is finalized. Please check whether these are important
Dieses Problem tritt in folgendem Szenario auf:
Ausgabe des Scripts Sync-MailPublicFolders.ps1 nach Deaktivierung aller E-Mail-aktivierten Öffentlichen Ordner:
Creating an Exchange Online remote session... Exchange Online remote session created successfully. Enumerating local mail enabled public folders... Mail public folders enumeration completed: 0 local folder(s) found. WARNUNG: You are about to remove ALL mail-enabled public folders from Exchange Online Active Directory. Only proceed if you do not have any users on Exchange Online already using mail-enabled public folders.
Das Script meldet zwar, dass bei der Synchronisation die Informationen über die inzwischen E-Mail-deaktivierten Ordner aus Exchange Online entfernt werden, dies ist jedoch nicht der Fall.
Prüfen Sie in der Exchange Online PowerShell, ob sich noch E-Mail-aktivierte Ordner in der Exchange Online Organisation befinden.
Get-MailPublicFolder -ResultSize Unlimited
Prüfen Sie, welche vermeintlich E-Mail-aktivierten Ordner inzwischen deaktiviert wurden und entfernen Sie diese Ordner aus der Exchange Online Organisation
# Löschung eines lokal nicht mehr E-Mail-aktivierten Ordners Get-MailPublicFolder 'Mail Public Folder' | Remove-SyncMailPublicFolder # Löschung alle E-Mail-aktivierten Ordner Informationen aus Exchange Online Get-MailPublicFolder -ResultSize Unlimited | Remove-SyncMailPublicFolder
Nach der Löschung der Informationen aus Exchange Online wird die nächste inkrementelle Synchronisation des Migrationsbatches ohne Fehler durchlaufen.
Viel Spaß bei der MIgration von Öffentlichen Ordner zu Exchange Online!
Exchange Server besteht aus zwei Kernkomponenten. Zum einen ist es die Bereitstellung von Postfächern, mit all den benötigten Client-Zugriffsprotokollen und Postfach-Funktionen. Die zweite Komponente ist der Nachrichtenfluss, also der Empfang, die Verarbeitung und der Versand von E-Mail-Nachrichten.
Was sich so einfach und trivial anhört, ist ein zentraler und komplexer Baustein in der Exchange Architektur. In diesem Artikel versuche ich ein wenig Licht ins Dunkel des Exchange Nachrichtenflusses zu bringen. Lassen Sie uns mit einem kurzen Rückblick auf die Exchange Server Architektur beginnen.
Wer sich den Nachrichtenfluss von Exchange Server anschaut, muss sich immer den Funktionsaufbau eines Exchange Servers und die empfohlene Implementierung im Rahmen der Preferred Architecture (PA) in Erinnerung rufen. In der PA wird Exchange Server immer in einer Konfiguration aus mehreren Exchange Servern, die als Datenbankverfügbarkeitsgruppe (DAG) zusammengefasst sind, betrieben. Hierdurch wird eine hochverfügbare Bereitstellung von Postfachfunktionen und Nachrichtentransport erreicht.
Jeder Exchange Server besteht aus einer Frontend- und Backend-Komponente. Eingehende Verbindungen von Drittsystemen erfolgen immer über die Exchange Frontend-Komponenten. Die Kommunikation mit den Backend-Komponenten erfolgt im Regelfall nur Exchange-intern.
Das folgende Diagramm zeigt den schematischen Aufbau der Verbindungen in einer DAG.
Die Konfigurationen für den Nachrichtenfluss unterteilen sich in organisationsweite und serverbezogene Einstellungen. Die organisationsweiten Einstellungen gelten, wie der Name es schon sagt, für die gesamte Exchange Organisation, ganz unabhängig davon wie viele Exchange Server oder DAGs Sie betreiben. Ob und wie ein Exchange Server diese Einstellungen verarbeiten kann, hängt von der Produktversion ab. Diese Einstellungen sind vollständig in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Sendekonnektoren.
Serverbezogene Einstellungen wirken sich nur für ein bestimmtes Serversystem aus. Diese Einstellungen werden hauptsächlich ebenfalls in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Empfangskonnektoren. Einige wenige Einstellungen werden jedoch auch in der lokalen Systemregistrierung gespeichert.
Für den sicheren und stabilen Betrieb von Exchange Server ist eine funktionierende Active Directory Replikation unerlässlich. Hierzu gehört auch eine korrekte Konfiguration der Active Directory Sites. Sie ist gerade in größeren Exchange Organisationen unerlässlich.
Ebenso wichtig ist die korrekte und einheitliche Konfiguration der TLS-Einstellungen auf allen Exchange Servern. Ohne solch eine Konfiguration ist nicht sichergestellt, dass verschlüsselte Verbindungen durch die Empfangs- und Sendekonnektoren aufgebaut werden können. Exchange Server vertraut hier auf die Konfiguration des lokalen Windows Server Betriebssystems und die Bereitstellung gültiger TLS-Zertifikate.
Kommen wir nun zum eigentlichen Thema, dem Exchange Nachrichtenfluss und beginnen mit dem Empfang von E-Mail-Nachrichten.
Exchange Server nehmen eingehende E-Mail-Nachrichten über unterschiedliche Wege entgegen. Der bekannteste Weg ist der Empfang über das Protokoll SMTP. Ein Exchange Server unterscheidet hierbei drei unterschiedliche Quelltypen. Im Frontend-Transport erfolgt die Annahme von Verbindungen anderer Server über den Standard TCP-Port 25. Zu den Servern, die sich über diesen Standard SMTP-Port verbinden, zählen:
Diese Verbindungen erfolgen über den Default Frontend Konnektor, der in seiner Standardkonfiguration nur Nachrichten, die an bekannte Empfänger eigener Domänen entgegennimmt. Die Zustellung von Applikationsnachrichten an externe Empfänger erfordert die Erstellung eines separaten Frontend-Empfangskonnektor.
Zusätzlich zu den Empfangskonnektoren stehen zwei weitere Wege über das lokale Dateisystem des Exchange Servers zur Verfügung, das Pickup- und Replay-Verzeichnis. Beide Verzeichnisse werden vom Backend-Transportdienst, den Sie aus früheren Exchange Versionen sicher noch als Hub-Transport kennen, permanent überwacht und sobald eine Datei dort abgelegt ist, wird sie aufgenommen und verarbeitet. Das Pickup-Verzeichnis dient der Ablage von neuen E-Mail-Nachrichten durch Applikationen. Das Replay-Verzeichnis können Sie nutzen, um Nachrichten, die Sie aus einer Warteschlange exportiert und entfernt haben, erneut in die Verarbeitung zu übergeben.
Zum Schutz vor unberechtigten Verbindungen verwendet Exchange Server unterschiedliche Formen der Authentifizierung. Ergänzend verfügen die Eingangswege über eine Header-Firewall, mit der unberechtigte Informationen aus einer E-Mail-Nachricht herausgefiltert werden.
Der Frontend-Transport verfügt über keine komplexe Business-Logik. Daher ist es wichtig, das Zusammenspiel zwischen Frontend-Transport und Transportdiensten im Backend zu verstehen und sich immer wieder in Erinnerung zu rufen, wenn es zu Problemen kommt. Der Empfangskonnektor im Frontend-Transport nimmt die Verbindung entgegen und führt die Authentifizierung durch. Anschließend wird eine Proxyverbindung zum Transportdienst per TCP-Port 2525 aufgebaut. Hierbei entscheidet nun die Konfiguration Ihrer Exchange Umgebung darüber, wie diese Proxyverbindung erfolgt. Bei einem Einzelserverbetrieb erfolgt die Verbindung zum Transportdienst des gleichen Servers. In einer DAG-Konfiguration wählt der Frontend-Transport den Transportdienst des DAG-Mitgliedservers aus, auf dem in diesem Moment die Datenbankkopie mit dem Postfach des Empfängers aktiv eingebunden ist.
Das folgende Diagramm zeigt das Zusammenspiel zwischen Frontend und Backend beim Empfang von Nachrichten per SMTP.
Beim Empfang einer Nachricht per SMTP versucht Exchange Server die Nachricht ausfallsicher entgegenzunehmen. Zu diesem Zweck erstellt Exchange Server eine Kopie der empfangenen Nachricht und speichert sie als Schattenkopie im Transportdienst eines anderen Exchange Servers. Erst nach dem erfolgreichen Speichern der Schattenkopie und der Speicherung in der lokalen Warteschlange des Backend-Transportdienstes, meldet der empfangende Exchange Server dem sendenden Server eine OK-Meldung.
Auf einem Exchange Server können mehrere Empfangskonnektoren für den gleichen Port konfiguriert werden. Wenn Sie weitere Konnektoren für den gleichen Port erstellen, müssen Sie festlegen, wie Exchange Server einen Konnektor auswählen soll. Am einfachsten ist hier die Konfiguration der IP-Adressen des absendenden Systems als Remote IP-Adresse am Konnektor.
Im Backend des Exchange Servers befinden sich zwei Transportdienste. Der wichtigste Dienst ist der Transportdienst, den manche von Ihnen sicher noch als Hub-Transport aus älteren Versionen von Exchange Server kennen. Diesen Dienst schauen wir uns im nächsten Abschnitt einmal genauer an. Der zweite Dienst ist der Postfachtransportdienst. Dieser Dienst hat die Aufgabe, eingehende Nachrichten in Postfächern lokal eingebundener Datenbanken zu speichern und Nachrichten, die versendet werden sollen, aus Postfächern lokaler Datenbanken zu lesen und zur weiteren Verarbeitung an den Transportdienst zu übermitteln. Diesen Dienst beschreibe ich in einem zukünftigen Artikel.
Der einfach erscheinende Empfang einer E-Mail-Nachricht ist, aus Gründen der Nachrichtensicherheit und zum Schutz vor dem Ausfall eines Systems, eine komplexe Aufgabe. Nach dem Empfang der Nachricht muss sie verarbeitet werden.
Die gesamte Verarbeitung von E-Mail-Nachrichten erfolgt im Transportdienst und ist Warteschlangen-basiert, mit der Betonung auf „Warte“. Eine empfangene E-Mail-Nachricht wird in der Submission-Warteschlange gespeichert und wartet dort darauf, zur sog. Kategorisierung aufgegriffen zu werden. In der Categorizer-Komponente erfolgt die Hauptarbeit des Transportdienstes. Zu den Aufgaben gehören:
Nach der Verarbeitung im Categorizer ist die Nachricht bereit zur weiteren Zustellung und wird hierzu in einer passenden Warteschlange gespeichert. Der Transportdienst legt für jedes Zustellungsziel eine separate Warteschlange an. Dies ist der Grund, warum Sie immer eine unterschiedliche Anzahl an Warteschlangen auf einem Exchange Server sehen. Die Warteschlangen gliedern sich in unterschiedliche Kategorien:
Zur Speicherung der Warteschlangen verwendet der Transportdienst auf jedem Exchange Server eine eigene Datenbank. In dieser Datenbank werden alle Nachrichten mit ihrem jeweiligen Verarbeitungs- und Zustellungsstatus gespeichert. Der Transportdienst kümmert sich eigenständig um den Funktionsstatus der Datenbank. Kommt es zu einem nicht behebbaren Fehler, wir eine komplett neue Datenbank erstellt und die korrupte Datenbank in einen neuen Ordner verschoben.
Das folgende Schaubild zeigt die Hauptkomponenten zur Verarbeitung von E-Mail-Nachrichten im Exchange Transportdienst.
Leider steht uns für die aktuelle Version Exchange Server kein detailliertes Diagramm des Transportdienstes offiziell zur Verfügung. Im Microsoft Download Center steht das Diagramm von Exchange Server 2010 zur Verfügung und bietet einen guten konzeptionellen Überblick über den Transportdienst. Achten Sie auf die Unterschiede zu modernen Exchange Server Versionen.
Anwender leben in der Illusion, dass die Zustellung von E-Mail-Nachrichten eine einfache Sache ist und haben meist kein Verständnis für eine verzögerte Zustellung von Nachrichten. In Zeiten von Gigabit-Leitungen und schier unerschöpflicher Computer-Ressourcen hat man sich daran gewöhnt, dass Nachrichten nahezu in Echtzeit übertragen werden.
Einen wesentlichen Beitrag zu einer schnellen und fehlerfreien Verarbeitung leistet das korrekte Routing einer E-Mail-Nachricht. Damit eine Nachricht von Exchange Server fehlerfrei verarbeitet und zugestellt werden kann, ist eine fehlerfreie Active Directory Gesamtstruktur unerlässlich. Die im Exchange Transportdienst aktiven Routing-Agenten arbeiten mit den Informationen, die im Active Directory gespeichert sind. Dies sind u.a.:
Beim Routing einer Nachricht spielt auch die Nachrichtengröße eine Rolle. Exchange zieht mehrere Konfigurationen zu maximalen Nachrichtengröße in Betracht, um so zu bewerten, ob die Nachricht auch wirklich zugestellt werden kann. Kann eine Nachricht nicht zugestellt werden, erhält der Absender einen sog. Non-Delivery Report (NDR). Der Transportdienst betrachtet für die Ermittlung der erlaubten Nachrichtengröße die Konfigurationen auf Organisationsebene, die aller Sende- und Empfangskonnektoren der internen Verbindungsstrecke und die Einstellungen des Zielpostfaches.
Sendekonnektoren arbeiten die Nachrichten in den Warteschlangen ab und versuchen das jeweilige Zielsystem mit den Konnektoreinstellungen zu erreichen. Eine korrekte DNS-Namensauflösung ist der Schlüssel zu einer fehlerfreifunktionierenden Exchange Infrastruktur. Die interne Namensauflösung ist selten eine Fehlerquelle. Anderes sieht es aus, wenn es um die DNS-Auflösung externer Domänen geht. Stellen Sie sicher, dass Ihre Exchange Server auch externe Domänen effizient und sicher auflösen können, um einen fehlerfreien Nachrichtenfluss mit externen Empfängern zu gewährleisten.
Kommt es beim Versuch einer Zustellung zu einem Fehler, wird der Fehler in der Warteschlange festgehalten. Im Regelfall erkennen Sie Zustellfehler am Anwachsen einer oder mehrerer Warteschlangen. Die Überwachung der Warteschlangengröße ist unerlässlich für einen stabilen Betrieb der Exchange Organisation.
Bedenken Sie, dass die Datenbank des Transportdienstes im Installationspfad eines Exchange Servers platziert ist. Wenn Ihre Exchange Server eine hohe Anzahl von Nachrichten verarbeiten muss, sollten Sie die Datenbank auf einem separaten und ausreichend dimensionierten Laufwerk platzieren.
Der Exchange Server Nachrichtenfluss ist, wenn man unter die Motorhaube schaut, ein komplexes Gebilde. Mit einem richtig konfigurierten Active Directory sind keine Probleme beim Betrieb von Exchange Server zu erwarten. Die Herausforderungen für den Exchange Nachrichtenfluss beginnen mit der Anpassung der Exchange Konfiguration.
Gerade im Hinblick auf die Konfiguration von zusätzlichen Empfangskonnektoren müssen Sie sich immer fragen, ob Sie einen neuen Konnektor wirklich benötigen. Das Troubleshooting des Exchange Nachrichtenflusses ist nicht schwierig, jedoch zeitaufwendig. Gerade in Exchange Umgebungen, die seit einigen Jahren betrieben werden und mehrere Exchange Versionen gesehen haben, besteht ein Risiko, dass veraltete Einträge in der Konfigurationspartition den Betrieb stören. Gleiches gilt für die Exchange Empfängerobjekte. Eine regelmäßige Pflege vermeidet Störungen im Nachrichtenfluss.
Der tägliche Betrieb Ihrer Exchange Organisation wird durch ein proaktives Monitoring, in dem nicht nur der Nachrichtenfluss überwacht wird, einfacher. Neben der Überwachung der Warteschlangen, empfehle ich auch die Überwachung der Transportdienste selbst. Exchange Server verfügt mit der Funktion der Managed Availability zwar über eine integrierte Monitoring Lösung mit automatischen Recovery-Aktionen, jedoch möchten Sie sicher nicht von automatisch neustartenden Diensten überrascht werden.
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.
Im ersten Teil der Serie haben ich einen Überblick über das Zusammenspiel der Teams Backend Services mit lokalen Exchange Organisationen vorstellt. Der zweite Teil der Serie beschreibt, wie die Teams Backend Services die lokale Exchange Organisation per AutoDiscover finden und welche Möglichkeiten Sie haben, um Fehlerquellen zu isolieren, sollte es bei diesem Prozess und dem Zugriff der Kalender-App zu Problemen kommen.
Dieser dritte Teil befasst sich mit Kalender-Stellvertretungen für Teams-Meetings und dem kalenderbasierten Präsenzstatus.
Zum Themenkomplex möglicher Verbindungsprobleme zwischen den Microsoft Backend Services und Exchange Server finden Sie zusätzliche Information in der Microsoft Online Dokumentation.
Der Microsoft Teams Client stellt Ihnen nur den persönlichen Kalender zur Verfügung, um Besprechungen oder Live-Meetings zu planen. Wenn ein Stellvertreter eine Team-Besprechung in meinem Namen in meinem Kalender erstellen soll, muss diese Besprechung über Outlook für Desktop geplant werden. Die Planung einer neuen Teams-Besprechung ist nur möglich, wenn das Microsoft Teams AddIn im Outlook Client des Stellvertreters geladen ist.
Eine weitere wichtige Voraussetzung ist, dass die Stellvertreterberechtigung über den Outlook-Einrichtungsassistenten für Stellvertretungen erfolgt ist. Eine direkte Berechtigung auf dem Postfachordner Kalender ist nicht ausreichend.
Die Erstellung einer neuen Teams-Besprechung durch einen Stellvertreter in Outlook mit einem Postfach in der lokalen Exchange Organisation nutzt ebenfalls den Exchange Web Services Endpunkt.
Hierbei werden folgende Schritte durchlaufen:
/EWS
Kommt es zu Problemen bei der Erstellung einer neuen Teams-Besprechungseinladung als Stellvertreter, können Sie folgende Punkte prüfen:
Eine weitere Fehlerquelle für den Zugriff auf Exchange Server Endpunkte sind Zugriffsfilterungen auf Basis des User Agent Strings. Wenn Sie Layer 7 Netzwerkgeräte einsetzen, die solche Filterungen durchführen, konfigurieren Sie diese für Bypass.
Im zweiten Teil der Artikelserie haben Sie die detaillierten Schritte für die Fehlersuche in den Exchange Server Protokolldateien kennengelernt. Nutzen Sie für das Troubleshooting der Kalenderstellvertretungen die gleiche Vorgehensweise.
Microsoft Teams kann den Präsenzstatus auf Basis von Kalenderinformationen im persönlichen Postfach auf „In einer Besprechung“ setzen. Bei der Nutzung eines lokalen Exchange Server Postfaches sind dieser Funktionen jedoch Grenzen gesetzt.
Der Microsoft Teams Client fragt den Präsenzstatus alle sechs Minuten beim Präsenzdienst im Teams Backend ab. Eine Exchange Kalenderabfrage kann in zwei unterschiedlichen Modi erfolgen:
Im Zusammenspiel mit Exchange Server ist nur der Pull-Modus unterstützt.
Im Gegensatz zu den bisher beschriebenen Zugriffsarten, erfolgt der Zugriff durch den Präsenzdienst per REST-Protokoll statt. Hierbei werden folgende Schritt durchlaufen:
Die Möglichkeiten zur Fehleranalyse gleichen auch hier den Möglichkeiten, die Sie bereits bei AutoDiscover und dem Kalenderzugriff kennengelernt haben:
$exinstall\FrontEnd\HttpProxy\rest\web.config <httpRuntime maxRequestLength="2097151" maxUrlLength="2048" maxQueryStringLength="4096" requestPathInvalidCharacters="<,>,*,%,\,?" requestValidationMode="2.0" />
Wie auch bei den Kalenderstellvertretungen , sind auch beim Präsenzstatus Zugriffsfilterungen auf Basis des User Agent Strings eine Fehlerquelle. Wenn Sie Layer 7 Netzwerkgeräte einsetzen, um Zugriffe auf den REST-Endpunkt zu filtern, so konfigurieren Sie diese für Bypass oder entfernen diese aus dem Zugriffspfad.
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.
https://outlook.office365.com/autodiscover/autodiscover.json?Email=John.Doe@varunagroup.de&Protocol=EWS
https://outlook.office365.com/EWS/Exchange.asmx
autodiscover.varunagroup.de
https://autodiscover.varunagroup.de/autodiscover/autodiscover.json?Email=John.Doe@varunagroup.de&Protocol=EWS
{"Protocol":"EWS","Url":"https://mail.varunagroup.de/EWS/Exchange.asmx"}
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:
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.
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:
https://exch01.varunagroup.local/EWS/Exchange.asmx
https://mail.apac.varunagroup.de/EWS/Exchange.asmx
https://mail.emea.varunagroup.de/EWS/Exchange.asmx
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.
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:
Das Thema "ungünstiger Exchange Server Implementierungen" scheint in seiner Vielfalt unerschöpflich. Leider ist Exchange Server, auch in der aktuellen Version 2019, ein sehr tolerantes Produkt, wenn es um die Installation und den Erstbetrieb geht. Die eigentlichen Probleme und Fehler einer schlechten Exchange Server Implementierung treten erst nach einer gewissen Betriebszeit in Erscheinung. Ähnlich sieht es aus, wenn nach einer IT-Störung notwendige Wiederherstellungsschritte ausgelassen oder unbedacht ausgeführt werden.
Heute möchte ich mit Ihnen folgendes Beispiel teilen, bei dem einige Informationen auf Annahmen basieren, da von Kundenseite nicht alle Fragen beantwortet wurden bzw. beantwortet werden konnten.
In der lokal installierten Exchange Server Plattform treten Performance-Probleme mit der Nachrichtenzustellung im Outlook-Client auf. Nach Aussage des Kunden erfolgt die Zustellung eingehener Nachrichten mit einer bis zu 60-minütigen Verzögerung.
Diese Beschreibung erscheint auf den ersten Blick auf einen einfach zu lösenden Fehler hinzudeuten. Bei genauer Betrachtung zeigt sich aber, dass es sich um ein schwerwiegendes Problem innerhalb der Exchange Server-Plattform handelt.
Im Vorfeld wurde, so die Aussage des Kunden, die IT-Infrastruktur durch eine Krypto-Attacke kompromittiert. Im Rahmen der ausgeführten Wiederherstellungsmassnahmen wurde, so der Anschein, ein Domain Controller auf einen älteren Stand zurückgesetzt. Zu dieser Maßnahme fehlen leider detaillierte Informationen.
Laut Active Directory Konfigurationspartition besteht die Exchange Server Organisation aus insgesamt 11 Exchange Server Systemen, die sich wie folgt aufteilen:
In der Realität der Serverlandschaft in der lokalen IT-Infrastruktur sieht es allerdings anders aus:
Die Ressourcen der aktuell betriebenen beiden Exchange Server 2016 Systeme:
Weitere Fakten:
In der beschriebene Exchange Server Plattform kommen unterschiedliche Probleme zusammen. Das beschriebene Fehlerbild der verzögerten Nachrichtenzustellung hängt weniger mit der eklatante Fehlkonfiguration der Exchange Organisation zusammen, als mit dem schlechten Aufbau der IT-Hardware. Hier kommen mehrere Punkte zusammen:
Die Probleme hinsichtlich der Leistungsdefizite der beiden Exchange Server 2016 Systeme hätten bereits im Vorfeld mit einer einfachen Systemüberwachung des Betriebssystems erkannt werden können. Bei der Konfiguration des Arbeitsspeicher für die Systeme standen die Einschränkungen der Hypervisor-Hostsysteme im Vordergrund. Die realen Anforderungen von Betriebssystem, Exchange Server 2016, Endpunkt-Sicherheitslösung und anderer installierter Komponenten, fanden keinen Anwendung. Insbesondere wurden auch die internen Anforderungen von Exchange Server 2016 beim Betrieb einer DAG, in Kombination mit der Managed Availability, nicht berücksichtigt.
Mit dieser Hardware-Konfiguration kann der Programmcode von Exchange Server nicht korrekt arbeiten. Die im Verhältnis recht hohe Zahl an vorhandenen Prozessorkernen führt nicht zu einer Beschleunigung von Exchange Server. Da gleichzeitig nicht genug freier Arbeitsspeicher zur Verfügung steht und die Disk I/O-Leistung zu gering ist, kommt es zwangsläufig zu einer verzögerten Ausführung des Codes und damit automatisch zu einer verzögerten Verarbeitung von Nachrichten.
Für diese Hardware-Plattform sind zu viele iSCSI-Volumes in Betrieb und zu viele Postfachdatenbanken je Server eingebunden. Bei 40 Datenbanken mit je einer aktiven und einer passiven Kopie werden insgesamt 80 Datenbankkopien auf den iSCSI-Zielen betrieben. Trotz der starken Reduzierung der Disk I/O-Anforderungen in Exchange Server 2016, im Vergleich zu den Vorversionen, kann ein iSCSI-NAS die permanent erforderliche Leistung nicht liefern. Für ein Caching von Postfachinformationen steht nicht genug Arbeitsspeicher zur Verfügung. Exchange Server muss die Daten direkt auf Disk schreiben, um die Daten sicher zu persistieren.
Die fehlerhafte Konfiguration der Exchange Organisation im Active Directory trägt ihren ganz eigenen Teil zu den Problemen bei. Diese Konfiguration wird von allen Exchange Servern gelesen und für weitere Aktionen verwendet. Einige dieser Aktionen, die jeder einzelne, in Betrieb befindliche, Exchange Server durchführt, sind:
Exchange Server besteht aus viel mehr als nur der Verarbeitung von individuellen eingehende und ausgehenden Nachrichten. Die Funktion der Managed Availability nimmt einen nicht unerheblichen Teil des Leistungsbedarfs eines Exchange Servers in Anspruch. Exchange Server ist dafür ausgelegt, eine hochverfügbare Messaging-Plattform bereitzustellen. Hierzu dienen all die Funktionen, die unter der Haube ablaufen. Neben den Anforderungen an die Systemleistung von CPU und Arbeitsspeicher, schreiben alle Exchange Server Komponenten Protokolldateien auf Disk. Dies wird gerne ebenfalls vernachlässigt.
Die in der Active Directory Konfigurationspartition vorhandenen Exchange Server 2010 Systeme sind als Computerobjekte nicht mehr vorhanden. Dies deutet darauf hin, dass die Wiederherstellung der authoritativen AD-Datensicherung Ursache des Fehlers ist. Alternativ ist es auch möglich, dass diese Situation durch eine "Ad-Hoc-Deinstallation" von Exchange Server aus dem Active Directory eingetreten ist. Unter einer "Ad-Hoc-Deinstallation" versteht man das unmittelbare Löschen des AD-Computerobjektes eines Servers, auf dem Exchange Server installiert ist. Diese Art der "Deinstallation" von Exchange Server führt automatisch zu verwaisten Einträgen in der Konfigurationspartition und damit zu Folgeproblemen beim Betrieb der Exchange Organisation.
Führen Sie unter keinen Umständen eine "Ad-Hoc-Deinstallation" von Exchange Server durch.
Die Fehlersituation in der Exchange Server-Plattform bei diesem Kunden ist noch nicht abschließend gelöst. Die optimale Lösung erfordert zum einen die Bereinigung des Active Directory und zum anderen einen Umbau der Exchange Server Infrastruktur. Dies ist jedoch mit Investitionen verbunden.
Dieses Beispiel ist eine Ergänzung zu den in meinem Buch "Exchange Server 2019 - Das Handbuch für Administratoren" beschriebenen Beispielen ungünstiger Exchange Server Implementierungen.
Ich wünsche Ihnen viel Spaß und gute Laune mit Exchange Server.
Image by Pexels