Run commands on remote Windows machines using PowerShell Remoting and WinRM: enable and configure the service, use Enter-PSSession for interactive sessions and Invoke-Command for parallel scripted execution across server fleets.
PowerShell Remoting is like using remote control software (like TeamViewer) but instead of controlling the mouse, you send PowerShell commands. Enter-PSSession is like walking into the remote machine's PowerShell prompt—it's interactive. Invoke-Command is like sending a postcard with instructions to 50 different houses at once—all of them do the task and send you back a report.
WinRM (Windows Remote Management) is the Windows implementation of the WS-Management protocol. PowerShell Remoting uses WinRM as its transport. Default ports are 5985 (HTTP) and 5986 (HTTPS). Always use HTTPS in production.
Enter-PSSession creates an interactive remote session. Your prompt changes to [servername]: PS C:\>. Commands run on the remote machine. Exit-PSSession or exit ends the session.
Invoke-Command runs a script block on one or many remote machines. Pass a -ComputerName array for parallel execution. Results are deserialized objects—they look like the original type but are read-only copies (properties work, methods may not). Use this for ad-hoc queries and scripted management at scale.
Persistent sessions (New-PSSession) maintain state across multiple Invoke-Command calls. Use them when you need to keep state between operations or avoid the overhead of reconnecting many times.
HTTP remoting (port 5985) transmits credentials and command output unencrypted. In production environments, enable HTTPS (port 5986) with a valid certificate. For Azure VMs, use Just-In-Time (JIT) access or Azure Bastion rather than enabling WinRM on public IPs. Scan for open 5985 ports on your perimeter—exposed WinRM HTTP is a critical security finding.
Invoke-Command defaults to 32 simultaneous remote connections. For larger fleets, increase with -ThrottleLimit 50 or decrease to 10 on memory-constrained management servers. Sending commands to 200 servers with ThrottleLimit 32 will work in 7 parallel batches—expect roughly linear time scaling.
# Enable remoting (run as admin on the target)
Enable-PSRemoting -Force
# Test connectivity
Test-WSMan -ComputerName web01
# Interactive session
Enter-PSSession -ComputerName web01 -Credential (Get-Credential)
# Now running on web01:
Get-Service -Name IIS*
# Return to local:
Exit-PSSession
# Run a command on one remote machine
Invoke-Command -ComputerName web01 -ScriptBlock {
Get-Service -Name W3SVC
} -Credential $cred
# Run in parallel across multiple servers
$servers = @("web01", "web02", "web03", "web04")
$results = Invoke-Command -ComputerName $servers -ScriptBlock {
[PSCustomObject]@{
Computer = $env:COMPUTERNAME
IISRunning = (Get-Service W3SVC).Status -eq 'Running'
DiskFreePct= [math]::Round((Get-PSDrive C).Free / ((Get-PSDrive C).Free + (Get-PSDrive C).Used) * 100, 1)
}
} -ThrottleLimit 20
$results | Sort-Object Computer | Format-Table -AutoSize
# Pass variables into the remote session with $Using:
$threshold = 80
Invoke-Command -ComputerName $servers -ScriptBlock {
$drives = Get-PSDrive -PSProvider FileSystem
foreach ($d in $drives) {
$usedPct = [math]::Round($d.Used / ($d.Used + $d.Free) * 100, 1)
if ($usedPct -gt $Using:threshold) {
Write-Warning "$env:COMPUTERNAME - Drive $($d.Name): ${usedPct}% used"
}
}
}
# Persistent session for multiple operations
$session = New-PSSession -ComputerName web01 -Credential $cred
Invoke-Command -Session $session -ScriptBlock { Stop-Service W3SVC }
Copy-Item -Path .\app.zip -Destination C:\Deploy -ToSession $session
Invoke-Command -Session $session -ScriptBlock { Start-Service W3SVC }
Remove-PSSession $session
A platform team deploys a new version of a .NET application to 12 load-balanced IIS servers during a maintenance window. Using Invoke-Command in parallel: stop IIS on all servers simultaneously, copy the new build artifacts via Copy-Item with -ToSession (or file share), validate the archive hash on each server, extract and replace the application files, then start IIS on all servers. Total deployment time: under 3 minutes versus 30 minutes of sequential RDP sessions.
Enable-PSRemoting -Force on localhost (admin required) if not already enabled.Test-WSMan -ComputerName localhost to verify WS-Management is responding.Enter-PSSession -ComputerName localhost for an interactive local session and verify your prompt changes.Invoke-Command -ComputerName localhost -ScriptBlock { $env:COMPUTERNAME } to confirm remote execution returns the machine name.$Using:.Create a health-check function that uses Invoke-Command to query multiple machines (or localhost multiple times to simulate) and returns: computer name, uptime, available memory (MB), and whether the W3SVC or Spooler service is running. Store results in a variable and pipe to Format-Table -AutoSize. This is the template for real fleet health dashboards.
Problem: Invoke-Command to a server succeeds for Get-Service but fails with "WinRM cannot process the request" when you try to copy files or access a network share from the remote session.
Copy-Item -ToSession, then process them locally from the remote script.PowerShell Remoting lets you run commands on remote machines. It uses the WS-Management (WinRM) protocol over HTTP (port 5985) or HTTPS (port 5986). It is built into all modern Windows Server versions and can be enabled with Enable-PSRemoting.
Enter-PSSession creates an interactive session where you type commands and see results immediately. Invoke-Command runs a script block on one or many remote machines programmatically, returns results, and is suitable for automation scripts. Invoke-Command can target multiple machines simultaneously; Enter-PSSession targets one.
$Using: allows a script block in Invoke-Command to access local variables. Without it, $threshold inside a remote script block is undefined. With $Using:threshold, PowerShell serializes the local variable and passes it to the remote session.
Use Invoke-Command with all 30 servers in the -ComputerName array and -ThrottleLimit 30 to run in full parallel. Script block: stop the app service, use Copy-Item with -ToSession or a UNC path to copy the new build, start the service, verify it started. Results return as objects you can inspect for failures. Add error accumulation and fail the pipeline if any server reported an error.
This is the Kerberos double-hop problem. The remote session cannot forward credentials to a second network resource. Resolution options: copy files to the remote server first with Copy-Item -ToSession, use a service account pre-authorized on the file share, configure CredSSP delegation (with care—it exposes credentials), or use an Azure file share with a SAS token that does not require Kerberos.
Operations teams run weekly patch compliance checks with Invoke-Command across entire server fleets, collecting hotfix lists and comparing against required baselines. CI/CD pipelines use persistent sessions to stop services, deploy artifacts, and start services on multi-server IIS farms as part of zero-downtime blue-green deployments.
PowerShell Remoting over WinRM enables scripted management of remote machines without RDP. Enter-PSSession is interactive; Invoke-Command is scriptable and parallel. Pass variables with $Using:. Use persistent sessions for multi-step operations. Always use HTTPS in production. The double-hop limitation requires design decisions around credential delegation or pre-staged data. Invoke-Command is the core tool for fleet-scale automation.