Centralized Mail Transport

Wenn sie Exchange im Hybrid-Mode betreiben, dann haben Sie es genau genommen mit zwei Exchange Organisationen zu tun und jede hat ihre eigene Konfiguration bezüglich dem Empfang und insbesondere dem Versand von Mails. Für jede Organisation steuern sie getrennt, wie diese ihre Mails in das Internet oder zu Partnern sendet. Und das muss wohl überlegt sein, wenn viele Firmen haben heute On-Premises etablierte Spamfilter, Disclaimer-Lösungen und Verschlüsselungsgateways, die natürlich auch von Absendern des Exchange Online Tenants genutzt werden müssen. Microsoft kennt dazu die Funktion des "Centralized Mail Transport".

Beachte dazu auch Office 365: Mail Connector

Establishing Exchange Hybrid Mailflow
https://www.youtube.com/watch?v=1i_SO6nKe0o&t=605s
Sehr gute Beschreibung zum Mailrouting in einer Hybrid Umgebung

Allerdings ist diese Einstellung so dominant, dass Sie auch nicht mehr willentlich einen eigenen Connector für die ein oder andere "Ausnahme"-Domain einrichten können. Sie können es wohl einrichten aber die Konfiguration greift nach meinen Tests (Dez 2016) einfach nicht mehr. Daher beschreibe ich auf dieser Seite einen Weg, wie Sie die Konfiguration "Centralized Mail Transport" mit Ausnahme-Domänen meistern um z.B. Journalmails an einen Archivdienstleister vom Office 365 Tenant auszuleiten, ohne dass Sie alle Mails durch ihre On-Prem-Umgebung routen.

Aus meiner Sicht ist diese Konfiguration maximal am Anfang einer Hybrid-Bereitstellung sinnvoll. Auf Dauer sollten Sie schon daran arbeiten, dass auch Exchange Online ohne Umweg über die On-Premises-Server seine Mail versenden kann.

Centralized Mail Transport

In der Regel senden Postfächer in der Cloud ihre Mails direkt in das Internet und nur Empfänger On-Prem bekommen die Mails über einen passenden Connector. Allerdings gibt es auch die Option, dass alle Mails über die On-Prem-Server geroutet werden. Das ist z.B. erforderlich, wenn Sie durch ein Gateway digital signieren wollen. Hierzu können Sie im Hybrid Konfigurationsassistent die Funktion "Route all Internet-bound messages through your On-Premises Exchange Servers " (Exchange 2010) bzw. "Enable Centralized Mail Transport” (Exchange 2013) aktivieren. Hier erst noch einmal die Einstellung beim Hybrid Konfiguration Wizard, die den Centralized Mailtransport einrichtet.

Wird hierüber die Konfiguration durchgeführt, dann legt der Assistent einige Connectoren im Hintergrund an. Maßgeblich ist hier vor allem der Connector in Office 365, über den alle Mails zum Server On-Premises geroutet werden. Dazu legt der Assistent einen Send-Connector zur Organisation an, wie man in der GUI und noch besser in der Exchange remote PowerShell sehen kann:

PS C:\> Get-OutboundConnector  |fl name,recipientdomains,enabled,RouteAllMessagesViaOn-Premises,IsTransportRuleScoped

Name                          : Outbound to 1191ecb5-aafb-41d5-a616-52a314c7d5db
RecipientDomains              : {*}
Enabled                       : True
RouteAllMessagesViaOn-Premises : True
IsTransportRuleScoped         : False

Achten Sie hier auf den Eintrag "RouteAllMessagesViaOn-Premises:$true"

Sie können über die Exchange Management Shell oder Exchange PowerShell gerne weitere Connectoren mit anderen "RecipientDomains" und abweichenden Smarthosts anlegen aber ihre Mails werden immer über On-Premises geroutet. Anscheinend hat das Exchange Routing in Exchange Online hier eine andere Logik und kümmert sich nicht mehr allein um die "RecipientDomains".


Quelle: https://technet.microsoft.com/en-us/library/jj659050(v=exchg.150).aspx

Das bedeutet natürlich auch, dass Sie ihren Exchange Server so konfigurieren müssen, dass Mails aus Office 365 Postfächern in das Internet über ihre On-Premises -Umgebung als Relay erlaubt sind.

Auch eine direkt an Exchange Online zugestellte Mail wird so immer erst über "On-Premises" gesendet. Damit bauen Sie sich ganz schnell eine Loop, wenn Exchange Online den internen Server nicht als "Meine Org" erkennt.

Centralized Mail Transport mit EOP

