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 have to set it up manually with TrustedHosts. Here’s the safe way to do it.

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.

WinRM listens on TCP 5985 (HTTP) and 5986 (HTTPS). Enable-PSRemoting opens these automatically for private/domain profiles — but if your server’s network is classified Public, the firewall rule won’t apply. Either reclassify the connection as Private or add a scoped rule (see Step 4).

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. For production, SSL/HTTPS (5986) with certificates is the proper approach; TrustedHosts is fine for a controlled internal network.

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: Firewall scoping (recommended)

Instead of leaving WinRM open to the whole network, restrict it to your admin subnet:

Set-NetFirewallRule -Name 'WINRM-HTTP-In-TCP' -RemoteAddress 192.168.10.0/24

This pairs well with the rest of 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? On a trusted internal network with a tightly scoped list, yes. Exposed to untrusted networks, switch to HTTPS (5986) with certificates.

Sources: Windows OS Hub — Configure PSRemoting for Non-Domain (Workgroup) Computers, Microsoft Learn — Installation and configuration for Windows Remote Management