Problema

En entornos mixtos (on‑premise y Azure) es frecuente observar que los servidores Windows Server en Azure realizan la comprobación de actualizaciones con una periodicidad distinta a la de los mismos servidores en datacenters propios. Mientras que los equipos locales pueden estar configurados para buscar actualizaciones cada hora, los VMs en Azure a menudo aparecen con solo unas cuantas consultas al día. El síntoma se manifiesta en los logs de Windows Update, en el historial de WSUS/Azure Update Manager y en la consola de GPO donde la política parece idéntica en ambos grupos.

Este comportamiento genera incertidumbre: ¿está el VM recibiendo actualizaciones con retraso? ¿Se está desperdiciando tiempo de parcheo porque la ventana de mantenimiento se reduce sin razón? La raíz del problema suele estar en la interacción entre la imagen base de Azure, la configuración de la política de actualización y los servicios de sincronización internos de la plataforma.

Causa

Varias causas pueden producir una cadencia de comprobación más lenta en Azure:

  1. Imagen de Azure con configuración de “Update Policy” predefinida
    Las imágenes oficiales de Windows Server en Azure incluyen un conjunto de ajustes de Windows Update que priorizan la reducción de tráfico de red y la alineación con los ciclos de mantenimiento de Azure. Entre ellos, el parámetro ScheduledInstallDay y ScheduledInstallTime pueden quedar establecidos en “Auto” y “0 h”, lo que fuerza una ventana de comprobación limitada.

  2. Servicio “Windows Update Medic” desactivado o restringido
    Azure puede aplicar una política que desactiva el servicio WaaSMedicSvc para evitar reinicios inesperados en máquinas de producción. Sin este servicio, la lógica de reintentos se vuelve menos agresiva y la frecuencia de polling disminuye.

  3. Configuración de “Delivery Optimization” orientada a la red de Azure
    Cuando la opción “Group” está en “Azure”, el cliente intenta descargar actualizaciones de peers dentro de la misma región. Si la topología no tiene peers activos, el cliente pospone la comprobación para evitar tráfico innecesario.

  4. Política de “Update Management” de Azure Automation
    Si el entorno usa Azure Update Manager (parte de Azure Automation) con la opción “Customer‑managed”, la frecuencia de escaneo se controla mediante el schedule del runbook. Un schedule con “Daily” en vez de “Hourly” sobrescribe cualquier GPO local.

  5. Diferencias en la zona horaria o en la configuración de “Time Synchronization”
    Los VMs en Azure pueden estar sincronizados con un servidor NTP diferente, lo que altera la alineación de los intervalos de polling definidos en la política.

En la práctica, el problema suele ser una combinación de la primera y la cuarta causa: la imagen base establece valores conservadores y Azure Update Manager impone su propio schedule, anulando la intención de los GPO on‑premise.

Solución

La solución se divide en tres pasos: inspección, alineación de políticas y validación.

1. Inspeccionar la configuración actual

Utiliza PowerShell para obtener los valores de Windows Update que están activos en el VM:

Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" |
  Select-Object AUOptions, ScheduledInstallDay, ScheduledInstallTime, NoAutoRebootWithLoggedOnUsers

Revisa también la configuración de Delivery Optimization:

Get-DeliveryOptimizationConfig | Select-Object -Property DownloadMode, Group, CacheSize

Y verifica el estado del servicio WaaSMedic:

Get-Service -Name WaaSMedicSvc

2. Forzar la política deseada mediante GPO o PowerShell

Si la política de la organización requiere un polling cada hora, sobrescribe los valores de la imagen:

Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" `
  -Name AUOptions -Value 4   # 4 = Auto download + schedule install
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" `
  -Name ScheduledInstallDay -Value 0   # 0 = Every day
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" `
  -Name ScheduledInstallTime -Value 0   # 0 = Midnight (pero el polling sigue cada hora)

Para asegurar que el polling sea cada hora, habilita la tarea programada interna de Windows Update:

