Home   2026-10-22 19:56:51

←

Microsoft waarschuwt dat Exchange Server kan uitvallen na Patch Tuesday-updates

Original article

Microsoft waarschuwt dat sommige Exchange-servers problemen kunnen hebben na de installatie van de recente Patch Tuesday-updateronde. Zo kan Outlook soms helemaal geen verbinding meer maken en kunnen e-mails blijven hangen. Microsoft zegt dat het probleem komt door vier specifieke updates voor Windows Server.

Microsoft schrijft op een ondersteuningspagina dat het sinds vorige week 'sommige meldingen ziet' van gebruikers bij wie Exchange Server-installaties 'instabiel' kunnen worden. Dat gebeurt sinds 13 oktober. Toen bracht Microsoft de Patch Tuesday-update voor oktober uit. Daarin werd opnieuw een recordaantal bugs gerepareerd, maar de updates leiden ook steeds vaker tot problemen.

In dit geval zitten de problemen in Exchange, soms specifiek in Outlook Web App. Daarin kunnen gebruikers en beheerders een foutmelding zien omdat Exchange OWA geen verbinding met de server kan maken. Ook kunnen e-mailwachtrijen vol komen te zitten en kunnen sommige gebruikers sneller dan verwacht tegen limieten aanlopen.

De problemen komen volgens Microsoft voor in Exchange Server 2016, 2019 of Subscription Edition. Microsoft zegt dat het in sommige gevallen kan helpen een server opnieuw op te starten.

Microsoft zegt dat vier verschillende updates voor Windows Server problemen kunnen veroorzaken. Daarbij noemt Microsoft ook Windows Server 2022 en 2025. Het bedrijf zegt dat niet alle servers worden getroffen.

Microsoft noemt geen definitieve oplossing, maar noemt wel een tijdelijke maatregel. Met het commando reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f kunnen de maximale RPC-componenten in de Endpoint Mapper worden verhoogd, wat het probleem mogelijk oplost.

Windows stock. Bron: Samuel Boivin/NurPhoto via Getty Images

Door Tijs Hofmans

Nieuwscoördinator

Feedback • 18-10-2026 11:35
37 • submitter: Technoid

18-10-2026 • 11:35

37

Submitter: Technoid

Lees meer

Reacties (37)

Microsoft zegt dat het probleem komt door vier specifieke updates voor Windows Server.
Nee het komt door dezelfde update, maar die heeft voor de 4 verschillende OS-versies telkens een ander KB-nummer:
De bugged copilot updates lijkt wel een regulier item te worden. Vertragen van de updates met een paar dagen en in de tussentijd de community is voor ons momenteel een prima voorzorgsmaatregel gebleken.
Wij hebben ook opgemerkt dat since 13 oktober we problemen hebben met onze exchangeSE server. Maar na een reboot werkt het weer. Moet kijken welke updated geïnstalleerd zijn door EPC en die weer te verwijderen!

Telkens rebooten is natuurlijk een tijdelijke oplossing. Hopelijk komen ze snel met een fix!

[Reactie gewijzigd door theduke1989 op 18 oktober 2026 11:45]

Advies van MS is de updates niet verwijderen, maar deze reg change doorvoeren: reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

zie ook: https://techcommunity.mic...ber-2026-windows-/4565382

Deze reg change lijkt voor nu goed te werken. Heb deze op een aantal getroffen servers uitgevoerd en sindsdien in ieder geval geen uitval meer gehad.

[Reactie gewijzigd door Dennism op 18 oktober 2026 13:48]

Wat er eigenlijk gebeurt is dat alle mail databases worden gedismount. Hierdoor kan uiteraard geen enkele mailbox meer geopend worden en loopt je mail queue vol.

Als je daarna een database dismount met de hand (want hij blijft zeggen dat ze gemount zijn) gaat dat prima. Echter zodra je hem weer probeert te mounten krijg je foutmeldingen. Die foutmeldingen zag je al in de event log op de achtergrond, Exchange zelf was er echter niet bewust van.

