Optimize patch order to reduce reboots
I find that patching fully from Microsoft Updates may require 4 reboots on an OS like Vista SP2. Patching that OS with Kbox, might require 10 or 15. End-users don't like reboots. Optimizing patch deployment to a system would be greatly welcomed to reduce the restarts a workstation/server needs.
The new patching introduced in 10.0 minimized the need for this when it is safe to do so.
This has been open since 2011? Insanity. You would think this would be their #1 priority since the importance of ordering the Servicing Stack updates first became a MAJOR issue for patching Windows 10.
John McPherson commented
Is the prioritizing of Servicing Stack Updates a component of this. Are there other opportunities for Windows reboot optimization? If not, does this feature request now only apply to MAC OS?
This is a big deal for end users and thus a big deal for IT. We have a renewal coming up for KACE SMA in Q2 of 2019 and may start looking elsewhere if this doesn't get addressed effectively.
This is a must as users get annoyed at multiple reboots.
Brett Stewart commented
A single reboot after all patches is a must or our employees are going to rebel. We are getting a lot of angry feedback about multiple reboots and they make no sense. A patch should register the need for a reboot, but Quest should not force it until all patches are done.
Ray Jasutis commented
What I did was disable reboot notification for my sites that complained too much about mulitple reboots. Sometimes it was 3-4 reboots to complete a monthly patch cycle. I ask that they reboot before they go home each night. I also send myself notification of users who haven't rebooted in over 5 days. I then manually send those users an email asking they reboot nightly. It's a pain, but it gets the job done.
Please figure out a way to minimize the number of reboots needed during patching.
Mark H commented
This is becoming an issue for us. I have all my Dells switching on a 04:00 on a Sunday morning to run the updates. I'm finding that at on Monday morning some updates are still running. Of course the reboots then causes the users no end of issues and I get it in the neck. If this can be sorted it would be appreciated.
I still have to use Windows Update Server to roll out some MS patching because its quicker. So I've two systems to look at rather than just concentrating on KACE.
I have had to disable the reboots and send the customers alerts by using a label that includes machines that are required to reboot. Last week I sent a deployment with a snooze option on the reboot and some peoples machines reboot before the snooze period was up. Very frustrating.
Reposting my post from nearly 2 years ago.
Since this post isn't marked as completed, and still "Planned":
I love Kace. However, even I am starting to get frustrated with the number of reboots required before queued patches can continue installing. I'd like to see all available patches install, then a single reboot to finish up. As would my 300+ users. :-) (Now 500+, and including 50+ Macs)
We may drop KACE because the reboots are so bad and would be better if just done directly through Microsoft. There are other ways of doing a lot of the things we currently use KACE for, and KACE is so complicated for so many things that we're seriously on the fence. This could very well be the deciding factor. This seriously issue needs to be figured out and released - excess reboots are not winning anyone any popularity contests, and it's difficult to trust a company when they say they're going to do something, but it's still not done 5 YEARS later!
Deepinder Singh commented
I am still facing issues with multiple reboots. Any fix, script or anything???
I'll be looking into SCCM option soon.
Is this planned for an expected version release? Any updates? It has been in planning for a few years now.
Eric Elder commented
Perhaps now that Dell has acquired Patch Authority Ultimate, which I used and LOVED until Dell bought the company and then squished the competition, they can look at their system and implement features from it that are/were far superior to the patching process.
With PAU you can tell it what time to reboot, so you could deploy patches during business hours, but delay the reboot until non-business hours. Or you could tell it to only reboot if needed, since not all patches require a reboot.
Since this post isn't marked as completed, amd still "Planned":
I love Kace. However, even I am starting to get frustrated with the number of reboots required before queued patches can continue installing. I'd like to see all available patches install, then a single reboot to finish up. As would my 300+ users. :-)
Sovalon Torres commented
This is very frustrating. Coming from vProtect from VMWare, that product did not do a lot of things very well, but the rebooting procedure was great. One reboot for the service pack, and one reboot for the non SP patches. Please change this.
So, has anything been done to improve this?
27 reboots is fun!
Adrian Lanham commented
I agree. I noticed the QChain.exe in my KACE directory but it doesn't appear to be very effective. With other Patch Management systems, deploying multiple patches would only take one or two reboots, depending on if the updates were chainable. This was similar to Microsoft Windows updates. Deploying those same patches through KACE seems to take around 10-15 reboots. Can something be done?
David S. commented
I thought KBOX claimed to do Q-Chaining. Where patches were sorted in order of dependencies. Eliminating the need for multiple reboots.
Josh Imlay commented
Agreed, I am running an update cycle and we are looking at 6-8 re-boots to finish the installs.