Exchange Server ломается после октябрьских обновлений Windows Server: что делать

Коротко о главном

Октябрьский Patch Tuesday 2026 года обернулся серьёзной проблемой для администраторов Exchange. Обновления безопасности для Windows Server, выпущенные 13 октября, вызывают отказ Microsoft Exchange Server примерно через 24 часа после установки.

Симптомы: Outlook Web Access (OWA) перестаёт открываться, почтовые очереди растут, пользователи не могут подключиться к почте. В журнале приложений фиксируется ошибка MapiExceptionMdbOffline с кодами hr=0x80004005, ec=1142 и Event ID 1006.

Microsoft подтвердила проблему и расследует её совместно с партнёрами по Windows. Официального исправления пока нет, но сообщество уже нашло несколько временных обходных путей.

Критически важно: устанавливать октябрьские обновления Exchange Server для возникновения проблемы не требуется. Достаточно обновлений Windows Server.

Что именно произошло

13 октября 2026 года Microsoft выпустила октябрьские обновления безопасности для поддерживаемых версий Windows Server. Через два дня, 15 октября, на форумах и в блогах начали появляться массовые сообщения администраторов Exchange о сбоях.

Характер сбоя описан в отчётах пользователей:

«Установили октябрьские обновления. Примерно через 24 часа сервер Exchange перестал работать. OWA недоступен, почта не ходит. В логах MapiExceptionMdbOffline».

Другой администратор подтвердил:

«Можем подтвердить. У нас DAG-кластер. Один из серверов Exchange остановил службу баз данных примерно через 24-30 часов после автоматического обновления».

Какие обновления Windows Server виноваты

Microsoft назвала четыре обновления, которые могут быть связаны с проблемой:

Версия Windows ServerНомер обновления
Windows Server 2025KB5126646
Windows Server 2022KB5126655
Windows Server 2019KB5126651
Windows Server 2016KB5126868

Обновления Exchange Server (SU) за октябрь 2026 здесь ни при чём. Microsoft прямо указывает: «Установка октябрьских обновлений Exchange не требуется для возникновения проблемы». Проблема вызвана именно обновлениями уровня операционной системы Windows Server.

Симптомы и диагностика

Что видит пользователь

  • OWA не открывается. При попытке войти в почту через браузер появляется ошибка.
  • Почта не доставляется. Новые письма не приходят, отправленные зависают в очереди.
  • Outlook не подключается к серверу (в некоторых случаях).

Что видит администратор

  • Ошибка в OWA: MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142).
  • Event ID 1006 в журнале приложений (Application Log).
  • Почтовые очереди растут и не обрабатываются.
  • Exchange Admin Center может показывать базы данных как подключённые, хотя фактически они недоступны.

Что важно проверить

  1. Время после установки обновлений. Проблема проявляется примерно через 24 часа (по некоторым сообщениям от 22 до 36 часов).
  2. Журнал приложений на предмет Event ID 1006.
  3. Очереди сообщений через Exchange Management Shell или Queue Viewer.
  4. Доступность OWA это самый быстрый индикатор.

Кого затрагивает

Проблема затрагивает on-premises Exchange Server. В сообщениях упоминаются:

  • Exchange Server 2016 (в программе ESU).
  • Exchange Server 2019 (в программе ESU).
  • Exchange Server Subscription Edition (SE).

Гибридные среды также могут пострадать, но там ситуация осложняется дополнительными факторами (см. раздел про MRSProxy).

Exchange Online (облачная почта) не затрагивается проблема касается только локальных серверов.

Почему это происходит (что известно)

Microsoft не раскрыла точную техническую причину. В официальном сообщении говорится, что компания «расследует проблему совместно с партнёрами по Windows».

Однако независимый анализ, опубликованный в блоге Borncity, указывает на возможную связь с переполнением или утечкой в механизме RPC (Remote Procedure Call) на уровне Windows Server. Один из читателей блога описал workaround, который продлевает время работы сервера: изменение параметра реестра, связанного с RPC.

Официального подтверждения этой теории от Microsoft нет.

