Pannes d’Exchange après les mises à jour Windows Server d’octobre 2026 : MapiExceptionMdbOffline (ec=1142)

Depuis le Patch Tuesday du 13 octobre 2026, les serveurs Exchange tombent en panne après environ 24 heures de fonctionnement : les clients perdent la connexion à leur boîte aux lettres, OWA affiche MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142), les e-mails restent dans les files d’attente et, dans les DAG, les copies de bases de données ne se répliquent plus. Le 15 octobre 2026, Microsoft a ajouté une note à l’annonce des SU Exchange d’octobre : les mises à jour d’octobre pour Windows Server sont à l’origine du problème ; l’installation du SU Exchange n’est pas nécessaire pour que le problème survienne. Aucun correctif ni contournement officiel n’est encore disponible (état au 16 octobre 2026).

Symptômes

Les symptômes rapportés jusqu’à présent :

• OWA échoue avec MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142) ; l’Application Log contient l’Event ID 1006.
• Les clients Outlook perdent la connexion à la boîte aux lettres.
• Les e-mails ne sont livrés ni en interne ni en externe, et les files d’attente de transport grossissent.
• Dans les DAG, les copies de bases de données ne se répliquent plus ; selon des témoignages de lecteurs sur Born, les basculements lors du passage en mode maintenance échouent.
• Le Centre d’administration Exchange affiche néanmoins les bases de données comme montées (Frankys Web).

L’erreur ne survient pas directement après l’installation, mais, selon les rapports, après environ 22 à 30 heures de fonctionnement. Le redémarrage du serveur rétablit le fonctionnement, mais la panne se reproduit après approximativement le même délai. Dans les commentaires sur Born, il est observé que le service de réplication des boîtes aux lettres s’arrête pendant ou après les tâches de maintenance des bases de données, puis que les erreurs MdbOffline apparaissent ; cela n’est toutefois pas confirmé.

Mises à jour concernées

Dans l’ajout à l’annonce Exchange, Microsoft cite les mises à jour cumulatives Windows suivantes :

Les SU Exchange (Exchange SE : KB5128895, « SU11 ») ainsi que des mises à jour cumulatives pour le .NET Framework ont également été publiés le même Patch Tuesday. Sur un Exchange SE affecté sous Windows Server 2019, les trois paquets suivants étaient installés :

• Security Update For Exchange Server Subscription Edition (KB5128895)
• 2026-10 Cumulative Update for .NET Framework 3.5, 4.7.2 and 4.8 for Windows Server 2019 for x64 (KB5128923)
• 2026-10 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5126651)

Microsoft ne mentionne pas la mise à jour .NET dans l’ajout. Des lecteurs sur Born signalent toutefois des pannes avec la combinaison des mises à jour Windows et .NET (KB5128928 sous Windows Server 2022) ainsi qu’un serveur avec KB5126651 et le SU Exchange, mais sans mise à jour .NET, qui fonctionnait toujours après plus de 24 heures. La participation de la mise à jour .NET reste donc incertaine.

Concernant le SU Exchange : des forums et commentaires indiquent que la situation s’améliorerait avec l’installation du SU11 Exchange. Cela ne peut pas être confirmé ; les pannes sont également survenues sur un serveur avec SU11. Inversement, plusieurs administrateurs signalent des pannes sans SU Exchange installé, ce qui correspond à la déclaration de Microsoft. Le SU Exchange corrige six vulnérabilités, dont une exécution de code à distance critique via un e-mail spécialement conçu ; détails dans l’article sur le SU d’octobre. Le différer ne résout pas le problème.

Vérifier l’état

Commencez par déterminer, sur chaque serveur Exchange, lesquelles des mises à jour d’octobre sont installées :

$kbs = "KB5126646", "KB5126655", "KB5126651", "KB5126868", "KB5128923"
Get-HotFix -Id $kbs -ErrorAction SilentlyContinue |
  Select-Object PSComputerName, HotFixID, InstalledOn

