VBR Job Next Run Properties empty

[benthomas]

Hi all,

I'm working on some PowerShell reporting around VBR Jobs, and found that the Next Run property of a Jobs Schedule Options isn't populated by default until I call the `GetScheduleOptions()` method.

Code: Select all

PS C:\> $Job = Get-VBRJob -Name TestJob 
PS C:\> $job.ScheduleOptions.NextRun

PS C:\> $job.GetScheduleOptions().NextRun
7/08/2024 11:30:00 PM
PS C:\> $job.ScheduleOptions.NextRun
7/08/2024 11:30:00 PM
PS C:\>

I've tested this on both build 12.1.2.172 and 12.0.0.1420.

Is this a known issue?

[david.domask]

Hi Ben,

Indeed, the .NET method you're calling there GetScheduleOptions() was deprecated internally some time ago; .NET methods are unsupported methods, so it's best not to rely on them in your code whenever possible.

Pass a CBackupJob object to Get-VBRJobScheduleOptions, this is the correct endpoint to pull such data from, you'll see the NextRun property there.

[benthomas]

Hey David,

Thanks for the response and the recommended command.

I'm curious though, as when I'm calling $job.ScheduleOptions.NextRun this is just looking properties on the CBackupJob object. I'm wondering why this is an empty property until the deprecated method is called and then the property also becomes populated.

Are there any plans to remove these properties if they're linked to the deprecated methods?


Cheers,
Ben

[david.domask]

Hi Ben, you're very welcome for the cmdlet.

I forget the specifics on this to be quite honest, but from my Support days this was brought up and the result of the research was the unsupportedness of this methodology and an explanation for the behavior being that the internal mechanism had changed so it was no longer the "right" place to poll for this information. I am pretty sure Get-VBRJobSchedule was improved later on to provide a proper endpoint for this that didn't require unsupported methods.

Long-term, the cmdlets will all be made a bit more "friendly" to avoid the need for using such unsupported methods -- you can see this across the last releases as we extend the cmdlet endpoints for new features and they are much more "lithe" and return usable reportable data without the .NET methods being exposed, which is the goal with the Powershell cmdlets -- you shouldn't need to use unsupported methods to retrieve the data, so it will be addressed, just some of the cmdlets will require a bit more attention than others.

[benthomas]

Thanks for the extra info, I'll look at reworking the script tomorrow with the newer cmdlet.

Is there an area you'd appreciate feedback on what dotnet methods I find myself having to fall back on frequently to get information I'm after?

[david.domask]

You're always welcome Ben!

Feel free to DM me your findings; while we can't really provide support and official answer for any .NET methods is "unsupported, use at your own risk", I am a bit curious what you found personally.