PowerShell: remoting connection failed
Documentation: Microsoft Learn
Check the remoting transport, target address, authentication and endpoint when a PowerShell remote connection fails.
What it means
The remoting transport could not establish or maintain the connection. Failures may involve WinRM or an SSH-based connection, depending on how the session was created. A connection lost during execution does not prove that the remote operation made no changes.
Likely causes
- The WinRM service is stopped, or it is running with no listener configured
- TCP 5985 or 5986 is blocked by the host firewall or by a network device in between
- The name resolves to a stale address, or does not resolve at all
- Kerberos is unavailable because the target was addressed by IP or is not domain joined, and TrustedHosts does not include it
- The credential is valid but the account is absent from Remote Management Users and from the session configuration permissions
Check
Run these checks before changing anything.
What these checks establish
DNS, TCP and Test-WSMan check different layers. A listener response does not prove this account can open the selected PowerShell endpoint. Port 5985 applies to the usual HTTP WSMan setup, not every remoting configuration.
Fix
Verify the intended host, transport, port and endpoint. Investigate connectivity before authentication when the port is unreachable. If the listener responds but session creation is denied, inspect credentials and endpoint permissions. Configure remoting through the environment’s approved management path; do not treat broad TrustedHosts changes as authentication or as a universal fix.
Verify: Create a session to the intended endpoint with the intended identity and execute a read-only identity or hostname check.
