Seit der zweiten Septemberwoche fällt in einigen Hybrid-Umgebungen etwas auf, das auf den ersten Blick wie ein klassisches Transportproblem aussieht. Die Queue des Send Connectors für Exchange Online wächst, Nachrichten hängen im Status „Retry“, und Benutzer beschweren sich über verzögerte E-Mails an Kollegen, deren Postfächer bereits in der Cloud liegen. Wer dann reflexartig Zertifikate, Firewall-Regeln oder den Smarthost prüft, sucht an der falschen Stelle. Die Ursache steht meistens schon im LastError der Queue: 4.7.230.
Microsoft hat Anfang September angekündigt, die Mindestversion für Exchange 2016 und Exchange 2019 anzuheben, die E-Mails über einen On-Premises-Inbound-Connector an Exchange Online weiterleiten dürfen. Die neue Untergrenze ist das letzte öffentlich verfügbare Sicherheitsupdate vom Oktober 2025. Das allein wäre in vollständig gepatchten Umgebungen kein Drama.
Der eigentliche Sprengstoff steckt im Nebensatz der Ankündigung: Bei der nächsten Anhebung liegt die geforderte Version oberhalb jedes öffentlich verfügbaren Updates für Exchange 2016 und 2019. Spätestens dann ist das Thema keine Patchfrage mehr, sondern eine Migrationsfrage.
Links
- Exchange 2016/2019: Throttling and Blocking up to the Final Public Update Baseline
- Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online
- How to pause throttling and blocking of out-of-date on-premises Exchange Servers
- Exchange Server build numbers and release dates
Transport Enforcement ist kein neues Thema
Der Mechanismus ist nicht neu. Microsoft hat das sogenannte Transport Enforcement bereits 2023 eingeführt, damals unter dem Motto, Exchange Online vor Nachrichten aus dauerhaft verwundbaren Exchange Servern zu schützen. Zuerst traf es auf Exchange 2007, dann auf Exchange 2010 und schließlich auf Exchange 2013. Ab 2024 kamen Exchange 2016 und 2019 hinzu, allerdings mit einer Untergrenze, die nur Server erfasste, die deutlich hinter dem aktuellen Patchstand lagen.
Neu ist jetzt die Qualität der Grenze. Bisher musste man schon ziemlich nachlässig sein, um gedrosselt zu werden. Mit der aktuellen Anhebung trifft es Server, die vor einem Jahr noch auf dem neuesten Stand waren, aber seit dem Supportende am 14. Oktober 2025 nicht mehr aktualisiert wurden. Und mit der angekündigten nächsten Stufe trifft es jeden Exchange 2016 oder 2019 Server, der nicht im kostenpflichtigen ESU-Programm steckt.
Für die Praxis heißt das
Die neue Baseline entspricht Exchange 2019 CU15 mit dem Oktober-SU (Build 15.2.1748.39) beziehungsweise Exchange 2016 CU23 mit dem Oktober-SU (Build 15.1.2507.61). Wer noch auf Exchange 2019 CU14 läuft, sollte den Sprung auf CU15 direkt einplanen.
Oder natürlich direkt auf Exchange Server SE aktualisieren.
Was genau gedrosselt wird und was nicht
Es geht ausschließlich um den On-Premises-Inbound-Connector.
Der wichtigste Punkt, der in Diskussionen regelmäßig untergeht: Das Enforcement betrifft weder pauschal jeden Exchange Server in deiner Organisation noch jede Mail, die irgendwie in Exchange Online landet. Geprüft werden ausschließlich Server, die über einen Inbound-Connector mit dem ConnectorType OnPremises einliefern. Genau diesen Connector erstellt der Hybrid Configuration Wizard, wenn du den zentralisierten oder klassischen Hybrid-Mailflow konfigurierst.
E-Mails, die über einen Connector vom Typ Partner angenommen werden, etwa von einem Drittanbieter-Gateway, durchlaufen diese Prüfung nicht. Das gilt ebenso für ganz normale E-Mails , die über den MX-Eintrag bei Exchange Online Protection ankommen. Microsoft betont ausdrücklich, dass sich das Ganze aktuell nur auf den On-Premises-Pfad bezieht. Das Wort „aktuell“ würde ich mir an dieser Stelle allerdings gut merken.
Wie Exchange Online die Version erkennt
Exchange Online muss deinen Server nicht abfragen, um seine Version zu ermitteln. Jeder Exchange Server trägt seinen Build in den Received-Header ein, sobald er eine Nachricht weiterleitet. Exchange Online wertet genau diese Angabe aus. Entscheidend ist daher der Server, der die SMTP-Session tatsächlich mit Exchange Online aufbaut. In vielen Umgebungen ist das ein Edge-Transport-Server oder eine festgelegte Gruppe von Mailbox-Servern, die im Send Connector für mail.protection.outlook.com als Source-Server eingetragen sind.
Das hat einen interessanten Nebeneffekt: Ein vergessener Exchange 2016 im Keller, der keine E-Mails in die Cloud überträgt, taucht beim Enforcement überhaupt nicht auf. Für den Mailflow ist das egal, für die Angriffsfläche deiner Exchange-Server ganz sicher nicht.
Wie Exchange Online die Version erkennt
Das Enforcement eskaliert stufenweise. In den ersten 30 Tagen wird nur berichtet. Danach beginnt das Throttling mit einigen Minuten pro Stunde, in denen Exchange Online die Verbindung mit 450 4.7.230 temporär ablehnt. Dein Server behält die Nachricht in der Queue und versucht es später erneut. Benutzer merken zunächst nur Verzögerungen. Mit jeder Stufe wird das Zeitfenster größer, und ab etwa Tag 60 kommt das Blocking hinzu. Dann antwortet Exchange Online mit 550 5.7.230, und die Nachricht geht als NDR an den Absender zurück. Nach 90 Tagen ist der Pfad komplett zu.
Gerade die Mischphase ist tückisch, weil das Fehlerbild sporadisch auftritt. Ein Teil der Mails kommt an, ein anderer Teil bleibt hängen oder bounct. Wer so ein Muster im Message Tracking sieht, sollte zuerst die Buildnummer prüfen und erst danach mit dem Lesen von Netzwerk-Traces beginnen.
Die im Diagramm dargestellten Minutenangaben sind der öffentlich verfügbaren Dokumentation entnommen.
Warum die nächste Anhebung die eigentliche Deadline ist
Wer seine Server jetzt auf das Oktober-SU 2025 aktualisiert, hat zunächst Ruhe. Jedoch nur vorübergehend. Microsoft hat klargestellt, dass die nächste Anhebung kommt und dann eine Version voraussetzt, die nicht öffentlich verfügbar ist. Dann bleiben nur noch zwei Gruppen: Kunden im ESU-Programm, die keine öffentlichen Updates erhalten, jedoch noch auf das Oktober-SU 2026 aktualisieren konnten, und Kunden, die auf Exchange Server SE umgestiegen sind.
Das ESU-Programm verschiebt das Problem allerdings nur. Es ist zeitlich begrenzt. danach erhalten Exchange 2016 und 2019 schlicht keine Updates mehr – für niemanden. Spätestens bei der übernächsten Anhebung sind also auch ESU-Kunden betroffen. Meine Meinung dazu ist ziemlich eindeutig: ESU ist ein Notfallfallschirm, kein Flugplan. Wer in einer Hybridumgebung arbeitet und den On-Premises-Connector braucht, kommt an Exchange Server SE nicht vorbei.
Die gute Nachricht ist, dass der Weg für die meisten Umgebungen überschaubar ist. Exchange 2019 CU15 lässt sich per In-Place-Upgrade auf Exchange Server SE heben, technisch ist das nicht viel mehr als ein weiteres CU. Bei Exchange 2016 führt der Weg über neue SE-Server und eine klassische Migration von Postfächern und Rollen. Und wer Exchange On-Premises nur noch für die Attributverwaltung betreibt und gar keinen lokalen Mailflow mehr braucht, sollte ernsthaft prüfen, ob der letzte Exchange Server nicht komplett verschwinden kann. Ohne On-Premises-Mailflow gibt es auch kein Enforcement.
Praxisbeispiel: Bestandsaufnahme in fünf Minuten
Zuerst lohnt sich ein Blick darauf, welche Inbound Connectors in Exchange Online überhaupt vom Typ OnPremises sind. In Exchange Online PowerShell reicht dafür ein kurzer Befehl:
Connect-ExchangeOnline
Get-InboundConnector | Select-Object Name, ConnectorType, Enabled, TlsSenderCertificateName, SenderIPAddresses
Alles zum ConnectorType OnPremises ist relevant. Connectoren vom Typ Partner kannst du für dieses Thema ignorieren.
Als Nächstes zeigt dir Exchange Online selbst, welche On-Premises-Server es gesehen hat und in welcher Enforcement-Phase sie sich befinden:
Get-OnPremServerReportInfo
ServerFQDN : smtpo.varunagroup.de
Build : 15.2.2562.29
ExchangeServer : ExchangeServerSubscriptionEdition
FirstDetectedDate : 06.11.2025 08:51:09
RecommendedBuildVersions : 15.2.2562.57, 15.2.2562.56, 15.2.2562.53, 15.2.2562.50, 15.2.2562.49, 15.2.2562.47, 15.2.2562.46, 15.2.2562.45, 15.2.2562.44, 15.2.2562.43,
15.2.2562.42, 15.2.2562.41, 15.2.2562.39, 15.2.2562.38, 15.2.2562.37, 15.2.2562.36, 15.2.2562.35, 15.2.2562.30, 15.2.2562.29
ThrottleEnabledDate : 06.12.2025 08:51:09
BlockingEnabledDate : 05.01.2026 08:51:09
NextStageThrottleRate : 0
NextStageBlockRate : 60
NextStageStartDate : 04.02.2026 08:51:09
Dieselbe Information findest du im Exchange Admin Center unter den Mail-Flow-Reports im Bericht zu veralteten verbundenen On-Premises-Servern. Der Reportname lautet: „Verbindung mit lokalen Exchange-Servern herstellen“.
Auf der lokalen Seite solltest du dich nicht auf AdminDisplayVersion aus Get-ExchangeServer verlassen, denn die zeigt nur das CU und nicht das installierte SU. Die Dateiversion von ExSetup.exe ist zuverlässig. Aus der Exchange Management Shell heraus geht das für alle internen Server so, Edge Transport Server klammern wir dabei bewusst aus:
Get-ExchangeServer | Where-Object { -not $_.IsEdgeServer } | ForEach-Object {
$build = Invoke-Command -ComputerName $_.Fqdn -ScriptBlock {
(Get-Command ExSetup.exe).FileVersionInfo.ProductVersion
}
[pscustomobject]@{
Server = $_.Name
Roles = $_.ServerRole
Build = $build
}
}
Ein sauber gepatchter Mailboxserver hilft dir nichts, wenn der Edge davor noch auf einem alten SU läuft. Deshalb filtert das Skript oben die Edge-Systeme aus, und du prüfst sie separat direkt auf dem jeweiligen Server.
Eine Einschränkung gilt für die Edge-Transport-Server. Die stehen in der Regel im Perimeternetz, sind nicht Mitglied der Domäne und für Remote PowerShell aus dem internen Netz bewusst nicht erreichbar. Das Skript oben läuft bei ihnen deshalb ins Leere, auch wenn sie dank EdgeSync in der Ausgabe von Get-ExchangeServer erscheinen. Die Build-Version fragst du auf einem Edge-Transport-Server direkt auf dem System selbst ab, also per RDP-Sitzung in der lokalen Exchange Management Shell:
(Get-Command ExSetup.exe).FileVersionInfo.ProductVersion
Liegt die Version eines Servers, der an Exchange Online sendet, unter 15.2.1748.39 (Exchange 2019) oder 15.1.2507.61 (Exchange 2016), bist du betroffen. Ob das Throttling schon zuschlägt, siehst du schnell in den Queues:
Get-Queue | Where-Object { $_.LastError -like '*4.7.230*' -or $_.LastError -like '*5.7.230*' } | Select-Object Identity, Status, MessageCount, LastError
Wenn du kurzfristig nicht patchen kannst, gibt es einen Notausgang. Microsoft erlaubt eine Pause des Enforcements von insgesamt 90 Tagen pro Jahr:
# Abfrage einer möglichen Konfiguration
Get-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer
# "Freikaufen" für 14 Tage
New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer -NumberOfDays 14
Zwei Dinge solltest du dabei beachten. Die Pause setzt den Zyklus nicht zurück. Nach ihrem Ablauf geht es auf der Stufe weiter, auf der das Enforcement zuvor stand.
Eine einmal angelegte Pause lässt sich außerdem nicht vorzeitig beenden. Wer also gleich 90 Tage einträgt und nach einer Woche mit dem Patchen fertig ist, hat sein Kontingent für das Jahr aufgebraucht. Lege die Pause daher lieber kurz an und verlängere sie bei Bedarf.
Fazit
Das aktuelle Throttling lässt sich in gepatchten Umgebungen mit einem einzigen Update beheben. Das Oktober-SU 2025 ist weiterhin öffentlich verfügbar und erfüllt damit die heutige Baseline. Wer noch nicht aktualisiert hat, sollte das schnell nachholen. Und nicht erst, wenn die ersten NDRs mit 5.7.230 im Helpdesk eingehen.
Viel wichtiger ist aber der Blick nach vorn. Microsoft hat die nächste Stufe bereits angekündigt, und diese lässt sich mit Exchange 2016 oder 2019 ohne ESU schlicht nicht mehr erfüllen. Mit ESU, dessen Phase 2 nun auch zu Ende ist, gewinnst du ein paar Monate, mehr nicht. Auch wenn du weiterhin ESU Phase 2 erwerben kannst, erhältst du damit nur die Möglichkeit, das SU von Oktober 2026 herunterzuladen. Es wird keine Security Updates für Exchange Server 2016 oder 2019 geben. Punkt.
Wenn deine Hybrid-Umgebung auf den On-Premises-Connector angewiesen ist, gehört die Migration auf Exchange Server SE jetzt auf die Roadmap, und zwar mit Termin. Für Exchange 2019 CU15 ist das In-Place-Upgrade der schnellste Weg. Für Exchange 2016 wird es eine echte Migration sein. Und wenn du ehrlich feststellst, dass du gar keinen lokalen Mailflow mehr brauchst, ist vielleicht der beste Exchange Server der, den du abschaltest.
