MENU
  1. Inicio
  2. Windows
  3. Windows Server
  4. Reenvío de eventos de Windows (WEF) con método Source‑Initiated: guía completa de configuración y resolución del error WinRM 105

Reenvío de eventos de Windows (WEF) con método Source‑Initiated: guía completa de configuración y resolución del error WinRM 105

Windows Server

El reenvío de eventos de Windows (WEF) con el método Source‑Initiated es una funcionalidad poco explotada que simplifica la centralización de registros, reduce el número de conexiones entrantes que se deben abrir en el Collector y aumenta la visibilidad sobre incidentes de seguridad y problemas operativos. Sin embargo, cuando algo falla, puede ser frustrante aislar la causa. Este artículo profundiza en la arquitectura, los requisitos previos y, sobre todo, en la solución a uno de los errores más frecuentes: el Evento 105 del cliente WinRM que indica que la URL solicitada no está disponible.

Índice

Escenario de laboratorio

Contamos con un equipo Windows Server 2019 (rol de Forwarder) y una estación Windows 10 22H2 (rol de Collector) dentro del mismo dominio. Se ha:

  • Habilitado WinRM en ambos equipos.
  • Creado una suscripción Source‑Initiated en el Collector.
  • Abrir el puerto 5985/TCP en sus firewalls locales.

Al ejecutar wecutil qi <Suscripción> o al revisar el Visor de eventos del Forwarder, aparece el Evento 105:

The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available…

RAÍZ DEL PROBLEMA

El mensaje 105 suele confundirse con un bloqueo de firewall, pero con frecuencia se debe a:

  1. Conflictos de binding en IIS: si en el Collector existe un sitio web escuchando en el puerto 80 con un nombre de host explícito, las peticiones WS‑Management (/wsman) pueden redirigirse al sitio web en lugar de al servicio WinRM.
  2. Configuraciones WinHTTP heredadas: un proxy establecido hace años e ignorado por GPO puede forzar a WinRM a encaminar la solicitud fuera de la red local.
  3. Valores incorrectos en la GPO “Target Subscription Manager”: errores de sintaxis, uso del nombre NetBIOS en vez del FQDN o concatenar varias URL sin salto de línea.

Matriz de pasos correctivos

PasoExplicación
Revisar el sitio “Default Web Site” en IIS (Collector)Abrir IIS Manager → Default Web Site → Edit Bindings… Verificar que exista una binding HTTP sin nombre de host y con IP “All Unassigned”. Si no existe, crearla; si existe pero contiene un “Host name”, dejarlo en blanco. Reiniciar IIS para liberar el puerto.
Comprobar la presencia de un proxy WinHTTPEn el Collector: netsh winhttp show proxy Si devuelve algo distinto de Direct access, restablecerlo: netsh winhttp reset proxy
Confirmar conectividad WinRMDesde el Forwarder: Test-WSMan <FQDN-Collector> -Port 5985 Ambos equipos deben mostrar un listener HTTP activo: winrm enumerate winrm/config/listener
Ajustar la GPO “Target Subscription Manager”Usar el formato correcto (una línea): http://<FQDN-Collector>:5985/wsman/SubscriptionManager/WEC,Refresh=10 Evita concatenar con punto y coma; los saltos de línea son los separadores válidos.
Comprobaciones adicionalesLos servicios Windows Event Collector y Windows Remote Management deben estar Iniciados y en tipo de inicio Automático. El grupo Event Log Readers del Collector debe incluir a NETWORK SERVICE. Si persiste el error, capturar tráfico con Wireshark para descartar RST o redirecciones HTTP 301.

Cómo funciona el método Source‑Initiated

En un flujo Source‑Initiated:

  1. El Forwarder (equipo origen)
    1. Lee la GPO Target Subscription Manager.
    2. Envía una solicitud WS‑Management al Collector.
    3. Escucha instrucciones sobre qué registros enviar.
  2. El Collector
    1. Acepta la conexión en /wsman/SubscriptionManager/WEC.
    2. Autentica al Forwarder (Kerberos, NTLM o certificados).
    3. Devuelve la lista de suscripciones y filtros definidos por el administrador.

La gran ventaja es que el servidor central ya no necesita tener mapeado cada equipo remoto; el Forwarder se “presenta” espontáneamente tras aplicar GPO.

