Centralized Mail Transport mit Multi Forest

Anfangs konnte ein Office 365 Tenant nur mit genau einer Exchange OnPremises-Organisation verbunden werden. Wollte eine Firma dabei alle Mails aus der Cloud immer über die lokale Umgebung versenden, dann war Hybrid Centralized Mail Transport das Mittel der Wahl. Das funktioniert aber nicht mehr, wenn Sie zwei lokale Exchange Umgebungen im Hybrid-Mode mit einem Tenant verbunden haben

Hybrid mit einem Forest

Wenn Sie einfach den Hybrid Configuration Wizard nutzen, dann legt er ihnen OnPremises einen Send-Connector an, der alle Mails an <tenantname>.mail.onmicrosoft.com zu ihrem Tenant sendet. Auf der Gegenseite gibt es einen Inbound-Connector zur Annahme der Mails. Weiterhin gibt es in der Cloud einen Outbound-Connector, der Mails an ihre registrierten Domains zum lokalen Server sendet.

Ohne weitere Konfiguration werden aber Mails der Exchange Online Benutzer nicht über die OnPremises-Umgebung gesendet sondern Exchange Online sendet selbst Mails ins Internet. Das ist der Default, weswegen Sie z.B. auch den SPF-Record um die Microsoft Server ergänzen müssen.

Eingehende Mails landen in dem Bild aber weiter OnPremises und werden dann in die Cloud gesendet. Theoretisch könnten externe Mailserver auch Mails direkt an Office 365 senden. Gute Mailserver halten sich aber den MX-Record. Dennoch gibt es da schon einen Hintereingang:

Centralized mit einem Forest

Oft haben die Firmen aber lokal zusätzliche Funktionen, die auch für die Cloud-Postfächer greifen müssen, z.B. SMIME-Signatur auf dem Gateway, Disclaimer-Lösungen, JournalArchive oder Sie wollten einfach nur verbergen, dass Sie auch in der Cloud unterwegs sind.

Für diese Konfiguration gibt es im HCW extra die Einstellung "Centralized Mail Transport". Über diese kleine Checkbox, die im Connector nur ein Flag ist, routet Exchange Online alle Mails über die OnPremises Umgebung. Dies gilt insbesondere für alle Mails Richtung Internet.

Zwei Forests

Nun ist es aber seit einiger Zeit möglich, dass ein Exchange Online Tenants zeitgleich mit zwei Exchange OnPremises Topologien verbunden ist. Natürlich hat dabei jede OnPremises-Umgebung ihre eigene dedizierte Routingdomains und die Cloud kennt alle Domänen beider OnPremises-Topologien. Natürlich muss auch ADSync entsprechend konfiguriert werden, damit er Office 365 - Multi-Forest Umgebung unterstützt und alle Empäfnger beider lokaler Installation in Exchange Online bekannt sind.

Jeder Exchange Admin startet für sich den HCW und richtet wieder "seine" drei Connectoren ein. Das Routing vom Tenant zur jeweiligen OnPremises-Umgebung erfolgt über die SMTP-Domäne des Ziels. Auch hier sendet Exchange Online daher Mails an das Internet nicht über eine lokale Installation sondern direkt vom Tenant raus.

Allerdings sollten Sie hier nun nicht auf den Gedanken kommen, auf einem oder sogar beiden HCW-Läufen die Option "Centralized Mail Transport" zu aktivieren. Das Ergebnis wäre wohl ein Chaos, da Exchange Online dann z.B. Mails an "uclabor.de" vielleicht durch "msxfaq.de" schleusen würde.

Internet Routing über OnPremises

Sie wollen hier sicher mehr Kontrolle haben, welche Mail letztlich über welches System geroutet wird. Das geht aber nicht mehr über die normalen Connectoren. Hier müssen wir mit Transportregeln und eigenen Connectoren arbeiten. In der Cloud gibt es die Funktion Exchange Online Connector Routing, welche in Exchange OnPremises nur über 3rd Party Produkte verfügbar ist.

Bitte ändern sie nie die Connectoren, welche durch den HCW angelegt wurden, denn diese werden beim nächsten Lauf des HCW eventuell wieder überschrieben.

In dem folgenden Beispiel möchte ich z.B. erreichen, dass alle Cloud-Benutzer mit dem Absender aus "msxfaq.de" über die OnPremises Umgebung versenden, während die Cloud-Anwender von uclabor.de direkt aus der Cloud senden.

Ich aktiviere bei der Einrichtung des HCW daher nicht die Funktion "Centralized Transport", sondern lege einen zweiten "Outbound Connector" von dem Exchange Online Tenant zur OnPremises-Umgebung an. Er kann ruhig den gleichen Smarthost nutzen, den auch der vom HCW angelegte Connector nutzt. Der Connector wird über über eine Transportregel angesprochen, die wie folgt konfiguriert wird:

Wenn Absenderdomain = msxfaq.de
Dann Reroute zu Connector "Internet via MSXFAQ"

Diese Regel reicht damit schon aus, dass Mails aus dem Tenant abhängig von der Absenderadresse zum OnPremises-Umgebung von MSXFAQ geroutet wird.

Achtung. Die Regel ist so noch nicht korrekt, denn es kann ja auch eingehende Mails mit dem Absender geben.

