Hybrid Manuell

Auf dieser Seite beschreibe ich die Zusammenhänge von "Exchange Hybrid", damit Sie ggfls. auch Umgebungen konfigurieren können, die laut Microsoft nicht vorgesehen sind.

Beachten Sie dazu auch die Seite Hybrid Topologien

Was war noch mal Hybrid?

Wenn eine Firma auf ihrem On-Premises Exchange System mehrere Tochterfirmen mit betreibt und diese nun in einen eigenen Tenant migriert werden sollen, dann wäre eine geteilte Konfiguration durchaus interessant.

Die Frage ist dabei aber, welche Einstellungen für "Hybrid" eigentlich vorgenommen werden müssen. Das Commandlet "Set-Hybrid-Konfiguration" liefert z.B. eine "Feature-Liste", die ein ganz guter Ansatzpunkt ist:


Quelle: https://docs.microsoft.com/en-us/powershell/module/exchange/set-hybridconfiguration?view=exchange-ps#parameters

Wenn Sie sich überlegen, welche Funktionen sie für die Koexistenz bereitstellen müssen und wie diese auch zwischen mehreren Tenants konfiguriert werden, dann sollten Sie auch ohne HCW eine vergleichbare Funktion erreichen können.

Ich brauche nicht drauf hinzuweisen, dass Sie bei Problemen wohl keine Unterstützung von Microsoft erwarten dürfen.

Zumal auch der HCW nur eine Teilmenge der Konfiguration beschreibt und prüft. Es kann durchaus weitere Funktionen von Exchange und Office 365 geben, die nicht dokumentiert oder erst später addiert werden. Sie sollten sich also schon vorher entsprechende Test-Routinen überlegen.

DirSync

Um die meiner Ansicht nach wichtigste Voraussetzung kümmert sich der HCW nämlich gar nicht. Er prüft nicht einmal im Tenant nach, ob ein Verzeichnisabgleich vorhanden ist. Für die überwiegende Anzahl von Installation dürfte aber eine aktive ADSync-Installation für einen Hybrid-betrieb essentiell sein. Nur dann "kennt" die Cloud die lokalen Benutzer und ob diese ein Postfach haben. Wenn dies nicht vorhanden ist sehen die ersten Exchange Online Anwender nur einen Bruchteil der Empfänger und Gruppenmitgliedschaften von Verteilern sind nicht aktuell.

Das Thema ist so wichtig, dass es mehr als nur eine Seite auf der MSXFAQ dazu gibt.

Solange sie aber nur eine OnPremise-Umgebung mit einem Forest mit einem Tenant verbinden, ist das Setup überschaubar. Wenn Sie mehrere On-Premises Umgebungen haben, dann müssen Sie darauf achten, dass ein ADSync die Informationen aus allen Forests liest und den gemeinsamen Tenant schreibt. Vergessen Sie dabei nicht, das die Benutzer in Exchange Online dann automatisch alle Empfänger aller Exchange Organisationen sehen. Für die lokalen Anwender müssen Sie aber selbst dafür sorgen, dass die Postfächer in der jeweils anderen Umgebung bereitgestellt werden. Auch dazu gibt es schon einige Seiten:

Wenn aber HCW schon nicht prüft, ob ADSync konfiguriert ist, dann könnte man daraus auch ableiten, dass ADSync gar keine unabdingbare Voraussetzung ist, sondern sie auch anderweitig den Betrieb sicherstellen können. Es gibt sogar unterstützte ADSync-Topologien, in denen zwei Tenants mit jeweils eigenem ADSync nur eine exklusive Teilmenge an Empfängern synchronisieren. Mittlerweile ist es sogar möglich, dass das gleiche AD-Konto in mehrere Tenants repliziert wird. Allerdings sind dabei einige Besonderheiten hinsichtlich Exchange zu beachten.

Wir sollten also im Hinterkopf behalten, dass wir irgendwie sicherstellen müssen, dass bei einer Koexistent von Exchange On-Premises und Exchange Online die Postfächer der einen Seite auf der jeweils anderen Seite als Empfänger vorliegen.

SecureMail und CentralizedTransport

Es ist kein Problem, mehrere Exchange Organisationen per SMTP zu verbinden. Wenn jede Umgebung ihre eigene Routing-Domain hat, die per MX-Record auflösbar ist, dann funktioniert dies vermutlich schon automatisch. Aber es ist nicht sicher aus zwei Gründen:

  • Verschlüsselung, Opportunistic TLS
    Es wird nicht sichergestellt, dass die SMTP-Verbindung zwingend TLS nutzt. Da es aber ja "interne Mails" oder zumindest wichtige Mails mit bekannten Partnern sind, sollten Sie eine TLS-Übertragung erzwingen
  • Spamfilter
    Wenn Sie schon TLS nutzen und sich die Gegenseite mit einem Zertifikat ausweisen kann oder eine feste IP-Adresse nutzt, dann können Sie dieses Wissen auch beim Spamfilter konfigurieren, damit die Mails zwischen den Partnern etwas "freundlicher" behandelt werden. Das ist sogar erforderlich, wenn Sie SMTP-Sharing betreiben. (Siehe auch Tenant Domain Sharing).

Der Hybrid Configuration Wizard übernimmt diese Konfiguration, indem er drei (früher vier) Einstellungen vornimmt:

  • Exchange Online: Inbound Connector
    Damit Mails von ihrer On-Premises-Umgebung von ihrem Tenant angenommen werden, legt er einen Inbound Connector an und nutzt dazu das Zertifikat ihres Exchange Servers
  • On-Premises Send Connector
    Passend dazu wird dann ein Send-Connector auf dem lokalen Exchange angelegt, der die Mails an die TargetDomain "<tenantname>.mail.onmicrosoft.com" per MX-Record an den passenden Eingangsserver zu ihrem Tenant routet und ihr Zertifikat nutzt.
[PS] C:\>Get-SendConnector "Outbound to Office 365"| fl

AddressSpaces                : {smtp:msxfaq.mail.onmicrosoft.com;1}
CloudServicesMailEnabled     : True
DNSRoutingEnabled            : True
DomainSecureEnabled          : False
Identity                     : Outbound to Office 365
RequireTLS                   : True
TlsAuthLevel                 : DomainValidation
TlsCertificateName           : CN=AlphaSSL CA - SHA256 - G2, O=GlobalSign nv-sa, C=BE, CN=*.msxfaq.de,OU=Domain Control Validated
TlsDomain                    : mail.protection.outlook.com
  • On-Premises "Receive Connector"
    Bis Exchange 2013 hat der HCW noch einen eigenen Receive Connector angelegt, um die Mails aus der Cloud anzunehmen. Seit Exchange 2016 wird der bestehende Connector einfach etwas angepasst. Wenn eine Verbindung per TLS mit dem Client-Zertiifkat "mail.protection.outlook.com" ankommt, dann wendet ihr Exchange Server die Konfiguration "AcceptCloudServicesMail" an.
[PS] C:\>(Get-ReceiveConnector "EX2016\Default Frontend EX2016").tlsdomaincapabilities | fl

Domain             : mail.protection.outlook.com
Capabilities       : AcceptCloudServicesMail
SmtpX509Identifier :
  • Exchange Online
    Passend dazu gibt es in Exchange Online dann einen "Outbound Connector", der Mails an ihre native SMTP-Domain per Smarthost an den von ihnen hinterlegten Servernamen sendet.

Diese Konfiguration können Sie natürlich ebenfalls von Hand verwalten. Denken Sie aber daran, dass zwischen Exchange Online und On-Premises laut Microsoft kein 3rd-Party-Relay stehen darf, da Exchange durchaus ein paar "Erweiterungen" wie XOORG und Exchange nutzt, die sonst keiner versteht. Auch der Sonderfall Hybrid Centralized Mail Transport und die Probleme mit Centralized Mail Transport mit Multi Forest müssen Sie beachten.

1:N Routing

Wenn Sie nun eine On-Premises Umgebung mit mehreren Tenants verbinden wollen, dann haben mindestens zwei Herausforderungen:

Internet -> On-Prem -> Cloud

Von ihrem lokalen Exchange System müssen Sie ein Mailrouting zu zwei Tenant aufbauen, was aber seitens Exchange Online natürlich die gleiche "Wolke" ist. Der HCW baut ihnen dazu einen Send-Connector, der Mail an "<tenantname>.mall.onmicrosoft.com" mit TLS-Zwang per MX-Record zustellt und dabei optional ein Zertifikat nutzt. Sie haben nun die Wahl, ob sie nun einen Connector bauen, in dem mehrere Domains in der Form "<tenantnameX>.mall.onmicrosoft.com" addiert werden oder ob sie für jeden Kunden einen einen Send-Connector bauen. Eigene Connectoren könnten Sie mit eigenen Zertifikaten ausstatten. Dazu ist es wichtig das eingehende Routing bei Exchange Online zu verstehen:


Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143

