EXO Doppelhybrid

Diese Seite beschreibt die Einrichtung von zwei Exchange OnPremises-Umgebungen mit einem Tenant. Diese Kombination ist offiziell möglich und gerade beim Thema "Zukauf" eine mögliche Konstellation, um Firmen zu konsolidieren. Der Fall beschreibt nicht die Migration von Tenant zu Tenant oder die Verbindung von zwei Tenants mit einer Exchange Organisation.

Umgebung

Zur weiteren Beschreibung der Komplexität habe ich eine exemplarische Konfiguration gewählt, in der ich hoffentlich die meisten Fragen stellen und auch beantworten kann.

Allerdings gibt es noch sehr viel weitere Abwandlungen und kann eine individuelle Betrachtung ihrer Umgebung mit einer fundierten Analyse, der Bewertung verschiedener Phasen bis zur Durchführung nicht ersetzen. Wenn ihnen die Informationen auf der Seite nicht ausreichen, dann sprechen Sie meine Kollegen bei Net at Work oder mich gerne an.

Die Situation stellt sie wie folgt dar:

  • Eine Firma haut "historisch" bedingt zwei lokale AD/Exchange Umgebungen
    Dieser Fall ist gar nicht mal so selten, wenn eine deutsche Firma z.B.: eine Niederlassung oder später zugekaufte Firma in z.B. den USA hat und man damals eben ziemlich autark unterwegs war. Es gibt dann auch zwei Forests und selbst mit einer WAN-Verbindung kann man hinsichtlich Datenschutz dann getrennt entscheiden.
  • Routing zwischen Exchange Organisationen
    Natürlich können Sie zwischen den lokalen Exchange-Umgebungen auch ein Mailrouting, einen Kontaktabgleich und Frei/Belegt-Zeiten einrichten. Das ist zwar nicht schwer aber muss halt gemacht und betrieben werden. Daher gibt es auch hier noch viele Firmen, die darauf verzichtet haben, so dass sogar "interne" Mails über das Internet gehen. Wie Anfangs geschrieben ist das hier nur ein Beispiel, was auf einem realen Kunden basiert. Ihre Startvoraussetzung kann eine andere sein.
  • Ein Office 365 Tenant
    Aber wenn Sie sich vorab informiert haben, wie eingeschränkt die Zusammenarbeit zwischen Tenants ist, dann sollten Sie immer versuchen, dass eine Firma auch in einem Office 365-Tenant unterkommt. Sicher gibt es Aufgabenstellungen wie "geografischer Standort", Datenschutz, Lizenzverrechnung etc. Das ist aber zu schaffen und allemal besser als nicht miteinander zu arbeiten

Damit so eine Konstellation mit zwei oder mehr AD-Forests samt lokalen Exchange Servern und dem gemeinsamen Tenant funktioniert, müssen Sie einige Konfigurationen richtig machen. Das Bild hier zeigt auch nur einen Zwischenstand und kann an vielen Stellen weiter optimiert werden. So würde ich selbst nie eine Umgebung auf Dauer aufbauen und betreiben.

Aber es ist ein guter Zwischenstand, an dem ich die verschiedenen Aspekte beschreiben kann. Die Intention hierbei war es, über den Exchange Hybrid Mode die Postfächer von "Org1" langsam in die Cloud zu migrieren. Parallel muss aber "Org" in den USA möglichst schnell in die Cloud, da der lokale Exchange 2010 Server nicht nur von Softwarestand aus der Wartung läuft, sondern auch zu klein und zu schlecht abgesichert ist.

Org1 hatte also schon den Exchange Hybrid Mode mit ADSync eingerichtet und sogar den MX-Record schon über Exchange Online Protection geroutet während Org2 später dazu gekommen ist. Das Bild zeigt den Zeitpunkt, in dem Org2 seine Postfächer in die Cloud migriert aber seine ganzen lokalen Einstellungen noch nicht angepasst hat.

ADSync

