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 nicht mehr korrekt. Im Mai 2023 konnte ich erstmals nachtracken, dass Exchange Online sehr wohl einem Autodiscover Redirect folgt. Siehe dazu die aktuellere Seite Hybrid Free/Busy Details

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.

Man kann es 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..

Exchange agiert leider nicht als Proxy o.ä. um diese Konstellation zu vereinfachen. Wenn Sie nun noch interessiert sind, dann lesen Sie gerne weiter.

Organzation Relationship

Zuerst schauen wir uns die grundlegende Konfiguration noch einmal an, wenn zwei Exchange Organisationen eine engere Zusammenarbeite miteinander vereinbaren. Die anfragende Organisation muss einen Eintrag anlegen, mit der die Anfragen an die andere Organisation erlaubt werden und die andere Organisation muss hinterlegen, welche Informationen sie bereit ist zu teilen. Wir sprechen hier von der "Organization relationship". Etwas anders ist die "Sharing Policy", die mehr Andere Möglichkeiten eröffnet, z.B. auch das Teilen von Kalendern mit Inhalten.

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

Bedeutung der URLs

Bei so einer "Organisation Relationship" finden Sie nach der Einrichtung zwei Informationen unter "Allgemein":

Es gibt eine Anwendungs-URL und einen Endpunkt für die Auto-Ermittlung. Die hat Exchange bei der Anlage der Federation gleich selbst angelegt.

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 also diese Werte und verbindet sich damit. Sollte dies nicht möglich sein, verhindert die GUI die Anlage der "Organization Relationship"

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.

IntraOrganization Connector

Neben der einen "OrganizationRelationShip" legt der HCW auch noch einen IntraOrganizationConnector an. Auch hier gibt es z.B.: das Feld "TargetSharingEpr", indem der On-Premises Hybrid Server stehen sollte

PS C:\> Get-IntraOrganizationConnector | fl
 
TargetAddressDomains : {msxfaq.de, msxfaq.com}
DiscoveryEndpoint    : https://owa.msxfaq.de/autodiscover/autodiscover.svc
TargetSharingEpr     : https://hybrid.msxfaq.de/EWS/Exchange.asmx
Enabled              : True
AdminDisplayName     :
ExchangeVersion      : 0.20 (15.0.0.0)
Name                 : HybridIOC - xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ObjectCategory       : EURP193A002.PROD.OUTLOOK.COM/Configuration/Schema/ms-Exch-Intra-Organization-Connector
ObjectClass          : {top, msExchIntraOrganizationConnector}
IsValid              : True
ObjectState          : Unchanged

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