This BAOI guide provides a structured method for how to repair winrm and powershell remoting without multiplying unnecessary changes.
Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.
Étapes à suivre
1
Set perimeter
Identify the equipment, service, affected users and start time.
2
Collect Elements
Record the exact messages, logs and useful settings.
3
Test methodically
Start with the basic dependencies before the application components.
4
Apply correction
Change only the identified parameter or component.
5
Validate
Rewrite the full scenario and document the result.
Commands utiles
Test-SysMan server
winrm enumerate winrm/config/listener
À retenir
Keep the initial values for a backwards.
Avoid multiple simultaneous changes.
Compare with a functional configuration when possible.
Technical deep dive
WinRM / PowerShell Remoting: listener, authentication and firewall
Technical checkpoints
WinRM typically listens on HTTP 5985 or HTTPS 5986; listener and firewall must be coherent.
Test-WSMan validates WSMan without starting a full PowerShell session.
WinRM chain
Test resolution, port, WSMan then authentication in that order.
Test-NetConnection server -Port 5985
Test-WSMan server
Enter-PSSession server
Topic-specific pitfalls
Enable-PSRemoting changes listener/firewall; do not run it as a simple test without knowing the baseline.
A Kerberos error can come from hostname/SPN/time even when the port responds.
How to validate
Test-WSMan and a remote session work with the intended authentication mechanism.
No broader-than-needed TrustedHosts or firewall exception remains after remediation.
Operational context
WinRM and PowerShell Remoting failures should be separated into listener, service, firewall, authentication and name-resolution problems. Verify the transport from both ends before changing TrustedHosts or weakening authentication controls.
Step-by-step checks
Confirm the WinRM service is running and enumerate configured listeners, including transport, address and certificate binding where HTTPS is used.
From the management host, test DNS resolution, TCP reachability and Test-WSMan against the exact hostname that administrators normally use.
Inspect PowerShell session configurations and the effective Windows Firewall rules for the active network profile.
Review authentication context, SPN/Kerberos behavior and any workgroup or cross-domain constraints before considering TrustedHosts.
Useful verification commands
Use commands only on systems you administer and capture the read-only output before making a configuration change.
Test-WSMan and a controlled remote PowerShell session must succeed with the intended hostname and authentication method without broadening trust beyond the administrative requirement.
Evidence to keep
Keep source and destination hostnames, listener configuration, service state, firewall profile/rules, Test-WSMan output and the exact authentication error from the failed session.
Frequently asked question
Should I add the server to TrustedHosts immediately?
No. In a domain, Kerberos and correct DNS/SPN identity should normally be preferred. TrustedHosts is mainly a constrained exception for scenarios where mutual Kerberos identity cannot be used.