I saw a tweet from Don Jones this week that pointed to a free ebook that he and Tobias Weltner wrote on PowerShell Remoting called, aptly enough, ‘Secrets of PowerShell Remoting’ (find it under the “Freebies” section). Its a great book to have and refer too often. The book covers much of the advanced functionality of Remoting as well but don’t let that put you off. The first 17 pages are the most critical to getting an understanding and too begin utilizing it. Follow-up with the rest of it as you need it.

If there is any single feature of PowerShell that is “hero” making it is Remoting. Once you’ve used it, particularly once you’ve used it perform a routine administrative task or quickly solve a problem, you will become “power mad”. There are really only 3 cmdlets that you need to know to use Remoting; Enter-PSSession, New-PSSession, and Invoke-Command. There is also one for enabling Remoting (Enable-PSRemoting) the ebook above covers the setup aspects nicely. You can also pull up your trusty help for that cmdlet. I’ll touch on utilizing the Remoting not the setup.

You really have two modes when it comes to Remoting in PowerShell, interactive and session based. To use PowerShell Remoting interactively on another system you use the Enter-PSSession cmdlet. Simply use the -ComputerName parameter of the cmdlet and the name of the remote system.

You now have a PowerShell session on the remote system much the same way you have a console session open on your local system. You can utilize all the PowerShell cmdlets and code you know and love. You can see when logged into a remote session your command prompt changes to indicate which system your remoted into and operating on.

Enter-PSSession is good for one off tasks, and investigative troubleshooting type work. It’s kind of an SSH for PowerShell.

The other two important Remoting cmdlets are kind of a matched set, Invoke-Command and New-PSSession. Invoke-Command can be used independantly but it has some limitations. Independently you can utilize the -ComputerName parameter to point it at a remote system and execute a scriptblock (simply speaking PowerShell code enclosed in squigly braces {}) using the -ScriptBlock parameter.

You can see it returned the same directory output that I got while remoted in via Enter-PSSession. However this time it returned the output to my PowerShell console locally. You can see the added column ‘PSComputerName’, identifying which computer it came back from.

In the next example  using the Invoke-Command in this fashion does not preserve any session. When I invoke the first command to create the $Greeting variable it creates it, as I don’t get any errors, however the next time I execute a command to use $Greeting I get nothing. This is a one-hit wonder kind of Remoting cmdlet; execute my code remotely, give me the output and thank you very much.

The real power of PowerShell Remoting comes into play and is made possible by the New-PSSession cmdlet. The simplest way to use the New-PSSession cmdlet is to feed it some computer names using the ubiquitious -ComputerName parameter. Pass a bundle of your computer names seperated by commas and your good to go. Save the output to a variable and then use that variable with the Invoke-Command -Session parameter. Try using the $Greeting again and you will see what a difference a session makes.

I absolutely love these cmdlets. While these examples are simple you can execute just about anything in that scriptblock and utilize any module or object that is available on those remote systems. I’ve used these extensively with IIS and the WebAdministration module that comes with Windows Server 2008. You simply establish your session, import the WebAdministration module, then execute any PowerShell in those sessions that you would normally execute on each system. For instance you can exeute the same configuration commands, recycle the app pools all at once, or just use the IIS: provider to query the system and return that data to your local console for further analysis. The same can be achieved for SharePoint, or Exchange, or any environment where you have multiple similar systems. Simply create session variables for your bundle of systems as you need them and execute PowerShell at scale!

While I mentioned at the start there are only 3 important cmdlets for Remoting there are really a few others as well, namely Exit-PSSession, and Remove-PSSession. Those correlate to the Enter-PSSession and New-PSSession and should be pretty obvious as to the usage. It is important to clean up after you are through using Remoting. There are some gotchas and limitations with Remoting as far as number of sessions and what can and can’t be returned object wise via Remoting, the ebook covers these very well and will obviously help you get the most out of Remoting but are not pertinent to getting your feet wet.

If PowerShell is the future (that’s a weak “if”, it really is the future) then PowerShell Remoting is the reason WHY it is the future. One of the first things you should learn after you get the basics of PowerShell and the pipeline is Remoting. It is what will take you from a “hero”, to an Iron Man strolling through your network, Repulsor ™ blasting every administration nightmare you come across. It really is that cool!

Joel.