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.

Die Grenzen von HCW

Für den parallelen Betrieb von Exchange Online mit Exchange OnPremises hat Microsoft eine "Hybrid Konfiguration" vorgesehen, mit der die Anwender auf beiden Seiten möglichst ohne Einschränkungen miteinander arbeiten können. Die Einrichtung kann der Administrator sehr elegant über den HCW - Hybrid Configuration Wizard durchführen, welcher sowohl in der lokalen Exchange Konfiguration als auch in Exchange Online die erforderlichen Eintragungen durchführt. Details dazu finden Sie auf HCW im Detail.

Allerdings unterstützt der HCW dabei immer nur eine Kopplung von einem Tenant mit 1-5 OnPremises Exchange Umgebung.

 

Wer eine lokale Exchange Umgebung aber mit zwei oder mehr unterschiedliche Tenants in Koexistenz betreiben will oder muss, kann den HCW dazu nicht nutzen.

Der HCW kann nur eine Topologie pro Exchange Organisation speichern und wenn Sie die zweite Hybrid-Bereitstellung per HCW einrichten wollen, überschreiben Sie quasi die erste Konfiguration. Zudem nimmt HCW keine Rücksicht auf OUs und Segmentierungen, addiert die "<tenantname>.mail.onmicrosoft.com"-Adresse in die Default Policy und einige andere Dinge, die den Einsatz des HCW hier scheitern lassen. Weitere Details dazu finden Sie auf HCW Features&Topologien. Offiziell kann eine Exchange OnPremises Organisation nur mit genau einem Tenant verbunden werden. Technisch ist dies aber nur durch den HCW und vielleicht das Microsoft Support Statement vorgegeben.

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

Hybrid Dokument

Wenn Sie den Exchange Hybrid Wizard ausgeführt haben, dann hat er alle eingegebenen Informationen genutzt, um ihre Systeme zu konfigurieren. Er hat aber zusätzlich auch die Informationen in einem "Hybrid Configuration Document" im lokalen Active Directory abgelegt. So werden bei einem weiteren Start des HCW die gleichen Werte erneut vorgeschlagen.

[PS] C:\Windows\system32>Get-HybridConfiguration

ClientAccessServers       : {}
EdgeTransportServers      : {}
ReceivingTransportServers : {EX16}
SendingTransportServers   : {EX16}
OnPremisesSmartHost       : hybrid.msxfaq.de
Domains                   : {msxfaq.com, msxfaq.de}
Features                  : {FreeBusy, MoveMailbox, Mailtips, MessageTracking, OwaRedirection, OnlineArchive,
                            SecureMail, Photos}
ExternalIPAddresses       : {}
TlsCertificateName        : <I>CN=GlobalSign RSA OV SSL CA 2018, O=GlobalSign nv-sa, C=BE<S>CN=*.msxfaq.de, 
                            O=FCEDV, L=Hoevelhof, S=Nordrhein-Westfalen, C=DE
ServiceInstance           : 0
AdminDisplayName          :
ExchangeVersion           : 0.20 (15.0.0.0)
Name                      : Hybrid Configuration
DistinguishedName         : CN=Hybrid Configuration,CN=Hybrid Configuration,CN=MSXFAQ,CN=Microsoft
                            Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de
Identity                  : Hybrid Configuration
Guid                      : 99ef51e4-7dc3-46d0-aacf-25e0b87039da
ObjectCategory            : msxfaq.de/Configuration/Schema/ms-Exch-Coexistence-Relationship
ObjectClass               : {top, msExchCoexistenceRelationship}
WhenChanged               : 02.05.2022 18:10:29
WhenCreated               : 26.01.2015 12:27:15
WhenChangedUTC            : 02.05.2022 16:10:29
WhenCreatedUTC            : 26.01.2015 11:27:15
OrganizationId            :
Id                        : Hybrid Configuration
OriginatingServer         : DC01.msxfaq.de
IsValid                   : True
ObjectState               : Unchanged

Interessant ist hier der Parameter "Features". Diese Information wird übrigens auch im Exchange Online hinterlegt, so dass der Microsoft Support ihre Eingaben verifizieren kann.

Allerdings ist genau das auch heute das einer der Gründe, warum Sie eine Exchange Organisation nur mit einem Tenant einrichten können. Es gibt genau ein solches Dokument und jeder zweite Aufruf des HCW wird die vorherige Konfiguration überschreiben. Allerdings macht ein zweiter Aufruf mit einem anderen Tenant die vorherige Konfiguration nicht rückgängig. Ich kann mir gut vorstellen, das Microsoft solche Sonderfälle nicht supporten kann oder will. Damit sind sie aber nicht per Se unmöglich. Wenn eine Firma auf ihrem OnPremises 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 OnPremises 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 OnPremises 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 vier Einstellungen vornimmt:

  • Exchange Online: Inbound Connector
    Damit Mails von ihrer OnPremises-Umgebung von ihrem Tenant angenommen werden, legt er einen Inbound Connector an und nutzt dazu das Zertifikat ihres Exchange Servers
  • OnPremises 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
  • OnPremises "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 OnPremises 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. 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 OnPremises 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 OnPremises für alle Nutzer gelten.

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

Aber rein von der Konfiguration sollte es kein Problem sein, auch mehrere Tenants mit einer Exchange OnPremises-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 OnPremises gibt es die "Remote Verschiebeanforderung". Technisch ist die Cloud hier der aktive Part, der die Mails aus dem OnPremises-Postfach in die Cloud "saugt" oder wieder zurückspielt. Damit der OnPremises-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 "OnPremises" 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 OnPremises Server erhalten, der die Authentifizierung des Servers akzeptieren muss.

Wenn Sie ihre Postfächer noch OnPremises 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 OnPremises 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 OnPremises Umgebung haben. Es ist mittlerweile sogar erlaubt, bis zu fünf Exchange OnPremises 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 OnPremises-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