Remoting with PowerShell

Analogy categoryAnalogies

How PowerShell Remoting Works

PowerShell Remoting is built on WS-Management (WinRM), a SOAP-based protocol that listens on TCP port 5985 for HTTP and 5986 for HTTPS, and it must be enabled on the target machine with Enable-PSRemoting before any remote session can be established. Unlike simple remote-execution tools that just run a command and capture text output, PowerShell Remoting serializes actual .NET objects across the connection, so a remote Get-Process still returns objects with usable properties on the local machine, not just formatted text.

🏏

Cricket analogy: Enable-PSRemoting is like installing the Hawk-Eye tracking system in a stadium before any match can use ball-tracking replays; the infrastructure must be switched on before it can be used.

Interactive and One-Off Remote Sessions

Enter-PSSession -ComputerName Server01 opens an interactive session where every command you type runs on the remote machine until you call Exit-PSSession, which is convenient for exploratory troubleshooting on a single server. Invoke-Command -ComputerName Server01,Server02 -ScriptBlock { Get-Service } instead runs a script block against one or many computers in parallel and returns the results to the local session, tagging each result object with a PSComputerName property so you can tell which machine each result came from.

🏏

Cricket analogy: Enter-PSSession is like a commentator stepping into the dressing room for a live one-on-one interview, fully present on that one 'machine' until they step back out.

Persistent Sessions and Security Considerations

New-PSSession creates a reusable session object stored in a variable, which Invoke-Command -Session can reuse across multiple calls to preserve state like imported modules or variables between commands, and Import-PSSession can even bring a remote module's commands into the local session as local proxy functions. By default, PowerShell Remoting only trusts domain-joined or explicitly trusted machines; connecting to a workgroup computer typically requires adding it to TrustedHosts on the client with Set-Item WSMan:\localhost\Client\TrustedHosts, and multi-hop scenarios (a command that itself needs to reach a third machine) require CredSSP or Kerberos delegation since credentials do not automatically forward across a second hop.

🏏

Cricket analogy: New-PSSession preserving state across calls is like a specialist spin-bowling coach staying with the same player through an entire net session, remembering adjustments from ball to ball instead of starting fresh each time.

powershell

# One-off command against multiple servers
Invoke-Command -ComputerName 'Server01','Server02' -ScriptBlock {
    Get-Service -Name 'W3SVC' | Select-Object Status, StartType
} | Format-Table PSComputerName, Status, StartType

# Persistent session for repeated calls
$session = New-PSSession -ComputerName 'Server01'
Invoke-Command -Session $session -ScriptBlock { $data = Get-ChildItem C:\Logs }
Invoke-Command -Session $session -ScriptBlock { $data.Count }
Remove-PSSession $session

# Trust a workgroup machine before connecting
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'WorkgroupPC01' -Force

Adding a machine to TrustedHosts disables mutual authentication for that connection, meaning the client can no longer verify the remote machine's identity via Kerberos. Restrict TrustedHosts entries to specific hostnames you control rather than using a wildcard '*', and prefer HTTPS listeners with certificate-based authentication for any remoting that crosses untrusted networks.

PowerShell Remoting runs over WinRM (WS-Management) on ports 5985 (HTTP) and 5986 (HTTPS) and must be enabled with Enable-PSRemoting.
Remoting transfers serialized .NET objects, not just text, so remote command output remains fully queryable locally.
Enter-PSSession opens an interactive session with one remote machine at a time.
Invoke-Command -ComputerName runs a script block against one or many machines and tags results with PSComputerName.
New-PSSession creates a reusable session that preserves state across multiple Invoke-Command calls.
TrustedHosts must be configured to connect to non-domain-joined machines, and doing so disables mutual authentication.
Multi-hop remoting scenarios require CredSSP or Kerberos delegation since credentials don't forward automatically.