Best Practices Question
How do you handle patch scheduling? (K1000)
10/26/2015 1871 views
This is a topic that I've been struggling with and fighting over for the past few years that we've used our K1000 for patching, and I'm curious how others have tackled this same issue.
Back when I first implemented Kace for patching, I opted to use a more aggressive patch schedule. I would run our patch schedule on Monday, Wednesday, and Friday evenings to detect/deploy to our workstations and set the schedule to force a reboot. When our users then complained that they had left unsaved documents open and it's too much of an inconvenience to save/close everything before leaving for the day, I changed the patch schedule to prompt for a reboot rather than forcing a reboot.
When our users then complained that the reboot prompt popping up was annoying, I changed the schedule to auto-suspend after a few hours to prevent it from popping back up in the event that the patching process required more than one reboot (somewhat uncommon now, but used to be the norm back on version 4.x).
When our users then complained that they were being prompted at all, I then had to change the patch schedule to only run on Friday evenings, prompt for a reboot (force reboot after prompt timed out), and then suspend the patch schedule after a few hours so that our users with encrypted laptops did not get the reboot prompt again Monday morning when they returned to work, should more than 1 reboot be needed.
We are now in a situation where patches are not being pushed out as timely as I feel they should. I am trying to come up with some alternate scheduling ideas to present to management that would allow us to push out our patches in a more timely manner while not being too annoying or intrusive to our users. Would some of you mind sharing how you go about patch scheduling, and how you handle patching encrypted laptops that utilize pre-boot authentication?