Wenn Sie auf der Seite Office 365 - Multi-Forest Umgebung aufgepasst haben, dann wissen Sie, dass ein Tenant immer nur genau von einer ADSync-Instanz bedient werden kann. Daraus folgern mehrere Aussagen:

  • Eine ADSync-Installation per LDAP mit beiden AD-Forests kommunizieren können
    Es reicht erst einmal wirklich ein LDAP-Zugriff. Es muss kein Trust zwischen den Forests bestehen und eine spätere Migration der Konten wird hier nicht weiter betrachtet.
  • Jeder Forest muss (sollte) eine eindeutige UPN-Domain haben
    Das ist wichtig aber nicht zwingend, wenn sie keinen Trust haben. Sie können dann natürlich kein ADFS/PTA verwenden aber mit PasswordHashSync kann man damit durchaus arbeiten.
  • Eindeutige Identitäten
    Es würde mich nicht überraschen, wenn der gleiche Mensch in beiden Forests ein Konto und im schlimmsten Fall sogar ein Postfach hatte und das erst bei der Einrichtung von ADSync auffällt.
  • Alle Domains im Tenant
    Natürlich müssen Sie im Office 365-Tenant auch alle UPN-Domains und SMTP-Domains  der beiden Forests eintragen.
  • Exchange Hybrid und RTP-Attribute
    Denken Sie daran, dass ADSync auch eventuell lokal vorhandene Lync/Skype for Business Attribute repliziert. Damit wirklich alle Exchange Attribute mitkommen, müssen Sie im ADSync auf jeden Fall die Exchange Hybrid-Bereitstellung aktivieren. Dies ist zwingend aber wird z.B. vom HCW nicht verifiziert.

ADSync sorgt dann nicht nur dafür, dass die Benutzer aus beiden AD-Umgebungen auch im Tenant ein gültiges Anmeldekonto haben, sondern auch die Exchange Informationen in der Cloud vorliegen. Noch ehe Sie überhaupt den Hybrid Configuration Wizard ausgeführt haben, sollten Sie in Exchange Online alle Empfänger der beiden lokalen Umgebungen sehen. Das betrifft auch die Verteiler u.a.

ADSync out of Scope

Ich möchte in dem Zuge noch mal explizit darauf hinweisen, dass durch ADSync alle Empfänger beider lokaler Exchange Organisationen in den gemeinsamen Tenant synchronisiert werden. Die Anwender, die also schon ein Exchange Online Postfach nutzen, sehen alle Empfänger. Das bedeutet aber nicht, dass dies für alle Umgebungen der Fall ist.

  • Org1 sieht nur Org1
    Die Benutzer, die weiterhin in der lokalen Exchange Umgebung von Organisation1 sind, sehen nur ihre Empfänger. Dies beinhaltet nicht die Cloud-Only Empfänger und auch nicht die Empfänger aus Org2
  • Keine gemischte Verteiler/Doppelte Verteiler
    Auch die Mitglieder von Mail-Verteilern werden durch ADSync zwar synchronisiert aber sind dennoch getrennt. In der Exchange Online Welt erscheinen die Verteiler beider Exchange OnPremises Umgebungen aber können dort nicht verwaltet werden. Sie können auch keine Mitglieder der anderen Exchange Organisation enthalten.

Als Tabelle wird das noch einmal klar.

Benutzer Org1 Empfänger Org2 Empfänger Cloud Empfänger Mitglied Org1 Verteiler Mitglied Org2 Verteiler

Org1 Postfach

Ja

Nein

Nein

Ja

nein

Org2 Postfach

Nein

Ja

Nein

Nein

Ja

Exchange Online Postfach

Ja

Ja

Ja

Wenn Org1 Remote Mailbox

Wenn Org2 Remote Mailbox

Wenn Sie die roten Flecken nun auch grün machen wollen, dann müssen Sie auch einen Verzeichnisabgleich zwischen den beiden Exchange OnPremises Umgebungen bereitstellen. Jeder Empfänger aus der einen Exchange OnPremises Organisation muss als Kontakt in der anderen Exchange OnPremises Organisation angelegt und auch gepflegt werden. Datei müssen Sie natürlich aufpassen, dass der ADSync diese Kontakte nicht auch noch versucht in der Cloud anzulegen. Entweder er schafft es diese an die eh schon bestehenden Postfächer zu "mergen" oder sie schließen die Kontakte der jeweils anderen Exchange Organisation in ADSync entsprechend aus. (eigene OU, Filterattribut).

Sie sollten die Kontakte dann auch nicht als Mitglieder in lokalen Verteilern aufnehmen, da diese dann ja nicht in der Cloud als Mitglied gepflegt werden könnten. Besser ist es hier die Postfächer selbst in die Verteiler der Organisation aufzunehmen und die Gruppe der einen Umgebung als Kontakt in der anderen Umgebung aufzunehmen.

Das Thema "Identity" und "Verzeichnisabgleich" kann also deutlich komplexer werden. Ich werde hier nicht weiter darauf eingehen.

HCW

Die Konfiguration der Hybrid-Bereitstellung ist relativ einfach, wenn Sie sich auf "MinHybrid" oder "KlassicHybrid" beschränken.

Meines Wissens ist "ModernHybrid" noch nicht möglich, da sie zwar je einen Agenten pro Exchange Umgebung installieren könnten aber die Cloud nicht unterscheiden kann, welcher Agent nun genutzt werden soll.

Wer also "Free/Busy" benötigt und damit nicht mit "MinHybrid" eine schnelle Migration anstrebt, muss wohl oder über "Classic-Hybrid" umsetzen. Dazu gehört natürlich.

  • Autodiscover: Eigene SMTP-Domain pro ExchangeOrg
    Exchange Online sucht ja per "autodisover.<maildomain>" den Weg zu den lokalen Installationen
  • Eigene EWS-Veröffentlichung
    Entsprechend muss jede Exchange Organisation über einen EWS-Zugang verfügen
  • Eigener SMTP-Transport
    Für die Mailübertragung muss Exchange Online auch zu jedem System eine Verbindung aufbauen können und eingehende Verbindungen über ein Zertifikat erkennen.

Allerdings brauchen Sie zumindest mit Exchange 2013/2016 als Frontend-Server kein MFG Microsoft Federation Gateway mehr, da OAUTH genutzt wird. Wenn in der Quelle aber nur Exchange 2010 vorhanden ist, dann ist das Microsoft Federation Gateway weiterhin erforderlich.

Mailrouting

Die Konfiguration durch den HCW legt automatisch die entsprechenden Connectoren für den Mailfluss an. Damit ist der Weg zwischen dem Tenant und der lokalen Umgebung sichergestellt. Hier kann es aber interessant sein, in die Konfiguration einzugreifen. Wenn Exchange Online eh alle Empfänger kennt, dann könnten Sie ja auch ihre lokalen Exchange Server derart konfigurieren, dass Mails an die Empfänger in der anderen Organisation nicht mehr über Internet oder einen direkten Connector sondern "über die Cloud" gehen. Sie könnten damit nicht nur ihr eigenes VPN entlasten sondern auch die ein oder andere Unzustellbarkeit vermeiden. Exchange Online kennt im Idealfall ja eh alle gültigen Empfänger und ist vielleicht schon der zentrale Posteingang, d.h. der MX-Record ihrer Firma läuft schon über Exchange Online Protection.

Um die lokalen Exchange Server dazu zu bringen, alle Mails an die Partnerorganisation über Exchange Online zu routen, reicht es nicht aus, die anderen Domains im Send-Connector zu hinterlegen. Wenn Sie sich den Send-Connector von Hybrid genau anschauen, dann hat er folgende Parameter:

  • Adressraum:  msxfaq.mail.onmicrosoft.com
    Alle Empfänger in der Cloud sind lokal ja eine "Remote Mailbox", "Remote Shared Mailbox" o.ä. mit einer TargetAddres in der Domäne "msxfaq.mail.onmicrosoft.com"
  • Zustellung: MX-Record
    Allerdings hinterlegt Microsoft bei dem Send-Connector keinen Smarthost, sondern nutzt DNS zur Zielermittlung. Der Connector sucht also per DNS nach dem MX-Record für die Maildomäne "mail.msxfaq.onmicrosoft.com" und landet dabei in der Cloud.

Wenn Sie nun beim Adressraum der Org1 einfach noch "lyncfaq.de" als SMTP-Adresse der ORG2 addieren würden, dann würden die Mails zwar zu dem Connector gehen aber dank DNS-Auflösung natürlich nicht zum Tenant gesendet werden sondern zum Server, auf den die Domain per MX-Record auflöst. Daher sollten sie den MX-Record selbst auflösen und diesen Host als "Smarthost" eintragen.

C:\>nslookup -q=mx msxfaq.mail.onmicrosoft.com

Nicht autorisierende Antwort:
msxfaq.mail.onmicrosoft.com     MX preference = 10, mail exchanger = msxfaq-mail-onmicrosoft-com.mail.protection.outlook.com

