How to manage concurrent jobs in PowerShell

There had been many times in the past two months where I had to write scripts that run multiple jobs concurrently. Since PowerShell doesn’t have a built-in way to limit the number of jobs run at a time, this task falls on us, mere mortals. (On a side note: I’ve had my fair share of PowerShell Workflow and foreach -parallel, it is not ideal!).
Manage the concurrent jobs means, if there is more than X amount of jobs, wait for at least 1 job to finish its execution before starting another. Sounds simple enough. In the past, I wrote a snippet, which was a bulky chunk of code with over 100 lines of code and also did many other “generic” stuff.
Since then I wrote scripts that implement that idea but I didn’t have a solid snippet to use or a simple pattern to follow.

Now I’ve written one that is simple and designed to do this one thing:

Lets go over it.

There are 3 inputs to this snippet:

  • $ConcurrentJobsThreshold integer variable – number of jobs that will run concurrently.
  • $Servers which represents a collection, we would like to start a job for each item in this collection.
  • The ScriptBlock value in the Start-Job cmdlet – What we do on each item.

There is a foreach loop, iterating through the collection.

First thing in the loop, we get all the jobs that are running.
If the amount of running jobs is smaller than the threshold we set at the beginning, a new job will be created.
Otherwise, if the amount of running jobs is greater or equal (-ge) to the threshold we will wait for one of these jobs to finish.

Wait-Job gets an array of job objects and waits for them to change status to Completed, Failed, Stopped, Suspended or Disconnected. (See the Notes section in the help page of Wait-Job)
By itself, Wait-Job will wait for all the given jobs to finish (change its state to one of the specified states), and with the -Any switch it will wait for the first job that will finish (or if it’s already finished), and return it.

Finally, we are waiting for all the remaining jobs to finish (Wait-job without -Any), and we’re done.

Now, this is just a template, you can add more stuff like:

  • Progress bar using Write-Progress
  • Stop the Script execution if there are more than Y amount jobs with state of ‘Failed’
  • Collect the jobs outputs to a log file:
    After the concurrency threshold was reached
    $RunningJobs | Wait-Job -Any | Receive-Job -Wait -AutoRemoveJob | Out-File 'log.txt' -Append
    and at the end:
    Get-Job | Wait-Job | Receive-Job | Out-File 'log.txt' -Append
  • Add a Pause functionality

In one of the recent scripts, where the line $RunningJobs | Wait-Job -Any I wrote Get-Job | Wait-Job -Any instead. In this variation of the script after the first job failed there was no limitation on the number of jobs that were running concurrently. Instead of 20 jobs, we had more than 200, that took too many resources (the horrors!!!). What happened was something like that:
After a job finished its execution (changed state to Failed or Completed) Get-Job hands over Wait-Job -Any an array of jobs that looks like this (for illustration only the jobs statuses are listed):

@(Failed, Running, Completed, Running, Running,…) | Wait-Job -Any

Wait-Job -Any immediately returns the first finished job, which in this example could be either the first job (with status ‘Failed’) or the third job (with status ‘Completed’). And while the amount of running jobs is still the same, a new job is created which exceeds the threshold that was set. I could make sure to remove finished jobs with Remove-Job or Receive-Job -Wait -AutoRemoveJob, which is actually what I did for jobs in ‘Completed’ state only and forgot the failed ones… >_>

for reference please don’t hesitate to use Get-Help, and Get-Help -Online
Start-Job
Wait-Job
Receive-Job
Stop-Job
Remove-Job
or to ask me 🙂

Have a great week!

Amir.

My script to inspect PowerShell objects

About two years ago a friend from work asked me to help him with finding an object’s properties path that holds a specific value he knew existed there somewhere.

To clarify what I’m calling a properties path is this:

$obj.FirstLevelProperty.SecondLevelProperty.ThirdLevelProperty…

etc.

