PowerShell 2.0 remoting guide: Part 1 – The basics
I am starting a series of articles on remoting feature of PowerShell 2.0. This is one of the best features of PowerShell 2.0 and my favorite feature for sure. The number of very cool things one can achieve using this feature is just un-imaginable. I have started digging deep in to this feature as I start writing a network file browser powerpack as a part of hands-on. I hope it is worth sharing what I learn by writing about it here. So, this is the first in that series of posts. In this post, we will look at absolute basics to start using PowerShell remoting.
What is PowerShell remoting?
This is a new feature in PowerShell 2.0 that enables remote management of computers from a central location. Remoting uses WS-Management to invoke scripts and cmdlets on remote machine(s). This feature also enables what is known as “Universal Code Execution Model” in Windows PowerShell v2. UCEM means that whatever runs locally should run anywhere. PowerShell remoting lets you import remote commands in to a local session — a feature known as implicit remoting and also enables you to save or export these imported commands to local disk as a module for later use. There are bunch of other features such as interactive sessions, etc. We will look in to all these features but one thing at a time.
PowerShell remoting allows for multiple ways of connecting. These ways include interactive (1:1), fan-out (1:many), and fan-in (many:1 by using the IIS hosting model, Ex: MobileShell ). We will look at each of these methods in this series of articles on remoting.
To enable PowerShell remoting, all computers participating in remote management should have the following software.
PowerShell 2.0 and WinRM 2.0 are included as a part of Windows Management Framework download and hence is available for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. WinRM 2.0 and PowerShell 2.0 can be installed on the following supported operating systems:
To be able run scripts and commands on remote computers, the user performing remote script execution must be a member of the administrators group on the remote machine or should be able to provide administrator credentials at the time of remote execution. Also, on client versions of Windows such as Windows Vista and Windows 7, network location must be set either to Home or Work. WS-Management may not function properly if the network location is set to Public.
Here is the setup I have to experiment with PowerShell remoting. I will use these virtual machines and the Windows Server 2008 R2 OS to write my file browser PowerPack using PowerShell remoting. This will help me get a good coverage of all supported operating system families.
Jonathan Medd is currently writing a PowerShell cmdlet series in which he is talking about remoting cmdlets also. What I am going to write here is not a repeat of that. In the next post, we will look at how to configure the available systems to enable at an overview of PowerShell remoting cmdlets. I will also talk about various methods to enable PowerShell remoting. So, stay tuned..!Share on: