Stephen I'm with you on this one.  Not only have we been getting the forced reboots (which supposedly was fixed in the most recent update).  But after going round and round with KACE Support, we found that Lumensions/Patchlink do NOT patch any Microsoft product that they do not consider 'critical'.  Meaning all those important, recommended, optional patches Microsoft may push, aren't even options.

I also suggest this for user voice.
http://kace.uservoice.com/forums/82699-k1000/suggestions/1895283-deploy-windows-updates-other-than-only-security-p

Or maybe we need to put a suggestion in that is more general like "Make KACE Patching not suck".

Yes, absolutely.  A little while back I did log an idea along these lines.  Refer:

http://kace.uservoice.com/forums/82699-k1000/suggestions/2558401-additional-end-user-options-for-patch-installs

Perhaps, if others agree that this would be useful, they could add their "me too" votes?

Stephen,

Are you familiar with the KACE User Voice site?  You can suggest feature requests and vote for those suggested by others.  r2

I hear what you are saying Ron.  But the problem is that the flexibility of the KACE patching approach simply isn't adequate to my needs.  I need to be able to give the user control over the timing of patching, within certain limits.  Leaving computers on overnight isn't an option.  Waking them up with "wake on LAN" doesn't really suit either, because 30% of my clients are out of the office travelling at any given time, and when they come back into the office I want them patched that same day, but I want the user to be able to defer until a suitable time.  Hitting the Sleep button repeatedly all day is just plain annoying for users.  What would work for me is options like:

(a) sleep for [user specified period not exceeding a limit I set]; or
(b) sleep until [specified time of day]; or
(c) install patches when I next shut down; or
(d) install patches when I next boot up

Its all about flexibility; for me and for the users.  Yes, there are occasional patches which inadvertantly cause a reboot.  I can live with the occasional glitch.  But its the lack of flexibility which is killing me.

mmortenson,

The "at some point in the middle is where it decided to reboot on it's own" is typically caused by a "bad patch".  Was this schedule's Patch Action set to Deploy or Detect and Deploy?  Can you look back at the Windows Event Logs to determine which patch had installed immediately prior to the spontaneous reboots?  r2

p.s.  For all:  Anytime you are going to patch a user's system with their interaction, it is ALWAYS a good idea to ask them to save their work and close ALL apps before clicking OK to continue.  Patches simply aren't made to patch open apps without causing bad things to happen.

Just got on the latest and greatest version yesterday, which i thought may have fixed the snooze and the rebooting without prompting issues, which i also experienced on previous versions...

Tested it last night with full prompting (prompt before install, allow snooze, message during patching, prompt before reboot, no reboot on timeout, & re-prompt)

Results
1. Snooze is working
2. Prompt before reboot is broken - it shutdown all apps and rebooted with no warning (same as old version, note: just microsoft patches)
2a. on the test system, there were 99 patches detected to be applied (we had this off for many months), at some point in the middle is where it decided to reboot on it's own (force closed apps, reboot)
2b. after the reboot, it went through the verify step, then it showed as completed.  Note that not all of the detected patches were applied.
2c. kicked off another deploy cycle just for fun, it did some more patches, again the auto-reboot, no prompt, again the verify step, marked as completed, not all patches applied
2d. third deploy kicked off, the rest of the patches were (finally) applied, but this time, it decided to actually prompt for permission to reboot! [:D]

My recommendation is to not use K1000 to patch non-Lab systems.  Regular workstations and roaming laptop users will be better served by WSUS, WUInstall, or homegrown patching since it won't reboot spontaneously.  Your users will be happier since they won't lose their work!  Hopefully someday, this will be fixed.

Just for fun, i'm going to try patching Adobe products in the coming weeks to see if they exhibit the same behavior via the k1000...

steelc took the words right out of my fingers. +1 for you Steelc!

