MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

FreeBusy mit zwei Tenants

Wenn Sie z.B. durch eine Merger&Acuisition einen Exchange Hybrid Mode mit zwei Tenants einrichten müssen, dann hat das direkt Auswirkungen auf die "Free/Busy"-Funktion.

Vorarbeiten

Gegeben ist eine Firma mit einer lokalen Exchange Installation, die dauerhaft oder im Rahmen einer Migration eine Verbindung zu zwei Tenants aufrecht erhalten muss. Wenn Sie nicht nur mit "Minimum Hybrid", also Mailrouting und Migrationsendpunkt arbeiten, sondern auch Frei/Belegt-Zeiten benötigen, dann ist das Setup etwas aufwändiger. Die folgenden Vorarbeiten sind aber immer vorhanden:

  • Verzeichnisabgleich und Adressbuch
    Damit Exchange Hybrid funktioniert, muss jede Organisation seine Empfänger kennen. Das ist die Aufgabe von ADSync, welcher hier aber zweimal installiert werden muss, da jeder Tenant seine eigenen Benutzer benötigt. Aufgrund der Eindeutigkeit der DNS-Domains pro Tenant bedeutet dies aber auch, dass Tenant1 auch nur die Benutzer repliziert bekommt, die zur Domain1, im Beispiel dann "msxfaq.de" haben.
    Das bedeutet weiterhin, dass die OnPremises-Benutzer ohne Adressbuchrichtlinien problemlos alle Empfänger beider Domain sehen, während ein schon in Exchange Online betriebener Benutzer nur "seine" Benutzer aus dem Entra ID-Adressbuch sieht. Sie sollten nie die Benutzer der anderen Domain in ihren Tenant replizieren, sondern dann eher über Gast-Identität und Cross-Tenant Sync nachdenken.
  • Mailrouting
    Der HCW - Hybrid Configuration Wizard richtet für Sie die entsprechenden Connectoren zum Routing ein, damit Mails an die MOERA - Microsoft Online Email Routing Address als auch zu den eigentlichen SMTP-Domänen zugestellt werden. Auch hier gibt es natürlich Feinheiten zu beachten, dass der absendende lokale Exchange Server dem jeweils richtigen Tenant zugeordnet wird. Siehe dazu auch OnPremises Connector Attribution.
  • MigrationEndpoint
    Die dritte Komponenten ist die Definition des Migration Endpoints in jedem Tenant, damit Exchange Online den Weg zur Migration von Postfächern kennt.
  • Dedicated Hybrid Application
    Seit Okt 2025 ist die Nutzung einer eigenen AppRegistration für den Zugriff von OnPremises auf den eigenen Exchange Online Tenant erforderlich. Bei zwei Tenants sind das unterschiedliche Objekte und im lokalen Exchange Server gibt es je Tenant einen eigenen AuthServer "EvoSTS*" mit der passenden ApplicationIdentifier.
    Get-AuthServer "EvoSts - fb2c2d99-4d38-4d1f-ba15-be51f857b56a" | fl name,domainname,ApplicationIdentifier
    Die Einrichtung macht der HCW für sie aber sie müssen die Einrichtung noch aktivieren.

Das Startbild sieht vereinfacht wie folgt aus. Autodiscover verweist auf die OnPremises-Umgebung.

Wer mit Wem?

In dem Bild sehen Sie viele Pfeile und die vielen grünen Pfeile zeigen an, welche Fälle es alles geben kann. Allerdings funktionieren nicht alle, wie die folgende Tabelle beschreibt. Die "internen" Abfragen von zwei Benutzern auf dem gleichen System, also z.B. A1 mit A2, habe ich nicht gesondert aufgeführt, da diese immer funktionieren.

Von Nach Status Beschreibung

A

B

OK

Hybridbereitstellung Tenant 1

B

A

OK

Hybridbereitstellung Tenant 1

A

C

OK

Abfrage innerhalb der gleichen Exchange Organisation

C

A

OK

Abfrage innerhalb der gleichen Exchange Organisation

C

D

OK

Hybridbereitstellung Tenant 2

D

C

OK

Hybridbereitstellung Tenant 2

A

D

Konfiguration

A wird die RemoteMailbox D mit der RemoteRoutingAddress über das lokale AD auflösen und wenn der Admin eine F/B-Relationship zwischen Tenant2 und der Domain MSXFAQ.DE eingerichtet hat, sollte dies funktionieren. Bedenken Sie aber dass im Tenant2 der Benutzer A nicht bekannt ist aber die lokale Umgebung für die Funktion C->D schon eine Relationship hat.

