Teams Kalender

Wenn ihre Teams-Betriebsart "TeamsOnly" oder "SfBwithCollabandMeeting" ist, dann nutzen sie Microsoft Teams für Meetings. Sie können dann mit Teams auch Besprechungen Planen und einladen. Das funktioniert sogar mit Exchange On-Premises Postfächern, wenn einige Voraussetzungen erfüllt sind.

Kalender in Teams

Wenn Sie alles richtig eingestellt haben und ihr Postfach von Teams erreichbar ist, dann sehen Sie in der Leiste in Teams den "Kalender" und auch die anstehenden Termine:

Was dabei im Hintergrund passiert und wie Sie Fehler und Probleme ermitteln und beheben können, beschreibe ich hier.

Teams Client, Server und das Postfach

Bis auf dem Client der Kalender angezeigt wird und sie einen Termin planen und letztlich in ihrem Exchange Postfach-Kalender ablegen können, sind einige Stationen zu durchlaufen:

Nach meinen Analysen fragen die Teams Services nicht direkt die Exchange Online Services als Proxy, sondern verbinden sich selbst mit dem Exchange Online oder Exchange On-Premises Service.

  • Teams Client zu Backend
    Anders als bei Skype for Business greift der Teams Client nicht direkt auf ihren Exchange Server zu sondern spricht mit dem Teams Backend. Dazu meldet sich der Anwender natürlich mit seinen eigenen Anmeldedaten am Teams Backend an,
  • Teams Services und Autodiscover
    Es ist dann die Aufgabe der Teams Services einen Weg zum Postfach auf einem Exchange Server zu finden. Dazu bedient sich das Teams Backend aber nicht der klassischen Autodiscover-Funktion von Exchange sondern nutzt die neue Autodiscover V2-Variante, bei der eine JSON Antwort zurück kommt.
  • Teams Services und EWS
    Der eigentliche Zugriff von Teams auf das Postfach erfolgt aber noch per EWS (Stand Mai 2020) und noch nicht per Graph, was theoretisch auch möglich wäre (Siehe Graph und Exchange On-Premises) Teams authentifiziert sich dabei als "Microsoft Teams Services" mit der AppID "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe".
  • Exchange FE zum BE
    Der nächste Hop ist dann schon wieder bekannt. Der Exchange Frontend Server sucht zum gewünschten Benutzer den Postfachserver und verbindet sich dann als Proxy mit dem Server. Der Backend Server liefert die Daten über den Frontend an den Teams Service, damit dieser die Daten dann an den Client zur Ansicht sendet.

Dabei kann natürlich einiges daneben gehen. Einige Informationen liefert dabei schon Microsoft selbst.

Voraussetzungen

Meist ist der Fehler schnell gefunden wenn Sie die Voraussetzungen einmal genau lesen und auch verstehen, warum diese notwendig sind. Es ist zugleich eine Checkliste.

Prüfpunkt

Beschreibung

Erfüllt

Teams Mode

Zuerst sollten die die Betriebsart ihres Benutzers prüfen. Nur bei folgenden Betriebsarten blendet Teams überhaupt einen Kalender ein:

  • Island
  • TeamsOnly
  • SfbwithTeamsCollabandMeeting

Bei "SfBOnly" oder "SfBwithTeamsCollab" hingegen wird der Kalender nicht sichtbar.

ADSync Identity

Die Synchronisation der On-Premises Postfächer in die Cloud ist natürlich schon für die spätere Exchange Hybrid-Bereitstellung erforderlich. Aber Teams nutzt die Informationen aus dem AzureAD um die Exchange-Umgebung zu ermitteln. Wenn ein Benutzer ein Postfach in Exchange Online hat, dann gehen die Teams Services direkt dort hin und meines Wissens nicht über Autodiscover.

