Helpdesk: "From JUMP01, Enter-PSSession -ComputerName FS02 fails with 'Connecting to remote server FS02 failed with the following error message : WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer.' RDP to FS02 works, and Invoke-Command to FS01 from the same box works. A forum post says to run Set-Item WSMan:\localhost\Client\TrustedHosts -Value * here and Enable-PSRemoting -SkipNetworkProfileCheck -Force on every server. Can we do that?"
Not yet. The WinRM cannot complete the operation error isn't an authentication failure. It's the client telling you it never got a WS-Management answer from that name on that port: the name resolved somewhere else, the path or a network firewall dropped TCP 5985, the WinRM service or its listener isn't there, the Windows Firewall rule on the target is off or scoped to the local subnet, the target's network profile flipped to Public, or a proxy got in the way. Microsoft's own copy of the message, from Server Manager's troubleshooting guide, says as much: "Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet." TrustedHosts doesn't touch any of that. Microsoft describes it as an authentication setting: "you should consider the TrustedHosts setting to be the list of hosts for which you wish to suppress the error generated by being unable to verify the server's identity." Work through it as a chain: which command, which name, from where, and what else works? → what does the whole error say? → does the name resolve to the right address, and does TCP 5985 answer? → does WinRM itself answer (Test-WSMan)? → on the target: is the service running and is there a listener on the right addresses? → is the firewall rule on, in which profile, scoped to which addresses, and what profile is the network in? → is a proxy in the path? → once it connects, does the error change to an authentication one? → change one link → prove it from the same client. Resolve-DnsName, Test-NetConnection, Test-WSMan, Get-Service, winrm enumerate winrm/config/listener, Get-WSManInstance, Get-NetConnectionProfile, Get-NetFirewallRule, Get-NetFirewallAddressFilter, netsh winhttp show advproxy, and setspn -Q are the sources for that chain. Set TrustedHosts to * just in case and you've told every PowerShell session on that box to skip server identity checks for every name, while the firewall rule that dropped the packet is still dropping it.
If the same server also fails Kerberos to file shares or SQL with a target name error, The Target Principal Name Is Incorrect covers the DNS, password, and SPN side. If the remoting failure shows up during Hyper-V live migration or remote host management, Hyper-V Live Migration Failed (Event 21502) covers the migration side. This post covers "a Windows client or server that fails Enter-PSSession, Invoke-Command, New-PSSession, Test-WSMan, Windows Admin Center, Server Manager, or Hyper-V Manager to a Windows Server target with 'WinRM cannot complete the operation', with or without the related 'connection to the remote host was refused', 'client cannot connect to the destination', 'cannot process the request', or OperationTimeout errors, and you need a read-first path before you set TrustedHosts to *, open the Public firewall rule to Any, or re-run Enable-PSRemoting everywhere."
TL;DR
- Read the whole error, not the first five words. WinRM cannot complete the operation means no answer came back; "The WinRM client cannot process the request" and "WinRM cannot process the request" mean an answer came back and authentication failed. They have different fixes (Step 2).
-
Prove the path before the service.
Test-NetConnection -ComputerName FS02 -Port 5985tells you whether the name resolves and TCP 5985 answers from this client. A failure there is DNS, routing, or a firewall, not PowerShell (Step 3). -
Test-WSManis the cheapest WinRM probe. Microsoft: it "submits an identification request that determines whether the WinRM service is running on a local or remote computer." Without-Authenticationit's sent anonymously, so it separates a missing listener from missing rights (Step 4). - A running service isn't a listener. Microsoft: "By default, no WinRM listener is configured. Even if the WinRM service is running, WS-Management protocol messages that request data can't be received or sent." A policy-made listener with an empty filter listens on nothing (Step 5).
- The Public profile is the classic cause. Microsoft: Enable-PSRemoting "also creates a firewall rule for public networks that allows remote access only from computers in the same local subnet." A server whose NIC fell to Public answers its own subnet and nobody else (Step 6).
- TrustedHosts is for authentication, not reachability. Microsoft: "The computers in the trusted hosts list aren't authenticated." Use it only for the IP-address or workgroup case it was made for, with a specific entry (Steps 8 and 9).
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | The exact command, the name or IP typed, the client and target, their domain or workgroup, the tool, the network path, and which other targets work | "Remoting is broken on FS02" with no client, no command, and no note that RDP works |
| 2. Error read | The full message is copied and classified as no answer, refused, timeout, name resolution, or authentication | Every remoting error treated as the same problem and fixed with TrustedHosts |
| 3. Name and path | The name resolves to the target's current address, and TCP 5985 (or 5986) answers from this client | A stale A record, a second NIC registered in DNS, or a network firewall between sites |
| 4. WinRM answers |
Test-WSMan returns the identity response from this client |
Port open but no WS-Management answer, or a different service on the port |
| 5. Service and listener | WinRM is Running, a listener exists for the transport you use, and ListeningOn lists the target's addresses | Service disabled on a client OS; a policy listener with an empty IPv4 filter; a changed port |
| 6. Firewall and profile | The WinRM inbound rule is enabled for the profile the NIC is actually in, with a remote address scope that includes this client | NIC in Public, rule scoped to Local subnet, or a policy that disabled the rule |
| 7. Proxy | No WinHTTP or session proxy sends WinRM traffic somewhere it shouldn't go | A machine-wide WinHTTP proxy left from a deployment tool |
| 8. Authentication | Once it connects, the account and method work: Kerberos by name, or NTLM by IP with TrustedHosts or HTTPS and explicit credentials | Error changes to "cannot process the request" and someone sets TrustedHosts to *
|
| 9. Change | One link fixed on the right side (client or target), with the reason written down | Enable-PSRemoting, TrustedHosts *, firewall Any, and a proxy reset all in one go |
| 10. Proof | The same command from the same client works, and still works after a reboot and a policy refresh | Works today, fails after the next reboot when the profile drops to Public again |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| The exact command and what was typed for the computer name | Short name, FQDN, and IP address take different authentication paths, and the error text names which one failed (Steps 2 and 8) |
| The client it ran from, and the target | Most fixes are on one side only: TrustedHosts and proxy are on the client; the service, listener, firewall rule, and profile are on the target |
| Domain, trusted domain, workgroup, or Microsoft Entra-only on each side | Kerberos works only by name inside a domain or across a trust; everything else is NTLM and needs HTTPS or TrustedHosts (Step 8) |
| The tool: PowerShell, Windows Admin Center, Server Manager, Hyper-V Manager, or a monitoring product | They all use WinRM, but each wraps the error in its own text; Server Manager and WAC have their own documented checks (Step 2) |
| The network path: same subnet, another site, VPN, or another VLAN | The Public-profile rule allows only the local subnet, so "works from the server next to it, fails from the jump box" is a clue (Step 6) |
| What else works from the same client to the same target | RDP, ping, SMB, or Invoke-Command to a neighbor narrow it to the WinRM port, rule, or service on this target |
| What changed | A new server build, an in-place upgrade, a NIC or VLAN change, a new GPO, a security baseline, or a deployment tool that set a proxy |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| WinRM cannot complete the operation to one target only | The path, the listener, the firewall rule, or the profile on that target | Steps 3 to 6 |
| The same error from one client to every target | Something on the client: a proxy, DNS, or an outbound firewall | Steps 3 and 7 |
| It works from the same subnet but not from another | The Public-profile rule scoped to the local subnet, or a network firewall | Step 6 |
| It works by FQDN but not by IP address | Not a reachability problem at all; IP means NTLM, which needs TrustedHosts or HTTPS | Step 8 |
| "The connection to the remote host was refused" | Something answered and refused; usually no listener on that port | Step 5 |
| "The WinRM client cannot process the request" or "WinRM cannot process the request" | The connection worked and authentication failed | Step 8 |
| "Access is denied" | The account isn't allowed on the endpoint, or the shell isn't elevated for local WSMan changes | Step 5 |
| It started after an in-place upgrade or a client OS rebuild | Client versions of Windows have the WinRM service disabled by default; a reset profile or trusted hosts list | Steps 5 and 6 |
| Server Manager shows the target as not accessible | Microsoft's table puts this error under "Target computer not accessible" network connection errors | Steps 3 and 6 |
| Hyper-V Manager can't connect to a remote host | Microsoft's Hyper-V page: "To manage remote Hyper-V hosts, enable remote management on both the local computer and the remote host." | Steps 5 and 6 on the host |
| Windows Admin Center can reach some servers but not others | Microsoft's WAC page: test Enter-PSSession from the gateway itself |
Steps 3 to 6 from the gateway |
Step 2: Read the whole error (read-only)
Copy the full text, including the part after the first sentence. In PowerShell, the last error holds it:
# Read-only: the full text of the last remoting error, and its error ID
$Error[0].Exception.Message
$Error[0].FullyQualifiedErrorId
Then match it against Microsoft's messages. They look alike and they point at different links:
| Microsoft's message (excerpt) | Where Microsoft lists it | What it tells you (our reading unless noted) |
|---|---|---|
| "Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer." | Server Manager troubleshooting guide, "Target computer not accessible" | No WS-Management answer came back; name, path, firewall rule, profile, or listener (Steps 3 to 6) |
| "The connection to the remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL." | about_Remote_Troubleshooting, enable remoting sections | The host answered and refused; usually no listener on that port, or remoting disabled (Step 5) |
| "The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests." | about_Remote_Troubleshooting, proxy and firewall policy sections | A proxy in the way, or a policy-made listener with no addresses (Steps 5 and 7) |
| "The WinRM client cannot process the request because the server name cannot be resolved." | Server Manager troubleshooting guide, name resolution error | DNS on the client can't find that name (Step 3) |
| "The WS-Management service cannot complete the operation within the time specified in OperationTimeout." | about_Remote_Troubleshooting, timeout errors | The session connected and a command ran too long; not a connection problem |
| "The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting." | about_Remote_Troubleshooting, IP address and workgroup sections | Connected; NTLM was needed and neither HTTPS nor TrustedHosts was set (Step 8) |
| "Default authentication may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided." | Server Manager troubleshooting guide, Default authentication error | Connected by IP; same fix as the row above, plus -Credential (Step 8) |
| "WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred." | Server Manager troubleshooting guide, Kerberos security error | Connected; Kerberos failed, often an SPN or a name that points at another account (Step 8) |
| "The I/O operation has been aborted because of either a thread exit or an application request." | about_Remote_Troubleshooting, operation failure | WinRM stopped or restarted while the command ran; Microsoft's fix is to start the service and retry |
Two details matter when you compare with forum posts. First, the text PowerShell prints usually says WinRM where Microsoft's Server Manager copy says Windows Remote Management (WinRM), and the WinRM service where it says the Windows Remote Management service; read it as the same no-answer case (our reading). Second, Microsoft's Server Manager table lists the same no-answer text for workgroup targets where TrustedHosts was already set, and gives the cause as "a subnet timeout error occurs if the user has not changed the default subnet restrictions for computers in workgroups". That's the firewall scope (Step 6), not authentication: adding the server to TrustedHosts a second time won't change it.
Step 3: Does the name resolve, and does the port answer? (read-only)
Run these from the client that fails, by the same name the failing command used:
# Read-only, on the client: what the name resolves to from here
Resolve-DnsName -Name FS02.contoso.com -Type A_AAAA
# Read-only, on the client: name resolution, route, and TCP 5985 (WinRM over HTTP) in one test
Test-NetConnection -ComputerName FS02.contoso.com -Port 5985 -InformationLevel Detailed
# Read-only, on the client: TCP 5986 (WinRM over HTTPS), if the command uses -UseSSL
Test-NetConnection -ComputerName FS02.contoso.com -Port 5986
Then, on the target's console or an RDP session (remoting to it is the thing that's broken), read the addresses it actually has:
# Read-only, on the target: its IPv4 addresses, to compare with what DNS returned on the client
Get-NetIPAddress -AddressFamily IPv4 | Select-Object -Property InterfaceAlias, IPAddress, PrefixLength
The ports are Microsoft's defaults: "PowerShell Remoting with WinRM listens on the following ports" HTTP 5985 and HTTPS 5986, and the Invoke-Command reference adds "The default ports are 5985 (WinRM port for HTTP) and 5986 (WinRM port for HTTPS)." Older guidance with port 80 and 443 is from before WinRM 2.0; Microsoft's HTTPS article: "On earlier versions of Windows, WinRM HTTP uses port 80 and WinRM HTTPS uses port 443."
| Finding | What it means (our reading unless noted) |
|---|---|
| DNS returns an address the target doesn't have | A stale record, a second adapter registered in DNS, or the wrong zone; the client is knocking on another box. Fix DNS before anything else |
| The name doesn't resolve at all | Microsoft's "The WinRM client cannot process the request because the server name cannot be resolved." case, or a short name with no matching DNS suffix on this client; try the FQDN |
TcpTestSucceeded : True on 5985 |
The path and something listening on the port are fine from this client; go to Step 4 |
TcpTestSucceeded False, and the same test from a server in the target's own subnet is True |
The target's rule allows only the local subnet (the Public profile case), or a network firewall between the subnets blocks 5985 (Step 6) |
TcpTestSucceeded False from everywhere, RDP to the target works |
Nothing is listening on 5985, or the host firewall drops it for every source (Steps 5 and 6) |
| Ping fails but TCP succeeds | ICMP is blocked; ignore ping and trust the TCP result |
| 5985 fails, 5986 succeeds | The target only has an HTTPS listener; use -UseSSL or add an HTTP listener deliberately (Step 9) |
If the path fails only from one site or VPN, check the network firewall between them for TCP 5985 before you touch the server. Microsoft's Server Manager guide gives the same first suspect for this message: "The network connecting the client and server is offline, or there is a problem with the target server's connection to the network."
Step 4: Does WinRM itself answer? (read-only)
An open port isn't proof that WinRM is behind it. Test-WSMan asks WinRM directly. Microsoft: it "submits an identification request that determines whether the WinRM service is running on a local or remote computer."
# Read-only, on the client: anonymous identify request to the default port
Test-WSMan -ComputerName FS02.contoso.com
# Read-only, on the client: the same request with authentication (also returns the OS version)
Test-WSMan -ComputerName FS02.contoso.com -Authentication Default
# Read-only, on the client: over HTTPS, if the target has an HTTPS listener
Test-WSMan -ComputerName FS02.contoso.com -UseSSL
Microsoft explains why the first one is useful: "If you do not specify the Authentication parameter, the Test-WSMan request is sent to the remote computer anonymously, without using authentication." So the two forms split the problem:
| Finding | What it means (our reading unless noted) |
|---|---|
Anonymous Test-WSMan fails with the same "cannot complete the operation" text |
WinRM isn't reachable from here; Steps 5 and 6 on the target |
Anonymous works, -Authentication Default fails |
Reachability is fine; it's an authentication problem (Step 8) |
Both work, Enter-PSSession still fails |
The session endpoint, permissions, or a session proxy option; Steps 5, 7, and 8 |
Test-WSMan by FQDN works, by IP address fails |
IP means NTLM; see Step 8 |
-UseSSL fails with a certificate error |
The HTTPS listener exists; its certificate doesn't match the name or isn't trusted (Step 9) |
For Windows Admin Center, run the same tests from the gateway, not from your browser's machine: it's the gateway that opens the WinRM session. Microsoft's WAC page says a failed Enter-PSSession from the gateway "might relate to WinRM issues, network connectivity problems, or authorization issues."
Step 5: On the target, is the service running and is there a listener? (read-only)
Read these on the target, from its console or RDP, in an elevated PowerShell window. Microsoft: "You must have administrative rights to view or change settings for the local computer in the WSMan: drive."
# Read-only, on the target: the WinRM service and its startup type
Get-Service -Name WinRM | Select-Object -Property Name, Status, StartType
# Read-only, on the target: the listeners, in Microsoft's form
winrm enumerate winrm/config/listener
# Read-only, on the target: the same listeners through PowerShell, with Source and ListeningOn
Get-WSManInstance winrm/config/listener -Enumerate
# Read-only, on the target: the service settings (auth methods, IPv4Filter, IPv6Filter, ports)
winrm get winrm/config
# Read-only, on the target: does WinRM answer locally, before the network is involved?
Test-WSMan -ComputerName localhost
# Read-only, on the target: the session endpoints and who may use them
Get-PSSessionConfiguration | Format-Table -Property Name, Permission -AutoSize
Microsoft's defaults to compare with: "On server versions of Windows, the WinRM service startup type is Automatic. However, on client versions of Windows, the WinRM service is disabled by default." And remoting is on by default on servers: "Windows Server 2012 and newer releases of Windows Server are enabled for PowerShell remoting by default." So a Windows Server target without a listener had it removed or never got the default, usually by policy, an image, or a hardening script (our reading).
Read the listener output against Microsoft's listener properties:
| Property | Microsoft's default or description | What to look for (our reading unless noted) |
|---|---|---|
| Transport | "The value must be either HTTP or HTTPS. The default is HTTP." | The transport your command uses exists; -UseSSL needs an HTTPS listener |
| Port | "WinRM 2.0: The default HTTP port is 5985." | Anything else needs -Port on the client; Server Manager can't use a changed port |
| Address | "Specifies the address for which this listener is being created." |
* for all addresses, or the right one |
| Enabled | "The default value is True." | False means it exists and does nothing |
| Source | Microsoft's policy example shows Source : GPO
|
A policy owns it; local edits won't stick |
| ListeningOn | "Specifies the IPv4 and IPv6 addresses that the listener uses." | Empty means it listens on nothing |
The empty ListeningOn case is Microsoft's own example. When the listener policy is misconfigured: "A configuration error in the policy results in an empty value for the ListeningOn property." The fix is in the policy: Microsoft's remoting help says "Enable the policy and specify the IPv4 and IPv6 filters." Its remoting help names the policy Allow automatic configuration of listeners, under Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM service; Microsoft's Server Manager page names the setting in that folder "Allow remote server management through WinRM". Read both names as the same listener policy when you look for it in your GPOs (our reading).
| Finding | What it means (our reading unless noted) |
|---|---|
| WinRM Stopped or Disabled | Nothing to answer; on a client OS that's the default, on a server something disabled it (Step 9) |
| No listener at all | Remoting was never enabled or was removed; Test-WSMan -ComputerName localhost fails too (Step 9) |
Listener Source : GPO, ListeningOn : {}
|
Microsoft's policy misconfiguration case: the IPv4 or IPv6 filter in the listener policy is blank or excludes the target's addresses |
| Listener on a port other than 5985 or 5986 | Microsoft: "If the default authentication mechanism or the WinRM listener port number on a remote server has been changed from default settings, Server Manager cannot communicate with the remote server." |
Test-WSMan -ComputerName localhost works, remote fails |
The service and listener are fine; it's the firewall rule, profile, or path (Step 6) |
winrm e winrm/config/listener fails locally with error 0x80338012 |
Microsoft's local-functionality case: "This problem may occur if the Window Remote Management service and its listener functionality are broken." (Step 9) |
| Endpoints without your group in Permission | Remote sessions will fail with Access is denied after the connection works; Microsoft: connect with "a user account that's a member of the Administrators or Remote Management Users group on the remote computer" |
| Two listeners on the same port with different addresses | Microsoft: "If two listener services with different IP addresses are configured with the same port number and computer name, then WinRM listens or receives messages on only one address." |
Step 6: Is the firewall rule on, for the right profile and scope? (read-only)
This is the step that matches the second half of the message, "By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet." Read the profile first, then the rules, on the target:
# Read-only, on the target: the network category of each connected adapter
Get-NetConnectionProfile | Select-Object -Property InterfaceAlias, Name, NetworkCategory
# Read-only, on the target: the WinRM inbound rules, whether they're on, for which profile, and the action
Get-NetFirewallRule -Name 'WINRM*' | Select-Object -Property Name, DisplayName, Enabled, Profile, Action
# Read-only, on the target: the remote address scope of each WinRM rule
Get-NetFirewallRule -Name 'WINRM*' | ForEach-Object -Process {
$r = $_
$r | Get-NetFirewallAddressFilter | Select-Object @{n='Rule';e={$r.Name}}, RemoteAddress
}
# Read-only, on the target: the local port on each WinRM rule
Get-NetFirewallRule -Name 'WINRM*' | Get-NetFirewallPortFilter | Select-Object -Property Protocol, LocalPort
# Read-only, on the target: the rules group policy delivers (the RSOP store), which local edits can't override
Get-NetFirewallRule -PolicyStore RSOP | Where-Object -FilterScript { $_.DisplayName -like '*Remote Management*' } |
Select-Object -Property Name, DisplayName, Enabled, Profile, Action
Microsoft's rule names come from the Enable-PSRemoting and remoting help pages: WINRM-HTTP-In-TCP and WINRM-HTTP-In-TCP-NoScope in its client example, and WINRM-HTTP-In-TCP-PUBLIC for the Public rule on servers. The display name you'll see in the console is "Windows Remote Management (HTTP-In)". Microsoft also warns: "The name of the firewall rule can be different for different versions of Windows." That's why the read above uses a wildcard.
What Microsoft says the defaults are:
| Where | Microsoft's text |
|---|---|
| Servers, private and domain networks | "the Enable-PSRemoting cmdlet creates firewall rules that allow unrestricted remote access." |
| Servers, public networks | "It also creates a firewall rule for public networks that allows remote access only from computers in the same local subnet." |
| Clients, public networks | "By default, it fails on public networks, but if you use the SkipNetworkProfileCheck parameter, Enable-PSRemoting succeeds and creates a firewall rule that allows traffic from the same local subnet." |
| Any Windows | "On public networks, the default Windows Firewall rule allows PowerShell Remoting connections only from within the same subnet." |
winrm quickconfig |
"The command winrm quickconfig creates a firewall exception only for the current user profile." |
| Finding | What it means (our reading unless noted) |
|---|---|
| A domain-joined server's adapter shows NetworkCategory Public | Domain detection failed on that adapter (no DC reachable when the network was identified, wrong DNS, or a second adapter); the Public rule's local-subnet scope now applies to everyone else |
| NetworkCategory DomainAuthenticated, the Domain rule enabled and Allow | The host firewall isn't the block for domain traffic; look at the path (Step 3) or a third-party firewall |
| The WinRM rule for the active profile is disabled or missing | Something removed or disabled it; check RSOP first, then the local rule (Step 9) |
RemoteAddress LocalSubnet on the rule for the active profile |
Exactly the "same local subnet" restriction in the message; clients in other subnets get no answer |
| The rule exists in RSOP disabled, or the policy blocks local rules | A GPO owns it; a local Enable-PSRemoting or Set-NetFirewallRule won't stick |
| LocalPort isn't 5985 | Someone moved the listener or the rule; they must match each other and the client's -Port
|
On the policy side, Microsoft names two settings. The Windows Firewall: Allow local port exceptions policy decides whether local rules apply at all: "This policy allows members of the Administrators group to create a firewall exception for the Windows Remote Management (WinRM) service." And for Server Manager's version of this message, Microsoft's advice is the same read: "Try verifying that Windows Firewall exceptions have been enabled on the target server for Windows Remote Management (WinRM) inbound rules."
Step 7: Is a proxy in the path? (read-only)
Microsoft: "Because PowerShell remoting uses the HTTP protocol, it is affected by HTTP proxy settings." Read the machine-wide WinHTTP setting and any session option on the client:
# Read-only, on the client: the WinHTTP advanced proxy setting (Microsoft's current form)
netsh winhttp show advproxy
# Read-only, on the client: the older form, deprecated but still present on many builds
netsh winhttp show proxy
# Read-only, on the client: a session option set in this session or in a profile script
$PSSessionOption
Microsoft's proxy notes for WinRM: "By default, WinHTTP is not configured to use a proxy server." and, for WinRM 1.1 and earlier, "the WinRM client relies on the Windows HTTP services (WinHTTP) proxy configuration." On the session side, New-PSSessionOption's ProxyAccessType accepts IEConfig, WinHttpConfig, AutoDetect, NoProxyServer, and None, and "The default value is None."
| Finding | What it means (our reading unless noted) |
|---|---|
WinHTTP shows direct access, $PSSessionOption empty |
No proxy on this client; move on |
| A WinHTTP proxy with no bypass for internal names | Left by a deployment, update, or security tool; WinRM traffic to internal servers may go to the proxy |
$PSSessionOption set with ProxyAccessType in a profile script |
Every remoting command in that session inherits it |
| The error is "The client cannot connect to the destination specified in the request." rather than "cannot complete the operation" | Microsoft lists that text under its proxy section; this is the more likely step for it |
Microsoft's proxy page is also clear about HTTP through a proxy: "If the proxy server requires authentication, the WinRM clients and servers must use HTTPS." A design that sends WinRM to internal servers through an authenticating proxy over HTTP is the problem, not a setting (our reading).
Step 8: When it connects, does the error change to authentication? (read-only)
Often, fixing the profile or the rule turns "cannot complete the operation" into one of the "cannot process the request" messages. That's progress: the connection works and the authentication path is now the question. Microsoft's rules for which path you get:
| How you connect | What Microsoft says happens | What it needs |
|---|---|---|
| By computer name, inside a domain or across a trust | "When a client connects to a domain server using its computer name, the default authentication protocol is Kerberos." | A working SPN for the name you typed; no TrustedHosts needed |
| By IP address | "Kerberos authentication doesn't support IP addresses. When you specify an IP address, NTLM authentication is used." | "Configure the computer for HTTPS transport or add the IP addresses of the remote computers to the TrustedHosts list on the local computer." and -Credential
|
| From or to a workgroup computer | "When the local computer isn't in a domain, you must meet the following requirements" | HTTPS or TrustedHosts, "Verify that a password is set on the workgroup-based computer.", and -Credential
|
| Between Microsoft Entra-only joined machines | "WinRM considers the Microsoft Entra-only joined machines as workgroup machines." | Microsoft's TrustedHosts and SPN prefix fix (Step 9) |
On the IP and workgroup rows, Microsoft adds: "Use the Credential parameter in all remote commands. This is required even when you connect as the current user." The Invoke-Command reference says the same: "To use an IP address in the value of ComputerName, the command must include the Credential parameter."
Read what the client already trusts, and the SPNs behind the name you typed:
# Read-only, on the client: the current TrustedHosts list
Get-Item WSMan:\localhost\Client\TrustedHosts
# Read-only, any domain-joined machine: which account holds the HTTP SPN for the target's names
setspn -Q HTTP/FS02.contoso.com
setspn -Q HTTP/FS02
# Read-only: the SPNs registered on the target's computer account
setspn -L FS02
# Read-only, on the client: request a ticket for the target's HTTP SPN, to see the Kerberos error directly
klist get HTTP/FS02.contoso.com
WinRM's Kerberos SPN is HTTP/ plus the name. Microsoft's New-PSSessionOption reference explains the classic conflict: the IncludePortInSPN option "Includes the port number in the Service Principal Name (SPN) used for Kerberos authentication", and it exists because "For example, an IIS application that allows for Kerberos authentication can require the default SPN to be registered to a user account that differs from the computer account." If setspn -Q HTTP/FS02.contoso.com returns a service account instead of the FS02 computer account, that's your Kerberos failure (our reading of Microsoft's text).
Read the authentication errors against Microsoft's Server Manager table:
| Microsoft's message (excerpt) | Microsoft's cause (excerpt) | Next (our reading unless noted) |
|---|---|---|
| "error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred." | One listed cause: "The Service Principal Name (SPN) for the remote computer name and port does not exist." | The setspn -Q reads above; the SPN side of The Target Principal Name Is Incorrect
|
| "error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request." | "Client is in a domain, but the domain controller for the client computer is not accessible." | The client's own DC path, not the target |
| "The following error occurred while using Kerberos authentication: Cannot find the computer" | Workgroup target by name, an untrusted domain, or a misspelled domain name | Explicit credentials and TrustedHosts for the workgroup case; fix the name for the typo case |
| "Default authentication may be used with an IP address under the following conditions" | Connecting by IP without TrustedHosts or HTTPS | Connect by name, or meet the IP conditions deliberately |
| "If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting." | Workgroup or non-Kerberos connection | HTTPS, or a specific TrustedHosts entry (Step 9) |
Two cases look like remoting failures and aren't this one. First, Access is denied after the session opens: the account isn't in Administrators or Remote Management Users on the target, or the endpoint's Permission excludes it (Step 5). Second, the second hop: "Access to the resource on ServerC is denied, because the credentials you used to create the PowerShell Remoting session aren't passed from ServerB to ServerC." That's delegation, and Microsoft's second-hop page lists the options in order of preference, starting with CredSSP and resource-based Kerberos constrained delegation.
Step 9: Change one link (a change)
Fix the link the reads pointed at, on the side it's on, and nothing else. Write down the before value for each.
Service stopped or disabled (target). Set it back to Microsoft's server default and start it:
# Change, on the target: WinRM to Automatic and running
Set-Service -Name WinRM -StartupType Automatic
Start-Service -Name WinRM
If a policy or baseline set it to Disabled, fix it there, or the next refresh puts it back (our reading).
No listener, missing rules, or default endpoints removed (target). Enable-PSRemoting puts back Microsoft's defaults. What it does, per Microsoft: it runs Set-WSManQuickConfig, which "Starts the WinRM service.", "Sets the startup type on the WinRM service to Automatic.", "Creates a listener to accept requests on any IP address.", and "Enables a firewall exception for WS-Management communications.", then sets up and enables the session configurations and restarts WinRM.
# Change, on the target only, in an elevated Windows PowerShell window: restore the remoting defaults
Enable-PSRemoting -Force
Run it only on the target that needs it. Microsoft: "Because the configuration starts listeners, it's prudent to run it only where it's needed." Run it in Windows PowerShell if you manage Windows PowerShell endpoints; Microsoft warns that in PowerShell 7 it "only affects endpoints created with PowerShell version 6 and greater". -SkipNetworkProfileCheck does nothing on a server: Microsoft says it "has no effect on server versions of Windows, that by default, have a local subnet firewall rule for public networks."
Listener functionality broken (target, error 0x80338012 on local winrm commands). Microsoft's two steps, in order:
winrm invoke Restore winrm/Config
winrm quickconfig
Policy listener with an empty filter (GPO). Edit the listener policy in the GPO that applies to the target and fill in the IPv4 and IPv6 filters (Microsoft: "Wildcards ( *) are permitted."), or narrow them to the address ranges the servers use. Then read Get-WSManInstance winrm/config/listener -Enumerate again after the next policy refresh: ListeningOn should list the server's addresses.
Adapter in the Public profile on a domain server (target). Fix why domain detection failed: DNS servers on that adapter, a DC reachable from that adapter's network, a second adapter that shouldn't be registering. Microsoft's Set-NetConnectionProfile can change Public to Private but not to Domain: "You cannot set the DomainAuthenticated type by using this cmdlet. The server automatically sets the value of DomainAuthenticated when the network is authenticated to a domain controller." For an adapter that truly isn't on a domain network (a backup or storage VLAN with no DC), Microsoft's form is:
# Change, on the target: mark one non-domain adapter Private (not a fix for a domain adapter that should be DomainAuthenticated)
Set-NetConnectionProfile -InterfaceAlias 'Ethernet 2' -NetworkCategory Private
Rule scoped to the local subnet, and the clients really live elsewhere (target or GPO). Microsoft's example opens the Public rule to everywhere: Set-NetFirewallRule -Name 'WINRM-HTTP-In-TCP-PUBLIC' -RemoteAddress Any. Read its warning first: "The firewall rule for public networks is meant to protect the computer from potentially malicious external connection attempts. Use caution when removing this rule." We'd add only the management subnet instead (our form):
# Change, on the target: keep the local subnet and add only the admin or jump-box subnet to the Public WinRM rule
Set-NetFirewallRule -Name 'WINRM-HTTP-In-TCP-PUBLIC' -RemoteAddress LocalSubnet, 10.50.0.0/24
If the rule comes from a GPO, change it in the GPO; a local edit won't win.
Proxy in the path (client). If the WinHTTP proxy isn't needed on that machine, Microsoft's reset is netsh winhttp reset proxy, which "Resets the WinHTTP proxy setting to DIRECT." If something else on the box needs it, leave it and bypass the proxy for remoting only (our form):
# Change, for this session only, on the client: no proxy for this remoting connection
$so = New-PSSessionOption -ProxyAccessType NoProxyServer
Enter-PSSession -ComputerName FS02.contoso.com -SessionOption $so
IP address or workgroup target (client). Prefer connecting by name with Kerberos. If you must use NTLM, prefer HTTPS on the target; otherwise add the one host, not *. Microsoft: "The value that you set for the TrustedHosts item affects all users of the computer." Save the current value, then add to it:
# Read first, on the client: keep the current value somewhere you can restore it from
$curValue = (Get-Item WSMan:\localhost\Client\TrustedHosts).Value
$curValue
# Change, on the client: append one host to the existing list (Microsoft's -Concatenate form)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value '10.20.30.40' -Concatenate
For Microsoft Entra-only joined machines, Microsoft's documented fix is a TrustedHosts value plus the client SPN prefix change: "To resolve this issue, set the default SPN prefix to HOST by running the following command". Apply that only to the Entra-only case it was written for.
HTTPS instead of TrustedHosts (target). Microsoft: "WinRM HTTPS requires a local computer Server Authentication certificate with a CN matching the hostname to be installed. The certificate mustn't be expired, revoked, or self-signed." With the certificate in place, run winrm quickconfig -transport:https on the target, open TCP 5986 ("Open port 5986 for HTTPS transport to work."), and connect with -UseSSL.
SPN on the wrong account (domain). If HTTP/FS02 is registered to a service account for a web app, either move that app to its own name, or use New-PSSessionOption -IncludePortInSPN for remoting so the client asks for HTTP/FS02:5985. Moving SPNs breaks the other service if you get it wrong; The Target Principal Name Is Incorrect covers reading SPNs before changing them. Microsoft's setspn note: "you should use setspn -S instead because it verifies that there are no duplicate SPNs."
Step 10: Prove it from the same client (read-only, and again after a reboot)
Run the same reads from the client that failed, by the name users type, then again after the target reboots and after the next policy refresh. A profile that drops to Public at boot, or a GPO that turns the rule back off, only shows up then:
# Read-only, on the client: the path, the WinRM answer, and a real remote command
Test-NetConnection -ComputerName FS02.contoso.com -Port 5985
Test-WSMan -ComputerName FS02.contoso.com -Authentication Default
Invoke-Command -ComputerName FS02.contoso.com -ScriptBlock { $PSVersionTable.PSVersion }
# Read-only, on the client: TrustedHosts holds only what you meant to add
Get-Item WSMan:\localhost\Client\TrustedHosts
# Read-only, on the target after a reboot: still the right profile, rule, and listener
Get-NetConnectionProfile | Select-Object -Property InterfaceAlias, NetworkCategory
Get-NetFirewallRule -Name 'WINRM*' | Select-Object -Property Name, Enabled, Profile, Action
Get-WSManInstance winrm/config/listener -Enumerate
If the tool was Windows Admin Center, run the Invoke-Command from the gateway; if it was Server Manager, refresh the server in the pool and read its Manageability column.
Pass criteria (our reading): TcpTestSucceeded True on the port you use from every client subnet that needs it; Test-WSMan -Authentication Default returns the product version; Invoke-Command by the FQDN users type returns output without -Credential inside the domain; the adapter is DomainAuthenticated (or deliberately Private for a non-domain network) after a reboot; the WinRM rule for that profile is enabled with a scope you chose; ListeningOn lists the server's addresses; TrustedHosts is empty or holds specific entries with a written reason; and the original command works from the original client.
Common false starts
| False start | Why it doesn't help (our reading unless noted) |
|---|---|
Setting TrustedHosts to *
|
It doesn't change reachability, and Microsoft: "The computers in the trusted hosts list aren't authenticated." It affects every user on the client |
| Adding the server to TrustedHosts again | Microsoft's workgroup rows with TrustedHosts already set still fail on the subnet restriction; the fix is the rule scope |
Running Enable-PSRemoting -SkipNetworkProfileCheck on a server |
Microsoft: the parameter "has no effect on server versions of Windows" |
| Opening the Public rule to Any on every server | Microsoft's warning: the rule "is meant to protect the computer from potentially malicious external connection attempts." Fix the profile, or add one subnet |
Running winrm quickconfig and assuming every profile is covered |
Microsoft: it "creates a firewall exception only for the current user profile." |
| Restarting the WinRM service on the client | The client doesn't need a listener; the missing answer is on the target or the path |
| Editing a local rule or listener that a GPO owns | The next policy refresh puts the GPO's version back; read RSOP and Source : GPO first |
| Treating ping as the test | ICMP and TCP 5985 are filtered separately; Test-NetConnection -Port 5985 is the test |
| Switching to an IP address to get around a DNS problem | That moves you from Kerberos to NTLM and into the TrustedHosts case; fix the name |
| Disabling the Windows Firewall to test | It hides which rule or profile was wrong, and someone forgets to turn it back on |
| Setting LocalAccountTokenFilterPolicy for a reachability error | Microsoft: it "disables user account control (UAC) remote restrictions for all users of all affected computers." It's for local-admin access, not for "cannot complete" |
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| WinRM disabled on the target | Automatic and Running, and fix the policy or baseline that disabled it | Starting it by hand on every reboot |
| No listener or missing default rules |
Enable-PSRemoting -Force on that target only |
Running it on every machine in the estate just in case |
| Policy listener with ListeningOn empty | Fill in the listener policy's IPv4 and IPv6 filters in the GPO | Local winrm edits the GPO overwrites |
| Domain server in the Public profile | Fix domain detection (DNS, DC path, extra adapter) | Opening the Public rule to Any |
| Admins in another subnet blocked by the local-subnet scope | Add the management subnet to the rule scope, in the GPO if it's policy-managed |
-RemoteAddress Any on every server |
| Network firewall between sites drops 5985 | A rule for 5985 (or 5986) from the admin subnets to the servers | Moving admins onto the server subnet |
| WinHTTP proxy left by a tool | Reset it if nothing needs it, or -ProxyAccessType NoProxyServer for remoting |
Leaving it and routing WinRM through the proxy |
| Workgroup, Entra-only, or IP-only targets | HTTPS listener with a proper certificate, or a specific TrustedHosts entry | TrustedHosts *
|
| HTTP SPN registered to a service account | Move the app's name, or -IncludePortInSPN for remoting |
Deleting the SPN without reading who uses it |
FAQ
What does "WinRM cannot complete the operation" mean?
The client sent a WS-Management request to that name and port and got no usable answer. Microsoft's text names the checks: "Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer." It's reachability, not authentication; the authentication errors say "cannot process the request" instead (Steps 2 to 6).
What port does WinRM use?
TCP 5985 for HTTP and TCP 5986 for HTTPS. Microsoft: "Starting in WinRM 2.0, the default listener ports configured by Winrm quickconfig are port 5985 for HTTP transport, and port 5986 for HTTPS." Older Windows used 80 and 443 (Step 3).
How do I fix "the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet"?
Read the target's network profile first. On a domain server, Public usually means domain detection failed on that adapter; fix that and the Domain rule applies. If clients in another subnet really need access on a Public network, add their subnet to the Public WinRM rule rather than opening it to Any (Steps 6 and 9).
Should I set TrustedHosts to * to fix WinRM?
No. TrustedHosts is for NTLM connections by IP address or to workgroup machines, and Microsoft describes it as the list of hosts "for which you wish to suppress the error generated by being unable to verify the server's identity." It doesn't fix a firewall, profile, or listener problem. When you need it, add specific hosts with -Concatenate, or use HTTPS (Steps 8 and 9).
Why does Enter-PSSession work by name but not by IP address?
By name inside a domain, remoting uses Kerberos. Microsoft: "Kerberos authentication doesn't support IP addresses. When you specify an IP address, NTLM authentication is used." NTLM needs HTTPS or a TrustedHosts entry on the client, plus -Credential (Step 8).
Related posts
- The Target Principal Name Is Incorrect (when the error turns into a Kerberos or SPN failure once the connection works)
- Hyper-V Live Migration Failed (Event 21502) (when remoting fails between Hyper-V hosts during migration or remote host management)
- Active Directory Replication Error 1722 (when the same firewall, profile, or NIC also blocks RPC between the same servers)
Free checklist
Setting TrustedHosts to * on every admin box, or opening the Public WinRM rule to Any on every server, before anyone read which link dropped the request, is a change made everywhere at once. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=winrm-cannot-complete-the-operation
Admin Pack Studio; not affiliated with Microsoft. Steps 1-8 and 10 are read-only checks: Resolve-DnsName, Test-NetConnection, Get-NetIPAddress, Test-WSMan, Get-Service, winrm enumerate, winrm get, Get-WSManInstance, Get-PSSessionConfiguration, Get-NetConnectionProfile, Get-NetFirewallRule, Get-NetFirewallAddressFilter, Get-NetFirewallPortFilter, netsh winhttp show advproxy, netsh winhttp show proxy, Get-Item on the WSMan: drive, setspn -Q, setspn -L, klist get, and Invoke-Command with a read-only script block. Setting the WinRM service startup type, starting it, running Enable-PSRemoting, winrm invoke Restore, or winrm quickconfig, changing listener policy, network profiles, firewall rule scope, the WinHTTP proxy, TrustedHosts, HTTPS listeners and certificates, the SPN prefix, or SPNs are deliberate changes. Change one link at a time, prove it from the same client after a reboot, and check current Microsoft Learn for version-specific behavior.
