LES - Last Exchange Server

Immer mehr Firmen schließen langsam ihre Exchange Migration in die Cloud ab und machen sich Gedanken, wie Sie die lokale Umgebung zurückbauen. Das ging bis 20. Apr 20222 offiziell leider gar nicht, da die Nutzung von ADSync mit Exchange Online einen lokalen Exchange Server erforderlich machte.

Update 20. Apr 2022

Mit dem Exchange Exchange 2019 CU12 vom 20. April 2022 hat Microsoft einen Weg geöffnet, wie Sie ohne lokalen Exchange Server weiterhin die Empfänger in Exchange Online verwalten können.

Siehe dazu Exchange Management Rolle

Es hat allerdings einige Jahre gedauert, denn die ersten Wünsche dahingehend gab es schon im Sep 2014

Kundenprofile

Für wen diese Seite ist, erklärt sich am besten anhand der verschiedenen Kundenszenarien, die sich eigentlich nur darum drehen, ob der Kunde ein lokale Active Directory mit ADSync nutzt:

Fall ADSync Lokale Postfächer Beschreibung
A

Nein

Nein

Eher kleine Firmen haben entweder gar kein lokales AD mehr oder sie verzichten Trotz AD auf ADSync und damit auch auf Password Hash Sync. Das ist durchaus ein übliches Szenario für Handwerker und kleine Firmen mit wenige Fluktuation. Sie könnte auch mit AzureAD alleine als gemeinsamer Anmeldedienst arbeiten. Wer hier schon Exchange hatte, kann die Inhalte einfach per Cutover-Migration umziehen.
B

Ja

Nie

 Ich habe einige Kunden, die von einem anderen Mailsystem (Notes, GroupWise, IMAP4 etc.) kommen aber natürlich ein lokales Active Directory nutzen und auch weiter nutzen wollen. Wer das Microsoft Support Statement ernst nimmt (Siehe ADSync mit Exchange Online), muss dennoch lokal einen Exchange Server samt Schemaerweiterung installieren, damit er per Exchange PowerShell oder ECP auch die Cloud-Empfänger verwalten kann.
C

Ja

Früher

Dann gibt es die Firmen, die von Exchange On-Premises gekommen sind und mittlerweile alle Postfächer, öffentlichen Ordner etc. nach Exchange Online verschoben haben. Der letzte lokale Exchange Server kann aber noch nicht weg, weil er für die Verwaltung und vielleicht das Mailrouting noch erforderlich ist.
D

Ja

Dauerhaft

Alle Firmen, die weiterhin selbst Exchange Empfänger On-Premises betreiben, kommen um den Hybrid Mode nicht herum. Sie haben aber mindestens einen lokalen Exchange Server und sind daher auch nicht betroffen.

Die folgenden Überlegungen gelten also nur für die Firmen B und C.

Problem: ADSync

Auf der Seite Hybrid Connector Server gibt es die Langfassung aber wer Exchange Online mit ADSync verwendet, kann einige Aktionen in der Cloud nicht konfigurieren, da ADSync autoritativ für einige Felder ist. Das sind zum einen die bekannten Standardfelder.

Hier könnte ich ja noch verstehen, wenn Exchange Online die Änderung unterbindet. Aber die Blockade betrifft auch z.B. ProxyAddresses:

In der Testumgebung gibt es wohlgemerkt lokal gar keinen Exchange Server und keine Exchange Schema-Erweiterung und entsprechend kann ich in ADSync auch gar nicht den Exchange Hybrid Mode einstellen.

Herausforderung: Mailrouting

Die zweite Herausforderung ist das Mailrouting zwischen lokalen Systemen und Exchange Online. Solange es einen lokalen Exchange Server als "Brückenkopf" gibt, können lokale Dienste wie Drucker, Scanner, ERP/CRM-Systeme, PowerShell-Skripte etc. ihre Mails einfach "lokal" abliefern und der Hybrid Connector Server sendet diese "sicher" per TLS und am Spamfilter vorbei zu Exchange Online. Sie müssen lokal in der Firewall kein Port 25 ausgehend samt Namensauflösung und SMTP ohne TLS erlauben.

Eingehend kann Exchange Online ebenfalls Mails an Subdomains durch den TLS-Tunnel zu ihrem Exchange System senden, der die Mails dann intern weiter leitet. Kein anderer interner Server muss "aus dem Internet" von Exchange Online, d.h. auch von anderen Tenants, erreichbar sein.

