MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Exchange Online ohne Brückenkopf

Diese Seite beschreibt, wie sie Drucker, Scanner, ERP-Systeme etc. an Exchange Online anbinden, ohne einen lokalen Exchange Server zu benötigen. Der kostenfreie "Hybrid Connector Server ohne Postfach" darf nämlich auch kein SMTP-Routing machen.

Bisher

Die meisten Leser kennen vermutlich Exchange Online - Hybrid. Sie haben früher lokale Exchange Server und mit den ersten Exchange Online Postfächern haben Sie natürlich den Hybrid Mode konfiguriert, damit sie nicht nur Postfächer migrieren und frei/Belegt-Zeiten sehen konnten, sondern auch der Mailfluss zwischen den beiden Standorten problemlos möglich war.

Das war aus mehreren Gründen notwendig.

  • Mails als Intern erkennen
    Das jeweils andere Exchange System muss die Mails ihres Umgebung als "Trusted" einstufen, damit z.B. interne OOF statt externe OOF-Texte generiert wurden. Dass sie Mails an Empfänger (Postfäher und Verteiler) senden konnten, die nur von authentifizierten Absendern erreichbar sein sollten u.a.
  • Spamschutz
    Ohne das "intern-Vertrauen" würden Spamfilter eine "extern" abkommende Mail mit der eigenen SMTP-Domain als Phishing einstufen und nicht ins Postfach zustellen.
  • Zwingend verschlüsselt
    Zudem wollen Sie sicherstellen, dass die Mails zwischen beiden Systemen zwingend per TLS abgesichert werden, so dass ein Mitlesen fremder Stellen nicht möglich ist. Wer es ganz perfekt gemacht hat, nutzt dazu öffentliche Zertifikate und lässt Exchange auch den Namen prüfen
  • Relay
    Je nach Routing haben ihre Exchange Online Postfächer alle Mails über das OnPremises System geroutet oder lokale Server alle Mails über die Exchange Online ins Internet gesendet. Das funktioniert natürlich nur, wenn das jeweils andere Exchange System auch nur dem legitimen Absender "vertraut"
  • Interne Systeme
    Und dann gibt es immer noch lokale Systeme, die Mails an Postfächer in Exchange Online oder Internet senden wollen und interne Systeme, die Mails annehmen müssen.

Für all diese Fälle konnten wir auf die Relay-Funktion des lokalen Exchange Servers vertrauen. Wir konnten über Send-Connectoren die Mails an die ERP-Systeme zustellen und über Receive-Connectoren den Empfang per SMTP an interne lokales und Online-Empfänger sicherstellen und für ausgewählte Systeme z.B. über die Source-IP sogar ein Relay ins Internet zulassen.

Hybrid Server ist kein Transport Server

Die Frage zu Lizenzen ist nicht immer einfach zu erklären aber mit den Informationen zu Exchange Server SE wurde ein Abschnitt addiert, der sehr deutlich die Nutzung des kostenfreien Exchange Hybrid Servers für Routing untersagt.

Wer frühere Lizenztexte nachliest, findet weniger deutliche Aussagen aber vermutlich war dies auch schon mit Exchange 2016/2019 nicht mehr erlaubt. Nun ist es aber deutlich beschrieben und wir müssen uns überlegen, wie wir die eigene Umgebung entsprechend anpassen. Der im Rahmen des HCW - Hybrid Configuration Wizard lokal mit einer Lizenz versehenen Server (ohne Postfach) darf nur für die Verwaltung per Exchange Control Panel oder Remote PowerShell genutzt werden.

Wenn dies so ist und ich keinen Exchange braucht, dann würde ich vielleicht direkt die Exchange Management Rolle ganz ohne Exchange nutzen

Lizenzieren mit M365 E3/E5

Jeder Exchange Server hat auch eine SMTP/Transport-Rolle aber wenn dieser über den HCW lizenziert wird, dürfen Sie diese nicht nutzen. Sie können natürlich einfach eine "richtige" Exchange Server Lizenz für den lokalen Betrieb kaufen. Prüfen Sie einmal, ob sie vielleicht sogar so eine Lizenz schon haben. Wer z.B. Microsoft 365 E3/E5 für alle Benutzer lizenziert hat dürfte über die "Extended Use Rights" auch schon Lizenzen für vollwertige Exchange Server samt SA besitzen und damit gar nicht mehr in die Verlegenheit kommen, mit der HCW-Lizenz arbeiten zu müssen.

Ausgehende Szenarien ohne lokalen Exchange

