[Feature-Request] Invoke-IcingaCheckScheduledTask - involve also information from Cmdlet "Get-ScheduledTaskInfo"

[stevie-sy]

Now the check Invoke-IcingaCheckScheduledTask only use the PowerShell-cmdlet "Get-ScheduledTask". This one has as return the value "state" for monitoring. If you really want to check if a ScheduledTask works correctly and as expected, you have to involve the Cmdlet ""Get-ScheduledTaskInfo". This returns following two values, which are more usefully and meaningful for monitoring: LastTaskResult and LastRunTime.

With the solutation now you can only say which state you expect. But e.g. you expect "Ready" this doesn't say anything if the the task is really running nor if work correctly. If I'm correct, you will catch only an error if the a script which the task triggers produces an endless loop and as a result the state is "running". Or vica versa if you expect "running" but for some reason the task is "ready".
E.g. this is a standard task from Microsoft:

As you can see this task is ready but has as last run result 0x800710E0. In such cases the check would be ok.

And as an example for LastRunTime: If you configure a task that it should run every hour. but for some reasons the task doesn't run (config error or what ever) like this, the state is still ok. So you won't recognize that something is wrong.

For us I expand the check with fowolling code:

...
param(
...
[String]$RunTime, 
...
)
...
$RunTime = Convert-IcingaPluginThresholds -Threshold $RunTime
...
$lastrunresult = $taskinfo.LastTaskResult
$lastruntime = $taskinfo.LastRunTime
$lastrunresulthex = [System.String]::Format("{0:X}",$lastrunresult)

$TaskCheck = New-IcingaCheck -Name ([string]::Format('{0} ({1}) - last run {2} with result 0x{3}', $task.TaskName, $task.TaskPath, $lastruntime, $lastrunresulthex)) -Value ($ProviderEnums.ScheduledTaskStatus[[string]$task.State]) -Translation $ProviderEnums.ScheduledTaskName
.....                     
         
if ($lastrunresult -gt 0) 
{
   [void]$TaskCheck.SetCritical()
}
f ($RunTime.value -gt 0) 
{
   $compareDate = (Get-Date).AddSeconds(-$RunTime.value)  
   if ($lastrunresult -lt $compareDate)   
   {
      [void]$TaskCheck.SetCritical()
   }
}
...

The result looks like this. For us this is ok, but maybe you have better ideas.

[LordHepipud]

Hello,

thank you for the idea. This is definitely something we can add to the default plugin. I will have a look on this on how we can add this globally, without the runtime of the plugin exploding (which is my current fear, but it could be fine at all)

[stevie-sy]

Thank you.

BTW: If you ware wondering why I use [void] instead of Out-Null (like mentioned in your doc) in my code: Because Microsoft recommand this in following paragraph:
https://docs.microsoft.com/en-us/powershell/scripting/dev-cross-plat/performance/script-authoring-considerations?view=powershell-5.1#suppressing-output ;-)
In here is a discussion what is faster and was not: https://stackoverflow.com/questions/5260125/whats-the-better-cleaner-way-to-ignore-output-in-powershell (spoiler: Out-null loose ;-) )

[LordHepipud]

I created two PR's for this - one inside the Framework and one inside the plugins. Could you please test both and ensure that monitoring, thresholds and everything related is working as expected?

Documentation and plugin configuration have been updated as well inside the PR.

For the Out-Null - yes, I am aware of this but I honestly don't like the [void] or $null = handling. Especially with [void] things can become more complicated when you deal with Cmdlets, as you have to place them between ().

Therefor I personally recommend Out-Null, because it is easier readable. but if anyone is using the other methods, I won't mind😄

[stevie-sy]

Thanks for the fast change! I will test this the next few days.

And about Out-Null:
I just wanted to mention it because of performance (The difference in performance surprised me a lot while reading the stackoverflow thread) :-) If you came or work with Bash before using PowerShell, you can read it in the same way like > /dev/null :-). When reading [void], it remembers me to any C bases language :-) How to write correctly: a matter of taste :-)

[LordHepipud]

You are welcome :-)

I will have a look on some core aspects of Icinga for Windows - maybe we can gain additional performance by removing Out-Null. I honestly didn't expect it to have this much of an impact but hey - everyday something new to learn :D

Thanks for the input!

[stevie-sy]

I tested the check and really like the output. Very detailed information! 👍

Only a small note to "last task result": If you compare the output in the task scheduler, you'll see there is written the return code as hex notation. The same in the official docs: https://docs.microsoft.com/en-us/windows/win32/taskschd/task-scheduler-error-and-success-constants. I think if somebody is searching the error code in the web, it's a little bit easier to find solutions. I don't know how you see it?

I'll took some diffrent Microsoft tasks from task tree \Task Scheduler Library\Microsoft\Windows. E.g.

• MapsToastTask
• ScheduledDefrag
• ProactiveScan
• SynchronizeTime

and deployed the service to a Windows Server 2012R2, 2016 and 2019 server. If the task ist not configured or named in diffrent way, the check doesn't work and quits with following exception:

I took a look into the code and I'll see you always run New-IcingaTaskObject which always triggers Cmdlet Get-ScheduledTaskInfo. And this one fails if the task is not existing. You create the filter for "unknown hosts" later.

[LordHepipud]

Thank you for the input. I just updated the PR on plugins with a new version. The issue should be resolved now.

For the error: It is using the hex code. I assume in your case the error is 0x000420. I'm not adding a 0x before and 0 before seems to be removed.

It should match the exit code in your scheduled tasks.

[stevie-sy]

Thank you, looks good now!

Yes the error code matches. My intention here is, if somebody mabe not recognize on the first view, that it's the same number because of diffrent notation. ;-) But it's ok, if it's not possible to change the behaviour.

[LordHepipud]

Thank you very much. For some reason, PowerShell interprets the hex value always to 420 for example at the moment.
I'm pretty sure I can resolve this while re-writing the entire check handling again, to better interpret values in the future.

For the moment, this is sadly not possible.