Bug in Get-VBRJob IsScheduleEnabled?

[cparker4486]

Hello,

Why does "IsScheduleEnabled" returned True for jobs that are not scheduled? Please see the screenshot. Shouldn't he two jobs highlighted in red be returning False?



On a separate note, why is "Name" recognized as a parameter of Get-VBRJob but IsScheduleEnabled and other parameters are not?

[veremin]

Why does "IsScheduleEnabled" returned True for jobs that are not scheduled?

Because this parameter shows the general state of a given job – whether it’s enabled or disabled. If you disable a job, the said parameter will output “True”. Otherwise, it will output “False”.

The parameter you’re looking for is .CanRunByScheduler(), so, the script should look like this:

Code: Select all

Get-VBRjob | select name, {$_.canrunbyscheduler()} |ft -AutoSize 

On a separate note, why is "Name" recognized as a parameter of Get-VBRJob but IsScheduleEnabled and other parameters are not?

This is by design. In order to sort the jobs by given parameter you should use the following script:

Code: Select all

Get-VBRjob | where {$_.canrunbyscheduler() -eq $True} 

Thanks.

[cparker4486]

Thanks for the information. canrunbyscheduler() doesn't appear in the list when I do "Get-VBRJob | fl" so how should I have gone about discovering that function?

On the second part, I think I may have a misunderstanding of PS cmdlets. What's confusing is that cmdlets seem to have an inconsistency in which parameters they expose as arguments. For example, Get-Service exposes Name and DisplayName but not Status. So I can do "Get-Service -Name *search*" but not "Get-Service -Status stopped". Instead I have to do "Get-Service | ? status -eq stopped". Do you know why?

edit: Let me clarify that question. Do you know why cmdlets don't expose every key as a parameter for the command?

[veremin]

how should I have gone about discovering that function?

You can use Get-Member function in order to see all the parameters/functions a job has:

Code: Select all

Get-VBRJob -name "Name of backup Job" | Get-Member 

Do you know why?

I believe, it’s just the way the cmdlets are written. The writer decides whether or not to expose certain parameters this way. Thanks.

[cparker4486]

Thanks for the info.

[tsightler]

edit: Let me clarify that question. Do you know why cmdlets don't expose every key as a parameter for the command?

I think it's fair to say that no (or at least very few) cmdlets expose every possible property of an object as a command line option. There are some that are pretty much considered "standard" such as "Name", and others which are more left up to discretion based on use case. This isn't unique to Veeam Powershell as more as a base concept of powershell and part of it's power.

For example, take the "Get-VM" parameter from the vSphere PowerCLI powershell interface, it provides command line parameters to filter on things like Datastore, Location, Name, Id, and I think a couple of others, but what if you want to query only VMs that are currently powered on? There's no command line parameter for that, you simply fall back to leveraging the object model for the VM, something like:

Code: Select all

Get-VM | where { $_.PowerState -eq “PoweredOn”}

So this would return only VMs that are powered on. Simple enough, and easy enough to mimic with a simple command line option. But what happens when you want to get more complex, like returning all VMs that are powered on with more than 4GB of RAM and less than 2 vCPUs? With the syntax above is easy for me to construct such complex queries to get only the results I want leveraging the object model and the full range of conditional logic available to me in Powershell. This level of selection logic would be extremely difficult to mimic using only command line options and would get ugly very quickly.