Hybrid Free/Busy Details

Diese Seite beschäftigt sich mit der ein oder anderen Besonderheit, wenn die andere Exchange Organisation im Hybrid-Mode Postfächer in der Cloud oder Exchange On-Premises hat. Mittlerweile akzeptiert Exchange Online tatsächlich einen Redirect mit Autodiscover, wenn Sie denn alles richtig konfiguriert haben.

Diese Seite aktualisiert ein früheres Verhalten von Exchange, welches einem Autodiscover Redirect nicht gefolgt ist. Ich habe bei ExchangeOnine im Mai 2023 das neue Verhalten nachstellen können. Die Aussagen auf Hybrid FreeBusy beschreiben noch das vorherige Verhalten.

Umgebung

Zuerst schauen wir uns wieder die Umgebung für die nächsten Schritte an. Wir haben einen Benutzer in einer Exchange Organisation, der gerne die Frei-Belegt-Zeiten eines Benutzers in einer anderen Exchange Organisation erhalten möchte. Der anfragende Benutzer kann entweder auf Exchange Online oder Exchange On-Premises sein. Letztlich fragt er seinen Exchange Server, der dann versucht die Daten vom Exchange System des anderen Benutzers zu erhalten. Hier kommt dann die Besonderheit dass der anfragende Benutzer eigentlich nur die Mailadresse der anderen Seite kennt aber nicht, ob der andere Benutzer nun On-Premises oder in Exchange Online liegt. Früher mussten wir daher Kontakte mit der korrekten "TargetAddress" anlegen, damit der anfragende Exchange das richtige Ziel angesprochen hat. Das ist nun nicht mehr erforderlich.

Das folgende Bild zeigt insgesamt acht "OrganizationRelationShip"-Einstellungen, die für eine vollständige Funktion erforderlich sind, wenn beide Firmen hybrid arbeiten. Die Pfeile zeigen zwar die beide Richtungen aber das bedeutet nicht, dass die Einstellungen identisch sein müssen, Es kann durchaus sein, dass MSXFAQ.DE von UCLABOR die Frei/Belegt-Zeiten sehen darf aber umgekehrt nicht. Dennoch müssen auf beiden Seiten die OrganizationRelationsship-Einträge vorliegen.

In der Folge beschreibe ich nur eine Anfrage eines Benutzers in MSXFAQ.DE, der die Frei/Belegt-Zeiten eines Benutzers in UCLABOR.DE erhalten möchte. Die Gegenrichtung ist ja nur die Umkehrung der Zugriffe. Denken Sie daran, dass eine OrganizationRelationship sowohl steuert, welche anderen Domain ein Benutzer ausgehend anfragen kann als auch, welche andere Domain umgekehrt eingehend die Information abrufen können. Hier ist wichtig, die richtige Domain zu hinterlegen, die auf die richtige Zielumgebung verweist.

Hier sehen Sie eine Konfiguration im Tenant "UCLABOR", der nicht nur erlaubt dass Benutzer aus UCLABOR zu MSXFAQ eine Anfrage stellen können und dieses dann an den Exchange Online-Service geht sondern steuert auch, dass Personen aus MSXFAQ sich autorisieren können. Dabei sind zwei Dinge zu beachten.

  • Ausgehende Domain.
    Eine Domain kann immer nur in genau einer OrganizationRelationship verwendet werden. Wenn die andere Seite "hybrid" ist, dann müssen Sie die beiden "onmicrosoft.com"-Domains in einer OrganizationRelationship zu Exchange Online eintragen. Die anderen Domains aber zum On-Premises Server. Das Beispiel hier zeigt das Szenario, wenn die Domain "uclabor.net" kein lokales Postfach hat und immer zur Cloud soll.
  • Eingehende Domain
    Wenn ein anderer Tenant bei ihnen eine Anfrage stellt, dann weist er sich mit der Mailadresse des anfragenden Benutzers aus. Die Domain des anfragenden Benutzers muss in der Liste erscheinen..

Damit das alles funktioniert, muss natürlich alle Exchange Server einen "FederationTrust" zum Microsoft Service eingetragen haben. Das macht der HCW meist automatisch und nur so kann der Exchange Server ein Ticket für den jeweils anderen Server erhalten. Nur so kann sich der anfragende Server korrekt beim angefragten Server authentifizieren.

Wichtig: In dem Anfrage-Request steht eine Mailadresse des anfragenden Benutzers drin. Allerdings gibt es da einen kleinen Unterschied:
On-Premises: Hier ist es die primäre SMTP-Adresse
Online: Hier nutzt Exchange Online nur dann die primäre SMTP-Adresse, wenn der Benutzer keine <userpart>@<tenantname>.mail.onmicrosoft.com hat.

Domains und OrganizationRelationship

Es kann nur eine OrganizationRelationship pro Domain geben und die kann auch nur auf eine AutodiscoverURL ein ApplicationURI verweisen.

Das bedeutet aber auch, dass z.B.: die Neueinrichtung eines Hybridmode eine Aufteilung erfordert und beim Rückbau der lokalen Umgebung sie auch ihre Partner darüber informieren müssen.

Szenarien

In dem Bild haben wir nun vier Szenarien, wobei 1und 3  als auch 2 und 4 im Ablauf identisch sind, denn es macht keinen Unterschied, wo der anfragende Anwender sitzt. Es unterscheidet sich nur seine Mailadresse. Die Online-User kommen mit ihrer mail.onmicrosoft.com-Adresse.

Szenario Anfragender Benutzer Zielpostfach Funktionsweise

1

A: Online:

C: Online

Exchange Online Server A besorgt sich ein OAUTH Ticket als User A und fragt per Autodiscover den passenden Server. Bei einer Hybrid-Bereitstellung verweist msxfaq.de auf die OnPremise-Umgebung und Server D bekommt die Anfrage. Server D erkennt die "Remote Mailbox" und sendet einen Redirect auf die <userpart>@<tenantname>.mail.onmicrosoft.com. Server A stellt dann neue neue Anfrage für die Zieldomain an Exchange Online Server C.

2

A: Online:

D: OnPrem

Exchange Online Server A besorgt sich ein OAUTH Ticket als User A und fragt per Autodiscover den passenden Server. Bei einer Hybrid-Bereitstellung verweist msxfaq.de auf die OnPremise-Umgebung und Server D bekommt die Anfrage und beantwortet die Anfrage.

3

B: OnPrem

C: Online

Exchange Online Server A besorgt sich ein OAUTH Ticket als User A und fragt per Autodiscover den passenden Server. Bei einer Hybrid-Bereitstellung verweist msxfaq.de auf die OnPremise-Umgebung und Server D bekommt die Anfrage. Server D erkennt die "Remote Mailbox" und sendet einen Redirect auf die <userpart>@<tenantname>.mail.onmicrosoft.com. Server A stellt dann neue neue Anfrage für die Zieldomain an Exchange Online Server C.

4

B: OnPrem

D: OnPrem

Exchange Online Server A besorgt sich ein OAUTH Ticket als User A und fragt per Autodiscover den passenden Server. Bei einer Hybrid-Bereitstellung verweist msxfaq.de auf die OnPremise-Umgebung und Server D bekommt die Anfrage und beantwortet die Anfrage.

Bei der Auswahl der Zieladresse ist Exchange unkritisch. Sie können auch eine sekundäre Adresse ansprechen. Wenn das Postfach in Exchange Online ist, dann leitet Exchange On-Premises eine Anfrage natürlich auch die <userpart>@<tenantname>.mail.onmicrosoft.com um.

Es ist bei einer Hybrid-Umgebung absolut essentiell, dass die Benutzer auch eine <userpart>@<tenantname>.mail.onmicrosoft.com-Adresse haben. Ansonsten kann der lokale Exchange Server keine Umleitung senden, der Exchange Online Server den anfragenden Benutzer nicht verifizieren.

Einrichtung und Fehler

Bei der Konfiguration einer solchen Umgebung laufen Sie natürlich auf diverse Fehler. Ich habe mit zwei Tenants ohne Eintragungen gestartet und habe nach und nach die OrganizationRelationships addiert, die Replikation abgewartet und immer wieder wieder eine Abfrage versucht. Bei der Analyse der Fehler gibt es zwei Optionen, da ja alles per HTTPS verschlüssel ist:

  • Client-Analyse
    Viele Administratoren wissen nicht, dass Exchange Server sehr wohl aussagekräftige Fehlermeldungen in der HTTP-Antwort an den Client liefern. Leider zeigen aber weder Outlook noch OWA diese einfach an. Outlook kann diese in einen ETL-Trace schreiben, den sie aber nicht lesen können. Also bleibt nur Fiddler o.ä. um die Meldungen zu sehen. Einfacher ist es daher meist per Browser in Outlook WebApp zu arbeiten und mit dem Browser Debugger (F12) den Netzwerkverkehr nachzuschauen.
  • Server-Analyse
    Wenn das Zielsystem ein Exchange On-Premises Server ist, dann können Sie z.B. mittels IIS - Webserver Troubleshooting einen FREB-Trace ziehen und so die Anfrage an den Server und Rückantwort analysieren.

Ich habe beide Methoden für die folgenden Mitschnitte genutzt.

Start ohne Konfiguration

Zuerst habe ich einfach mit einem Benutzer user@msxfaq.de einen Termin geplant und einen user1@uclabor.de eingeladen. Natürlich habe ich keine Frei/Belegt-Zeiten gesehen, denn weder in der Quelle noch im Ziel war eine OrganizationRelationship konfiguriert worden.

"error": {
"message": "GetSchedule is not supported for domain: uclabor.de. 43190",
"responseCode": "7002",
"diagnosticData": "CalculatedRequestType:None;LID:43190;FailureMessage:GetSchedule is not supported for domain: uclabor.de. 43190;ResponseCode:7002;"
}

Im OWA-Trace des anfragenden Benutzers ist auch zu sehen, dass die Domain nicht freigeschaltet ist. Der Administrator in der Quelle muss also erst etwas konfigurieren

Admin trägt „uclabor.de“ ein

DAs hat er dann nachgeholt und verweist auf den "On-Premises"-Server für uclabor.de. Das ist der normale Weg, wenn die Zielumgebung im Hybrid-Mode ist. Die Konfiguration enthält also

Domain: uclabor.de
AnwendungsURI: FYDIBOHF25SPDLT.uclabor.de
Autodiscover Endpunkt: https://autodiscover.uclabor.de/autodiscover/autodiscover.svc/WSSecurity

Der Benutzer user@msxfaq.de hat erneut einen Termin geplant und einen Benutzer aus der Domain "uclabor.de" addiert.

Hinweis: Um Probleme mit negativem Caching auszuschließen, habe ich für jede Anfrage immer ein neues Postfach in uclabor.de genutzt

Diesmal hat sich der Fehler verändert.

"error": {
"message": "Autodiscover failed for email address user2@uclabor.de with error 
            Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverInvalidUserException: 
            The response from the Autodiscover service at \u0027https://autodiscover.uclabor.de/autodiscover/autodiscover.svc/WSSecurity\u0027 
            failed due to an error in user setting \u0027ExternalEwsUrl\u0027. 
            Error message: InvalidUser.\r\n. Name of the server where exception originated: GV2PR08MB8050. LID: 33676.",
"responseCode": "5039",
"diagnosticData": ""
}

Der Zielserver wurde nun angesprochen aber liefert einen "InvalidUser" zurück. Das stimmt so natürlich nicht, denn entweder wäre es ein On-Premises Postfach oder eine RemoteMailbox gewesen. Ich habe mit FREB auf dem On-Premises Server D nachgeschaut und folgenden Zugriff gesehen (Auszug)

HeaderValue="X-BackEndCookie=user@msxfaq.mail.onmicrosoft.com

<soap:Body>
<GetUserSettingsRequestMessage xmlns="http://schemas.microsoft.com/exchange/2010/Autodiscover">
  <Request>
    <Users>
      <User>
        <Mailbox>user2@uclabor.de</Mailbox>
      </User>
     </Users>
     <RequestedSettings>
       <Setting>ExternalEwsUrl</Setting>
       <Setting>ExternalEwsVersion</Setting>
       <Setting>InteropExternalEwsUrl</Setting>
       <Setting>MailboxVersion</Setting>
    </RequestedSettings>
    <RequestedVersion>Exchange2010</RequestedVersion>
  </Request>
