Problema

Muchas organizaciones que ya usan SCCM con WSUS están empezando a adoptar Intune y su funcionalidad Windows Update for Business (WUfB). El escenario típico es:

  1. Los equipos están Hybrid‑joined a Azure AD y a AD on‑premise.
  2. SCCM entrega la configuración del cliente y una GPO que apunta al servidor WSUS interno.
  3. Se habilita co‑management y se transfiere la carga de trabajo de actualizaciones a Intune.
  4. Se mantiene dual scan para seguir recibiendo paquetes de terceros (Adobe, etc.) desde SCCM.

El dilema surge al decidir si eliminar la GPO de WSUS. Si se desactiva demasiado pronto, los equipos pueden intentar descargar actualizaciones directamente de Microsoft antes de que Intune les asigne un anillo, lo que genera instalaciones inesperadas o fallos de cumplimiento. Si se mantiene, existe la posibilidad de que SCCM siga enviando actualizaciones de Windows, creando conflicto con la política de Intune.

Causa

1. Dependencia implícita de la GPO

La GPO que define WindowsUpdate\WUServer y WindowsUpdate\WUStatusServer sigue siendo la única fuente de información para el cliente Windows Update mientras la política de Intune no se haya aplicado. En equipos recién desplegados, el agente Intune tarda varios minutos (a veces más) en registrarse y recibir la configuración de WUfB. Durante esa ventana, el cliente recurre al WSUS configurado por GPO.

2. Dual scan y prioridad de fuentes

Con dual scan habilitado, Windows Contacta primero al cloud service (Intune) y, si la respuesta es “no policy”, recurre al on‑premise WSUS. Si la GPO está presente, el cliente siempre tiene una segunda vía válida, lo que evita que quede “sin fuente”. Sin embargo, si la GPO se elimina antes de que Intune haya distribuido la política, el cliente no tiene ninguna ruta y puede caer en la configuración predeterminada de Microsoft Update, fuera de los anillos definidos.

3. Paquetes de terceros gestionados por SCCM

Los paquetes que no son de Windows (Adobe, Java, etc.) siguen llegando a través de SCCM. La eliminación de la GPO no afecta directamente a esos paquetes, pero sí altera la lógica de búsqueda de actualizaciones de Windows. Si el cliente intenta actualizar Windows directamente desde Microsoft y, simultáneamente, SCCM instala un paquete de terceros que depende de una versión específica de Windows, pueden aparecer errores de dependencia.

Solución

Paso 1 – Verificar que Intune ya entrega la política WUfB

Antes de tocar la GPO, confirma que la política está activa en al menos un 90 % de los equipos objetivo.

  1. En el portal de Intune, abre Devices → Configuration profiles y localiza el perfil que contiene la configuración de Windows Update.
  2. Usa Device configuration → Device status para revisar el porcentaje de dispositivos con “Compliant”.
  3. En un equipo de prueba, ejecuta:
powershell -Command "Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate' | Select-Object -Property WUServer, WUStatusServer"

Si los valores están vacíos, Intune ya está sobrescribiendo la GPO.

Paso 2 – Implementar una política de “fallback” temporal

Crea una GPO de solo lectura que mantenga los valores de WSUS pero con la opción Do not connect to any WSUS server (valor 0 en UseWUServer). Esto permite que el cliente siga “viendo” la GPO sin forzar una conexión real.

  1. En el editor de GPO, navega a Computer Configuration → Administrative Templates → Windows Components → Windows Update.
  2. Habilita Specify intranet Microsoft update service location y deja los campos vacíos.
  3. Habilita Do not connect to any Windows Update Internet locations.

Esta configuración mantiene la jerarquía de políticas y evita que el cliente recurra a Microsoft Update antes de que Intune lo autorice.

Paso 3 – Desactivar la GPO de WSUS de forma gradual

