Preparing the Windows Host

Windows Server 2012 and later — usually yes

On Windows Server, remote management is enabled by default since Windows Server 2012. A default installation therefore already has:

• the WinRM service running,
• an HTTP listener on port 5985,
• the firewall open on 5985, and
• Kerberos and Negotiate authentication enabled.

That is exactly what this client needs, which is why connecting to a freshly installed Windows Server with an administrator account normally works with no host-side preparation at all.

It can still have been turned off afterwards — by Group Policy, by a hardening baseline, or by an unattended-install answer file — so verify rather than assume.

Windows 10 / 11 and other client versions — no

Client versions of Windows do not enable WinRM by default. You must enable it explicitly, and the network profile matters (see Enabling WinRM).

Domain membership is not what enables WinRM

Domain membership does change three things that matter here:

• Kerberos becomes possible. Kerberos needs a KDC, so it is only available in a domain; workgroup hosts are limited to NTLM. See Authentication^[2].
• Group Policy becomes the practical way to enable WinRM across many hosts at once — which is why WinRM is in fact enabled on the client machines of many domains. That is the GPO's doing, not the domain's.
• Domain accounts escape UAC remote token filtering, unlike local accounts. This is the single most common cause of “my local admin account gets access denied” — see Local administrators and UAC.

Checking on the host

Get-Service WinRM                              # is the service running?
winrm enumerate winrm/config/listener          # is there a listener, on which port and address?
winrm get winrm/config/service                 # Negotiate/Kerberos enabled? AllowUnencrypted? RootSDDL?
Get-NetFirewallRule -Name 'WINRM*' | Select-Object Name, Enabled, Profile

winrm get winrm/config/service needs an elevated prompt; it is also the quickest way to read the listener's security descriptor (RootSDDL) discussed under Privileges.

Checking from the client

The quickest end-to-end check is the standalone jar (Command-Line Client^[4]) — it exercises the same code path as the library:

java -jar winrm-java-2.0.00-standalone.jar \
  -h server.example.com -u 'DOMAIN\user' -pf password.txt \
  wql 'SELECT Name FROM Win32_ComputerSystem'

java -jar winrm-java-2.0.00-standalone.jar \
  -h server.example.com -u 'DOMAIN\user' -pf password.txt \
  command whoami

Run both: they exercise different plug-ins on the host and can fail independently — the first needs WMI access, the second needs remote-shell access.

The quick way (HTTP, port 5985)

This client needs three things on the host: the service running, a listener, and the firewall open. One command sets up all three, from an elevated prompt on the target host:

winrm quickconfig

Answer y when it asks. Add -quiet to skip the prompt. You can also use PowerShell's Enable-PSRemoting -Force, which also enables WinRM.

On client versions of Windows: the network profile

On Windows 10 / 11, winrm quickconfig refuses to create the firewall exception when the active network profile is Public, and fails with a message to that effect. The service and the listener may still be configured, but the port stays closed — so connections time out.

The clean fix is to set the network to Private (or join a domain), then re-run winrm quickconfig:

Set-NetConnectionProfile -InterfaceAlias 'Ethernet' -NetworkCategory Private

Where that is not possible, create the inbound rule explicitly, scoped as tightly as you can:

New-NetFirewallRule -DisplayName 'WinRM HTTP' -Direction Inbound -Protocol TCP `
  -LocalPort 5985 -RemoteAddress 192.0.2.10 -Action Allow

HTTPS (port 5986)

An HTTPS listener needs a server certificate whose subject (or SAN) matches the name you connect by, and whose thumbprint is bound to the listener:

winrm quickconfig -transport:https

quickconfig only succeeds if a suitable certificate is already in the host's LocalMachine\My store. Otherwise create one and bind it explicitly — for a lab host, a self-signed certificate is enough. Remember to open port 5986 as well, which quickconfig -transport:https does not necessarily do for you:

$cert = New-SelfSignedCertificate -DnsName 'server.example.com' -CertStoreLocation Cert:\LocalMachine\My
New-WSManInstance -ResourceURI winrm/config/Listener `
  -SelectorSet @{ Address = '*'; Transport = 'HTTPS' } `
  -ValueSet @{ Hostname = 'server.example.com'; CertificateThumbprint = $cert.Thumbprint }
New-NetFirewallRule -DisplayName 'WinRM HTTPS' -Direction Inbound -Protocol TCP -LocalPort 5986 -Action Allow

On the client side, a self-signed certificate is not trusted by default since 2.0.0: import it into a Java trust store, or opt out for testing. See TLS / HTTPS^[1].

At scale: Group Policy

For many hosts, enable the listener through Computer Configuration → Administrative Templates → Windows Components → Windows Remote Management (WinRM) → WinRM Service → “Allow remote server management through WinRM”, set to Enabled (registry: HKLM\Software\Policies\Microsoft\Windows\WinRM\Service, AllowAutoConfig = 1).

Two further things the policy does not do, and that you must configure alongside it:

• open the firewall — add the inbound rule for port 5985 (or 5986) through the Windows Firewall policy, and
• start the service — set the WinRM service startup type to Automatic through the System Services policy.

Setting that same policy to Disabled is the supported way to turn remote management off, and is a frequent reason a Windows Server that “should” work does not.

The short answer

Administrator rights are what make WinRM work with zero host configuration, because the default security descriptor on the WinRM listener grants full access to BUILTIN\Administrators and to nobody else who connects over the network.

Local administrators and UAC

This is the trap that catches most people connecting to a workgroup host or with a local account. Microsoft states it plainly:

Local administrator accounts other than the built-in Administrator account may not have rights to manage a server remotely, even if remote management is enabled.

Under UAC, a local account that is a member of Administrators receives a filtered token on network logon, stripped of its administrative privileges — so WinRM denies it. The built-in Administrator account is exempt; domain accounts in Administrators are not affected at all.

To let other local administrator accounts connect, set on the target host:

New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' `
  -Name LocalAccountTokenFilterPolicy -PropertyType DWord -Value 1 -Force

