1: PS > $job = Get-WmiObject Win32_NetworkAdapter -AsJob
2: PS > $job
3:
4: Id Name State HasMoreData Location Command
5: -- ---- ----- ----------- -------- -------
6: 9 Job9 Running False localhost Get-WMIObject
As you can see on line 4, there is a State property, and the job is still in progess. I’ll check the job again after a few seconds:
1: PS > $job
2:
3: Id Name State HasMoreData Location Command
4: -- ---- ----- ----------- -------- -------
5: 9 Job9 Completed True localhost Get-WMIObject
Great, it’s been updated. Always nice to work with live objects like this. So, my next trick is to create a Where-Object filter to use when I’m doing a bunch of long-running jobs:
1: PS > $job | Where-Object { $_.state -eq "Completed" }
2: PS >
Ok, what the heck happened? That should have returned the job in question, right? The answer is that for some reason, the WMI guys used a differently named property, and “faked” the name using PowerShell’s output subsystem.
Here is an example showing what I mean:
1: PS > $job | Get-Member *state*
2:
3: TypeName: Microsoft.PowerShell.Commands.PSWmiJob
4:
5: Name MemberType Definition
6: ---- ---------- ----------
7: StateChanged Event System.EventHandler`1[System.Management.Automation.JobStateEventArgs...
8: JobStateInfo Property System.Management.Automation.JobStateInfo JobStateInfo {get;}
9:
10: PS > $job.JobStateInfo
11:
12: State Reason
13: ----- ------
14: Completed
So for now you will need to use this JobStateInfo property to work with the job state. The good news is that I’ve raised this to the WMI team and hoepfully they will fix this for V2.
/me crosses fingers.
You can use Get-Job and specify the state:
PS > Get-Job -State completed
Nice one Shay, thanks.
Tell the WMI team to just alias the property. That is what it is there for.
Yup, that’s what they should’ve done.
This is a common Gotcha with the powershell formatting system, where a Different column header than the property is displayed to make things *easier* yet it can confuse you. Its a good/bad thing
Sometimes the propertyname is longer and more detailed and the column header is smaller to fit on screen. In this case their format data allows them to FLATTEN hirachical data into a table. This makes it really easy to see that state just from $job, without having to run another command to get the child property. That is useful, even though when you are scripting against it you can’t cheat and have to get the real property as below
$job | Where-Object { $_.jobstateinfo.state -eq “Completed” }
No, it’s a bad/bad thing! They can *always* alias it.
Wow, that’s an annoying bug. You should post the link to your bug report here so we can all vote for it.
Right you are, Robbie. I’m asking MSFT is there an existing bug to track before I make a new one.