The first idea that came to my mind was to use Show-Object cmdlet by Lee Holmes. In short Show-Object opens a window with the object’s properties tree that you can inspect (you can read more on how to use this cmdlet on The Scripting Guy’s blog post).
My friend didn’t like the idea that of inspecting the object property by property, branch by branch. He wanted a fast way, a function if possible, to search for a value and get the properties path so he could copy-paste into his scripts.

I accepted his request as a challenge and started writing.
My initial idea was to inspect the object using Get-Member to get the names of all the object’s properties, print their names and dynamically call them, like this:

$InputObject = Get-Process winlogon
Get-Member -InputObject $InputObject |
    Where-Object {$_.MemberType -eq 'Property'} |
    Select-Object -ExpandProperty Name | Foreach-Object {
    "[ORIGIN].$_ : $($InputObject.$_)"
}

But this is only to get the first level properties, if I want to get deeper it will be easy to write a recursion:

function Get-ObjectProperty {
    param($InputObject, $Path="[ORIGIN]")
        Get-Member -InputObject $InputObject |
            Where-Object {$_.MemberType -eq 'Property'} |
            Select-Object -ExpandProperty Name | Foreach-Object {
                "[ORIGIN].$_ : $($InputObject.$_)"
                Get-ObjectProperty -InputObject $InputObject.$_ -Path "$Path.$_"
	    }
}

As you can see above, each line of the output start with [ORIGIN], which is a representation of the $InputObject parameter, joined by dot (‘.’) with the properties path, a colon and the corresponding value.
With that its easy to look for a specific value using Select-String:

PS C:\> Get-ObjectProperty (Get-NetAdapter)[0] | Select-String ': .*MSFT'
[ORIGIN].CreationClassName: MSFT_NetAdapter
[ORIGIN].CimClass: ROOT/StandardCimv2:MSFT_NetAdapter
[ORIGIN].CimClass.CimClassName: MSFT_NetAdapter
[ORIGIN].CimClass.CimSystemProperties.ClassName: MSFT_NetAdapter
[ORIGIN].CimSystemProperties.ClassName: MSFT_NetAdapter

But there might be a problem with the function as written above. There are objects that have one of their properties points to another object, and its properties points to other objects and so on… And somewhere along the way there will be a pointer back to the first object. In that case calling the function will cause it to run in an infinite loop.

To solve that I added 2 more parameters, $Depth and $Table:

  • $Depth sets a limit to the amount of recursion calls in a branch.
  • $Table is an array that holds all the objects hash codes that were processed along the way. If an object has the same hash as another object that was processed before, it will be skipped.
    * This is not a perfect solution as different objects can have the same hash code. As explained on MSDN, it depends on the implementation of the GetHashCode() function.

Yesterday I’ve uploaded the script function Get-ObjectProperty to my Github repository, but not before I made some improvements:

  • Replaced the implementation of ($obj | Get-Member) with ($obj.psobject.Properties). It produces the same results but I feel that it’s more fluent to write. Each property in psobject.Properties has value property, so instead of extracting all the property names and calling $obj.$propertyName I’m just calling $obj.psobject.Properties.foreach({$_.Value}).
  • Added the ability to filter the leaf properties by regular expression.

Until next time,
have a great week,
sincerely,
Amir.

First Post

So this is my first blog post!

Finally!

I was struggling with writing this post for a while now. I opened this blog over 6 months ago…

 

My name is Amir Granot, Granola is a nickname I was given by my friends for the first time at school and it stuck.

 

This blog will be a place where I will share my ideas, thoughts about technology, and tools that I find useful to me (wether I wrote them or someone else).

Almost every day I write something new, a script, code snippet, and every now and then I build something that might be useful to others.

Nowadays my focus is everything PowerShell but it may change as I grow, learn and master new things.

 

I was inspired to open this blog by bloggers and contributors in the PowerShell community, to name a few:

 

Sincerely,

Amir.