Hybrid FreeBusy

Die Planung von Terminen funktioniert besser, wenn der Einladende sofort sehen kann, ob und wann die Teilnehmer in ihrem Kalender noch Zeit haben. Microsoft Exchange hat dazu eine passende Lösung, bei der Outlook den eigenen Exchange Server fragt, der dann über Internet die anderen Exchange Server um Auskunft bittet. Der Administrator muss das nur einrichten. Wie sieht das aber aus, wenn eine Firma nun Exchange Hybrid hat oder beide Firmen schon Hybrid fahren?

Die Aussagen auf dieser Seite sind zumindest für Exchange Online wohl nicht mehr korrekt.
Im Mai 2023 konnte ich erstmals aus den Logs sehen, dass Exchange Online sehr wohl einem Autodiscover Redirect folgt.
Siehe dazu die aktuellere Seite Hybrid Free/Busy Details

Beachte dazu auch FreeBusy mit zwei Tenants - Free/Busy-Koexistent und Migration von Exchange OnPremises mit mehreren Tenants

Die Lösung

Diese Seite ist etwas länger und ich möchte nicht, dass Sie alles durchlesen und am Ende erkennen, das es zwar ein Abstieg in die Tiefen von Exchange ist, aber bei ihnen gar nicht zutrifft. Hier geht es um die Anzeige der Frei/Belegt-Zeiten zwischen getrennten Exchange Umgebungen, bei denen ein Teil der Postfächer in Exchange Online liegt.

Leider ist die Lösung alles andere als elegant. Sie brauchen ganz viele Kontakte und ähnlich wie bei Migrationen einige Routingdomänen.

Sie können es manuell umsetzen aber es ist ein größerer Aufwand, denn:

  • Jede abgefragte Exchange Umgebung braucht zwei SMTP Domänen, damit die Anfragen ans richtige Ziel geroutet werden
  • Die abfragende Exchange Umgebung muss MailContacts oder MailUser pflegen, deren TargetAddress auf die Exchange Plattform verweist, auf der das Postfach zu finden ist
    Migriert also Firma2 ein Postfach in die Cloud, muss Firma1 seinen Kontakt anpassen. Das geht also nur sinnvoll, wenn die Firmen kooperativ zusammenarbeiten und ein Verzeichnisabgleich diese Pflege zeitnah automatisiert.
  • Zwischen den Exchange Organisationen muss eine Vertrauensstellung eingerichtet werden
    Sowohl der Administrator der anfragenden Organisation als auch die angefragte Organisation kann Über eine "OrganizationRelationship" steuern, wer was sieht oder auch nicht sieht.

Diese Seite behandelt die abfrage von "Free/Busy"-Zeiten. Diese Einstellungen sind nicht relevant, wenn Sie Stellvertreter-Funktionen ausführen. Wenn als ein Benutzer in Exchange Online eine ShareMailbox OnPremises öffnet, dann wird ihr Client sich per Autodiscover direkt auf den Weg zum Zielserver machen.

Berechtigungen

Sie mögen in Exchange Online durchaus die Rolle "Exchange Administrator" haben, aber abhängig von der Variante der Hybrid-Bereitstellung benötigen Sie "Global Admin"-Rechte, um OAUTH und OrganizationRelationShip zu konfigurierten.

Umfang Variante Feature Benötigte Rechte

Minimum

Modern

Alle

Global Admin

Minumum

Classic

Alle

Exchange Admin

Full

Modern

Alle

Global Admin

Full

Classic

 OAuth
OrganizationRelatrionship
DedicatedHybridApp

Global Admin

Full

Classic

 CoexistenceDomain
Migration Endpunkt
OrganizationTransfer
Mailrouting

Exchange Admin

Nur bei "Minimum/Classic" reicht der Exchange Admin und bei einer "Full/Classic"-Bereitstellung können Sie teilweise auf Global Admin verzichten

Autodiscover, TargetSharingEpr und EWS