Wenn es aber im AzureAD gar keine Exchange Informationen gibt, dann gehen die Teams Services davon aus, dass der Benutzer kein Postfach hat. Prüfen Sie daher ihre ADSync-Installation hinsichtlich:

  • Exchange Transformation Rules
    Das ADSync Setup prüft bei der ersten Installation das lokale Schema. Nur wenn zu dem Zeitpunkt schon Exchange On-Premises installiert war, addiert das Setup auch die Exchange Transformations-Regeln. Prüfen Sie das mit dem ADSync Rule Editor. Fehlen die Regeln, dann starten Sie das ADSync Setup noch einmal und aktivieren den Punkt das Directory Schema neu einzulesen. Hier sehen Sie allein die Regeln über "Person"-Objekte bei einem korrekten Setup
  • AD Attribute Filterung
    Manchmal schreibt der Datenschutz vor, dass die bestimmte AD-Felder aus der Synchronisation mit ADSync ausschließen sollen. Die Exchange Properties dürfen sie nicht ausschließen, da ansonsten nicht nur der Exchange Hybrid Mode Probleme bekommt sondern auch Teams.
  • Scope
    Natürlich müssen die Benutzer auch durch ADSync "gefunden" werden. Wenn Sie auf OUs filtern oder die Vererbung von Berechtigungen auf OUs unterbrochen haben, dann könnte das Objekt gar nicht in der Cloud sichtbar sein. Allerdings wäre es dann sehr ungewöhnlich, dass sich der Benutzer überhaupt anmelden könnte.
  • Exchange Hybrid-Checkbox
    Vergessen Sie in den erweiterten Optionen nicht die "Exchange Hybrid Bereitstellung" zu aktivieren.

Exchange Hybrid (OAUTH)

Die Teams Services authentifizieren sich nicht per Benutzername/Kennwort oder mit einem Client-Zertifikat an ihrem On-Premises Exchange Server sondern per OAUTH als Applikation. Exchange On-Premises "vertraut" dieser Application. Dieses Setup macht normalerweise der Exchange Hybrid Configuration Wizard aber manchmal kommt eine Meldung wie:

“HCW has completed, but was not able to perform the OAuth portion of your Hybrid configuration”

Dann sollten Sie prüfen, ob sie den aktuellsten HCW nutzen oder OAUTH manuell einrichten. Der HCW ändert an den lokalen IIS-Verzeichnissen die Anmeldungen. Aber vor allem aktiviert er den Vertrauenseintrag für den evoSTS. Tocken Issuer. Das können Sie auch prüfen.

Get-AuthServer EvoSts

Name      IssuerIdentifier        Realm                   TokenIssuingEndpoint    Enabled
----      ----------------        -----                   --------------------    -------
EvoSts    https://sts.windows.... de21c301-a4ae-4292-a... https://login.window... True

Der Eintrag muss vorhanden und auf "Enabled=True" stehen.

Natürlich muss auch das virtuelle Verzeichnis ein OAUTH aktiviert haben

Get-WebServicesVirtualDirectory | ft server,oauthauthentication -autosize

Server         OAuthAuthentication
------         -------------------
EX2016         True

Skype Hybrid (OAUTH)

Auch Skype for Business Online spielt mit Teams immer noch im Unterbau eine Rolle. Auch hier muss eine Konfiguration erfolgen.

AutodiscoverV2

Ich hatte schon weiter oben geschrieben, dass Teams die AutodiscoverV2-Funktion nutzt. Sie können die Funktion von AutodiscoverV2 sehr einfach mit einem PowerShell-Befehl prüfen, der ihnen die EWS-URL zu einem Postfach liefert. (Hier am Beispiel eines Office 365 Postfachs)

invoke-restmethod https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/User1@uclabor.de?Protocol=EWS

Protocol Url
-------- ---
EWS      https://outlook.office365.com/EWS/Exchange.asmx

Eine Herausforderung ist dies für Firmen, die bisher mit AutodiscoverV1 und der "Redirect-Funktion" z.B. sehr viele Domänen mit einem Zertifikat verwenden. Das ist bei AutdiscoverV2 zumindest mit Teams so nicht vorgesehen. Hier brauchen Sie für jede SMTP-Domäne ein passendes Zertifikat für "autodiscover.<domain". Da viele Namen in einem Zertifikat recht teuer und aufwändig in der Anforderung sind und selbst dann es Limits gibt, könnte eine Lösung mit vielen virtuellen Instanzen und Let's Encrypt-Zertifikaten eine mögliche Option darstellen.

