Solución definitiva al error 0x80244017 en Windows 11 Enterprise

Cuando trabajas con Windows 11 Enterprise y despliegues masivos de actualizaciones, un solo error en Windows Update puede tumbarte medio entorno en cuestión de horas. Eso es justo lo que ocurre con el temido código 0x80244017, que suele traducirse en “Same as HTTP status 401 – the requested resource requires user authentication”. En cristiano: el cliente no está autorizado a hablar con el servidor de actualizaciones (WSUS o punto de actualización de software en ConfigMgr/SCCM).

Si gestionas un entorno empresarial con WSUS o Microsoft Configuration Manager y ves estados de cumplimiento en “Desconocido”, implementaciones que marcan fallo con 0x80244017 o equipos nuevos que no descargan nada del servidor, este artículo es para ti. Vamos a ver, con todo lujo de detalles, qué significa realmente el error, cómo se relaciona con otros códigos habituales de Windows Update, qué revisar en WSUS/SCCM (puertos, SSL, GPO, proxy, certificados…) y cómo arreglar también los problemas de actualización más típicos de Windows 11 24H2 cuando el fallo ya no es de infraestructura, sino del propio sistema operativo.

Qué significa el error 0x80244017 en Windows 11 Enterprise

El código 0x80244017 se corresponde con un error de protocolo de Windows Update que, en la práctica, suele llegar al cliente como HTTP 401: se requiere autenticación de usuario. Es decir, el servidor de actualizaciones (WSUS o el punto de actualización de software) está respondiendo, pero el cliente no tiene permiso para acceder al recurso o algo en el camino (proxy, firewall, balanceador) exige una autenticación que el agente de Windows Update no puede proporcionar.

En entornos empresariales, este fallo aparece sobre todo al escanear actualizaciones de software con SCCM/ConfigMgr: en el informe ves que el ADR se ha desplegado a la colección correcta, las actualizaciones aparecen dentro del grupo de actualizaciones, pero en “Activos totales” todos los equipos figuran como “Desconocido”. Si vas a Monitoring → Deployments y revisas la implementación, todas las máquinas muestran fallo tras el resumen de estado, con el código 0x80244017.

En servidores (por ejemplo, EC2 en AWS) que usan un WSUS corporativo, puedes ver el mismo problema al lanzar un install-windowsupdate desde PowerShell: el módulo PSWindowsUpdate indica que no puede continuar porque el WSUS devuelve un error equivalente a HTTP 401 y el script muestra claramente la referencia a 0x80244017.

El punto común en todos los casos es el mismo: el agente WU no puede autenticarse correctamente frente al origen de actualizaciones. Esto no tiene nada que ver con el usuario conectado en la sesión interactiva, sino con cómo está configurado WSUS, el punto de actualización de software, el proxy y las directivas que empujan la URL de actualización.

Errores de examen de actualizaciones en SCCM y WSUS: visión global

Microsoft documenta desde hace años que la mayoría de errores de “scan” o examen de actualizaciones en ConfigMgr se deben a problemas de comunicación o de firewall entre el cliente y el servidor WSUS/punto de actualización de software. Aunque el foco aquí sea 0x80244017, conviene tener claro el mapa general de errores frecuentes, porque muchas veces se combinan entre sí.

Para diagnosticar correctamente, es clave revisar siempre dos registros en el cliente: WUAHandler.log (registro de SCCM que simplemente refleja lo que dice el agente de Windows Update) y WindowsUpdate.log (registro propio de WU, que contiene el detalle fino del error). Lo que veas en WUAHandler será siempre un reflejo del código que ha devuelto el agente WU; la información útil casi siempre está en WindowsUpdate.log.

En escenarios con problemas de infraestructura, aparecen a menudo códigos como 0x80072ee2, 0x8024401C, 0x80244023, 0x80244018, 0x80244021, 0x8024401B, 0x8024402C, que se traducen en errores de tiempo de espera, non-authoritative, HTTP 403, HTTP 407 o problemas de resolución del servidor. Todos ellos apuntan, de una forma u otra, a conectividad de red, puertos, proxy o certificados.

Además, hay una batería de códigos clásicos (0x80245003, 0x80070514, 0x8DDD0018, 0x80246008, 0x80200013, 0x80004015, 0x800A0046, 0x800A01AD, 0x80070424, 0x800B0100, 0x80248011) que suelen indicar componentes de Windows Update dañados o ausentes en el cliente, lo que se arregla muchas veces ejecutando el solucionador de problemas de Windows Update o reseteando la carpeta SoftwareDistribution y el almacén de catroot2.

