Microsoft investiga fallos de Exchange tras las actualizaciones de Windows Server
Exchange Server 2016, 2019 y Subscription Edition pueden sufrir fallos tras las actualizaciones Windows de octubre, según el equipo de Exchange. Microsoft descarta retirar los parches y publica una mitigación provisional con Registro y reinicio.

Microsoft investiga inestabilidad de Exchange Server tras las actualizaciones de Windows Server distribuidas el 13 de octubre. El equipo de Exchange reconoció reportes a partir del 16 de octubre: algunos servidores pierden acceso a bases de datos de buzones, las colas de correo crecen y Outlook on the web puede dejar de responder. Microsoft no dice que afecte a todas las instalaciones ni lo atribuye a las actualizaciones de Exchange.
Un fallo que puede aparecer horas después
El aviso incluye Exchange Server 2016, 2019 y Subscription Edition, ejecutándose sobre versiones afectadas de Windows Server. Microsoft lista KB5126646 para Server 2025, KB5126655 para Server 2022, KB5126651 para Server 2019 y KB5126868 para Server 2016 como actualizaciones de Windows que pueden desencadenar el problema tras cierto tiempo. El alcance depende del servidor y de su carga: algunos pueden no verlo, y la rapidez o gravedad varía entre entornos.
Entre los síntomas, el equipo de Exchange destaca errores MapiExceptionMdbOffline al abrir Outlook on the web (OWA), con el evento 1006 en el registro de Aplicación. También pueden atascarse las colas de correo y algunos miembros de un Database Availability Group (DAG) pueden tener problemas para alcanzar quórum. Reiniciar puede recuperar el servicio de forma temporal, pero no elimina por sí mismo la causa que Microsoft sigue investigando.
-WinCrew dice: Que el reinicio devuelva OWA no equivale a que el incidente esté resuelto; si reaparece al día siguiente, el reloj también forma parte del síntoma.-
No desinstalar las actualizaciones de Windows
La recomendación oficial es no retirar las actualizaciones de Windows Server de octubre. Para servidores afectados, Microsoft publica una mitigación provisional: desde un símbolo del sistema elevado, configurar el valor de Registro EpmapSavedContextCap como REG_DWORD 65536 en HKLM\SOFTWARE\Microsoft\Rpc, reiniciar y vigilar si el fallo vuelve. Si reaparece, el equipo de Exchange indica que se eleve el límite. La compañía afirma que esta medida ha resuelto casos de clientes que ha asistido, pero no la presenta como arreglo definitivo.
El ajuste cambia un valor bajo la rama de RPC de Windows y exige un reinicio. Microsoft no describe en ese aviso una causa raíz confirmada ni lo presenta como arreglo definitivo. No es una orden para copiar a toda la granja sin evaluar impacto. Antes de aplicarlo, los administradores deberían confirmar que el servidor afectado coincide con el escenario, coordinar la ventana de reinicio y seguir el aviso de Microsoft para su versión. La fuente no documenta un procedimiento general de reversión, así que no conviene inventar uno ni tratar el ajuste como una solución permanente.
-WinCrew dice: En una plataforma de correo, «reiniciar y cruzar los dedos» es una ventana de mantenimiento demasiado optimista; Microsoft pide además medir si vuelve a ocurrir.-
Qué está confirmado y qué sigue pendiente
BornCity recogió reportes de administradores y describió fallos de bases de datos y colas de correo que aparecían tras las actualizaciones; después actualizó su seguimiento con el aviso del equipo de Exchange. Ese contraste ayuda a entender por qué el reconocimiento oficial importa, pero los informes no permiten calcular cuántos servidores están afectados ni concluir que cualquier error de Exchange de octubre tenga la misma causa.
La publicación de Microsoft estaba en investigación al actualizarse el 16 de octubre. No atribuye el problema a la actualización de seguridad de Exchange, no afirma que se reproduzca en todo Windows Server y no anuncia todavía una corrección definitiva. Para un administrador, la combinación útil es versión de Exchange, edición y build de Windows Server, KB instalada, hora hasta el fallo, registro de aplicación, estado de OWA, colas y quórum del DAG. Esos datos permiten comparar el incidente con el patrón descrito sin convertir una coincidencia temporal en diagnóstico automático.
El servidor puede parecer estable justo después del parche y fallar después bajo carga. Por eso, tras aplicar la mitigación autorizada, la comprobación debe incluir observación sostenida y seguimiento de las colas y bases de datos, no solo una prueba de inicio de sesión inmediatamente después del reinicio. El estado público sigue siendo investigación abierta: la mitigación provisional reduce el impacto en casos asistidos, pero no sustituye a una corrección permanente.
Diccionario de la Crew
OWA — Outlook on the web, interfaz web para acceder al buzón de Exchange.
DAG — Database Availability Group, grupo de disponibilidad que mantiene copias de bases de datos de Exchange entre servidores.
Endpoint Mapper — componente de RPC que permite localizar servicios y puntos de conexión en Windows.
