Remoting was the most eagerly awaited feature in PowerShell v2. As a result, PowerShell's capabilities reached new heights. The following excerpt, provided by Manning Publications, describes the forms of remote control. It is based on chapter 10 of PowerShell in Depth, by Don Jones, Richard Siddaway and Jeffery Hicks.
Want the whole thing? Manning Publications is offering a 40% discount on PowerShell in Depth to TechTarget readers. Use the promotional code 12pidtt at manning.com; if you buy the print book, the e-book is free.
Remoting was one of the major new technologies introduced in PowerShell v2 and in the broader Management Framework Core v2 that PowerShell is a part of. With v3, Microsoft has continued to invest in this important foundational technology.
The first thing we need to clear up is some of the confusion over the word “remote.” Essentially, PowerShell v2 offers two means for connecting to remote computers:
- Cmdlets which have their own –computerName parameter. These utilize proprietary communications protocols, most often DCOM or RPC, and are generally limited to a single task. These do not use PowerShell Remoting (with a couple of exceptions).
- Cmdlets that specifically use the Remoting technology: Invoke-Command, anything with the –PSSession noun, and a few others.
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 utilized through remoting.
So what exactly is remoting? Quite simply, it’s the ability to send one or more commands over the network to one or more remote computers. The remote computers execute the commands 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 those 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 later 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 take care of getting the data across the network.
Terminology gets a lot of people messed up when it comes to remoting, so let’s get that out of the way.
- WS-MAN is the network protocol used by 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. WS-MAN is a flavor of good old HTTP, the same protocol your Web browser uses to fetch Web pages from a Web server.
- Windows Remote Management, or WinRM, is a Microsoft service that implements the WS-MAN protocol and that handles communications and authentication for connections. WinRM is actually 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 applications could certainly have their own specific uses for WinRM.
One of the new features in PowerShell v3 is a set of Common Information Model (CIM) cmdlets. Over time, these will 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 functionality. Both sets of cmdlets utilize the same underlying WMI data repository; one of the primary differences between the two sets is in how they communicate over the network. The WMI cmdlets use Remote Procedure Calls (RPCs), while the CIM cmdlets use WinRM. The CIM cmdlets do not use remoting—they provide their own utilization of WinRM. We point this out only as an example of how confusing the terminology can be. In the end, you don’t necessarily need to worry about it all the time, but, when it comes to troubleshooting, you’ll definitely need to understand which bits are using what.
Now for a bit more terminology, this time diving into some of the specific implementation details:
- An endpoint is a particular configuration item in WinRM. An endpoint represents a specific application that WinRM can receive traffic for, along with a group of settings that determine how the endpoint behaves. It’s entirely possible for a single application, like PowerShell, to have multiple endpoints set up. Each endpoint might be for a different purpose, and might have different security, network settings, and so forth associated with it.
- A listener is another configuration item in WinRM, and 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 forth. A listener also is set up to use either HTTP or HTTPS; if you want to be able to use both protocols, then you would have two listeners set up.
In the next few sections, we’re going to walk you through the complete process of setting up and using Remoting. This will specifically cover the “easy scenario,” meaning that both your computer and the remote computer are in the same Active Directory domain.
There are two levels of authentication in WinRM: machine level and user level. User-level authentication involves the delegation of your logon credential to the remote machine that you’ve connected to. The remote machine can thus undertake any tasks you’ve specified using your identity, meaning you’ll be able to do whatever you have permission to do, and no more. By default, the remote machine cannot delegate your credentials to any other machines, which can lead to a problem called “the second hop.”
Remoting also supports machine-level authentication. In other words, when you connect to a remote machine, your computer must trust that machine. Trust normally comes through mutual membership in an Active Directory domain, although it can also be manually configured in a number of ways. The practical upshot, however, is that your computer will refuse to connect to any remote machine that it doesn’t know and trust. That can create complications for some environments where the machines aren’t all in the same domain, requiring additional configuration to get remoting to work.
Firewalls and security
One of the joys of remoting is that it operates over a single port: 5985 for HTTP and 5986 for HTTPS, by default, although you can reconfigure those if you like. It’s therefore pretty easy to set up firewall exceptions that permit Remoting traffic.
Some organizations, mainly those with very tight network security, may have some trepidation about enabling Remoting and its firewall exceptions. Our only advice is to “get over it.” Remoting is now a foundational, mandatory technology in Windows. Not allowing it would be like not allowing Ethernet. Without remoting, you’ll find that many of Windows’ administrative tools and features simply don’t work.
Remoting actually is more secure than what we’ve used in the past for these tasks. It authenticates, by default, using the Kerberos protocol, which never transmits passwords on the network (encrypted or otherwise). Remoting uses a single, customizable port, rather than the thousands required by older protocols like RPCs. WinRM and remoting have a huge variety of configuration settings that let you control who can use it, how much they can use it, and so on.
This was first published in June 2012