Fix WinRM 'WSManFault: The client cannot connect to the destination' on Windows

What's happening

You run Enter-PSSession, Invoke-Command, or any WinRM-based tool and hit this:

WSManFault Message: The client cannot connect to the destination specified in the request.
Verify that the service on the destination is running and is accepting requests.

The WS-Management stack throws this as a catch-all. The client sent the request — and got silence back. Four things can cause that: the remote WinRM service isn't running, a firewall dropped the packet on port 5985, the client doesn't trust the remote host, or authentication failed. Each fix is different, so pinpoint the layer first.

Quick diagnostic checklist

Run these three checks before changing anything. They tell you exactly which layer is broken.

# 1. Can you reach the remote machine at all?
Test-Connection -ComputerName REMOTE_HOST -Count 2

# 2. Is port 5985 (WinRM HTTP) open?
Test-NetConnection -ComputerName REMOTE_HOST -Port 5985

# 3. What does WinRM say locally?
winrm id -r:REMOTE_HOST

Test-NetConnection returning TcpTestSucceeded: False means the firewall or the WinRM listener is the culprit. If it's True but WinRM still fails, the problem is TrustedHosts or authentication — the network is fine, the WinRM layer isn't.

Fix 1 — Enable and start WinRM on the remote machine

WinRM ships disabled on most Windows workstations. That's the most common cause of this error. If you have console, RDP, or GPO access to the remote machine, start here.

# Run on the REMOTE machine (elevated PowerShell)
Enable-PSRemoting -Force

# Verify the service is running
Get-Service WinRM

# Check the listener is active
winrm enumerate winrm/config/listener

Enable-PSRemoting does three things at once: starts the WinRM service, creates the HTTP listener on port 5985, and adds the inbound firewall rule. On a machine set to a Public network profile it may refuse to run — add -SkipNetworkProfileCheck to force it:

Enable-PSRemoting -Force -SkipNetworkProfileCheck

Fix 2 — Open the firewall on the remote machine

The service can be running, the listener active — and you're still blocked. Windows Firewall drops inbound traffic on port 5985 unless there's an explicit allow rule. Add one manually:

# On the REMOTE machine
# Allow WinRM HTTP (5985)
New-NetFirewallRule -DisplayName "WinRM HTTP" `
  -Direction Inbound -Protocol TCP -LocalPort 5985 `
  -Action Allow

# If you use HTTPS (5986)
New-NetFirewallRule -DisplayName "WinRM HTTPS" `
  -Direction Inbound -Protocol TCP -LocalPort 5986 `
  -Action Allow

GPO-managed firewalls are trickier. Check what policy is applied with gpresult /h gpo.html, open the HTML report, and search for "Windows Remote Management". If a GPO is blocking port 5985, fix it at the policy level — a local rule won't override it.

Fix 3 — Add the remote host to TrustedHosts on the client

Outside a domain — workgroup, cross-domain, or connecting by IP — WinRM won't even attempt authentication unless the remote machine is listed in TrustedHosts. The handshake fails silently before credentials are ever sent.

# On the CLIENT machine (elevated PowerShell)
# Add a specific host
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "REMOTE_HOST" -Force

# Or add multiple hosts (comma-separated)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "host1,host2,192.168.1.50" -Force

# Or trust everything (lab use only — never in production)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force

# Verify
Get-Item WSMan:\localhost\Client\TrustedHosts

Restart the WinRM service on the client after changing TrustedHosts — the setting doesn't take effect until the service reloads:

Restart-Service WinRM

Fix 4 — Specify credentials explicitly

Kerberos only works within a domain. Cross-domain and workgroup connections need explicit credentials — pass them with Get-Credential:

$cred = Get-Credential  # prompts for username/password

# Test with explicit credentials
Enter-PSSession -ComputerName REMOTE_HOST -Credential $cred

# Or for Invoke-Command
Invoke-Command -ComputerName REMOTE_HOST -Credential $cred -ScriptBlock {
    hostname
    whoami
}

On workgroup machines, prefix the username with the machine name: MACHINENAME\Administrator. Using just Administrator often fails — it defaults to a domain lookup that doesn't exist in a workgroup.

Fix 5 — Check and recreate the WinRM listener

A corrupted or misconfigured listener is rarer, but it happens — especially after Windows updates or a botched winrm quickconfig. Delete the existing listener and recreate it from scratch:

# On the REMOTE machine
# List current listeners
winrm enumerate winrm/config/listener

# Delete all listeners
winrm delete winrm/config/listener?Address=*+Transport=HTTP

# Recreate the default HTTP listener
winrm create winrm/config/listener?Address=*+Transport=HTTP

# Or use the quick config shortcut
winrm quickconfig -q

Fix 6 — Increase WinRM MaxEnvelopeSizekb (large payloads)

Connection works for simple commands like hostname, but fails when you return a large object? The default envelope size is 500 KB — too small for anything complex. Bump it to 8 MB:

# On the REMOTE machine
Set-Item WSMan:\localhost\MaxEnvelopeSizekb -Value 8192

Verify the fix

# From the CLIENT machine
# 1. Test connectivity
Test-NetConnection -ComputerName REMOTE_HOST -Port 5985

# 2. Test WinRM directly
Test-WSMan -ComputerName REMOTE_HOST

# 3. Open an interactive session
Enter-PSSession -ComputerName REMOTE_HOST

# 4. Run a remote command
Invoke-Command -ComputerName REMOTE_HOST -ScriptBlock { hostname; $PSVersionTable.PSVersion }

A successful Test-WSMan looks like this:

wsmid           : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 3.0

If Enter-PSSession drops you into [REMOTE_HOST]: PS C:\Users\...>, you're in. Run exit to close the session cleanly.

Troubleshooting by error detail

• "WinRM cannot complete the operation" — check port 5985/5986: the firewall is blocking. Go to Fix 2.
• "The WinRM client cannot process the request" — mentions TrustedHosts: go to Fix 3.
• "Access is denied": wrong credentials or insufficient permissions. Go to Fix 4.
• "The server certificate on the destination computer has the following errors": HTTPS listener has a bad or self-signed cert. Fix the cert, or switch to HTTP for internal networks.
• "Connecting to remote server failed" — after a GPO push: run gpupdate /force on the remote machine first, then retry.

Domain environment — skip most of this

Both machines on the same domain? WinRM usually works right after Enable-PSRemoting runs on the remote. Skip TrustedHosts entirely — Kerberos handles host trust automatically. The one thing that still bites you is a missing firewall rule on the remote side. Fix 2 handles that.

What to remember

One vague error, four different root causes: service down, firewall blocked, untrusted host, bad credentials. Don't guess. Run Test-NetConnection -ComputerName REMOTE_HOST -Port 5985 first. TcpTestSucceeded: True means the network is fine — move to WinRM config. False means stop and fix the firewall. That single check cuts troubleshooting time in half.