Delayed patching schedules
Thanks to the experts who take the time to help along the newbies. I've been researching this issue all morning and I'm not finding exactly what I'm looking for.
We've set up a couple of labels for patching to include 1) a few test systems and 2) the production systems. What the boss wants to do is push the new patches to the test systems first, then after a 5-7 day period push the same patches to the remaining machines (the production group). Is there a way with the K1100 to send a patch to a machine and then after X amount of time send the same patch to another machine?
Again, appreciate the help. If you just reply with a link to a solution I don't mind the reading.
Answers (3)
deploy the patch to your test group label and when you are sastisfied change the deploy to the production label
Comments:
-
So the answer is to monitor it manually and direct the scheduling of the patches. We were hoping there was something more automatic that we could configure and employ. - AndrewQ 11 years ago
-
someone still may give you an automated method, that is how we currently do it. In the past we have had patches break things so we keep the changing over manual till the humans not the machines are satisfied. - SMal.tmcc 11 years ago
KACE did a blog a few months back that explains how to do this using a little SQL-fu.
http://blog.kace.com/2012/06/22/k1000-kloser-look-testing-patches-before-deployment/
Change 30 to 7 and this should work for you:
"You can set up a patch smart label for testing and another for production machine deployment. The way this works is you create a Patch smart label, targeting the appropriate patches you wish to deploy for testing. Next you create another patch label with the same criteria with one extra item, select “Release Date” “>” “DATE_SUB(now(), INTERVAL 30 DAY)” and create the label, name it ex. OS Patches Greater than 30 days Old. Next you will need to edit this label, to go the Home – > Label – > Smart Labels and select the label you just created by clicking on it. Once you’ve clicked on it, locate the ’DATE_SUB(now(), INTERVAL 30 DAY)’) and remove the quotation marks before Date and between the last to parenthesis. This greater than 30 days old will be your production patches because it will allow you to deploy the first label that includes all patches regardless of age to a test group of machines and if there is an issue you can catch it before it goes company wide. What you can now do is take the standard label and deploy it to a group of computers in various departments for testing (or use a labels that includes your standard testing machines), if your other deployment labels are also including a variation of this for GREATER than 30 days- your automated testing of the patches has 30 days before it goes live for deployment to the rest of your network, so you have 30 days to catch any issues that are caused by a particular patch. Adjust INTERVAL 30 DAY to INTERVAL 10 DAY or any other number that you wish to set your release cycle to."
Comments:
-
And... upon reading that, looks like they have their sign backward. My SQL code for production patches more than 30 days old is:
select UID from KBSYS.PATCHLINK_PATCH where ( KBSYS.PATCHLINK_PATCH.RELEASEDATE < DATE_SUB(now(), INTERVAL 30 DAY)) - tshupp 11 years ago
We use the following method:
KACE is set to download patches every Wednesday morning at 3:00am.
Patches are deployed to our test group on Wednesday at 9:00pm.
Patches are deployed to the rest of campus on Thursday at 9:00pm.
This gives us a very short window to verify that the patches are good for release, but it has worked for us so far. You could change the patching schedule for the rest of campus to be as late as Tuesday to give you some more time. The key to this setup is not downloading new patches every day. I chose Wednesday morning to download patches due to many vendors going to Tuesday patch release schedule and then giving Lumension a day to package them and get them distributed.
Comments:
-
Would that one day turn around from testing to deployment give you a good sample of how effective the patch would be? And how would you back out the patch after it was deployed and it broke something on a test system after it was already deployed to the rest of the users? - ebarlow 11 years ago
-
We have had the experience of a bad patch getting through and the one day was enough time to catch it. The test group includes most of our division so a fair number of folks were reporting the issue first thing Thursday morning. We found the offending patch and disabled it in the Patch Listing. You can then create a Rollback patch schedule that backs out a given patch. In our case we used a script instead. Microsoft had already released a "Fix It" tool to correct the issue caused by the patch and we decided to deploy it to the affected machines.
Having only one day does make me nervous but so far it hasn't been a large issue. If it started to become a larger problem we would most likely push back patching for the rest of campus to Monday night, giving us more time to detect problems. - chucksteel 11 years ago
