So using Kaseya we can currently see if a reboot is pending by checking certain registry keys, but what about the "Reboot Pending" status under the Patch Management Module?
I have recently looked into this to figure out how I could reset this status and in the process learned how I can script a check in an agent procedure to see if a machine is pending a reboot. By using the below SQLCMD Select query in a Get "Constant" Variable Step as the value we can get the current rebootPending value from the patchStatusTotals table in the KSubscribers DB for the target agent.
msg+++SQLCMD:SELECT rebootPending FROM patchStatusTotals WHERE agentGuid='+++GETVARGUID:'
If the value is 0 then its not pending a reboot, if greater then 0 then it is pending a reboot. I'm not entirely sure what else it means if it is greater then 1, I suspect it is similar to how the Windows Automatic Update logs how many patches installed that required a reboot but it is not important at this time (yet).
Using this information I can now add smarter logic to my Pre-Patch Management procedures that will only reboot the machine if a reboot is pending.
Hope you guys can make use of it too
Thanks for sharing that.
@HardKnoX, would you mind sharing your script? Thanks!
Nice. Thank you. Now if we could keep Kaseya from rebooting the machine for something dumb like a Malicious Software Removal Tool update...
This is an old one, they have blocked the SQLCMD commands from being used in the Agent procedures so now you have to create a XML file with the following content between the two lines;
<?xml version="1.0" encoding="utf-8" ?>
<queryDef label="Patch Reboot Pending" sql="SELECT rebootPending FROM patchStatusTotals WHERE agentGuid='+++GETVARGUID:'" />
(I can upload the XML file but it will get blocked by the auto mod of the forums, so let me know if you can't get the xml file to work)
Save it as RebootStatus.xml and place it in the following folder on your Kaseya server;
.\Kaseya\xml\Procedures\AgentProcSQL\0\SQLReadTo use create a sqlRead line and give it a variable name and then test if the variable size is greater than 0 a reboot is required (see example image below);
(click on the image to get a better view of the lines)
There are several reasons Kaseya may wish to reboot an endpoint:
Patching is one, a KES & KAV antivirus engine updates are others - all of these are not necessarily "immediate" (i.e. they can be delayed by the user or the VSA and are shown as pending).
To check KES, use SQL="select RebootNeeded from AVFeature where agentGuid='+++GETVARGUID:'"
to check KAV, use SQL="select phase from kav.AVInstallProgressState where agentGuid='+++GETVARGUID:'". A phase vale of 16 = "Waiting for reboot".
There are other actions within the VSA that ARE immediate and cannot be "pending" e.g. installing KBU, KES or KAV (and perhaps others), a scheduled 'reboot' agent procedure, etc.
Thank you @HardKnoX and @Craig Hart!!
I have never seen a need to reboot after manually installing a Windows Malicious Software Removal Tool update. I suppose a reboot may be required should it ever detect malware but, barring that... Yet, when Kaseya Patch Management applies that update, a reboot is always required by Kaseya.
My understanding of patch management is that Kaseya *always* reboots after a patch cycle, regardless. It's hard coded into the VSA to do so - it does not check to see if a reboot is required, it just does one no matter what.
Yes, I agree this is annoying and would be better if it checked for the need to reboot and not reboot if not required.
With the roadmap suggesting that patch management is about to be ripped out and replaced with a new product from heat software/lumension, I wouldn't hold my breath waiting for and improvements to the existing patch module.
The trouble with using the Kaseya Patch Reboot is that on Windows servers it generates unexpected shutdown messages because it does not use the Windows shutdown command with the correct switches.
This can make troubleshooting unexpected crashes that occur during patch events difficult and make customers and noob engineers all excited in a bad way. So the only solution I have come up with so far is to disable the inbuilt patch reboot and to use the post patch procedure to reboot the server.
By putting the reboot action in the post patch procedure also allows you to do other neat things like check if the server reboot was not delayed by hours somehow and make it skip the reboot. This actually happened to me twice where a customer's server patch rebooted at 10AM on Monday morning instead of 4AM.
I have noticed that the patch process including the pre patch procedure does not execute if a reboot is pending which make it hard work around if you have a limited patch window and a lot of servers that have to be rebooted in a specific sequence.
To combat this I did two things
1) I use an uptime performance monitor to let me know if machines skip two server Patch window reboots. This allows you to schedule one off reboots as needed.
2) I created a separate agent procedure that checks if the pending reboot status is triggered and scheduled a reboot to clear it before the patch event.
The whole patch reboot function in my opinion needs a major overhaul there as to be a better way to do it that does not require so many workarounds.
HardKnoX Prey tell, how did you disable the inbuilt patch reboot??