Hi zusammen,
wir versuchen den Teams Kalender wieder zu bekommen in unserer Exchange 2016 CU22 Hybrid Umgebung.
Das ganze funktionierte ca 1 Jahr lang, jedoch seit ca. einem Monat nicht mehr.
Als es noch funktionierte, verwendeten wir lediglich Azure AD Synch und hatten den Hybrid Modus nicht aktiv.
Nachdem zu beginn des Problems im O365 Portal einige Teams Probleme gelistet waren begannen wir mit der Fehleranalyse erst später.
Letztendlich kamen wir zu dem Ergebnis, dass nun ein Hybrid Setup erforderlich ist.
Wir richteten Hybrid somit über den HCW ein und stellten sicher das in Azure AD Synch der Hybrid Modus angehakt ist.
Dies alles verlief ohne Fehlermeldung, jedoch bleibt der Kalender verschwunden.
Weitere Fehlersuchen führten uns zu folgenden Informationen, jedoch bisher zu keiner Lösung:
-
Der Test über https://testconnectivity.microsoft.com/tests/TeamsCalendarMissing/input schlägt mit "User mailbox is marked as undiscoverable by Teams middle-tier service." fehl, und der Teams Log zeigt "isMailboxDiscoverable: false"
-
Autodiscoverv2 funktioniert.
-
Oauth test von On-Prem zur Cloud meldet "Success". Befehl in der lokalen Exchange Shell:
Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <On-Premises Mailbox> -Verbose | Format-List
-
Oauth test von Cloud zu On-Prem Schlägt fehl mit "Error:[OAuthCredentials:Authenticate] the authorization header was 'Bearer', but no challenge returned from ' https://something.domain.de/ews/Exchange.asmx '. That url may not support OAuth". Befehl in der Online Exchange Shell:
Test-OAuthConnectivity -Service EWS -TargetUri <external hostname authority of your Exchange On-Premises deployment>/metadata/json/1 -Mailbox <Exchange Online Mailbox> -Verbose | Format-List
Wir hatten bereits einen Call im O365 Support offen, dieser wurde jedoch aufgrund des vermeintlich lokalen Oauth-Fehler geschlossen, mit dem Hinweis, dass sie keinen lokalen Exchange supporten.
Es gab hier lediglich den Versuch die O365 Lizenz neu zuzuordnen, was jedoch nichts bewirkte.
Bezüglich Oauth wird immer wieder auf folgenden Artikel verwiesen, jedoch ist der OrganizationConnector und EvoSTS Server korrekt hinterlegt: https://docs.microsoft.com/en-us/exchange/configure-oauth-authentication-between-exchange-and-exchange-online-organizations-exchange-2013-help
Mittlerweile haben wir diese Einträge auch einmalig entfernt und mit hilfe des Artikels manuell neu angelegt. Hier gab es zwar Unterschiede in einer URL zwischen dem was der HCW erstellt hat und der Artikel vorgibt, jedoch bleibt der Fehler nach wie vor der selbe.
Es scheint als wäre nicht die Oauth Konfiguration sondern etwas anderes das Problem, jedoch fehlt uns bisher ein Hinweis wo wir noch suchen können. Der Ereignislog scheint hier nicht zu helfen.
Anbei noch die ausführliche Fehlermeldung, auch wenn diese eventuell nicht die Quelle des Problems ist:
Test-OAuthConnectivity -Service EWS -TargetUri https://etwas.domain.de/metadata/json/1 -Mailbox onlineuser@domain.de -Verbose | Format-List RunspaceId : dcf1fb31-b726-449d-8afe-cce2XXXXXX Task : Checking EWS API Call Under Oauth Detail : Die Konfiguration wurde zum letzten Mal erfolgreich geladen um 01.01.0001 00:00:00 UTC. Dies war vor 1062863598 Minuten. Der Tokencache wird geleert, weil "zwischengespeichertes Token verwenden" auf "false" festgelegt ist. Oauth-Protokoll für ausgehende Exchange-Nachrichten: Clientanforderungs-ID: 5e66d6f7-31ad-4af5-8d48-d1108XXXXXXX Information:[OAuthCredentials:Authenticate] entering Information:[OAuthCredentials:Authenticate] challenge from 'https://etwas.domain.de/ews/Exchange.asmx' received: Basic realm="etwas.domain.de" Error:[OAuthCredentials:Authenticate] the authorization header was 'Bearer', but no challenge returned from 'https://etwas.domain.de/ews/Exchange.asmx'. That url may not support OAuth Exchange-Antwortdetails: HTTP-Antwortnachricht: Ausnahme: System.Net.WebException: The request was aborted: The request was canceled. ---> Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: The specified url may not support OAuth. at Microsoft.Exchange.Security.OAuth.OAuthCredentials.Authenticate(String challengeString, WebRequest webRequest, Boolean preAuthenticate) at System.Net.AuthenticationManager2.Authenticate(String challenge, WebRequest request, ICredentials credentials) at System.Net.AuthenticationState.AttemptAuthenticate(HttpWebRequest httpWebRequest, ICredentials authInfo) at System.Net.HttpWebRequest.CheckResubmitForAuth() at System.Net.HttpWebRequest.CheckResubmit(Exception& e, Boolean& disableUpload) at System.Net.HttpWebRequest.DoSubmitRequestProcessing(Exception& exception) at System.Net.HttpWebRequest.ProcessResponse() at System.Net.HttpWebRequest.SetResponse(CoreResponseData coreResponseData) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.GetResponse() at Microsoft.Exchange.Monitoring.TestOAuthConnectivityHelper.SendExchangeOAuthRequest(ADUser user, String orgDomain, Uri targetUri, String& diagnosticMessage, Boolean appOnly, Boolean useCachedToken, Boolean reloadConfig) ResultType : Error Identity : Microsoft.Exchange.Security.OAuth.ValidationResultNodeId IsValid : True ObjectState : New
Über jegliche Hilfe wären wir sehr dankbar.
Grüße
Hi zusammen,
wir konnten das Problem lösen. Der Teams Kalender funktioniert, jedoch wird nach wie vor die gleiche Oauth Fehlermeldung ausgeben, offensichtlich ist diese aber nicht relevant.
Wir setzen eine Soniwall SMA mit WAF (Web Application Firewall ein). Die Heuristischen Regeln aktualisieren sich hier automatisiert und ohne ein Update der Appliance selbst. Eine dieser Regeln (Suspicious Authorization Header) hat sich scheinbar aktualisiert und die Zugriffe von O365 blockiert.
Zusätzlich funktionierten die globalen Ausnahmen in der WAF nicht, der Support hat uns hierzu einen Workarround über die Ausnahmen auf der Regel selbst genannt, welcher auch funktioniert.
Herausgefunden haben wir dies durch den Free Busy Test auf https://testconnectivity.microsoft.com, da dort eine detaillierte 401 Fehlermeldung generiert wird mit "Server: SonicWALL SSL-VPN Web Server" im Header.
Grüße