I would offer the following suggestions:
For machines that aren't mobile, schedule an automatic power on in the BIOS, if you can. Most BIOS setups will allow you to schedule the computer to power on at a certain time, and you can schedule your updates to begin shortly after that. You may also be able to set the computers to Wake on LAN and have the KBOX send the WOL packet before patching is scheduled. You can schedule wake on LAN events in the Distribution tab.

If you set the machines to power on in the middle of the night and then also set a time for patching to complete, you could also then schedule a script to shut them down. So, perhaps you schedule the wake up for 1:00am and then let the patching job run for four hours (which is probably more than enough), you could then schedule a shutdown for 5:00am. Alternatively, you could have them power on at 6:00am and only let patching run for two hours, which should mean they'll be finished before the start of your work day, and since people are coming in, there isn't a huge need to shutdown before they get there. With that kind of schedule you can have the patches install immediately and have the system reboot automatically.

The mobile staff are a little more difficult to deal with, and you might need to develop a different patch schedule that better fits their needs. I actually have a schedule that I call "Patch Now" which allows me to add a computer and run patching immediately. It obviously isn't an automated process, but it may work. Alternatively you could setup a patch schedule for them that will patch upon next connection and those users just need to learn to turn on their computer and realize that they will need to allow patches to run before they can work on it. You could set it to delay patching by a few hours, giving them a chance to catch up on work, but then they'll need to not use the computer for a little bit.

My institution is also concerned with sustainability, so our machines are set to go to sleep and users are trained to shutdown. We're still in the process of working out those details, but I think that the added security of up to date machines is worth it. We also used WSUS before, but I much prefer the flexibility that KACE provides with updates, in addition to the application patching. I think that a big part of implementing a solution like KACE is user education and communication. As system administrators we need to make sure we get our message across that these updates are important and in the long run users' machines will perform better with patching setup and working properly. If you need to convince management of the need then remind them of how much time you spend manually updating computers when they are acting problematic. I'm betting that your hourly wage is higher than what they are spending for kilowatt hour to keep the computers on for patching.

I would like to be able to schedule Detect and Deploy as an overnight job, but (unfortunately?!) my organisation is a very green shade of green and there are strict rules in place about leaving computers on overnight and so on.  So that won't be an option for me. 

Because we need to be PCI compliant, I am also being squeezed from another direction about ensuring that ALL software (not just MS software) is patched with the latest security updates. 

Lastly, we are an overseas aid organisation and roughly 30% of the staff travel regularly, so even if I picked a "patch Thursday" or similar, a fair chunk of my staff are out of the office and will miss the window.

So I don't see a resolution that works for me in the short term, unless I get:

* option to schedule a Deploy either at Next Shutdown, or Next Startup; or
* option for users to make that choice via the Agent popup window

We have enabled patching on our campus and are also going through some growing pains. One change I made is that the prompt to begin patching includes a notice that we don't recommend users to use their computer while patching is in progress, because it may close applications. I think that once users get used to leaving their computers on Thursday evenings (when we have patching set to run) these issues will go away. Our bigger issue is that we don't automatically restart their computer, and some users snooze the reboot for quite a while.

There is a known bug that pressing the Snooze button doesn't work, at least that's what I was told when I submitted a support ticket for that issue. I wasn't given an ETA on when a fix would be released, although I would hope that would be a priority.

I hope this isn't normal, or accepted behavior.  With the new year I've started to deploy patches Microsoft and Adobe patches via the K1000 and am having problems as well.  Most of my users are laptop users who rarely if ever connect to WAN or VPN.  I have to schedule their updates to occur during the day, or and even upon log in when they schedule is missed.  As a result I have a detect run for them at 8am (with the option to run on log in if missed), and deploy at noon.  The deploy prompts to ok/snooze.  Unfortunately when they hit Snooze it just runs anyway.

I am ready to work intensively with support on the issue now that I've finished some other major projects.  I'll be sure to share what I learn.

Do you have a patch window?

I set my patches to run during the night, with a suspend time to prevent them from bleeding into working hours.  So far, I haven't had any problems from users.

Casey