schtasks /Change /TN "\Microsoft\Windows\WindowsUpdate\AU\Schedule Scan" /RU "SYSTEM" /TR "wuauclt.exe /detectnow" /SC HOURLY

Si se usa Azure Update Manager, ajusta el schedule del runbook:

  1. En el portal de Azure, abre Automation Account → Update Management → Update deployments.
  2. Edita el deployment que afecta a los VMs en cuestión.
  3. Cambia la frecuencia de “Schedule” a Hourly o crea un nuevo deployment con esa periodicidad.
  4. Guarda y publica.

3. Desactivar interferencias de Delivery Optimization (opcional)

Si la topología de peers es escasa y está provocando retrasos, fuerza el modo “Simple”:

Set-DeliveryOptimizationConfig -DownloadMode Simple

4. Reiniciar los servicios y forzar una comprobación inmediata

Restart-Service -Name wuauserv
Restart-Service -Name WaaSMedicSvc
wuauclt.exe /detectnow

Cuándo aplicar esta solución

  • Síntomas: los logs de WindowsUpdate.log muestran menos de 5 eventos de “Checking for updates” en 24 h; Azure Update Manager indica “Last scan: 12 h ago”; los servidores en Azure tardan más de 24 h en recibir parches críticos.
  • Entorno: VMs basados en imágenes oficiales de Azure, gestionados por Azure Update Manager o por GPO on‑premise.
  • No aplica: entornos donde la política de actualización está intencionalmente configurada para “Weekly” o “Monthly”, o cuando la imagen está personalizada y ya contiene los valores deseados.

Código

# Obtener configuración actual
Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update"

# Forzar política de polling cada hora
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" -Name AUOptions -Value 4
schtasks /Change /TN "\Microsoft\Windows\WindowsUpdate\AU\Schedule Scan" /SC HOURLY

# Ajustar Delivery Optimization (opcional)
Set-DeliveryOptimizationConfig -DownloadMode Simple

# Reiniciar servicios y disparar escaneo inmediato
Restart-Service -Name wuauserv
Restart-Service -Name WaaSMedicSvc
wuauclt.exe /detectnow

Verificación

  1. Revisar el historial: abre Event Viewer → Applications and Services Logs → Microsoft → Windows → WindowsUpdateClient → Operational. Busca eventos con ID 19 (“Checking for updates”) y confirma que aparecen al menos cada hora.
  2. Comprobar la tarea programada: schtasks /Query /TN "\Microsoft\Windows\WindowsUpdate\AU\Schedule Scan" debe mostrar Schedule: HOURLY.
  3. Validar Azure Update Manager: en el portal, verifica que el último “Scan time” del deployment sea reciente (< 1 h).
  4. Confirmar descarga: ejecuta Get-WindowsUpdateLog y busca líneas que indiquen Downloading dentro del intervalo esperado.

Si todos los puntos anteriores concuerdan, la cadencia de actualización está alineada con la política deseada.

Notas adicionales

  • Cambiar la frecuencia de polling incrementa el tráfico de red hacia los endpoints de Microsoft. En entornos con ancho de banda limitado, evalúa el impacto antes de pasar a “Hourly”.
  • Algunas imágenes de Azure incluyen un script de “post‑deployment” que vuelve a aplicar valores predeterminados al iniciar. Busca en C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp o en Task Scheduler entradas que ejecuten Set-ItemProperty. Elimina o desactiva esas tareas para evitar que tus cambios se sobrescriban.
  • Cuando se usa Azure Update Manager con “Customer‑managed”, los cambios en GPO solo son efectivos si el agente de Update Management está deshabilitado. Asegúrate de que el agente no esté reescribiendo la configuración cada 30 min.
  • En entornos con varios suscriptores, sincroniza la política de frecuencia entre todos los grupos de recursos para evitar que algunos VMs sigan usando la configuración predeterminada de Azure.