Troubleshooting Microsoft Teams und lokale Exchange Postfächer – Teil 2

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=EWShttps://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
  • 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.

Diagramm Teams Backend Services zu Exchange Server Verbindung

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.
    Screenshot Remote Connectivity Analyzer - Teams Kalender Tab Test

  • Prüfen Sie die OAuth-Authentifizierung

Links

Cover Microsoft Exchange Server Handbuch für Administratoren - 2. Auflage
Logo Thomas' Tech & Community Talk Podcast Logo
%d Bloggern gefällt das: