If you are an administrator, responsible for KACE patching, and your responsibility encompasses anywhere from a couple hundred to a couple thousand nodes, you have no-doubt experienced the frustration in setting up, and implementing manageable patching on the K1000.
In this article, I will not discuss the whole patching process, but will concentrate on the patching labels, which, if you think about it, are the toughest part of the patching process.

In order to implement patching correctly, there are groups of labels that will need to be created:

  1. Labels that will target the machines that need to be patched
  2. Labels that will target the patching groups.

Let’s focus on the latter point (2):

Before we continue to the details, I will speak from experience, and the method I will share with you was inspired by a KACE trainer, and I have added a few things to it. You will find out though, that no method will ever be completely turn-key. There is small maintenance steps that will be required in the long run. (Unless, dare I say, you possess some serious Regular Expression foo). Also, you may or may not end up liking my method, it is obviously not the only one around, and possibly not the best, but I did the work already, so I thought I’d share.

The premise upon which this system is based, is in the name of the labels. We will create different labels that will target different sets of software, and after we’re done with those, we will create a label group label which will target the labels themselves, to create a relevant group of your choice. Think of the labels as the ingredients for your sandwich, and the label group, as the sandwich itself. 🙂

We will use a specific nomenclature with this method, specifically in the label group. Let’s take an example label, and dissect it:

PL – tOFFICE – t2003 – X-tSERVER – X-iSI

It looks kind of cryptic, but bear with me, it’ll get clearer.

  • PL : this refers to “Patch Label”. Because there are many labels all in the same list, it is important to create some sort of prefix for the labels
  • – : Notice that there is a space between the PL, the dash, and the tOFFICE. This will serve as a separator of items when we get to creating the patch label group. You will also find that the dash is also used in another context
  • tOFFICE: the “t” refers to “Title”, and anything that comes after that refers to the title of the product, in this case office
  • t2003: Same as above, only referring to the title which contains 2003
  • – X: the X refers to a NOT. So any place there is an X, the expression after it is negated. Note the spaced dash before the X, and the non-spaced dash after the X
  • -iSI: the “i” refers to “Impact”, and “SI” refers to “Software Installer”. Because there is an X before the -iSI, this will mean that it is NOT a software installer

At this point, and even without looking at any additional details within the smart label, I can read this label as follows: Target any product with the title “Office” and “2003” but exclude anything that has “SERVER” in the title. Also, exclude anything that could be a software installer. This means that we’re only targeting patches for existing software.

Below is a reference table of the nomenclature that I use. You can use the same ones, or you can create your own. The most important part though, is to stay completely consistent as you create multiple labels, because these will serve as keywords to build your Patch Label Groups.

Now that we have the system down. It’s time to create the different labels that will include the different types of patches that we would want to include. In my case, I’m in an enterprise setting, so I’m pushing patches that match my environment, and these are the ones I will share with you. For the most part, these will be sufficient for most other organizations. However, you may find that you may need to create some additional specific ones. Because the contents of the reference table are pretty wordy, I have included them in an attached Excel file that you are welcome to download. (Link at the bottom of the article)

Here is an example of what you will find in the Excel sheet:

Name Description Smart Label What it does
PL – tOFFICE – t2003 – X-tSERVER – X-iSI Title: Office Title: 2003 Title: Server Impact: NOT Software Installer select UID from KBSYS.PATCHLINK_PATCH where (((( KBSYS.PATCHLINK_PATCH.TITLE like ‘%office%’) AND KBSYS.PATCHLINK_PATCH.TITLE like ‘%2003%’) AND KBSYS.PATCHLINK_PATCH.TITLE not like ‘%server%’) AND KBSYS.PATCHLINK_PATCH.IMPACTID not in (‘Software’) ) Installs Office 2003 Patches. While excluding full software installers
PL - tOFFICE - t2003 - X-tSERVER - X-iSI

Create the smart label by specifying the criteria

This is essentially the same thing that would need to be done for all the rest of the labels.

The only piece that is left is to create the label group for the individual labels.

The target query we’re looking for is something like this:

select UID
where (  (1  in (select 1 from LABEL,
LABEL.NAME like '%- iSI%')) )

The label for the above query would be the following: PLG – DESKTOP Upgrades – iSI

The above query is essentially getting the label names which contain the “- iSI” which refers to software installers. You can look in the Excel document for the other label groups.

Some of the additional patch labels we created don’t need to belong in a label group, but can be used individually on their own. An example of this would be the label: PL – vMICROSOFT – tREGEX-SP-DSK-XP-7 – X-iSI. This one can be used to create a patch schedule to push Service Packs to Windows XP and Windows 7. In most cases, these need to be separated from the normal patching schedules.

As I mentioned in the beginning of this article, this is only a small piece of the whole patching process, but it’s a good start to get you to a solid foundation.

Also, please remember, that building those smart labels are based on analyzing results and filtering the labels to adjust them. For instance, in the case of Firefox, you will have to adjust the label when new version of Firefox is out. (which apparently is every week nowadays 🙂 ) .

Another small challenge I found with this, is the Java updates, in speaking with many sources, it doesn’t look like there is a fool-proof way to get those  exactly how you want them all the time, because the behavior of KACE JRE installers depends on what already exists on the workstations. As you know, Java can easily install an upgrade in parallel to another version, and not instead, which creates a bit of a complication in installation. Will save this discussion for another post.



Print Friendly
Subscribe By Email for Updates.