Get-HotFix ne répertorie pas les mises à jour .NET de manière fiable sur tous les systèmes ; en cas de doute, l’historique des mises à jour dans les paramètres affiche l’état complet. Vérifiez la version d’Exchange dans l’Exchange Management Shell avec Get-ExchangeServer | Format-Table Name, AdminDisplayVersion et comparez-la aux numéros de build Exchange.

Vérifiez ensuite l’état des bases de données, des copies et des files d’attente dans l’Exchange Management Shell :

Get-MailboxDatabaseCopyStatus -Server $env:COMPUTERNAME |
  Format-Table Name, Status, CopyQueueLength, ReplayQueueLength, ContentIndexState
Get-Queue | Where-Object MessageCount -gt 0 |
  Format-Table Identity, DeliveryType, Status, MessageCount, LastError
Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1006; StartTime=(Get-Date).AddDays(-2)} |
  Select-Object TimeCreated, ProviderName, Message

Plusieurs composants Exchange consignent l’Event ID 1006 ; l’entrée déterminante est celle contenant le message MdbOffline dans le texte.

Procédure en attendant le correctif

Microsoft indique examiner le problème avec l’équipe Windows et ne mentionne jusqu’ici ni contournement ni rollback. Dans l’intervalle :

1. Serveurs Exchange pas encore mis à jour : Suspendez les mises à jour Windows d’octobre (ainsi que la mise à jour .NET du même jour) sur les serveurs Exchange, dans WSUS, Intune ou votre propre gestion des mises à jour. C’est un compromis : les mises à jour Windows corrigent elles aussi des vulnérabilités de sécurité. Les serveurs Exchange accessibles depuis Internet doivent donc faire l’objet d’une surveillance particulièrement étroite.

2. Installer tout de même le SU Exchange : Selon Microsoft, le SU Exchange KB5128895 (ou les paquets ESU pour 2016/2019) n’est pas le déclencheur et corrige une faille critique exploitable sans compte par e-mail.

3. Serveurs déjà affectés : Un redémarrage rétablit le fonctionnement pendant environ une journée. Planifiez des redémarrages contrôlés à des intervalles nettement inférieurs à 22 heures, par exemple chaque nuit, au lieu d’attendre la prochaine panne. Selon des lecteurs sur Born, le redémarrage des seuls services Exchange aide aussi temporairement ; sa durée d’efficacité n’est pas établie.

4. DAG : Redémarrez les membres l’un après l’autre et déplacez au préalable les bases de données actives vers un serveur fraîchement redémarré. Après chaque redémarrage, vérifiez avec Get-MailboxDatabaseCopyStatus que les copies sont à nouveau Healthy et que les files d’attente se résorbent avant de redémarrer le serveur suivant.

5. Surveiller les files d’attente : Gardez Get-Queue et l’Event ID 1006 à l’œil, idéalement avec une alerte, afin qu’une panne ne soit pas détectée seulement via des signalements d’utilisateurs.

6. Vérifier les sauvegardes : Un lecteur sur Born signale un VSS Writer défaillant dans la sauvegarde après la panne. Contrôlez les sauvegardes des dernières nuits.

Pour désinstaller les mises à jour Windows : depuis 2021, Microsoft fournit la mise à jour cumulative avec la Servicing Stack Update sous la forme d’un paquet combiné. wusa /uninstall ne supprime pas un tel paquet ; il faut utiliser DISM /Online /Remove-Package avec le nom du paquet provenant de DISM /Online /Get-Packages. Microsoft n’a pas validé la désinstallation comme contournement et aucun rapport de rollback réussi suivi d’un fonctionnement stable n’est encore disponible. Le cas échéant, testez d’abord cette procédure sur un seul serveur.

Selon Frankys Web, Microsoft ne répertorie pas encore le problème comme Known Issue dans les mises à jour Windows (état au 16 octobre 2026). Gardez l’annonce Microsoft à l’œil ; Microsoft y ajoute les compléments à la fin, sous « Updates to this blog post ». Cet article sera mis à jour dès qu’un correctif ou un contournement officiel sera disponible.