EWS

Der Zugriff der Teams Services erfolgt aktuell per EWS und daher muss ihr Exchange Server per EWS aus dem "Internet" oder zumindest aus dem Teams Datacenter erreichbar sein. eine "Preauthentication" mit einem Benutzername/Kennwort o.ä. ist nicht möglich. Sie können aber aus Sicherheitsgründen natürlich die "anonymen Zugriffe" auf die IP-Adressen von Microsoft beschränken oder andere Firewall-Funktionen oder einen Reverse Proxy einsetzen. So könnte eine gute Firewall z.B. im ApplicationID im Bearer-Token anschauen. Teams identifiziert sich mit der AppID "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe"

Exchange erlaubt auch eine Filterung nach "User Agent" auf Organizationlevel und pro Benutzer:

PS C:\>Get-OrganizationConfig | fl *ews*

EwsEnabled                 :
EwsAllowOutlook            :
EwsAllowMacOutlook         :
EwsAllowEntourage          :
EwsApplicationAccessPolicy :
EwsAllowList               :
EwsBlockList               :


PS C:\>Get-CASMailbox user1@msxfaq.de | fl *ews*

EwsEnabled                 : True
EwsAllowOutlook            :
EwsAllowMacOutlook         :
EwsAllowEntourage          :
EwsApplicationAccessPolicy :
EwsAllowList               :
EwsBlockList               :

Teams kommt mit zwei Useragenten bei ihrem Exchange an:

"MicrosoftNinja/1.0 Teams/1.0 (ExchangeServicesClient/0.0.0.0) SkypeSpaces/1.0a$*+"
"SchedulingService"

 

Exchange 2016CU3+

Das Teams Backend nutzt zwar EWS aber mit erweiterten Funktionen, die Exchange 2013 einfach noch nicht kennt. Maßgeblich ist dabei der Postfachserver und natürlich darf der Frontend auch nicht älter sein. Der Zugriff auf Kalender ist daher nicht möglich, wenn ihr Postfach noch auf Exchange 2013 oder gar Exchange 2016 On-Premises liegt. Es reicht auch nicht einen neueren Frontend Server zu nutzen, da dieser als Reverse-Proxy die Daten nur an den Backend weiter gibt.


Quelle: https://docs.microsoft.com/de-de/microsoftteams/exchange-teams-interact

Wenn Sie nicht mindestens Exchange 2016 CU3+ haben, dann liefert ihr Server einen 500 Fehler mit

App Setup Policies

Der Teams Client folgt zwar keinen Gruppenrichtlinien, lokalen Registry-Einträgen oder INI-Dateien aber bekommt seine Anweisungen über die Teams Richtlinien. Kontrollieren Sie hier einmal die ihrem Benutzer zugewiesenen Einstellungen:

Mit dieser Checkliste sollten Sie letztlich die Ursache finden, wenn Sie keinen Kalender haben.

Fehler mit Exchange 2013

Es gibt mehrere Stelle, an denen Sie die Funktion von Teams mit ihrem On-Premises Server überprüfen können. Auf ihrer Firewall, ReverseProxy bzw. Loadbalancer oder letztlich auch im IISLog des von Exchange Online angesprochenen Exchange Frontend Servers sollten Sie die Anfragen zu AutodisoverV2 und später auch EWS finden. Wenn Sie nicht schon vorher die HTTP-Requests mitschneiden können, dann ist FREB (Siehe IIS - Webserver Troubleshooting) eine Möglichkeit. Hier zeige ich ihnen einen per FREB aufgezeichnete Anfrage, die leider beim Zugriff auf ein Exchange 2013-Postfach mit einem HTTP 500 Fehler abgewiesen wird.

Über den "Compact View" sehen wir dann erst den Header mit dem (hier gekürzten) Bearer Token

Das habe ich erst mal decodiert, siehe Bearer Decoding, und dann die kritischen Teile durch "x" ersetzt. Sie können aber auch so erkennen, welche App hier welche Rechte auf welches Postfach hat.

{
  "aud": "https://ews.msxfaq.net",
  "iss": "https://sts.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/",
  "iat": 1591370546,
  "nbf": 1591370546,
  "exp": 1591378046,
  "acct": 0,
  "acr": "1",
  "aio": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "amr": [
    "pwd"
  ],
  "app_displayname": "Microsoft Teams Services",
  "appid": "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe",
  "appidacr": "2",
  "enfpolids": [],
  "family_name": "User1Nachname",
  "given_name": "User1Vorname",
  "ipaddr": "80.66.216.15",
  "name": "Nachname, Forname",
  "oid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "onprem_sid": "S-1-5-21-xxxxxxxxxx-xxxxxxxxx-xxxxxxxxx-1043",
  "puid": "xxxxxxxxxxxxxxxxx",
  "scp": "Addins.ReadWrite 
          Calendars.ReadWrite 
          Contacts.ReadWrite 
          Directory.Read.Global  
          EWS.AccessAsUser.All  
          Group.ReadWrite.All  
          Mail.ReadWrite  
          Mail.Send  
          MailboxSettings.ReadWrite  
          OfficeIntelligence- 
          Internal.Read  
          SubstrateSearch- 
          Internal.ReadWrite  
          User.ReadWrite",
  "sid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "sub": "xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "tid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "unique_name": "user1@msxfaq.net",
  "upn": "user1@msxfaq.net",
  "uti": "xxxxxx-xxxxxxx",
  "ver": "1.0"
}

Die "Microsoft Teams Services" mit der Appid "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" haben demnach ziemlich viele Rechte und über die Exchange Hybrid Konfiguration wird auch der EvoSTS als "vertrauenswürdiger Aussteller" eingetragen.

Im weiteren Verlauf finden Sie dan auch die XML-Datei mit der EWS-Anfrage nach den Kalenderdaten und nicht nur der "Free/Busy"-Zeiten:

Lassen Sie sich nicht von dem "Erfolgreich" in Zeile 105 irritieren. In Zeile 110 steht hier die Information, dass es ein 500er Fehler ist. Erst weiter unten sehen wir dann auch die EWS Antwort:

Der Fehler "errorinvalidserverversion" beschreibt die Situation, dass hier Teams im Request die Mindestversion "Exchange2015" anfordert und der Exchange 2013 Server damit nicht dienen kann.

Buffer="<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <s:Fault>
      <faultcode xmlns:a="http://schemas.microsoft.com/exchange/services/2006/types">a:ErrorInvalidServerVersion</faultcode>
      <faultstring xml:lang="de-DE">Die angegebene 
Serverversion ist ung%C3%BCltig.</faultstring>
      <detail><e:ResponseCode xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">ErrorInvalidServerVersion</e:ResponseCode>
      <e:Message xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">Die 
angegebene Serverversion ist ung%C3%BCltig.</e:Message>
      </detail>
    </s:Fault>
  </s:Body>
</s:Envelope>"

Ich weiß leider nicht, welche Gründe für diese Mindestversion sprechen, denn die einfache Anfrage nach dem Kalender konnten sogar schon Exchange 2013 und 2010 beantworten. Vermutlich wurde es einfach nicht mit getestet. Damit ist auch der Grund analysiert, warum das Postfach mindestens auf Exchange 2016-Backend Servern liegen muss.

Weitere Fehlersuche

Die "nicht erscheinende Kalender" ist wohl bei vielen Firmen ein Problem und daher hat auch Microsoft neben der offiziellen Dokumentation auch einige Artikel gebloggt, die eine gute Referenz bieten:

Zudem gibt es mittlerweile einen eigenen Analyzer auf https://testconnectivity.microsoft.com/tests/TeamsCalendarMissing/input

Damit wird aus der Cloud z.B. auch geprüft, ob für das Postfach z.B. die OAUTH-Anmeldung verfügbar ist

Weitere Links