K1000 Patch schedule with reboot set to prompt, but some PC's are rebooted?
I deployed the current patches to a small group of lab machines and at least one, maybe more was rebooted by the ampagent even though I have it set to prompt in the same schedule we always use with no changes to it. The event log has the data below. I need to deploy to our end users today. Anyone know why the Ampagent would force a reboot like this? Or better yet, is this something that may happen to many more machines?
We're at 6.2 with all fixes. Agents are 6.2.1025. Windows 7 x64bit client.
The process C:\Program Files (x86)\Dell\KACE\AMPAgent.exe (COMPNAME) has initiated the restart of computer COMPNAMEon behalf of user NT AUTHORITY\SYSTEM for the following reason: Legacy API shutdown
Reason Code: 0x80070000
Shutdown Type: restart
Comment:
EDIT: Could this be caused by a machine running low on disk space? I just noticed the first machine that reported this is 96.6% full.
Reboot options are as below. Same settings we always use.
Thanks
3 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
h2opolo25
9 years ago
From what I remember if you have ANY reboot options other than NO REBOOT it will eventually reboot the machine. With the options you have above it will show 5 prompts at 5 minute intervals and then at the last prompt it will reboot.
The way KACE has this set up is as follows...
NO REBOOT = PC will not reboot.
Force Reboot = No prompts, PC just reboots
Prompt User = Prompt shown. Ability to snooze reboot but eventually the PC will reboot.
Posted by:
getElementById
9 years ago
Based on what the Help / User Guide says, your machines shouldn't be rebooting with that patch schedule. That said, I'm inclined to agree with h2opolo25 on this. Here is a snapshot of the Help below.
If the reboot was delayed at each prompt then it would've rebooted, based on what I'm reading below. But you said these were lab machines so they would've been left untouched yes?
Comments:
-
Thank you both. These machines (in our little world at my office) are referred to as lab machines with regard to patching. I send a patch run to lab machines that nobody uses with a forced reboot and if those machines are good, then I send patches some of our IT staff machines which is what this one was. One of our staff members reported that her machine prompted to reboot, but she didn't click yes or no and it rebooted that same morning. But her reboot occurred prior the timer running through all cycles.
ANSWER: Her C: drive was 99% full. That's the only difference I found between her and the others that reported no problem.
Today, some of our non IT staff returned from vacation and one found they had patched but their machine was too slow to use. This machine is also 99% full. Maybe it's just coincidence, but I'm a bit concerned that the patch run is not deleting expanded files. Hard to say if the files I found were left because the patch run failed to delete or if they failed to be deleted because the drive ran out of space for other reasons of low space (user files). Both users have profiles in the 30GB range with other large chunks of data that should be elsewhere.
I'm fairly certain this was a case of low disk space prior to the patch run, but if anyone else has seen a patch run eat up available disk space, please let me know.
Much appreciated to all for the suggestions and advice. - murbot 9 years ago-
That is odd. I could see the job failing if there wasn't enough disk space but that doesn't explain the rebooting problem. After reading your comment here I went and looked on my own machine and found 1.5g of un-deleted items! But, most of the patches were recent (last Monday) so maybe it does delete on the next run? I'm not sure... Back to the original topic of reboot, you said in your OP that you needed to push to the end users that same day. Did you do that already? [Edit]: and did any machines reboot that shouldn't have? - getElementById 9 years ago
-
No reports from anyone else regarding anything related to this patch run. I did push our staggared runs and all machines that have been online have patched. I suspect, but could be wrong that one of the two users was being pretty active either deleting files or breaking connections so that could have contributed to the reboots.
I do think there's some extra files laying around that should've been deleted, but I haven't determined with certainty that these files are patch related. - murbot 9 years ago
Posted by:
EdT
9 years ago
You need to examine one or two of the affected machines with very low available disk space to find out exactly what is eating up disk space. I have seen a machine with 15Gb of Office service packs repeatedly downloaded because there was an error in the local Office source files preventing the service pack installing correctly. This was in the %TEMP% folder. Patch runs frequently fail to delete files, so you need to check both the user and system %TEMP% locations and all the other usual download locations that can fill up.
Patching is not running on my system because the hard drive is full and all the systems are in downloading status. Also the schedule that these tow systems are in has a reboot later option set after prompting the user for a reboot. From the time the command shows up to when it rebooted is like 20 minutes. - iceheat 9 years ago
A list of “Resolved Issues” is published in the product Release Notes accompanying new releases that can be referenced to identify if a fix for this defect has been implemented. Product Release Notes are available in the “release notes and guides” area of our Support Portal at software.dell.com/support" - kelleyplumos 9 years ago
Did they label it as a problem with "patching" or with "disk space" or any other moniker beyond the call number KA-1162? - murbot 9 years ago