Patching 101
I am looking for some useful tips and suggestions for patching machines. I have just confirmed the KACE agent is deployed to all of our machines. I would prefer to set something up for patching critical patches first, then being able to select appropriate patches for machines by labels.
thanks,
Answers (5)
jverbosk has an excellent write-up here: http://www.itninja.com/blog/view/k1000-patching-setup-tips-things-i-have-learned-ldap-smart-labels-sql-reports
You will also find some helpful videos here: http://www.kace.com/support/resources/kb/article/kace-kontinuing-education-k1000-and-k2000-recordings
We have a patching schedule for everyday at 3pm with no forced reboot, for critical updates only. You have to set up a patching label and then assign that label to the update classifications that you want. All of our machines follow a strict naming convention, so we then assign the patching label to a staff label that encompasses all of our staff machines.
If your machines will be on late enough, you can schedule it for after hours and force a reboot if you want.
We have a test machine label we deploy to first for patches released in the past 15 days. Then after testing passes it automatically changes to our production patch label and is deployed like a regular patch schedule. If there are any issues with individual patches we mark them as inactive before the 15 days so that they do not deploy to production.
Comments:
-
That is a good idea, but doesn't KACE supposedly test patches before sending them down to the K1? - nheyne 10 years ago
-
Lumension actually does, but they also tested MS13-036 which recently found it's way to my Kbox. Which caused BSODs. It's always good to test.
We have software analyst that test the software after we push MS patches to verify it broke nothing within the app. Since we're a hospital it's important that nothing breaks since it could affect lives. They test during those 15 days. - dugullett 10 years ago-
That is good to know! We may need to do something like this in the future. - nheyne 10 years ago
-
It doesn't happen often at all, but all it takes is one time to BSOD 300 machines to realize you should have tested. If your interested just add the line below to your label. This will get all new patches released in the past 15 days.
AND KBSYS.PATCHLINK_PATCH.RELEASEDATE > DATE_SUB(NOW(), INTERVAL 15 DAY)) - dugullett 10 years ago
There are many ways to china in this scenario, but first I have to second dugullett. A test bed is a must. You'll also find that Java patching doesn't work all that well when the machines are running. It'll look like java installed correctly up until someone tries to use something requiring Java. Then it'll act several shades of stupid. If you're focusing on patching critical items first, which is all most of us bother to patch when possible, it all boils down to your patch smart labels. I group by manufacturer and then by criticality. For example my labels look a lot like this.
PATCH : ADOBE READER : CRITICAL
Patch denotes the type of smart label (makes it easier to manage smart labels from label management).
ADOBE READER is the product I'm targeting.
CRITICAL is also self explanitory.
Use your labels to drill down the patches your running detect/deploy against and you'll be able to granularly control your patch runs. Doing so with a test bed is always wise, again use machine labels to accomplish this. Run different patch labels at different times, this makes it easier to figure out when a patch does break something. Another important thing to note about patching is that it does persist after reboot. If KACE detects that you need 65 critical patches and you install 45 before it prompts you to reboot. It will resume downloading and installing the remaining patches until complete. This will happen each time you run patching on your machines which means there may be more reboots. For some things such as Java I've taken to using managed installs to have tighter control.
Everyone has given some really good feedback regarding my inquiry. The original article attached from jverbosk was a tad overwhelming but extremely informative. Below I am going to list what I am going to do to start and let’s see if I can get some feedback. We follow a naming convention by location. Example: VA-Computer1 for Virginia PC’s, MD-Computer1 for Maryland PC’s. All of the PC’s at each location are running the same OS. All of the servers are located at our headquarters. I do not plan on using LDAP
1.Create a test environment for patching
2.Create Smart labels for location (VA) (MD) (DE)
3.Create Smart labels for our computers and servers
a. Desktops
b. Laptops
c. Servers
4.Create Smart labels for our OS
a. WinXPsp3
b. Win7sp1x64
c. Win7sp1x86
d. 2k3sp2
e. 2k8.r2sp2
5.Create OS Patching Smart Labels
a. PATCH WinXPsp3 (OS only, Critical, Non Superseded)
b. PATCH Win7xp1x64 (OS only, Critical, Non Superseded)
(and so on…)
Configure Patch Subscriptions
6.Create Parent App Patch Smart Labels
a.Label = Patch Apps
I. Patch Type = Application
II. Impact = Critical
III. Superseded = No Criteria
b.Create Child label to exclude labels by REGEX
c.Create Child babel to exclude apps by their ID title (Apple, Firefox, non REGEX-able exclusions)
7.Set up Detect Patch Schedules from smart labels (Desktop – Win7sp1x64)
8.Set up Deploy Patch Schedules
Am I on the right track here? I typed this on the fly after reading about 30 comments.