Powershell of via de web interface maakt daarbij trouwens geen verschil. Het herstarten van de Exchange services geeft geen oplossing, je moet echt rebooten.

[Reactie gewijzigd door Technoid op 18 oktober 2026 12:42]

Vroeg me al af waarom de store van de week ineens niet meer mounted was aldus owa.

Lost de register sleutel dit op? Bij mij kwam het overigens voor in een zeer kleine omgeving.
In theorie zou de key dit oplossen, dit zal de tijd echter moeten gaan uitwijzen of dat daadwerkelijk de oplossing is.
ging er net weer eentje onderuit bij een klant, lang leve goede monitoring, daar nu de reg fix gedaan en reboot. Fingers crossed. Ik wordt zo onderhand wel een beetje moe van de vibecoded updates..... Ze mogen de QA agent nog wel even beter opvoeden.

Wederom de stores dismounted.
Het vibecoden is het probleem niet.

Testen is het probleem! Hier is overduidelijk gewoon niet goed getest.
Beste moment om een update klaar te zetten is toch vrijdagmiddag 16u net voor je de deur dicht trekt? Echte mannen testen ofcourse in productie (yes, is joke)
Oplossen is veel gezegd: dit zet het gewoon helemaal op een maximum van blijkbaar 64K

Het is dus maar de vraag of dat aantal voor grote omgevingen voldoende hoog is en of die blijven hangen, welke door een reboot uiteraard allemaal gewoon worden weggegooid. Waarschijnlijk worden er dus plots veel meer calls per transactie gedaan dan voordien, maar is deze workaround in het geval van een reboot natuurlijk draconisch te noemen.

Ik hoop voor de getroffen klanten dan ook dat er snel een definitieve oplossing komt dmv een out-of-band update, want elke x aantal dagen je mailserver gaan rebooten alsof het 2003 was is natuurlijk wat van de gekke 8)7
want elke x aantal dagen je mailserver gaan rebooten alsof het 2003 was is natuurlijk wat van de gekke 8)7
Maar zeg nou zelf, dat waren toch prachtige tijden? :o
Hier ook een zeer kleine installatie en regkey net toegepast. Server wordt nu extra gemonitord. En natuurlijk bedankt weer Microsoft.

Update: na ruim een uur uiteindelijk KB5126651 verwijderd.

[Reactie gewijzigd door SignsOfLife op 18 oktober 2026 13:46]

Controleer via Powershell of ze dismounted zijn. Is makkelijk weer te mounten. Onze archive DB was dismounted. Maar de normale gelukkig niet.
Uiteraard ook via Poweshell geprobeerd maar je blijft fouten krijgen zoals "Unable to make connection to the server." met nog een hele lap tekst er voor en erna.
De databases worden niet dismounted (iig bij de gevallen die ik 'behandeld' heb de laatste dagen niet). Ik dacht eerst ook dat dit het geval was, en de foutmelding bij het openen van OWA lijkt dat ook te suggereren. maar bijvoorbeeld outlook zonder cache mode kan 'gewoon' verbinding maken met dit probleem actief, je kan ook gewoon mail blijven lezen in outlook alleen verzenden gaat niet meer (blijft in outbox hangen). Iets dat niet gaat wanneer de database met de betreffende mailbox daadwerkelijk dismounted is.

Ook het ECP geeft aan dat de databases gewoon mounted zijn, net als controles via powershell. Ik krijg eerder het idee dat (gezien ook de reg fix) dat er iets volloopt, waarna bepaalde componenten afhankelijk daarvan niet meer kunnen communiceren met de database. Ook andere zaken lijken niet gerelateerd aan de datastores lijken dan niet meer te werken. Een simpele Test-ComputerSecureChannel gaf bijvoorbeeld ook een verkeerd resultaat zodra het probleem 'actief' is, terwijl het na een reboot weer het correcte resultaat geeft.

[Reactie gewijzigd door Dennism op 18 oktober 2026 13:58]

Ja bijzonder hè!

De reden dat ik bijna er zeker van ben is door het ram geheugen verbruik van bepaalde services. Normaal zijn die enkele tientallen GB groot echter zodra je iets dismount dan is die slechts enkele mb of is het hele proces weg.
De service health pagina van Windows server 2025 meld voor exchange online ook nog:
The October 2026 update introduced a default limit on the amount of memory used by Endpoint Mapper when handling Endpoint Lookup calls. For workloads such as Exchange Server, the default limit of 512 simultaneous Endpoint Lookup calls might not be sufficient under heavy load. Administrators can use this registry setting to increase the maximum number of simultaneous Endpoint Lookup calls, which increases the amount of memory that Endpoint Mapper can use.

Microsoft Support: An additional mitigation is available for affected devices through Microsoft Support. To apply this mitigation in your organization, please contact Microsoft Support for business.
https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2025#5047msgdesc

Ze hebben op meerdere fronten zitten sleutelen en voor sommige is de regkey zoals in het artikel staat een mogelijkheid oplossing. Maar heb je last van de Server 2025 icm de Endpoint Lookup calls dan is Microsoft Support de way to go.

[Reactie gewijzigd door HKLM_ op 18 oktober 2026 11:53]

Het is wel een Catch 22 aan het worden. Microsoft wil dat je zo snel mogelijk update omdat er problemen zijn, maar nieuwe updates zorgen bijna altijd voor problemen, waardoor je beter niet meteen kunt updaten.
Is ook een mooie manier om de gebruikers die een eigen exchange runnen naar de 365 te krijgen natuurlijk.
Is er een MS product dat meer problemen en kwetsbaarheiden heeft dan MS Exchange Server? Je zou bijna denken dat ze dit met opzet doen, om bedrijven naar M365 te jagen...
Bor Coördinator Frontpage Admins / FP Powermod @SSH • 18 oktober 2026 12:30
Dat lijkt mij een stap te ver. Je gaat er hier vanuit dat veel kwetsbaarheden automatisch betekenen dat Microsoft het product bewust verwaarloost, en daar zie ik geen bewijs voor.

Exchange heeft vooral een lastig profiel: het is een complex product dat vaak rechtstreeks aan internet hangt, e-mail verwerkt en daardoor een zeer interessant doelwit is. Als er een kwetsbaarheid wordt gevonden, heeft die vaak direct impact en krijgt die veel aandacht.

Daarnaast moet je onderscheid maken tussen het aantal kwetsbaarheden en het aantal incidenten. Een kritieke kwetsbaarheid in een internet-facing Exchange-server is nu eenmaal zichtbaarder dan tien kwetsbaarheden in een product dat nauwelijks extern bereikbaar is.
Maar je kunt toch niet ontkennen dat er heel erg op lijkt dat ze vervolgens gewoon een halfbakken oplossing maken? Fijn dat er een kwetsbaarheid wordt verholpen, maar vervolgens wordt er weer een bug geïntroduceerd die, naar het zo lijkt, bij best wel veel organisaties impact heeft.

“We hebben een oplossing voor een DoS die eigenlijk in de praktijk niet echt een issue gaat zijn (CVE 5,9), maar daarbij heb je zeer grote kans dat je jezelf DoS-ed binnen 24 uur”

Een database dismount die niet wordt opgemerkt in het systeem zelf en geen recovery mechaniek heeft anders dan rebooten is gewoon niet handig. Nu dit bekend is opent het de deur voor phishing mails met “dringende exchange hotfixes” en het terugrollen van updates die wel degelijk belangrijk zijn, waarmee je dus weer die fixes teniet doet voor de kwetsbaarheden die je zeker wel wil patchen vooral vanwege internet facing services.

Mensen melden dat dit probleem ook in een labomgeving optreed zonder noemenswaardige load maar wel met een DAG opstelling die an sich al wel veel RPC verkeer genereert. de vraag is of men van tevoren bij andere teams geïnventariseerd heeft of een dergelijke setting problemen op zou kunnen leveren. Het limiet gaat van de standaard 65536 immers naar 512. Dat is nogal een andere ordegrootte.