In meinem Fall sollte ich also von "Zustellung per DNS" auf "Zustellung per SmartHost" umstellen und als Ziel "msxfaq-mail-onmicrosoft-com.mail.protection.outlook.com" eintragen.

Eine andere Lösung sieht so aus, dass sie generell alle Mails von OnPremises zu Exchange Online routen und Microsoft den Versand ins Internet übernehmen lassen.

New-SendConnector `
   -Name "OnPrem to Office365" `
   -AddressSpaces * `
   -CloudServicesMailEnabled $true `
   -Fqdn <fqdn des Servers mit TLS-Zertifikat> `
   -RequireTLS $true `
   -DNSRoutingEnabled $false `
   -SmartHosts <domain>-com.mail.protection.outlook.com `
   -TlsAuthLevel CertificateValidation

Wenn es schon einen Connector gibt, sollten Sie den bestehenden Connector entsprechend anpassen. In die Gegenrichtung müssen Sie natürlich nichts anpassen

FreeBusy

Durch die Einrichtung des Hybrid Mode mit beiden Exchange OnPremises Umgebungen sollten die Cloud Benutzer mit den lokalen Anwendern problemlos auch die Frei/Belegt-Zeiten nutzen können. DAs ist aber noch keine Lösung vor die Nutzung von Frei/Belegt-Zeiten zwischen den beiden OnPremises Umgebungen. Wenn dies erforderlich ist, müssen Sie dies manuell einrichten.

Auf der Seite Hybrid FreeBusy habe ich dazu ausführlich die Funktion beschrieben, wie zwei Firmen mit Hybrid und zwei Tenants diese Funktion erreichen können. Wenn Sie einen Tenant haben, dann gibt es dennoch zwei OnPremises Umgebungen und die Herausforderungen sind sehr ähnlich. Die lokale Exchange Umgebung kann ja gar nicht wissen, ob der Empfänger der andren Domäne nun schon in der Cloud oder noch OnPremises ist. Da weder der Exchange Online Service noch der OnPremise-Service aber ein Redirect oder Proxying macht, muss ihr eigener Exchange Server gleich die richtige Gegenstelle fragen.

Das kann er nur, wenn er über einen entsprechenden Kontakt geleitet wird. Sie können also eine Free/Busy-Verbindung von msxfaq.de zu lynfaq.de über die beiden OnPremises Server einrichten und für die Cloud auf die onmicrosoft.com-Adresse verweisen. Sie brauchen dann aber im AD-Forest von msxfaq.de einen Exchange MailContact, der als Zieladresse entweder auf lyncfaq.de oder auf msxfaq.mail.onmicrosoft.com verweist. Das richtig Ziel für die TargetAddress ist davon abhängig, wo das Postfach des Empfängers auf der anderen Seite ist.

Wenn ein Postfach im Ziel verschoben wird, muss analog der Kontakt in der abfragenden Umgebung aktualisiert werden. Denken Sie aber auch hier wieder daran, dass Sie den Kontakt nicht mit ADSync in die Cloud replizieren, da sie ansonsten wieder doppelte Kontakte oder Fehlermeldungen aufgrund doppelt vergebener Mailadressen haben.

Teams u.a.

Zuletzt müssen natürlich auch noch Microsoft Teams und all die anderen Produkte geprüft werden. Microsoft Teams kann z.B. auf den Kalender des Anwenders zugreifen. Das funktioniert auch, wenn das Postfach noch "OnPremises" liegt. Dazu sind aber mehrere Dinge erforderlich:

  • AutodisoverV2
    Teams macht eine AutodiscoverV2-Anfrage gegen Exchange Online und erwartet als Antwort die EWS-URL
  • OAUTH2-Anmeldung
    Diese Funktion wird normalerweise mittlerweile durch den HCW mit eingerichtet. Eventuell müssen sie die aktuelle Version des HCW noch einmal ausführen.
  • EWS-Zugriff
    Dann greift Teams über das Backend auf den lokalen Exchange Server per EWS zu und authentifiziert sich per OAUTH

Aber es funktioniert dann auch mit mehreren lokalen Exchange-Umgebungen. Voraussetzung ist natürlich, dass jede OnPremises-Umgebung ihre eigene eindeutige SMTP-Domain hat. SMTP-Adress-Sharing ist hier nicht möglich und wenn sie die Regel befolgen, dass UPN=SMTP=SIP-Adresse ist, dann verbietet sich natürlich auch ein Sharing der UPN-Domains.

Weitere Links