Get next run of job when set to "run after"...

[bib_ak]

Hello, I run this script:

Code: Select all

if ((Get-PSSnapin -Name VeeamPSSnapIn -ErrorAction SilentlyContinue) -eq $null) {
  Add-PsSnapin VeeamPSSnapIn
}

$tab = @()
Get-VBRJob | where { $_.Jobtype -eq "Backup" } | ForEach-Object { 
  $entry = New-Object psobject
  $entry | Add-Member -type NoteProperty -name "Name" -value $_.Name
  $entry | Add-Member -type NoteProperty -name "Next Run" -value $_.ScheduleOptions.NextRun
  $entry | Add-Member -type NoteProperty -name "Latest" -value $_.ScheduleOptions.LatestRun
  $entry | Add-Member -type NoteProperty -Name "Success" -Value $_.getLastResult()
  $tab += $entry
}
$tab | Export-Csv -Path export.csv
$header = "<title>Custom Report</title><style>body { background-color:#DDDDDD;}</style>"
$tab | ConvertTo-Html -head $header | Out-File report.html

It generates a nice overview of when all my jobs was last run, what status they had, and next scheduled run time:



The problem is obvious when you look at the above picture - the job scheduled to run at 17:30 shows correct next run time, but the ones scheduled to run in a row *after* the first job displays no next run! Any way to get the output like "run after job xxx"?

[veremin]

In the way I see it, you will have to add some "auditorial" part that checks whether the given job uses "after this job" type of schedule, then, finds the previous job in schedule, and outputs its name, along with corresponding phrase "Run after "X" Job":

If ($Job.ScheduleOptions.OptionsScheduleAfterJob.IsEnabled -eq $True) {
Write-Output "Run after " (Get-VBRJob | Where {$_.id -eq $Job.PreviousJobIdInScheduleChain}).name
}

Thanks.

[bib_ak]

Thank you for the pointers.
Unfortunately "PreviousJobIdInScheduleChain" does not seem to work, or at least it doesn't yield any result... I'm using the latest Veeam B&R v7. Can anyone verify that this option actually works as intended?

[veremin]

I've tested in my environment, and everything seems to be working fine. Solely for the testing purposes you can try to limit the scope to the one job that has "run after" type of schedule and see whether the corresponding parameter returns something.

I don't have an access to the console and the moment, but the testing script should look like this:

Code: Select all

$Job = Get-VBRJob -name "Name of the job with "Run after this job" schedule"
$Job.PreviousJobIdInScheduleChain

Thanks.

[bib_ak]

No sir, the variable isn't even there!

The only thing showing up with $Job.P and pressing my "tab" key is $Job.PostJobCommand

Update: Just to be clear - my version of Veeam is 7.0.0.690, Enterprise

[veremin]

Hmm, looks strange, as I'm pretty sure everything worked perfectly in my case.

I will double check it tomorrow, once I'm in the office, and provide you with more details accordingly.

Thanks.

[veremin]

I have just checked it with VB&R .771 and can confirm that the "PreviousJobIdInScheduleChain" parameter is there. Also, I have found the place where this parameter is duplicated. So, you can try the different one ($Job.Info.ParentScheduleId) and see whether it makes any difference.

Thanks.

[bib_ak]

ParentScheduleId works - thank you!

I really can't understand how you find the variable PreviousJobIdInScheduleChain - I have now checked on 3 different customer installs, 2 of them were 7.0.0.771 - no sign of it anywhere.

But who cares, an existing duplicate works fine for me Thumbs up for great support here in the forums - I often value forum support higher than support tickets, since others can benefit from it as well!

[tsightler]

I've seen some weird things with missing parameters if the latest Windows Manager Framework wasn't installed, especially common if you're just using the stock version of powershell on Windows 2008R2. If you're on this platform I'd strongly recommend installing at least the Windows Management Framework 3.0 which you can download here. Don't know if that's what's going on in this case but it's helped me with several issues where clients running some of my Powershell scripts that were very similar.