How do you handle patch scheduling? (K1000)
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?
Thanks!
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
getElementById
9 years ago
I patch aggressively - similar to how you started out patching. Every Tuesday I do a "Patch Tuesday" overnight for anything OS related. Monday nights I take care of the applications like Flash, Java, etc. Forced reboots all around. There's not always patches to install, but you never know when that out-of-band hotfix will come out for something being actively exploited. This is why I opted for weekly patching. I also run a daily Detect.
We also had users complain about various things related to the reboots. With so many breaches being reported, it was easy enough to support our reasoning of security first and convince management that users would need to deal with it. Losing data or leaking information is not worth the users negligence of hitting save!
I do have some exceptions however. For those few workstations I have a scheduled report sent to me that shows all the machines flagged as needing a reboot. It includes the Uptime field so if I see its been too long then I can request the user reboot.I think this might have been one of the built-in reports but I cannot remember exactly. Here is a picture of the SQL for that report.
For the oddities (such as your encrypted laptops) or machines that aren't regularly connected to the network: I schedule a "Turn-In" with the users. This is a dedicated time where the machine is on the network and left untouched to take care of any patching or maintenance on those machines. We work around the users schedules to a certain degree but they also understand that it is necessary. I have several detect and deploys that I can set off manually that I use for this. These machines don't get patched as aggressively due to time constraints but usually at least once a month.
I hope you get all the feedback you need on this to make a good plan for you environment. I know I spent a lot of time planning in the beginning and have made several adjustments and tweaks since then to arrive where we are at now. Good luck!
Comments:
-
Thank you for the information! - Michael4732 9 years ago
Posted by:
chucksteel
9 years ago
Our default patching schedule runs every Thursday night. We run a separate detect schedule earlier in the day and the deploy schedule runs in the evening. Restarts occur if no one is logged into the computer, otherwise they get prompted to restart every 30 minutes but they can only delay the restart 15 times, after that they are forced to restart. We run separate detect and deploy cycles to avoid multiple restarts so if computers need a lot of patches it may take a couple of weeks for them to get caught up. Since Microsoft releases patches monthly this hasn't been too much of a problem for us. For those times that there has been an update that we deem critical enough for immediate deployment we will create a separate schedule and push those updates out more aggressively.
Users are encouraged to leave their computers powered on but logged out on Thursday evening. If they don't logout then they get the restart prompt Friday morning. If they power off their computer then patching runs the next time they power up. Our campus has a strong focus on sustainability so most of our users tend to power off their machines every night.
When users complain about the restart prompts we remind them of the importance of maintaining a secure environment on campus. Thankfully upper management is supportive of our stance and backs us up. You still have a few days left of Cyber Security Month, maybe now is your chance to make a change in your environment.
