PowerShell Remoting (WinRM) on a Windows VPS: Administer Servers Without RDP

RDP is how you look at a Windows VPS; PowerShell Remoting is how you operate it. WinRM (Windows Remote Management) is built into every modern Windows Server and lets you run commands, scripts, and full interactive sessions over the network without a desktop session — the foundation of real automation. Here is how to enable it, secure it, and use it day to day.

Everything below works on any Windows VPS that gives you administrator access. If you have not picked a host yet, our comparison table is a good place to compare plans — WinRM sessions are lightweight, but the network throughput of the provider still matters for large file transfers.

What WinRM Actually Is

WinRM is Microsoft’s implementation of the WS-Management protocol. The service listens on TCP 5985 (HTTP) and 5986 (HTTPS), and PowerShell’s remoting cmdlets — Enter-PSSession, Invoke-Command, New-PSSession — are just clients for it. It is enabled by default on Windows Server, but the firewall rules and listener are not.

Enable It in One Command

From an elevated PowerShell console on the VPS:

Enable-PSRemoting -Force

This starts the WinRM service, creates the HTTP listener, and opens the 5985 firewall rule for the Private and Domain profiles. Verify from your workstation with Test-WSMan 203.0.113.10 — you should get a response with the protocol version.

Connect from Your Workstation

An interactive session works exactly like a PowerShell window on the server:

$cred = Get-Credential
Enter-PSSession -ComputerName 203.0.113.10 -Credential $cred

One catch: if the VPS is not domain-joined (most VPS instances are not), the client must list the server in TrustedHosts or the connection is refused:

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

TrustedHosts falls back to NTLM authentication, which works but is not the most secure option — if you expose WinRM to the internet rather than a VPN, set up the HTTPS listener below instead.

Run Commands Without a Session

For one-off tasks, skip the interactive session and pipe results straight back:

Invoke-Command -ComputerName 203.0.113.10 -Credential $cred -ScriptBlock {
  Get-Volume | Sort-Object DriveLetter |
    Select-Object DriveLetter,
      @{n='FreeGB';e={[math]::Round($_.SizeRemaining/1GB,1)}}
}

The same call accepts an array of computers — Invoke-Command -ComputerName srv1,srv2,srv3 ... — and runs against them in parallel with a default throttle of 32. That is how one console window administers a whole fleet of VPS instances.

Persistent Sessions for Scripted Jobs

When a task spans multiple commands, keep a session alive instead of re-authenticating each time:

$s = New-PSSession -ComputerName 203.0.113.10 -Credential $cred
Invoke-Command -Session $s -ScriptBlock { Copy-Item C:\app\*.zip D:\deploy\ -Force }
Invoke-Command -Session $s -ScriptBlock { & D:\deploy\deploy.ps1 }
Remove-PSSession $s

Lock It Down: HTTPS Listener

For production, expose WinRM over HTTPS (5986) with a certificate instead of plain HTTP:

$cert = Get-ChildItem Cert:\LocalMachine\My |
  Where-Object Subject -like '*vps.example.com*' | Select-Object -First 1
New-Item -Path WSMan:\localhost\Listener\Transport\HTTPS `
  -Address * -HostName vps.example.com `
  -CertificateThumbprint $cert.Thumbprint -Force

Connect with Enter-PSSession -ComputerName vps.example.com -Credential $cred -UseSSL. Also raise the default 500 KB message size limit if you push large payloads: Set-Item WSMan:\localhost\MaxEnvelopeSizekb -Value 2048.

Copy Files Over WinRM

You do not need SMB or FTP for transfers — Copy-Item works across a session in both directions:

Copy-Item C:\deploy\app.zip -ToSession $s -Destination C:\deploy\app.zip
Copy-Item C:\logs\app.log -FromSession $s -Destination D:\collected

The transfer runs over the same WinRM channel (5985/5986), so there are no extra ports to open on the VPS. For very large files it is slower than raw SMB, but for deployment packages and logs it is perfectly adequate and far simpler to script. Keep the session alive for the whole deployment: state such as the current directory and imported modules persists between Invoke-Command calls, which makes multi-step deploys far more predictable.

Troubleshooting WinRM

• Get-Service WinRM must show Running; if it keeps stopping, set Set-Service WinRM -StartupType Automatic.
• From the client, Test-NetConnection 203.0.113.10 -Port 5985 verifies the port is reachable at all.
• Error 0x8033810c (access denied) usually means the server is missing from TrustedHosts, or the account lacks admin rights.
• If a connection only works with AllowUnencrypted set, treat that as a stopgap and move to the HTTPS listener instead.

Not on Windows? Use pwsh

PowerShell 7 runs on Linux and macOS, and the remoting cmdlets behave identically — the same Enter-PSSession and Invoke-Command calls work from a MacBook or a CI runner. WinRM is also scriptable over plain HTTP, which makes it easy to drive from build pipelines.

WinRM needs full administrator access to the server, and Hostwinds Windows VPS plans ship with exactly that, so remoting works out of the box.

WinRM will not replace RDP for GUI work, but for scripts, scheduled jobs, and multi-server automation it is the difference between clicking and commanding. Compare plans side by side in our comparison table to find a host with the network throughput your WinRM sessions deserve.