Ansonsten steht ihnen immer noch der Weg offen, ganz ohne lokalen Exchange Server zu arbeiten. Wenn Sie dabei ihre Anwender mittels ADSync abgleichen und die Exchange Konfigurationen im lokalen AD verwalten, dann müssen Sie dies z.B. über die Exchange Management Rolle durchführen.

Ohne den lokalen Exchange Server als "Brückenkopf" können Sie nun zwei Wege zum Versand interner Mails an ihre Exchange Online Postfächer umsetzen:

Szenario  Beschreibung

Direkter Versand per NAT 

 

Sie können in ihrer Firewall die gewünschten Systeme einfach über eine Regel den Zugriff  auf Exchange Online zulassen. Idealerweise nutzen sie dazu den MX-Record oder Namen, den sie im Microsoft 365 Portal dazu angezeigt bekommen.

Tipp: Ich würde intern einen CNAME "smtprelay.<ihre domain>" anlegen, der auf den eigentlichen SMTP-Service verweist, so dass spätere Anpassungen ohne weitere Konfiguration auf den Druckern, Scanner, PowerShell-Skripten etc. erfolgen können.

Die Konfiguration hat natürlich den Nachteil, dass Sie nur anhand der Source-IP-Adressen vielleicht steuern können, welches System nach extern darf aber sie keine weiteren Filter oder Rewrite-Funktionen umsetzen können.

Anderes SMTP-Relay 

 

Nur weil sie lokal keinen Exchange Server mehr betreiben, könnten Sie dennoch ein kleines SMTP-Relay betreiben. Leider ist der Windows SMTP-Server seit Windows 2025 nicht mehr verfügbar und auch andere Windows-basierte 3rd Party Server wie hMailServer werden wohl nicht mehr weiter entwickelt. Prüfen Sie aber einmal, ob ihre Firewall keine SMTP-Relay-Funktion bereitstellt. Ansonsten könnten Sie natürlich auch ein kleines Linux-System mit Postfix, SendMail, Exim o.ä. aufsetzen. Hier könnten Sie dann neben der Source-IP-Adresse auch weitere Filter und Regeln um setzen.

Zudem könnten Sie so den direkten Durchgriff über Port 25 ins Internet vermeiden, was einen höheren Schutz bietet und Einstellungen bezüglich Authentifizierung, TLS-Zwang etc. müssten Sie auch nur an einer zentralen Stelle vornehmen. Ihr Server könnte z.B. auch eine DKIM-Signatur anbringen, die Sie dann in Exchange Online verifizieren könnten.

Da die Mails so per SMTP allerdings anonym an Exchange Online zugestellt werden, müssen Sie Vorkehrungen treffen, so dass diese Mails nicht im Spamordner landen. Exchange Online muss dazu ihrer Firewall, sei es als SMTP-Server oder als NAT-System vertrauen. Das geht am besten über folgende Einstellungen in Exchange Online

  • Inbound Connector
    Sie sollten in Exchange Online einen "Inbound Connector" vom Typ "OnPremises" einrichten und anhand der Source-IP-Adresse oder noch besser einem eindeutigen Zertifikat des lokalen Systems erkennen. Damit haben Sie zwar noch keinen "Vorteil" aber können weitere Konfigurationen anwenden.
    Wenn Sie ganz sicher sind, dass ihr lokaler Server "abgesichert" ist und Zertifikat oder Souce-IP-Adresse nich von anderen Systemen missbraucht werden können, dann könnte Sie den Paraneter "TreatAsInternal" nutzen. Siehe dazu auch TreatMessagesAsInternal.
  • TLS-Zwang
    Wen Sie genauso sicher sein wollen, wie mit einem lokalen Exchange Server, dann sollten Sie dem lokalen SMTP-Service ein kommerzielles Zertifikat verpassen, damit er sich damit ausweisen und Sie TLS erzwingen können.
  • Extended Protection
    Über das Security Center können Sie für den Connector die Schutzfunktionen zu DKIM anpassen
  • SPF
    Vielleicht sollten ihre Drucker, Scanner, Skripte nicht mit ihrer primären SMTP-Domain senden. Mit einer eigenen Domain sollten Sie dann einen passenden SPF-Eintrag veröffentlichen, damit Exchange die Mails nicht gleich als Fälschung oder Spoofing aussortiert
  • Transport-Regel und SCL
    Sie könnten auch abhängig von einem Header oder eben ihrer eigenen SMTP-Domain per Transportregel den SCL-Wert auf "-1" setzen

Es gibt also durchaus Wege, wie lokale Skripte, Programme o.ä. auch Mails an ihren Exchange Online Tenant senden können.