D

A

Konfiguration

Auch dazu muss der Administrator eine Relationship zur Domain msxfaq.de einrichten.

B

C

Konfiguration

Siehe D->A

C

B

Konfiguration

Siehe A->D

B

D

Konfiguration

Die F/B Abfragen funktionieren nur, solange B die "MOERA - Microsoft Online Email Routing Address"  von D nutzt und es eine OrgRelationsShip zwischen den Tenants eingerichtet wurde. B weiß das aber nicht und das Konto von D wird durch ADSync nicht in seinen Tenant repliziert. Hier sollten Sie über Gast-Identität und Cross-Tenant Sync nachdenken.

D

B

Konfiguration

Siehe B->D

Die größere Herausforderung ist bei solchen Umgebungen das Identity Management, damit sie im jeweils anderen Tenant die "richtigen" Benutzerinformationen pflegen. Denken Sie auch an Gruppenmitgliedschaften.

Zudem enthält ja die Anfragen der Quelle die Identität des anfragenden Benutzers, die vom anderen Exchange Server ggfls. in Form eines Kontakts auflösbar sein muss.

Tenant2 ist Cloud Only

Gehen wir nun einen Schritt weiter, dass Tenant2 alle Benutzer in die Cloud migriert hat und zuletzt auch den Autodiscover-Eintrag zu Exchange Online umgestellt hat. Eine Interorg/OrganizationRelationship zur bisherigen lokalen Exchange Umgebung entfällt bzw. kann/muss auf den Tenant2 umgeroutet werden.

 

Natürlich gibt es weiterhin eine lokale "RemoteMailbox", die aber sogar entfallen kann, wenn sich der Tenant2 zur Umsetzung von IsExchangeCloudManaged entschließt. Bislang gab es aber OnPremises nur eine Interorg/OrgrelationShip für die OnMicrosoft-Domain des Tenant2. Die muss nun erst angepasst werden, dass der lokale Exchange Server auch die Domain "uclabor.de" Richtung Exchange Online sendet. Die Tabelle verändert sich dann etwas:

Von Nach Status Beschreibung

A

B

OK

Hybridbereitstellung Tenant 1

B

A

OK

Hybridbereitstellung Tenant 1

A

C

Entfällt

Entfällt

C

A

Entfällt

Entfällt

C

D

Entfällt

Entfällt

D

C

Entfällt

Entfällt

A

D

Konfiguration

A kann weiter die RemoteMailbox D mit der RemoteRoutingAddress über das lokale AD auflösen und wenn der Admin eine F/B-Relationship zwischen Tenant2 und der Domain MSXFAQ.DE eingerichtet hat, sollte dies funktionieren. Bedenken Sie aber dass im Tenant2 der Benutzer A nicht bekannt ist aber die lokale Umgebung für die Funktion C->D schon eine Relationship hat.
Es kann aber auch sein, dass die Postfächer im Tenant2 gar nicht mehr im lokalen AD sichtbar sind (z.B. IsExchangeCloudManaged) . Dann ist es eine klassische F/B-Konfiguration zu einem fremden Tenant, selbst wenn ADSync noch die Anmeldekonten verwalten würde.

D

A

Konfiguration

Hier ändert sich zur ersten Tabelle nichts. Der Administrator muss eine Relationship zur Domain msxfaq.de einrichten.

B

C

Entfällt

Entfällt

C

B

Entfällt

Entfällt

B

D

Konfiguration

Die F/B Abfragen funktionieren nur, solange B die "MOERA - Microsoft Online Email Routing Address"  von D nutzt und es eine OrgRelationsShip zwischen den Tenants eingerichtet wurde. B weiß das aber nicht und das Konto von D wird durch ADSync nicht in seinen Tenant repliziert. Hier sollten Sie über Gast-Identität und Cross-Tenant Sync nachdenken.

D

B

Konfiguration

Siehe B->D

Durch die Migration einer nach Exchange Online entfallen schon einmal sechs Szenarien, die sie ansonsten betreiben und testen müssten.

Beide in Exchange Online

Nun führen wir die Migration zu Ende und auch der Teil mit der Domain MSXFAQ.DE migriert alle Postfächer in die Cloud. Die Autodisover-Auflösung wird zu Exchange Online umgestellt und lokal bleiben entweder nur noch die "RemoteMailbox" zurück oder sogar nur die Benutzer, wenn beide Firmen die IsExchangeCloudManaged-Option nutzen wollen. Unabhängig von diesem Detail gibt es aber keinen Exchange/Outlook-Client mehr, der einen lokalen Server frage und damit ggfls. eine Weiterleitung über die MOERA - Microsoft Online Email Routing Address bekommt.