A useful diagnostic: if the built-in Administrator authenticates but another member of Administrators does not, with the password known-good in both cases, it is token filtering essentially every time.

What each operation actually requires

The privileges are not one single thing — the client uses two different WinRM plug-ins, gated separately:

So an account can perfectly well run WQL queries and fail to run commands, or the reverse. When diagnosing, test the two independently — as in Checking from the client above.

Configuring a non-administrator account

Non-administrative access is possible, and is the right choice for a monitoring account that only needs to read WMI. Step 1 below is always required. Step 2 is only needed for WQL queries (and therefore for transfer-and-run, which discovers the remote Windows directory with one): an account that only runs commands or calls uploadFile(...) never reaches WMI, so grant it nothing there.

1. Grant remote access to the WinRM listener. The default listener security descriptor (RootSDDL) grants full access to BUILTIN\Administrators and read access to interactive users only: O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD). Inspect the value on your own host first, since a hardening baseline may have changed it:

(Get-Item WSMan:\localhost\Service\RootSDDL).Value

So the account needs an entry in the descriptor itself:

winrm configSDDL default

That opens a permissions dialog: add the account or group and grant Read and Execute. Prefer this dialog over setting RootSDDL as a string — it adds your entry to the existing descriptor, whereas assigning the value wholesale risks dropping the entries already there.

2. Grant WMI access — required for WQL queries. Two steps, both on the target host:

• Add the account to the local WinRMRemoteWMIUsers__ group, which exists to gate the WinRM WMI plug-in:

  net localgroup WinRMRemoteWMIUsers__ /add 'DOMAIN\monitoring'
  

  Note

  WinRMRemoteWMIUsers__ and Remote Management Users carry the same description in Windows (“can access WMI resources over management protocols”), which makes them easy to confuse. WinRMRemoteWMIUsers__ is the one Microsoft's WinRM documentation names for the WMI plug-in on Windows 8 / Server 2012 and later — it is current, not a legacy name — and it is created when WinRM is configured, so a host where WinRM was never enabled may not have it yet.

  Either way, membership in neither group is sufficient on its own: the namespace rights below and the RootSDDL entry from step 1 are what actually grant access.

• Then grant the account rights on the WMI namespace itself, since group membership alone does not confer them. Run wmimgmt.msc → WMI Control → Properties → Security, select the namespace (Root\CIMV2 for almost everything), Security, add the account, and grant Enable Account and Remote Enable, with Applies to set to This namespace and subnamespaces.

  Those two are all a SELECT query needs. In particular Execute Methods is not required — it authorizes invoking WMI class methods, which this client never does (it only runs SELECT queries; anything else is rejected locally as a WqlSyntaxException). Many monitoring guides grant it anyway; leave it off unless something else on the account's behalf needs it.

  Granting these on Root with This namespace and subnamespaces covers every namespace at once; granting them on Root\CIMV2 alone is tighter and usually sufficient.

3. Remote commands need more than this. Listener access lets a non-administrator open a remote shell, but the commands you then run are ordinary Windows processes subject to ordinary Windows security — reading a service's state, a registry key or a protected directory still requires the corresponding rights, and much of what people run over WinRM needs administrative ones. The practical guidance: use a non-administrator account for WQL-only workloads, and expect to need an administrative account when you run commands. Whichever you choose, verify it with command whoami as shown above rather than assuming.

The second hop

A remote command authenticates with a network logon whose credentials cannot be delegated onward. So a command that reaches a second remote resource — a UNC path, another server, a mapped drive — fails with access denied, even though the same command works when run locally on the host.

Windows solves this with CredSSP or Kerberos constrained delegation. This client does not support CredSSP (Authentication^[2]), so the workaround is to avoid the second hop: copy what you need onto the host first (File Transfers^[3]), or have the command use credentials it supplies itself.