Windows Event Forwarding Source‑Initiated: come risolvere l’errore WinRM 105 “HTTP URL non disponibile” su Windows Server 2019 e Windows 10

Guida completa alla risoluzione dell’errore WinRM 105 in un ambiente Windows Event Forwarding (WEF) con subscription di tipo Source‑Initiated: dalla diagnosi alla correzione, con verifiche puntuali e consigli di hardening.

Indice

Scenario e sintomi

In un laboratorio AD DC46.com è stato configurato Windows Server 2019 come Forwarder (sorgente) e un Windows 10 come Collector. Dopo aver:

abilitato WinRM su entrambe le macchine,
creato sul Collector una subscription Source‑Initiated che raccoglie solo il Security log,
aggiunto il computer Forwarder all’elenco degli host di origine,
configurato sul Forwarder il Target Subscription Manager con:
http://DESKTOP-0W48R8S.DC46.com:5985/wsman/SubscriptionManager/WEC,Refresh=10

si osserva sul Forwarder l’evento 105 in WinRM con messaggio (tradotto): “Il client WinRM ha inviato una richiesta a un server HTTP e ha ricevuto una risposta che indica che l’URL HTTP richiesto non è disponibile…”. Risultato: nessun evento compare nel canale Forwarded Events del Collector.

Come funziona WEF in modalità source‑initiated

In WEF esistono due modelli:

Collector‑Initiated: il Collector contatta a intervalli definiti un set noto di computer sorgente e pulla gli eventi.
Source‑Initiated: i computer sorgente (Forwarder) “aprono la strada” verso il Collector, che pubblica una subscription. I Forwarder sanno dove inviare gli eventi grazie al Target Subscription Manager (TSM) configurato con un URL WS‑Man.

Nella modalità source‑initiated il Forwarder stabilisce una sessione WinRM verso il Collector, invoca l’endpoint /wsman/SubscriptionManager/WEC e pubblica gli eventi selezionati dalla subscription. Se l’URL è errato, il listener WinRM non esiste, c’è un proxy di mezzo o il binding HTTP non corrisponde, WinRM segnala l’evento 105.

Perché appare l’evento WinRM 105 “HTTP URL non disponibile”

Le cause tipiche sono poche e molto concrete:

Listener WinRM assente o con URLPrefix diverso da wsman sul Collector: la richiesta arriva ma l’endpoint richiesto non esiste.
Proxy WinHTTP o ispezione HTTP intercetta la chiamata 5985 e risponde con 404 Not Found o 501 Not Implemented.
DNS/Host header puntano all’host sbagliato (FQDN risolto verso un IP diverso dal Collector).
Firewall/NAT loopback blocca o redirige la sessione WS‑Man.
IIS o altre applicazioni HTTP occupano binding o registrazioni URL con HTTP.SYS, rendendo l’endpoint WEC non raggiungibile o non corrispondente.

Prerequisiti e impostazioni consigliate

Entrambi i computer sono nel dominio DC46.com e risolvono correttamente il nome DESKTOP-0W48R8S.DC46.com verso l’IP del Collector (verifica con nslookup e ping).
Ora sincronizzata (Kerberos tollera solo piccoli scarti) e canali 5985/5986 raggiungibili.
Il servizio Windows Remote Management (WS‑Management) è in Running sia su Collector sia su Forwarder.
Il servizio Windows Event Collector (WecSvc) è inizializzato sul Collector (wecutil qc).

Configurazione di base del Collector su Windows 10

Preparazione essenziale (da eseguire una sola volta):

# Esegui come amministratore sul Collector (Windows 10)
wecutil qc
winrm quickconfig -q
Facoltativo ma utile alla diagnosi
wecutil es

Creazione rapida della subscription Source‑Initiated (GUI):

Apri Event Viewer → Subscriptions → Create Subscription….
Tipo di subscription: Source‑initiated.
Events to collect: canale Security con i filtri desiderati (XPath o XML Query).
Source computers: aggiungi OU/gruppi o il singolo computer Forwarder.
Protocol: WS‑Man su HTTP (per test in lab) o HTTPS (consigliato in produzione).

Configurazione del Forwarder su Windows Server 2019

Sul Forwarder:

# Abilita WinRM
winrm quickconfig -q

Verifica che non ci siano proxy WinHTTP

netsh winhttp show proxy

(Se serve) Azzeramento proxy WinHTTP

netsh winhttp reset proxy

Imposta il Target Subscription Manager (via registro o GPO).

Verifica la chiave:

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\EventCollector\SubscriptionManagers"

La voce deve contenere una riga simile a:

http://DESKTOP-0W48R8S.DC46.com:5985/wsman/SubscriptionManager/WEC,Refresh=10

Procedura di troubleshooting passo‑passo

La tabella seguente riassume le azioni risolutive. Subito dopo trovi i dettagli con esempi di comandi e output atteso.

Passaggio	Azione consigliata	Scopo
Verificare la listener WinRM	`winrm enumerate winrm/config/listener` deve mostrare un listener HTTP (5985) con URLPrefix=wsman. In assenza: `winrm quickconfig -q`.	Assicura che WS‑Man risponda all’endpoint corretto.
Controllare binding HTTP in IIS (solo se IIS è presente)	In IIS Manager → Default Web Site → Bindings… aggiungi o correggi un binding HTTP con Host name vuoto e IP All Unassigned. Non usare 5985.	Evita collisioni o risposte 404/501 se HTTP.SYS instrada alla web app sbagliata.
Aprire il traffico di rete	Consenti 5985 (HTTP) e/o 5986 (HTTPS) in ingresso su Collector e in uscita dal Forwarder. Disabilita NAT loopback/transparent proxy lungo il percorso.	Impedisce blocchi o dirottamenti della sessione WS‑Man.
Eliminare eventuali proxy WinHTTP	`netsh winhttp show proxy`. Se c’è un proxy: `netsh winhttp reset proxy`.	Il traffico WEF deve raggiungere direttamente il Collector.
Convalidare i permessi di lettura eventi	Sui computer di origine (Forwarder): aggiungi NETWORK SERVICE o l’account DOMINIO<Collector$> al gruppo locale Event Log Readers.	Abilita la lettura del canale Security da parte del servizio che inoltra gli eventi.
Aggiornare criteri di gruppo	`gpupdate /force` su Collector e Forwarder dopo ogni modifica.	Propaga le impostazioni WinRM/WEF senza riavvio.
Eseguire un test WS‑Man	Dal Forwarder: `winrm id -r:DESKTOP-0W48R8S.DC46.com` oppure PowerShell `Test-WSMan DESKTOP-0W48R8S.DC46.com`.	Conferma negoziazione WS‑Man e reachability.
Analizzare il traffico	Con Wireshark o Message Analyzer cerca HTTP 404/501 e reset TCP sulla 5985/5986.	Isola firewall, proxy o URL errato.

Verificare la listener WinRM

winrm enumerate winrm/config/listener

Output atteso (estratto):

Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman

Se non compare nulla o URLPrefix non è wsman, ripristina la configurazione di base:

winrm quickconfig -q

Controllare IIS e registrazioni HTTP.SYS

IIS non deve mai occupare la porta 5985/5986. Se IIS è installato sul Collector, verifica che i binding HTTP usino la porta 80/443 e non ci siano URL reservation che entrano in conflitto con WS‑Man. Puoi elencare le URL reservation correnti con:

netsh http show urlacl

Se trovi reservation sospette verso /wsman o /wsman/SubscriptionManager legate a processi non WinRM, rimuovile con cautela.

Aprire il traffico di rete

Abilita le regole firewall integrate:

# Sul Collector (ingresso)
netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes
Sul Forwarder (uscita)
netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes

In presenza di NAT hairpin, load balancer L7 o proxy trasparenti, escludi l’URL WEC dalle ispezioni: la risposta intermedia spesso genera il 105.

Eliminare eventuali proxy WinHTTP

netsh winhttp show proxy
netsh winhttp reset proxy

Ricorda che il proxy del browser non influisce: conta quello WinHTTP usato dalle API di sistema (WinRM lo usa).

Convalidare i permessi per il Security log

Per inoltrare il canale Security è necessario che l’entità che legge localmente gli eventi sul Forwarder abbia i diritti adeguati. In ambienti source‑initiated bastano due opzioni equivalenti:

