49The many forms of remote control

Remoting is a complex technology, and we’ll do our best to explore it as thoroughly as possible. But some uses for Remoting are outside the purview of an administrator: Programming custom-constrained runspaces, for example, requires software develop- ment skills that are outside the scope of this book.

NOTE Everything in this chapter focuses on PowerShell v4 and v3, but the majority of the material also applies to v2. The three versions of the shell can talk to each other via Remoting—that is, a v2 shell can connect to a v3 or v4 shell, and vice versa. PowerShell Remoting between v3 and v4 works seamlessly.

10.1

The many forms of remote control

The first thing we need to clear up is the confusion over the word remote. PowerShell v2 offers two means for connecting to remote computers:

 Cmdlets, which have their own –ComputerName parameter. They use their own proprietary communications protocols, most often DCOM or RPC, and are gen- erally limited to a single task. They don’t use PowerShell Remoting (with a cou- ple of exceptions that we’ll cover later in this chapter).

 Cmdlets that specifically use the Remoting technology: Invoke-Command, any- thing with the –PSSession noun, and a few others that we’ll cover in this chapter. In this chapter, we’re focusing exclusively on the second group. The nice thing about it is that any cmdlet—whether it has a –ComputerName parameter or not—can be used through Remoting.

NOTE PowerShell v3 introduced another type of Remoting: CimSessions. These are analogous to PowerShell Remoting sessions and also work over WSMAN by default. They are covered in detail in chapter 39.

What exactly is Remoting? It’s the ability to send one or more commands over the net- work to one or more remote computers. The remote computers execute the com- mands using their own local processing resources (meaning the command must exist and be loaded on the remote computers). The results of the commands—like all PowerShell commands—are objects, and PowerShell serializes them into XML. The XML is transmitted across the network to the originating computer, which deserializes

them back into objects and puts them into the pipeline. The serialize/deserialize part of the process is crucial, because it offers a way to get complex data structures into a text form that’s easily transmitted over a network. Don’t overthink the serializing thing, though: It’s not much more complicated than piping the results of a command to Export-CliXML and then using Import-CliXML to load the results back into the pipeline as objects. It’s almost exactly like that, in fact, with the additional benefit of having Remoting taking care of getting the data across the network.

PowerShell Web Access (PWA—Microsoft uses PSWA but the PowerShell commu- nity prefers PWA as an acronym) was introduced in Windows Server 2012 and enhanced in Windows Server 2012 R2. PWA is covered in appendix B. PWA uses Power- Shell Remoting “under the hood.” It’s best to consider PWA as a presentation layer superimposed on PowerShell Remoting, which is why we don’t cover it here.

10.2

Remoting overview

Terminology gets a lot of people messed up when it comes to Remoting, so let’s get that out of the way.

 WSMAN is the network protocol used by PowerShell Remoting. It stands for Web Services for Management, and it’s more or less an industry-standard protocol. You can find implementations on platforms other than Windows, although they’re not yet widespread. WSMAN is a flavor of good-old HTTP, the same pro- tocol your web browser uses to fetch web pages from a web server.

 Windows Remote Management, or WinRM, is a Microsoft service that implements the WSMAN protocol and that handles communications and authentication for connections. WinRM is designed to provide communications services for any number of applications; it isn’t exclusive to PowerShell. When WinRM receives traffic, that traffic is tagged for a specific application—such as PowerShell—and WinRM takes care of getting the traffic to that application as well as accepting any replies or results that the application wants to send back.

 Remoting is a term applied to PowerShell’s use of WinRM. Therefore, you can’t do “Remoting” with anything other than PowerShell—although other applica- tions could certainly have their own specific uses for WinRM.

One of the features introduced in PowerShell v3 was a set of Common Information Model (CIM) cmdlets. Over time, they’ll replace the legacy Windows Management Instrumentation (WMI) cmdlets that have been in PowerShell since v1, although for now the WMI and CIM cmdlets live side by side and have a lot of overlapping function- ality. Both sets of cmdlets use the same underlying WMI data repository; one of the pri- mary differences between the two sets is in how they communicate over the network. The WMI cmdlets use remote procedure calls (RPCs), whereas the CIM cmdlets use WinRM. The CIM cmdlets aren’t using Remoting —they provide their own utilization of WinRM (more details in chapter 39). We point this out only as an example of how confusing the terminology can be. In the end, you don’t have to worry about it all the time, but when it comes to troubleshooting you’ll definitely need to understand which parts are using what.

Now for a bit more terminology, this time diving into some of the specific imple- mentation details:

 An endpoint is a particular configuration item in WinRM. An endpoint repre- sents a specific application for which WinRM can receive traffic, along with a group of settings that determine how the endpoint behaves. It’s entirely possi- ble for a single application, like PowerShell, to have multiple endpoints set up. Each endpoint might be for a different purpose and might have different secu- rity, network settings, and so forth associated with it.

 A listener is another configuration item in WinRM, and it represents the service’s ability to accept incoming network traffic. A listener is configured to have a TCP port number, is configured to accept traffic on one or more IP addresses, and so

51