Achtung:
Wenn Sie von lokalen Systemen über Exchange Online ins Internet senden wollen, d.h. Exchange Online als ausgehendes Relay nutzen, dann sind zusätzliche Schutzfunktionen erforderlich. Ich würde hier nicht den eigenen Tenant nehmen, was mittels TreatMessagesAsInternal natürlich möglich ist, aber beachten Sie dazu TERRL - Tenant External Recipient Rate Limit, Exchange Online External Recipient Rate (ERR) Limit und Exchange Online als Outbound Relay.

Eingehende Szenarien ohne lokalen Exchange

Auch in die Gegenrichtung wurde der lokale Exchange Transport-Service bei einer Hybrid-Bereitstellung genutzt. Entweder, weil direkt über Centralized Mail Transport jede Mail über den lokalen Server geroutet wurde oder weil lokales Gateways über Connectoren angebunden waren. Mehr als einmal habe ich in Kunden-Tenants entsprechende Outbound-Connectoren gefunden, die z.B. SMTP-Domains für FAX-Server oder ERP-Systeme zum lokalen Exchange Server geroutet haben, der dann über einen Send-Connector oder teilweise auch Foreign-Connector die Mails ans eigentliche Zielsystem übermittelt haben.

Technisch hat Exchange Online die Mails per SMTP an eine lokale IP-Adresse gesendet, an der ein Exchange Server eingehende Verbindungen angenommen und das MTLS-Zertifikat von Exchange Online geprüft hat. Wobei diese Prüfung eher schwach war. Exchange hat Mails als "intern" angesehen, wenn die Absenderdomain aus seinen "AcceptedDomain" gekommen ist und die Gegenseite sich mit "mail.protection.outlook.com" ausgewiesen hat. Alle anderen Mails hat Exchange aber auch angenommen. Daher war es auch mit Exchange Hybrid essentiell, z.B. per Firewall die eingehenden Verbindungen auf Exchange Online zu beschränken.

Ohne einen lokalen Exchange Server müssen Sie nun einen anderen Weg finden, dass sie Mails von Exchange Online wieder OnPremises annehmen und an die richtigen Server weitergeben.

 

Hier gibt es eine gute und eine weniger gute Möglichkeit Mails von Exchange Online zu lokalen Systemen zu übertragen: 

  • SMTP
    Sehr viele Firewalls haben auch einen SMTP-Funktion integriert, die zwar im Bereich Spamfilter/SMIME oft nicht an kommerzielle Lösungen heranreichen, aber durchaus Mails von Exchange Online annehmen und intern weiter geben können. Ansonsten können Sie statt eines lokalen Exchange Servers natürlich wieder einfach eine Postfix/Exim/SendMail-Instanz installieren, um das Mailrouting zu übernehmen.
  • Postfach
    Sie können immer noch in Exchange Online z.B.: per Transportregel alle Mails an eine Domain in ein Postfach umrouten. Das geht einfach und wenn es nur ein paar hunderte Mails/Tag mit ein paar MB, stört sie eher die Anmeldung per MFA Postfach in Exchange Online (Exchange Online Message Rate Grenzen). POP3/IMAP4 mit Username/Kennwort gehen quasi nicht mehr. Die Lizenz ist noch zu beachten.
    Eine Variante wäre ein lokales Postfach auf einem eigenen kleinen lokalen Mailserver, über den sie dann auch intern ohne Cloud solche Mails abholen könnten.

 

Ein Exchange OnPremises Server hat hier keinen Vorteil gegenüber Linux-basierten Mailservern, wenn wir man vielleicht von den Kenntnissen der Administratoren zu den unterschiedlichen Systemen absieht.

Einschätzung

Das Verbot den letzten lokalen Exchange ohne Postfächer weiterhin neben dem Exchange Admin Center zusätzlich auch für Mailrouting zu verwenden, mag für den ein oder anderen Administrator überraschend sein. Aber wenn wir ehrlich sind, dürfte es nur ganz wenige Firmen betreffen. Wenn eine Firma schon zu 10% in Exchange Online ist, dann hat sie schon in der Vergangenheit alles daran gesetzt, die lokalen Exchange Server zu reduzieren oder komplett zu entfernen. Seit Exchange 2019 CU12 vom 20. Apr 2022 konnten Sie mit der Exchange Management Rolle und minimaler Beschreibung schon ohne lokalen Exchange arbeiten. Das gilt auch für Firmen, die direkt mit Exchange Online gestartet haben und erst später mit ADSync dann die erweiterte Verwaltung, z.B. für weitere sekundäre Adressen (ProxyAddresses) konfiguriert haben.

Die andere Gruppe hat auch weiterhin lokale Exchange Server und wird diese mit Exchange SE und vielleicht Microsoft 365 eh lizenziert haben,

Weitere Links