/build/static/layout/Breadcrumb_cap_w.png

Best Practice Windows Patching after Patch Tuesday

Hello, we are trying to find the best process for Windows patching.


The goal is to patch a test group in the FOLLOWING week after the patch Tuesday from Microsoft and the rest of the clients ONE WEEK later. Furthermore we want to get patch reports for each group at the end of the week.


Currently our schedule is:


TEST GROUP

- from the 1st-14th of the month we run detect on all clients

- on THIRD Wednesday and THIRD Friday we install updates on the test group we have detected until 14th of the month (in two separate install tasks)

- on THIRD Saturday we provide a report about the patch success


ALL CLIENTS

- from the 1st-14th of the month we run detection on all clients

- on the FOURTH Monday and on the FOURTH Wednesday we install updates on all clients that we have detected by the 14th of the month (in two separate install tasks)

- on FOURTH Saturday we provide a report about the patch success


But this construct works more bad than good. On the one hand we don't want to have multiple restarts for the users on the day (hence the two patch days) on the other hand it can be that the third Wednesday and the third Friday are not in one week.


We are looking for a solution that chains things together:

Detection until Patch Tuesday (dynamic) -> In the following week install from Monday on all test clients -> at the end of the week send a report about the success -> in the following week (2nd after Patch Tuesday) install on all machines the patches detected until Patch Tuesday -> send a report about the success at the end of the week.


Is there such a possibility? 


0 Comments   [ + ] Show comments

Answers (2)

Posted by: PaulGibson 6 months ago
Orange Belt
3

I'm using a patch label on most of my clients with "Released is not within  last 2 days" (yeah, we live dangerously). You could setup one for "Released is not within last 14 days" for the test computers, and "Released is not within last 21 days" for the rest of the computers (or adjust the days to your preference). Then run the on the appropriate days. That won't do quite what you described, but it'll give you two weeks after patches are released before your test computers get them, and another week before the rest of the computers. 

Rather than running multiple schedules for computers, I use "Run On Next Connection if Offline".

I'd recommend running a detect right before the deploy. If a patch is bad and removed, you don't want a detect that several days old thinking it should be installed; I don't know how KACE handles that situation. 


Posted by: Hobbsy 5 months ago
Red Belt
0

Running patch deployments on the third and fourth weeks, I guess, makes sure that you do not patch prematurely if the 1st of any month falls on a Weds, Thurs or Friday.


The first thing I would say is we tend to run daily detect only on all clients as it takes little effort and also means that your patch database downloads everything that is needed as soon as it can, regardless of if your patch download is set to overnight or within 30 mins. Run that as a separate schedule.


The challenge you want to address is making sure that once you start to patch the test rings no other patches creep in there until the following month and as Mr Gibson states the easiest way to do that is to create smart labels for your patch deployment groups, saying Not released 


The easiest way to do that is to set release date criteria on your Deployment patch labels saying is not within previous 5 days  and not within previous 12 days for a week later, that way you know you are patching identically updates on all machines.


We also find when deploying patches a detect and deploy provides the best feedback and update on patched files in general.

 
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