Exchange nestabilnost posle Windows ažuriranja. Microsoft preporučuje privremenu registracionu mitigaciju umesto uklanjanja bezbednosnih zakrpa dok istražuje ograničenje RPC Endpoint Mapper konteksta.
Tema je proverena prema izvoru Microsoft Exchange Team. Fokusna fraza „Exchange nestabilnost posle oktobarskih Windows ažuriranja“ odnosi se na konkretno ažuriranje i njegove praktične posledice.
Koji sistemi i simptomi su obuhvaćeni
Microsoft upozorava da Exchange Server može postati nestabilan nakon instaliranja oktobarskih kumulativnih ažuriranja za Windows Server. Problem nije vezan za samu instalaciju Exchange bezbednosnih zakrpa. To znači da ga mogu videti i okruženja koja su ažurirala operativni sistem, ali nisu promenila Exchange build. Prijavljeni simptomi uključuju neuspešne prijave u Outlook on the web, grešku MapiExceptionMdbOffline, rast transportnih redova i probleme sa prebacivanjem baza u Database Availability Group konfiguracijama.
Obuhvat uključuje podržane Exchange Server verzije na Windows Server 2016, 2019, 2022 i 2025 sistemima. Intenzitet nije isti svuda. Microsoft kaže da brzina pojave problema zavisi od opterećenja, pa neki serveri mogu raditi dugo bez vidljivog kvara, dok drugi počinju da otkazuju posle približno jednog dana. Privremeni restart može vratiti funkcionalnost, ali ne uklanja osnovni uzrok.
Zašto dolazi do nestabilnosti
Zvanično objašnjenje upućuje na ograničenje broja istovremeno sačuvanih RPC Endpoint Mapper konteksta. Posle Windows ažuriranja podrazumevani limit iznosi 512. Exchange pod opterećenjem može nastaviti da akumulira kontekste sve dok novi RPC pozivi ne počnu da otkazuju. Baze podataka pritom mogu izgledati montirano i zdravo, iako servisi više ne mogu pouzdano da im pristupe. To administratoru može otežati dijagnozu ako proverava samo status baze.
Važno je razlikovati uzrok od vremenske podudarnosti. Oktobarski Exchange paket može biti instaliran u istom prozoru održavanja, ali Microsoft kaže da je problem u Windows Server komponenti. Zbog toga uklanjanje Exchange zakrpe ne bi predstavljalo ciljanu korekciju. Sličan princip važi i kod drugih infrastrukturnih incidenata: prvo treba potvrditi sloj na kome greška nastaje, kao u našem vodiču za Windows DNS Server zaštitu.
Privremena mitigacija
Microsoft preporučuje dodavanje DWORD vrednosti EpmapSavedContextCap u granu HKLM\SOFTWARE\Microsoft\Rpc i postavljanje decimalne vrednosti 65536, zatim restart servera. Ova izmena povećava prostor za sačuvane Endpoint Mapper kontekste. Ako se problem ponovi, Microsoft podrška može preporučiti dodatno povećanje, ali promenu ne treba naslepo kopirati na svaki server bez evidencije, prozora održavanja i plana povratka.
Kompanija izričito savetuje da administratori ne uklanjaju oktobarska Windows bezbednosna ažuriranja kao standardno rešenje. To bi moglo vratiti operativnu stabilnost, ali bi istovremeno otvorilo poznate ranjivosti. Ispravniji pristup je testiranje mitigacije, potvrda kroz događaje i transportne redove, pa pažljivo uvođenje na ostale članove okruženja.
Šta pratiti posle promene
Posle restarta treba nadgledati OWA prijave, transportne redove, Event Viewer zapise i DAG operacije. Korisno je beležiti broj sati do eventualnog povratka simptoma i uporediti ga sa opterećenjem. U višeserverskom okruženju promenu treba uvoditi kontrolisano kako bi barem jedan član ostao dostupan. Zdrav status baze sam po sebi nije dovoljan dokaz da MAPI i transport rade ispravno.
Administratori treba da provere Microsoftovu aktuelnu objavu pre svakog narednog koraka, jer se preporuka može promeniti kada stigne vanredna ispravka. Ako okruženje pokazuje drugačije simptome, treba otvoriti podršku umesto primene sve većih vrednosti registra bez dijagnoze.
Exchange nestabilnost posle Windows ažuriranja: kontrolna lista
Pre izmene registra administrator treba da zabeleži trenutno stanje: broj poruka u redovima, aktivne baze, stanje ključnih servisa, raspoloživ prostor i vreme poslednjeg restarta. Zatim se promena uvodi u planiranom prozoru, prvo na jednom članu grupe visoke dostupnosti. Posle restarta proveravaju se klijentske prijave, slanje i prijem poruka, replikacija baza i novi događaji u dnevnicima. Tek kada su sve funkcije stabilne, isti postupak se prenosi na ostale servere.
Važno je i unapred definisati uslov za eskalaciju. Ako se Exchange nestabilnost posle Windows ažuriranja vrati uprkos preporučenoj vrednosti, ako se pojave drugačije MAPI greške ili ako baza izgubi zdrav status, sledeći korak nije nasumično povećavanje registra. Potrebno je sačuvati dijagnostičke podatke i uključiti Microsoft podršku. Tako se izbegava da privremena mitigacija prikrije zaseban problem u skladištu, mreži ili konfiguraciji.
Zaključak
Ovo je primer konflikta između bezbednosti i dostupnosti koji se rešava preciznom mitigacijom, a ne povlačenjem svih zakrpa. Microsoft je identifikovao Endpoint Mapper limit kao uzrok i ponudio privremenu registracionu promenu. Dok trajna ispravka ne bude dostupna, ključni koraci su kontrolisano testiranje, restart u održavanom terminu, nadzor svih Exchange funkcija i dokumentovanje svake promene.
