unexpected Veeam cmdlet behaviour with Select-Object

[Valdemar]

Can anyone explain this to me?

A straight forward sample with "Get-Service" works as expected (empty lines removed for readability):

Code: Select all

PS E:\Work> $svc  = Get-Service | Select-Object -First 1
PS E:\Work> $svc
Status   Name               DisplayName                           
------   ----               -----------                           
Stopped  AeLookupSvc        Application Experience                

Similar sample with a Veeam cmdlet shows this:

Code: Select all

PS E:\Work> $sess = Get-VBRBackupSession | Select-Object -First 1
Job Name             State      Start Time             End Time               Result    
--------             -----      ----------             --------               ------    
PROD-ACCESS (Incr... Stopped    24.05.2022 00:30:10    24.05.2022 00:32:49    Success   
PS E:\Work> $sess
PS E:\Work> 

instead of assigning the result to the variable, the result is output to console and the variable remains empty (null).
Same with other cmdlets, like Get-VBRJob, ...

If I omit "| Select-Object..." everything works as expected.
If I use "| Where-Object..." everything works also as expected.

[david.domask]

Hi @Valdemar,

I think this is actually behavior of Select-Object, not of Veeam. Check this line from the documentation:

https://docs.microsoft.com/en-us/powers ... escription

When you include a Select-Object command with the First or Index parameters in a command pipeline, PowerShell stops the command that generates the objects as soon as the selected number of objects is generated, even when the command that generates the objects appears before the Select-Object command in the pipeline. To turn off this optimizing behavior, use the Wait parameter.

In fact I did see the same behavior you did, but using the -Wait parameter and it works as you're expecting it to. My guess is that the stop just dumps STDOUT to the console as per the Select-Object design described above, and my below test by allowing Get-VBRTapeJob to run in full first makes it behave right also.

Code: Select all

PS C:\Users\Administrator> $tjob = (Get-VBRTapeJob) | Select-Object -First 1
PS C:\Users\Administrator> $tjob


FullBackupPolicy           : WeeklyOnDays
Object                     : {vmware-fi-nixsobr, vmware-ffi-day-retention, vmware-pervm-ffi, template-backup}
ProcessIncrementalBackup   : True

So I suppose it's just that with your current code, it terminates the pipeline (including the variable saving) per Select-Object behavior.

You can workaround this by using the -outvariable parameter at the end of your pipeline (and further piping to Out-Null). Note you do not prefix the variable with $ when using -OutVariable

Code: Select all

PS C:\Users\Administrator> Get-VBRBackupSession | Select-Object -First 1 -OutVariable Firstsession |Out-Null
PS C:\Users\Administrator> $Firstsession

Job Name             State      Start Time             End Time               Result
--------             -----      ----------             --------               ------
support2\ddomask_... Stopped    7/3/2022 23:00:34      7/3/2022 23:44:03      Failed

Now, as to why Get-Service behaves differently, regrettably I can't tell you Personally I suspect custom private optimizations on the built-in Windows cmdlets, but I have no proof for this, it's just a guess.

But if the goal is to do a speed optimization and just return the first result, I'm not sure there's a good way to do this with Select-Object; the result will always be unpredictable anyways without some sorting from Sort-Object or other sorting, so maybe you can describe what you're trying to do a bit more and we can optimize the result based on that.

[david.domask]

Though, as a follow up, I tested cmdlets from a few other apps (e.g. PowerCLI) and I do see that Veeam seem to be the unique ones here...so maybe there is some mis-behavior to check.

Can I ask you to open a Support Case @valdemar and reference this thread + the examples? It's possible that this is all by design, but I guess it bears some scrutiny to confirm why there is a difference with our cmdlet set.

[Valdemar]

Thank you, David.

I red the quoted part of the documenatation, but I haven't understood it.
Even when the first cmdlet stops processing for optimization reasons it should return a result instead of sending it to console.
("... generates the objects as soon as...") just speeds up the process of generating the resulting object(s).

The -outvariable - trick is great though I do not understand why this works - I guess it goes throught the same optimization.

I will open a ticket and will put the findings here.

[david.domask]

Hi @Valdemar,

You can actually disregard most of my post. I wrote it mostly in a rush before I had a chance to test other applications and frankly I now think there might be a detail on how Veeam is doing it that we miss, but this is just supposition.

The reason -outvariable works is that it happens _after_ the previous commands run, so the order of execution changes. If this works for you, great! But I think that it bears checking to understand why there seems to be something different here. It might still be as I suggested, but after testing with PowerCLI from Vmware, I don't see the same behavior, so now I find it curious.