Ich habe einige Kunden, die über "Centralized Mail Transport" sicherstellen wollen, dass jede ausgehende Mail von Office 365 auf jeden Fall über die On-Premises Umgebung rausgeht. Was dabei aber gerne übersehen wird ist der Empfang. Rein technisch ist es nämlich weiterhin möglich, dass Sie einen MX-Record auf Office 365 setzen oder unabsichtlich jemand die Mails zu Office 365 sendet. Diese Mails werden von Exchange Online auch angenommen und zugestellt. (Siehe auch Exchange Online als Nebeneingang für Mailempfang) Allerdings ist das Mailrouting dann überraschend. Ich habe es selbst erst festgestellt, als ich den MX-Record einer Domain auf Exchange Online gestellt habe und dann die On-Premises-Umgebung zu Wartungszwecken heruntergefahren wurde. Sehr schnell haben sich Anwender beschwert, dass keine Mails mehr eingehend ankommen. Ein kurzer Blick auf das Portal hat das Verhalten bestätigt:

Da haben sich wohl einige Mails irgendwie gestaut und über das Messagetracking wurde auch sichtbar, wo:

Die Mails wurden zwar von Exchange Online angenommen aber nicht direkt in das Postfach zugestellt, sondern trotzdem zur On-Premises-Umgebung gesendet. Der lokale Exchange Server hat dann erkannt, dass die Zieladresse zu einer "Remote Mailbox" in der Cloud gehört und über einen Connector wieder zurück muss. Exchange Online erkennt dann natürlich dass die Mail nun über einen "Inbound Connector" ankommt, der für Hybrid eingerichtet wurde und stellt dann die Mails wieder zu.

Das ist ein Nebeneffekt von "Centralized Mailbox", der ja genau genommen nichts anderes sagt, also dass alle Mails über die On-Premises Umgebung müssen.

