Problema

Al iniciar una VM de Windows Server 2022 (o 2019) sobre Proxmox, el registro de eventos muestra repetidamente Event ID 5719 (NETLOGON). El mensaje indica que el cliente no pudo contactar al controlador de dominio dentro del tiempo de espera. Tras unos minutos, la replicación y el inicio de sesión funcionan sin incidentes. El síntoma se repite en cada arranque, afecta a servidores que no son controladores de dominio y suele aparecer cuando la NIC está basada en VirtIO con multiqueue habilitado y la máquina usa el modelo q35. En entornos donde los DC ya están operativos, el error se reduce a una cuestión de sincronización de red durante el arranque.

Causa

  1. Arranque demasiado rápido – Proxmox entrega la interfaz de red a la VM casi inmediatamente. Windows inicia los servicios de dominio antes de que la pila TCP/IP haya completado la negociación de la NIC VirtIO, especialmente con multiqueue y drivers recientes.
  2. GPO “Always wait for the network…” – Cuando la política está desactivada, el subsistema Netlogon no espera a que la conexión de red esté lista y lanza la solicitud de autenticación prematuramente.
  3. Configuración de la NIC – El driver VirtIO 0.1.271, aunque funcional, necesita un par de segundos para establecer los anillos de transmisión/recepción y para que el switch virtual (Linux bridge o OVS) aprenda la dirección MAC. En máquinas q35, la detección de PCIe puede añadir latencia adicional.
  4. Resolución de nombres – Si el DNS interno todavía no está accesible cuando Netlogon se ejecuta, la búsqueda del controlador de dominio falla y genera el 5719.
  5. Política de arranque de servicios – En versiones recientes de Windows Server, los servicios críticos pueden estar configurados como “auto (delayed start)”. Si Netlogon no está retrasado, compite con la inicialización de la NIC.

Solución

Una estrategia combinada suele eliminar el error sin sacrificar el tiempo de arranque:

1. Habilitar la política “Always wait for the network at computer startup and shutdown”

Esta GPO obliga a Windows a bloquear la fase de arranque hasta que la interfaz reporte Connected. En entornos sin dominio, se puede aplicar localmente:

  1. Ejecutar gpedit.msc.
  2. Navegar a Computer Configuration → Administrative Templates → System → Logon.
  3. Activar Always wait for the network at computer startup and shutdown.

Si no se dispone de gpedit, el mismo efecto se consigue editando el registro:

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v EnableFirstLogonAnimation /t REG_DWORD /d 0 /f
reg add "HKLM\System\CurrentControlSet\Services\Netlogon\Parameters" /v SyncDomainWithMembership /t REG_DWORD /d 1 /f

2. Añadir un retraso de arranque al servicio Netlogon

Configurar Netlogon como “delayed start” permite que la NIC se estabilice antes de que el cliente intente la autenticación.

sc config Netlogon start= delayed-auto

Reiniciar la VM para que el cambio tome efecto.

3. Ajustar la NIC VirtIO

  • Desactivar multiqueue si no se necesita alto rendimiento en servidores de bajo tráfico. En la VM, abre el Administrador de dispositivos, localiza el adaptador “Red Ethernet (VirtIO)”, abre sus propiedades y desmarca “Enable multi‑queue”.
  • Actualizar el driver a la última versión disponible en el repositorio de Proxmox (p.ej., 0.1.280). Los paquetes virtio-win se pueden montar como ISO y actualizar desde el Administrador de dispositivos.
  • Forzar una MAC estática en la configuración de la VM (net0: virtio,bridge=vmbr0,mac=XX:XX:XX:XX:XX:XX). Evita que Proxmox genere una MAC aleatoria en cada arranque, lo que a veces retrasa la asociación en el switch.

4. Configurar un script de espera en el arranque

Si la política GPO no es viable (por ejemplo, en entornos sin dominio), un script de PowerShell que espere a que la interfaz tenga una dirección IP válida antes de iniciar Netlogon es útil.

$iface = "Ethernet"
while ((Get-NetIPAddress -InterfaceAlias $iface -AddressFamily IPv4).IPAddress -eq $null) {
    Start-Sleep -Seconds 2
}
Restart-Service Netlogon

Colocar el script en C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp o registrar una tarea programada que se ejecute al iniciar con la condición “NetworkAvailable”.

5. Verificar la resolución DNS al arranque

Asegurarse de que la primera consulta DNS se resuelva contra un servidor interno disponible:

  • Añadir la IP del controlador de dominio como primary DNS en la configuración de la NIC.
  • Opcionalmente, habilitar DNS cache en la VM (netsh interface ip set dns "Ethernet" static <IP_DC>).

Cuándo aplicar esta solución

  • Síntomas: Event ID 5719 en el registro de System durante los primeros minutos del arranque; fallos intermitentes de inicio de sesión con cuentas de dominio; latencia al montar unidades de red al iniciar.
  • Entornos: Windows Server 2019/2022 ejecutándose como máquina virtual en Proxmox (versión 9.x o superior) con NIC VirtIO, sin ser controlador de dominio.
  • No aplica: Si la VM es controlador de dominio (el error suele indicar otro problema), o si la red física tiene problemas de conectividad que impiden que los DC respondan. En esos casos, la solución pasa a nivel de infraestructura (switch, VLAN, firewall).

Código

# Habilitar GPO “Always wait for the network” vía registro
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v EnableFirstLogonAnimation /t REG_DWORD /d 0 /f
reg add "HKLM\System\CurrentControlSet\Services\Netlogon\Parameters" /v SyncDomainWithMembership /t REG_DWORD /d 1 /f

# Cambiar Netlogon a delayed start
sc config Netlogon start= delayed-auto

# PowerShell de espera de IP antes de reiniciar Netlogon
$script = @"
$iface = "Ethernet"
while ((Get-NetIPAddress -InterfaceAlias $iface -AddressFamily IPv4).IPAddress -eq $null) {
    Start-Sleep -Seconds 2
}
Restart-Service Netlogon
"@
Set-Content -Path "C:\Scripts\WaitForIP.ps1" -Value $script -Encoding UTF8

Verificación

  1. Reiniciar la VM y abrir el Visor de eventos. Confirmar que Event ID 5719 no aparece o que aparece solo después de que el servicio Netlogon se haya iniciado manualmente.
  2. Ejecutar nltest /sc_verify:<domain>; la salida debe indicar 0 errores.
  3. Comprobar que la dirección IP está asignada inmediatamente después del arranque (ipconfig /all).
  4. Verificar que la latencia de arranque no supera los 30 segundos adicionales; un retraso mayor sugiere que la política GPO no está siendo respetada.

Notas adicionales

  • En clústers con alta densidad de VMs, habilitar QoS en el bridge de Proxmox para priorizar tráfico de dominio puede reducir la ventana de tiempo en la que la VM “no ve” al DC.
  • Si la VM necesita alta capacidad de red, mantén multiqueue habilitado y compensa con un delay de 5 s en el script de PowerShell; la diferencia de rendimiento suele ser marginal frente a la estabilidad.
  • Cuando se usan plantillas de VM, incorpora los cambios de GPO y del registro en la plantilla base; así cada despliegue nuevo hereda la corrección sin pasos manuales.
  • En entornos con SR-IOV o vhost-net, la interacción con VirtIO cambia; en esos casos, el problema del 5719 desaparece porque la NIC se presenta como hardware físico y Windows la reconoce como lista al instante.

Con estos ajustes, la mayoría de los despliegues de Windows Server bajo Proxmox dejan de registrar el Event 5719 y los servicios de dominio funcionan sin interrupciones durante el arranque.