PowerShell Workflow for Mere Mortals: Part 5

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


Hey, Scripting Guy! Question Hey, Scripting Guy! I have a number of commands that I want to run against several remote servers. The commands include stuff that must happen prior to something else happening. But then, there are also some things that I would like to happen as fast as possible. Is this permissible? If so, do I have to write two different workflows?


Hey, Scripting Guy! Answer Hello TB,

Microsoft Scripting Guy, Ed Wilson, is here. This afternoon I am sipping an awesome cup of Oolong tea with a cinnamon stick, jasmine flower, and lemon grass. The flavor is just about perfect. In the background, I am listening to Ravel. Outside, the sky is dark and it is raining. The thunder seems to punctuate the music.

Note  This is the last post in a five-part series about Windows PowerShell Workflow for “mere mortals.” Before you read this post, please read: 

For more information about workflow, see these Hey, Scripting Guy! Blog posts: Windows PowerShell Workflow

Well TB, the good news is that you do not need to write two different workflows to enable parallel processing and sequential processing. Windows PowerShell Workflows are flexible enough to handle both in the same workflow.

Adding a sequence activity to a workflow

To add a sequence activity to a Windows PowerShell Workflow, all I need to do is use the Sequence keyword and specify a script block. When I do this, it causes the commands in the sequence script block to run sequentially and in the specified order.

The key concept here is that a Sequence activity occurs within a Parallel activity. The Sequence activity is required when I want commands to run in a particular order. This is because commands running inside a Parallel activity run in an undetermined order.

The commands in the Sequence script block run in parallel with all of the commands in the Parallel activity. But the commands within the Sequence script block run in the order in which they appear in the script block. The following workflow illustrates this technique:

workflow get-winfeatures


 Parallel {

    Get-WindowsFeature -Name PowerShell*

    InlineScript {$env:COMPUTERNAME}

    Sequence {


        $PSVersionTable.PSVersion } }


In the previous workflow, the order for Get-WindowsFeature, the inline script, and the Sequence activity is not determined. The only thing I know for sure is that the Get-Date command runs before I obtain the PSVersion because this is the order that I specified in the Sequence activity script block.

To run my workflow, I first run the PS1 script that contains the workflow. Next, I call the workflow and I pass two computer names to it via the PSComputerName automatic parameter. Here is my command:

get-winfeatures -PSComputerName server1, server2

The image that follows shows the Windows PowerShell ISE where I call the workflow. It also illustrates the order in which the commands ran this time. Note that the commands in the Sequence script block ran in the specified order—that is, Get-Date executed before $PsVersionTable.PSVersion. Also notice that they were in the same Parallel stream of execution.

Image of command output

Some workflow coolness

One of the cool things about this workflow, is that I ran it from my laptop running Windows 8. What is so cool about that? Well, the Get-WindowsFeature cmdlet does not work on desktop operating systems. Therefore, I ran a command from my laptop—a command which does not exist on my laptop, but it does exist on the target computers, Server1 and Server2.

Another cool workflow feature is the InlineScript activity. I am able to access an environmental variable from the remote servers. The InlineScript activity allows me to do things that otherwise would not be permitted in a Windows PowerShell Workflow. It adds a lot of flexibility.

TB, that is all there is to using Windows PowerShell Workflow and specifying Sequence information. This concludes Windows PowerShell Workflow week. Join me tomorrow when I will talk about Active Directory with Windows PowerShell.

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 (8)

  1. jrv says:

    @Ed – great.  I was just looking at it with PowerShell in mind.  No direct support in PowerShell  Looks like we requires direct use of the WorkflowQueue class. I will be interested to see what you come up with.

    Yes – NOBM is good for thunderstormy weather and great at Halloween.

  2. jrv says:

    @Ed – more like "Night on Bald Mountain" maybe.

  3. jrv says:

    @Ed – Will you be tackling Workflow Queuing?


    This is where the power of Workflow really starts to shine.

  4. jrv says:

    @Ed – Oolong and thunder;  shouldn't it  be Mussorgsky?

  5. Kiran says:

    Thanks ED….these were helpfull…..if you have time can u do a demo of foreach -parallel on a bunch of servers returning say ping or uptime info….right now I think this is probably the foremost candidate for workflows at least for sysadmins like myself….

  6. Ed Wilson says:

    @Kiran — PowerShell MVP Niklas Goude wrote this article blogs.technet.com/…/use-powershell-workflow-to-ping-computers-in-parallel.aspx in which he pings computers in parallel. But I think I might very well do the uptime one. Great suggestion.

    @Aleksandar Totovic Thank you.

    @JRV hmm, a good suggestion. I love Pictures at an Exhibition, but perhaps the Sunless cycle of songs might be more appropriate 🙂

  7. Ed Wilson says:

    @JRV Yes, workflow queuing is a great thing to talk about. I am thinking about a more advanced Workflow series — but it will be in a few weeks before I get it on the schedule.

    @JRV Night on Bald Mountain is a great work.