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.

Problem

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:

• Sie haben eine Hybrid Koexistenz-Konfiguration mit Exchange Online, in der Benutzerpostfächer bereits in Exchange Online gehostet werden und die Öffentlichen Ordner noch in der lokalen Exchange Organisation auf Exchange Server 2010 bereitgestellt werden
• Sie haben vor der Migration der Legacy Public Folder zu Exchange Online E-Mail-aktivierte Öffentliche Ordner mit Hilfe des Scriptes Sync-MailPublicFolders.ps1 zu Exchange Online synchronisiert
• Sie haben vor der Migration die E-Mail Aktivierung für alle oder einige Öffentlichen Ordner aufgehoben und diese Änderung mit Hilfe des Scriptes Sync-MailPublicFolders.ps1 zu Exchange Online synchronisiert
• Das Migrationsbatch für die Migration der Legacy Public Folder zu Modern Public Folder ist gestartet

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.

Lösung

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.

Links

• Verwenden der Stapelmigration zum Migrieren von öffentlichen Ordnern einer Vorgängerversion zu Office 365 und Exchange Online
• Download PowerShell Script Sync-MailPublicFolders.ps1

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.

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.

Troubleshooting von Kalender-Stellvertretungen und kalenderbasiertem Präsenzstatus

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.

Troubleshooting Microsoft Teams und Kalender-Stellvertretungen

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:

1. Der Stellvertreter wechselt im eigenen Outlook-Client auf den Kalender des Managers und klickt in der sog. Ribbon-Bar auf "Neue Teams-Besprechung"
   
    
2. Das Teams Addin verbindet stellt eine Verbindung mit den Teams Backend Services her und fordert die Stellvertreterberechtigung des Manager-Postfaches an
    
3. Die Teams Backend Services ermitteln per AutoDiscover V2-Abfrage die EWS-URL
    
4. Die Teams Backend Services stellen eine OAuth authentifizierte Verbindung zum virtuellen Verzeichnis /EWS her
    
5. Die Teams Backend Services senden eine GetDelegate-SOAP-Anfrage für das Teams Meeting im Manager-Postfach
    
6. Exchange Server antwortet mit einer Liste der Stellvertreter und den zugehörigen Berechtigungen
    
7. Die Teams Backend Services antworten dem Teams AddIn mit den Informationen für das neue Teams-Meeting
   
    

Kommt es zu Problemen bei der Erstellung einer neuen Teams-Besprechungseinladung als Stellvertreter, können Sie folgende Punkte prüfen:

• Funktioniert die Teams Kalender-App für das Manager- und Stellvertreter-Postfach fehlerfrei?
   
• Test Sie die Stellvertreterberechtigung mit Hilfe des Remote Connectivity Analyzers
  
  https://go.granikos.eu/2OgCDWe
   
• Führen Sie eine manuelle GetDelegate-Abfrage mit Hilfe eines SOAP-Client, z.B. SOAPe, durch
  • Nehmen Sie wieder Fiddler zu Hilfe, um weitere Informationen des http-Protokolls zu erfassen
     
• Sie erhalten eine Teams Fehlermeldung
  
   
  • Prüfen Sie die Stellvertreterberechtigung, eine direkte Berechtigung auf dem Kalenderordner ist nicht ausreichend
     
• Prüfung der Exchange Protokolldateien und Exchange Einstellungen
  
  • Ist die GetDelegate-Anfrage in den EWS-Protokolldateien vorhanden?
  • Prüfung der IIS Frontend- und EWS-Proxy-Protokolle
  • Prüfung der PartnerApplication-Konfiguration

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.

Troubleshooting Microsoft Teams und kalenderbasierter Präsenzstatus

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:

• Pull-Modus, Abfrage der Kalenderinformationen im 1h-Intervall
• Push-Modus, Abonnement-basierte Abfrage

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:

1. Die Teams Backend Services ermitteln per AutoDiscover V2-Abfrage die REST-URL
2. Die Teams Backend Services stellen eine OAuth authentifizierte Verbindung zum virtuellen Verzeichnis /api her
3. Die Teams Backenend Services versuchen ein Abonnement einzurichten
   1. Hierbei kommt es zu einem RPC-Endpunkt nicht gefunden Fehler
4. Die Teams Backend Services führen als Fallback eine normale Kalenderabfrage durch und geben die Informationen an den Präsenzdienst weiter

Die Möglichkeiten zur Fehleranalyse gleichen auch hier den Möglichkeiten, die Sie bereits bei AutoDiscover und dem Kalenderzugriff kennengelernt haben:

