Październikowe aktualizacje Windows Server zatrzymują Exchange. Obejście wdrażasz przed patchem, a nie po awarii, i traktujesz je jak zmianę bazową

Od Patch Tuesday 13 października część lokalnych serwerów Exchange po instalacji aktualizacji Windows Server traci dostęp do skrzynek, a kolejki poczty rosną. Przyczyną nie jest podatność ani październikowa poprawka samego Exchange, tylko nowy domyślny limit w RPC Endpoint Mapper. Fakty i zalecenie „nie odinstalowuj” streszczałem już we wpisie o październikowym SU dla Exchange. 20 października Microsoft dopisał do swojego komunikatu FAQ, które zmienia sposób obsługi tematu w procesie: wartość rejestru można ustawić przed instalacją aktualizacji, a kolejnej poprawki w najbliższym czasie nie będzie. Obejście przestaje więc być reakcją na awarię, a staje się częścią planu wdrożenia i konfiguracji bazowej serwera.

Objawy, które można zmierzyć

Microsoft wymienia: błąd OWA MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142) ze zdarzeniem 1006 w dzienniku Application, wiadomości zostające w Skrzynce nadawczej Outlooka, kolejki rosnące w ciągu dnia, problemy z dostępem do skrzynek przy replikacji i członków DAG, którzy nie osiągają kworum. Restart pomaga tylko na chwilę, a objawy narastają „after certain time”. To ważne dla okna serwisowego: serwer, który działa godzinę po restarcie, nie jest jeszcze dowodem, że problem go nie dotyczy.

Co zmieniło FAQ z 20 października

Microsoft dopisał trzy odpowiedzi, które mają bezpośredni wpływ na proces:

• Nie czekaj i nie odinstalowuj. „October 2026 updates for Windows Server carry a significant security payload and installation of those updates should not be delayed for the sake of a single issue with Exchange server interoperability.” Te same KB zamykają m.in. CVE-2026-96951, które jest w CISA KEV od 13 października.
• Klucz można utworzyć wcześniej. „Creating the registry key beforehand has no impact on Windows Server because the registry key is read and used only once October 2026 Windows Server updates are installed.” Wartość przetrwa instalację aktualizacji.
• Kolejnej poprawki w najbliższym czasie nie będzie. „There is no imminent follow-up release from either Windows or Exchange. Both teams are still analyzing this long-term.”

Microsoft dopisał też, że podnoszenia limitu powyżej 65536 „we have so far not seen any cases where this might be needed”. Pierwotna wersja komunikatu mówiła tylko „if it re-occurs, raise the limit”.

Wniosek 1: obejście należy do planu wdrożenia, nie do reakcji na incydent

Najczęstszy scenariusz w organizacjach wygląda tak: pierścień serwerów Exchange dostaje październikowe aktualizacje Windows, po kilku godzinach rosną kolejki, zespół poczty eskaluje, a ktoś proponuje cofnięcie aktualizacji, bo „przed patchem działało”. Skoro wartość można ustawić z wyprzedzeniem i nie ma ona wpływu przed instalacją, ten scenariusz da się wyeliminować. Na serwerach Exchange, które jeszcze nie dostały październikowych aktualizacji, wdrożenie powinno wyglądać tak: najpierw wartość rejestru, potem aktualizacja i restart, na końcu kontrola usług. Serwery, które dostały aktualizację bez klucza i jeszcze nie mają objawów, nie są „bezpieczne”. Objawy zależą od obciążenia i mogą pojawić się w szczycie.

Wniosek 2: obejście bez daty końca to zmiana bazowa

Gdy dostawca zapowiada poprawkę, obejście zapisuje się jako wyjątek tymczasowy z terminem. Tu Microsoft mówi wprost, że poprawki „w najbliższym czasie” nie będzie. Wartość rejestru stanie się więc na dłużej elementem konfiguracji każdego serwera Exchange.

Druga kolumna jest trudniejsza, ale uczciwsza. Najgroźniejszy przypadek to nowy serwer Exchange, odtworzony z obrazu po awarii albo dodany do DAG w listopadzie, bez tej wartości. Przejdzie normalny cykl aktualizacji i w szczycie zacznie gubić pocztę, a nikt nie powiąże tego z komunikatem sprzed miesiąca. Wartość powinna więc trafić do skryptu budowy lub polityki konfiguracji, z komentarzem: źródło, data i warunek usunięcia („do przeglądu po publikacji przez Microsoft rozwiązania długoterminowego”).

Zakres: Microsoft opisuje obejście dla serwerów Exchange („From an elevated Command Prompt on an Exchange Server”). Komunikat nie zaleca go dla innych serwerów Windows i nie wyjaśnia, w jakim celu wprowadzono limit ani jaki jest koszt pamięciowy wartości 65536. Dlatego nie rozciągałbym tej zmiany na całą flotę „na wszelki wypadek”. Limit wprowadziła aktualizacja bezpieczeństwa, a powodu jego wprowadzenia Microsoft nie podaje. Rozsądniej przyjąć, że ma uzasadnienie, i zmieniać go tylko tam, gdzie zaleca to dostawca. Czy limit wiąże się z którymś z październikowych CVE, nie udało mi się ustalić.

Wniosek 3: nie obwiniaj SU dla Exchange

