Ъпдейт за Windows Server чупи Exchange: пощата спира

Microsoft потвърди, че кумулативните ъпдейти за Windows Server от 13 октомври 2026 дестабилизират локалните инсталации на Exchange Server: потребителите не могат да влязат в Outlook on the Web, писмата увисват в Outbox, а опашките на транспорта растат. Проблемът е описан в съобщение на екипа на Exchange от 16 октомври и беше разпространен от BleepingComputer.

Кои ъпдейти и кои сървъри

Четири пакета носят проблема:

• KB5126646 — Windows Server 2025 (билд 26100.33650)
• KB5126655 — Windows Server 2022 (билд 20348.5761)
• KB5126651 — Windows Server 2019 (билд 17763.9376)
• KB5126868 — Windows Server 2016 (билд 14393.9612)

Засегнати са Exchange Server 2016, 2019 и Subscription Edition, когато са инсталирани върху тези версии на Windows. Тежестта зависи от натоварването — малък сървър с десетина потребители може да не усети нищо, докато натоварен клъстер спира за часове.

Важно уточнение: вината не е в октомврийския security update за Exchange (KB5128895). Microsoft изрично съветва да не го деинсталирате — той си остава необходим.

Какво виждате на практика

Симптомите се появяват не веднага, а около 20–24 часа след инсталацията, което подвежда доста администратори да търсят причината другаде. След това:

• OWA отказва вход, Outlook губи връзка с пощенската кутия;
• писмата стоят в Outbox, вътрешните и външните опашки се пълнят;
• репликацията в Database Availability Group се къса, членовете не събират кворум;
• Exchange Admin Center показва базите като монтирани, но те не отговарят.

В Application лога се появяват две характерни събития. Event ID 1006 от MSExchange Mailbox Replication дава MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142), а Event ID 4082 от MSExchangeRepl е още по-прям: „There are no more endpoints available from the endpoint mapper“.

Рестартът на сървъра връща пощата — но само докато броячът не се напълни отново.

Снимка: Microsoft

Защо се случва

Октомврийските ъпдейти въвеждат нов лимит в RpcEpMap.dll — компонента RPC Endpoint Mapper, който казва на клиентите на кой порт слуша дадена услуга. Лимитът е 512 запазени контекста за търсене и е добавен като защита срещу CVE-2026-96300 — пропуск от типа неконтролирана консумация на ресурси, който позволява отказ на услуга.

Проблемът е, че Exchange създава такива контексти непрекъснато и ги освобождава само когато съответният процес приключи. При нормален работен ден 512 се изчерпват за около едно денонощие, след което всяко ново RPC запитване се отрязва и Exchange докладва базите като офлайн.

С други думи — това не е грешка в кода на Exchange, а твърд таван, сложен от съображения за сигурност, който не е съобразен с реалните модели на достъп на Exchange. Подобни конфликти между хардънинг и съвместимост не са новост: същата логика видяхме и при пропуска в KVM, който пуска код от госта към хоста, където закърпването наложи промени дълбоко в хипервайзора.

Решението на Microsoft

Microsoft официално препоръча заобиколното решение на 16 октомври. От команден ред с administrator права на Exchange сървъра:

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

Еквивалентът в PowerShell:

New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Rpc `
  -Name EpmapSavedContextCap -Value 65536 -PropertyType DWORD -Force

След това сървърът трябва да се рестартира — ключът не се чете в движение. Препоръчителната начална стойност е 65536; ако проблемът се върне, тя може да се вдигне до 16777215, както описва Michel de Rooij в eightwone.com.

Контекст

Казусът е учебникарски пример защо локалният Exchange е все по-неблагодарен за поддръжка: една промяна в RPC стека на Windows поваля пощата, а бързото решение разменя достъпност за сигурност. Администраторите, които още не са ъпдейтнали, имат лукса да сложат ключа в регистъра преди инсталацията на пакета и да си спестят денонощието с пълни опашки.

Съветът, който важи независимо от кръпките: следете Event ID 4082 и състоянието на DAG-а активно, а не когато потребителите се обадят. Случаят, в който ConnectWise спря Cloud Backup след пробив в Microsoft 365, е различен по природа, но урокът е същият — колко бързо една инфраструктурна подробност се превръща в спряла услуга за всички.

Microsoft не е обявила кога ще излезе истинска поправка. Дотогава ключът в регистъра е единственото, с което разполагате — и не, деинсталирането на ъпдейтите не е решение, което компанията одобрява.