Entsprechend müssen Sie in der Cloud dann die "Inbound Connectoren" anlegen. Die Cloud will ja wissen, wer da ankommt und zu welchem der vielen Tenants die Kommunikation gewidmet ist. Exchange Online sollte daher ihre gemeinsam genutzte On-Premises Umgebung unterscheiden können. Das geht am besten mit Zertifikaten, die ihnen aber entweder ihr Kunde überlässt oder der im Tenant wird z.B. eine Subdomain des OnPrem-Hosters als Accepted Domain konfiguriert.

Ohne Zertifikate können alle Tenants natürlich auch die IP-Adresse verwenden, wobei dann Exchange die "MAIL FROM" betrachtet. Der Connector greift also nur, wenn eigene Absender von On-Premises in die Cloud senden. Für externe Mails, die über das On-Premises-System zu Exchange Online geroutet werden, sollten Sie dann einen Partner Connector anlegen, der die Mails vom On-Premises System für die RemoteDomains "*" annimmt. Nebenbei haben Sie dann auch den Hintereingang geschlossen (Siehe Exchange Online als Nebeneingang für Mailempfang)

Tenant -> On-Prem -> Internet

In die Gegenrichtung müssen sie unterscheiden, ob sie nur die Mails an ihren eigenen Empfänger zum On-Premises-System routen möchten oder generell alle Mails. Im ersten Fall legen Sie einfach einen Outbound-Connector vom Typ "OnPrem" in der Cloud an, der seine Mails an den On-Premises Exchange Server per TLS sendet. Dort kommt dann eine Verbindung aus dem Internet an, die per MTLS mit dem einem Zertifikat abgesichert ist, welches auf den Namen "protection.mail.outlook.com" ausgestellt ist.

Meist hat der erste HCW-Lauf schon On-Premises den Receive Connector angepasst, so dass hier drin steht.

Set-ReceiveConnector `
   -Identity „EX2016\Default EX2016“ `
   -TlsDomainCapabilities "mail.protection.outlook.com:AcceptCloudServicesMail"}

Damit "erkennt" Exchange On-Premises die verschiedenen Tenants und behandelt diese Mails anders, wenn der Absender oder Empfänger eine Adresse aus den "AcceptedDomains" hat.

Aber das ist noch nicht alles:

  • AcceptedDomain
    Zum Mailrouting gehört natürlich dazu, dass Sie die Domain entsprechend als "Accepted Domain" sowohl in den richtigen Tenants als auch On-Premises eintragen.
  • Empfängerrichtlinie
    Die Domain sollte z.B. über Empfängerrichtlinien den Empfängern (Postfächer aber auch Verteiler, Räume etc.) zugewiesen werden, denn ADSync muss ja die "<tenantname>.mail.onmicrosoft.com"-Domain auch in die Cloud replizieren. Denken Sie auch daran, dass es in der Cloud Empfänger gibt, die eine Mailadresse ihrer Domain haben.
  • Remote Domain
    Über die Remote Domains sollten Sie dann die Mailformatierung (RTF/MAPI), die OOF-Meldungen etc. konfigurieren. Das ist aber nicht "sicher multitenant", da solche Einstellungen ja zumindest On-Premises für alle Nutzer gelten.

Hier sind also Einschränkungen zu erwarten, weil vielleicht "zu viel" geht. Exchange On-Premises ist halt kein echtes "Multi Tenant System" mehr.

Aber rein von der Konfiguration sollte es kein Problem sein, auch mehrere Tenants mit einer Exchange On-Premises-Organisation zu verbinden, auch wenn Microsoft dies natürlich aktuell (Stand Jun 2022) nicht mittels HCW unterstützt.

Für eine komplette Liste der Änderungen durch den HCW verweise ich auf die Seite HCW im Detail.

MoveMailbox

Für die Migration von Postfächern zwischen Exchange Online und On-Premises gibt es die "Remote Verschiebeanforderung". Technisch ist die Cloud hier der aktive Part, der die Mails aus dem On-Premises-Postfach in die Cloud "saugt" oder wieder zurückspielt. Damit der On-Premises-Server aber die Cloud gewähren lässt, muss hier ein Migration-Endpunkt konfiguriert werden. Genau genommen muss der MRSProxy und OAUTH auf dem Server aktiviert werden, der von Exchange Online angesprochen wird. Das macht der HCW für sie.

# Identity zur Lesbarkeit umgebrochen. Dies muss ein String sein

Set-WebServicesVirtualDirectory `
   -Identity 'CN=EWS (Default Web Site),CN=HTTP,CN=Protocols,CN=EX01,
              CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),
              CN=Administrative Groups,CN=ORG,CN=Microsoft Exchange,CN=Services,
              CN=Configuration,DC=msxfaq,DC=net' `
   -MRSProxyEnabled: $true

