Error 0x80240069 al usar WSUS en Windows 11 24H2: causas, síntomas y solución

Cuando toca desplegar una nueva versión de Windows 11 en empresa, cualquier tropiezo con WSUS puede convertirse en un dolor de cabeza. En las últimas oleadas, varios administradores han visto cómo la actualización a Windows 11 24H2 se cae con el código 0x80240069 nada más empezar, incluso lanzándola desde el Centro de Software de Configuration Manager.

La casuística se repite: el servicio de Windows Update se detiene de forma inesperada, los registros se llenan de errores y, pese a permitir descargas directas desde Microsoft Update, el proceso sigue fallando en equipos gestionados mediante WSUS. La buena noticia es que Microsoft ya ha reconocido el problema, lo ha mitigado con revisiones y ofrece vías claras para solucionarlo o, como mínimo, capear el temporal mientras llega el arreglo definitivo.

Qué está pasando con el error 0x80240069 en entornos WSUS

En escenarios con Configuration Manager (por ejemplo, ConfigMgr 2409) y clientes en Windows 11 23H2 que intentan dar el salto a 24H2, se han observado fallos inmediatos con 0x80240069 (-2145124247) al iniciar la actualización desde el Centro de Software. El registro CAS.log suele reflejar algo tipo “error al descargar contenido; liberando la solicitud”, lo que apunta a un corte en la fase de obtención del paquete.

Coincidiendo con ese momento, el Visor de eventos muestra varias pistas: “El servicio Windows Update finalizó inesperadamente”, trazas que no arrancan (como WindowsUpdate_trace_log con 0xC0000035) y referencias a svchost.exe_wuauserv. Curiosamente, si el mismo equipo se deja escanear e instalar parches directamente contra Microsoft Update, la operación funciona, lo que sugiere que el agente WU no está roto y el problema aparece al pasar por WSUS.

En otro caso real con Windows 11 24H2 durante las actualizaciones de agosto, el Centro de Software marcaba como fallidos tanto KB5063878 como KB890830. El registro WUServiceWatcher reportaba que wuauserv se cerraba con el código 1067 y en Eventos de Aplicación se veía una excepción 0xc0000005 en ntdll.dll para el proceso svchost.exe_wuauserv. En equipos con Windows 10 o Windows Server 2022 del mismo entorno, sin embargo, todo iba como la seda.

Reconocimiento oficial de Microsoft y estado de las correcciones

Microsoft ha confirmado un problema que afectaba a la entrega de la actualización de características de Windows 11 24H2 a través de WSUS, especialmente tras instalar los parches de seguridad de abril de 2025 (por ejemplo, KB5055528 y posteriores). En este contexto, en muchos clientes la descarga ni siquiera comenzaba o se interrumpía, y el registro de Windows Update mostraba 0x80240069 además del mensaje de que el servicio wuauserv se detuvo inesperadamente.

Para resolverlo, Microsoft ha publicado una serie de correcciones que abarcan varias capas: un paquete específico para servidores WSUS, cambios del lado del cliente y revisiones en metadatos de las actualizaciones. En algunos despliegues, el fabricante llegó a aplicar un KIR (Known Issue Rollback) y posteriormente revisó el paquete problemático, de manera que, tras resincronizar WSUS y aprobar la revisión, los clientes volvieron a actualizar sin incidencias.

La recomendación práctica es clara: conviene asegurarse de que tanto los servidores WSUS como los clientes tienen instaladas las últimas acumulativas, comprobar el estado de sincronización y forzar una nueva sincronización si fuera necesario para que bajen los metadatos corregidos. En múltiples casos reportados, al día siguiente de la revisión, la implementación progresó con normalidad tras la resync y la aprobación correspondiente.

KB5063878 y otros síntomas específicos que se han visto

La acumulativa de seguridad KB5063878 para Windows 11 24H2 ha sido una de las más mencionadas en estos incidentes, con usuarios que veían el 0x80240069 al intentar instalarla. Junto a ello, los registros del sistema evidenciaban reiteradas paradas inesperadas del servicio Windows Update, algo que en la práctica dejaba la actualización en un bucle de error.

Conviene recordar que KB5063878 es importante: aporta más de un centenar de correcciones de seguridad (107 vulnerabilidades), por lo que dejarla sin desplegar no es una opción en entornos corporativos. En lo que respecta a WSUS, algunos administradores hallaron una medida provisional para sortear el bloqueo: importar manualmente los paquetes a WSUS a partir de sus identificadores.

