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.

Warum "Last Exchange Server"?

Am 14. Okt 2025 endet der offizielle Support für Exchange 2016/2019 und nur wer im ESU-Programm für Extended Support (ca. 3000€/Server) bekommt noch einige Monate weitere Updates. Sie können entweder zu Exchange Server SE migrieren oder zu Exchange Online. Am 14. Okt 2025 werden die lokalen Exchange Server natürlich nicht funktionsunfähig aber wenn das nächste Update für Exchange SE eine von extern oder Anwendern ausnutzbare Lücke korrigiert, können Sie davon ausgehen, dass diese Lücke in Exchange 2016/2019 auch vorhanden ist aber nicht gefixt wird. Für die Firmen, die nicht nach Exchange SE migrieren, sondern quasi 100% in Exchange Online sind, stellt sich dann die Frage:

Wozu brauche ich noch einen lokalen Exchange Server, wenn ich in Exchange Online bin?

Oft brauchen Sie ihn nicht mehr und letztlich könnten wir den letzten Exchange Server auch noch deinstallieren. Aber halt. So schnell geht es noch nicht, denn oft ist ihr lokaler Server noch erforderlich, z.B. für

  • Empfängermanagement
    Wenn Sie einen Verzeichnisabgleich nutzen, dann müssen Sie alle Empfänger noch lokal verwalten. Das können Sie aber mittlerweile lösen, indem Sie z.B. IsExchangeCloudManaged nutzen oder ADSync mit Exchange Online Only und der Exchange Management Shell verwenden.  Vielleicht brauchen Sie auch gar keinen ADSync mehr und wollen das lokale AD komplett zurückbauen. Dann muss der letzte Exchange Server auch weg
  • Mailrouting
    Vielleicht haben Sie interne Dienste, die Mails per SMTP versenden und diese bislang an Exchange OnPremises gesendet haben. Hierzu müssen Sie eine Lösung finden. Dazu habe ich auf Exchange Online ohne Brückenkopf viele Optionen beschrieben, damit sie keinen lokalen Exchange Server mehr betreiben müssen. Auchu den Empfang aus dem Internet müssen Sie natürlich vor der Abschaltung auf Exchange Online umstellen.
  • IMAP/POP/SMTP und BasicAuth/OAUTH oder EWS
    Wenn 3rd Party Dienste ihre Mails heute per IMAP/POP aus dem Postfach lesen und per SMTPAUTH senden, dann geht das mit Exchange Online, wenn die Produkte die Anmeldung per OAUTH verstehen. Eine einfache Anmeldung per Benutzername/Kennwort ist in Exchange Online nicht möglich und auch der Zugriff per EWS endet im Okt 2026. Wenn Sie alle Apps umgestellt haben. dann kann ihr lokaler Exchange Server weg.

Für die ein oder anderen Fälle können Sie die lokalen Exchange Server natürlich auch durch 3rd Party Mailserver ersetzen. Dann betreiben Sie aber wieder einen SMTP-Server, was sie eigentlich gerade verhindern wollten.

Deinstallieren Sie nicht den letzten Exchange Server

Die Exchange Deinstallationsroutine entfernt nicht nur die Programmdateien sondern baut auch einige Einträge im Active Directory ab. Zudem sollten die vorher auch die Hybrid-Konfiguration zurückbauen und überlegen, wie Sie die lokalen Benutzer im "Exchange Online Betrieb" vielleicht doch noch mit Mailadressen versehen, damit z.B. 3rd Party Programme diese Informationen per LDAP bekommen können.

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:

Szenario Lokales AD mit ADSync Lokale Postfächer Beschreibung

A

Nein

Nein

Eher kleine Firmen haben entweder gar kein lokales AD mehr oder sie verzichten 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 und die Empfänger direkt in der Cloud verwalten.

B

Ja

Nein

 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), musste früher dennoch lokal einen Exchange Server samt Schemaerweiterung installieren, damit er per Exchange PowerShell oder ECP auch die Cloud-Empfänger verwalten kann. Das geht heute aber auch ohne Exchange, entweder mit IsExchangeCloudManaged oder einer Exchange Management Rolle.

C

Ja