• Ist die richtige API-URL in der AutoDiscover Antwort enthalten und auf dem Internet erreichbar?
  • Hier hilft Ihnen wieder einmal Fiddler
     
• Prüfen die web.config des Frontend REST-Verzeichnisses, wenn Sie die kumulativen Updates für Exchange Server von Dezember 2020 noch nicht installiert haben
  • In der web.config muss das Attribut maxQueryStringLength ergänz werden.

$exinstall\FrontEnd\HttpProxy\rest\web.config

<httpRuntime maxRequestLength="2097151" maxUrlLength="2048" maxQueryStringLength="4096" requestPathInvalidCharacters="<,>,*,%,\,?" requestValidationMode="2.0" />

• Prüfung der IIS Frontend- und REST-Proxy-Protokolle
• Prüfung der REST-Protokolle

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.

Links

• SOAPe Client bei GitHub
• Troubleshooting Microsoft Teams and Exchange Server interaction issues
• Exchange Server Build Numbers and Release Dates

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

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

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. 

Ausgangssituation

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. 

Fakten

Laut Active Directory Konfigurationspartition besteht die Exchange Server Organisation aus insgesamt 11 Exchange Server Systemen, die sich wie folgt aufteilen:

• 6 Exchange Server 2010 SP3
  • 3 Systeme mit Mailbox-Rolle
    30 Postfachdatenbanken
  • 3 Systeme mit kombinierter CAS- und Hub-Transport-Rolle
     
• 5 Exchange Server 2016 mit CU12
  • 2 Systeme mit produktiv eingebunden Postfachdatenbanken in einer DAG mit ca. 40 Postfachdatenbanken
  • 3 Systeme ohne produktiv eingebundene Postfachdatenbanken
     
• 2 konfigurierte Datenbankverfügbarkeitsgruppen (DAG)

In der Realität der Serverlandschaft in der lokalen IT-Infrastruktur sieht es allerdings anders aus:

• Exchange Server 2010 Systeme sind nicht mehr vorhanden
• Keine Aussage, ob Exchange Server 2010 auf diesen sechs Systemen deinstalliert wurde oder ob die Systeme einfach gelöscht wurden
• Migration von Exchange Server 2010 zu Exchange Server 2016 gilt beim Kunden offiziell als abgeschlossen

Die Ressourcen der aktuell betriebenen beiden Exchange Server 2016 Systeme:

• 12 vCores
• 16 GB Arbeitsspeicher
• Bereitstellung des Datenspeichers per iSCSI von einem QNAP NAS

Weitere Fakten:

• Selbstsignierte Exchange Server Zertiifkate für Frontend-Dienste
• Unterschiedliche Konfiguration je Exchange Server
• ~100 Transportregeln mit CC-Ergänzungen für die Zustellung an weitere Mitarbeiter
• Endpunkt-Sicherheitslösung ohne Konfiguration von Exchange Server-Ausnahmen

Fazit

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 Einbindung der Volumes per iSCSI über die allgemeine Netzwerkinfrastruktur führt zu einer schlechten Disk I/O Performance
• Die Nutzung von 40 Exchange-Postfachdatenbanken per iSCSI über den gleichen iSCSI Endpunkt verschlechtert die Disk I/O Performance nochmals
• Das Verhältnis von verfügbarer Prozessorleistung und Arbeitsspeicher der Exchange Server 2016 Systeme ist unüberlegt konfiguriert
• Der Arbeitsspeicher ist für die Einbindung von 40 Postfachdatenbanken viel zu gering
  • Bei einer guten Datenbankverteilung innerhalb der DAG und Einbindung von 20 aktiven Postfachdatenbankkopien je DAG-Mitgliedsserver ist der Arbeitsspeicher bereits zu gering
  • Bei einer Aktivierung aller Datenbankkopien auf einem Exchange Server im Fehlerfall steht nicht ausreichend Arbeitsspeicher zur Verfügung

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:

• Regelmäßiger Test der Kommunikationsverbindungen (http https, etc.) zu den anderen Exchange Servern, die in der Konfiguration der Exchange Organisation vorhanden sind
  • Funktionstest zu anderen Mitgliedsservern der gleichen DAG
  • Funktionstest der Erreichbarkeit von Exchange Servern außerhalb der DAG
• Versand von Test-Nachrichten zwischen allen aktiven Postfachdatenbanken einer DAG
  • Funktionstest der E-Mail-Zustellung
  • Funktionstest der Suchindizierung
  • Funktionstest der Client-Protokolle
• Prüfung auf fehlende Kalendereinträge in jedem Postfach

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.

Links

• Exchange Server Systemanforderungen
• Exchange Server Unterstützungsmatrix
• Exchange Server Architektur

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