Windows Event Forwarding: errore WinRM 504 verso WEC – soluzione tramite bypass proxy WinHTTP

Gli agenti Windows Event Forwarding possono generare errori 504 (timeout) quando tentano di contattare il collector WEC tramite WinRM/WS‑Man. La causa più comune è un proxy WinHTTP non configurato con il bypass corretto. In questa guida risolvi l’errore e ripristini il forwarding in modo sicuro.

Indice

Panoramica del problema

In uno scenario di Windows Event Forwarding (WEF) con subscription di tipo source-initiated, il forwarder prova a contattare il subscription manager all’URL:

http://WefcollectorSRV:5985/wsman/SubscriptionManager/WEC

Nel registro Microsoft‑Windows‑Eventlog‑ForwardingPlugin/Operational compaiono errori ripetuti come il seguente:

Code="2150859023" ... The WinRM client received an HTTP status code of 504 from the remote WS-Management service.

I servizi WinRM e Wecsvc risultano avviati, ma il forwarder continua a generare 504 (timeout) e non si riesce a creare o mantenere la sessione WS‑Man.

Cosa significa realmente l’errore 504 in questo contesto

Il codice 504 (Gateway Timeout) indica che una componente intermedia sul percorso HTTP non ha ricevuto una risposta in tempo. In ambienti enterprise questo intermediario è spesso un proxy HTTP o un appliance di sicurezza che intercetta la porta 5985. Poiché WEF/WinRM usa WinHTTP (non le impostazioni proxy di IE/Edge), se il collector non è incluso nella bypass list di WinHTTP, le chiamate WS‑Man possono:

Uscire attraverso il proxy (che non comprende WS‑Man) e andare in timeout.
Essere bloccate, riscritte o rate‑limited dal proxy, generando 504.
Subire connection reuse o idle timeout non compatibili con la long‑polling di WEF.

Sintomi tipici osservabili

Eventi ripetuti con Code="2150859023" nel log Eventlog‑ForwardingPlugin/Operational.
Impossibilità di creare/aggiornare le subscription (nessun evento “created successfully”).
Connettività di rete apparentemente OK (ping/DNS) ma sessione WS‑Man non stabilita.
Su endpoint con proxy obbligatorio, altri servizi HTTP funzionano, ma WEF no.

Diagnostica veloce: checklist eseguibile

Esegui i seguenti controlli dal computer forwarder (sorgente degli eventi):

Verifica proxy WinHTTP
netsh winhttp show proxy Se vedi un proxy configurato e il collector non è in bypass, è molto probabile che sia la causa.
Risoluzione DNS del collector
nslookup WefcollectorSRV Se il nome non risolve o risolve su un IP errato, anche questo può produrre “2150859023”.
Reachability TCP
PowerShell Test-NetConnection -ComputerName WefcollectorSRV -Port 5985 Conferma che la porta sia raggiungibile senza passare da proxy; questo test da solo non prova l’assenza di proxy, ma aiuta.
Test WinRM puntuale
winrm id -r:WefcollectorSRV:5985 Serve solo a verificare la risposta del servizio WS‑Man; in domini Kerberos può richiedere FQDN.
Firewall locale
netsh advfirewall firewall show rule name="Windows Remote Management (HTTP-In)" Il forwarder in modalità source‑initiated apre connessioni in uscita; assicurati che non siano bloccate.

Soluzione rapida e comprovata

Se l’ambiente utilizza un proxy HTTP a livello di sistema, configura la bypass list di WinHTTP per il collector e riavvia WinRM. La tabella seguente riassume i passaggi.

Passaggio	Azione	Spiegazione
1	Verificare la configurazione proxy di WinHTTP: `netsh winhttp show proxy`	WinRM/WEF usa WinHTTP, non le impostazioni proxy di IE/Edge. Se il collector non è escluso, il traffico WS‑Man passa nel proxy e può andare in timeout (504).
2	Aggiungere il collector nella bypass list: `netsh winhttp set proxy proxy-server="proxyserver:proxyport" bypass-list="<local>;10.;192.168.;172.16.*;WefcollectorSRV"`	Inserendo `WefcollectorSRV` (o FQDN) nella bypass list forzi il traffico verso il collector a ignorare il proxy. Usa wildcard secondo lo schema IP della tua LAN.
3	Riavviare WinRM: `net stop winrm && net start winrm`	WinRM legge le impostazioni WinHTTP solo all’avvio; il riavvio applica immediatamente la nuova configurazione.
4	Ricreare/aggiornare la subscription WEF e verificare: `wecutil es` oppure controllare l’evento ID 100 “The subscription was created successfully.”	Dopo il bypass, l’errore 504 scompare e il forwarder stabilisce la sessione WS‑Man con il collector.

