With PowerShell 1.0 all cmdlets were run against the local PowerShell runspace and thus ran in the local machine context. This was great for the most part as many of the Exchange cmdlets were able to reach out and manipulate non-local information so that it could move mailboxes or configure storage group settings. That works fine and well for many cmdlets, but what if you need to get information with a cmdlet that doesn’t allow you to specify a remote server, from your administrative workstation? Not so easy, huh?

This is one way PowerShell 2.0 remoting can help.

Note: Exchange Server 2007 does not support PowerShell 2.0. PowerShell 2.0 is currently a CTP, so there are no released Microsoft products that support PowerShell 2.0, however you can be assured at after PowerShell 2.0 has been released Microsoft products will switch over to fully support these new features.

To be able to use PowerShell remoting, PowerShell 2.0 needs to be installed on both the client and the server that you will be remoting to and from. Without having a specific product that leverages or consumes PowerShell 2.0, you can run cmdlets on a remote server by using the Invoke-Command cmdlet.

For example you could return the list of running services on FileServer1 by running the Get-Service cmdlet remotely. (Yes, I do realize that you can also specify –ComputerName parameter on the Get-Service cmdlet, but this same method can be used for other cmdlets that are unable to work remotely):

Invoke-Command -ComputerName FileServer1 –scriptblock {Get-Service}

That is nice and all, but what if you want to get the list of services from more than one server? You can specify more than one server in the computer name parameter.

Invoke-Command -ComputerName FileServer1, FileServer2 –scriptblock {Get-Service}

Now that is just cool!