Chapter 13: Remote control: One-to-one and one-to-many
Introduces PowerShell remoting as a shell-wide way to run commands on other computers without requiring every cmdlet to provide its own remote-connection parameter.
After this chapter you will be able to
- Shell-wide remoting capability. Explain why PowerShell has a shell-wide remoting system and what it lets you run on another computer, including commands not installed locally.
- Remote command execution and results. Explain that a remote PowerShell command runs on the remote computer, while only its results come back to your computer.
- Windows remoting transport and service. Explain that PowerShell remoting on Windows uses WSMan over HTTP by default or HTTPS, and that Microsoft provides WSMan through the WinRM background service. Distinguish WinRM being installed by default on the specified Windows versions from the service being enabled.
- SSH for PowerShell remoting. Explain why PowerShell uses SSH for remoting on macOS and Linux, and describe its availability on Windows.
- Remote object serialization. Trace how output from a remote command becomes usable on the local computer: PowerShell serializes output objects into XML, sends the XML over the network, and deserializes it back into objects.
- Deserialized object limitations. Explain why returned remote objects are point-in-time snapshots rather than live objects, and why you cannot use those returned objects to perform actions such as stopping a process.
- PSRP over SSH setup sequence. Describe the setup sequence: ensure the SSH server and client are available, install the module that enables PSRP over SSH, enable PSRP over SSH, and restart the OpenSSH service. Note that macOS already has the SSH client and that the server-enabling and service-restart instructions differ by platform.
- Windows SSH remoting setup. Describe the Windows setup steps given for PowerShell remoting over SSH: install OpenSSH, check the firewall rule, edit the target machine’s SSH configuration, and restart the service.
- Receiving Computer Configuration. Explain that PSRP over SSH and PowerShell remoting need to be configured on computers that will receive incoming commands, rather than on every computer issuing them.
- SSH Listener and Subsystem Routing. Describe how the sshd listener receives incoming traffic and routes PSRP connections to PowerShell registered as an SSH subsystem.
- WinRM listeners and endpoints. Explain how a WinRM listener receives incoming traffic and how WinRM routes that traffic to a registered endpoint, such as PowerShell.
- Enabling receiving computers. Describe where remoting must be enabled and what running Enable-PSRemoting as an administrator configures on a Windows computer.
- One-to-one remoting model. Explain that one-to-one remoting gives you a shell prompt on one remote computer, where commands run and results appear in your shell window.
- Session connection and exit. Describe how to choose the connection parameter, recognize an established session, and leave it with Exit-PSSession.
- One-to-many command execution. Explain how Invoke-Command runs a command on multiple remote computers and returns their results. Describe what happens when the number of computers exceeds the default concurrency limit.
- Nested remote command braces. Distinguish the outer curly braces that enclose work sent to remote computers from braces used by a Where-Object command nested inside them.
- Computer names from files. Explain how a text file of computer names can supply the -HostName parameter without typing a comma-separated list each time.
- Remote Object Method Limitations. Explain why objects returned by remoting usually cannot perform actions locally, and where to put commands that need their methods.
- Remote filtering and network traffic. Explain how the placement of a filter changes where it runs and how much data crosses the network. Describe why filtering on each remote computer is more efficient than filtering all results locally.
- Remote actions and returned objects. Explain why an action such as Stop-Process should run on the remote computer along with Get-Process, rather than be applied locally to its returned result. State what kinds of work the section considers appropriate for returned Invoke-Command results.
- Security restrictions on remoting. Explain why PowerShell remoting may be unavailable under restrictive company policies and what exceptions an administrator should check for.
- Separate invocation state. Describe what happens to PowerShell between remote command invocations and how to run a related series of commands that depend on one another.
What it builds on
- What are objects? (chapter 8) · Introduces the PowerShell objects that commands produce.
- Using object actions, or methods (chapter 8) · Introduces actions that can be performed with objects.
- Filtering objects out of the pipeline (chapter 12) · Introduces filtering objects with Where-Object.
- Parenthetical commands (chapter 10) · Introduces using parentheses to run a command before supplying its result elsewhere.
Section by section
Introduction
Introduces PowerShell remoting as a shell-wide way to run commands on other computers without requiring every cmdlet to provide its own remote-connection parameter.
- Shell-wide remoting capability: Explain why PowerShell has a shell-wide remoting system and what it lets you run on another computer, including commands not installed locally.
Why it matters: You can administer a remote computer without installing every administrative cmdlet on your own workstation.
Key terms: remoting, cmdlet, Invoke-Command, -ComputerName
13.1 The idea behind remote PowerShell
This section explains where a remote PowerShell command runs and what returns to the user's computer.
- Remote command execution and results: Explain that a remote PowerShell command runs on the remote computer, while only its results come back to your computer.
Why it matters: This distinction helps you understand what remote commands affect and what you see locally.
Key terms: remote PowerShell, remote computer, results
13.1.1 Remoting on Windows devices
Explains the protocol and Windows service behind PowerShell remoting on Windows devices.
- Windows remoting transport and service: Explain that PowerShell remoting on Windows uses WSMan over HTTP by default or HTTPS, and that Microsoft provides WSMan through the WinRM background service. Distinguish WinRM being installed by default on the specified Windows versions from the service being enabled.
Why it matters: This explains what carries a remote PowerShell connection on Windows and why an installed WinRM service may still need enabling.
Key terms: Web Services for Management (WSMan), HTTP, HTTPS, Windows Remote Management (WinRM), group policy
13.1.2 Remoting on macOS and Linux devices
Explains why PowerShell remoting on macOS and Linux uses SSH and notes that SSH can also be used for remoting into Windows.
- SSH for PowerShell remoting: Explain why PowerShell uses SSH for remoting on macOS and Linux, and describe its availability on Windows.
Why it matters: It explains why SSH is the remoting option discussed for non-Windows devices and why it can also apply to Windows.
Key terms: WSMan, WinRM, Secure Shell (SSH), OpenSSH, PowerShell remoting protocol (PSRP)
13.1.3 Cross-platform remoting
This section explains how remote PowerShell returns objects, why those objects have limitations, and what setup is needed to follow the remoting examples.
- Remote object serialization: Trace how output from a remote command becomes usable on the local computer: PowerShell serializes output objects into XML, sends the XML over the network, and deserializes it back into objects.
Why it matters: This explains why remote output looks like objects locally even though it traveled over the network as XML. - Deserialized object limitations: Explain why returned remote objects are point-in-time snapshots rather than live objects, and why you cannot use those returned objects to perform actions such as stopping a process.
Why it matters: It prevents you from treating returned remote results as live, controllable processes. - Remoting example prerequisites: State the version requirement for both computers and distinguish the recommended domain arrangement from a strict requirement; describe the localhost fallback for following the examples without a second computer.
Why it matters: These conditions help you choose a workable setup for the chapter’s remoting examples.
Key terms: serialization, deserialization, XML, output objects, deserialized objects, snapshots, memory usage, CPU utilization, PowerShell v7.1, domain
13.2 Setting up PSRP over SSH
13.2.1 macOS and Linux
This subsection outlines the macOS and Ubuntu setup sequence for PSRP over SSH.
- PSRP over SSH setup sequence: Describe the setup sequence: ensure the SSH server and client are available, install the module that enables PSRP over SSH, enable PSRP over SSH, and restart the OpenSSH service. Note that macOS already has the SSH client and that the server-enabling and service-restart instructions differ by platform.
Why it matters: These are the prerequisites and steps the section gives before using PSRP over SSH.
Key terms: SSH server, SSH client, PSRP over SSH, OpenSSH service
13.2.2 Setting up SSH on Windows
This section outlines how to set up PowerShell remoting over SSH on Windows and cautions readers to secure the SSH server and private key.
- Windows SSH remoting setup: Describe the Windows setup steps given for PowerShell remoting over SSH: install OpenSSH, check the firewall rule, edit the target machine’s SSH configuration, and restart the service.
Why it matters: These are the Windows-side preparations the section gives before using PowerShell remoting over SSH. - SSH server and key security: State the section’s security caution for an SSH server and its guidance about private-key authentication.
Why it matters: Getting SSH running is not the same as securing the server and its credentials.
Key terms: OpenSSH client and server, OpenSSH-Server-In-TCP, sshd_config, Subsystem for PowerShell, OpenSSH service, OpenSSH, private-key authentication, private key
13.3 PSRP over SSH overview
The section explains where PSRP-over-SSH remoting must be enabled and how SSH routes incoming PowerShell connections.
- Receiving Computer Configuration: Explain that PSRP over SSH and PowerShell remoting need to be configured on computers that will receive incoming commands, rather than on every computer issuing them.
Why it matters: This tells you which machines need preparation before they can receive remote commands. - SSH Listener and Subsystem Routing: Describe how the sshd listener receives incoming traffic and routes PSRP connections to PowerShell registered as an SSH subsystem.
Why it matters: It explains how an incoming SSH connection reaches PowerShell without requiring a separate SSH port for PowerShell.
Key terms: PSRP over SSH, PowerShell remoting, incoming commands, sshd listener, subsystem, PSRP, PowerShell, endpoint
13.4 WinRM overview
This section explains how WinRM receives and routes remote commands, how to enable PowerShell remoting on Windows, and two practical configuration considerations.
- WinRM listeners and endpoints: Explain how a WinRM listener receives incoming traffic and how WinRM routes that traffic to a registered endpoint, such as PowerShell.
Why it matters: This explains why receiving PowerShell commands requires more than simply having WinRM running. - Enabling receiving computers: Describe where remoting must be enabled and what running Enable-PSRemoting as an administrator configures on a Windows computer.
Why it matters: It identifies the machines to configure and the command that performs the necessary setup. - Public network firewall restriction: Explain why Enable-PSRemoting can fail when a network connection is set to Public and describe the section’s security warning about changing that setting.
Why it matters: It helps diagnose a common setup failure without suggesting an unsafe fix on a public network. - Group Policy configuration alternative: Describe Group Policy as an alternative to running Enable-PSRemoting separately on each computer, and identify where the section points readers for its settings.
Why it matters: It offers an administrative alternative when configuring remoting across many computers.
Key terms: WinRM, listener, endpoint, session configurations, Enable-PSRemoting, Set-WSManQuickConfig, WinRM service, Windows Firewall exception, Public, Work
13.5 Using Enter-PSSession and Exit-PSSession for one-to-one remoting
This section explains how to enter, use, and leave a one-to-one PowerShell remoting session, including its limits and common pitfalls.
- One-to-one remoting model: Explain that one-to-one remoting gives you a shell prompt on one remote computer, where commands run and results appear in your shell window.
Why it matters: It helps you keep track of which computer your commands affect. - Session connection and exit: Describe how to choose the connection parameter, recognize an established session, and leave it with Exit-PSSession.
Why it matters: The parameter and prompt tell you how you connected and whether you are still working remotely. - Remote identity and profile: Explain whose permissions apply to commands in the remote session and what happens to a remote profile script on connection.
Why it matters: It explains both the permissions you have and why familiar profile-based setup may be missing. - Remote chaining caution: Explain why the section warns against starting another Enter-PSSession while already at a remote prompt.
Why it matters: Watching the prompt helps you avoid an accidental chain of remote connections. - Direct remote object processing: Explain why commands piped together within a one-to-one remote session work as though typed at the remote computer’s console.
Why it matters: It lets you reason about a pipeline in the remote prompt much like one run directly on that computer.
Key terms: one-to-one remoting, shell prompt, -HostName, -ComputerName, SSH, WinRM, Enter-PSSession, Exit-PSSession, credentials, PowerShell profile script
13.6 Using Invoke-Command for one-to-many remoting
This section shows how Invoke-Command sends work to multiple remote computers and explains the syntax for commands, scripts, and computer lists.
- One-to-many command execution: Explain how Invoke-Command runs a command on multiple remote computers and returns their results. Describe what happens when the number of computers exceeds the default concurrency limit.
Why it matters: This lets you run the same work across many computers without addressing each one separately. - Nested remote command braces: Distinguish the outer curly braces that enclose work sent to remote computers from braces used by a Where-Object command nested inside them.
Why it matters: Recognizing which braces contain the remote work helps prevent sending the wrong command. - Remote script file option: Describe the alternative to supplying a command in a script block: specifying a local script file for Invoke-Command to send to remote computers.
Why it matters: A script file offers a way to send more complex work than a command typed directly. - Computer names from files: Explain how a text file of computer names can supply the -HostName parameter without typing a comma-separated list each time.
Why it matters: A reusable list saves retyping hostnames when you repeatedly target the same group of computers.
Key terms: Invoke-Command, one-to-many, 1:N remoting, -throttleLimit, curly braces, Where-Object, -ScriptBlock, script file, -HostName, Get-Content
13.7 Differences between remote and local commands
Introduces a forthcoming comparison of Invoke-Command with local command execution and other forms of remote connectivity.
13.7.1 Deserialized objects
Explains why objects returned by remoting lose most methods and why actions on them should run on the remote computer.
- Remote Object Method Limitations: Explain why objects returned by remoting usually cannot perform actions locally, and where to put commands that need their methods.
Why it matters: It helps you put an action where the object can still perform it.
Key terms: deserialized objects, methods, read-only copy, script block
13.7.2 Local vs. remote processing
This section explains why processing should happen on the remote computer before Invoke-Command returns results, especially when filtering data or changing remote processes.
- Remote filtering and network traffic: Explain how the placement of a filter changes where it runs and how much data crosses the network. Describe why filtering on each remote computer is more efficient than filtering all results locally.
Why it matters: Where you put the filter can greatly reduce the data sent over the network. - Remote actions and returned objects: Explain why an action such as Stop-Process should run on the remote computer along with Get-Process, rather than be applied locally to its returned result. State what kinds of work the section considers appropriate for returned Invoke-Command results.
Why it matters: Keeping actions remote helps prevent a command intended for another computer from acting on yours.
Key terms: Invoke-Command, Where, serialized, deserialized, Get-Process, Stop-Process, action cmdlets
13.8 But wait, there’s more
This section contrasts hostname-based ad hoc remoting with reusable connections and explains how security restrictions can affect remoting.
- Ad hoc and reusable connections: Distinguish the ad hoc connections used in the earlier examples from reusable connections, and explain when reusable connections might be useful.
Why it matters: It helps you recognize when repeatedly specifying hostnames may be less convenient than reusing a connection. - Security restrictions on remoting: Explain why PowerShell remoting may be unavailable under restrictive company policies and what exceptions an administrator should check for.
Why it matters: A blocked connection may reflect company policy rather than a problem with your PowerShell command.
Key terms: ad hoc remoting connections, hostnames, reusable, persistent connections, PowerShell remoting, security policies, firewalls, SSH, WinRM
13.9 Common points of confusion
This section explains two common remoting surprises: connection setup may need troubleshooting, and separate command invocations do not retain one another’s state.
- Remoting setup and troubleshooting: Explain when remoting will typically work without extra configuration and what to consult when it does not.
Why it matters: It gives you a first place to look when a remote connection does not work as expected. - Separate invocation state: Describe what happens to PowerShell between remote command invocations and how to run a related series of commands that depend on one another.
Why it matters: Putting dependent commands together prevents you from relying on state that a later invocation will not have.
Key terms: remoting, domain, about_remote_troubleshooting, invocation, remote computer, PowerShell
13.10 Lab
13.11 Lab answers
13.12 Further exploration
This section points readers to a free, periodically updated guide for more detailed PowerShell remoting configuration and troubleshooting.
Where this is used later
- Creating a process job (chapter 14) · Introduces PowerShell remoting.
- Creating and using reusable sessions (chapter 18) · Introduces remoting over SSH.
- Implicit remoting: Importing a session (chapter 18) · Importing a remote session builds on the idea of connecting to a PowerShell endpoint.
- Further exploration (chapter 16) · Creating and using a connection to a remote computer.
- (chapter intro) (chapter 18) · Introduces one-to-one remoting with Enter-PSSession.
- Enter-PSSession with session objects (chapter 18) · Builds on using Enter-PSSession to enter a remote session.
- Invoke-Command with session objects (chapter 18) · Uses Invoke-Command with reusable session objects.
- Remoting, as a job (chapter 14) · Using Invoke-Command for one-to-many remoting.
Concepts explained in this chapter
- Invoke-CommandInvoke-Command is a PowerShell cmdlet that runs commands or script blocks on local or remote computers.
- remotingRemoting is the execution of commands or management operations on a computer or service over a network connection.
- deserializationDeserialization is the conversion of a stored or transmitted representation back into an in-memory object or data structure.
- serializationSerialization is the conversion of an in-memory object or data structure into a representation suitable for storage or transmission.
- Enter-PSSessionEnter-PSSession is a PowerShell cmdlet that creates an interactive session with a local or remote computer.
- WinRMWinRM is Microsoft's Windows Remote Management service and protocol for transporting administrative communications between computers and applications.
- Exit-PSSessionExit-PSSession is a PowerShell cmdlet that ends the current interactive PowerShell session and returns to the originating shell.
- one-to-one remotingOne-to-one remoting is an interactive remoting mode that provides a shell session on a single remote computer.
- remote chainingRemote chaining is the practice of initiating a second remote connection from within an existing remote session.
- Enable-PSRemotingEnable-PSRemoting is a PowerShell cmdlet that configures a computer to receive PowerShell remoting connections.
- -scriptblock-ScriptBlock is an Invoke-Command parameter that specifies executable PowerShell statements to run remotely.
- Select-ObjectSelect-Object is a PowerShell cmdlet that selects specified properties or creates customized objects from input objects.
- Sort-ObjectSort-Object is a PowerShell cmdlet that orders input objects according to specified property values.
- script blockA script block is a PowerShell language construct that groups executable statements inside braces for invocation or deferred execution.
- methodA method is a callable operation associated with an object that can direct the object to perform an action.
- commandA command is an executable instruction that a shell can invoke to perform an operation.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.