</GetUserSettingsRequestMessage>
</soap:Body>
</soap:Envelope>"

Hier ist nicht nur ersichtlich, für welche Mailbox der Server die Frage stellt, sondern auch der Anfragende Benutzer. Nun hat mein Benutzer in der Quelle ein Exchange Online Postfach mit der Mailadresse user@msxfaq.de. Allerdings kommt Microsoft Exchange Online hier mit der mail.onmicrosoft.com-Adresse an. Der Server liefert als HTTP-Fehler im Trace zurück, was sie weiter oben in OWA schon gesehen haben. (Auszug)

<a href="https://autodiscover.uclabor.de:443/autodiscover/autodiscover.svc/WSSecurity" 
   title="https://autodiscover.uclabor.de/autodiscover/autodiscover.svc/wssecurity" 
   target="_blank" 
   rel="noreferrer noopener">https://autodiscover.uclabor.de:443/autodiscover/autodiscover.svc/WSSecurity</a>,
 STATUS_CODE 200, 344>
<ErrorCode>NoError</ErrorCode>
<ErrorMessage/>
<UserResponses>
  <UserResponse>
    <ErrorCode>InvalidUser</ErrorCode>
    <ErrorMessage>Invalid user 'user2@uclabor.de' specified. </ErrorMessage>
    <RedirectTarget i:nil="true"/>
    <UserSettingErrors/>
    <UserSettings/>
  </UserResponse>
</UserResponses></Response></GetUserSettingsResponseMessage>

Damit der Zielserver überhaupt eine Rückmeldung liefert, muss er eine OrganizationRelationship für die anfragende Domain habe. Dies ist hier aber nicht die "msxfaq.de" sondern eine msxfaq.mail.onmicrosoft.com

Zieladmin On-Premises addiert Quelle onmicrosoft.com als Partner

Diese fehlende Konfiguration habe ich im Ziel dann nachgeholt. und den Request gestartet. Nun sehe ich beim gleichen Request auf dem Exchange On-Premises Server eine erfolgreiche Rückmeldung. Die Autodiscover-Anfrage liefert bei einer Remote-Mailbox sogar die TargetAddress.

<xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<ErrorCode>NoError</ErrorCode>
<ErrorMessage/>
<UserResponses>
  <UserResponse>
    <ErrorCode>RedirectAddress</ErrorCode>
    <ErrorMessage>Redirection address.</ErrorMessage>
    <RedirectTarget>user3@uclabor.mail.onmicrosoft.com</RedirectTarget>
    <UserSettingErrors/>
    <UserSettings/>
  </UserResponse>
</UserResponses></Response></GetUserSettingsResponseMessage></s:Body></s:Envelope>"

Diese Meldung sehe ich auf dem anfragenden Client nicht aber ich sehe eine andere aufschlussreiche Fehlermeldung:

"message": "Configuration information for forest/domain uclabor.mail.onmicrosoft.com could not be found in Active Directory.",
"responseCode": "5039",
"diagnosticData": ""

Der Exchange Server 2016 Server der Quelle hat den Redirect verstanden und wollte dieser nun folgen. Allerdings konnte er da nicht, da der Administrator in der Quelle diese Domain noch nicht eingerichtet hatte.

Addiere uclabor.onmicrosoft.com in der Quelle

Nun sollte der Server in MSXFAQ auch die Anfragen an die Exchange Online Instanz von UCLABOR starten. Die Einrichtung braucht etwas länger, da Exchange mit dem Microsoft Federation Services kommuniziert und so auch andere Domains ermittelt, die damit verknüpft sind. Am Ende wurde dann folgender Eintrag addiert:

Domains: uclabor.mail.onmicrosoft.com
Domains: uclabor.onmicrosoft.com
Anwendungsurl: “outlook.com”
AutoD Endpunkt https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity

Beachten Sie, dass hier die "uclabor.de" nicht aufgelistet, wird, da diese ja bei einer Hybrid-Konfiguration im Ziel weiter auf den On-Premises Server verweist und eine Domain immer nur genau ein Zielsystem haben kann. Ich stelle die Anfrage an einen Benutzer "user3@uclabor.de" aber da ich auf Exchange Online natürlich keine IIS-Tracing nutzen kann, bleibt nur nur die Diagnose auf dem Client. Dort finde ich dann auszugsweise:

"error": {
"message": "Autodiscover failed for email address user3@uclabor.mail.onmicrosoft.com with error 
     System.Web.Services.Protocols.SoapHeaderException: An error occurred when verifying security for the message.\r\n 
  at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)\r\n 
  at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)\r\n 
  at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult)\r\n
  at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.\u003C\u003Ec__DisplayClass48_0.\u003CEndInvoke\u003Eb__0()\r\n
  at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation).",
"responseCode": "5039",
"diagnosticData": ""
},

Wenn Sie das bisher gelernte verstanden haben, dann sind die Schritte bis hier schnell erzählt:

  1. Server A oder B fragt Server D, der für uclabor.de zuständig ist
  2. Server D prüft die Anfrage, findet die OrganizationRelationship und sendet eine Umleitung auf user3@uclabor.mmail.onmicrosoft.com
  3. Server A stellt dann die Anfrage an Server C, der für uclabor.mmail.onmicrosoft.com zuständig ist
  4. Server C verweigert die Auskunft, da es dort noch keine OrganizationRelationship  für die Quelle gibt.

Damit ist klar, welche Konfiguration hier noch fehlt:

Addieren der Quelle in Zielcloud als OrgRelationship

Nachdem ich nun in Exchange Online von uclabor.de auch noch eingetragen haben, dass msxfaq.mail.onmicrosoft.com eine OrganizationRelationship hat, konnte ich die Frei/Belegt-Zeiten endlich sehen. Da die OrganizationRelationship aber nicht nur die Behandlung eingehender Anfragen steuert, sondern seinerseits auch die Gegenrichtung kontrolliert, müssen Sie eventuell zwei OrganizationRelationship-Einträge konfigurieren. Wenn die Quelle ebenfalls "Hybrid" ist, dann muss der Eintrag für die Firmendomain "msxfaq.de" auf den Server B verweisen und die Exchange Online Domain "msxfaq.mail.onmicrosoft.com" eine eigene OrganizationRelationship sein.

Nachdem all diese Einstellungen nach einigen Minuten auch gewirkt haben, konnte user@msxfaq.de endlich die Frei/Belegt-Zeiten der Anwender bei UCLABOR.DE abfragen.

Erfolgreiche Anfrage

 Dann sehen Sie natürlich keine Fehlermeldung mehr sondern eine korrekte Rückgabe in der Form. OWA stellt dazu einen Request an folgende URL:

POST https://outlook.office.com/outlookgatewayb2/graphql?n=162&cv=xxxxxxx

Die Authorization erfolgt per Bearer im Header per OAUTH-Token (gekürzt(

{
  "typ": "JWT",
  "nonce": "xxx",
  "alg": "RS256",
  "x5t": "-xxx",
  "kid": "-xxx"
}.{
  "aud": "https://outlook.office.com",
  "iss": "https://sts.windows.net/22991c1b-aa70-4d9c-85be-637908be565f/",
  "acct": 0,
  "acr": "1",
  "aio": "xxxxxx",
  "amr": [
    "pwd",
    "mfa"
  ],
  "app_displayname": "Office 365 Exchange Online",
  "appid": "00000002-0000-0ff1-ce00-000000000000",
  "appidacr": "2",
  "auth_time": 1683993232,
  "enfpolids": [],
  "family_name": "Nachname",
  "given_name": "Vorname",
  "ipaddr": "2a00:6020:4e92:e200:1532:681d:4db2:b052",
  "name": "Nachname, Vorname (User)",
  "oid": "54aedb0f-5161-423b-8950-3ec0628d00cd",
  "onprem_sid": "S-1-5-21-xxxxx-xxxx-xxxx-xxxx",
  "puid": "xxxxx",
  "rh": "0.AToAGxyZInCqnE2FvmN5CL5WXwIAAAAAAPEPzgAAAAAAAAA6AJ0.",
  "scp": "Calendars.ReadWrite DWEngine-Internal.Read EAS.AccessAsUser.All 
          Files.Read Files.ReadWrite Files.ReadWrite.All Files.ReadWrite.Shared 
          Locations-Internal.ReadWrite 
          Mail.ReadWrite MailboxSettings.ReadWrite 
          Notes.ReadWrite Notes-Internal.ReadWrite 
          OfficeFeed-Internal.ReadWrite OWA.AccessAsUser.All 
          PeoplePredictions-Internal.Read Premium-Internal.ReadWrite 
          SubstrateSearch-Internal.ReadWrite TailoredExperiences-Internal.ReadWrite 
          Todo-Internal.ReadWrite 
          User.Read.All 
          user_impersonation",
  "tid": "22991c1b-aa70-4d9c-85be-637908be565f",
  "unique_name": "user@mxsfaq.de",
  "upn": "user@msxfaq.de",
  "ver": "1.0",
  "wids": ["b79fbf4d-3ef9-4689-8143-76b194e85509"]
}.[Signature]

Die Payload des HTTP-POST enthält dann die JSON-Struktur mit den angeforderten Informationen:

[
  {
    "operationName": "GetSchedule",
    "variables": {
      "input": {
        "userId": "user@msxfaq.de",
        "availabilityViewInterval": 15,
        "endTime": {
          "dateTime": "2023-06-08T00:00:00.000Z",
          "timeZone": {
            "name": "UTC"
          }
        },
        "schedules": [
          "user4@uclabor.de"
        ],
        "startTime": {
          "dateTime": "2023-05-11T00:00:00.000Z",
          "timeZone": {
            "name": "UTC"
          }
        }
      }
    },
    "query": "query GetSchedule($input: GetScheduleInput) {\n
         getSchedule(request: $input) {\n
           schedules {\n
             availabilityView\n
             error {\n
               message\n
               responseCode\n
               diagnosticData\n
             }\n
             scheduleId\n
             scheduleItems {\n
                isPrivate\n location\n status\n subject\n
                isException\n isReminderSet\n isMeeting\n isRecurring\n id\n
                startTime {\n dateTime\n timeZone {\n name\n }\n }\n
                endTime {\n dateTime\n timeZone {\n name\n }\n }\n
              }\n
              workingHours {\n
                daysOfWeek\n
                startTime\n endTime\n 
                timeZone {\n
                name\n bias\n standardOffset {\n
                time\n dayOccurrence\n dayOfWeek\n month\n year\n 
              }\n
              daylightOffset {\n time\n dayOccurrence\n dayOfWeek\n month\n year\n daylightBias\n }\n
            }\n
          }\n
          flexibleWorkingHours {\n
            start {\n dateTime\n timeZone {\n name\n}\n
            }\n
            end {\n
              dateTime\n timeZone {\n name\n }\n
            }\n
            workLocationType\n  isConfirmed\n workLocationDetails {\n id\n }\n
          }\n
          flexibleWorkingHoursError {\n message\n responseCode\n diagnosticData\n }\n
        }\n
      }\n
    }\n"
  }
]

Die Antwort zum 200OK hat folgende Payload (Auszug)

[
    {
        "data": {
            "getSchedule": {
                "schedules": [
                    {
                        "availabilityView": "222222222222   2688 lange Zahlenkolonne, die wohl den Belegstatus anzeigt    000",
                        "error": null,
                        "scheduleId": "user4@uclabor.de",
                        "scheduleItems": [
                            {
                                "isPrivate": false,
                                "location": "",
                                "status": "Busy",
                                "subject": "",
                                "isException": false,
                                "isReminderSet": false,
                                "isMeeting": false,
                                "isRecurring": false,
                                "id": "",
                                "startTime": {
                                    "dateTime": "2023-05-09T08:00:00Z",
                                    "timeZone": {
                                        "name": "UTC"
                                    }
                                },
                                "endTime": {
                                    "dateTime": "2023-05-11T14:00:00Z",
                                    "timeZone": {
                                        "name": "UTC"
                                    }
                                }
                            },

Anhand der Informationen im "availabilityView" können Outlook und OWA den Frei/Belegt-Status einblenden. Wenn die Gegenseite es erlaubt, kommen natürlich unter "scheduleItems" noch Details zu den Terminen mit.

Secondary Address

Benutzer ändern durch Heirat/Scheidung ihren Namen und damit oft ihre primäre Mailadresse. Wenn eine Firma ihren Namen ändert (Umfirmierung, Kauf, Verkauf etc.), ändert sich auch die Domain. Daher habe ich natürlich auch einmal eine Mailadresse genutzt, die bei der angefragten Seite als sekundäre SMTP-Adresse hinterlegt ist.

"error": {
"message": &"message": "Autodiscover failed for email address secondmail@uclabor.mail.onmicrosoft.com 
             with error System.Web.Services.Protocols.SoapHeaderException: 
             An error occurred when verifying security for the message.\r\n 
             at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)\r\n
             at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)\r\n 
             at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult)\r\n
             at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.\u003C\u003Ec__DisplayClass48_0.\u003CEndInvoke\u003Eb__0()\r\n 
             at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation).",
"cuteAndHandleException(ExecuteAndHandleExceptionDelegate operation).",
"teAndHandleException(ExecuteAndHandleExceptionDelegate operation).",
"ception(ExecuteAndHandleExceptionDelegate operation).",
"ption(ExecuteAndHandleExceptionDelegate operation).",
"eption(ExecuteAndHandleExceptionDelegate operation).",
"eAndHandleExceptionDelegate operation).",
"ndHandleExceptionDelegate operation).",
"AndHandleExceptionDelegate operation).",
"ptionDelegate operation).",
"ionDelegate operation).",
"peration).",
"ration).",
";,
"
"""quot;uot;ot;t;;quot;eption(ExecuteAndHandleExceptionDelegate operation).",
"eption(ExecuteAndHandleExceptionDelegate operation).",
"tion(ExecuteAndHandleExceptionDelegate operation).",
"on(ExecuteAndHandleExceptionDelegate operation).",
"(ExecuteAndHandleExceptionDelegate operation).",
"xecuteAndHandleExceptionDelegate operation).",
"uteAndHandleExceptionDelegate operation).",
"eAndHandleExceptionDelegate operation).",
"",
"diagnosticData": ""
},
"availabilityView": "",
"error": {
"message": "Autodiscover failed for email address Frank.Carius@netatwork.de with error System.Web.Services.Protocols.SoapHeaderException: 
            An error occurred when verifying security for the message.\r\n
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)\r\n
   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)\r\n
   at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult)\r\n
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.\u003C\u003Ec__DisplayClass48_0.\u003CEndInvoke\u003Eb__0()\r\n
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation).",
"responseCode": "5039",
"diagnosticData": ""
},

Sonderfall: Unbekannter Empfänger

Wenn ich als Ziel eine nicht gültige Mailadresse angebe, dann kommt folgendes:

"error": {
"message": "Autodiscover failed for email address unknonw@uclabor.de 
     with error Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverInvalidUserException: 
     The response from the Autodiscover service at \u0027
     https://autodiscover.uclabor.de/autodiscover/autodiscover.svc/WSSecurity\u0027
      failed due to an error in user setting \u0027ExternalEwsUrl\u0027.
      Error message: InvalidUser.\r\n.
     Name of the server where exception originated: GV2PR08MB8050. LID: 33676.",
"responseCode": "5039",
"diagnosticData": ""
},
"message": "NoFreeBusyAccessException:The caller does not have access to free/busy data. LID: 40764",
"solve e-mail address 
user@msxfaq.}

Keine OrgRelationShip , kein Kontakt

Diese Fehlermeldung ist natürlich schnell erklärt. Hier gibt es keine "Org Relation Ship" und auch kein Kontaktobjekt in der Quelle.

"error": {
Message": "Unable to resolve e-mail address user@msxfaq.de to an Active Directory object."
...

Exchange fragt gar nicht beim Zielsystem an und wenn Sie das Problem "fixen", dann kann es bei EXO und Exchange dank Caching und DoS-Schutz durchaus einige Stunden dauern, bis die Korrektur auch greift.

Weitere Links