Wenn ich im Beispiel auf die "249" im "Mailflow Dashboard" (https://protection.office.com/mailflow/dashboard) drücke, dann bekomme ich sogar einen Hinweis, wie ich das fixen kann:

Und der "Fix it Now"-Button ist nur einen Klick entfernt und erklärt im nächsten Fenster dann, was wohl passieren wird:

Da muss ich dann aber doch mal einhalten, weil das ja meine "Hybrid-Konfiguration" zerstören wird und danach keine Mails mehr von Office 365 direkt über den "Connector" zur eigenen Umgebung gehen.

Hier sollten Sie also immer genau zweimal hinschauen, ehe ein Assistent eine Konfiguration verändert.

Bypass über Internet

Selbst mit aktiviertem "Centralized Mail Transport" gibt es immer wieder man wieder den Bedarf, das Mails dennoch nicht über die On-Prem-Umgebung gehen sollen. In den meisten Fällen, in denen ich mit entsprechenden Anforderungen konfrontiert wurde, ging es um "Hosted Journalarchiv", d.h. das Mails anhand einer Journalregel zu einem anderen externen Dienstleister per Mail gesendet werden sollten. Da macht es natürlich keinen Sinn diese Massen auch noch durch die On-Prem Umgebung zu schleusen. Ein weiterer Fall wäre z.B. eine Alarmkette, bei der man per Mail eine Meldung an einen Dienstleiter oder das private Postfach bei einem anderen Anbieter absetzen will, während das Routing über On-Premises gestört ist. Es ist gar nicht ungewöhnlich, wenn z.B. Dienste in der Cloud ihre Umgebung überwachen und sie Office 365 auch als "Versender" nutzen wollen.

Der erste Versuch dazu einfach einen neuen Connector Richtung "Internet" einzurichten wird schon im Ansatz blockiert:

Sie können heute gar keinen Connector "Richtung Internet" einrichten, bei dem Sie dann später per Addressraum (RecipientDomains nennt dies Office 365 mittlerweile) die Mails versendet werden. Office 365 sendet per Default alle Mails über die Microsoft eigenen Relay und Spamfilter in das Internet.

Connector für Adressraum (Irrweg)

Ich habe dann einen Connector in der Cloud angelegt, der als "Partner-Connector" versucht hat, alle Mails von Office 365 an eine bestimmte Domain über einen Smarthost oder deren MX-Eintrag zu routen. Das Abschlussbild hat auch "Erfolg" verkündet.

Allerdings konnte es erst nicht glauben, dass die Mails nicht diesen Weg genutzt haben, sondern weiterhin den Connector zur On-Prem-Umgebung, die der Hybrid Configuration Wizard eingestellt hat.

Eine Quelle habe ich noch nicht gefunden aber anscheinend setzt das Flag "RouteAllMessagesViaOn-Premises:$true" das Routing anhand von RecipientDomains außer Kraft.

Connector für bedingtes Routing

Aber Office 365 kennt im Gegensatz zu Exchange On-Prem noch eine andere Möglichkeit in das Routing von Nachrichten einzugreifen. Zuerst definiere ich den Connector wie schon gehabt mit Namen und Beschreibung:

Auf der zweiten Seite wähle ich nun aber "RecipientDomains" anstelle von Domänen:

Die nächsten Schritte sind wieder identisch. ich muss den "Next Hop" angeben, der von Office 365 entweder über den MX-Record für die Empfängerdomäne gefunden werden kann oder von mir als Smarthost explizit angegeben wird:

Optional kann ich hier, es es ein "Partner Connector" ist, auch die Verschlüsselung vorschreiben:

Die Zusammenfassung zeigt noch einmal die gemachten Einstellungen

Ehe die Konfiguration aktiv werden kann, zwingt Office 365 Sie dazu eine Mailadresse in diesem Ziel anzugeben, damit eine Testnachricht versendet werden kann:

So stellt Microsoft von vorneherein sicher, dass Sie keine ungültige Konfiguration anlegen. Per Powershell können Sie die Konfiguration noch einmal anzeigen lassen. Hier sehen Sie meinen "Bypass" und den Connector, der alle Mails zu meiner On-Premises-Umgebung routet:

PS C:\> Get-OutboundConnector  |ft name,recipientdomains,enabled,RouteAllMessagesViaOn-Premises,IsTransportRuleScoped -AutoSize

Name                                      RecipientDomains  Enabled RouteAllMessagesViaOn-Premises IsTransportRuleScoped
----                                      ----------------  ------- ----------------------------- ---------------------
Bypass Centralized Mailrouting via MX    {}                 True    False                         True
Outbound to 1191ecb5-aafb-41d5-a616-xxxx {*}                True    True                          False

Die Vorarbeit ist geleistet, um den Connector in einer Transportregel zu nutzen.

Transportregel

Nun muss ich eine Transportregel anlegen, die Mails entsprechend der geforderten Bedingungen zum richtigen Connector sendet. Das ist in Exchange per Browser schnell gemacht:

Auch diese Regel können Sie per PowerShell sehr einfach sehen:

PS C:\> Get-TransportRule

Name                                               State    Mode        Priority Comments
----                                               -----    ----        -------- --------
Bypass Centralized Mailrouting                     Enabled  Enforce     0        ...

Sonderfall Journal

Ich hatte anfangs aufgeführt, dass die Ausleitung eines Journals zu einem Dienstleister ein Szenario ist, bei dem so eine Bypass-Regel wünschenswert ist um den Umweg über On-Premises zu umgehen. Leider scheint das per Default erst einmal nicht zu funktionieren, da der Journal-Agent nach dem Transportrule-Agent aktiv gewesen ist.

Lastly, the journal report messages themselves are privileged messages, which will not be intercepted by transport rules, and can be configured such that they will never expire in a transport queue
Quelle: Interception and Redirection of Messages Using Transport Rules or Journaling https://blogs.technet.microsoft.com/exchange/2010/01/28/interception-and-redirection-of-messages-using-transport-rules-or-journaling/

Oder kurz gefasst:

  • Journalregeln werden nach den Transport Regeln abgearbeitet
  • Journalmails werden nie über Transportregeln umgestellt

Ich habe es daher natürlich nachgestellt und einen Connector für Transportrouting erstellt, dann eine Transportregel für alle Mails an eine Domäne mit diesem Connector als Ziel addiert und eine Journalregel definiert, die bestimmte Mails an eine Adresse in dieser Domäne sendet. Es wurde zwar jede Mail auch als Journalmail erstellt aber nicht über die Transportregel und den eigens eingestellten Connector versenden oder gemäß "centralized mail transport" über die On-Prem-Umgebung versendet.

Es ist nicht möglich, eine Journal-Mail über diese Transportregeln zu einem Connector zu senden, wenn "Centralized Mail Transport" aktiv ist.

Eine Lösung könnte so aussehen, dass Sie den Hybrid Configuration Wizard ohne die Option "Centralizes Mail Transport" ausführen und danach über Transport-Regeln alle Mails nach extern über den Connector zu On-Premises leiten mit Ausnahme der Domains, die sie über das normale Routing steuern wollen.

Versuche es anders zu machen

So ganz konnte ich das nicht glauben, dass bei "Centralized Message Transport" der Weg über eine Transportregel der einzige Weg sein sollte. Also habe ich verschiedene Optionen per PowerShell versucht aber mir jedes Mal einen Fehler eingehandelt. Hier meine Versuche:

Set-OutboundConnector `
   -identity "Bypass Centralized Mailrouting via MX" `
   -IsTransportRuleScoped:$false 
"RecipientDomains" muss für einen Non-TransportRuleScoped-Connector angegeben werden; 
anderenfalls sollte "RecipientDomains" nicht angegeben werden.

Set-OutboundConnector `
   -identity "Bypass Centralized Mailrouting via MX" `
   -RouteAllMessagesViaOn-Premises:$true
"RouteAllMessagesViaOn-Premises" kann nicht auf "true" gesetzt werden, wenn der Connectortyp nicht "On-Premises" ist.

Set-OutboundConnector `
   -identity "Bypass Centralized Mailrouting via MX" `
   -IsTransportRuleScoped:$true `
   -RecipientDomains carius.de
"RecipientDomains" muss für einen Non-TransportRuleScoped-Connector angegeben werden; 
anderenfalls sollte "RecipientDomains" nicht angegeben werden

# folgendes geht
Set-OutboundConnector  `
   -identity $a[0].identity  `
   -IsTransportRuleScoped:$true `
   -RecipientDomains $null

Alle Versuche auch per PowerShell eine andere Konfiguration ohne Transportregel zu erhalten, sind fehlgeschlagen.

Für mich bedeutet das, dass Routing-Konfigurationen über "RecipientDomains" als Kriterium nur solange funktionieren, wie es nicht einen Connector für "Centralized Mail Transport" gibt. Da dies aber immer einmal erforderlich sein kann, würde ich in Exchange Online alternative Connectoren nur noch über Transportregeln adressieren.

Wer also diese Konstellation meistern muss, der sollte "Centralized Mail Transport" besser nicht aktivieren und manuell per Transportregeln und Connectoren dafür sorgen, dass alle Mails dennoch über On-Prem geroutet werden.

Eingehender Verkehr

Wenn ich alles über meine eigene Umgebung versendet, dann mache ich das z.B. weil ich meinen eigenen Spamfilter nutzt oder z.B. S/MIME oder PGP auf dem Gateway umsetze. Über die passende Wahl des MX-Records kann ich dann natürlich auch sicherstellen, dass eingehende Mails wieder über dieses System ankommen und erst einmal durch meine On-Premises-Umgebung gehen, ehe sie dann über die Weiterleitung der "Remote Mailbox" in die Cloud gesendet werden.


Quelle: https://technet.microsoft.com/en-us/library/jj659050%28v=exchg.150%29.aspx

Sie sehen hier gut, dass die Mail an das lokale Exchange System gehen. Im lokalen Active Directory gibt es ein passenden AD-Objekt zum Office 365 Postfach, welches als "Remote Mailbox" ausgeführt ist. Dort ist über die "TargetAddress" hinterlegt, dass die Mail an die "User@%tenantname%.mail.onmicrosoft.com" weiter geleitet wird. Diese Zieladresse ist dem Connector zur Cloud zugeordnet.

Exchange Online Protection und Hybrid Routing

Trotz Centralized Hybrid Routing ist und aber aufgefallen, dass eingehende Mail aus dem Internet, die über den eigenen Spamfilter schon geprüft wurden, auf dem Weg zum Office 365 Postfach noch mal durch Exchange Online Protection bewertet und sogar in den Junk-E-Mail-Folder verschoben wurden. Nach kurzer Analyse haben wir die Ursache auch gefunden. Der "Inbound Connector" in Office 365, der als Verbindung von der On-Premises-Organisation zu Exchange Online angelegt wurde, filtert natürlich auf die Sender-Domains. Die Beschreibung sagt das auch ganz deutlich:

Mails, die über diesen Connector kommen UND deren Absenderadresse zu meinen SMTP-Domänen gehört, werden so behandelt. Das gilt aber nicht für Mails, die über die On-Premises-Plattform aus dem Internet kommen. Wenn Sie also verhindern möchten, dass Mails bei dieser Konstellation ein zweites Mal auf Spam und Viren geprüft werden, dann sollten Sie einen zusätzlichen Connector anlegen, der wie folgt konfiguriert ist.

  • Mailflow Szenario From: Partner To: Office 365
    Nur wenn Sie dieses Szenario auswählen, können sie die Source-Domänen eintragen.
  • Domain für "Partner"
    Hier trage ich "*",, also any domain ein.
  • Identifizierung des Servers: per Source-IP ihrer Umgebung oder per SSL-Zertifikat
    Ich bevorzuge natürlich die Identifizierung des Servers per TLS-Zertifikat und TLS-Zwang

Oder als Schlussbild in ECP:

Da dieser Connector nur für Mails von meiner On-Premises-Umgebung gilt und von dort ja nur Mails kommen, die meine eigene Schutzlösung bereits gefiltert hat, ist dieser Connector kein Risiko. Er ist eher erforderlich, wenn Sie ihren Anwendern nicht immer wieder erklären wollen, warum Mails in Exchange Online noch im Spam-Filter landen.

Weitere Links