Buenas prácticas de seguridad

  • Cifrado TLS (HTTPS/5986): aunque 5985 utiliza HTTP puro, el contenido se firma e integra con Kerberos, pero no va cifrado. En entornos con segmentación estricta o datos sensibles, genera un certificado y escucha en 5986.
  • Delegación restringida: impide que un atacante reutilice las credenciales delegadas. Aplica el parámetro -Compatibility HTTPS cuando crees el listener con PowerShell.
  • Políticas de filtrado: limita la suscripción a canales y niveles de evento estrictamente necesarios. Menos registros = menos superficie.

Validación tras los cambios

  1. Ejecutar gpupdate /force en el Forwarder y en el Collector.
  2. Revisar el Visor de eventos → Applications and Services Logs → Microsoft → Windows → ForwardedEvents en el Collector.
  3. En el Forwarder, comprobar la aparición de Evento 100 (successful subscription).
  4. Verificar que el contador % Processor Time del Forwarder no supere valores anómalos: cada lote enviado consume CPU sobre todo si hay compresión.

Automatización con PowerShell

Si gestionas cientos de servidores, crea funciones reutilizables:

function Enable-WEFSourceInitiated {
    param(
        [Parameter(Mandatory)]
        [string]$CollectorFqdn
    )
    # 1. Habilitar WinRM
    Enable-PSRemoting -Force
    # 2. Configurar listener HTTP
    if (-not (winrm get winrm/config/listener |
              Select-String "Transport = HTTP")) {
        winrm create winrm/config/Listener?Address=*+Transport=HTTP
    }
    # 3. Apuntar a Subscription Manager
    $url = "http://$CollectorFqdn`:5985/wsman/SubscriptionManager/WEC"
    wecutil cs SubscriptionManager $url
}

Cuándo utilizar Collector‑Initiated en su lugar

El enfoque Source‑Initiated brilla en redes con gran número de endpoints, clientes móviles o subredes administradas por terceros. No obstante, el modo Collector‑Initiated es útil si necesitas:

  • Control unilateral sobre la cantidad de datos extraídos.
  • Iniciar conexiones desde un segmento DMZ hacia la LAN interna (inversión de flujo).
  • Auditar hosts sin pertenencia al dominio (se confía en credenciales locales).

Optimización de rendimiento

El reenvío de eventos genera tráfico constante. Para evitar congestión: Tamaño del lote (Batching) Configura en cada suscripción un intervalo de recolección y un máximo de eventos por lote (por ejemplo, 50 eventos o 60 segundos). Compresión WinRM comprime paquetes automáticamente si exceden 16 KB. No intentes “doble compresión” con Gzip a nivel de red, no aporta beneficios. Filtros Xpath selectivos Usa Xpath para incluir solo canales y niveles críticos: *[System/Level=1 or System/Level=2].

Preguntas frecuentes

¿Necesito IIS para que WinRM funcione?

No, WinRM no depende de IIS. El conflicto surge cuando otro servicio (IIS) acapara el puerto 80 y desvía las peticiones.

¿Cómo valido el certificado de un listener HTTPS?

Ejecuta Invoke-WebRequest https://<Collector>:5986/wsman; revisa que llegue una respuesta 401 Unauthenticated con el certificado correcto en la cadena SSL.

¿Puedo reenviar eventos desde equipos Workgroup?

Sí. Configura autenticación mutua con certificados y utiliza la propiedad /CertificateThumbprint en winrm set winrm/config.

Conclusión

Corregir el Evento 105 del cliente WinRM requiere validar desde lo más obvio (firewall) hasta lo menos evidente (proxy WinHTTP o bindings IIS). Una vez ajustados estos valores, WEF se convierte en un mecanismo robusto para agrupar logs a escala y detectar amenazas en tiempo real, especialmente combinado con Azure Monitor o SIEMs como Splunk. Mantén tus suscripciones depuradas, cifra los canales cuando sea necesario y automatiza la configuración para reducir la fatiga operativa.

Si sigues estos pasos y buenas prácticas, tu infraestructura de Windows Event Forwarding operará de forma estable y segura, proporcionando la visibilidad que tu equipo de operaciones y seguridad necesita.

Windows Server
Índice