Causas típicas del 0x80244017 (HTTP 401) en entornos empresariales

Aunque pueda sonar genérico, el 0x80244017 normalmente se debe a algún tipo de bloqueo de autenticación entre el cliente y WSUS/SUP. Los casos más habituales son:

• Configuración de proxy WinHTTP o WinINET incorrecta, que obliga a usar un proxy con credenciales de usuario cuando el agente WU espera salida directa o un proxy sin autenticación.
• Firewall o dispositivo intermedio (proxy inverso, balanceador, appliance de filtrado web tipo Lightspeed Rocket, etc.) que inspecciona las peticiones y devuelve un 401/403 si no se cumple alguna condición.
• Configuración SSL errónea en WSUS (directorios virtuales pidiendo certificado de cliente, puerto incorrecto, certificado de servidor mal asignado o no confiado).
• Desajuste entre GPO y configuración de SCCM: una directiva de dominio sobrescribe la configuración local que genera ConfigMgr para señalar el punto de actualización de software.
• Problemas puntuales de sincronización o versión de contenido entre WSUS y el punto de actualización de software, que pueden provocar respuestas inconsistentes a algunos clientes.

En entornos reales se han visto situaciones curiosas: clientes con mismo GPO, mismo firewall y IP vecinas (192.168.x.101 y 192.168.x.102) donde uno actualiza sin problemas y el otro devuelve 0x80244017. En esos casos, muchas veces el problema está en el propio equipo afectado (almacén WU dañado, certificados, configuración local alterada) o en algún dispositivo intermedio que trata a uno de los equipos de forma ligeramente distinta (reglas por IP, VLAN, etc.).

Cómo diagnosticar y solucionar el 0x80244017 paso a paso

La clave para no volverse loco es seguir una metodología de diagnóstico ordenada. A grandes rasgos, estos son los pasos que deberías cubrir en Windows 11 Enterprise cuando te enfrentas al 0x80244017 en un entorno con WSUS o SCCM.

1. Verifica la URL y el puerto de WSUS/SUP en el registro

En el cliente, revisa la clave:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Ahí deberías ver la URL que está usando el agente para hablar con WSUS, incluyendo el puerto (80, 443, 8530, 8531). Asegúrate de que coincide con la configuración real del punto de actualización de software y del sitio de WSUS en IIS. Si estás usando SSL, lo normal es algo del estilo https://servidor:8531.

2. Comprueba la conectividad directa a los directorios virtuales clave

Desde el cliente afectado, intenta acceder en un navegador o con herramientas como curl a estas rutas de WSUS:

• SelfUpdate: por ejemplo, http://SUPSERVER.CONTOSO.COM:8530/Selfupdate/wuident.cab
• ClientWebService: http://SUPSERVER.CONTOSO.COM:8530/ClientWebService/wusserverversion.xml
• SimpleAuthWebService: http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx

Si alguna de estas llamadas devuelve 401 o 403 directamente cuando las haces desde el cliente afectado, ya tienes pista: algo en el camino (proxy, firewall, configuración de IIS) está pidiendo autenticación o denegando la petición. Si desde otros clientes funciona y desde este no, el problema es local. Si desde todos falla, revisa WSUS/IIS y la infraestructura de red.

3. Revisa la configuración de puertos y firewall en WSUS y SCCM

WSUS puede trabajar en los puertos 80, 443, 8530 o 8531. En IIS (tanto en IIS 6 como en 7/8/10), comprueba en las propiedades del sitio de WSUS (o del sitio web predeterminado si WSUS usa ese) cuáles son los puertos HTTP/HTTPS asignados. Luego ve a la consola de Configuration Manager, a Administration → Site Configuration → Servers and Site System Roles, selecciona el sistema de sitio que aloja el punto de actualización de software y revisa en sus propiedades qué puertos tiene configurados.

Si los puertos no coinciden entre lo que WSUS realmente usa en IIS y lo que SCCM cree que tiene, la sincronización puede fallar o el cliente puede estar intentando contactar por un puerto que no está abierto. Desde el cliente, usa telnet SUPSERVER.CONTOSO.COM <puerto> para comprobar que el puerto está accesible. Si telnet no consigue abrir conexión, probablemente tengas un firewall bloqueando el tráfico.