Microsoft trödelt?

Seit vielen Jahren ist das Thema akut aber noch gibt es keine sichtbare Lösung. Im Jahr 2015 habe ich schon in Redmond mit den relevanten Personen gesprochen und angeblich wird an einer Lösung gearbeitet. Aber es kann wohl nicht allein an der COVID19-Thematik und Teams liegen, dass nun nach sechs Jahren immer noch keine Lösung sichtbar ist. Aber vielleicht kommt gerade Bewegung in die Sache. Ich hoffe zumindest nicht, dass die Lösung auf der Abschaffung des lokalen AD beruht. Das wäre mit AzureAD-Join, Intune, viele Dienste in der Cloud für den ein oder anderen Kunden durchaus möglich.

Ich persönlich gehe aber davon aus, dass die meisten meiner mittleren und größeren Kunden noch auf Jahre hinaus ein lokales Active Directory betreiben und damit ADSync für den Abgleich sorgt.

Microsoft hat es in einem Blog-Post im Oct 2020 schön beschrieben.

As you probably also know we have historically provided a free license for these ‘management’ servers if their only use is to properly manage Exchange attributes when recipient objects are mastered On-Premises. You also know that we never provided this free license type for Exchange Server 2019.
We want to assure you that we are still committed to delivering a solution that will allow these lingering servers to be removed, but it will not arrive before Exchange Server 2016 enters Extended Support.
or this reason, we want to make our recommendation for this scenario clear. Our broad recommendation is to keep Exchange Server 2016 in production use until such point as we release a solution that allows those servers to be removed. As explained earlier, Extended Support still provides security and time zone updates and so keeping them in production and ensuring they are properly patched does not increase your risk profile in any way.
Quelle: Exchange Server 2016 and the End of Mainstream Support https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-2016-and-the-end-of-mainstream-support/ba-p/1574110.

THR2145 - Why do we need to keep an Exchange Server On-Premises when we move to the cloud
https://myignite.techcommunity.microsoft.com/sessions/66438

Das Problem ist also keineswegs unerkannt geblieben aber einen Exchange 2018 Server wollte mal halt nicht mehr kostenfrei bereitstellen. Daher ist ein Exchange 2016 Server selbst im "extended Support" immer noch die Empfehlung

Alternativen für ADSync

ADSync liest die lokalen Eigenschaften und überträgt diese in den meisten Fällen unidirektional in die Cloud. Es gibt natürlich einige wenige Felder, die auch in die Gegenrichtung repliziert werden. (Siehe ADSync Bidirektional). Daraus ergeben sich mehrere Optionen.

Option Beschreibung

Bidirektional

Theoretisch könnte Exchange Online es durchaus zulassen, die Felder in der Cloud schreibbar zu machen und durch ADSync ggfls. ins lokale AD zu übertragen. Das wäre zumindest für die Felder "ProxyAddresses" und "Mail" aus meiner Sicht ausreichend, die ADSync bei aktivierter "Exchange Hybrid"-Checkbox synchronisiert.

Entkoppelt

Ich könnte auch damit leben, wenn Exchange Online losgelöst vom lokalen AD seine Felder verwaltet. Das Verhalten kennen wir schon von Skype for Business. Wenn ich lokal keine Rufnummer gepflegt habe, kann ich diese in der Cloud setzen. Ein Indikator könnte hier ja die Checkbox "Exchange Hybrid" im ADSync sein. Wenn Sie nicht gesetzt ist, sollte ADSync die Felder ignorieren und in der Cloud die Verwaltung erlauben

Agent

 Wenn die bidirektionale Replikation mit ADSync zu komplex ist, könnte Exchange Online sich z-B. eines lokalen Agenten bedienen, um die Werte direkt zu schreiben. Mit AzureAD Cloud Sync gibt es schon eine Lösung, die vielleicht einfach erweitert werden kann, um die Werte lokal und in der Cloud zu schreiben.

Sie sehen, dass es durchaus Optionen gibt. Ich könnte mir die "entkoppelte" Lösung vorstellen, wenn ADSync keine Exchange Hybrid-Checkbox hat. Größere Firmen könnte aber mit einer Replikation der Felder Mail und ProxyAddresses aus der Cloud ins lokale AD sehr gut bedient sein. Denken Sie immer dran, dass es lokal keine Exchange Server mehr gibt und die Felder nur für 3rd-Party Abfragen überhaupt relevant sein könnten.

