Comment réparer WinRM et PowerShell Remoting

Ce guide montre comment réparer WinRM et PowerShell Remoting à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. WinRM écoute typiquement en HTTP 5985 ou HTTPS 5986 ; le listener et le firewall doivent être cohérents.

Étapes à suivre

1. 1

   Identifier les critères déterminants

   WinRM écoute typiquement en HTTP 5985 ou HTTPS 5986 ; le listener et le firewall doivent être cohérents.

2. 2

   Recouper le contexte technique

   Dans un domaine, Kerberos est préférable ; TrustedHosts est surtout un contournement pour certains scénarios workgroup et ne chiffre pas à lui seul le trafic.

3. 3

   Chaîne WinRM

   Tester résolution, port, WSMan puis authentification dans cet ordre.

4. 4

   Écarter les erreurs de diagnostic

   Enable-PSRemoting modifie listener/firewall ; ne pas l’exécuter comme simple test sans connaître la baseline.

5. 5

   Valider le résultat

   Test-WSMan et une session distante fonctionnent avec le mécanisme d’authentification prévu. Aucune ouverture de TrustedHosts ou règle firewall plus large que nécessaire ne reste après correction.

Commandes utiles

À retenir

• Test-WSMan vérifie WSMan sans exécuter une session PowerShell complète.
• Une erreur Kerberos peut venir du nom utilisé/SPN/temps même si le port répond.
• Aucune ouverture de TrustedHosts ou règle firewall plus large que nécessaire ne reste après correction.

Test-NetConnection serveur -Port 5985
Test-WSMan serveur
Enter-PSSession serveur