Run now status page for SCHEDULED Kscripts
The run now status page is somewhat usefull, for Online kscripts that were run NOW. However, for scripts that are scheduled, you need to have a view to see their success failure rate.
Fabio Jourdan commented
you can use this SQL i created, you need only to change de "KBOT_ID", you can see this code passing the mouse pointer over the script name at the script pages...
m.NAME, m.ID, STATUS, START_TIME, u.FULL_NAME, s.*, d.*, o.*
inner join MACHINE m
on l.machine_id = m.ID
left outer join KBOT_LOG_DETAIL s
on s.ID = l.STATUS_DETAIL_ID
left outer join KBOT_LOG_DETAIL d
on d.ID = l.DEBUG_DETAIL_ID
left outer join KBOT_LOG_DETAIL o
on o.ID = l.OUTPUT_DETAIL_ID
left outer join `USER` u
on u.USER_NAME = m.`USER`
KBOT_ID = 328
order by START_TIME desc
Cody Lee commented
The year is 2018, and somehow this "swiss-army knife" of the IT world still can't seem to do basic things.
If someone has a sql report to get this information, please let me know!
Mark Zecchino commented
This is functionality that is absolutely necessary! Why would anyone want to schedule something and have no idea if it ran?
Shauna Sonnenwald commented
Agreed. I schedule software deployments quite often through Scripting, and being able to provide my manager with the results has always been quite cumbersome. Having the status results of Scheduled scripting jobs would be VERY useful.
This is definitely a feature that should be in the system. I have a lot of users here at the university that have been asking to see status of scheduled scripts.
I absolutely agree. Scripts need to be devoid of time and target. This could be accomplished by creating a task to execute a specific against a set number of targets at a specific time. Results would be aggregated on a separate tab simliar to run now and would ideally include the name of the KACE user that scheduled the script. This construct would provide the desparately needed visbibility into the timing of recurring scripts and script execution results AND would reduce the overall script glut. Currently, any scheduled script must be duplicated if the time or targets needs to change leading to script glut. Please vote this idea up!
Tom Howell commented
I can't even think of using SCHEDULED Kscripts because if there is no high level job log/status like the "run now status" page without a "SCHEDULED Kscripts status" how do I know there is no rogue jobs running.
The "SCHEDULED Kscripts status" page should also show what is going to run today, tomorrow, next week as far out as you like so you can review what is going to run on your system are validated jobs. also when I scheduled a job to run I want to come back later a see it ran and who is still going to get it when they return depending on the job. They I should also be able to cancel the job if it has not gone out yet and if it when out to 100 system 50 receive it 50 will receive it when they check in the cancel will not remove the job from the "SCHEDULED Kscripts status" it will show 50 done 50 error due to canceled job.