Workstation Patching

I'm looking for suggestions on patching:

1.Schedule - How often do you patch?

2. Do you notify your users before patching?

3. Timeout Action - How many times do you prompt your users before restarting?

4. How do you stop Windows from managing updates. Since we have moved to KACE many of our users are receiving feature updates automatically since we have removed the agent for what used to manage these updates.

4.  Any other suggestions?

Thank you!

0 Comments   [ + ] Show comments

Answers (2)

Answer Summary:
Posted by: chucksteel 4 years ago
Red Belt

Top Answer

I work at Dickinson College and we put together page that informs users of our update policies. The answers to questions 1, 2, and 3 for all of our scenarios can be found on that page:


We stop Windows from managing updates via group policy. We are, however, moving towards using Group Policy to control updates in a more granular manner to supplement patches coming from KACE. In particular controlling the Feature Updates and when they are applied. We also use Group Policy to set the Office update channels to establish early adopters/testers and production computers.

We took a lot of time to develop the schedules and their settings and collected feedback from users. Working in a higher education environment makes it more difficult for us to just put policies in place than corporate, but raising the importance of security helped. 

Dickinson is also highly focused on sustainability with a goal of being carbon neutral by 2020, which meant balancing when computers are powered on with our patching requirements. We push BIOS power on settings using Dell CCTK to match when machines should be on for patching and also use energy policies to hibernate machines. The smart labels which push those settings are configured to allow exceptions and only apply where necessary, e.g. we don't set laptops to power on for patching.

I recommend setting up a default patching schedule in this manner:

Create a smart label that includes any machines that don't have a label applied that ends in "Patching" (We call this label "Patch Production")

Create other labels for your patching schedules that end with the word patching, e.g. "Lab Patching", "Admissions Patching" (they're special), "Test Patching", etc. And yes, we even have a "No Patching" label for very special people.

This setup automatically places machines into a default patching schedule and our technicians then add the necessary labels to those machines which require exceptions. Those patching labels can also be smart labels, e.g. computers in the Admissions department are in the Admissions OU, an LDAP label is applied to those machines and a smart label applies the Admissions Patching label to the machines with the Admissions Department ldap label.

  • Thank you for this in depth insight! - rruhl 4 years ago
  • I appreciate the level of detail provided. I read through the "Computer Security Updating Policies and Best Practices" and there is a ton of great information. Thank you for sharing. - Andy_V 4 years ago
Posted by: Nico_K 4 years ago
Red Belt

Every environment needs other patching setups.
In my env I have most of the devices locally and they are avaiable daily. (not every system but most of them)
I have also some systems externally with a very irregluar pattern, when they are online.
The Appliance is open to the public, so no VPN etc nessesary.

1. for the local systems I run a detect every tuesday morning (8:00, start if it comes up later and stop at 14:00) and a deploy every friday before the end of the shift (15:00, and stop at 22:00); for the remote label ones the same daily.
2. I notify them if a reboot is nessesary.
3. I prompt 5 times with a delay of 3hr
4. The KACE has a setting, which can disable that.
5. (your second 4) determine how it fits well in your environment and the work schedules of your colleagues. Since this is different in every env.

Even the kind of patching is different.
I personally don't patch with labels but deny to install software installers with slightly different settings, which works well for me but may be a problem in other envs.
The latest major versions are maintained with MI/Scripts

  • Thanks for the insight! - rruhl 4 years ago

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