Dale Lane of IBM announced that the latest version of the IBM PowerShell Library for WebSphere MQ now supports administering remote queue managers.  You can read the details and see a couple of examples HERE.  Kudos to Dale and that team!  What this allows you to perform operations on multiple remote queue managers. 

Some of you might ask, "Why not just wait and let PowerShell V2 do the remoting for you?".  I wanted to address that issue in this blog.

First lets start with the conclusion:  It is perfectly fine for Cmdlets to do their own remoting!

So let's lay it out. 

1. In PowerShell V2, ALL CMDLETS will get remoting for free. 
   
   We will ship an agent that you can run on your remote machines and a set of cmdlets that will submit command sequences to that remote machine for invocation.  e.g.
   
   PS> Invoke-Expression -computername server1 {get-process }
   
   Where it says "get-process", you can type ANY command or pipeline or set of commands. 
   
   We'll take that request, send it to the remote machine (or machines) via WS-MGMT and if our agent is on that machine and running and you have the right privs, it will run.  The command will create a set of objects which we will then serialize into a property bag of a fixed set of types (e.g. strings, datetimes, GUIDs, XML, ints, etc) and return it to you on your local system.
   
2. PowerShell V2 remoting is going to be amazingly cool and amazingly powerful.  Here are a few of the many things you'll be able to do:
• A single command can run scripts on hundreds of remote machines (with throttling).
• You can run it and wait for the results or run it as a job and collect the results when you are ready.
• It will run over firewalls and the bitheads can control a ton of networking parameters (e.g. port, endpoint, use of SSL etc)

So with all that, why would a cmdlet ever do their own remoting?  There are lots of reasons including:

1. Maximal flexibility/Power.  There is no conflict between a cmdlet's remoting and PS remoting, they can be used in combination.  You can use PS remoting to get to a remote machine and run a script which uses a cmdlet that does it's own remoting.
2. Platform Support. 
1. The cool thing about the WebSphere announcement is that the remote MQ queues can be on Windows, AIX or Linux operating systems.
2. Cmdlets might be able to work with versions of Windows that PowerShell does not support (e.g. WIN2K).
3. Cmdlets might be able to talk to Windows machines that don't have the PowerShell agent installed (they might not have PowerShell installed or it might be V1).
3. Better semantics.  A cmdlet might be able to return a richer native object.   A Snapin could have a rich .NET type for remote objects that is much richer than we can produce using our generic approach. Don't get me wrong, I think you'll like the object we give you but the bottom line is that we'll do the best we can given that we know nothing about the object we are working with and no matter what, the object we'll return will not have methods.  
4. Your feature is intrinsically remote.  Take Active Directory for instance.  It makes perfect sense for AD cmdlets to issue LDAP calls.

So if you are a team developing cmdlets, you are free to rely upon us to take care of your remoting needs in the V2 timeframe.  Grab the CTP and kick the tires to get that in focus.  But, if you already have your own remoting solution, feel free to write cmdlets that leverage that as well.

Enjoy!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx