Has anyone else seen the K1000 / SMA OfflineScheduler Service create an infinite reboot loop?
We have a daily scheduled reboot for all our desktop systems. This script runs via the offline scheduler so that it runs regardless of the desktop being on network/VPN. We created the script in 2018 and it has essentially run successfully each day since that time.
However, on Saturday morning all agents running the script went into an infinite loop. The system would restart, but the script would run again. The script was timed to run so soon after startup that there was no way to intervene.
We finally used a remote command tool and sc config OFFLINESCHEDULER start=disabled to kill the service. We currently have the offline scheduler disabled company-wide until Quest helps us complete a root-cause analysis.
Our KACE systems management appliance was updated to the latest version (12.0.149) on 1/25 at 10 PM.
Our KACE systems management clients were updated to the latest client version (12.0.38) on 2/1. We have no clients in our system not on this version.
The Restart Script has been in place for so long that I cannot find the last time it was changed before yesterday's events in the KACE logs.
KACE published a KB Article with an statement about this:
The issue was related to the daylight saving time change and it won't affect the scheduler anymore.
The KScheduler service can be started again and the Offline KScripts can be enabled.This issue will not occur again.
We experienced this exact same event. We too have a reboot offline script that runs daily and on Saturday morning our computers started to reboot in a loop. My wonder is if it had anything to do with the daylight savings time but that was not set to happen until Sunday morning. However the Kace server looks to time.kace.com. I don't know what that source is managed by...maybe that time source was not set correctly and thus the server time was wrong and kept pushing out this script?
Or, if the offline scripts are run based on the client computer's time and the offline script is stored on the local computer agent then maybe the computers had the wrong system time and kept thinking it was time to run that script. ??? this is all speculation. We are in the same boat as you and are still trying to figure out what could cause this behavior.
I do see a couple of windows patches being deployed prior to this event, including Windows Malicious Software removal too. I wonder if that could have impacted this script?
If you find any ansers would you mind updating this thread? I will certainly do the same if we find the answer.