Microsoft dwukrotnie podkreśla, że problem nie wynika z październikowego SU dla Exchange i występuje także bez niego. W praktyce zbieżność dat podpowiada odwrotnie: Exchange SU i aktualizacje Windows często wchodzą w tym samym oknie. Wstrzymanie SU dla Exchange w reakcji na tę awarię nic nie da, a zostawi otwarte październikowe podatności Exchange, w tym RCE wyzwalane e-mailem opisane w poprzednim wpisie. Dla Exchange 2016 i 2019 październik był też ostatnim miesiącem poprawek w programie Period 2 ESU, więc odłożony SU może już nie mieć następcy.

Kryterium zamknięcia: stan usługi, nie kod instalatora

Raport „KB zainstalowane na 100% serwerów Exchange” nie mówi, czy poczta działa. Dla tej zmiany proponuję dwa osobne pola w zgłoszeniu:

• Status poprawki: KB zainstalowane, serwer zrestartowany, build potwierdzony.
• Status usługi: wartość EpmapSavedContextCap obecna, OWA logowanie działa, długość i wiek kolejek w normie, replikacja i kworum DAG bez błędów, brak zdarzenia 1006 przez co najmniej jeden pełny cykl obciążenia (dzień roboczy), a nie tylko godzinę po restarcie.

Zgłoszenie zamyka się dopiero wtedy, gdy oba pola są zielone. Jeżeli na którymś serwerze rozważane jest wstrzymanie aktualizacji Windows, to powinna być czasowa, zatwierdzona decyzja ryzyka z terminem, a nie domyślna reakcja. Mając obejście od dostawcy, trudno ją uzasadnić.

Co powinien zrobić VE

1. Lista serwerów: wszystkie serwery Exchange (także członkowie DAG i serwery hybrydowe) z wersją Windows, stanem październikowych KB i obecnością wartości rejestru.
2. Serwery przed aktualizacją: ustaw wartość rejestru przed instalacją, zgodnie z FAQ Microsoftu, w ramach tej samej zmiany.
3. Serwery po aktualizacji bez wartości: ustaw ją z restartem w najbliższym oknie, nawet bez objawów. Zbierz przed zmianą podstawowe pomiary (kolejki, OWA, replikacja), żeby było z czym porównać.
4. Konfiguracja bazowa: dodaj wartość do budowy serwera Exchange i do kontroli dryfu. Opisz źródło i warunek przeglądu.
5. Nie rozszerzaj zakresu bez potrzeby: zmiana dotyczy serwerów Exchange. Inne serwery z nietypowymi objawami RPC po październikowych aktualizacjach zgłaszaj do Microsoftu, który oferuje dodatkowe obejście przez Support for business.
6. Raportuj osobno status poprawki i status usługi. Nie wstrzymuj SU dla Exchange z powodu tej regresji.
7. Obserwuj komunikat Exchange Team i sekcję „Known issues” w KB. Gdy pojawi się rozwiązanie długoterminowe, wartość rejestru trzeba będzie przejrzeć.

Powiązane na blogu

• Exchange CVE-2026-70571: RCE wyzwalany e-mailem i październikowy SU — tam pierwsze streszczenie tej regresji i kryteria zamknięcia SU
• Windows Shell CVE-2026-96951 — zero-day z KEV zamykany tymi samymi aktualizacjami Windows
• Ghostscript na RHEL 8 CVE-2026-112177 — inna regresja po poprawce i jak ją obsłużyć w VM

Źródła

• Microsoft Exchange Team — „Exchange servers may become unstable after installation of October 2026 Windows updates” (z FAQ dodanym 20.10.2026) — techcommunity.microsoft.com
• Microsoft Support — KB5126646, Windows Server 2025, sekcja „Known issues in this update” (limit 512 wywołań Endpoint Lookup) — support.microsoft.com
• Microsoft Exchange Team — Released: October 2026 Exchange Server Security Updates — techcommunity.microsoft.com
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-96951, wersja katalogu 2026.10.21) — cisa.gov

Nota redakcyjna: wpis powstał na podstawie szkicu VMRT Radar z 19 października 2026 i został zweryfikowany ze źródłami pierwotnymi 20 października 2026, a ponownie 22 października 2026 (ok. 22:40 CEST): wpis Exchange Team (treść, data modyfikacji 20.10.2026, FAQ), sekcja „Known issues” w KB5126646 oraz katalog CISA KEV w wersji 2026.10.21. Względem szkicu dodałem odpowiedzi z FAQ z 20.10 (klucz przed instalacją, brak bliskiej kolejnej poprawki, brak przypadków wymagających wartości powyżej 65536), wynikające z nich zmiany w procesie oraz informację, że opis limitu 512 pochodzi z KB, a nie z wpisu Exchange Team. Nie potwierdziłem: artykułu BleepingComputer (nie udało się go pobrać), stron KB5126655, KB5126651 i KB5126868 osobno (numery za wpisem Exchange Team), powodu wprowadzenia limitu i jego związku z którymkolwiek CVE, kosztu pamięciowego wartości 65536, czy problem dotyczy serwerów innych niż Exchange, ani na czym polega dodatkowe obejście dostępne przez Microsoft Support. Podział na wyjątek i zmianę bazową, kryterium zamknięcia i lista działań to oceny autora, nie zalecenia Microsoftu.