Enable PowerShell Remoting (WinRM) on a Standalone / Workgroup Server

PowerShell Remoting is what makes patching servers with PSWindowsUpdate and running remote commands possible. On a domain it “just works” because Active Directory provides Kerberos trust between machines. On a standalone / workgroup server there’s no such trust — so you need an appropriate authenticated connection setup, such as certificate-based HTTPS. TrustedHosts is an alternative with weaker server identity verification, not a requirement for every workgroup connection.

Step 1: Enable WinRM on the target server

On the server you want to connect to, open an elevated PowerShell and run:

Enable-PSRemoting -Force

-Force skips the confirmation prompts. (Without admin rights you’ll get “Access is denied.”) This starts the WinRM service, sets it to automatic, and creates the firewall rules.

Enable-PSRemoting normally configures an HTTP listener on TCP 5985. It does not automatically create an HTTPS listener on 5986. HTTPS needs a suitable server-authentication certificate, a configured HTTPS listener and the corresponding firewall rule.

On supported Windows Server versions, remoting can be enabled on Public networks with a local-subnet-only firewall scope. Windows client editions generally require -SkipNetworkProfileCheck to enable remoting on a Public network, also with a local-subnet restriction. Check the effective rules on the actual OS; do not mark an untrusted network Private merely to make remoting work.

Step 2: Set TrustedHosts on the client

This is the part domain admins never have to think about. Because workgroup machines can’t use Kerberos, the client must explicitly trust the servers it connects to (it falls back to NTLM auth). On the computer you’re connecting from:

# Trust specific hosts by name or IP (most secure — list only what you need)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'SRV01,192.168.10.20' -Force

Add more later without wiping the list using -Concatenate:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'SRV02' -Concatenate -Force

Check what’s trusted:

Get-Item WSMan:\localhost\Client\TrustedHosts

⚠️ Don’t use TrustedHosts = *. It tells your machine to trust every host for NTLM auth — a real security risk. Always list specific names or IPs. Prefer HTTPS with a correctly validated server certificate. A controlled network and a narrow TrustedHosts list reduce exposure but do not provide Kerberos/certificate server identity verification.

Step 3: Connect

Interactive session:

Enter-PSSession -ComputerName SRV01 -Credential (Get-Credential)

Run a command on several servers at once:

Invoke-Command -ComputerName SRV01,SRV02 -Credential (Get-Credential) -ScriptBlock {
  Get-Service -Name W32Time
}

Because there’s no domain, you must pass -Credential with a local account that exists on the target (e.g. SRV01\opsadmin).

Step 4: Review listeners and firewall scope

On the target, inspect the configured listeners and remoting rules in an elevated Windows PowerShell session:

winrm enumerate winrm/config/listener
Get-NetFirewallRule -Name 'WINRM*' | Select-Object Name, Enabled, Profile, Direction, Action

Keep a console recovery route available. Review all enabled rules allowing the listener, including Public-profile and custom/policy rules, and restrict their remote-address scopes to the intended admin sources. Adding a narrow rule does not cancel an existing broad allow rule. Test a fresh allowed and disallowed connection before claiming access is restricted.

For HTTPS, follow Microsoft’s certificate and listener procedure, then connect with -UseSSL to the certificate’s matching hostname. A TrustedHosts entry does not authenticate the server’s identity the way a correctly validated HTTPS certificate does. Do not disable certificate validation to avoid a name or trust error.

This pairs with the standalone server hardening checklist.

FAQ

“WinRM cannot process the request… not in TrustedHosts.” You set TrustedHosts on the wrong machine. It goes on the client (where you run the command), naming the target.

Do I need TrustedHosts on both ends? Only on the initiating client. The target just needs WinRM enabled.

Is NTLM/TrustedHosts safe? TrustedHosts permits connections without Kerberos server identity verification; a narrow list reduces scope but does not make the server identity verified. Prefer correctly configured HTTPS/certificates for workgroup remoting, and never expose management listeners broadly.

Sources: Microsoft Learn — Enable-PSRemoting and profile behavior, Microsoft Learn — Configure WinRM for HTTPS, Microsoft Learn — WinRM installation and configuration