Die Abfrage von Frei/Belegt-Zeiten ist eine Aufgabe für EWS. Der Anwender fragt seinen eigenen Exchange an, damit dieser dann eine Anfrage an die Umgebung des Zielpostfachs stellt. Da der Zugriff über Organisationsgrenzen erfolgt, muss der anfragende Server den EWS-Zugangspunkt entweder per Autodiscover selbst ermitteln oder der Administrator konfiguriert die URL. Eine statische Konfiguration ist immer dann sinnvoll, wenn es sich um Partnerunternehmen handelt und vielleicht "Autodiscover" gar nicht aus dem Internet eingerichtet ist oder andere Beschränkungen dies verhindern. Eine manuelle Konfiguration bedeutet natürlich, dass die Administratoren sich bei Veränderungen entsprechend absprechen und manuelle Konfigurationen eignen sich nicht wirklich für eine "weltweite Federation" mit ganz vielen Firmen.

Für die Konfiguration von Free/Busy hat Microsoft im Laufe der Zeit mehrere Stellen vorgesehen die aus Kompatibiliätsgründen mit älteren Exchange Versionen immer noch vorhanden sind. Microsoft hat ein sehr umfangreiche Diagramme und Tabellen hier veröffentlicht:

Nachdem seit Oktober 2025 aber Exchange 2016/2019 nicht mehr supportet wird und die in dem Dokument beschrieben Exchange 2013/2010/2007 Server schon lange nicht mehr genutzt werden sollten, übernmehe ich folgende grundlegende Vorgehensweise von Exchange.


Quelle: Demystifying Hybrid Free/Busy: what are the moving parts? https://techcommunity.microsoft.com/blog/exchange/demystifying-hybrid-freebusy-what-are-the-moving-parts/607704

Das bedeutet für den Hybrid-Mode

  • Es muss einen IntraOrganizationConnector geben.
    Wenn es den nicht gibt, dann fällt Exchange zwar noch auf das "OrganizationRelationShip" zurück und prüft dann noch den AvailabilityAddressSpace, aber würde dann nur eine Anmeldung per DAUTH und nicht per OAUTH machen.
  • IntraOrganizationConnector  muss aktiviert sein
    Prüfen Sie, ob der Connector auch tatsächlich "aktiv" ist
  • Ist die SMTP-Domain enthalten?
    Auf der OnPremises Seite muss die "<tenantname>.mail.onmicrosoft.com"-Domain addiert sein, die als TargetAddress-Domain bei der RemoteMailbox verwendet wird.
    In Exchange Online müssen es die lokalen Domains sein
  • Autodiscover wird genutzt
    Der anfragende Server nutzt "Autodiscover", es sei denn Sie geben abweichende URLs an. Mit Autodiscover sind die Einträge in "ExternalURL" beim EWS Virtual Directory auf dem angefragten Server wichtig. Wenn Sie auf Autodiscover verzichten, dann müssen Sie

Für eine Hybrid-Bereitstellung zwischen Exchange Online und Exchange OnPremises sind DAUTH, Federation Gateway, Organizbation Relationship und AvailabilityAddressSpace nicht wichtig.

IntraOrganizationConfiguration

Für die "IntraOrganizationConfiguration" muss in der jeweiligen Topologie eine globale Konfiguration vorhanden sein. Das können Sie sehr einfach mit "Get-IntraOrganizationConfiguration" in der Exchange PowerShell prüfen. Hier ein Beispiel meiner Testumgebung:

OnPremises sehen wir schön die URls, die Exchange hier erwartet. Ein "Set-IntraOrganizationConfiguration" gibt es aber nicht.

IntraOrganizationConnector

Damit ihre Exchange Organisation auch weiß, wohin sie genau schauen muss, müssen Sie für die Anmeldung per OAUTH einen "IntraOrganizationConnector" anlegen. Die Arbeit übernimmt für Sie eigentlich der HCW - Hybrid Configuration Wizard. Hier wieder die beiden Ausgaben aus meiner Testumgebung:

  • Exchange OnPremises
  • Exchange Online

