Troubleshoot PowerShell Remoting and WinRM failures by checking listeners, ports, firewall rules, authentication and service health.
Start with Check the WinRM service and work through the six diagnostic checks in order.
Record results before changing configuration and validate the original symptom after each controlled change.
Quick checks
Start with the basic checks in this runbook before moving to deeper troubleshooting.
- Confirm the affected service or component is available.
- Check recent configuration or connectivity changes.
- Run the relevant commands and compare the result with the expected state.
Check the WinRM service
Confirm the Windows Remote Management service is running on the target server.
Check the listener
Verify an HTTP or HTTPS listener exists on the expected interface and port.
Test TCP connectivity
Test TCP 5985 for HTTP or 5986 for HTTPS from the client network.
Check Windows Firewall
Review Windows Remote Management firewall rules and the active network profile.
Check authentication
Validate Kerberos, domain trust or an approved HTTPS/trusted-host configuration for the environment.
Test PowerShell remoting
Run Test-WSMan and a PowerShell remoting test and use the exact error to guide the next step.
Useful commands
Run these checks from an appropriate administrative session and replace example values with your environment.
WinRM service
Get-Service WinRMWinRM test
Test-WSMan <server>Quick troubleshooting path
Use this sequence to isolate the failing dependency before changing production configuration.
- Check the WinRM service → Confirm the Windows Remote Management service is running on the target server.
- Check the listener → Verify an HTTP or HTTPS listener exists on the expected interface and port.
- Test TCP connectivity → Test TCP 5985 for HTTP or 5986 for HTTPS from the client network.
- Check Windows Firewall → Review Windows Remote Management firewall rules and the active network profile.
- Check authentication → Validate Kerberos, domain trust or an approved HTTPS/trusted-host configuration for the environment.
- Test PowerShell remoting → Run Test-WSMan and a PowerShell remoting test and use the exact error to guide the next step.
What good troubleshooting looks like
Good infrastructure troubleshooting is evidence-driven. Capture the original state, test the dependency that can prove or disprove your hypothesis, make the smallest safe change and repeat the original test.
Symptom → hypothesis → direct test → result → controlled change → validation → documentation