Wenn der Tenant nicht mit dem originären Microsoft ADSync abgeglichen würde, dann könnte man in der Cloud direkt die Exchange Properties verwalten. Aber in ADSync steckt so viel Know-How drin, welches man nachprogrammieren müsste und selbst dann gibt es Herausforderungen wie die Authentifizierung, bei der gerade kleinere Firmen mit "Password Hash Sync (PHS)" sehr gut fahren. Das lässt sich aber nur sehr schwer Nachprogrammieren, z.B. indem man den Kennwort-Update-Prozess selbst baut (Siehe auch Graph und Kennworte).
Vermutlich warten wir besser auf eine Lösung von Microsoft.

Alternativen für Provisioning

Ich sage es ungerne aber wenn ich die Exchange Felder in der Cloud aufgrund der Blockade durch ADSync (Siehe ADSyncBlock) nicht verwalten kann, aber mit der lokale Exchange Server stört dann kann ich auf die Idee kommen, einfach nur die Exchange Schema-Erweiterung einzuspielen, um damit die Exchange Online Properties zu verwalten.

Technisch ist das sogar möglich, z.B. indem Sie nur die Schema-Erweiterung durchführen und dann die LDAP-Felder manuell beschreiben oder vielleicht mit einer "lokalen Exchange PowerShell" arbeiten. ic habe das schon vor einigen Jahren auf ADSync mit Exchange Online Only beschrieben.

All diese Überlegungen sind aber weit weg von jeglichem Support-Statement und sie haben ein hohes Risiko durch falsch oder unvollständig gepflegte AD-Felder. Eine Lösung muss hier durch Microsoft kommen.

Alternativen für Mailrouting Ausgehend

Aus Sicherheitsgründen möchten sie eigentlich nicht, dass interne Clients direkt per SMTP über 25/TCP durch die Firewall mit Exchange Online sprechen. Sie brauchen zumindest eine statische IP-Adresse, damit sie in der Cloud einen "Inbound Connector" zum entschärfen der Spamfilter anlegen können. Aber selbst dann ist die Verbindung nicht zwingend per TLS gesichert.

Der einfachste Weg solche internen Mails zum eigenen Tenant zuzulassen ist ein kleiner lokaler SMTP-Service. Das kann ein Windows SMTP-Server, hMailServer oder auch ihre Firewall sein, die SMTP-Verbindungen von ausgewählten Clients von Intern annimmt und dann per SMTP mit STARTTLS zum Office 365 Tenant sendet. Idealerweise mit einem Zertifikate, so dass der Partner-Connector in der Cloud die Verbindungen anderen Regeln unterwerfen kann. Um eine sichere Zustellung von einem internen Mailserver zum eigenen Tenant zuzulassen, können Sie in Exchange Online einen "Inbound Connector" wie folgt definieren:

# Eingehende Mail mit Absender "msxfaq.de" als intern behandeln, 
# wenn der einliefernde Mailserver sich mit einem Zertifikat mit dem Namen "mailout.msxfaq.de" ausweist.

New-InboundConnector `
   -ConnectorType OnPremises `
   -Enabled $true `
   -Name "Inbound from Relay On-Premises" `
   -RequireTls $true `
   -RestrictDomainsToCertificate $true `
   -SenderDomains msxfaq.de `
   -TlsSenderCertificateName mailout.msxfaq.de> `
   -TreatMessagesAsInternal $true

Wichtig ist hier der Parameter "-TreatMessagesAsInternal $true", welcher Exchange Online anweist, die Mails als Intern anzusehen, selbst wenn der interne Server kein Exchange Server ist und daher keine erweiterten Header setzen kann.


Quelle: https://learn.microsoft.com/en-us/powershell/module/exchange/set-inboundconnector?view=exchange-ps

Ich sehe es als eher unwahrscheinlich an, dass sie alle Skripte und anderen internen SMTP-Versender auf TLS umstellen können. Aber ein lokales SMTP-Relay, welches intern Mails von vertrauenswürdigen Systemen annimmt und dann per SMTP-TLS zu Exchange Online sendet, ist nicht schwer aufzusetzen. Dazu brauche ich keinen "fetten" lokalen Exchange Server