4. Valida la configuración de SSL y certificados (incluido el 0x80072f0c)

Cuando WSUS está configurado para trabajar bajo SSL, es imprescindible que los directorios virtuales de WSUS estén ajustados correctamente: deben usar SSL, pero no deben requerir certificado de cliente. Si IIS está configurado para “Aceptar” o “Requerir” certificados de cliente, aparecerá el error 0x80072f0c (se requiere un certificado de cliente para completar la autenticación), que a menudo se mezcla con otros códigos de escaneo.

En el servidor WSUS, abre el Administrador de IIS, localiza el sitio de WSUS y revisa los enlaces HTTPS. Asegúrate de que está asignado un certificado de autenticación de servidor válido y de confianza para los clientes. Luego, en la consola WSUS, en “Opciones → Origen de actualización y servidor proxy”, comprueba que la casilla de “Usar SSL” está marcada si el entorno lo requiere.

También debes verificar que, en la consola de Configuration Manager, el punto de actualización de software está marcado para requerir SSL cuando el sitio trabaja en modo HTTPS o mixto, y que el certificado utilizado cumple los requisitos (nombre, cadena de confianza, fechas, etc.). Cualquier desajuste aquí puede terminar devolviendo errores de autenticación, incluyendo el 0x80244017.

5. Configuración de proxy WinHTTP y WinINET

El agente de Windows Update utiliza WinHTTP para salir a Internet o para hablar con WSUS. La configuración de proxy de Internet Explorer/Edge (WinINET) no siempre coincide con la de WinHTTP, y en muchos casos es necesario importar la configuración si el proxy se define solo a nivel de navegador.

En versiones antiguas de Windows se usaba proxycfg.exe, mientras que en Windows 10/11 debes recurrir a netsh winhttp:

• Revisar proxy actual: netsh winhttp show proxy
• Importar configuración desde IE: netsh winhttp import proxy source=ie

Errores como 0x80244021 (HTTP 502), 0x8024401B (HTTP 407), 0x80240030 o 0x8024402C suelen indicar problemas directos con el proxy: autenticación requerida, formato inválido de la lista de proxy o nombres que no se resuelven. Si el proxy corporativo requiere autenticación de usuario, es fácil acabar provocando el 0x80244017, porque el agente de Windows Update no es capaz de responder al reto de autenticación interactiva que espera el proxy.

6. Comprueba que ninguna GPO pisa la configuración de WSUS de SCCM

Cuando usas Configuration Manager para gestionar actualizaciones, el propio cliente de SCCM configura una política local para apuntar al punto de actualización de software correcto (nombre FQDN y puerto). Si, además, tienes una GPO de dominio que configura directivas de Windows Update (por ejemplo, para un WSUS independiente o heredado), esa política de dominio sustituye a la configuración local.

En ese caso, en WUAHandler.log verás entradas del estilo: «Group policy settings were overwritten by a higher authority (Domain Controller)». El resultado es que el cliente intenta escanear contra un servidor/puerto que no coincide con lo que espera ConfigMgr, lo que puede generar errores de autenticación o simplemente fallos de conexión.

La solución pasa por unificar el servidor WSUS que se usa para instalaciones de cliente y para actualizaciones de software, y asegurarte de que, si aplicas una GPO de Windows Update, el valor del servidor y puerto coincide exactamente con el que SCCM está configurando. Si usas el sitio web predeterminado, la URL típica sería algo tipo http://server1.contoso.com:80.

7. Valida que los clientes encuentran la ubicación de WSUS

Cuando ConfigMgr entrega políticas al cliente, le indica qué origen de actualizaciones (WSUS) debe usar. Si por cualquier motivo el punto de administración devuelve una ubicación vacía o incoherente, el cliente no sabrá a dónde ir a escanear y aparecerán estados de cumplimiento como “Desconocido”.

Para diagnosticarlo:

• Revisa PolicyAgent.log para asegurarte de que el cliente recibe correctamente las políticas.
• Comprueba CcmMessaging.log para descartar errores de comunicación con el punto de administración.
• En el servidor, desde la base de datos de ConfigMgr, revisa las tablas CI_UpdateSources, WSUSServerLocations y Update_SyncStatus para verificar que el ID de origen de actualización y la versión de contenido coinciden.
• Activa el registro detallado y de depuración en el cliente y en el punto de administración si necesitas más información.