Die weiter zu betrachtenden Szenarien vereinfachen Sie erneut, da die native Domains auch zugleich auf die richtige Exchange Plattform verweist und keine Umleitung über Autodiscover Redirect mehr erforderlich ist. 

Von Nach Status Beschreibung

A

B

Entfällt

Entfällt. Konto in diesem Szenario nicht vorhanden

B

A

Entfällt

Entfällt. Konto in diesem Szenario nicht vorhanden

A

C

Entfällt

Entfällt. Konto in diesem Szenario nicht vorhanden

C

A

Entfällt

Entfällt. Konto in diesem Szenario nicht vorhanden

C

D

Entfällt

Entfällt. Konto in diesem Szenario nicht vorhanden

D

C

Entfällt

Entfällt. Konto in diesem Szenario nicht vorhanden

A

D

Entfällt

Entfällt. Konto in diesem Szenario nicht vorhanden

D

A

Entfällt

Entfällt. Konto in diesem Szenario nicht vorhanden

B

C

Entfällt

Entfällt. Konto in diesem Szenario nicht vorhanden

C

B

Entfällt

Entfällt. Konto in diesem Szenario nicht vorhanden

B

D

Konfiguration

Der HCW richtet keine F/B-Relationship zwischen Tenants ein. Das bleibt die manuelle Arbeit der beiden Administratoren. Aber danach sollten Sie die Frei/Belegt-Zeiten auflösen können. Damit die Anwender nicht "blind" die Mailadresse tippen können Sie bei befreundeten Unternehmen einen Verzeichnisabgleich zwischen den Tenants über Gast-Identität und Cross-Tenant Sync nachdenken.

D

B

Konfiguration

Siehe B->D

Was mit mit Delegation?

Der Zugriff von Benutzern auf andere Postfächer im Rahmen einer Delegierung ist von Free/Busy unabhängig, aber wird oft vermischt. Wenn z.B. Free/Busy nicht funktioniert aber ich als Stellvertreter einen Kalender in einem anderen Postfach öffnen kann, dann zeigt Outlook mir sehr wohl die Details an. Das ist aber nicht "Free/Busy", auch wenn es ähnlich aussieht.

Delegaten erfordert aber immer eine Authentifizierung des Benutzers gegen das andere Postfach. In Verbindung mit Exchange Online muss der anfragende Benutzer sich a Tenant authentifizieren. Bei obigem Beispiel funktioniert das nur, wenn die Benutzer per ADSync auch im Tenant bekannt sind

Von Nach Status Beschreibung

A

B

OK

Benutzer A kann sich am Tenant 1 anmelden und damit auf den Kalender von Benutzer B zugreifen, wenn diese ihm die Rechte eingeräumt hat

B

A

OK

Benutzer B kann sich OnPremises  anmelden und damit auf den Kalender von Benutzer B zugreifen, wenn diese ihm die Rechte eingeräumt hat

A

C

OK

Benutzer A kann OnPremises auf den Kalender von Benutzer C zugreifen, wenn diese ihm die Rechte eingeräumt hat

C

A

OK

Benutzer C kann OnPremises auf den Kalender von Benutzer A zugreifen, wenn diese ihm die Rechte eingeräumt hat

C

D

OK

Benutzer D kann sich am Tenant 2 anmelden und damit auf den Kalender von Benutzer D zugreifen, wenn diese ihm die Rechte eingeräumt hat

D

C

OK

Benutzer C kann sich OnPremises  anmelden und damit auf den Kalender von Benutzer C zugreifen, wenn diese ihm die Rechte eingeräumt hat

A

D

Nein

Dieser Zugriff ist nicht möglich, da Benutzer A im Tenant 2 nicht bekannt ist

D

A

Nein

Dieser Zugriff ist nicht möglich, da das Postfach A im 2 nicht bekannt ist

B

C

Nein

Siehe D->A

C

B

Nein

Siehe A->D

B

D

Nein

Ich kenne keinen Weg, wie Tenant-übergreifend ein Zugriff auf Postfächer möglich ist

D

B

Nein

Ich kenne keinen Weg, wie Tenant-übergreifend ein Zugriff auf Postfächer möglich ist

All diese Aussagen sind eine Momentaufnahme (Stand Jan 2026) Es kann durchaus sein, dass Microsoft zukünftig Funktionen anpasst. Technisch könnte ein Benutzer z.B. einem Gastkonto entsprechende Berechtigungen.

Weitere Links