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! Question 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?


Hey, Scripting Guy! Answer 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.

Image of command output

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.

Image of error message

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

Image of command output

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.

Image of command output

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 

Comments (6)

  1. mredwilson says:

    @Tamas The reason for using PSComputerName instead of just ComputerName is that PowerShell Workflow automatically creates the PSComputerName variable for core PowerShell cmdlets. Therefore to do workflow, we must use that parameter instead of ComputerName.

  2. mredwilson says:

    @Hieronymus I am glad you like the series of articles. Yes, Workflow is very powerful, and it will work in a heterogeneous environment.

  3. mredwilson says:

    @Stacey Check that both of your Windows Server 2008 R2 machines have PowerShell remoting enabled. I would also check the versions of PowerShell that you have installed on your computers.

  4. Anonymous says:

    Hey Ed,

    What is the reason behind that the "PSComputerName" parameter has to be used instead of "ComputerName"?

  5. Hieronymus Fortesque Lickspittle says:

    This is very exciting, I can't wait to try it out.  Just to clarify from the part 1 post yesterday, when using WMI commands the remote computer's PowerShell version doesn't matter at all?  It doesn't even need PowerShell installed?

  6. Stacey says:

    What does . . . .

    The WS-Management service cannot process the request. A DMTF resource URI was used to access a non-DMTF class. Try again using a non-DMTF resource URI.


    on one server the workflow worked and on the other server I received the above error. both machines are windows 2008 r2

    Thank you,


Skip to main content