Временные обходные пути

Пока Microsoft не выпустила исправление, администраторы используют несколько подходов. Важно: это неофициальные методы. Применяйте их с осторожностью и только после тестирования в нерабочей среде.

Способ 1. Периодический перезапуск сервера (самый простой)

Если проблема проявляется через 24 часа, можно настроить автоматический перезапуск сервера до наступления критического момента.

Как это сделать:

  1. Создайте задачу в Планировщике заданий (Task Scheduler).
  2. Настройте триггер на перезапуск каждые 22 часа (или в удобное окно обслуживания).
  3. Действие: shutdown /r /t 0 (или перезапуск только служб Exchange, если это предпочтительнее).

Один из администраторов на Spiceworks прямо рекомендует: «Настройте задачу на перезапуск сервера с интервалом менее 22 часов. Желательно в удобное окно».

Плюсы: не требует изменения реестра, работает на всех версиях.

Минусы: перезапуск сервера это простой; для DAG-кластера нужно перезапускать узлы поочерёдно.

Способ 2. Правка реестра (продлевает время работы)

В обсуждениях на Tech Community и в блоге Borncity упоминается правка реестра, которая, по сообщениям, предотвращает сбой или продлевает время работы сервера.

Параметр:

  • Путь: HKLM\SOFTWARE\Microsoft\Rpc
  • Имя: EpmapSavedContextCap
  • Тип: REG_DWORD
  • Значение: 65536 (десятичное)

Команда для применения (от администратора):

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

Эта информация появилась в обсуждении на Spiceworks и была подхвачена другими администраторами. Microsoft официально не подтвердила этот метод. Эффект может зависеть от конфигурации сервера.

Способ 3. PowerShell-скрипт

В блоге Borncity упоминается, что читатель по имени Frank опубликовал PowerShell-скрипт, который может служить обходным путём. Конкретный код скрипта в открытых источниках не приводится, но, вероятно, он выполняет перезапуск служб Exchange или применяет настройки реестра автоматически.

