Hybrid 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-Premise" 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".

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-Premise-Umgebung routen.

Centralized Mail Transport

In der Regel senden Postfächer in der Cloud ihre Mails direkt in das Internet und nur Empfänger On-Premise bekommen die Mails über einen passenden Connector. Allerdings gibt es auch die Option, dass alle Mails über die On-Premise-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-Premise" 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" Set-OutboundConnector

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-Premise" 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 als Relay erlaubt sind.

Bypass über Internet

Selbst mit aktiviertem "Centralized Mail Transport" gibt es immer wieder man wieder den Bedarf, das Mails dennoch nicht über die On-Premise-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-Premise 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-Premise" 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-Premise-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-Premise 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. Poer Powershell können Sie die Konfiguration noch einmal anzeigen lassen. Hier sehen Sie meinen "Bypass" und den Connector, der alle Mails zu meiner "On-Premise"-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-Premise" 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-Premise-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-Premise" 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:

PS C:\> 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.

PS C:\> 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.

PS C:\> 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 $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-Premise geroutet werden.

Weitere Links