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
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.
- Sharing Scenarios in Exchange 2013
https://docs.microsoft.com/en-us/exchange/sharing-exchange-2013-help#sharing-scenarios-in-exchange-2013 - Organization relationships
https://docs.microsoft.com/en-us/exchange/organization-relationships-exchange-2013-help - Federation
https://docs.microsoft.com/en-us/exchange/federation-exchange-2013-help - Shared free/busy in Exchange hybrid
deployments
https://docs.microsoft.com/de-de/exchange/shared-free-busy
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
- Set-OrganizationRelationShip
https://docs.microsoft.com/en-us/powershell/module/exchange/sharing-and-collaboration/set-organizationrelationship?view=exchange-ps
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
- Get-IntraOrganizationConnector
https://docs.microsoft.com/de-de/powershell/module/exchange/get-intraorganizationconnector - Set-IntraOrganizationConnector
https://docs.microsoft.com/de-de/powershell/module/exchange/set-intraorganizationconnector
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 2016 ü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.
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:
- Demystifying Hybrid Free/Busy: what are
the moving parts?
https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-hybrid-free-busy-what-are-the-moving-parts/ba-p/607704#
Sehr lesenswerter Artikel zur Funktion
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
|
|
Sie konfigurieren auf dem On-Premises von Firma 1 den Zugriff auf die Cloud Services von Firma2
|
|
Sie konfigurieren auf dem Cloud Server von Firma 1 den Zugriff auf die Cloud von Firma2
|
|
Sie konfigurieren auf dem Cloud Server von Firma 1 den Zugriff auf die Cloud der 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:
- The Hybrid Mesh
https://techcommunity.microsoft.com/t5/exchange-team-blog/the-hybrid-mesh/ba-p/605910 - Demystifying Hybrid Free/Busy: what are
the moving parts?
https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-hybrid-free-busy-what-are-the-moving-parts/ba-p/607704 - Demystifying Hybrid Free/Busy: Finding
errors and troubleshooting
https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-hybrid-free-busy-finding-errors-and-troubleshooting/ba-p/607727
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 ---> 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 <S:Fault xmlns:S="http://www.w3.org/2003/05/soap-envelope"> <S:Code><S:Value>S:Sender</S:Value> <S:Subcode><S:Value>wst:FailedAuthentication</S:Value> </S:Subcode></S:Code><S:Reason> <S:Text xml:lang="en-US">Authentication Failure</S:Text> </S:Reason><S:Detail> <psf:error xmlns:psf="http://schemas.microsoft.com/Passport/SoapServices/SOAPFault"> <psf:value>0x80048800</psf:value><psf:internalerror> <psf:code>0x80048800</psf:code> <psf:text>AADSTS901124: Application 'outllook.com' does not exist.</psf:text> </psf:internalerror></psf:error></S:Detail> </S:Fault> 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
- Free/Busy und Hybrid-Mode
- Kalender Federation mit Exchange und Outlook
- MFG Microsoft Federation Gateway
- CalFed Office 365
- Autodiscover Redirect
- TargetAddress
- Routingdomänen
-
The Hybrid Mesh
https://techcommunity.microsoft.com/t5/exchange-team-blog/the-hybrid-mesh/ba-p/605910 -
Sharing (Exchange 2013)
https://docs.microsoft.com/en-us/exchange/sharing-exchange-2013-help - Shared free/busy in Exchange hybrid deployment
https://docs.microsoft.com/de-de/exchange/shared-free-busy
beschreibt nur das Sharing innerhalb der Hybrid Umgebung - Demystifying Hybrid Free/Busy: what are
the moving parts?
https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-hybrid-free-busy-what-are-the-moving-parts/ba-p/607704
Sehr guter Artikel und absolut lesenswert - Demystifying Hybrid Free/Busy: Finding
errors and troubleshooting
https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-hybrid-free-busy-finding-errors-and-troubleshooting/ba-p/607727 - How Does Free/Busy Works between two different office 365
Tenants and Configure
https://windowstechpro.com/how-does-free-busy-works-between-two-different-office-365-tenants-and-configure/ - How to troubleshoot free/busy issues in
a hybrid deployment of On-Premises Exchange
Server and Exchange Online in o365
https://support.microsoft.com/en-us/help/2555008/how-to-troubleshoot-free-busy-issues-in-a-hybrid-deployment-of-on-prem - Federated Calendar Sharing error 5039
and 5037
https://www.catapultsystems.com/blogs/federated-calendar-sharing-error-5039-and-5037/ - Behandeln von Frei/Gebucht-Problemen in
einer Hybridbereitstellung mit einem lokalen
Exchange-Server und Exchange Online in
Office 365
https://support.microsoft.com/de-de/help/2555008/how-to-troubleshoot-free-busy-issues-in-a-hybrid-deployment-of-on-prem
Behandelt aber nur die Probleme innerhalb einer Hybrid-Umgebung - Aktivieren der globalen und erweiterten
Protokollierung für Microsoft Outlook
https://support.microsoft.com/de-de/topic/aktivieren-der-globalen-und-erweiterten-protokollierung-f%C3%BCr-microsoft-outlook-15c74560-2aaa-befd-c256-7c8823b1aefa - Exchange Hybrid Free/Busy and Proxy
issue
https://www.risual.com/2015/10/exchange-hybrid-freebusy-and-proxy-issue/
Beschreibt einen ausgehenden Proxy, der den Exchange Server blockiert. - Top 10 Fixes for troubleshooting free/busy
between Exchange On-Premises and Exchange
Online in Office 365
https://www.thecloudtechnologist.com/top-10-fixes-for-troubleshooting-free-busy-between-exchange-On-Premises-and-exchange-online-in-office-365/ - Error
5016
Exchange
Free Busy
https://social.technet.microsoft.com/wiki/contents/articles/36717.error-5016-exchange-free-busy.aspx - Federated
Calendar
Sharing
error 5039
and 5037
https://www.catapultsystems.com/blogs/federated-calendar-sharing-error-5039-and-5037/ - Exceeded the number of Autodiscover
redirections for
e-mail;SMTP:username@domain.org. The maximum
(93232)
https://support.quest.com/de-de/coexistence-manager-for-notes/kb/93232/exceeded-the-number-of-autodiscover-redirections-for-e-mail-smtp-username-domain-org-the-maximum