Cómo solucionar el error 0x80244017 en Windows 11 Enterprise

W11 » Tutoriales para Windows 11 » Cómo solucionar el error 0x80244017 en Windows 11 Enterprise

Cuando aparece el error 0x80244017 en Windows 11 Enterprise suele pillarnos a contrapié: las actualizaciones no se instalan, los clientes de ConfigMgr/SCCM se quedan con estado “desconocido” y, para rematar, RSAT o las características opcionales se niegan a instalarse. Todo ello, normalmente, acompañado de una referencia al estado HTTP 401 que indica problemas de autenticación frente al servidor de actualizaciones.

Este código está muy asociado a entornos gestionados con WSUS y Administrador de configuración (ConfigMgr/SCCM), tanto en versiones actuales como heredadas (System Center 2012 / 2012 R2). También puede aparecer al instalar herramientas como RSAT en Windows 11 cuando el cliente está forzado a usar un WSUS corporativo. Vamos a desgranar en detalle qué significa este error, cómo se relaciona con los distintos componentes implicados (WUA, WSUS, IIS, proxy, certificados, directivas de grupo…) y qué pasos concretos puedes seguir para dejar de pelearte con él.

Qué significa el error 0x80244017 en Windows 11 Enterprise

El código 0x80244017 suele mapearse a un estado HTTP 401, lo que básicamente indica que el recurso solicitado requiere autenticación de usuario o que ésta es incorrecta. En el contexto de WSUS y Windows Update, esto se traduce en que el agente de Windows Update (WUA) no puede comunicarse correctamente con el servidor de actualizaciones, normalmente el WSUS configurado por la organización.

En escenarios reales, este error aparece cuando los clientes intentan hacer un análisis de actualizaciones contra el WSUS, cuando SCCM fuerza un ciclo de análisis o cuando se intenta instalar RSAT u otras características opcionales en un equipo que está configurado para usar un servidor WSUS. En la práctica suele ir de la mano de otros códigos de la familia 0x80244xxx o 0x80072eee relacionados con problemas de conectividad, proxy, autenticación o configuración errónea de WSUS.

En los registros típicos verás algo como que el análisis falla con 0x80244017 y, en paralelo, IIS del servidor WSUS devolverá códigos HTTP 401 o 403. El síntoma típico en SCCM es que los grupos de actualización muestran todas las máquinas con estado de cumplimiento desconocido y, al revisar las implementaciones desde “Monitors > Implementaciones”, todas aparecen fallidas con ese mismo código.

Componentes implicados: WUA, WSUS, SCCM y el proceso de análisis

Para entender por qué aparece el error 0x80244017 en Windows 11 Enterprise conviene tener claro qué ocurre tras bambalinas cuando un cliente comprueba si tiene actualizaciones pendientes. Aunque parezca un simple “Buscar actualizaciones”, por debajo intervienen varios componentes: el cliente de ConfigMgr/SCCM, los servicios de ubicación, el punto de administración (MP), el punto de actualización de software (SUP/WSUS) y el propio agente de Windows Update (WUA).

El flujo típico arranca cuando el cliente de ConfigMgr necesita hacer un análisis de actualizaciones, ya sea por una programación, porque se ha modificado una implementación o porque se ha forzado el ciclo desde la consola o desde el panel del cliente. El componente ScanAgent genera una solicitud de examen basándose en la política de actualizaciones recibida y queda reflejado en ScanAgent.log, donde verás referencias a la política, al UpdateSourceID y a la versión de contenido asociada.

A partir de ahí, el cliente necesita saber a qué servidor WSUS debe hablar. Para ello, Location Services construye una petición de ubicación de WSUS con datos como el ContentID, la versión, el sitio asignado, el sitio de AD, el dominio y la dirección IP/subred del cliente. Esta petición se envía al punto de administración (MP) y queda registrada en LocationServices.log y en CcmMessaging.log.

El punto de administración recibe la petición, la procesa y llama al procedimiento almacenado MP_GetWSUSServerLocations en la base de datos del sitio. En el log MP_Location.log puedes ver cómo construye la respuesta, que incluye una o varias URL de WSUS (por ejemplo, un WSUS por HTTP y otro por HTTPS) con su versión de contenido.

Una vez que el cliente recibe la respuesta, ScanAgent la pasa a WUAHandler, que es el componente encargado de configurar el agente de Windows Update para que use el servidor WSUS indicado. Aquí entra en juego la actualización de la Directiva de Grupo Local que establece las claves de registro WUServer, WUStatusServer y UseWUServer. Si todo va bien, el registro WUAHandler.log mostrará que se ha añadido un nuevo origen de actualización WSUS, que se ha forzado una actualización de directiva y que la configuración se ha aplicado correctamente.

El papel de Windows Update Agent y los errores más habituales

Una vez configurado el origen de actualizaciones, el agente de Windows Update (WUA) inicia un análisis contra el WSUS o contra Microsoft Update, según corresponda. El cliente CcmExec le pide un análisis mediante las APIs COM de Windows Update, y esto queda reflejado en WindowsUpdate.log como una solicitud COMAPI con el ClientId = CcmExec.

En el log de Windows Update verás algo similar a que el agente inicia un análisis, especifica los criterios (por ejemplo, actualizaciones de tipo Software y Driver), se indica que el servicio gestionado es el WSUS con su URL de ClientWebService y se listan las actualizaciones y categorías encontradas. Si todo funciona, al final se registrará que se han encontrado X actualizaciones y el análisis habrá concluido con éxito.

Sin embargo, cuando hay problemas, el análisis puede fallar por múltiples motivos: componentes dañados, claves de registro corruptas, problemas de proxy, timeouts HTTP, firewall, puertos bloqueados, conflictos de directiva o certificados mal configurados. El error 0x80244017 se enclava especialmente en la parte de errores de autenticación, pero suele ir acompañado o precedido de otros fallos de conectividad.

Además de 0x80244017, son frecuentes códigos como 0x80072ee2, 0x8024401C, 0x80244023, 0x80244018 o 0x80244022, que se corresponden con tiempos de espera, problemas de proxy, imposibilidad de resolver el servidor o estados HTTP 403. Revisar cuidadosa y sistemáticamente WUAHandler.log y WindowsUpdate.log es clave para no ir a ciegas.

Errores por componentes de Windows Update dañados o ausentes

Aunque el error 0x80244017 suele estar relacionado con la autenticación, conviene no perder de vista que muchos fallos de análisis provienen de componentes dañados del propio Windows Update. Otros códigos típicos de este bloque son 0x80245003, 0x80070514, 0x8DDD0018, 0x80246008, 0x80200013, 0x80004015, 0x800A0046, 0x800A01AD, 0x80070424, 0x800B0100 o 0x80248011.

En todos estos casos, detrás suele haber archivos del sistema faltantes o corruptos, problemas con el registro de componentes, claves de registro inconsistentes o almacenes de datos de Windows Update dañados. Un punto de partida muy razonable es ejecutar el solucionador de problemas de Windows Update nativo, que puede corregir una buena parte de estos problemas sin tocar nada a mano.

También es importante asegurarse de que el equipo utiliza la versión más reciente del agente de Windows Update, ya que versiones antiguas han tenido bugs conocidos, sobre todo en combinaciones específicas de sistema operativo y cliente ConfigMgr.

Si tras pasar el solucionador de problemas el error persiste, suele recomendarse reinicializar el almacén de datos de Windows Update en el cliente. Esto se hace deteniendo el servicio de Windows Update (net stop wuauserv), renombrando la carpeta C:\Windows\SoftwareDistribution (por ejemplo, a SoftwareDistribution.old) y volviendo a arrancar el servicio (net start wuauserv). Después conviene forzar un nuevo ciclo de análisis para que el cliente reconstruya su catálogo.

Problemas de proxy y errores de autenticación (401/403)

Una de las fuentes más recurrentes del error 0x80244017 en Windows 11 Enterprise son las configuraciones de proxy y autenticación, tanto a nivel de cliente como en los dispositivos intermedios de red. El agente de Windows Update usa WinHTTP para salir a por actualizaciones, lo que significa que el proxy configurado en Internet Explorer (WinINET) no siempre coincide con el que ve Windows Update.

Entre los códigos relacionados con proxy están 0x80244021 (HTTP 502 – bad gateway), 0x8024401B (HTTP 407 – autenticación de proxy requerida), 0x80240030 (lista de proxy con formato no válido) o 0x8024402C (no se puede resolver el nombre del proxy o del servidor de destino). En todos estos casos el análisis puede fallar antes incluso de llegar a un tema de credenciales.

Para comprobar la configuración de proxy que realmente está usando el agente de Windows Update en sistemas modernos se utiliza el comando netsh winhttp show proxy. Si la organización ya tiene el proxy bien definido en el navegador, se puede importar la configuración con netsh winhttp import proxy source=ie, de forma que WinHTTP herede exactamente los mismos ajustes.