Hier sind nur vier Felder relevant:

  • TargetAddressDomains
    Hier müssen alle Domains der gegenüberliegenden Seite hinterlegt sein, zu denen Sie die Frei/Belegt-Zeiten abfragen wollen
  • DiscoveryEndpoint
    Das ist die Autodiscover-Adresse, über die der anfragende Server die Informationen zur Domain abfragt.
  • TargetSharingEpr
    Wenn Sie nicht auf Autodiscover vertrauen wollen, dann können Sie hier direkt eine URL in der Form "https://<fqdn>/EWS/Exchange.asmx" hinterlegen. Wenn Sie eh nur einen aus dem Internet erreichbaren Zugang haben oder Sie Autodiscover nicht im Internet veröffentlicht haben, dann ist dies die passende Option.
  • Enabled
    Kontrollieren Sie, dass der Wert auch auf "true" steht.

Die Aussagen von Microsoft sind nicht ganz eindeutig, wo nun das Feld "TargetSharingEpr" gesetzt werden muss. Wenn es leer ist, muss Autodiscover funktionieren aber sie können es gerne setzen. Manchmal setzt HCW auch das Feld aber anscheinend nicht immer. Das dürfte auch von der "Checkbox" im HCW bei den Domain abhängen, ob sie dort Autodiscover nutzen wollen

Authentifizierung: OAUTH Zertifikat

Der Zugriffe von Exchange OnPremises zu Exchange Online und in der Gegenrichtung erfolgt natürlich nicht "anonym". Bei Exchange 2007 wurde dafür sogar ein Dienstkonto angelegt. Ab Exchange 2010 wurde dies durch das MFG Microsoft Federation Gateway bereitgestellt aber seit Exchange 2013/2016/2019/SE übernimmt die Funktion ein Exchange OAuth-Zertifikat. OnPremises hat ihr Exchange Server schon durch die Installation ein 5 Jahre gültiges "selfsigned" Zertifikat, mit dem sich ihre lokalen Exchange Server untereinander authentifizieren. Dieses Zertifikat wird bei Hybrid genutzt, um die Anfragen an die Cloud damit zu signieren. Der HCW - Hybrid Configuration Wizard lädt bei der Einrichtung von Hybrid das Zertifikat in die Cloud hoch, so dass Exchange Online den Zugriff verifizieren kann. Umgekehrt scheint Exchange OnPremises schon "eingebaut" der Cloud zu vertrauen. Denken Sie daher beim Tausch des Zertifikats nach 5 Jahren daran, dass auch die Hybrid-Konfiguration aktualisiert werden muss.

Seit April 2025 konnte Exchange 2019/SE schon auf den neuen Weg mit der Dedicated Hybrid Application umgestellt werden. Seit Oktober 2025 ist diese Einrichtung für die Abfrage von OnPremises zu Exchange Online sogar pflicht.

OrganizationRelationship

Neben dem "IntraOrganizationConnector" legt der HCW - Hybrid Configuration Wizard auch immer noch auf beiden Seiten eine "OrganizationRelationship" an. Das ist auch erforderlich, denn hierüber verwalten sie, welche Informationen Sie freigeben bzw. abrufen dürfen. All diese Einstellungen sind nicht bim IntraorgConnector zu finden. In meiner Testumgebung hat HCW folgenden Eintrag angelegt:

  • Exchange OnPremises
  • Exchange Online

Bei so einer "Organisation Relationship" finden Sie nach der Einrichtung zwei Informationen unter "Allgemein".  Hier ein paar Beispiele 

Gegenstelle TargetApplicationUri TargetAutodiscoverEpr

On-Premises

 
FYDIBOHF25SPDLT.<maildomain>
 
https://autodiscover.<maildomain>.de/autodiscover/autodiscover.svc/WSSecurity

Office 365

 
outlook.com
 
https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity

Der Assistent ermittelt diese Werte eigentlich alleine bei der Einrichtung in der GUI oder mittels HCW. Sollte dies nicht möglich sein, verhindert die GUI die Anlage der "OrganizationRelationship"

Sie können natürlich per PowerShell diese Eintragungen auch manuell setzen.

New-OrganizationRelationship `
   -Name <name> `
   -Domainnames <domänen>

Allerdings gibt es hier keinen Assistenten und die Parameter bleiben leer. Sie können diese dann wie auch weitere Parameter manuell pflegen. zudem gibt es noch weitere Parameter, die nur per Powershell gesetzt werden können, z.B.

  • TargetOwaURL
    Dieser Wert ist innerhalb einer Hybrid-Bereitstellung wichtig, damit Anwender zum richtigen OWA-Server umgeleitet werden
  • TargetSharingEpr
    Über diesen Parameter können Sie den Zugriff des Exchange Servers auf die entfernte Seite vorgeben, wenn die entfernte Seite z.B. autodiscover nicht korrekt umgesetzt hat
    Ein möglicher Wert sieht z.B. so aus: "https://mail.msxfaq.de/ews/exchange.asmx"

Bedenken Sie immer, dass diese "Organization Relationship" nicht nur zwischen verbundenen Unternehmen genutzt wird, sondern auch eine Basis für eine Migration von Benutzern zwischen Exchange Topologien ist. Und da ist es doch hilfreich, wenn ein Anwender beim Zugriff auf die falsche URL per OWA einen netten Hinweis auf die richtige URL bekomme

Sie müssen also für jede Konfiguration auf der einen Seite auch das Gegenstück auf der anderen Seite einrichten.

Es reicht nicht nicht, wenn Firma1 die Abfrage an Firma2 stellt. Die Firma2 muss die Abfrage der Frei/Belegt-Zeiten auch erlauben.

Beide Einstellungen sind an der gleichen Stelle aber in zwei unterschiedlichen Reitern.

  • Allgemein
    Bestimmt, dass ihre Organisation die andere Domain anfragen kann und wie Sie dort anfragt
  • Freigabe
    Dort bestimmen Sie, in welchem Umfang Sie Informationen an die andere Organisation freigeben.

Nur zur Sicherheit: Die Anzeige von Frei/Belegt-Zeiten innerhalb einer Exchange Organisation bedarf keiner weiteren Konfiguration.

Autodiscover Proxy und Redirect

Für die nächsten Abschnitte ist es wichtig zu verstehen, wie Exchange Server eine an sie gestellte Free/Busy-Abfrage behandeln. Wenn ein Outlook-Client sich mit seinem Postfach verbindet und auf dem falschen Server gelandet ist, dann kann Autodiscover im einen Verweis auf den "richtigen Server geben. Innerhalb der gleichen Exchange Topologie sucht Exchange den dem Postfach naheliegenden Frontend-Server und liefert deren InternalURL/ExternalURL als XML-Antwort aus. Wenn der Benutzer aber in einer anderen Exchange Topologie (Cross Org Migration) oder z.B. in der Cloud ist, dann hat das Postfach eine TargetAddress und Autodiscover sendet dem Benutzer einen Redirect als XML-Antwort.

Bei Free/Busy-Anfragen eines Client an einen Exchange Server erfolgt keine derartige Umleitung. Der Client verbindet sich immer nur mit "seinem" Server und es ist die Aufgabe des Servers, eine Verbindung zur entsprechenden Gegenstelle aufzubauen, sich als Server zu authentifiziere, die Daten abzurufen und dem Client auszuhändigen. Das gilt sowohl für die Federation in der gleichen Firma zwischen einer On-Premises Installation und einer Exchange Online-Instanz mit dem Hybrid-Mode aber auch bei einer Federation zwischen Firmen:

In dem Artikel steht z.B. für die Federation innerhalb einer Hybrid-Umgebung ein ganz interessanter Abschnitt:

1. Joe creates a meeting request and adds Jane as an attendee.
2. The On-Premises Exchange server in Contoso determines (usually based on Target Address of the mail-enabled user) that Jane is not a local mailbox and has a different domain name of contoso.mail.onmicrosoft.com set as the Target Address.
3. The Availability Service on the On-Premises Exchange server (Client Access Server if Ex2010 or Mailbox Server if 2013/2016) in Contoso then checks to see if there is a path to query Jane’s Free/Busy information for Contoso’s cloud side.
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-hybrid-free-busy-what-are-the-moving-parts/ba-p/607704#

Wenn ich einen On-Premises Server fragen, dann agiert er als Proxy, um die Anfrage in die Cloud zu übertragen. Bei Exchange 2010 macht das noch die CAS-Rolle und bei Exchange 2013/2016 macht es aber die Mailbox Rolle. Diese Rolle muss also über das Internet die Office 365 Server erreichen können.

Update: Bei meinem letzten Traces mit Exchange 2016 hat der Exchange Server einen Autodiscover Redirect an den anfragenden Server gesendet und nicht als Proxy die Anfrage zur Cloud weiter gegeben.

Auch in die Gegenrichtung gibt es dazu ein Statement:

1. Jane creates a meeting request and adds Joe as an attendee
2. The Exchange Online servers in Contoso-cloud side organization determine (usually based on target address of a mail-enabled user) that Joe is not a local mailbox and has a domain name of contoso.com set as the target address.
3. The Availability Service on Exchange Online servers checks to see if there is a path for it to find the Free/Busy information for Contoso On-Premises side organization.
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-hybrid-free-busy-what-are-the-moving-parts/ba-p/607704#

Aus der Ecke von Exchange - Autodiscover sollten Sie noch wissen, dass die Einträge für "autodiscover.<maildomain>" solange auf die lokale Exchange Umgebung verweisen müssen, solange es noch ein Postfach dort gibt. Eine Autodiscover-Anfrage für ein Postfach wird vom lokalen Server mit der passenden Internal/ExternalURL oder mit einer Umleitung in die Cloud beantwortet.

In die Gegenrichtung ist das mit AutodiscoverV1 nicht möglich. Wenn ihr Outlook bei der Verbindung durch einen Konfigurationsfehler die Cloud fragt, dann wird er nicht auf die On-Premises-Umgebung verwiesen. Mit Autodiscover V2 sieht das anders aus.

Konstellationen

Da Exchange nur bei der Einrichtung der "Organization Federation" die Parameter ermittelt und dann statisch interlegt, gibt es einige Fälle, die funktionieren und andere, die nicht funktionieren. In den folgenden vier Szenarien befasse ich mir nur mit dem Zugriffe von Firma1 auf die Frei/Belegt-Zeiten von Anwendern bei Firma2. Die Firma2 ist im Hybrid-Mode mit Exchange On-Premises und Exchange Online. Firma1 kann On-Premises Only, Cloud Only oder Hybrid Only sein. Die Funktion ist immer ausgehend von dem Homeserver, auf dem der anfragende Benutzer liegt. Zudem hat Firma2 den Zugriff von Firma1 als Sharing Policy schon eingerichtet.

  Beschreibung

Sie konfigurieren auf dem On-Premises von Firma 1 den Zugriff auf die On-Premises Umgebung von Frma2

  • Die Anwender von Firma 1 sehen die Frei-Belegt-Zeiten der On-Premises Anwender in Firma 2.
  • Die Anwender von Firma 1 sehen NICHT die Frei-Belegt-Zeiten der Cloud Anwender in Firma 2.

Sie konfigurieren auf dem On-Premises von Firma 1 den Zugriff auf die Cloud Services von Firma2

  • Die Anwender von Firma 1 sehen NICHT die Frei-Belegt-Zeiten der On-Premises Anwender in Firma 2
  • Die Anwender von Firma 1 sehen die Frei-Belegt-Zeiten der Cloud Anwender in Firma 2

Sie konfigurieren auf dem Cloud Server von Firma 1 den Zugriff auf die Cloud von Firma2

  • Die Anwender von Firma 1 sehen NICHT die Frei-Belegt-Zeiten der On-Premises Anwender in Firma 2
  • Die Anwender von Firma 1 sehen die Frei-Belegt-Zeiten der Cloud Anwender in Firma 2

Sie konfigurieren auf dem Cloud Server von Firma 1 den Zugriff auf die Cloud der Firma 2

  • Die Anwender von Firma 1 sehen die Frei-Belegt-Zeiten der On-Premises Anwender in Firma 2.
  • Die Anwender von Firma 1 sehen NICHT die Frei-Belegt-Zeiten der Cloud Anwender in Firma 2.

 

Ich habe die funktionierenden Zugriffe mit grünen Pfeilen dargestellt und die roten Pfeile zeigen, was nicht geht. Microsoft hat aber keinen Proxy programmiert, damit der angefragte Firmenserver die Anfrage quasi mit seinem Namen an den richtigen Server weiterleitet.

Im Mai 2023 konnte ich aber erstmals sehen, dass ein Exchange 2016 On-Premises Server eine Autodiscover-Anfrage auf eine "Remote Mailbox" mit einem Redirect zur Cloud beantwortet hat.

Dennoch ist das natürlich versionsabhängig.

Beachten Sie dabei meine ausführlichere Analyse auf Hybrid Free/Busy Details

Exchange organizations that have both On-Premises and cloud users:
If you set up calendar sharing with another Exchange organization that is configured in a hybrid deployment with Microsoft Office 365, free/busy availability lookups for Office 365-based or remote users that have been moved to the cloud will fail. Because the organization relationship for your Exchange organization is with the remote On-Premises Exchange organization, not the Office 365-based Exchange Online organization, the free/busy request can't query the Office 365-based users. Exchange 2013 doesn't support functionality to proxy these availability requests through the On-Premises organization to the Office 365 service.
https://docs.microsoft.com/en-us/exchange/sharing-exchange-2013-help?redirectedfrom=MSDN#CB

Allerdings beschreibt der Artikel alles mit Exchange 2007/2010/2013. Ich habe aber noch einen zweiten Blog-Artikel gefunden, der auf das Hybrid-Szenario sehr gut eingeht:

PDF mit umfangreicher Beschreibung der Fehler und deren Lösung
https://techcommunity.microsoft.com/legacyfs/online/media/2019/01/FB_Errors.FixesV6.pdf

Ohne Autodiscover:Kontakte anlegen

Versuchen Sie die Funktion erst einmal ohne Kontakt. Wie ich auf Hybrid Free/Busy Details beschrieben habe, sollte zumindest mit Exchange 2016 und Exchange Online auch ein Autodiscover Redirect funktionieren.