Para ser concretos, se han compartido estos GUID para la importación manual: Windows 11 24H2 (x64): 8018eab0-7242-4932-adf2-afda36f6b3f6 y Windows Server 2025 (x64): 92061378-be93-4659-a72a-037225e6bb0f. Aunque no es lo ideal, este enfoque ha permitido a algunos equipos desbloquear el despliegue mientras llegaba la revisión oficial de metadatos o el parche para WSUS.

En paralelo, hubo administradores que sospecharon de Delivery Optimization (DO) por el patrón de los errores, pero al habilitar la descarga directa desde Microsoft Update en el cliente ConfigMgr el fallo persistía, reforzando la idea de que el origen real estaba en WSUS o en la combinación de metadatos + parches mensuales.

Cómo se manifestó el bloqueo tras los parches de abril de 2025

Tras el Patch Tuesday de abril de 2025, Microsoft advirtió que los dispositivos con la actualización de seguridad mensual de abril (a partir de KB5055528) podían quedarse sin posibilidad de actualizar a Windows 11 24H2 mediante WSUS. El escenario típico era que la descarga no arrancaba o no concluía, con 0x80240069 en WindowsUpdate.log y el servicio de Windows Update deteniéndose de golpe.

Inicialmente no hubo solución inmediata pública; el fabricante pidió tiempo mientras trabajaba en un fix. Con posterioridad, entre KIR, revisiones de paquetes y actualizaciones específicas para WSUS, la rueda ha vuelto a girar, pero es clave que cada organización valide su cadena: versión de WSUS, sincronización correcta, aprobaciones vigentes y clientes al día.

Este no es el primer episodio de este tipo: en meses anteriores, clientes empresariales con Windows 11 22H2 y 23H2 también toparon con el mismo código 0x80240069 al intentar moverse a 24H2 por WSUS, y se solventó con acciones similares por parte de Microsoft en metadatos y servidor.

Medidas provisionales recomendadas si sigues atascado

Más allá de esperar a la corrección oficial, hay vida. Una opción es posponer temporalmente la instalación de los parches de abril de 2025 si tu plan inmediato es actualizar a 24H2 vía WSUS y estás todavía a tiempo de ajustar ventanas de mantenimiento.

Otra vía es optar por métodos alternativos para la actualización de características: Media Creation Tool, Windows Update Assistant o ISO oficial en despliegues controlados. Estas rutas eluden WSUS para el paquete de feature update, con lo que puedes completar el salto a 24H2 y, después, volver al carril habitual de WSUS para acumulativas y calidad.

Si necesitas que pase por WSUS sí o sí, puedes probar la importación manual por GUID mencionada antes. Y, en paralelo, asegúrate de que el servidor WSUS ha recibido y aplicado cualquier hotfix publicado por Microsoft para este problema concreto, seguido de una resincronización y verificación exhaustiva de metadatos en consola.

Diagnóstico rápido: qué revisar en los clientes y en WSUS/ConfigMgr

Como regla de oro, conviene empezar por los logs clave. En clientes gestionados por Configuration Manager, WUAHandler.log y WindowsUpdate.log son tus mejores aliados. El primero refleja lo que informa el Agente de Windows Update, y el segundo es donde aparece el detalle de la causa (incluido 0x80240069 cuando aplica). Si WUAHandler.log ni siquiera se genera tras forzar un ciclo de examen, seguramente hay un problema de directivas, ubicación de WSUS o comunicación con el punto de actualización de software.

Antes de nada, confirma que el Agente de Windows Update está actualizado y, si sospechas de corrupción local, restablece el almacén SoftwareDistribution del cliente: detén el servicio WU, renombra la carpeta y arranca de nuevo. Comandos típicos: net stop wuauserv, cambia C:\Windows\SoftwareDistribution a SoftwareDistribution.old, y ejecuta net start wuauserv. Tras ello, lanza un examen de actualizaciones desde el cliente.

Si ves errores relacionados con proxy, revisa la configuración de WinHTTP. Comprueba con netsh winhttp show proxy y, si tienes el proxy correcto en Internet Explorer/Configuración de Windows, impórtalo con netsh winhttp import proxy source=ie. Entre los códigos habituales por proxy mal configurado se encuentran 0x80244021 (HTTP 502), 0x8024401B (HTTP 407), 0x80240030 o 0x8024402C.

