Remoting and Sessions

## What remoting actually sets up PowerShell remoting works by starting a *runspace* — a live PowerShell engine — on the remote machine and exchanging serialized objects with it over a transport (WS-Man/WinRM by default, or SSH). Every remoting cmdlet is a different way of driving that remote runspace. The two you meet first are `Enter-PSSession` and `Invoke-Command`, and the difference between them is simply **who types the commands**: you, at a prompt, or a script block you wrote in advance. ## Enter-PSSession: the interactive prompt ```powershell Enter-PSSession -ComputerName Server01 # prompt becomes: [Server01]: PS C:\Users\me\Documents> Get-Service -Name Spooler exit ``` While you are inside, everything you type is executed on the remote host and the rendered output is sent back for display. The prompt prefix `[Server01]:` is the visible cue that you are no longer local — forgetting that is how people run a destructive command on the wrong box. You leave with `exit` or `Exit-PSSession`. `Enter-PSSession` targets **one** machine. Its `-ComputerName` parameter takes a single string, not an array, because an interactive console cannot sensibly be attached to fifty hosts at once. It is the tool for exploration, poking at a misbehaving server, or checking something you cannot yet express as a script. ## Invoke-Command: the scripted one ```powershell Invoke-Command -ComputerName Server01, Server02, Server03 -ScriptBlock { Get-Service -Name Spooler } | Sort-Object PSComputerName ``` Here the code is fixed up front. Each host runs the script block and returns its output; the results arrive in your **local** session as ordinary pipeline input, so you can `Where-Object`, `Sort-Object`, `Export-Csv` them locally. PowerShell tags each returned object with a `PSComputerName` property so you can tell whose result is whose — essential once you target more than one machine. `Invoke-Command` fans out in parallel across the computers you give it, so contacting many hosts is roughly as fast as contacting the slowest one, not the sum of all of them. ## The variable trap The script block is *shipped* to the remote host, so it does not close over your local variables: ```powershell $svc = 'Spooler' Invoke-Command -ComputerName Server01 -ScriptBlock { Get-Service -Name $svc } # $svc is empty remotely Invoke-Command -ComputerName Server01 -ScriptBlock { Get-Service -Name $using:svc } # correct ``` The `$using:` scope modifier tells PowerShell to capture the local value and send it along. The alternative is `-ArgumentList` together with a `param()` block inside the script block. Both are fine; `$using:` is shorter. ## -FilePath is read locally ```powershell Invoke-Command -ComputerName Server01 -FilePath .\Collect-Inventory.ps1 ``` This reads the file **on your machine** and sends its contents to run remotely. The script does not need to exist on the target, and does not need to be copied there first — a point people frequently get backwards. ## Both can ride on an explicit session Neither cmdlet is tied to `-ComputerName`. If you have created a session with `New-PSSession`, both accept it via `-Session`, which lets you reuse one connection and keep state between calls: ```powershell $s = New-PSSession -ComputerName Server01 Invoke-Command -Session $s -ScriptBlock { $x = 42 } Enter-PSSession -Session $s # $x is still there ``` ## Choosing between them Use `Enter-PSSession` when you do not yet know what you want to run, on a single host, and a human is watching. Use `Invoke-Command` for anything repeatable, anything touching more than one machine, and anything whose output you want to process — because its results come back as objects in your own session rather than as text on a remote screen. An interviewer asking this is checking that you understand remoting returns *data to you*, rather than merely giving you a remote terminal.