Cuando el error se manifiesta como 0x80244017 (HTTP 401) o 0x80244018 (HTTP 403), además del proxy hay que revisar los registros de IIS en el servidor WSUS. Si IIS registra efectivamente respuestas 401/403 para las peticiones del cliente, el problema suele estar en las reglas de autenticación o en dispositivos intermedios que interceptan el tráfico (proxies autenticados, balanceadores, firewalls con inspección profunda, etc.).

En un entorno típico, WSUS no debería requerir autenticación adicional para las URLs críticas como ClientWebService o SimpleAuthWebService, y el acceso debería gestionarse principalmente por red (firewall, subred, VPN…). Cualquier capa extra de autenticación web puede desencadenar el famoso 401 si el cliente no sabe cómo presentar credenciales.

Conectividad con WSUS: puertos, IIS y pruebas básicas

Dejando de lado el proxy, otro bloque importante de problemas está en la conectividad básica entre el cliente y el servidor WSUS/SUP. Durante el análisis, el agente de Windows Update debe poder conectarse a varias rutas del servidor WSUS: la ruta de Selfupdate, el ClientWebService y el SimpleAuthWebService, como mínimo.

Para verificar que el cliente apunta al servidor correcto, lo más fiable es revisar la clave del registro HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, donde se guarda la URL de WSUS que ha establecido el cliente, o bien leerla desde WindowsUpdate.log, donde se indica el WSUS server y el WSUS status server usados.

Una vez identificada la URL, conviene probar manualmente el acceso desde el cliente, por ejemplo abriendo en un navegador o con herramientas de línea de comandos la ruta http://SERVIDORWSUS:PUERTO/Selfupdate/wuident.cab. Si devuelve el fichero CAB sin problemas, la parte básica de conectividad funciona. Posteriormente, hay que probar rutas como http://SERVIDORWSUS:PUERTO/ClientWebService/wusserverversion.xml y http://SERVIDORWSUS:PUERTO/SimpleAuthWebService/SimpleAuth.asmx para confirmar que los directorios virtuales de WSUS responden.

Si cualquiera de estas URLs falla, es posible que haya problemas de resolución de nombres, puertos cerrados en el firewall, reglas de red intermedias que filtren tráfico o errores en la configuración del propio IIS de WSUS. Los puertos habituales para WSUS son 80 y 443 (cuando se usa el sitio web predeterminado) o 8530 y 8531 (cuando se configura un sitio específico). El puerto usado en WSUS debe coincidir con el configurado en el rol de punto de actualización de software (SUP) en la consola de ConfigMgr.

Para comprobar de forma rápida la accesibilidad de puertos desde el cliente sirve el clásico comando telnet SERVIDORWSUS PUERTO. Si telnet no puede abrir conexión, lo normal es que alguna regla de firewall o dispositivo de red esté bloqueando ese tráfico. Hacer la misma prueba desde otra máquina en la misma subred puede ayudar a aislar si se trata de un problema de ruta intermedia o de configuración en el propio cliente.

SSL, certificados y el temido error 0x80072F0C

En muchos entornos empresariales se configura WSUS para trabajar sobre HTTPS y SSL, especialmente cuando se quiere securizar la comunicación con el punto de actualización de software. Aquí entran en juego problemas adicionales de certificados que pueden desembocar en errores como 0x80072F0C, cuyo significado es “se requiere un certificado para completar la autenticación de cliente”.

Este error aparece cuando el servidor WSUS o alguno de sus directorios virtuales han sido configurados en IIS para exigir certificados de cliente. Para que WSUS funcione correctamente con SSL, los directorios de WSUS deben estar configurados para usar SSL pero, en lo relativo a certificados de cliente, deben estar configurados en “Ignorar certificados de cliente”, no en “Aceptar” ni “Requerir”. Si se fuerza la autenticación por certificado, el agente de Windows Update no sabe qué presentar y el análisis fracasa.

Además de la parte de IIS, cuando el sitio de ConfigMgr está en modo HTTPS o mixto hay que revisar en las propiedades del punto de actualización de software que esté marcada la casilla de requerir comunicación SSL con WSUS cuando así se haya diseñado. Del mismo modo, en la consola de WSUS hay que indicar que la sincronización de información de actualización use SSL.

Por último, es fundamental que el certificado de autenticación de servidor esté correctamente instalado en el sitio de administración de WSUS en IIS. En la pestaña de enlaces del sitio, la entrada HTTPS debe estar asociada al certificado adecuado, emitido por una CA de confianza para los clientes. Cualquier problema aquí puede generar errores de confianza de certificado y bloquear la comunicación.

