{"id":862,"date":"2010-04-20T00:00:00","date_gmt":"2010-04-20T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/new-remoting-features-in-powershell-2-0\/"},"modified":"2016-07-28T10:42:49","modified_gmt":"2016-07-28T10:42:49","slug":"new-remoting-features-in-powershell-2-0","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/sysadmin\/powershell\/new-remoting-features-in-powershell-2-0\/","title":{"rendered":"New Remoting Features in PowerShell 2.0"},"content":{"rendered":"
\n

PowerShell 1.0 was a fantastic leap forward for Windows-based administrators, enabling them to manage Microsoft products from the command line in a consistent and powerful way. However, one area which could possibly be considered weak, and which had many calls for improvement, was in the ability to remotely manage computers. Although the Get-WMIObject<\/b> cmdlet had remote functionality and there were other ways to get round running commands and scripts on remote computers, PowerShell 2.0 goes a long way to improve the experience. There are many more cmdlets that have built-in remoting functionality, and PowerShell 2.0 also adds full remoting capabilities with other servers.<\/p>\n

In the course of this article, I’m going to introduce you to some of this fantastic new functionality, point out why it’s such a huge leap forward from PowerShell 1.0, and take you on a whirlwind tour of some newfound powers at your fingertips. By the time we’re finished, I hope you’ll agree with me that PowerShell 2.0 remoting is a great piece of technology, and definitely something you should investigate more.<\/p>\n

New cmdlets with remoting functionality<\/h2>\n

In PowerShell 1.0, only the Get-WMIObject<\/b> cmdlet had the ComputerName<\/b> parameter available, enabling administrators to execute that cmdlet against remote machines. In PowerShell 2.0, this list has been extended to thirty five cmdlets with the ComputerName<\/b> parameter, including two of the most popular, Get-Process and Get-Service.<\/p>\n

Tip:<\/b> to quickly find which cmdlets have a ComputerName<\/b> parameter available, you can run the below command:<\/p>\n

Get-Command | Where-Object {$_.definition -match  'computername'}\n\n<\/pre>\n
It is important to note that the  remoting functionality used with the ComputerName parameter is not consistent  across all cmdlets, and is determined by the creator of the cmdlet. Most likely  it will not be using the technology which ‘full’ PowerShell remoting takes  advantage of, and will typically be using something like RPC instead.<\/p>\n
Great examples of this enhanced functionality are the  Get-Service <\/b> and Set-Service<\/b> cmdlets, which now make it possible to  query services on a remote computer and then manipulate them. To demonstrate:  the following command queries the Print<\/b> Spooler<\/b> service on the  remote machine Test01<\/b>:<\/p>\n
Get-Service Spooler  -ComputerName Test01\n<\/pre>\n
We observe that this service currently has a status of  Stopped<\/b>. By running the same command again, and this time piping it through  to the Set-Service<\/b> cmdlet and using the Status<\/b> parameter to apply  a status of Running<\/b>, we observe that this service has now started:<\/p>\n
Get-Service Spooler  -ComputerName Test01 |  Set-Service -Status Running\n<\/pre>\n
\"1007-JM1.JPG\"<\/p>\n
Fig 1. – A successful start of the Print Spool service  using PowerShell 2.0<\/p>\n
Previously, in PowerShell 1.0, we could have done this  through WMI using the Get-WMIObject<\/b> cmdlet and its ComputerName  parameter:<\/p>\n