aggiungere NETWORK SERVICE al gruppo locale Event Log Readers sul Forwarder;
oppure aggiungere l’account computer del Collector (DC46\DESKTOP-0W48R8S$) allo stesso gruppo sul Forwarder.

Attenzione: aggiungere membri sul Collector non dà a WinRM sul Forwarder la capacità di leggere il Security log di origine. Il controllo accessi avviene sul computer di origine.

Aggiornare i criteri

gpupdate /force

Se il Target Subscription Manager è stato impostato via GPO, controlla che il valore sia presente sul Forwarder in:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\EventCollector\SubscriptionManagers

Eseguire un test WS‑Man end‑to‑end

# Dal Forwarder
winrm id -r:DESKTOP-0W48R8S.DC46.com
oppure (PowerShell)
Test-WSMan -ComputerName DESKTOP-0W48R8S.DC46.com

Se la risposta riporta ProductVendor e ProtocolVersion, il listener risponde. In caso contrario, il problema è di reachability o di autenticazione.

Analizzare il traffico

Acquisisci traffico su 5985/5986. Se vedi HTTP 404/501 provenire da un IP che non è il Collector (ad esempio il proxy aziendale), hai trovato la causa dell’evento 105.

Verifiche rapide sullo stato delle subscription

Sul Collector:

# Elenco subscription registrate
wecutil es

Dettaglio di una subscription (sostituisci )

wecutil gs

Controlla i campi LastError, SourceCount e lo stato di attivazione.

Automazione tramite Criteri di Gruppo

Per eliminare errori di battitura e garantire coerenza:

Computer Configuration → Administrative Templates → Windows Components → Event Forwarding → Configure target Subscription Manager
Valore consigliato in laboratorio (HTTP):
Server=http://DESKTOP-0W48R8S.DC46.com:5985/wsman/SubscriptionManager/WEC,Refresh=10
Computer Configuration → Administrative Templates → Windows Components → Event Forwarding → Allow server-initiated connections

Dopo aver collegato la GPO all’OU dei Forwarder, verifica la presenza del valore in registro e l’assenza di errori nella subscription.

Uso di HTTPS su 5986

In produzione è preferibile TLS. Procedura sintetica:

Emetti un certificato server per il Collector con CN/SAN uguale al FQDN (DESKTOP-0W48R8S.DC46.com) e private key esportabile.
Installa il certificato nel Local Computer → Personal → Certificates del Collector.
Crea il listener HTTPS specificando il thumbprint: # Sul Collector winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="DESKTOP-0W48R8S.DC46.com"; CertificateThumbprint="<THUMBPRINT>"}
Aggiorna il TSM dei Forwarder: Server=https://DESKTOP-0W48R8S.DC46.com:5986/wsman/SubscriptionManager/WEC,Refresh=10

Ricorda di aprire la 5986 e di distribuire le CA intermedie/radice ai Forwarder.

FAQ e note operative

È obbligatorio impostare TrustedHosts? In dominio no: si usa Kerberos. TrustedHosts serve solo per scenari workgroup/NTLM.
Posso usare un alias DNS del Collector? Sì, ma assicurati che l’SPN HTTP/<aliasFQDN> sia valido per quell’host; altrimenti avrai errori di autenticazione.
Perché vedo 105 ma Test-WSMan funziona? Spesso l’endpoint base /wsman risponde, ma il percorso /wsman/SubscriptionManager/WEC viene risolto verso un server diverso (proxy) o non è esposto per via di un listener corrotto.
Quali Event ID sono utili? 100 (Collector: subscription attivata), 102/103 (Forwarder: connessione stabilita/terminata), 105 (Forwarder: URL non valido o listener assente).

Checklist finale

DNS e orario corretti; FQDN del Collector raggiungibile.
Su Collector: wecutil qc e listener WinRM attivo (winrm enumerate winrm/config/listener).
Niente proxy WinHTTP tra Forwarder e Collector (netsh winhttp reset proxy).
Firewall aperto su 5985/5986; nessun NAT loopback/proxy trasparente.
Sui Forwarder: NETWORK SERVICE o Collector$ nel gruppo Event Log Readers per inoltrare il Security log.
TSM corretto sul Forwarder: http(s)://<CollectorFQDN>:5985/5986/wsman/SubscriptionManager/WEC,Refresh=10.
Test-WSMan dal Forwarder → Collector eseguito con successo.
wecutil es/gs sul Collector senza errori in LastError.