LES

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. Es wird aber immer noch ein letzter lokaler Exchange Server aus den obigen Gründen betrieben

D

Ja

Dauerhaft

Alle Firmen, die weiterhin selbst Exchange Empfänger OnPremises und in Exchange Online betreiben, kommen um den Hybrid Mode nicht herum.

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

Timeline

Das Problem mit dem "Letzten Exchange Server" in Verbindung mit Exchange Online hat auch Microsoft schon lange auf dem Radar. Wer ein lokales AD genutzt hat, hat meist auch ADSync zum Abgleich mit Microsoft 365 eingesetzt und damit waren lange Zeit die Empfänger in Exchange Online "ReadOnly". Aber das ändert sich langsam.

Zeitraum Betriebsumgebung

Bis 20 Apr 2022

Sie mussten einen vollwertigen lokalen Exchange Server samt Schema-Erweiterung installieren, um die Empfänger in der Cloud zu verwalten, auch wenn Sie keinen lokalen Postfächer einrichten wollten. Wenn der lokale Server weder Postfächer betreibt noch SMTP-Routing übernimmt, konnten sie Exchange ohne weitere Lizenz im Hybrid-Mode einsetzen. Die Lizenzkosten sind allerdings der zu vernachlässigende Teil be einer Gesamtkostenbetrachtung (Hardware, Betrieb, Monitoring, Backup, Patchmanagement, Know-How, Updates und Migrationen)

Wir vergessen den Sonderfall, bei dem sie auf eine Pflege in Exchange Online verzichten und einfach über die Lizenz ein Postfach vergeben. (Siehe Doppelpostfach mit Exchange Online)

Ab 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. Sie installieren nur die Exchange PowerShell als Teil der Exchange Management Rolle. Dazu wurde zwar auch ihr Exchange Schema erweitert und die Berechtigungen über RBAC - Role Based Access Control sind nicht verfügbar, aber sie brauchen keinen aktiven Server zu betreiben

Ab 20 Auf 2025

Microsoft hat eine neue Funktion bereitstellt, um Exchange Online Empfänger in der Cloud zu verwalten und diese zugleich per ADSync aus dem lokalen AD verwalten zu lassen. Über das Attribut IsExchangeCloudManaged können Sie in Exchange Online die Postfächer "freistellen", so dass sie gar kein lokales Exchange zur Verwaltung mehr benötigen.

Problem: Empfängermanagement und Entra ID Sync

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. Ich 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.

Cloud Provisioning und OnPrem Mail

Denken Sie auch an lokale Produkte, die per LDAP nach Benutzern mit Mailadressen suchen. Es ist gar nicht mal so selten, dass z.B. "Scan2Mail"-Dienste und andere Programme sich an AD anbinden, um mögliche Ziele zu finden. Wenn Sie alle Exchange Informationen nur noch in Exchange Online und EntraID verwalten, dann schreibt niemand die Informationen in die lokalen Felder "Mail" und "ProxyAddresses" zurück. Diese Funktion wird zukünftig sicher mal EntraID Cloud Sync liefern aber 2025 ist davon noch nichts zu sehen.

Sie müssten hier dann eigene Skripte bauen, die z.B. per Graph die User und Mailadressen aus EntraID auslesen und die lokalen Objekte entsprechende aktualisieren. Das ist nicht schwer und schnell gemacht aber es müsste dann halt gemacht werden.

Alternativen für Mailrouting Ausgehend

Beachte dazu auch die Seite Exchange Online ohne Brückenkopf

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

Beachte dazu auch Exchange Online ohne Brückenkopf - So routen sie Nachrichten zwischen lokalen Servern und ihrem Exchange Online Tenant

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

Mittlerweile gibt es von Microsoft mit it IsExchangeCloudManaged oder der Exchange Management Rolle zwei Optionen, wie die Exchange Online und ADSync zusammen nutzen können, ohne einen lokalen Exchange Server zu betreiben. Wer keinen Verzeichnisabgleich benötigt, hat sogar noch eine dritte Option, die Empfänger in Exchange Online zu verwalten. Damit bleibt ihnen nur noch die Klärung, welche anderen Funktionen ein lokaler Exchange Server noch bereitstellt und wie sie diese auf andere Wege umstellen können.

Weitere Links