Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

License Error 0x80338012

0x80338012 in Windows Admin Center: the WinRM client cannot connect to the node

12 min read Updated October 4, 2026 Windows Server: RDS, Hyper-V & Clustering

Fix it now

Microsoft publishes 0x80338012 as the client being unable to connect to the destination specified in the request, and names winrm quickconfig on the destination as the action. It is not a timeout, so raising timeouts and shell quotas on the node will not move it.

Run the first three on the managed node in an elevated prompt; run the last from the gateway

winrm e winrm/config/listener
winrm invoke Restore winrm/Config
winrm quickconfig
Enter-PSSession -ComputerName <node>
  1. On the node, enumerate the listeners. If that command is itself what returned 0x80338012, the WinRM service and its listener configuration are the problem, not the network.
  2. Repair the configuration and re-create the listener: winrm invoke Restore winrm/Config followed by winrm quickconfig. Microsoft documents that pair as the resolution when the service and its listener functionality are broken.
  3. From the gateway, test the path: Test-NetConnection -Port 5985 -ComputerName <node> -InformationLevel Detailed, or 5986 if you have configured HTTPS.
  4. Then test remoting properly with Enter-PSSession -ComputerName <node>. A session that opens means connectivity and permissions are both fine.
  5. If the node is in a workgroup or another forest, add it on the gateway: Set-Item WSMan:\localhost\Client\TrustedHosts -Value '<node>'

Use exact names in TrustedHosts rather than a wildcard. The value replaces the list, so read it with Get-Item WSMan:\localhost\Client\TrustedHosts before you set it.

If Windows Admin Center loads the node, stop here. If it does not, the next section covers what the gateway is actually doing and where in that path it is being refused.

Why it happens

Windows Admin Center is a gateway, not an agent. Your browser talks to the gateway over HTTPS, and the gateway talks to each managed node over WS-Management, which by default means HTTP on 5985 or HTTPS on 5986. Everything the tool shows you, from disk usage to the event log, arrives through that channel as PowerShell and WMI calls. If the channel is not there, the tool has nothing to show.

The important correction is what the code means. 0x80338012, decimal -2144108526, is published as: the client cannot connect to the destination specified in the request; verify that the service on the destination is running and is accepting requests; and if the destination is the WinRM service, run winrm quickconfig on the destination. That is a connect failure, not an expiry. Reading it as a timeout sends people to shell quotas and MaxTimeoutms, which cannot fix a connection that was never made.

The documented repair when the WinRM service and its listener functionality are broken is two commands in order: winrm invoke Restore winrm/Config, which restores the configuration, then winrm quickconfig, which sets the service up to receive requests. That is worth trying before any network investigation, because the same code appears when you run winrm e winrm/config/listener locally on a node whose own configuration is broken, and no firewall rule anywhere explains that.

Three event IDs are commonly quoted alongside this code: 142 and 161 in the WinRM operational log, and 10154 in the System log. Microsoft does not publish a meaning for any of them, so this article does not assign one. Read them on the node if they are there; they carry their own detail. The diagnosis below is built on things that are published.

The WinRM service or its listener is broken on the node

You have this one if Running winrm e winrm/config/listener on the node itself returns 0x80338012, or winrm id returns an HTTP error.

  1. On the node, run winrm invoke Restore winrm/Config.
  2. Then winrm quickconfig and accept the changes it proposes.
  3. Re-enumerate: winrm e winrm/config/listener, and confirm a listener now exists on the address the gateway uses.
  4. Retry the connection from Windows Admin Center.

A listener bound only to a management network will not answer a gateway on a different subnet. Check the address it is bound to, not just that one exists.

The management port is not open from the gateway to the node

You have this one if A listener exists on the node, and Test-NetConnection from the gateway to 5985 or 5986 fails.

  1. On a Windows Server node, open the rule Microsoft names: Set-NetFirewallRule -Name WINRM-HTTP-In-TCP-PUBLIC -RemoteAddress Any
  2. On a Windows client node the documented rule name is WINRM-HTTP-In-TCP.
  3. Check the network profile the node’s interface is in. A rule scoped to Domain does nothing on an interface classified as Public.
  4. Ask the network team to permit the port from the gateway’s address, then retest with Test-NetConnection before going back to the console.