Esempi pratici di configurazione del bypass

Collector con FQDN

netsh winhttp set proxy proxy-server="proxy.corp.example:8080" bypass-list="&lt;local&gt;;10.;192.168.;172.16.*;Wec01.corp.example"

Più collector

netsh winhttp set proxy proxy-server="proxy.corp.example:8080" bypass-list="&lt;local&gt;;10.;192.168.;172.16.*;Wec01;Wec02;Wec03"

Ambiente senza proxy (ripristino)

netsh winhttp reset proxy

Import da impostazioni del browser (con cautela)

Se il proxy è definito in IE/Edge (o via PAC/WPAD) e desideri replicarlo in WinHTTP:

netsh winhttp import proxy source=ie

Dopo l’import, verifica comunque che il collector sia presente nella bypass list di WinHTTP e non solo in quella del browser.

Verifica post‑fix

Log WEF sul forwarder
wevtutil qe Microsoft-Windows-Eventlog-ForwardingPlugin/Operational /c:10 /rd:true /f:text Dovresti vedere la cessazione degli errori 504 e messaggi di handshake riuscito.
Log sul collector
Cerca l’evento ID 100 che conferma la creazione della subscription con successo.
Flusso eventi
Controlla che gli eventi attesi arrivino nella subscription e che i contatori di consegna crescano.

Approfondimenti, cause alternative e buone pratiche

DNS / FQDN – Assicurati che il nome del collector risolva al corretto indirizzo IP e che l’SPN (HTTP/hostname) sia coerente se usi Kerberos. Errori di risoluzione possono generare lo stesso codice 2150859023.
Firewall – Apri la porta TCP 5985 (HTTP) o 5986 (HTTPS) lungo il percorso. Sul forwarder basta l’uscita; sul collector l’ingresso deve essere consentito.
Timeout lato proxy – Se il proxy non si può bypassare, aumenta i timeout o, meglio, crea una regola di direct allow per il collector.
HTTPS consigliato – In ambienti sensibili usa HTTPS (5986) con certificati validi e nomi coerenti (CN/SAN). Questo evita ispezioni e manipolazioni del traffico.
Monitoraggio – Puoi attivare temporaneamente i canali Analytic & Debug di Eventlog‑ForwardingPlugin per analizzare il dettaglio del WS‑Man handshake (attenzione: molti eventi).
Load balancer / reverse proxy – Se c’è un bilanciatore davanti al WEC, verifica idle timeout, keep‑alive e max header size. Configurazioni conservative causano time‑out durante le lunghe sessioni WEF.
Autenticazione – Preferisci Kerberos in dominio. Con HTTP usa Negotiate; con HTTPS è possibile NTLM o certificati client, valutando pro/contro.

Domande frequenti (FAQ)

Il mio ambiente non usa proxy. Perché vedo 504?
Controlla bilanciatori, WAF, transparent proxy o dispositivi di sicurezza in transito. Verifica anche la risoluzione DNS e conflitti di rotta.

Devo far girare Wecsvc sul forwarder?
In uno scenario source‑initiated non è necessario; è il collector che esegue Wecsvc. Sul forwarder serve WinRM e il plugin WEF, oltre alla policy “Configure Target Subscription Manager”.

Posso usare solo IP invece del nome?
Puoi, ma perderesti i vantaggi di Kerberos e potresti incontrare problemi con certificati HTTPS. Meglio usare FQDN coerente con DNS e SPN.

Qual è la sintassi corretta della SubscriptionManager in GPO?
In Computer Configuration > Administrative Templates > Windows Components > Event Forwarding imposta ad esempio:
Server=http://WefcollectorSRV:5985/wsman/SubscriptionManager/WEC,Refresh=60

Serve “winrm quickconfig” sul forwarder?
Di norma è sufficiente che il servizio WinRM sia disponibile per l’uso come client. Quickconfig è utile ma non sempre necessario in source‑initiated.

Ho più subnet 172.16/12: come imposto il bypass?
Specifica più voci nella lista, ad esempio 172.16.;172.17.;...;172.31.*, oppure usa FQDN e domini di ricerca coerenti.

Esempio di distribuzione via GPO (startup script)

Per applicare in massa il bypass del proxy WinHTTP ai client WEF puoi usare uno script di avvio (Startup) assegnato tramite GPO:

@echo off
REM Configura proxy WinHTTP con bypass per i collector e per la LAN
netsh winhttp set proxy proxy-server="proxy.corp.example:8080" ^
  bypass-list="<local>;10.;192.168.;172.16.*;Wec01.corp.example;Wec02.corp.example"

REM Riavvia WinRM per applicare subito le impostazioni
net stop winrm /y
net start winrm

REM Log semplice su file
echo %date% %time% - WinHTTP proxy configurato e WinRM riavviato > C:\Windows\Temp\wef-winhttp.log