Der HCW übernimmt natürlich nicht die Konfiguration ihres Reverse Proxy, Firewall, Loadbalancer. Die URLs müssen per HTTPS auch anonym zumindest von Exchange Online erreichbar sein. Als Authentifizierung kommt OAUTH zum Einsatz.

Für eine komplette Liste der Änderungen durch den HCW verweise ich auf die Seite HCW im Detail.

FreeBusy/Mailtips/OnlineArchive

Der dritte Aspekte der Hybrid-Bereitstellung ist die Kommunikation der Server per HTTPS miteinander. Wenn ein Benutzern sein Postfach "On-Premises" hat und z.B. einen Termin mit einem Postfach in Exchange Online plant, dann fragt Outlook den eigenen Exchange Server nach den Frei/Belegt-Zeiten. Der Exchange Server fragt dann den Zielserver. Im LAN vertrauen sich die Exchange Server aber über die Grenzen der eigenen Organisation hinaus muss eine Partnerschaft aufgebaut werden. Das gilt in beide Richtungen, denn auch ein Exchange Online -Postfach möchte ja die Daten vom On-Premises Server erhalten, der die Authentifizierung des Servers akzeptieren muss.

Wenn Sie ihre Postfächer noch On-Premises nutzen aber z.B. das Postfacharchiv aus Platzgründen in die Cloud verlagern wollen, dann muss auch hier der lokalen Exchange Server einen Zugriff auf die Cloud-Dienste bekommen.

Entsprechend sind die Authentication Server und das Organization Relationship auf beiden Seiten von Exchange einzurichten.

MessageTracking

Bei der echten Hybrid-Bereitstellung kann ein Administrator sogar über die Grenzen der eigenen Organisation hinaus ein Messagetracking durchführen. Welche Konfiguration dazu nun genau erforderlich ist, habe ich noch nicht ermittelt. Ich habe das übergreifende Tracking eigentlich auch noch nie bewusst genutzt, da ich per PowerShell zielgerichtet suche und der Weg einer Mail anhand der Konfiguration ja vorgegeben ist.

OwaRedirection

Soweit ich es einschätzen kann, erkennen Exchange On-Premises und Exchange Online allein an der TargetAddress eines Benutzers, dass das Postfach ggfls. auf der anderen Seite liegt und OWA verweist den Anwender dann auf die andere URL. Dazu muss natürlich in der Organization Relation Ship der Parameter "-TargetOwaURL" korrekt gefüllt sein.

Photos

Meines Wissens lädt Outlook die Bilder selbst per HTTPS aus dem Postfach des Benutzers und muss sich dazu natürlich authentifizieren. Aber auch OWA möchte ja Bilder anzeigen, die dann der Exchange OWA-Server vom Postfachserver beziehen muss. Die Hintergründe und Anforderungen haben ich dazu aber noch nicht im Detail aufgeschlüsselt.

Es gibt aber in der "Organization Relationship" den Parameter "PhotosEnabled", so dass ich auch hier auf EWS und die korrekte Einrichtung von OAUTH tippe.

Einschätzung

Wenn Sie eine Umgebung betreiben, die von Microsoft offiziell unterstützt wird, dann würde ich immer den HCW einsetzen, um die Konfiguration korrekt auszuführen. Das geht immer, wenn sie eine 1:1 Beziehung zwischen einem Exchange Online Tenant und einer Exchange On-Premises Umgebung haben. Es ist mittlerweile sogar erlaubt, bis zu fünf Exchange On-Premises Umgebungen mit einem Tenant zu verbinden. Allerdings ist es nicht supportet und mit dem HCW nicht möglich, eine Exchange Organisation gleichzeitig mit mehreren Tenants zu verbinden.

Dann kommt die Handarbeiten, dass Sie sich ein Konzept zurecht legen, bei dem Sie z.B. für jeden Tenant einen eindeutigen Namensraum festlegen, je eine eigene ADSync-Instanz nutzen, die dann die Teilmenge an Benutzern in den jeweiligen Tenant replizieren und auf der gemeinsamen On-Premises-Topologie entsprechend die "<tenantname>.mail.onmicrosoft.com"-Domains sowohl als "Accepted Domains" anlegen und über Empfängerrichtlinien an die betreffenden Benutzer zuweisen. Dann fehlt nur noch das Mailrouting und die Organization Relationships.

Klingt einfach aber kann verzwickt sein. Eine fertige Anleitung hierzu habe ich aufgrund der eher seltenen Anwendung nicht. Zudem ist auch Exchange Online ein "Moving Target".

Weitere Links