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?
Answers (2)
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.
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.
Comments:
-
Thanks for this... didnt think to use the not within last.. (duh).. I agree detect and deploy is critical if you want any required patches to deploy NOW.. without that we were getting devices that had dependencies on patches and therefore were not up to date. IE a patch would be deployed but the others could not be deployed until that patch was applied.. so it would reboot and not be up to date. However. if you have a network monitor keep in mind servers will restart over and over again until done. This is really more critical when you are onboarding new devices or implementing patches for the first time otherwise it can take months to get a baseline. - barchetta 2 years ago