In dem Artikel "The Hybrid Mesh" (https://techcommunity.microsoft.com/t5/exchange-team-blog/the-hybrid-mesh/ba-p/605910) hat Microsoft auch die Lösung beschrieben. Bezogen auf meine beiden Firmen muss Firma 1 zwei eigenen "Organization Trust" zu je einer Gegenseite einrichten. Dabei sind unterschiedliche Domänen zu verwenden. Wenn Firma1 selbst auch schon im Hybrid Mode ist, dann sind das je zwei Vertrauensstellung je Exchange Umgebung. In die Gegenrichtung ist das alles noch einmal zu konfigurieren.

Ausgehender Trust   Domain

Firma1 (OnPrem) -> Firma 2 (OnPrem)

onprem.firma2.tld

Firma1 (OnPrem) -> Firma 2 (Cloud)

firma2.mail.onmicrosoft.com

Firma1 (Cloud) -> Firma 2 (Cloud) 

onprem.firma2.tld 

Firma1 (Cloud) -> Firma 2 (OnPrem) 

firma2.mail.onmicrosoft.com

Firma2 muss natürlich diese "Routing Domänen" als zusätzliche SMTP-Adressen bei all seinen Empfängern addieren. Damit die neuen Verbindungen aber wirken, müsste der Anwender nun diese neuen Domänen für die Empfänger verwenden. Das können Sie den Anwendern aber nicht wirklich zumuten. Sie wissen vermutlich schon, was nun passiert.

MailUser oder MailContacts mit der Targetaddresse sind zu pflegen 

Sie legen als für die Postfächer in Firma2 auf ihrer Seite bei Firma1 entsprechende Kontakte mit einer Targetaddresse auf das aktuelle Postfach an. Natürlich müssen Sie die Partnerbeziehungen wie in der Tabelle einrichten.

Die Targetadresse muss natürlich immer auf das passende Zielsystem verweisen, denn ein Refer, Redirect oder Proxy findet nicht statt.

Wenn eine Firma überwiegen schon in der Cloud arbeitet, dann kann sie ihren Partnern natürlich die Anpassung der Konfiguration zur Cloud vorschlagen. Dann funktionieren die normalen Mailadressen aber die weiter On-Premises betrieben Postfächer der abgefragten Firma funktionieren dann natürlich nicht.

Das Bild zeigt zudem nur die Verbindung von Firma1 zu Firma2. Wenn auch die Mitarbeiter von Firma2 die Frei/Belegt-Zeiten von Firma1 sehen wollen, dann muss das gleiche Setup spiegelverkehrt erfolgen.

Ich finde diesen Aufwand und die Einschränkungen alles andere als glücklich gelöst. Da dies aber schon mehrere Jahre der Fall ist und anscheinend keine hohe Priorität hat, erwarte ich auch keine Verbesserungen in nächster Zeit. Sie können also ohne Kontakte und diese Konfiguration nur akzeptieren, dass Sie nur von einem Teil der Benutzer in einem verbundenen Unternehmen die Frei/Belegt-Zeiten sehen.

Fehler und Ursachen

Bis dieser Artikel geschrieben war und ich die verschiedenen Quellen alle gefunden habe, habe ich mit mehreren Tenants und On-Premises-Umgebungen verschiedene Konstellationen ausprobiert und auf einem Outlook-Client mit Fiddler die EWS-Anfragen analysiert. Ich habe hier unterschiedliche Fehler gefunden, die ich hier vorstelle. Vielleicht stoßen Sie ja auch auf die Fehler und finden so vielleicht die Ursache. Einige Fehler sind auch durchaus aufschlussreich, als wenn Microsoft einige Funktionen doch schon ansatzweise aber nicht komplett programmiert hat.

PDF mit umfangreicher Beschreibung der Fehler und deren Lösung
https://techcommunity.microsoft.com/legacyfs/online/media/2019/01/FB_Errors.FixesV6.pdf

  • Proxy web request failed
    Ich habe von Firma1 die Exchange Online Instanz von Firma2 nach einem Benutzer gefragt, der bei Firma2 On-Premises lag. Ich konnte tatsächlich im Fehler sehen, dass die Cloud anscheinend eine Verbindung zum lokalen Exchange Server aufgebaut hat. Allerdings zu einer IP-Adresse die es nicht mehr gibt, weil dieser Tenant schon "Modern Hybrid" mit einem Agenten nutzt. Exchange Online scheint hier also noch nicht mit Modern Hybrid kompatibel zu sein. Ich kann aber nicht sagen, ob es dann funktioniert hätte, denn die Authentifizierung ist ja noch nicht geklärt.
Proxy web request failed. ,
 inner exception: System.Net.WebException: Unable to connect to the remote server
 ---&gt; System.Net.Sockets.SocketException: No connection could be made because 
the target machine actively refused it xx.xx.xx.xx:443  (=hybrid.msxfaq.com)
  • Unbekannter Benutzer
    Beim Versuch die Frei/Belegt-Zeiten eines nicht in Exchange Online existierenden Benutzers abzufragen, kam die folgende Meldung.
Microsoft.Exchange.InfoWorker.Common.Availability.MailRecipientNotFoundException: 
Unable to resolve e-mail address user@msxfaq.com to an Active Directory object.. 
Name of the server where exception originated: AM0PR0402MB3442
  • SOAP Error
    Diese Fehler ist bei einer Verbindung von Exchange Online zu Exchange On-Premises gekommen. Ich vermute auch hier, dass der Exchange Server sehr wohl meine Anfrage als Proxy weiter gegeben hat aber die andere Seite dann mangels Authentifizierung abgebrochen hat.
Proxy web request failed. , inner exception: System.Web.Services.Protocols.SoapHeaderException: An error occurred when verifying security for the message.
  • On-Premises zur Cloud
    Hier kommt nun ein sauberer 401-Fehler, denn der lokale Exchange Server um die F/B-Zeiten eines Cloud-Users gefragt wird. Für mich bedeutet das aber auch, dass der Exchange Server durchaus die Proxy-Funktion Richtung Cloud haben könnte und sich nur nicht anmelden kann, da er für den fragenden Anwende der anderen Organisation kein OAUTH-Token bekommt.
Proxy web request failed. , inner exception: System.Net.WebException: The request failed with HTTP status 401: Unauthorized.
  • Tippfehler in Application
    Wenn Sie genau hinschauen, dann finden Sie einen Tippfehler "Outllook" in der AppID, welche dann von der Gegenseite natürlich nicht gefunden wird
Fail  &lt;S:Fault xmlns:S="http://www.w3.org/2003/05/soap-envelope"&gt;
&lt;S:Code&gt;&lt;S:Value&gt;S:Sender&lt;/S:Value&gt;
&lt;S:Subcode&gt;&lt;S:Value&gt;wst:FailedAuthentication&lt;/S:Value&gt;
&lt;/S:Subcode&gt;&lt;/S:Code&gt;&lt;S:Reason&gt;
&lt;S:Text xml:lang="en-US"&gt;Authentication Failure&lt;/S:Text&gt;
&lt;/S:Reason&gt;&lt;S:Detail&gt;
&lt;psf:error xmlns:psf="http://schemas.microsoft.com/Passport/SoapServices/SOAPFault"&gt;
&lt;psf:value&gt;0x80048800&lt;/psf:value&gt;&lt;psf:internalerror&gt;
&lt;psf:code&gt;0x80048800&lt;/psf:code&gt;
&lt;psf:text&gt;AADSTS901124: Application 'outllook.com' does not exist.&lt;/psf:text&gt;
&lt;/psf:internalerror&gt;&lt;/psf:error&gt;&lt;/S:Detail&gt;
&lt;/S:Fault&gt; Microsoft.Exchange.Net.WSTrust.SoapFaultException: Soap fault exception received.
  • Public Folder Mailbox
    Bei der Suche nach einer lokalen Mailbox habe ich aus versehen die "Public Folder Mailbox" der On-Premises-Umgebung eingeladen. Hier kamen dann andere Fehlermeldungen von der Cloud
Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException: 
Exceeded the number of Autodiscover redirections for e-mail pfmailbox1@msxfaq.de. 
The maximum allowed redirections are 3. Name of the server where exception originated: DM5PR20MB2119. LID: 53772
Autodiscover failed for email address pfmailbox@msxfaq.de with error Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverInvalidUserException: 
The response from the Autodiscover service at 'https://autodiscover.msxfaq.de/autodiscover/autodiscover.svc/WSSecurity' 
failed due to an error in user setting 'ExternalEwsUrl'. 
Error message: InvalidUser.
  • PF Mailbox und On-Premises
    Ich habe dann einfach noch mal direkt den lokalen Exchange Server nach den F/B-Zeiten der Public Folder Mailbox gefragt
Mailbox logon failed., 
inner exception: Microsoft.Exchange.Data.Storage.AccessDeniedException: 
This operation is not supported on a public folder mailbox.

Hier habe ich dann meine Test-Serie eingestellt.

Weitere Links