Wir haben ja eine Hybrid-Bereitstellung und wenn nun ein Benutzer aus dem OnPremi-System mit der Absenderadresse aus "msxfaq.de" eine Mail an einen Empfänger im Tenant sendet, dann triggert dies auch die Regel. Wir müssen als sicherstellen, dass dieser Fall berücksichtigt wird. Eine Möglichkeit ist die Anpassung in der Art:

Wenn Absenderdomain = msxfaq.de
Ausser  Empfängerdomain = msxfaq.de
Dann Reroute zu Connector "Internet via MSXFAQ"

Sie könnten auch mit den Bedingungen "Empfänger ist intern" etc. arbeiten. Solche Regeln sind ja nie alleinstehend, sondern es gibt Wechselwirkungen mit anderen Regeln. Daher möchte ich noch einen anderen Weg vorstellen, indem ich in jeder Exchange Organisation eine Regel anlege, die einen Header mit dem Namen der Exchange Organisation anlegt, z.B.

Regel1: Onprem MSXFAQ:
Jede Mail
Ausser  X-SourceOrg vorhanden
Addiere Header "X-SourceOrg = MSXFAQ
Regel2: OnPremUCLABOR:
Jede Mail
Ausser  X-SourceOrg vorhanden
Addiere Header "X-SourceOrg = UCLABOR
Regel3: in Exchange ONline:
Jede Mail
Ausser  X-SourceOrg vorhanden
Addiere Header "X-SourceOrg = CLOUD

Der Vorteil ist nun, dass ich die Doppelverarbeitung von Regeln unterbinden kann. Diese Vorarbeit brauche ich z.B. ,wenn ich mittels Transportregel einen Disclaimer addiere und die Mail durch mehrere Stationen läuft. Nichts ist störender als mehrfach angehängte Disclaimer. Mit dieser Vorarbeit kann ich in der "Umleitungsregel" auch dieses Feld als "Ausschluss" oder Filter hinterlegen. Wenn der Header nicht meine eigene Organisation ist, dann sollte ich vielleicht nicht weiter in das Routing eingreifen und damit vielleicht eine Endlosschleife produzieren.

Bei der Story gibt es noch zwei weitere Routing-Richtungen, die sie berücksichtigen müssen:

  • Einlieferung per MX-Record
    In meinem Beispiel nutzt MSXFAQ seinen eigenen OnPremises Server als Mailserver (MX-Record) aber die andere Organisation UCLABOR nutzt als MX-Record schon Exchange Online Protection. Das führt dazu dass auch hier Mails von extern durch die Transportregeln laufen. Wer hier ein "Alle Mails zu OnPrem Umleiten, außer Absender = UCLABOR.DE" einrichtet, leitet unversehens auch all diese Mails aus dem Internet an Cloud-Empfänger auf die OnPremises-Umgebung um. Es gibt Fälle, wo das sogar gewollt ist, z.B. aus Compliance-Gründen. Aber wenn die Mail dann wieder zurück kommt, darf sie natürlich nicht erneut umgeleitet werden
  • System Mails
    Über den Exchange Online Tenant werden ja nicht nur Mails der Exchange Objekt versendet. Office 365 kennt weitere Dienste, die Mails absenden, z.B.: Teams-Einladungen, "Teams-Benachrichtigungen", Teams VoiceMails, SharePoint/OneDrive-Benachrichtigungen u.a., die an ihre Empfänger gehen. Microsoft stellt diese Mails über ihren Tenant zu und natürlich werden auch diese Nachrichten durch die Transportregeln verarbeitet. Der Absender ist hier aber nicht immer ihre primäre Domain sondern eventuell "niemand", d.h. "<>" oder eine <tenantname>.onmicrosoft.com-Adresse, die sie bei den Transportregeln schnell mall vergessen.

Office 365, Exchange Online und die Cloud ist ständigen Weiterentwicklungen und Veränderungen unterworfen. Sie sollten daher ihre Umgebung überwachen, um negative Auswirkungen früh zu erkennen. Wer mit Regeln in das Routing von Nachrichten eingreift, sollte alle Kombinationen überprüfen und z.B. Kennzahlen wie "Unzustellbarkeiten/Zeit" oder "Volumen /Zeit" überwachen, da Sie schnell auf Schleifen oder falsche Regeln hinweisen können

Zusammenfassung

Der Betrieb von zwei oder mehr Exchange OnPremises-Umgebungen mit einem Exchange Online Tenant ist von Microsoft offiziell unterstützt und problemlos möglich. In der Standardeinstellung von Microsoft kümmert sich aber jede der drei oder mehr Exchange Welten um ihre eigene Zustellung an externe Empfänger über das Internet. Wenn Sie den Fluss verändern wollen, darf dies nicht über die Option "Centralized Mail Transport" im HCW erfolgen, denn diese Einstellung auf einem Connector zu einer OnPremises-Plattform hat weitreichende Auswirkungen auf den kompletten Tenant und damit auch die anderen per Hybrid-Mode verbundenen Exchange Organisationen.

Wenn Sie Mails hier anderes routen, als Microsoft dies als Standard vorgesehen hat, können Sie dies per Transport-Regeln mit Umleitung auf entsprechende Connectoren erreichen. Allerdings sollten Sie dann alle mögliche Absender/Empfänger-Konstellationen genau betrachten, um Schleifen und unzustellbare Mails zu verhindern.

Weitere Links