Valuta di affiancare una WMI filter o una Security Filtering in GPO per applicare la policy solo ai gruppi di computer che fungono da forwarder.

Abilitazione dei log analitici per un debug mirato

Apri Event Viewer e vai in Applications and Services Logs → Microsoft → Windows → Eventlog‑ForwardingPlugin.
Fai clic destro su Analytic e Debug → Enable Log.
Riproduci il problema per qualche minuto, quindi disabilita i canali per evitare rumore e crescita eccessiva dei log.

Uso di HTTPS (5986) con certificati

Se scegli HTTPS:

Installa un certificato server valido sul collector, con CN/SAN che corrispondono al nome usato dai client (FQDN).
Aggiorna la GPO SubscriptionManager a https://WeccollectorSRV:5986/wsman/SubscriptionManager/WEC.
Conferma la reachability: Test-NetConnection WefcollectorSRV -Port 5986.
Mantieni comunque il bypass del proxy su WinHTTP per il collector, a meno di eccezioni concordate con il team rete.

Risoluzione completa: runbook operativo

Attività	Comando/Verifica	Esito atteso
Leggi stato proxy WinHTTP	`netsh winhttp show proxy`	Collector presente in bypass o “Direct access (no proxy server)”
Imposta bypass per WEC	`netsh winhttp set proxy ... bypass-list="...;Wec01"`	Bypass aggiornato
Riavvio WinRM	`net stop winrm && net start winrm`	WinRM in esecuzione con nuove impostazioni
Verifica WS‑Man	`winrm id -r:Wec01:5985`	Ricevi risposta WS‑Man senza time‑out
Controllo subscription	`wecutil es` / Evento ID 100	Subscription creata/aggiornata con successo
Validazione flusso	Eventi attesi presenti nel collector	Forwarding operativo e stabile

Consigli finali per affidabilità e sicurezza

Stabilità – Evita proxy intermedi per WS‑Man; se indispensabili, imposta eccezioni esplicite.
Sicurezza – Preferisci HTTPS, limita l’accesso alle porte 5985/5986 con firewall e segmentazione di rete.
Osservabilità – Crea alert sul collector quando una subscription cala a zero deliveries per più di N minuti.
Automazione – Standardizza la configurazione tramite GPO/Intune con script di verifica periodici (ad es. confronto tra netsh winhttp show proxy e stato atteso).

Sintesi operativa: l’errore 504 era causato dall’inoltro della richiesta WS‑Man attraverso un proxy che non gestiva correttamente il traffico verso la porta 5985. Escludendo il collector dal proxy (bypass di WinHTTP) e riavviando WinRM, la subscription è stata creata con successo e il forwarding ha ripreso a funzionare.

Appendice – codici e riferimenti utili

Codice errore: 2150859023 (hex 0x8033810F) – “The WinRM client received an HTTP status code of 504 from the remote WS‑Management service”.
Porte: 5985 (HTTP), 5986 (HTTPS).
Log rilevanti:
- Microsoft‑Windows‑Eventlog‑ForwardingPlugin/Operational – stato delle subscription lato forwarder.
- Microsoft‑Windows‑WinRM/Operational – eventi di connessione e autenticazione WS‑Man.
- Applications and Services Logs > Microsoft > Windows > EventCollector – lato collector.

Checklist rapida da copiare

✅ netsh winhttp show proxy → collector in bypass
✅ netsh winhttp set proxy ... bypass-list="...;WeccollectorSRV"
✅ net stop winrm && net start winrm
✅ winrm id -r:WeccollectorSRV:5985 senza timeout
✅ Evento ID 100 su collector / forwarding ripristinato

Esempi di comandi utili

:: Mostra impostazioni WinHTTP correnti
netsh winhttp show proxy

:: Imposta proxy + bypass (modifica host, porta e domini secondo la tua realtà)
netsh winhttp set proxy proxy-server="proxyserver:8080" bypass-list=";10.;192.168.;172.16.*;WefcollectorSRV"

:: Reset totale delle impostazioni WinHTTP
netsh winhttp reset proxy

:: Riavvio rapido WinRM
net stop winrm && net start winrm

:: Test connessione WS-Man
winrm id -r:WefcollectorSRV:5985

:: Ultimi 10 eventi del plugin WEF
wevtutil qe Microsoft-Windows-Eventlog-ForwardingPlugin/Operational /c:10 /rd:true /f:text

Seguendo questa procedura, trasformi un errore sfuggente (504) in un’interruzione ben compresa e facilmente prevenibile con policy e automazioni. Il punto chiave è ricordare che WEF dipende da WinHTTP: se il collector non è nella bypass list, prima o poi il proxy farà da collo di bottiglia.