Para descartar problemas de conectividad con WSUS, verifica la URL desde el cliente. Localiza la configuración en el registro en HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate y prueba el acceso a rutas típicas: http://SERVIDOR:8530/Selfupdate/wuident.cab, http://SERVIDOR:8530/ClientWebService/wusserverversion.xml y http://SERVIDOR:8530/SimpleAuthWebService/SimpleAuth.asmx. Si fallan, es probable un corte de DNS, firewall, puertos o proxy.

Hablando de puertos, WSUS puede trabajar con 80, 443, 8530 o 8531. Asegúrate de que están abiertos de extremo a extremo. Un telnet rápido (telnet SERVIDOR 8530) te da una pista instantánea. Si tu IIS está en juego, revisa en Administrador de IIS los enlaces del sitio WSUS para confirmar que la configuración de puerto cuadra con la del rol de punto de actualización en ConfigMgr.

SSL, certificados y el error 0x80072f0c

Si tienes WSUS con SSL y ves el código 0x80072f0c, revisa que los directorios virtuales de WSUS estén en SSL pero con “omitir certificados de cliente”. Si por error se ha configurado Aceptar o Requerir certificados de cliente, el escaneo da de bruces. En el punto de actualización de software de ConfigMgr, activa “requerir comunicación SSL” sólo si el sitio está preparado, con su certificado de autenticación de servidor instalado y enlazado al sitio en IIS.

En IIS, comprueba los enlaces HTTPS del sitio WSUS y que el certificado correcto está seleccionado. Si falta, asígnalo en Editar enlace de sitio, guarda y reinicia lo necesario. Después, valida que la consola WSUS tiene marcada la opción de usar SSL al sincronizar, para que no haya desajustes de configuración entre servidor y punto de actualización.

Directivas de grupo que pisan la configuración de WSUS

Otro clásico: la GPO de dominio sobrescribe la configuración local que aplica Configuration Manager para apuntar a su punto de actualización y puerto. Si el valor en la GPO no coincide exactamente con el que necesita tu punto de actualización (incluido FQDN y puerto), el examen falla. En WUAHandler.log verás que las directivas del dominio han sustituido las locales y, a partir de ahí, el cliente no encuentra su servidor.

Solución: alinear GPO con Configuration Manager. Esto implica que el nombre del servidor y el puerto coincidan con los del punto de actualización de software. Por ejemplo, si se usa el sitio web predeterminado, la URL debe incluir el FQDN correcto y el puerto (p. ej., http://server1.contoso.com:80). Cuando están alineadas, el cliente ya no se desorienta.

Más comprobaciones para afinar el diagnóstico

Si el punto de administración devuelve una ubicación WSUS vacía al cliente, puede haber un desajuste de la versión de contenido en WSUS por una sincronización fallida. En la consola de ConfigMgr, revisa el estado de sincronización del punto de actualización. Si toca rascar, mira las tablas CI_UpdateSources, WSUSServerLocations y Update_SyncStatus, validando que el identificador de origen y la versión de contenido coinciden.

Habilita registro detallado y de depuración tanto en el cliente como en el punto de administración. Asegúrate de que CcmMessaging.log está limpio de errores de comunicación. Si el examen se ejecuta y finaliza, deberían enviarse mensajes de estado al punto de administración; si no llegan, revisa el flujo de procesamiento de mensajes y cualquier bloqueo intermedio.

Otros códigos de error frecuentes y su significado

En el ámbito de WSUS/ConfigMgr hay una retahíla de códigos que conviene reconocer para no perder tiempo. Los 0x80245003, 0x80070514, 0x8DDD0018, 0x80246008, 0x80200013, 0x80004015, 0x800A0046, 0x800A01AD, 0x80070424, 0x800B0100 y 0x80248011 suelen apuntar a componentes ausentes o dañados. Muchas veces se arreglan con el solucionador de problemas de Windows Update o con el reset del repositorio del agente (SoftwareDistribution).

En problemas de conectividad, verás 0x80072ee2, 0x8024401C, 0x80244023, 0x80244017 (HTTP 401) y 0x80244018 (HTTP 403). En estos casos, confirma puertos, proxy, firewall y que el cliente llega a los directorios virtuales ClientWebService y SimpleAuthWebService de tu WSUS. Si IIS no devuelve el error en sus logs, suele haber un cortafuegos/proxy en el medio que está cortando la comunicación.

Con 0x80240069, el patrón observado en esta incidencia es distinto: no es que el cliente no alcance WSUS, sino que la descarga/instalación del feature update 24H2 falla por incompatibilidades transitorias (metadatos, revisión de paquetes o interacción con parches mensuales), resueltas por Microsoft con revisiones y actualizaciones.