Troubleshoot WinRM and PowerShell remoting by checking listeners, ports, firewall rules, authentication, TrustedHosts and service status.
Confirm the WinRM service and listener are configured, then work outward through firewall, authentication and TrustedHosts checks in order.
Test with Test-WSMan against the target's IP before assuming the problem is authentication rather than basic connectivity.
What to check first
WinRM failures almost always fall into one of three buckets: the service isn't listening, the network path is blocked, or the credential doesn't have permission on the target. Work through them in that order instead of jumping straight to authentication — a closed port produces the same generic "cannot connect" error as a bad password, and diagnosing them in the wrong order wastes time.
Confirm the WinRM service is running
On the target server, check the service state directly:
Get-Service WinRMIf it's stopped, start it and set it to automatic — but prefer winrm quickconfig over manually starting the service, since it also creates the listener and firewall exception in one step:
winrm quickconfig -forceVerify a listener exists and is bound correctly
A running service with no listener still fails every connection attempt. List the configured listeners and confirm one exists for the transport you're using (HTTP on 5985, HTTPS on 5986):
winrm enumerate winrm/config/listenerCheck that the listener's Address is * (all addresses) rather than bound to a specific IP that no longer matches the server, which happens after a NIC change or a server migrated between subnets.
Check the Windows Firewall rules
Confirm the built-in WinRM firewall rules are enabled and scoped correctly for the active network profile:
Get-NetFirewallRule -DisplayGroup "Windows Remote Management" | Select-Object DisplayName, Enabled, ProfileA common cause: the server's network adapter is on the Public profile instead of Domain or Private (frequent after a temporary NIC reset or a new vNIC on a VM), and the default WinRM rule only allows the Domain/Private profiles.
Test raw connectivity before authentication
Isolate network-layer failures from authentication failures by testing the port first:
Test-NetConnection -ComputerName SERVERNAME -Port 5985If that succeeds, move to Test-WSMan, which exercises the actual WinRM protocol without requiring full remoting authentication:
Test-WSMan -ComputerName SERVERNAMEIf Test-NetConnection fails but Test-WSMan was never reached, the issue is firewall or network routing — not WinRM configuration. Don't touch authentication settings yet.
Check authentication and TrustedHosts for non-domain targets
For workgroup machines or connections across untrusted domains, Kerberos isn't available and WinRM falls back to NTLM, which requires the target to be explicitly trusted:
Get-Item WSMan:\localhost\Client\TrustedHosts
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "SERVERNAME" -ForceUsing * in TrustedHosts works but disables an important safety check — scope it to specific hostnames or IP ranges where possible, especially on machines with elevated credentials cached.
Check for the double-hop problem
If a command works interactively over WinRM but fails only when that session tries to reach a third machine (e.g., a script on the remote server that needs to read a file share), you're hitting the double-hop limitation — the remote session can't forward your credential a second time. Confirm this is the cause by checking if the failing operation works when run locally on the target instead of remotely. Fix it with CredSSP authentication (weakens security — use only where necessary) or, preferably, Kerberos resource-based constrained delegation.
Useful commands
Run these from an elevated PowerShell session, replacing SERVERNAME with your target.
Get-Service WinRM
winrm enumerate winrm/config/listener
Test-NetConnection -ComputerName SERVERNAME -Port 5985
Test-WSMan -ComputerName SERVERNAME
Get-NetFirewallRule -DisplayGroup "Windows Remote Management" | Select-Object DisplayName, Enabled, Profile
Enter-PSSession -ComputerName SERVERNAME -Credential (Get-Credential)What should be captured for escalation?
Capture the exact error text (WinRM errors include a numeric code, e.g. 0x80090311 for "no authority could be contacted" — a name resolution issue, not a credential one), the output of Test-WSMan against the target, whether the target is domain-joined or workgroup, and the current TrustedHosts value on the client. This is usually enough for a second engineer to reproduce the failure without repeating the discovery steps above.