Problema
En entornos donde se usan suscripciones source‑initiated de Windows Event Forwarding (WEF), es frecuente observar que la recolección de eventos funciona sin interrupciones mientras los equipos permanecen encendidos. El punto crítico aparece cuando tanto el colector como los endpoints se apagan durante varios días y, al volver a encenderse, la suscripción pasa a estado Inactive y no se reactiva automáticamente. Los intentos de “Retry” desde el visor de eventos no cambian nada y la única forma de volver a recibir eventos es eliminar la suscripción y crear una nueva. El síntoma se manifiesta con errores de WinRM (códigos 1311, 0x80090311) y mensajes que indican que el “event source is in either disable or inactive state”.
Este comportamiento no es exclusivo de una configuración concreta; ocurre en cualquier despliegue donde la comunicación entre el Event Collector y los sources depende de WinRM y del registro de suscripciones en el servicio Wecsvc. La raíz del problema suele estar en la pérdida de estado de la suscripción durante el apagado prolongado y en la falta de un mecanismo de re‑registro automático al reinicio.
Causa
1. Caducidad del subscription cache en el colector
Wecsvc mantiene un caché en memoria que asocia cada endpoint con su suscripción activa. Cuando el colector se apaga, ese caché desaparece. Al iniciar de nuevo, el servicio intenta re‑activar la suscripción mediante el Subscription Manager. Si el endpoint aún no ha completado su proceso de arranque de WinRM (por ejemplo, porque el controlador de dominio todavía no está disponible), la petición falla y el colector marca la suscripción como inactiva. La marca persiste porque el colector no vuelve a intentar la activación una vez que WinRM está operativo.
2. Kerberos ticket expirado o no renovado
Durante el apagado, los tickets de Kerberos de los equipos caducan. Al arrancar, el endpoint intenta autenticarse con el colector usando el ticket almacenado; si el controlador de dominio no está disponible o la sincronización de tiempo aún no se ha estabilizado, la autenticación falla y WinRM devuelve el error 1311. Sin una autenticación válida, la suscripción no puede re‑registrarse.
3. Orden de arranque desfavorable
Si el colector (que también actúa como DC) arranca después del endpoint, el endpoint intenta conectarse a un servicio que aún no está escuchando en el puerto 5985/5986. Los logs muestran “HTTP server not available”. La primera tentativa falla y, al no haber un mecanismo de reintento continuo, la suscripción queda marcada como deshabilitada.
4. Política de re‑intento limitada
El parámetro Refresh= en la URL de suscripción controla la frecuencia con la que el endpoint consulta al colector. Un valor bajo (por ejemplo, 60 s) no garantiza que el endpoint vuelva a intentar después de una falla prolongada; la política interna de WEC solo ejecuta un número limitado de reintentos al iniciar y luego deja la suscripción en estado inactivo.
Solución
Una solución robusta combina tres acciones: garantizar que el colector esté disponible antes que los endpoints, forzar la renovación de los tickets Kerberos y habilitar un ciclo de re‑registro continuo.
Paso 1 – Asegurar el orden de arranque
- En el DC/collector, habilita el servicio Windows Event Collector con tipo de inicio Automático (Delayed Start). Esto permite que el controlador de dominio y los servicios de red se inicialicen antes de que Wecsvc empiece a aceptar conexiones.
- En los endpoints, configura la política “Always wait for the network at computer startup and logon” (ya está activada en la mayoría de los entornos) y añade una dependencia de servicio para que
WinRMespere aNetlogonantes de iniciar. En PowerShell:
sc config WinRM depend= Netlogon/AFD
Paso 2 – Renovar tickets Kerberos al arranque
Añade un script de inicio que borre los tickets existentes y solicite uno nuevo:
klist purge
klist get <DC_FQDN>
Colócalo en C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\renew_krb.cmd o como una tarea programada que se ejecute al iniciar el sistema con privilegios de SYSTEM.
Paso 3 – Habilitar re‑intentos automáticos de suscripción
Modifica la URL de suscripción para incluir el parámetro RetryInterval= (en segundos) y MaxRetry= (número de intentos). Por ejemplo:
Server=http://DC01.example.com:5985/wsman/SubscriptionManager/WEC,Refresh=60,RetryInterval=120,MaxRetry=0
MaxRetry=0 indica reintentos indefinidos. Esta configuración se aplica a través del GPO Event Forwarding en la sección Configure target Subscription Manager.
Paso 4 – Forzar la re‑activación de suscripciones existentes
En el colector, ejecuta el siguiente comando después de cada reinicio para limpiar suscripciones “zombie” y volver a registrarlas:
wecutil cs
wecutil ss
cs (clear subscription) elimina el estado guardado y ss (show subscription) vuelve a cargar la definición desde el archivo XML. Si prefieres no borrar, simplemente ejecuta:
wecutil es /q
Esto fuerza al servicio a volver a evaluar todas las suscripciones sin perder la configuración.
Paso 5 – Verificar la configuración de URL ACL
Asegúrate de que los ACL de HTTP incluyan tanto el SID de NT SERVICE\WinRM como el de NT SERVICE\Wecsvc. Un comando típico:
netsh http show urlacl url=http://+:5985/wsman/
Si falta alguna entrada, vuelve a crearla con el mismo sddl usado en la instalación original.
Cuándo aplicar esta solución
- Síntomas: después de varios días de apagado, los endpoints aparecen como Inactive en el visor de suscripciones; los logs de WinRM muestran errores 1311; no se reciben eventos nuevos aunque el colector y los endpoints estén en línea.
- Entorno: despliegues de WEF con suscripciones source‑initiated, colector que también actúa como controlador de dominio o DNS, máquinas virtuales que pueden ser apagadas por mantenimiento.
- No aplica: si la suscripción es collector‑initiated (el colector solicita eventos) o si el problema se reduce a una falla de red permanente (p.ej., firewall bloqueando puertos). En esos casos la solución se centra en la conectividad y no en la reactivación automática.
Código
# 1. Configurar dependencia de WinRM
sc config WinRM depend= Netlogon/AFD
# 2. Script de renovación Kerberos (renew_krb.cmd)
klist purge
klist get DC01.example.com
# 3. Forzar re‑carga de suscripciones en el colector
wecutil cs
wecutil ss
Verificación
- Reinicia el colector y, después de que el servicio
Netlogonesté activo, verifica queWecsvcesté en estado Running. - Inicia el endpoint y comprueba que el script de Kerberos se haya ejecutado (evento en
Systemcon ID 1000). - En el visor de eventos del endpoint, busca
Eventlog-ForwardingPlugin/Operationaly confirma que el ID 104 indica “successfully connected to the subscription manager”. - En el colector, abre Event Viewer → Subscriptions → Runtime Status y verifica que el endpoint aparezca como Active.
- Genera un evento de prueba (por ejemplo,
eventcreate /ID 1000 /L Application /T INFORMATION /SO TestWEF) y comprueba que aparece en Forwarded Events del colector.
Notas adicionales
- En entornos con alta disponibilidad, considera desplegar un segundo colector y usar la opción “Multiple collectors” en la suscripción. Cada endpoint mantendrá una lista de coletores y cambiará automáticamente si uno queda inactivo.
- Si el dominio utiliza time synchronization con NTP externo, verifica que la diferencia de tiempo entre endpoint y DC no supere los 5 minutos; de lo contrario, Kerberos fallará de forma intermitente.
- Algunas versiones de Windows Server introducen un bug donde
RetryIntervalno se respeta después de un reinicio del colector. En esos casos, aplicar el comandowecutil cscomo parte de un script de inicio del colector es la solución más fiable.