PowerShell Remoting and WinRM

What Is PowerShell Remoting?

PowerShell Remoting lets you run PowerShell commands on a remote computer as though you were sitting at its console, without ever opening a Remote Desktop session.

Think of it as picking up a direct line into a remote server’s PowerShell engine, rather than walking over to its desk and typing on its keyboard through RDP. You send a command, the remote engine runs it locally on that machine, and the result comes back to your console as structured data, not a screenshot.

Under the hood, this is carried by Windows Remote Management (WinRM), Microsoft’s implementation of the WS-Management protocol. WinRM listens for connections on TCP 5985 for HTTP and TCP 5986 for HTTPS, and PowerShell layers its own remoting protocol on top of those WS-Management messages. Three cmdlets sit on top of that transport: Enter-PSSession for an interactive one-to-one session, Invoke-Command for running a script block on one or many computers, and New-PSSession for creating a persistent connection either of the other two can reuse.

Why Remoting Instead of RDP or Local Consoles?

Clicking through Remote Desktop sessions one server at a time works fine for a handful of machines. It stops working the moment you have twenty, two hundred, or a Server Core box with no desktop to click through in the first place.

This is also why PowerShell Remoting has been enabled by default on Windows Server since Windows Server 2012 R2. Microsoft treats it as the baseline way to manage a server fleet, not an optional add-on.

Why Active Directory and Security Care About Remoting

Remoting is only as safe as the authentication behind it, and that authentication behaves differently depending on how you connect.

When a client connects to a domain-joined server by computer name, WinRM authenticates with Kerberos by default. Kerberos proves both the user’s identity and the server’s identity to each other without ever sending a reusable credential across the wire. When you connect by IP address, or to a workgroup computer with no domain to ask, Kerberos isn’t available and WinRM falls back to NTLM, which proves who you are but cannot prove who the server is.

Adding a host to TrustedHosts is not a statement that the host is trustworthy. It only tells your local WinRM client to stop demanding proof of the server’s identity over NTLM, which is why it should be scoped as tightly as possible rather than set to a wildcard on a workstation that talks to production.

Because a remoting session runs under the connecting user’s own account and inherits their normal access controls, it shows up in the same places any other authenticated logon would: security event logs on the target server, and (where module or script block logging is configured) the PowerShell operational log. Treat a remoting session the same way you would treat an interactive logon when you’re reviewing who touched what.

The Double-Hop Problem

This is the failure every PowerShell remoting user eventually runs into once a script tries to reach past the first remote computer.

The scenario: you are logged in to ServerA. From ServerA you open a remoting session to ServerB. A command running on ServerB then tries to reach a resource, a share, another server’s WMI, an Active Directory query, on ServerC. Access to ServerC is denied, because the credentials you used to authenticate to ServerB were never handed to ServerB to use on your behalf.

This is deliberate, not a bug. Kerberos and NTLM both authenticate you to the remote machine without giving that machine a copy of your credentials, which is exactly what stops a compromised intermediate server from impersonating you everywhere else on the network. It just means the second hop needs one of a small number of documented workarounds.

For a domain admin managing domain controllers, CredSSP is the pragmatic default Microsoft itself points to, precisely because the environment is already highly trusted. For anything less trusted, resource-based Kerberos constrained delegation is the modern recommended path: it is configured entirely with PowerShell against Active Directory, and it doesn’t require anyone to hold Domain Admin rights.

Configuring WinRM

On Windows Server this is usually already done for you. On workstations, or a server where remoting was previously disabled, you enable it explicitly.

# Enable PowerShell Remoting: starts WinRM, sets it to auto-start,
# creates a default HTTP listener, and opens the firewall exception
Enable-PSRemoting -Force

# Equivalent low-level command using the WinRM tool directly
winrm quickconfig

# Create an HTTPS listener as well (requires a suitable certificate
# and TCP 5986 open separately)
winrm quickconfig -transport:https

# Add a specific server to this client's trusted hosts (needed for
# NTLM auth by IP address, or workgroup machines with no Kerberos)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "server02.contoso.com" -Concatenate -Force

# Confirm what is currently in TrustedHosts
Get-Item WSMan:\localhost\Client\TrustedHosts

Scripts / Commands

The commands below cover connecting, running remote work at scale, and setting up the double-hop workarounds from the section above.

# Quick connectivity check before anything else
Test-WSMan -ComputerName Server01

# Start an interactive session on one remote computer
Enter-PSSession -ComputerName Server01 -Credential Domain01\User01

# Leave the interactive session (or just type exit)
Exit-PSSession

# Run a single command against several computers at once
Invoke-Command -ComputerName Server01, Server02, Server03 -ScriptBlock {
    Get-Service -Name W32Time
}

# Cap concurrent connections for a large fan-out (32 is the default anyway)
Invoke-Command -ComputerName (Get-Content .\servers.txt) -ThrottleLimit 20 -ScriptBlock {
    Get-CimInstance Win32_OperatingSystem | Select-Object Caption, LastBootUpTime
}

# Create persistent sessions once, then reuse them for multiple calls
$sessions = New-PSSession -ComputerName Server01, Server02
Invoke-Command -Session $sessions -ScriptBlock { Get-Process powershell }
Invoke-Command -Session $sessions -ScriptBlock { Get-Process pwsh }

# List sessions you currently have open, and tear them down when done
Get-PSSession
Remove-PSSession -Session $sessions

# Run a remote command as a background job on many servers
Invoke-Command -ComputerName Server01, Server02 -AsJob -JobName FleetCheck -ScriptBlock {
    Get-EventLog -LogName System -Newest 5
}
Get-Job -Name FleetCheck | Receive-Job

# Enable CredSSP for the double-hop problem (client side, then server side)
Enable-WSManCredSSP -Role Client -DelegateComputer "server02.contoso.com"
Enable-WSManCredSSP -Role Server

# Use CredSSP on a connection once both sides allow it
Invoke-Command -ComputerName Server02 -Credential $cred -Authentication Credssp -ScriptBlock {
    Test-Path \\Server03\Share
}

# Resource-based Kerberos constrained delegation instead of CredSSP:
# grant ServerB the right to delegate to ServerC
$ServerB = Get-ADComputer -Identity ServerB
$ServerC = Get-ADComputer -Identity ServerC
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

Enter-PSSession vs Invoke-Command vs New-PSSession

Troubleshooting Cheat Sheet

Final Thoughts

PowerShell Remoting is what turns a fleet of servers into something one engineer can actually manage. WinRM handles the transport, Enter-PSSession and Invoke-Command give you the two shapes of remote execution most work needs, and the double-hop problem is the one gotcha worth understanding before it shows up as a confusing access-denied error in someone else’s script.

Once remoting is configured, the same object pipeline you use locally, filtering, sorting, exporting, works exactly the same way on remote output. That consistency is why remoting sits underneath so much of enterprise PowerShell automation, from health checks to Active Directory reporting.