#Requires -RunAsAdministrator
param(
[ValidateRange(513, 2147483646)]
[int]$Value = 16777215,
[switch]$Remove
)
$RegKey     = 'HKLM\SOFTWARE\Microsoft\Rpc'
$BackupFile = "$env:ProgramData\EpmapWorkaround\EpmapSavedContextCap-Backup.reg"
if ($Remove) {
reg.exe import $BackupFile
}
else {
if (-not (Test-Path $BackupFile)) {
# Nur den einen Wert sichern. War er nicht vorhanden, löscht "=-" ihn beim Import wieder.
$current = (Get-ItemProperty -Path "Registry::$RegKey").EpmapSavedContextCap
$line = if ($null -ne $current) { '"EpmapSavedContextCap"=dword:{0:x8}' -f $current } else { '"EpmapSavedContextCap"=-' }
New-Item -Path (Split-Path $BackupFile) -ItemType Directory -Force | Out-Null
"Windows Registry Editor Version 5.00", "", "[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc]", $line | Set-Content -Path $BackupFile -Encoding Unicode
}
New-ItemProperty -Path "Registry::$RegKey" -Name EpmapSavedContextCap -Value $Value -PropertyType DWord -Force

Рекомендация: если вы не уверены в содержимом скрипта, не запускайте его в production-среде. Используйте способы 1 и 2 как более прозрачные.

Способ 4. Переименование локальной учётной записи Administrator (для гибридных миграций)

Отдельная, но связанная проблема: с 12 октября 2026 года гибридные миграции (Exchange 2019 → Exchange Online) начали падать с ошибкой MRSProxy 401.

Симптомы:

  • Ошибка TooManyTransientFailureRetriesPermanentException или CommunicationErrorTransientException.
  • В IIS: POST /EWS/mrsproxy.svc возвращает 401.
  • В Event ID 4625: попытка входа от имени «Administrator» с пустым доменом, NTLM.

Workaround: переименование локальной учётной записи Administrator на сервере Exchange. По сообщениям, после переименования миграции снова работают.

Важно: это отдельная проблема, не связанная напрямую с MapiExceptionMdbOffline. Но она также появилась в октябре 2026 и может совпасть по времени.
Ссылка на обсуждение https://learn.microsoft.com/en-ca/answers/questions/6040561/hybrid-moves-fail-since-oct-2026-mrsproxy-401-even

Что делать администраторам: пошаговый план

  1. Оцените риск. Если у вас есть on-premises Exchange Server, и вы ещё не установили октябрьские обновления Windows Server приостановите развёртывание этих обновлений до получения официального исправления от Microsoft.
  2. Если обновления уже установлены:
  • Немедленно проверьте OWA и очереди сообщений.
  • Запланируйте перезапуск сервера (или узлов DAG) в ближайшее удобное окно, не дожидаясь 24 часов.
  • Рассмотрите правку реестра (способ 2), если перезапуск невозможен.
  1. Настройте мониторинг:
  • OWA (HTTP-запросы).
  • Очереди сообщений (Queue Length).
  • Event ID 1006 в журнале приложений.
  • Доступность баз данных.
  1. Для DAG-кластеров: перезапускайте узлы поочерёдно, чтобы сохранить доступность баз данных.
  2. Для гибридных сред: если миграции падают с MRSProxy 401, проверьте Event ID 4625 и рассмотрите переименование локальной учётной записи Administrator.
  3. Следите за обновлениями Microsoft. Официальное исправление должно появиться в ближайшее время. Следите за Tech Community blog Exchange Team.

Официальная позиция Microsoft

Microsoft подтвердила проблему 15 октября 2026 года, обновив сообщение в Tech Community. Компания заявила, что расследует проблему совместно с партнёрами по Windows.

Что известно на момент публикации:

  • Причина не подтверждена.
  • Официального исправления нет.
  • Microsoft не рекомендует удалять обновления безопасности, но и не запрещает, если это необходимо для восстановления работоспособности.

Рекомендация Microsoft: следите за обновлениями в блоге Exchange Team.

Часто задаваемые вопросы

Проблема вызвана обновлениями Exchange Server?

Нет. Проблема вызвана обновлениями Windows Server. Установка октябрьских обновлений Exchange не требуется для возникновения сбоя.

Мой Exchange Online затронут?

Нет. Проблема касается только on-premises Exchange Server.

Через сколько времени проявляется проблема?

Обычно через 24 часа после установки обновлений Windows Server. По некоторым сообщениям от 22 до 36 часов.

Поможет ли перезапуск сервера?

Да, перезапуск временно восстанавливает работоспособность. Но проблема может вернуться через следующие 24 часа, если обновления остаются установленными.

Безопасно ли удалять обновления Windows Server?

Microsoft не рекомендует удалять обновления безопасности, так как они закрывают критические уязвимости. Однако если Exchange не работает, удаление обновления может быть единственным способом восстановить сервис. Взвесьте риски.

Есть ли официальное исправление?

На момент публикации нет. Microsoft расследует проблему.

Что делать, если у меня DAG-кластер?

Перезапускайте узлы поочерёдно, чтобы сохранить кворум и доступность баз данных.

Правка реестра EpmapSavedContextCap безопасна?

Это неофициальный метод. Microsoft его не подтвердила. Тестируйте в нерабочей среде перед применением в production.

Что в итоге

Октябрьские обновления Windows Server 2026 года создали серьёзную проблему для администраторов on-premises Exchange. Серверы выходят из строя примерно через 24 часа после установки обновлений, OWA и почта становятся недоступны. Microsoft подтвердила проблему и расследует её, но официального исправления пока нет.

Что делать сейчас: приостановите развёртывание обновлений, если ещё не установили их. Если уже установили настройте мониторинг, запланируйте перезапуск или примените правку реестра. Следите за обновлениями от Microsoft.

Читайте также на блоге andko.ru

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest
0 комментариев
Популярные
Новые Старые

0
Оставьте комментарий! Напишите, что думаете по поводу статьи.x
Menu