/build/static/layout/Breadcrumb_cap_w.png

Managed Installations - Software upgrade procedure

I cannot find anything in the manual about how to handle on upgrade. If I go from 1.0 to 1.1 of a software package how will kace manage the upgrade?


0 Comments   [ + ] Show comments

Answers (2)

Posted by: Hobbsy 2 years ago
Red Belt
1

So Nico has gone down the patch upgrade route with vigour ;o)

I think what you are asking is if you have v1 of a software and you need to distribute v2 how do you do it?

First you need to understand how installing v2 in a device with v1 behaves, that is down to the software manufacturer. Some will overwrite and replace v1 with v2, some will install v2 alongside v1, some will just mess it up.

You are correct in your approach, install v2 on a device with v1 installed and note the change (if any) in inventory. If v1 no longer shows then v2 replaces v1. If both show then you will also need to uninstall v1, via a managed install, to keep things clean.

If replacement is the behaviour, to upgrade all devices create a smart label that places all devices with v1 installed in the label, and make the label the target of your v2 managed installation.

If replacement is not the behaviour, consider creating a script to first run the uninstallation managed installation of v1 and then the managed installation of v2 and again target the same smart label.

With our involvement in Cyber Essentials certification preparation for UK KACE customers, this has become pretty much second nature for us, as we attempt to make sure customers only have supported software in their environment.

I hope that helps? Oh yes, and watch Nick the Ninja ignore my response…….

Posted by: Nico_K 2 years ago
Red Belt
0

We need more info :)

Right now we can only say: depends.

By default KACE does the following:
During Check In is every Software Item which is found on the device linked to this device in the backend database und anything which was linked but no more found unlinked.
This means: if You had SOFTWARE_1 installed in version 1.4 and manually updated to version 7 now SOFTWARE_1 version 7 is linked and no more 1.4
With this info you can plan and decide the next steps.
If you have the new Software Item in your DB you can change the current MI to this version and upload the new installer.
And now it really depends what happens:
Is a device in the label it runs through the MI. If it is not in the label, it does not.
Think of a typical environment where most of the MI are linked to a NEW_DEVICES label to deploy all important software via SMA. Then the new version is not installed on "older" systems.

Since many software titles are updated via the patching feed you also should think of that and how they interfere.

My personal best practices (and I see this also in many other environments) are:
1. if a software is in the patching feed do as follows:
1.1. create a MI for new devices and install the latest version avaiable 
1.2 link a new devices label to it and add a label of the older machines which need this software too.
1.3 remove the label of the older machines if all machines have gotten this software
1.4 regulary update the MI with a newer version (not nessesary to use each new version but 1x per year or quarter would be helpful)

2. if a software is not in the patching feed
2.1 create a MI for all devices in need and install the latest version avaiable
2.2 update th MI regulary (1x per year or quarter)

3. If you need a fixed version, unsubscribe this software from the patching feed and install via MI

Why?
If you have a MI with a special version 22.1.0.41c (as an example) and the patching feed is able to update it to 30.4.0 then the following will happen:
1. during a detect the patching mechanism sees: 22.1.0.41c is outdated
2. during patching the version is updated to 30.4.0
3. during check in the mI sees, that 22.1.0.41c is missing and it installs it, so 1. is true again.

Why? 
Because this is how Microsoft determine the installed software


Comments:
  • thank you for taking time to respond.
    If I could, Id like to give you my first real life scenario.

    I just deployed via MI Azure Advanced Threat Protection sensor to all servers. Kace thinks it is vs. 2.0. I followed the docs and installed it on one manually and ran an inventory and then used that discovered software for the MI. It is not easily known but I saw it that if you do not use precisely the same name as seen in the control panel/programs then there wont be a match. Anyway.. it is set for 20:00-23:00 hrs to install.

    So if there is a new version, I need to install manually, run an inventory, then update the MI with that new version.. Will kace know that the version is existing is 2.0 and thus run the new install? Does kace essentially look at the precise name, and then version to determine if an action needs to be taken? What if the name changes? This can easily happen. Why isnt the app ID used? I find this odd.

    I dont see much of our software in the software patching feed.. for example, boxer isnt there. ATP isnt there.. Cortex XDR not there.. mostly Microsoft software.. - barchetta 2 years ago
    • lets go from the bottom:
      look into your patch subscriptions. We only use 2 softwares which are not in the feed, but yes it is different in any environment. You can open a SR with a detailed request which software you would like to see in the patching feed. Depending on the software, licensing for patches etc it can be done or not.

      Yes, if there is a new version you need to follow this procedure. Usually every software version becomes a new entry (there may be differences depending on the individual software) and is checked against. And KACE checks for the entry in the DB.

      KACE does use mostly the windows internal WMI db to get the info. In the Control Panel there is a different detection but at the end it manipulates the same db, so would always query wmi (wmic product get name,version
      as an example) - Nico_K 2 years ago
 
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