PowerShell Workflow for Mere Mortals: Part 2

Summary: Microsoft Scripting Guy, Ed Wilson, continues a five-part series about Windows PowerShell Workflow.

 Hey, Scripting Guy! So Windows PowerShell Workflow seems pretty cool. But I am wondering if it is possible to use it to easily provide workflow types of things for remote computers? Is this possible?

—BB

 Hello BB,

Microsoft Scripting Guy, Ed Wilson, is here. We are enjoying a cool stretch of weather here in Charlotte, North Carolina. In fact, we have the windows open. We are also enjoying our visiting friends from Hamburg, Germany. So not only do we have great weather, but we have great company.

Note   This is the second in a five-part series of blog posts about Windows PowerShell Workflow for “mere mortals.” You should read PowerShell Workflow for Mere Mortals: Part 1 before you read this post. For more information about workflow, see these Hey, Scripting Guy! Blog posts: Windows PowerShell Workflow. 

Parallel Windows PowerShell

One of the reasons for using a Windows PowerShell Workflow is to be able to easily execute commands in parallel. This can result in some significant time savings.

Note  For an example of the time savings that are possible by using a Windows PowerShell Workflow and running commands in parallel, see the excellent post written by Windows PowerShell MVP, Niklas Goude, Use PowerShell Workflow to Ping Computers in Parallel .  

To perform a parallel activity by using Windows PowerShell Workflow, use the Foreach keyword with the –Parallel parameter. This is followed by the operation and the associated script block. The following script illustrates this technique:

Foreach -Parallel ($cn in $computers)

 { Get-CimInstance -PSComputerName $cn -ClassName win32_computersystem }

One of the things to keep in mind (as a major source of early frustration) is that when I call the Get-CimInstance cmdlet from within the script block of my parallel Foreach keyword, I have to use the automatically added PSComputerName parameter, not the ComputerName parameter I would normally use with the cmdlet. This is because this is the way that Windows PowerShell Workflow handles computer names. If I look at the command-line syntax for Get-CimInstance, I do not see the ––PSComputerName parameter at all.

The nice thing is that if I forget to use –PSComputerName, and I try to run the Windows PowerShell Workflow, an error message appears. The message is detailed enough that it actually tells me the issue and tells me what I need to do to solve it.

When I rename the parameter in Get-CimInstance, I can run the workflow, and it does not generate any errors. This is shown here.

The complete GetComputerInfo workflow is shown here:

Workflow GetComputerInfo

{

 $computers = "server1","client1"

 Foreach -Parallel ($cn in $computers)

 { Get-CimInstance -PSComputerName $cn -ClassName win32_computersystem } }

I call the workflow, and I am greeted with computer information for each of the servers with names I stored in the $computers variable. The script and the output from the script are shown here.

BB, that is all there is to use Windows PowerShell Workflow on a remote computer. Windows PowerShell Workflow Week will continue tomorrow when I will talk about more cool workflow stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy