Using a Counter Variable in a PowerShell Workflow Foreach -Parallel Loop

As I’m sure most of my blog readers are aware, I competed in the advanced track of the Scripting Games this year and ended up doing quite well. Two first place finishes and three second places finishes with the official judges and four first place crowd score finishes. I also ended up being the overall winner of the advanced track.

A few days ago someone on twitter asked me as the winner of the Scripting Games advanced track, what I would do with it? I plan to use it as a tool. I’ll continue doing the same thing I’ve been doing of learning more and trying to spread the word about PowerShell to others as well as sharing my knowledge of what I learn. Maybe as a Scripting Games winner, a few more people will listen.

Today I’ll start the first of many blogs to come in a series that shares information about what I learned during the Scripting Games. During event six, one of the goals was to name servers as SERVER1, SERVER2, etc. I started out doing something like this in a foreach loop:


Then I ended up using a workflow with foreach -parallel and that didn’t work out so well:


Here’s what I discovered was the solution to return the desired results in a workflow foreach -parallel loop:


I ended up not using this particular method of naming the servers, but this was something that wasn’t easy to figure out and there isn’t much documentation in books or on the Internet about this so I thought it was worth sharing and in six months when I need to do something like this again, I can search my blog to figure out how I did it.

Update: Be sure to see the comments on this blog article. As the tip from Jeffery Hicks in the comments states, you can’t count on the results from the workflow being sequential.



  1. Jeffery Hicks (@JeffHicks)

    Scope is always important in PowerShell and even more so in a workflow. You can’t assume that you can share variables across workflow activities. Using the workflow: prefix is one way. It is sorta-kinda like setting a global variable for the workflow. But I would think this should be an exception rather than the rule.

  2. Jeffery Hicks (@JeffHicks)

    In your example, defining a server name is no big deal but even though you are using a range of numbers, there’s no guarantee that activities run in parallel will run sequentially. I tested with a larger number range and notice that the server names are not sequential.


    I know you were testing using a counter, But in your example, you already have an integer you can use. Your counter, in this example, is duplicative.

    workflow test2 {
    foreach -parallel ($n in 1..100){
    $a = “SERVER$n”

  3. Jonas

    Guess you could use:
    foreach ($_ in 1..10) {
    $a = “Server”
    if you wanted to 🙂

  4. Ohad Schneider

    Workflows have some serious limitations, for example:

    Perhaps worst of all, getting a degree of parallelism of more than 5 is hard (I gave up trying to get it to work in my case and switched to jobs):

    Also, the code as you wrote it would be considered incorrect in most languages, as variable increments are usually not thread safe (e.g. two threads can observe the same value at the same time and it would be only incremented once). I suspect in PowerShell Workflows some work has been made to synchronize and make it OK, but I’ve not seen any official documentation to support this suspicion.

  5. despized

    Something I have used over the years from batch to powershell.

    Creates $i = 0
    Then does a less than check. To see if 0 is less than the item you are running the for statement against. If it is then iterate or increase.

    FOR($i=0;$i -lt $NETADAPT.length; $i++) {


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: