Windows PowerShell 2.0 CTP2
Introduction to Remoting
The information in this article was written against the second Community Technology Preview (CTP2) of Windows PowerShell 2.0. This information is subject to change in future releases of Windows PowerShell 2.0.
|
Introduction to Remoting in Windows PowerShell 2.0 CTP 2
One of the new features of the second CTP release (CTP2) of Windows PowerShell 2.0 is a major overhaul of the remoting capabilities. How big of an overhaul is a “major overhaul?” Bigger than you might expect: PowerShell remoting now works only on computers running Windows Vista Service Pack 1 or Windows Server 2008, and there’s now a new cmdlet (Invoke-Command) used to run commands against remote machines.
Before we talk about Invoke-Command, let’s reiterate that, in this second CTP release, remoting works only on computers running Windows Vista Service Pack 1 or Windows Server 2008. (And even then, you need to install WinRM CTP 2.0 to get anything to work.) That also means that you can connect only to another Windows Vista/Windows Server 2008 machine that has the CTP2 release and WinRM CTP 2.0 installed. Want to create a remote connection between your Windows Vista machine and a computer running Windows XP? Sorry, it’s not going to happen, at least not with CTP2.
If that’s a problem, then you might consider skipping this CTP release and waiting for the next one; with any luck, that release will enable remoting on “downlevel” clients.
If it’s not a problem (for example, because you only have PowerShell running on Windows Vista machines) then you just need to know about the changes involved in actually running commands on remote computers. In the initial CTP release for Windows PowerShell 2.0, the Invoke-Expression cmdlet was used to run a command against a remote machine:
Invoke-Expression –computerName atl-fs-001 –command Get-Process
This is not the case in CTP2; in fact, parameters like –computerName have actually been removed from Invoke-Expression. Instead, if you want to run the Get-Process cmdlet against the remote computer atl-fs-001 then you need to use this command:
Invoke-Command –computerName atl-fs-001 –scriptblock {Get-Process}
Note. OK, technically you could leave off the parameter names and just run this command: Invoke-Command atl-fs-001 {Get-Process}. But we thought the parameter names made it easier for you to understand what we were doing here. |
As you can see, the basic syntax is the same; we’ve simply substituted Invoke-Command for Invoke-Expression, and replaced the parameter –command with –scriptblock, making sure that we enclosed the command we want to run (Get-Process) in curly braces. That’s really all there is to it. (Under the covers there are many more changes than that, but that’s nothing you need to worry about.)
Of course, you can still run a command against multiple computers; for example, this command returns information about the processes running on the computers atl-fs-001, atl-fs-002, and atl-fs-003:
Invoke-Command –computerName atl-fs-001, atl-fs-002, atl-fs-003 –scriptblock {Get-Process}
As was the case with Invoke-Expression, Invoke-Command makes a connection to a remote machine, runs the command, and then immediately drops that connection. If you need to make a persistent connection to a remote computer (or set of computers) you can still create a runspace:
$objRunspace = New-Runspace atl-fs-001, atl-fs-002, atl-fs-003
You can then reference that runspace in your call to Invoke-Command:
Invoke-Command –runspace $objRunspace –scriptblock {Get-Process}
That should be enough to get you started. For more information (and a bunch of useful examples) take a peek at the Invoke-Command documentation by typing this command:
Get-Help Invoke-Command –full | more
And for more information on remoting in general, take a look at the various “About” topics on the subject. You can retrieve a list of those topics by running the following command:
Get-Help About_Remote*
Happy remoting!