The node is not domain-joined, or you are using a local account

You have this one if Domain nodes work and a workgroup node does not, or a local administrator account is refused where a domain account would be accepted.

  1. On the gateway, add the node to TrustedHosts: Set-Item WSMan:\localhost\Client\TrustedHosts -Value '<node>'. Read the current value first, because setting it replaces the list.
  2. On the node, allow non-administrator local accounts to connect by creating LocalAccountTokenFilterPolicy as a DWORD set to 1 under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
  3. Prefer joining the node to the domain, or using an HTTPS listener with a proper certificate, over a long TrustedHosts list.
  4. Retest with Enter-PSSession.

TrustedHosts weakens mutual authentication for the names in it. Keep the list short and use exact names rather than a wildcard.

Credential delegation is needed and is not enabled

You have this one if The connection works for some tools and fails for anything that has to reach a second hop, with a WinRM error about credentials.

  1. Recognise the shape: WinRM does not allow credential delegation by default.
  2. Where a tool genuinely needs it, enable CredSSP temporarily and turn it off again afterwards.
  3. If the node was upgraded from an older Windows Server release, check that the upgrade did not clear the gateway’s TrustedHosts settings.
  4. Retest the specific tool that was failing rather than the connection as a whole.

Full reference

What is published, and what is not

Identifier Status What Microsoft publishes
0x80338012 Published -2144108526. The client cannot connect to the destination specified in the request. Verify the service on the destination is running and accepting requests; if it is WinRM, run winrm quickconfig on the destination
0x80338171 Published -2144108175. The WinRM client received an HTTP bad request status (400) with no further detail from the remote service
Event ID 142 Not published No Microsoft page found. Read the entry in the WinRM operational log on the node
Event ID 161 Not published No Microsoft page found
Event ID 10154 Not published No Microsoft page found. If you suspect service principal names, check them directly with setspn rather than relying on an interpretation of this ID

The documented repair, in order

  1. winrm invoke Restore winrm/Config on the node. This is the first half of Microsoft’s documented resolution when the WinRM service and its listener functionality are broken.
  2. winrm quickconfig on the node, which is also the action named inside the 0x80338012 message itself.
  3. winrm e winrm/config/listener to confirm a listener now exists, and on which address.
  4. From the gateway, Test-NetConnection -Port 5985 -ComputerName <node> -InformationLevel Detailed.
  5. From the gateway, Enter-PSSession -ComputerName <node>. Microsoft documents this as the check that tells you connectivity and permissions are both in order; if the session opens, the remaining fault is in the tool, not the channel.

Firewall rules by their real names

Node type Rule name Command
Windows Server WINRM-HTTP-In-TCP-PUBLIC Set-NetFirewallRule -Name WINRM-HTTP-In-TCP-PUBLIC -RemoteAddress Any
Windows client WINRM-HTTP-In-TCP Set-NetFirewallRule -Name WINRM-HTTP-In-TCP -RemoteAddress Any

Opening these to Any is the documented workgroup configuration and is broader than most environments want. Scope -RemoteAddress to the gateway once you have proved the path, so the rule matches your actual management topology rather than the lab it was written for.

TrustedHosts, correctly

Command What it does
Get-Item WSMan:\localhost\Client\TrustedHosts Reads the current list. Do this first
Set-Item WSMan:localhost\Client\TrustedHosts -Value '192.168.1.1,server01.contoso.com,server02' Sets the list. It replaces, it does not append
Clear-Item WSMan:localhost\Client\TrustedHosts Empties it

A wildcard is documented, and it is a bad habit: it turns off the protection the list exists to provide, for every name. The better answers, in order, are joining the node to the domain, or configuring an HTTPS listener on 5986 with a real certificate, and keeping TrustedHosts for the handful of machines that genuinely cannot do either.

Gateway-side problems that masquerade as node problems

  • A machine restricted to HTTP/2 breaks integrated Windows authentication, because Windows Admin Center requires HTTP/1.1 for it. The documented remedy is EnableHttp2Cleartext and EnableHttp2Tls as DWORD 0 under HKLM\SYSTEM\CurrentControlSet\Services\Http\Parameters.
  • “You are not authorized to view this page” after an update is documented as a browser and certificate problem: restart the browser, refresh, and confirm the Windows Admin Center Client certificate was selected.
  • A gateway installation depends on the ServerManagementGateway service running.
  • A port conflict from a previous installation is cleared with netsh http delete sslcert ipport=0.0.0.0:443 and netsh http delete urlacl url=https://+:443/.

Why the timeout reading costs you an afternoon

If you treat this code as a timeout, the natural next steps are to raise MaxTimeoutms and the per-shell quotas on the node, and to look at whether the server is under load. None of that can help a client that could not connect, and worse, raising quotas hides a genuine resource problem if one exists. Take the published meaning at face value: something between the gateway and the WinRM service on the node is not answering, and the two candidates are the service configuration and the network path.

When a licence is the actual fix

None of the fixes above cost anything. WinRM, the firewall rules and Windows Admin Center itself are included with Windows Server. The one situation where a licence is genuinely involved is a node on a Windows Server release that is out of support and no longer receiving the fixes that keep remote management working, which turns a configuration problem into a platform one. If you have reached that point, the answer is to move the workload onto a current build, and Windows Server 2025 Standard is the usual choice. Arco can supply the licence and check whether the server is already covered by an agreement you hold before you buy another.

Every code this article covers

Code What it points at Source
0x80338012 The client cannot connect to the destination specified in the request. Microsoft names winrm quickconfig on the destination as the action; it is a connect failure, not a timeout Microsoft Learn
Event ID 142 Written to the WinRM operational log on the node. Microsoft publishes no meaning for it, so read the entry itself rather than an interpretation of the number not published by the vendor
Event ID 161 Also in the WinRM operational log, with no published meaning. Treat it as a pointer to the node rather than as a diagnosis not published by the vendor
Event ID 10154 Seen in the System log from the WinRM source. No published meaning. If you suspect a service principal name problem, check it directly with setspn -L and setspn -X not published by the vendor

Confirm the fix worked

  1. Run winrm e winrm/config/listener on the node and confirm a listener exists on the address the gateway uses.
  2. Run Test-NetConnection -Port 5985 -ComputerName <node> -InformationLevel Detailed from the gateway and confirm it succeeds.
  3. Run Enter-PSSession -ComputerName <node> from the gateway and confirm the session opens.
  4. Open the node in Windows Admin Center and load an inventory-heavy tool such as the event viewer or installed roles.
  5. Reboot the node and confirm the connection still works without anyone touching it.

Questions people ask about this

Is 0x80338012 a timeout?

No, and that is the most common mistake made with it. Microsoft publishes it as the client being unable to connect to the destination specified in the request, and names winrm quickconfig on the destination as the action. Raising WSMan timeouts or shell quotas cannot fix a connection that was never established.

Do I need a licence for Windows Admin Center?

No. It is included with Windows Server at no additional cost. If a licence ever becomes part of this problem it is because the managed server itself needs replacing, not because of the tool.

Should I use HTTPS on 5986 instead of HTTP on 5985?

For nodes outside a trusted network, yes. An HTTPS listener with a proper certificate is the cleaner arrangement and removes most of the reasons people reach for TrustedHosts.

Is adding a node to TrustedHosts a security problem?

It weakens mutual authentication for that name, so keep the list short, use exact names rather than a wildcard, and read the current value before setting it, because Set-Item replaces the list rather than adding to it.

Why does one node fail when the rest are fine?

Because this is per-node configuration. The gateway is proven working by every other server it manages, so run the documented repair on that node first: winrm invoke Restore winrm/Config, then winrm quickconfig.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix RD Web Access broken: HTTP 500.100, HTTP 404.17 and Event ID 1309 explained Free Fix Event ID 55 and 137: NTFS corruption appears on SAN and iSCSI volumes License Error Event ID 4096 and 0x800705B4: integration services time out during VM tasks License Error Event ID 4105: per-user RDS CALs are issued but not recorded in Active Directory
← Back to Knowledge Base