Utiliza Security Filtering o WMI Filtering para aplicar la GPO solo a los equipos que todavía no reportan la política de Intune.

  • WMI filter: SELECT * FROM Win32_OperatingSystem WHERE Version < "10.0.19044" (ejemplo para equipos con versiones antiguas que aún no han recibido la política).
  • Security filter: agrega solo el grupo de Computers → Intune‑Pending.

Una vez que el porcentaje de cumplimiento suba al 95 %, elimina el filtro y, finalmente, elimina la GPO.

Paso 4 – Asegurar la continuidad de los paquetes de terceros

Mantén la colección de SCCM que contiene los paquetes de terceros asignada a los mismos equipos. No es necesario cambiar nada en SCCM; la única interacción que se modifica es la entrega de actualizaciones de Windows.

Si utilizas Software Update Groups en SCCM, verifica que la regla “Do not download updates from Microsoft Update” siga activa para evitar que SCCM intente descargar de nuevo los mismos paquetes que Intune gestiona.

Paso 5 – Monitorear y cerrar la transición

Configura alertas en Endpoint Manager y en SCCM:

  • En Intune, crea una alerta de Update compliance < 80 %.
  • En SCCM, habilita el reporte Update Deployment Status para los grupos que todavía dependen de WSUS.

Cuando ambas métricas estén estables, procede a eliminar la GPO de forma permanente.

Cuándo aplicar esta solución

  • Escenario válido: Entornos híbridos con dispositivos Hybrid‑joined, co‑management activo y necesidad de seguir entregando paquetes de terceros desde SCCM.
  • Síntomas que indican la necesidad: Dispositivos que, tras habilitar Intune, siguen descargando actualizaciones de WSUS o, por el contrario, caen a Microsoft Update sin respetar los anillos definidos.
  • No aplicar: Cuando la organización ya ha migrado completamente a Intune y no usa SCCM para paquetes de terceros, o cuando todos los dispositivos son Azure AD‑joined y no dependen de GPOs locales.

Código

# Verificar valores de WSUS en la máquina local
powershell -Command "Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate' | Select-Object -Property WUServer, WUStatusServer"

# Forzar una actualización de políticas de Intune
powershell -Command "Invoke-DeviceSync"

Verificación

  1. Comprobación de política: En el portal de Intune, abre un dispositivo y revisa la sección Device configuration > Profiles > Assigned. Debe mostrar la política de Windows Update con estado Success.
  2. Registro de Windows Update: En el cliente, abre el Visor de eventos → Applications and Services Logs → Microsoft → WindowsUpdateClient → Operational. Busca eventos AU\_Policy\_Applied que indiquen que la política de Intune se aplicó.
  3. Prueba de fallback: Desconecta temporalmente el acceso al servidor WSUS y ejecuta wuauclt /detectnow. El cliente debe reportar “No WSUS server configured” y luego buscar actualizaciones según la política de Intune.
  4. Paquetes de terceros: En SCCM, revisa el Deployment Status del paquete de Adobe. Debe mostrarse como Success en los equipos que ya están bajo Intune.

Notas adicionales

  • Tiempo de propagación: En entornos con cientos de dispositivos, la política de Intune puede tardar hasta 2 h en aplicarse a todos los equipos. Planifica la eliminación de la GPO en ventanas de mantenimiento.
  • Dual scan genera tráfico adicional al contactar tanto a Intune como a WSUS. Si la red es limitada, considera desactivar temporalmente el dual scan una vez que la política de Intune esté establecida.
  • Backup de GPO: Exporta la GPO antes de modificarla (gpresult /h gpo_backup.html). Así puedes restaurarla rápidamente si algo falla.
  • Versiones de cliente: Asegúrate de que los dispositivos tengan al menos la versión de cliente de Windows 10 1903; versiones anteriores pueden no soportar correctamente la política de Intune WUfB.

Con este enfoque gradual, mantienes la continuidad de los paquetes de terceros, evitas actualizaciones inesperadas y garantizas que la política de Intune sea la única fuente de Windows Update una vez completada la migración.