Si el punto de administración devuelve una ubicación vacía de WSUS, es posible que haya un desajuste de versión de contenido derivado de una sincronización con errores. En ese caso, toca revisar el estado de sincronización del punto de actualización de software en la consola de Monitoring, corregir los problemas de sincronización y, si es necesario, re-sincronizar WSUS.

8. Resetea componentes de Windows Update en el cliente problemático

Si solo tienes unos pocos clientes con 0x80244017 mientras el resto actualiza sin problemas, puede que el fallo esté en el propio agente WU de esos equipos. En ese caso, conviene hacer un reset completo de Windows Update en el cliente afectado:

1. Detén el servicio de Windows Update:
   net stop wuauserv
2. Cambia de nombre la carpeta SoftwareDistribution:
   ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
3. (Opcional) Renombra catroot2 si sospechas corrupción de catálogos:
   ren %systemroot%\system32\catroot2 catroot2.bak
4. Inicia de nuevo el servicio:
   net start wuauserv
5. Fuerza un nuevo ciclo de examen desde el cliente SCCM o con UsoClient /StartScan.

En muchos casos, esta limpieza de componentes combinada con una revisión de certificados y proxy es suficiente para que el 0x80244017 desaparezca en esos equipos rebeldes.

Otros códigos frecuentes de Windows Update y su relación con Windows 11

Más allá del 0x80244017, en despliegues de Windows 11 Enterprise y en entornos mixtos (Windows 10/11) es habitual encontrarse una batería bastante amplia de códigos de error. Conocer qué significan y cómo se mitigan te ahorra horas de soporte.

Por ejemplo, el código 0x80246017 (WU_E_DM_UNAUTHORIZED_LOCAL_USER) indica que la descarga falla porque el usuario local no tiene autorización suficiente para descargar el contenido. En la práctica, suele solucionarse asegurando que el usuario que lanza el proceso tiene permisos de administrador local y que no hay restricciones de UAC o políticas corporativas que bloqueen la descarga.

Otros errores muy comunes son los de tiempo de espera y conectividad (0x80072EFD, 0x80072EFE, 0x80D02002, 0x80072EE2), que suelen deberse a reglas de firewall o de proxy que bloquean las URL de descarga de Microsoft. En esos casos, además de revisar la red, conviene capturar tráfico (Network Monitor, Wireshark, etc.) para entender exactamente dónde se corta la conexión y asegurarse de que el dispositivo puede acceder a todos los puntos de conexión de Windows Update (windowsupdate.microsoft.com, *.update.microsoft.com, *.download.windowsupdate.com, etc.).

Tampoco faltan, por desgracia, los clásicos 0x80070005 (acceso denegado), 0x80070003 (ruta no encontrada), 0x80070020 (violación de uso compartido por antivirus o drivers de filtro), 0x80070570 (archivos corruptos) o 0x800F081F/0x800F0831/0x80073701/0x8007371B (daños en el almacén de componentes). En estos casos la receta pasa casi siempre por usar DISM /Online /Cleanup-Image /RestoreHealth y sfc /scannow, revisar CBS.log y, si es necesario, actuar sobre permisos, rutas o procesos que bloquean el acceso.

Para algunos errores concretos, como el 0x80072F8F (problemas de decodificación por TLS 1.2 mal configurado) o el 0x80244007 (renovación de cookies en WSUS), Microsoft ofrece KB específicos y guías de mitigación muy detalladas que conviene revisar y aplicar en entornos corporativos antes de escalar al soporte oficial.

Problemas específicos al actualizar a Windows 11 y 24H2

Desde el lanzamiento de Windows 11 y especialmente con la versión 24H2, las actualizaciones han venido acompañadas de una buena ración de dolores de cabeza para muchos usuarios y administradores. Aunque estos problemas no siempre están ligados al 0x80244017, sí afectan a la fiabilidad general del proceso de actualización y es habitual que se mezclen incidencias de infraestructura con fallos propios del sistema operativo.

Por un lado, Windows 11 ha recibido ya cuatro grandes actualizaciones de características (21H2, 22H2, 23H2 y 24H2), además de más de cuarenta actualizaciones acumulativas mensuales. Cada una trae mejoras (soporte para Wi-Fi 7, cambios en la barra de tareas, ajustes de consumo, etc.), pero también introduce, de vez en cuando, bugs bastante molestos.

En 24H2 se han reportado problemas como la desaparición del puntero del ratón en aplicaciones basadas en Chromium (Chrome, Edge), fallos graves en el Explorador de archivos tras instalar el parche KB5051987, bloqueos del sistema durante la instalación que acaban en pantallas azules o revertidos de actualización al 98-99 %, y códigos como 0x800f0993, 0x800F081F, 0x80070032 o 0xC004F211.

Microsoft incluso ha tenido que bloquear temporalmente la actualización a 24H2 en dispositivos que usan un controlador incompatible (sprotect.sys de SenseShield Technology), asignando un ID de retención (56318982) para evitar que esos equipos reciban la actualización hasta que se resuelva el conflicto con dicho driver, que suele formar parte de soluciones de seguridad o cifrado.

Fallas habituales tras las actualizaciones de Windows 11

A nivel de usuario final, los síntomas de estos problemas de actualización van mucho más allá de un simple código de error en Windows Update. Algunos de los fallos más comentados en 24H2 han sido bastante llamativos.

Uno de los más sonados es que en determinadas combinaciones de hardware y software, tras aplicar la actualización, el puntero del ratón desaparece en ventanas de navegadores basados en Chromium. El sistema sigue respondiendo, pero la experiencia de uso se vuelve un infierno, sobre todo si el usuario no se desenvuelve bien solo con el teclado.

Otro caso peculiar es la aparición de una gigantesca caché de actualización, con un fichero de más de 8,6 GB dentro de la estructura de Windows Update que no se elimina de forma automática como ocurría antes. Ni el liberador de espacio en disco ni comandos como sfc /scannow consiguen borrarlo, y en algunos equipos la única manera de recuperar ese espacio ha sido realizar una instalación limpia de Windows.

El parche KB5051987, por su parte, se ha ganado la fama de “romper el Explorador de archivos”: tras instalarlo, muchos usuarios reportan que el Explorador deja de abrirse o se cuelga constantemente, aunque el proceso explorer.exe siga activo en segundo plano. En otros casos, la instalación del parche ni siquiera llega a completarse; el sistema se detiene en algún punto del proceso, revierte los cambios y muestra un mensaje indicando que “algo no ha salido según lo previsto”.

A esto se suman incidencias de Bluetooh que deja de funcionar (auriculares, cámaras integradas en monitores, etc.), comandos como Ctrl+Alt+Supr o el Administrador de tareas que dejan de responder en determinados escenarios, juegos que fallan tras el parche (Fortnite, Assassin’s Creed y otros títulos antiguos), bucles de solicitud de reinicio interminables y el código de error 0x80070005 bloqueando instalaciones. Algunas funciones de seguridad como Smart App Control han llegado a bloquear sin motivo aparente aplicaciones legítimas e incluso componentes de WSL.

Herramientas y métodos para reparar Windows Update en Windows 11

Una vez que sabemos que no hay un problema de WSUS/SCCM o de red, y que el fallo reside en el propio Windows 11, conviene echar mano de las herramientas de reparación del propio sistema antes de plantearse medidas drásticas como la reinstalación completa.

Solucionador de problemas de Windows Update

Windows 11 incluye un asistente específico para detectar y corregir errores típicos de actualización. Puedes ejecutarlo desde Inicio → Configuración → Sistema → Solucionar problemas → Otros solucionadores de problemas y, en la sección “Más frecuente”, lanzar “Windows Update → Ejecutar”.

Este asistente revisa automáticamente el estado de los servicios implicados, la integridad básica de los archivos, las rutas de descarga y la configuración de WU. Una vez termine, conviene reiniciar el equipo y probar de nuevo la instalación o el escaneo de actualizaciones.

Desinstalar actualizaciones problemáticas

Si tras instalar una actualización concreta (por ejemplo, KB5051987) el sistema comienza a dar problemas serios, lo más sensato es desinstalarla. Para ello:

1. Ve a Configuración → Actualización y seguridad → Windows Update.
2. Entra en el historial de actualizaciones y elige “Desinstalar actualizaciones”.
3. Localiza la actualización conflictiva por su identificador (KB5051987, KBxxxxxxx) y elimínala.
4. Reinicia el ordenador y comprueba si el sistema vuelve a comportarse de forma normal.

En entornos gestionados, es buena idea bloquear temporalmente dicha actualización en WSUS/SCCM hasta que Microsoft publique un parche correctivo o documentación específica.

