Exchange Online limite et bloque les serveurs Exchange 2016 et 2019 obsolètes à partir de septembre 2026 : fonctionnement du transport enforcement
À partir de la deuxième semaine de septembre 2026, Exchange Online exige des serveurs hybrides au minimum la SU d’octobre 2025, faute de quoi le flux de messagerie est limité puis bloqué. Contexte du transport enforcement depuis 2023, niveaux d’escalade avec codes SMTP, rapport dans l’Admin Center, pause de 90 jours via PowerShell et raison pour laquelle la prochaine hausse ne laissera passer que les clients ESU et Exchange SE.
Le 2 septembre 2026, l’équipe Exchange a annoncé le relèvement de la version minimale requise pour Exchange 2016 et Exchange 2019 dans le flux de messagerie hybride. À partir de la deuxième semaine de septembre 2026, Exchange Online exigera des serveurs qui remettent des messages via un connecteur entrant de type OnPremises au minimum le niveau de la dernière mise à jour de sécurité publique d’octobre 2025. Tout niveau inférieur sera limité puis bloqué. En bref : si vous n’avez pas appliqué de correctifs à vos serveurs hybrides depuis octobre 2025, vous perdrez progressivement la remise des e-mails vers Exchange Online au cours des prochaines semaines. Et le prochain relèvement, que Microsoft envisage dans les mois à venir, sera supérieur à toute mise à jour disponible publiquement : seuls les clients du programme ESU payant ou les environnements avec Exchange Server Subscription Edition (SE) satisferont alors à l’exigence.
L’annonce elle-même est brève. Sa signification pratique découle du système d’enforcement que Microsoft met progressivement en place depuis 2023 : quelles réponses SMTP votre serveur recevra, comment vérifier l’état dans l’Admin Center et via PowerShell, et quelles options restent pendant la transition jusqu’à la fin du programme ESU en octobre 2026.
Ce qui s’applique à partir de la deuxième semaine de septembre 2026
Le nouveau seuil minimal correspond aux mises à jour de sécurité du 14 octobre 2025. C’était le dernier Patch Tuesday lors duquel Microsoft a publié publiquement des mises à jour pour Exchange 2016 et 2019 ; toutes les SU depuis décembre 2025 ne sont disponibles que via le programme ESU.
| Version | Niveau minimal | KB | Build |
|---|---|---|---|
| Exchange 2019 CU15 | SU d’octobre 2025 (CU15 SU5) | KB5066367 | 15.2.1748.39 |
| Exchange 2016 CU23 | SU d’octobre 2025 (CU23 SU19) | KB5066369 | 15.1.2507.61 |
Il existe également une SU d’octobre 2025 pour Exchange 2019 CU14 (KB5066368, build 15.2.1544.36). Toutefois, l’article Microsoft mentionne explicitement CU15 SU5 comme version minimale ; CU14 n’est de toute façon plus un niveau recommandé depuis la publication de CU15 en février 2025. Prévoyez également la migration de CU14 vers CU15.
Trois précisions sont importantes :
- Seul le flux de messagerie hybride est concerné. Exchange Online vérifie la version des serveurs de remise pour les messages arrivant via un connecteur entrant de type
OnPremises. Il s’agit de la configuration hybride classique créée par le Hybrid Configuration Wizard. Les e-mails arrivant via une passerelle tierce ou un connecteur de typePartnerne passent pas par cet enforcement. - La version est lue dans les en-têtes. Un serveur Exchange inscrit son build dans la ligne
Receivedde chaque message qu’il transmet (… with Microsoft SMTP Server … id 15.1.2507.61). Exchange Online évalue cette information. C’est donc le niveau du serveur qui remet effectivement le message à Exchange Online qui compte, autrement dit dans de nombreux environnements l’Edge Transport Server ou le serveur Mailbox doté du connecteur d’envoi vers*.mail.protection.outlook.com. - Exchange SE n’est pas concerné. L’enforcement s’applique à Exchange 2016 et 2019 ; Exchange Server SE se situe au-dessus de tout seuil minimal tant qu’il reçoit régulièrement ses correctifs.
Contexte : le transport enforcement depuis 2023
L’annonce de septembre n’est pas une nouvelle mesure, mais l’étape suivante d’un système présenté par Microsoft en mars 2023 sous le titre «Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online». Microsoft définit comme «persistently vulnerable» tout serveur Exchange ayant atteint sa fin de support ou restant non corrigé face à des vulnérabilités connues. L’objectif est de protéger les destinataires d’Exchange Online contre les messages provenant de serveurs susceptibles d’être compromis, tout en incitant les exploitants à corriger ou désactiver leurs serveurs.
Le système a été activé par version :
| Période | Version concernée |
|---|---|
| Août 2023 | Exchange 2007 |
| Septembre 2023 | Exchange 2010 |
| Décembre 2023 | Exchange 2013 |
| Mars 2024 | Exchange 2016 et 2019 (niveaux de SU très obsolètes) |
| Septembre 2026 | Exchange 2016 et 2019 : seuil minimal = SU d’octobre 2025 |
| «dans quelques mois» | Exchange 2016 et 2019 : seuil minimal supérieur à la dernière mise à jour publique |
Pour Exchange 2016 et 2019, le seuil minimal concernait jusqu’ici des niveaux «significantly behind on security updates». La nouveauté est que Microsoft fixe la limite à la dernière mise à jour publique et touche ainsi pour la première fois des serveurs qui étaient encore entièrement corrigés il y a moins d’un an.
Les niveaux d’escalade
L’enforcement fonctionne selon trois mécanismes que Microsoft nomme «reporting», «throttling» et «blocking». Dès qu’un serveur passe sous le seuil minimal, un cycle de 90 jours débute. Voici les niveaux décrits dans l’article de référence de 2023 :
| Période | Mesure | Réponse SMTP |
|---|---|---|
| Jour 0 à 30 | Rapport uniquement dans l’Exchange Admin Center | aucune |
| Jour 30 à 40 | Limitation pendant 5 minutes par heure | 450 4.7.230 |
| Jour 40 à 50 | Limitation pendant 10 minutes par heure | 450 4.7.230 |
| Jour 50 à 60 | Limitation pendant 20 minutes par heure | 450 4.7.230 |
| Jour 60 à 70 | Limitation pendant 30 minutes par heure, plus blocage pendant 5 minutes par heure | 450 4.7.230 et 550 5.7.230 |
| Jour 70 à 80 | Blocage pendant 10 minutes par heure | 550 5.7.230 |
| Jour 80 à 90 | Blocage pendant 20 minutes par heure | 550 5.7.230 |
| À partir du jour 90 | Blocage complet | 550 5.7.230 |
Les deux réponses sont libellées comme suit :
450 4.7.230 Connecting Exchange server version is out-of-date;
connection to Exchange Online throttled for n mins/hr.
550 5.7.230 Connecting Exchange server version is out-of-date;
connection to Exchange Online blocked for n mins/hr.
La différence est déterminante pour l’exploitation. Avec 450, Exchange Online refuse temporairement la connexion ; le serveur On-Premises conserve le message dans sa file d’attente et réessaie ultérieurement. Les utilisateurs ne constatent d’abord que des retards, tandis que dans Queue Viewer ou dans Get-Queue, la file d’attente vers le connecteur d’envoi vers Exchange Online augmente avec l’état Retry et le message 4.7.230 comme LastError. Avec 550, le refus est définitif : l’expéditeur reçoit un NDR avec le code 5.7.230 et le message est perdu s’il n’est pas renvoyé. Comme le blocage n’est d’abord actif que quelques minutes par heure, le symptôme semble initialement sporadique : une partie des messages arrive, une autre échoue avec un NDR. Si vous observez ce schéma dans le suivi des messages, vérifiez d’abord le niveau de version avant de rechercher des problèmes de réseau ou de certificat.
L’annonce ne précise pas si Microsoft lancera le cycle complet de 90 jours à partir de la deuxième semaine de septembre pour le nouveau seuil minimal ou s’il commencera directement à un niveau ultérieur. L’article de référence indique que le système reprend, après une pause, au niveau atteint précédemment. Ne comptez donc pas sur un délai de grâce de 30 jours.
Rapport dans l’Exchange Admin Center et via PowerShell
Exchange Online liste les serveurs On-Premises détectés avec leur version dans un rapport spécifique : dans l’Exchange Admin Center, sous Reports, Mail flow, rapport sur les serveurs Exchange On-Premises connectés obsolètes («out-of-date connecting on-premises Exchange servers»). Le rapport affiche pour chaque serveur le build détecté, s’il se situe sous le seuil minimal et le niveau d’enforcement en cours.
Exchange Online PowerShell fournit les mêmes informations :
Connect-ExchangeOnline
Get-OnPremServerReportInfo
Le rapport ne connaît que les serveurs qui remettent réellement des e-mails à Exchange Online. Un serveur de gestion sans flux de messagerie ou une machine équipée uniquement des Management Tools n’y apparaît pas. Cela n’a pas d’importance pour l’enforcement, mais en a pour la sécurité : ces systèmes nécessitent eux aussi les SU.
Mettre l’enforcement en pause : 90 jours par an
Pour les environnements qui ne peuvent pas atteindre le seuil minimal à court terme, Microsoft propose une pause. Elle peut être activée pour un total de 90 jours par an, en une seule fois ou en plusieurs périodes :
Get-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer
New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer `
-NumberOfDays 30
Deux caractéristiques de la pause sont importantes en pratique. Premièrement, après son expiration, l’enforcement reprend au niveau où il avait été arrêté ; la pause ne réinitialise pas le cycle de 90 jours. Deuxièmement, aucun cmdlet ne permet de mettre fin prématurément à une pause en cours : si vous créez une pause de 90 jours et terminez le patching deux semaines plus tard, votre quota annuel est épuisé. Créez donc la pause la plus courte possible et prolongez-la si nécessaire.
La pause n’est en outre une solution que pour le seuil minimal actuel. Lorsque Microsoft relèvera la limite au-dessus de la dernière mise à jour publique dans quelques mois, un quota épuisé ne vous aidera plus.
Pourquoi le prochain relèvement est la véritable échéance
Exchange 2016 et 2019 ne sont plus pris en charge depuis le 14 octobre 2025. Microsoft a ensuite mis en place deux périodes ESU payantes : la période 1 jusqu’en avril 2026, la période 2 de mai à octobre 2026. En annonçant la période 2 le 15 avril 2026, l’équipe Exchange a précisé qu’il n’y aurait pas de prolongation supplémentaire. Les SU de décembre 2025 à août 2026 (dernièrement le build 15.2.1748.49 pour 2019 CU15 et 15.1.2507.72 pour 2016 CU23) sont exclusivement disponibles pour les clients ESU et ne sont pas proposées publiquement au téléchargement.
Il en résulte la situation suivante :
- Aujourd’hui, un serveur doté de la SU d’octobre 2025 satisfait au seuil minimal, avec ou sans ESU.
- Lors du prochain relèvement, le seuil minimal sera, selon Microsoft, supérieur au niveau d’octobre 2025. Sans contrat ESU, il n’existe aucun moyen légal d’atteindre ce niveau. Le flux de messagerie hybride de ces serveurs sera alors limité et bloqué, indépendamment de la qualité d’exploitation du reste de l’environnement.
- Le 31 octobre 2026, la période 2 prend également fin. Après cette date, il n’y aura plus de SU pour Exchange 2016 et 2019, pour personne. Au plus tard, le relèvement suivant touchera donc aussi les clients ESU.
Le programme ESU ne permet donc, au mieux, de gagner que quelques mois. Le seul niveau durable que l’enforcement laisse passer est Exchange Server SE. Microsoft a également annoncé qu’Exchange SE CU2, prévu pour le second semestre 2026, mettra fin à la coexistence avec Exchange 2016 et 2019 : l’installation échouera si des serveurs plus anciens sont détectés dans l’organisation. La migration est donc nécessaire non seulement en raison du flux de messagerie, mais aussi pour pouvoir continuer à installer des mises à jour pour SE.
Pour les environnements qui ne conservent Exchange On-Premises que pour gérer les attributs dans une configuration hybride, l’alternative consiste à retirer le dernier serveur : depuis Exchange 2019 CU12, les attributs des destinataires peuvent être gérés avec les Management Tools sans serveur Exchange en fonctionnement. Il n’y a alors plus de flux de messagerie On-Premises et l’enforcement devient sans objet.
Déterminer le niveau de version
Get-ExchangeServer n’affiche dans AdminDisplayVersion que le CU, et non la SU. La version de fichier de ExSetup.exe est fiable, tout comme le Exchange Health Checker, qui signale également les étapes manuelles manquantes. Pour une vue d’ensemble rapide de tous les serveurs :
Get-ExchangeServer | ForEach-Object {
$path = "\\$($_.Name)\C$\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe"
[pscustomobject]@{
Server = $_.Name
Version = (Get-Item $path).VersionInfo.ProductVersion
}
}
Si la version est inférieure à 15.2.1748.39 (2019 CU15) ou à 15.1.2507.61 (2016 CU23), le serveur passera sous le seuil minimal à partir de la deuxième semaine de septembre.
Procédure recommandée
-
Inventoriez les niveaux comme décrit ci-dessus, y compris les Edge Transport Server et les serveurs de gestion.
-
Vérifiez le rapport dans Exchange Online.
Get-OnPremServerReportInfoindique quels serveurs Exchange Online voit réellement et si un niveau d’enforcement est déjà actif. Comparez la liste avec l’inventaire : les serveurs absents ne remettent pas leurs messages via le connecteurOnPremises. -
Installez au minimum la SU d’octobre 2025. KB5066367 (2019 CU15) et KB5066369 (2016 CU23) restent disponibles publiquement dans le Microsoft Download Center. Les SU sont cumulatives ; un serveur au niveau d’août 2025 peut être directement mis à niveau vers octobre 2025. Avec CU14, installez d’abord CU15. Après l’installation, redémarrez, contrôlez l’état des services et exécutez à nouveau le Health Checker.
-
N’utilisez la pause que comme solution transitoire. Si la mise à jour ne peut pas être effectuée durant la première moitié de septembre, créez
New-TenantExemptionInfoavec une durée courte et ne considérez pas la pause comme une réserve de planification pour le prochain relèvement. -
Planifiez la migration vers Exchange SE. Sans contrat ESU, le prochain relèvement constitue l’échéance impérative ; avec ESU, c’est le 31 octobre 2026. Exchange 2019 CU15 peut être mis à niveau sur place vers SE ; Exchange 2016 nécessite le détour par une nouvelle installation de SE et le déplacement des boîtes aux lettres ou des rôles. Ceux qui exploitent Exchange uniquement pour la gestion des attributs retirent le dernier serveur et continuent d’utiliser les Management Tools.

Commentaires
Les commentaires sont chargés depuis GitHub / Giscus.