Alternativen für Mailrouting Eingehend

Der Empfang von Mails vom eigenen Tenant an interne Systeme kann ein Risiko sein. Ohne gesicherten lokalen Exchange Server müssten sie ja ihre anderen Mailserver zumindest von den Exchange Online-Adressen per SMTP erreichbar machen. Das ist nicht sehr einfach und eingehende Verbindungen sind eh aus Firewall-Sicht immer kritisch zu sehen.

Variante Beschreibung

Sammelpostfach

Eine Alternative könnte ein Postfach pro Service sein.

Nachteilig ist dabei natürlich, dass es ein Dienstkonto mit Zugangsdaten gibt, die Branchenanwendung IMAP4 oder POP3 mit ModernAuth (Siehe Exchange Online Authentifizierung) sprechen muss und in Exchange Online diverse Grenzwerte (Siehe Exchange Online Message Rate Grenzen) zu beachten sind. Wenn Sie diese Anforderungen erfüllen, dann kann dies aber funktionieren.

Über eine Transport Regel können Sie sogar Mails an eine Domain an so ein Postfach umleiten

SMTP-Relay

Auch andere Mailserver können bestimmte Relay-Funktionen bereitstellen. Sie können in Exchange Online jederzeit einen Send-Connector zu einer IP-Adresse über Port 25 anlegen und TLS erzwingen. Sie müssen allerdings sicherstellen, dass der Mailserver dann "sicher" ist, denn er ist auch von anderen Tenants theoretisch erreichbar.

Der SMTP-Service sollte also MTLS erzwingen und dann das Zertifikat der Gegenstelle (protection.outlook.com) und die TenantID im Header auswerten, ehe es die Mails intern weiter gibt.

Wenn ihre internen Services aber eine Zustellung per SMTP erwarten und sich nicht per IMAP4/POP3 mit ModernAuth anmelden können, dann ist zumindest eingehend immer noch die Funktion eines "Sammelpoststelle" denkbar. Leider geht das nur im Rahmen der von Microsoft vorgegebenen Randbedingungen.

  • Postfach brauche eine Lizenz
    Wenn aber nichts drin liegt, dann sollte da auch eine F3 mit 2 GB Platz reichen
  • Limits beachten
    Ein Postfach kann maximal 3600 Mail/Stunde empfangen. Diese Limit ist nicht verhandelbar und jede Mail darüber hinaus wird als "unzustellbar" abgelehnt.
  • Optional Transportregel
    So können Sie die Mails an eine Subdomain in das Postfach "umleiten"

    Dort landet dann eine Mail mit unverfälschtem Empfänger.
  • Sammeldienst
    Dann brauchen Sie nur noch einen Prozess, der bevorzugt per Graph, Notfalls aber auch per EWS, IMAP4 oder POP3 das Postfach leersaugt und an ihr System übermittelt.

Wenn Sie Mails per SMTP nur aus ihrem Tenant annehmen wollen, müssen Sie zumindest Port 25 für die Office 365 Mailserver freischalten. Die Adressen werden aber von allen Tenants genutzt und damit gibt es das Risiko einer Hintertür. Ihr Service müsste schon über einen SMTP-Header prüfen, wer der einliefernde Tenant ist. Technisch ist aber auch das ohne Exchange Server machbar.

Zwischenstand

Ich würde mich freuen, wenn ich auf dieser Seite irgendwann einmal eine öffentliche und von Microsoft untersstützte Lösung beschreiben kann. Schon heute sind Zwischenschritte denkbar aber erfordern jede Menge Kompromisse. Heute würde ich immer einen kleinen Exchange 2016 Server On-Premises einsetzen oder ihre Umgebung ist so klein, dass sie vielleicht auch ohne ADSync auskommen. In ganz seltenen Fällen, können Sie ADSync nutzen aber auf die Verwaltung von Exchange Online Properties verzichten. Allein durch die Zuweisung einer Lizenz in der Cloud bekommt auch ein ADSync-User schon ein Postfach mit einer Mailadresse, die dem UPN entspricht. Nur editieren können Sie natürlich nichts in Exchange Online. Zusätzliche SMTP-Adressen sind so z.B. nicht möglich.

Ob Microsoft an solch einer Lösung arbeitet, kann ich nicht sagen.

Weitere Links