Best Practices Question

K1000: Best Reboot Practices

05/14/2014 4497 views



We are trying to figure out the best practice of rebooting machines after patching. The built in reboot options for patch scheduling work, but sometimes multiple reboots are needed, which can be frustrating for users. We don't want to force a reboot as we work mostly work in a laptop environment and do not want users to lose important work. Perhaps there is a way to setup a reboot prompt through scripting the has the same features as patching schedule reboot, but also smart enough to run the script at next check in? What are some other methods used as far as rebooting user machines. Any ideas or suggestions are welcome.

0 Comments   [ + ] Show comments


All Answers


I don't think there really are best practices in regards to patch schedules. These are going to vary wildly based on the requirements of your company. I work at a small-medium sized business that works during normal 9-5 M-F business hours.

I have our primary patch schedule set up to kick off on Friday at the close of business. It is configured to prompt prior to patching with a 60 minute timeout (just in case anybody is working late). After the timeout, the detect and deploy jobs kick off and are set to force reboots.

I have our schedule set up to suspend itself after 10 hours. This gives the patch schedule plenty of time to run to completion, and will prevent the system from patching and causing issues on Monday morning should an encrypted laptop not be able to fully boot back up after rebooting from patching. We previously did not have this configured, but received multiple complaints about people being prompted to reboot multiple times due to patching.

The primary thing to focus on in this process is communication with end users. We sent out multiple emails over a week or two prior to beginning this letting people know to save and close out of anything prior to leaving work on Friday. Anybody that complains about lost work can just be referred to a the multitude of emails that were sent out warning them about this.

Answered 05/14/2014 by: Michael4732
Purple Belt


Do you have a detect and deploy job(single) setup? Or one detect job and then one deploy job? I found that if you have a single detect and deploy job it can cause multiple reboots or even unexpected forced reboots.  So I setup a single detect job on Thursday and then deployed it on Sunday.  I haven't seen the multiple reboot/unexpected reboot happen since.  

Answered 05/14/2014 by: HomerM
Purple Belt

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