Script PowerShell di diagnostica

Questo script raccoglie i check più importanti su Collector e Forwarder. Eseguilo con privilegi elevati (modifica i nomi in base al tuo ambiente).

$Collector = "DESKTOP-0W48R8S.DC46.com"

Write-Host "== Verifica listener WinRM sul Collector =="
Invoke-Command -ComputerName $Collector -ScriptBlock {
winrm enumerate winrm/config/listener
} -ErrorAction SilentlyContinue

Write-Host "`n== Test WS-Man dal Forwarder al Collector =="
try { Test-WSMan -ComputerName $Collector -ErrorAction Stop; "OK" } catch { $_.Exception.Message }

Write-Host "`n== Proxy WinHTTP sul Forwarder =="
netsh winhttp show proxy

Write-Host "`n== TSM sul Forwarder =="
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\EventCollector\SubscriptionManagers"

Write-Host "`n== Regole firewall WinRM (Forwarder) =="
netsh advfirewall firewall show rule name="Windows Remote Management (HTTP-In)"
netsh advfirewall firewall show rule name="Windows Remote Management (HTTPS-In)"

Write-Host "`n== Stato subscription sul Collector =="
Invoke-Command -ComputerName $Collector -ScriptBlock { wecutil es }

Conclusione

Nella stragrande maggioranza dei casi l’evento 105 nasce da un disallineamento tra endpoint richiesto e servizi effettivamente esposti: listener WinRM mancante o alterato, proxy WinHTTP, binding HTTP/URL reservation in conflitto o DNS errato. Applicando i passaggi descritti — in particolare listener WinRM con URLPrefix=wsman, assenza di proxy, porte 5985/5986 aperte e permessi corretti sul Forwarder — l’errore scompare e gli eventi del canale Security iniziano a fluire regolarmente nel log Forwarded Events del Collector.

Appendice: tabella riassuntiva delle azioni

Passaggio	Azione consigliata	Scopo
Listener WinRM	`winrm enumerate winrm/config/listener` → HTTP 5985, URLPrefix=wsman. In assenza: `winrm quickconfig -q`.	Endpoint WS‑Man disponibile.
Binding IIS/HTTP.SYS	Verifica che IIS non usi 5985/5986 e che non ci siano URL reservation in conflitto (`netsh http show urlacl`).	Evita 404/501 per URL non corrispondente.
Rete	5985/5986 aperte; niente NAT loopback/proxy trasparenti.	Raggiungibilità end‑to‑end.
Proxy WinHTTP	`netsh winhttp reset proxy` se configurato.	Traffico diretto al Collector.
Permessi Security log	Su ogni Forwarder: NETWORK SERVICE o Collector$ in Event Log Readers.	Accesso in lettura agli eventi di sicurezza.
GPO	Imposta TSM via GPO e `gpupdate /force`.	Coerenza e zero typo.
Test WS‑Man	`winrm id` / `Test-WSMan` dal Forwarder.	Validazione protocollo.
Trace	Sniff 5985/5986 e verifica codici HTTP.	Isolamento root cause.

Note e raccomandazioni aggiuntive

HTTPS consigliato in produzione: crea certificati per Collector e abilita un listener TLS su 5986 (winrm create ... Transport=HTTPS).
Automazione via GPO: usa i criteri “Configure target Subscription Manager” e “Allow server‑initiated connections”.
Verifica rapida dello stato: sul Collector wecutil es e wecutil gs <NomeSub> per controllare LastError e SourceCount.
Event ID utili: 100 (Collector: subscription attivata), 102/103 (Forwarder: connessione stabilita/terminata), 105 (Forwarder: URL non valido o listener mancante).

Con queste pratiche la tua infrastruttura WEF source‑initiated diventa stabile, sicura e soprattutto debuggable in pochi minuti, anche quando il temuto evento 105 fa capolino nei log.