Restaurar el sistema a un punto anterior

Siempre que tengas Protección del sistema activada, Windows crea periódicamente puntos de restauración que permiten devolver el sistema a un estado anterior sin afectar a los datos del usuario. Para usar esta opción, basta con buscar “punto de restauración” en el menú Inicio, abrir “Crear punto de restauración”, pulsar en “Restaurar sistema” y seleccionar uno de los puntos disponibles (normalmente, el más reciente anterior al problema).

Tras confirmar y finalizar, el sistema se reiniciará y dejará el equipo como estaba en el momento de crear ese punto: controladores, actualizaciones y configuraciones de entonces, pero manteniendo documentos, fotos y resto de archivos de usuario.

Herramienta Reset de Windows Update

Cuando los problemas de Windows Update persisten, hay utilidades de terceros (como la Herramienta Reset de Windows Update) que automatizan el proceso de restaurar componentes, limpiar cachés, re-registrar DLLs y ajustar servicios. Esta herramienta, de código abierto, puede ejecutarse con permisos de administrador y permite seleccionar la opción de “Restaurar componentes de Windows Update”, que aplica de golpe una colección de correcciones conocidas.

Tras su ejecución, es recomendable reiniciar el sistema y volver a intentar el escaneo o instalación de actualizaciones. En muchos equipos problemáticos, esta herramienta ha sido suficiente para recuperar el funcionamiento normal de Windows Update.

Pausar actualizaciones automáticas cuando dan guerra

Si una actualización en concreto está causando estragos y aún no hay solución oficial, puede ser prudente pausar temporalmente las actualizaciones automáticas. Desde la configuración de Windows Update puedes elegir una pausa durante un periodo determinado, lo que te da margen para investigar, aplicar mitigaciones y decidir cuándo volver a habilitar los parches.

Antes de instalar una actualización grande o un parche que ha dado problemas, es útil comprobar su ID de KB en el Catálogo de Microsoft Update, leer los problemas conocidos documentados por Microsoft y revisar foros o webs especializadas para ver cómo se está comportando en otros entornos.

Por qué no aparece la actualización de Windows 11 o 24H2

En ocasiones, el problema no es que la actualización falle, sino que ni siquiera aparece disponible en Windows Update. Esto puede deberse tanto a requisitos de hardware como a una configuración del propio Windows Update.

Para empezar, hay que recordar que Windows 11 exige cumplir unos requisitos mínimos: procesador compatible, al menos 4 GB de RAM, 64 GB de almacenamiento, tarjeta gráfica compatible con DirectX 12 y controlador WDDM 2.0, y, sobre todo, TPM 2.0 habilitado. Muchos equipos tienen el chip TPM pero lo traen desactivado en la BIOS, así que conviene entrar en la configuración de firmware y activarlo si es compatible.

Por otro lado, es posible que el propio usuario (o un administrador) haya pausado las actualizaciones en el pasado. En ese caso, en Configuración → Windows Update verás que la opción “Pausar actualizaciones” está activa. Solo con desactivarla y pulsar “Buscar actualizaciones” puede aparecer de nuevo la oferta de actualización pendiente.

También puede ocurrir que el sistema tenga archivos temporales corruptos que impiden que Windows Update funcione correctamente. Reiniciar el equipo a menudo limpia buena parte de esa basura, pero si el problema persiste, conviene borrar manualmente archivos temporales, vaciar cachés y revisar el estado de los servicios implicados.

En entornos empresariales, no olvides que la aparición o no de una actualización depende muchas veces de políticas de WSUS o SCCM: si el administrador no ha aprobado todavía una build concreta (por ejemplo 24H2) para el anillo al que pertenece ese equipo, Windows Update nunca la va a mostrar aunque el hardware sea perfectamente compatible.

En definitiva, el código 0x80244017 y el resto de errores de Windows Update no son más que síntomas de una cadena de dependencias que tiene que encajar: red, proxy, certificados, WSUS/SUP, GPO, servicios del sistema y, finalmente, la propia calidad de las actualizaciones de Windows 11. Si atacas cada eslabón con método, apoyándote en los registros adecuados (WUAHandler, WindowsUpdate.log, CcmMessaging, CBS.log) y en las herramientas de reparación que ofrece el sistema, es perfectamente posible devolver la estabilidad a los despliegues de Windows 11 Enterprise y minimizar el impacto de estos fallos en el día a día de tus usuarios.