Windows Event Forwarding : erreur WinRM 504/2150859023 due au proxy WinHTTP — diagnostic, correction et prévention

Un parc Windows cessait soudainement de remonter ses journaux via Windows Event Forwarding (WEF). Le client signalait l’erreur WinRM 2150859023 / HTTP 504 Gateway Timeout. Voici le diagnostic complet, la résolution immédiate (bypass proxy WinHTTP) et les actions préventives.

Sommaire

Incident : échec du transfert d’événements (Event Log Forwarding)

Les postes et serveurs sources n’arrivaient plus à contacter le gestionnaire d’abonnements du collecteur WEC. Le journal Microsoft‑Windows‑Eventlog‑ForwardingPlugin/Operational côté client mentionnait des connexions échouées vers l’URL WS‑Man du collecteur :

Adresse ciblée : http://WefcollectorSRV:5985/wsman/SubscriptionManager/WEC
Code d’erreur : 2150859023 (WinRM retourne HTTP 504 Gateway Timeout)
Conséquence : aucun événement n’était collecté sur le serveur d’agrégation.

Symptômes observés

Les abonnements WEF restent à l’état Inactive côté source.
Le collecteur ne reçoit plus ni flux ni battement d’activité (heartbeat).
Rien d’anormal visible sur les services locaux (WinRM et WECSVC lancés, code de sortie 0).

Analyse courte

La séquence de tests a rapidement orienté vers la couche réseau/proxy : du point de vue du système, les services fonctionnaient, la configuration d’abonnement pointait bien sur WefcollectorSRV, les journaux locaux n’étaient pas saturés, et le code HTTP 504 indiquait un « temps de traversée » dépassé vers le collecteur. La cause s’est avérée être un proxy WinHTTP non contourné.

Architecture et points clefs à connaître

Pour comprendre le problème, il est utile de rappeler comment fonctionne WEF :

Modèle push : les clients sources contactent le collecteur via WinRM (HTTP 5985 ou HTTPS 5986) et poussent leurs événements selon la stratégie d’abonnement.
WinHTTP vs WinINET : les services Windows (dont WinRM) utilisent WinHTTP, qui dispose de ses propres paramètres de proxy (gérés par netsh winhttp). Les réglages proxy du navigateur (WinINET) ne s’appliquent pas aux services.
WEC : le service Windows Event Collector héberge les abonnements, authentifie les clients (Kerberos/NTLM/Certificat) et stocke/route les événements.

Conséquence : un proxy configuré au niveau WinHTTP s’applique aussi aux connexions WinRM. S’il n’existe pas de règle d’exclusion (bypass) pour le collecteur interne, la requête peut être envoyée au proxy au lieu d’aller directement au serveur WEC, d’où un 504 Gateway Timeout lorsque le proxy bloque ou temporise la session WS‑Man.

Diagnostic détaillé

Services locaux : WinRM et WECSVC actifs, code de sortie 0 → faibles chances que la panne soit purement locale.
Paramètres d’abonnement : la valeur du registre HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager cible bien WefcollectorSRV.
Capacité journaux : tailles et rétention OK (wevtutil gl security) → pas de blocage par saturation locale.
Erreur 504 : caractéristique d’une requête WS‑Man qui ne traverse pas correctement une infrastructure intermédiaire (proxy/PAC/FW/LB).
Vérification proxy WinHTTP : netsh winhttp show proxy révélait un proxy déclaré sans bypass pour WefcollectorSRV.

Commandes d’observation utiles

REM Montrer la configuration proxy WinHTTP
netsh winhttp show proxy