Exchange is een van Microsofts grootste producten en ja het is complex, maar dat doen ze ook wel redelijk zelf. Neemt niet weg dat QA over de gehele linie wel een issue is waar MS mee bezig is.
challange is wel dat je zeker met hoeveelheid patches van deze maanden , en de hoeveelheid hardware in het veld. (In m365 is er maar een heel klein hardware profiel) en zo ontzetted veel configuratie combinaties zijn die gewoon niet te testen zijn,

Zelfs al pak je de hoofd 5 vendors (Dell Hp etc. ) X servers versies (16, 19, 22, 25) x de exchange versies (16,19,SE) X aantal patches

5*4*3*1102 = 66120 verschillende combinaties, en dan hebben we het nog niet over proc modellen, raid cards, memory etc.
Het ding is. Dit gaat bij vrijwel elke combinatie fout.

Het hele verhaal over hardware combinaties is natuurlijk een ding, maar dit is puur software en is niet per se afhankelijk van de hardware. Daarom zie je dit ook bij basis labopstellingen gewoon fiut gaan binnen 24 uur. Zet een dag opstelling aan en zelfs zonder users gaat het een keer stuk.

Microsoft heeft toegegeven dat ze een QA probleem hebben en dat was al voordat ze zoveel patches uitbrachten. Is het dan handig om de hoeveelheid patches op te schroeven als je weet dat je het niet kunt testen? Ben je dan niet gewoon blind patches tegen de muur aan het gooien en kijken wat er blijft plakken en wat je nog een keer op moet lossen?
En jij denkt / verwacht dat met M365 geen problemen ed mee zijn?....
Nee, niet minder problemen, M365 maakt het wel makkelijker deze te verhullen voor eindgebruikers. En perceptie telt tegenwoordig meer dan prestatie, lijkt het.
En jij denkt / verwacht dat met M365 geen problemen ed mee zijn?....
Nee maar wel 24/7 monitoring, patching en support. Op een niveau dat menig bedrijf zelf niet eens kan organiseren.
Microsoft doet dit niet bewust, als zoiets uit zou komen verliezen ze elk vertrouwen dat er is en dat zou hun verdienmodel enorm beschadigen. Wel wordt er onvoldoende getest. Zowel door Microsoft, maar kennelijk ook door klanten....
Als dit wat minder vaak zou voorkomen zou ik niet steeds moeite hoeven doen om mijn systeem niet te laten updaten. Updates stel ik tegenwoordig 5 weken uit omdat ik iedere keer problemen heb. Visual Studio updates klik ik iedere keer weg, mocht je het vergeten dan gaat hij gelijk updaten zodra je hem uitzet. Doe je dat niet, dan blokkeren ze de toegang tot het programma. Je zult maar net een release doen of iets belangrijks doen en Microsoft drukt weer een update door je neus. Gisteren heb ik perongeluk de popup niet optijd weggedrukt. En ja hoor, ik moest weer een update installeren nadat het programma uit gaat. Je weet wel, het moment dat je weg moet. En wat denk je? Update maakt Visual Studio kapot. Nu dit bericht weer. Ze hebben een update, maar het maakt ook weer wat stuk. Serieus Microsoft?
1 keer instellen dat je een netwerk verbinding met data limiet hebt en windows doet geen enkelen update meer
Ik ga echt conciërge worden bij een basisscholencomplex... Met lichte IT-werkzaamheden, sterk in administratief werk (in tegenstelling tot menig ander).
Zo klaar met Microwave shit...
Kan meteen een woensdagmiddag reserveren voor talentontwikkeling "het zwarte scherm; linux"
Een restart van de Exchange Server (HyperV on Windows Server 2019) loste het probleem op, tot de volgende dag de boel weer vast zat.

[Reactie gewijzigd door FulcoS op 18 oktober 2026 18:12]

Wij hadden een ander issue met Server 2019 na deze update. Storage space volumes waren offline. Niet alles maar wel een aantal. Nogal vervelend wanneer het een SQL server is.

Om te kunnen reageren moet je ingelogd zijn