Conflictos de Directiva de Grupo y sobreescritura de la configuración WSUS

En entornos de dominio es bastante habitual que la organización haya definido GPOs para gestionar Windows Update. El problema surge cuando estas directivas de dominio contradicen o pisan la configuración local que establece ConfigMgr para que el cliente apunte al SUP/WSUS correcto, tanto en nombre como en puerto.

La característica de actualizaciones de software de ConfigMgr configura por sí misma una política de grupo local que indica al agente de Windows Update qué servidor WSUS debe usar y en qué puerto. Si luego se aplica una GPO de dominio que establece otro servidor WSUS distinto (o el mismo pero con formato de nombre o puerto diferente), el cliente se quedará apuntando al valor de la GPO de dominio, que tiene prioridad.

Cuando esto ocurre, en el registro WUAHandler.log suele aparecer un mensaje claro indicando que los ajustes de Directiva de Grupo han sido sobrescritos por una autoridad superior (controlador de dominio), señalando el servidor y el estado de la política. A partir de ahí, el cliente intentará hablar con el servidor definido en la GPO, que puede no coincidir con el SUP de ConfigMgr y dará lugar a fallos de análisis, estados desconocidos y códigos como 0x80244017.

La solución pasa por alinear el servidor WSUS utilizado para la instalación del cliente y para las actualizaciones con el mismo host y puerto, y garantizar que la GPO de dominio especifica exactamente la misma URL (por ejemplo, http://server1.contoso.com:80 si se usa el sitio web predeterminado). En muchas organizaciones se opta directamente por no definir políticas de WSUS en GPO cuando se usa SCCM como motor de actualizaciones, para evitar estos conflictos.

Clientes que no localizan el servidor WSUS y estados “desconocido”

Cuando los clientes no son capaces de obtener o interpretar correctamente la ubicación del servidor WSUS, el efecto en la consola de ConfigMgr es que el estado de cumplimiento de las actualizaciones se queda en “desconocido” para un porcentaje importante de dispositivos, en ocasiones para todos. En los grupos de actualización ves que las actualizaciones están desplegadas, pero el recuento de activos no avanza.

En este escenario es clave revisar primero los logs de cliente como PolicyAgent.log, para confirmar que el cliente está recibiendo directivas de configuración, y CcmMessaging.log, para descartar errores de comunicación graves con el punto de administración. Si el punto de administración responde pero la ubicación WSUS enviada es vacía o inconsistente, puede haber un desajuste en la versión de contenido o en las tablas relacionadas con WSUS.

En el lado del servidor, conviene comprobar desde la consola, en Monitoring > Estado de sincronización del punto de actualización de software, que las sincronizaciones de WSUS se están completando correctamente y que las versiones de contenido de WSUS y ConfigMgr están alineadas. En casos avanzados, se revisan tablas como CI_UpdateSources, WSUSServerLocations y Update_SyncStatus para confirmar que el ID de origen de actualización y la versión de contenido coinciden.

Si además observas que el archivo WUAHandler.log no existe o no se crea ni siquiera al forzar un ciclo de análisis, es indicativo de que la política de examen de actualizaciones no está llegando al cliente o que éste no consigue localizar el servidor WSUS. Hasta que no se resuelvan esos problemas de ubicación, el cliente no llegará ni a intentar el análisis y, por tanto, no habrá mensajes de estado ni cambios de cumplimiento.

Error 0x80244017 al instalar RSAT en Windows 11 Enterprise

Un caso muy concreto y bastante habitual de error 0x80244017 en Windows 11 Enterprise se da al intentar instalar RSAT (Remote Server Administration Tools) u otras características opcionales desde “Características opcionales” de Windows. El asistente muestra que la instalación de RSAT no se ha podido completar y, en el historial, aparece el código 0x80244017 sin apenas explicación adicional.

Este problema se produce a menudo cuando el equipo está configurado mediante directiva para usar un servidor WSUS corporativo y, por algún motivo, ese WSUS no puede servir adecuadamente las características bajo demanda (Features on Demand) o hay un problema de autenticación/comunicación con él. En esencia, RSAT intenta descargarse como contenido opcional desde la ruta configurada, falla la conexión con WSUS y Windows reporta el error.

La solución más efectiva en este escenario consiste en deshabilitar temporalmente el uso de WSUS en el cliente y volver a forzar la instalación de RSAT desde Windows Update directo. Esto se realiza modificando una clave de registro muy concreta y reiniciando el servicio de Windows Update, de forma que durante ese tiempo el equipo consulte directamente a los servidores de Microsoft en lugar de al WSUS corporativo.

Para ello, se abre el Editor del Registro (regedit.exe) y se navega hasta la clave HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU. Allí se localiza el valor UseWUServer. Si está establecido a 1, significa que el equipo está obligado a usar un WSUS. Cambiando ese valor a 0, el cliente deja de utilizar WSUS y vuelve a consultar al servicio público de Windows Update, lo que suele permitir que RSAT y otras características opcionales se instalen sin trabas.

Cómo desactivar temporalmente WSUS en el cliente para instalar RSAT

Antes de tocar el registro, es recomendable hacer una copia de seguridad de la rama afectada, de forma que se pueda restaurar rápidamente si algo no sale como se esperaba. Una vez abierta la herramienta regedit, se exporta la clave de WindowsUpdate o, como mínimo, la subclave AU a un archivo .reg.

Con el respaldo hecho, se localiza el valor UseWUServer en la ruta HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU y se edita su valor. Si está a 1 (activar WSUS), se cambia a 0. Es importante que, una vez modificada la clave, se cierre el editor de registro antes de reiniciar el servicio, para evitar conflictos o bloqueos sobre la clave.

El siguiente paso es reiniciar el servicio de Windows Update desde la consola de servicios (services.msc) o con comandos. En la interfaz gráfica, basta localizar el servicio “Windows Update”, hacer clic derecho y pulsar en Reiniciar. Con ello, el servicio lee la nueva configuración y deja de usar el WSUS forzado por la clave UseWUServer.

Tras esto, se accede de nuevo a Configuración > Aplicaciones > Características opcionales, se pulsa en “Ver características” y se busca “RSAT: Herramientas de administración de acceso remoto” u otros módulos RSAT necesarios. Al intentar instalar de nuevo, la descarga se hará directamente desde los servidores de Microsoft y, en la gran mayoría de los casos, el error 0x80244017 desaparece y la instalación concluye correctamente.

Cuando la instalación haya terminado y se confirme que RSAT funciona, es aconsejable restaurar el uso de WSUS si la política corporativa así lo exige, volviendo a establecer UseWUServer en 1 o dejando que la GPO de dominio vuelva a aplicar sus ajustes habituales tras una actualización de directiva (gpupdate /force o reinicio del equipo).

Diagnóstico por registros: WUAHandler, WindowsUpdate y otros logs clave

Más allá de RSAT, cuando el error 0x80244017 afecta a despliegues masivos de actualizaciones con ConfigMgr, la única forma seria de atacarlo es apoyarse en los registros. Cada componente implicado deja trazas muy valiosas que permiten identificar si el problema está en la política, en la resolución de WSUS, en la conectividad, en la autenticación o en la propia instalación de la actualización.

En el lado del cliente, los logs más importantes son ScanAgent.log (gestión de solicitudes de análisis), LocationServices.log (resolución de ubicación WSUS), WUAHandler.log (interfaz entre ConfigMgr y el agente de Windows Update), WindowsUpdate.log (detalles del agente WUA), UpdatesStore.log (almacén local de resultados de análisis), StateMessage.log (mensajes de estado generados) y CcmMessaging.log (comunicación con el punto de administración).

En el lado del servidor, para el punto de actualización de software y WSUS, hay que revisar SUPSetup.log (instalación del SUP), WCM.log (configuración de WSUS), WSUSCtrl.log (estado de WSUS y conectividad), WSyncMgr.log (sincronización de actualizaciones) y los registros de IIS, donde se reflejan los accesos de los clientes a las rutas de WSUS, incluyendo códigos 401, 403, 404 o 500.

El patrón habitual con el error 0x80244017 es que el análisis se inicia correctamente, se intenta contactar con el WSUS, se registra un fallo de autenticación o un bloqueo HTTP en IIS y, finalmente, WUAHandler y WindowsUpdate informan del código de error. Localizar el punto exacto en que la comunicación se corta permite ajustar reglas de IIS, del proxy o del firewall con mucha más precisión que probando a ciegas.

En resumen, si se hace un repaso ordenado a la configuración de WSUS, las directivas de grupo, la conectividad de red, los parámetros de proxy, la configuración de SSL y los posibles daños en componentes del agente de Windows Update, el error 0x80244017 en Windows 11 Enterprise y otros sistemas gestionados suele tener solución, tanto cuando bloquea el despliegue de actualizaciones desde SCCM como cuando impide la instalación de RSAT u otras características opcionales.