REM Tester l'ID WinRM (côté client) vers le collecteur
winrm id -r:[http://WefcollectorSRV:5985](http://WefcollectorSRV:5985)

REM Voir les listeners WinRM locaux
winrm e winrm/config/listener

REM Vérifier la connectivité réseau brute
ping WefcollectorSRV
Test-NetConnection WefcollectorSRV -Port 5985

REM Sanité journaux et taille
wevtutil gl security
wevtutil el | findstr /i ForwardingPlugin
wevtutil qe "Microsoft-Windows-Eventlog-ForwardingPlugin/Operational" /c:5 /rd:true /f:text

Cause identifiée

Le serveur WefcollectorSRV n’était pas présent dans la liste d’exclusion du proxy WinHTTP. Les requêtes WS‑Man à destination de http://WefcollectorSRV:5985 passaient donc par le proxy, qui les temporairement refusait ou les laissait expirer. D’où le HTTP 504 et le code d’erreur 2150859023 côté client WEF.

Rappel : dans une liste d’exclusion WinHTTP, <local> ne couvre que les noms sans point. Si vos sources appellent le collecteur en FQDN (ex. WefcollectorSRV.contoso.local), ajoutez explicitement ce FQDN dans le bypass.

Solution mise en place

Ajout du collecteur à la liste de contournement du proxy WinHTTP + redémarrage de WinRM.

netsh winhttp show proxy
netsh winhttp set proxy proxy-server="proxyserver:proxyport" `
    bypass-list="&lt;local&gt;;10.*;192.168.*;172.16.*;WefcollectorSRV"
net stop winrm
net start winrm

Résultat : « The subscription was created successfully » ; la collecte d’événements a repris immédiatement.

Variantes utiles

REM Ajouter un FQDN spécifique au bypass (recommandé si vos sources utilisent le FQDN)
netsh winhttp set proxy proxy-server="proxyserver:proxyport" `
    bypass-list="<local>;10.*;192.168.*;172.16.*;WefcollectorSRV;WefcollectorSRV.contoso.local"

REM Importer le proxy du profil (attention : WinINET ≠ WinHTTP, à utiliser avec discernement)
netsh winhttp import proxy source=ie

REM Supprimer tout proxy WinHTTP (en environnement purement interne)
netsh winhttp reset proxy

REM Redémarrer proprement le service WinRM
sc stop winrm & sc start winrm

Vérifications après remédiation

Vérification	Commande / Action	Objectif
Tester l’accès direct sans proxy	`winrm id -r:http://WefcollectorSRV:5985`	Confirmer la connectivité WS‑Man après modification
GPO pour WinRM	Configuration ordinateur → Modèles d’administration → Composants Windows → WinRM	S’assurer que les clients autorisent l’hôte de collecte
Pare‑feu Windows	`netsh advfirewall firewall show rule name="Windows Remote Management (HTTP-In)"`	Règles entrantes sur le collecteur et les clients
Latence et MTU	`ping WefcollectorSRV -f -l 1472`	Détecter d’éventuelles fragmentations/limitations réseau
Surveillance post‑remédiation	Activer la subscription en mode « MinLatency »	Vérifier qu’aucune nouvelle perte de connexion ne survient

Contrôles complémentaires recommandés

Zone	Commande	À quoi s’attendre
Listeners WinRM	`winrm e winrm/config/listener`	Présence d’un listener HTTP sur 5985 (ou HTTPS 5986 selon votre design)
Résolution DNS	`nslookup WefcollectorSRV` ou `Resolve-DnsName`	IP interne attendue (pas d’IP du proxy)
Latence socket	`Test-NetConnection WefcollectorSRV -Port 5985`	Port ouvert, RTT cohérent (< 100 ms en LAN)
Abonnement côté collecteur	`wecutil gs <NomAbonnement>`	État Active, compte d’ordinateurs sources attendu
Journal du plugin WEF	`wevtutil qe "Microsoft-Windows-Eventlog-ForwardingPlugin/Operational" /rd:true /c:20`	Absence d’erreurs récurrentes, événements de reprise

Automatisation : audit et correction en masse

Pour fiabiliser l’environnement, industrialisez un contrôle de conformité du bypass WinHTTP sur l’ensemble du parc. Ci‑dessous un exemple de script PowerShell idempotent exécutable en Startup Script via GPO ou outil d’orchestration :

# Paramètres
$CollectorShort = "WefcollectorSRV"
$CollectorFqdn  = "WefcollectorSRV.contoso.local"
$DefaultBypass  = "<local>;10.*;192.168.*;172.16.*"

# Lecture du proxy WinHTTP actuel

$proxyShow = (netsh winhttp show proxy) -join "`n"
$needsSet  = $true
$targetByp = "$DefaultBypass;$CollectorShort;$CollectorFqdn"

if ($proxyShow -match "Direct access (no proxy server)") {

# Aucun proxy : rien à faire

$needsSet = $false
} elseif ($proxyShow -match "Bypass List\s*:\s*(.+)") {
$currentByp = ($Matches[1]).Trim()

# Normaliser et comparer

$norm = ($currentByp -split ';' | ForEach-Object { $*.Trim().ToLower() }) -join ';'
$want = ($targetByp  -split ';' | ForEach-Object { $*.Trim().ToLower() }) -join ';'
if ($norm -like "*$($CollectorShort.ToLower())*" -and $norm -like "*$($CollectorFqdn.ToLower())*") {
$needsSet = $false
}
}

if ($needsSet) {
Write-Host "Mise à jour du proxy WinHTTP (bypass)..."
netsh winhttp set proxy proxy-server="proxyserver:proxyport" bypass-list="$targetByp" | Out-Null

# Recyclage WinRM pour prise en compte immédiate

sc stop winrm | Out-Null
sc start winrm | Out-Null
}

# Test de santé après correction

$ok = $false
try {
$id = & winrm id -r:"http://$CollectorShort:5985" 2>&1
$ok = $LASTEXITCODE -eq 0 -and ($id -match "ProtocolVersion")
} catch { $ok = $false }

if (-not $ok) {
Write-Warning "Test WinRM ID KO vers $CollectorShort. Vérifier pare-feu/DNS/route."
} else {
Write-Host "WinRM ID OK vers $CollectorShort. Flux WEF attendu."
}

Astuce : si vous pilotez WinRM en HTTPS (5986), testez winrm id -r:https://WefcollectorSRV:5986 -skipCAcheck -skipCNcheck uniquement en phase de diagnostic. En production, utilisez des certificats valides et n’ignorez pas les contrôles.

Surveillance continue et seuils d’alerte

Mode d’abonnement : pour l’observabilité, configurez certains abonnements en MinLatency (latence minimale) afin de détecter rapidement un ralentissement anormal.
Alertes : déclenchez une alerte si aucun événement n’est reçu d’un client depuis X minutes/heures (en fonction de votre cadence moyenne).
Capacité : surveillez la taille des logs sur le collecteur et la volumétrie d’événements par source.
Qualité réseau : suivez le RTT vers le collecteur (métriques ICMP/TCP 5985) et les taux d’erreur WinRM.

# Exemple : compter les événements reçus les 15 dernières minutes (à adapter/filtrer)
Get-WinEvent -LogName "ForwardedEvents" -MaxEvents 10000 |
  Where-Object { $_.TimeCreated -gt (Get-Date).AddMinutes(-15) } |
  Measure-Object | Select-Object -ExpandProperty Count

Bonnes pratiques pour éviter la récidive

Définir un standard proxy WinHTTP : documenter le périmètre de bypass (plages privées RFC1918, FQDN des services internes comme WEC, noms courts et FQDN).
Stabiliser la résolution de nom : utiliser systématiquement le FQDN et l’ajouter explicitement au bypass.
Séparer trafic interne/externe : ne proxifiez pas le trafic WEF interne. Si un passage proxy est imposé, publier des règles spécifiques (allowlist) et vérifier les timeouts.
WinRM HTTPS : pour des traversées de zones à risque, privilégiez 5986 + certificats valides. Ajuster les firewalls en conséquence.
Automatiser les contrôles : GPO startup script ou outil de gestion de configuration pour valider en continu le bypass WinHTTP sur tous les hôtes.
Documentation & runbook : consigner l’URL WS‑Man, le port, les règles FW, la stratégie d’abonnement et les procédures de rollback.

Runbook opérationnel (pas à pas)

Confirmer l’erreur : lire Eventlog‑ForwardingPlugin/Operational et noter l’URL cible + code.
Tester WinRM direct : winrm id -r:http://WefcollectorSRV:5985.
Inspecter WinHTTP : netsh winhttp show proxy → si un proxy est défini, vérifier le bypass.
Corriger le bypass : ajouter WefcollectorSRV et WefcollectorSRV.fqdn.
Redémarrer WinRM : net stop winrm && net start winrm.
Valider : relancer winrm id et contrôler la reprise des événements dans ForwardedEvents.
Surveiller : passer l’abonnement critique en MinLatency pour 24–48 h.

FAQ rapide

Que signifie le code 2150859023 / HTTP 504 côté WinRM ?

C’est un échec de transaction WS‑Man par dépassement de délai (Gateway Timeout), typique d’un intermédiaire qui ne répond pas (proxy/firewall/LB) — le service local WinRM n’est pas nécessairement en cause. Pourquoi modifier le proxy WinHTTP et pas le proxy du navigateur ?

Les services (WinRM, BITS, etc.) s’appuient sur WinHTTP, indépendant de WinINET (navigateur). Les réglages du navigateur n’affectent pas WinRM. Le jeton <local> suffit‑il dans la liste d’exclusion ?

Non, il ne couvre que les hôtes sans point. Si vous utilisez un FQDN, ajoutez‑le explicitement au bypass. Faut‑il forcer HTTPS (5986) pour WEF ?

En interne, HTTP peut suffire si le réseau est de confiance. Pour des zones moins maîtrisées, préférez HTTPS + certificats valides (Kerberos ou certificats, selon vos contraintes). Comment déployer la correction à grande échelle ?

Via GPO (script de démarrage), solution d’orchestration, ou gestion de configuration. Évitez de pousser la valeur binaire WinHttpSettings en registre ; utilisez netsh winhttp par script.

Annexes

Checklist d’audit express

Proxy WinHTTP défini ? netsh winhttp show proxy
Bypass contient le nom court et le FQDN du collecteur ?
Résolution DNS correcte du collecteur ?
Port 5985/5986 accessible ? Test-NetConnection
Listeners WinRM présents ? winrm e winrm/config/listener
Abonnement Active côté WEC ? wecutil gs

Modèle de communication RCA (post‑mortem)

Rubrique	Contenu
Résumé	Perte de collecte WEF causée par l’absence de bypass du collecteur dans le proxy WinHTTP.
Impact	Arrêt complet de la remontée d’événements sur X sources pendant Y heures/jours.
Cause racine	Changement de configuration proxy non aligné avec la cartographie des services internes.
Mesures correctives	Ajout du collecteur (nom court + FQDN) au bypass, redémarrage WinRM, validation.
Actions préventives	Standard de bypass WinHTTP, tests automatiques `winrm id`, surveillance MinLatency, runbook documenté.

Bloc d’exclusion recommandé (exemple)

&lt;local&gt;;10.*;172.16.*;172.17.*;172.18.*;172.19.*;172.20.*;192.168.*;
WefcollectorSRV;WefcollectorSRV.contoso.local

Rappels sécurité

Ne placez pas * dans le bypass (contourne tout le proxy).
Avec HTTPS, n’utilisez pas -skipCACheck/-skipCNCheck en production.
Journalisez les changements de proxy (netsh) dans un fichier ou un canal SIEM.

Conclusion

Le couple WEF + WinRM est robuste, mais dépend de la configuration WinHTTP pour sortir du poste. Dans cet incident, l’absence d’exclusion du collecteur a détourné le trafic vers un proxy, provoquant des HTTP 504. L’ajout de WefcollectorSRV au bypass et le recyclage de WinRM ont rétabli la collecte en quelques secondes. En institutionnalisant un standard de bypass, des tests rapides (winrm id) et un monitoring MinLatency, vous neutralisez durablement ce type de panne.

Annexe : mémo de commandes

:: Montrer/poser/réinitialiser le proxy WinHTTP
netsh winhttp show proxy
netsh winhttp set proxy proxy-server="proxy:port" bypass-list="<local>;10.*;192.168.*;172.16.*;WefcollectorSRV;WefcollectorSRV.contoso.local"
netsh winhttp reset proxy

:: Services
sc query winrm
net stop winrm & net start winrm

:: Test WS-Man
winrm id -r:[http://WefcollectorSRV:5985](http://WefcollectorSRV:5985)
winrm e winrm/config/listener
winrm get winrm/config

:: Collecteur
wecutil gs "NomAbonnement"
wecutil qc

:: Journaux
wevtutil el
wevtutil gl security
wevtutil qe "Microsoft-Windows-Eventlog-ForwardingPlugin/Operational" /rd:true /c:20 /f:text

:: Réseau
ping WefcollectorSRV -f -l 1472
Test-NetConnection WefcollectorSRV -Port 5985