Need some clarification about how Kace handles linked Managed Installs, Custom Inventory Objects and Smart Labels

I am trying to simplify my Managed Installs, Scripts, Custom Inventory Objects and Labels. I wanted to get a little clarification on the order/process that Kace does Inventory, applying Labels, and checking software.

I have a number of software titles that I want to be able to control the installation of new major versions via Managed Install, but am fine with Kace deploying the patches between major versions. This is one use case for this, but I have many others.

My current implementation has become a bit out of hand and I am wanting to streamline it and clean it up, but I have some questions before I move forward. Currently, I create Custom Inventory Objects that target specific settings, configs, registry values, and a number of others and I then use a Smart Label to determine the Machines this gets deployed to. One issue I am encountering is the issue of Kace being a 32 bit client running on 64 bit machines. You have to make custom objects that just try to do too much with 32 vs 64 bit logic. I have a few pieces of software that just exploded in the number of custom inventory objects I needed to deploy it to all of the proper devices. When I look at my Custom items and realize I am nearing 20 custom items to properly manage all of the versions and different configs for a odd piece of software I came to the conclusion that this just is not sustainable. 

I am thinking of moving to a model where I just select the very first version of a software. Adobe Reader might be Adobe Reader XI (11.0.0) as a quick example. I then create a very detailed and precise Smart Label that defines the exact devices that needs Adobe Reader XI version 11.0.0 to 11.99.99 or whatever the range is for that major version. This is a very simplified example and I know can be done relatively easy in a Custom Inventory Object, but I see many people not doing them right on the forums since they are not taking 32 bit on a 64 bit client into account. My real use cases are not nearly this easy and are for more than just targeting a major version of a software title. 

If I move to this new method, after installation the software will not be registered as being installed since the version != 11.0.0. However, my label should properly remove that device as it will detect it as being installed. My question would be is when and in what order does Kace recheck these items? Will the Managed Install trigger the 2nd and 3rd attempts at installation before running a new inventory or will it run an inventory prior to retrying an install? I could always add a runkbot 4 0 to the end of my installation so I know a new inventory is ran immediately after the Software is installed. I am just not sure if this will work exactly how I expect it to.

0 Comments   [ + ] Show comments

Answers (1)

Posted by: chucksteel 5 years ago
Red Belt
You have a lot going on here but I believe this will help answer your question. KACE performs the following during a checkin:
1. Inventory
2. Software Deployment
3. Smart labels applied

I am not positive about the order of software deployment and when smart labels are applied, but I know for certain that KACE will check the inventory first and then run and managed installs based on software that is missing. In never versions of the appliance the computer inventory will show that a software title is installed immediately after the managed install runs. In previous versions you had to wait for the next inventory cycle for the title to appear in the installed software list.

Based on this and your other post it sounds like you are trying to create smart labels that will cover multiple sub-versions of software, and you are right that this is very complicated. 

  • Yeah, that unknown is what I am trying to figure out. The example I used was just the easiest one to explain. Many of those sort of scenarios I can still implement using CIR, but some of my other use cases CIR is just not reliable enough. The issue is the ordering. Depending on when Kace applies labels it could have a major impact on Inventory and Software Deployment. I would hope that Kace runs an inventory, applies the proper labels, and then does Software Deployment. I am not even sure if applying labels is just integrated in to the inventory or if it is a separate process. The question is, does it attempt another inventory before trying to do 2nd and 3rd installations of Managed Installs. If I add a runkbot.exe 4 0 to the end of a script, this seems to work properly. The software gets installed and is removed from the label upon finishing the runkbot 4 0. However, I hate doing that sort of thing without knowing exactly what Kace is doing on the backend. I can see this causing potential issues and creating a lot of unneeded stress on the endpoints, the K1000 and bandwidth.

    In regards to CIRs, I would rather unload the logic to a Label and just have dumb CIR or software versions. In practice, I would like to be able to even make a fake CIR that will 100% register as being uninstalled. Then just use a Label to handle installing the software, then immediately removing the Device from that label right after it is installed. This would also simplify my original issue of having to constantly check hundreds of items to ensure all OSes are still checked. Every time I go back and audit those there are things that have been unchecked in at least a few places. It drives me absolutely crazy that this has not been addressed. Though, I would likely still need to make 1 per managed install since you can't have multiple items attached.

    I tend to stretch the limits of my K1000 and am using it to do a bit more than I think was intended. I use a very large number of labels, CIR, scripts, MIs, and have them all connected in some form or fashion. I use Kace as a form of config management more of less. I put all of my scripts in the KScript section, and then have a wrapper that I use in MIs to deploy my Kscripts. In my MIs I just use a custom command line where I run "wrapper.bat 243" where the 243 is the Script's ID number in the scripting section. That way I can just write a script once and also get a sort of "Run Now" capability to a Managed Install without doing it twice.

    I was using CIR to monitor for the desired configs, settings, software, files, folder permissions, etc etc etc, but it is becoming a nightmare to manage due to Kace only being a 32 bit application. I just want to offload as much of that to labels as possible and try to lower the number of headaches I have to deal with caused by the 32bit issues or issues caused by trying to get around the 32bit limitation.

    I have another new Idea I have been tossing around in my head. I am thinking of making a script that runs at maybe checkin. I am still thinking about how I would implement it, but it would basically be a single script that I build all of my logic into. I would just keep adding to that one single script. The script would either update an xml file or some form of config file that has the information I normally would have used a CIR to pull. It just runs at inventory, gathers everything in one swoop, and then I just build CIR that monitor that single XML or config for the improper values. I'm still thinking about this and might continue brainstorming about this sort of topic.

    When did they add the ability to order Managed Installs? I was encountering some issues with this a while back and Support told me there was no way to Order them. I found out I could be watching one of the new KKEs that were uploaded a few days back. - gerane 5 years ago
    • Two things I can address:
      KACE won't try to run the managed install again until the machine checks in again. I know that for certain.

      I'm very surprised that you were told you can't order Managed Installs. We have been using KACE since version 5.5 and there has always been an order number as part of the configuration, at least that is my recollection. - chucksteel 5 years ago
      • Yeah, I was encountering a lot of headaches because I had labels referencing labels. I was getting different results when testing a label verse when an inventory was being run. I was told not to reference labels in labels because there was no way to order them and tell one label to populate before another. This just made no sense to me, and I told them if you aren't supposed to reference labels in labels, then they need to remove that as an option as it is confusing to their customers. I have never had a good experience with their support. I had great support during the demo phase, but that all went away after that. Maybe I am just unlucky and keep getting bad support reps.

        I didn't think to go back and question what I was told by their support. This was one of a few issues that I worked for a couple weeks with support with. The place to order them is hidden in the drop down menu and I never noticed it.

        I have a list of issues I just gave up on because I got no where after a month+ of back and forth with support. One issue being my kbox is just not running the way it should. I can go to access a label or CIR and it lock my kbox up for 15+ minutes where no one can access it. This happens regularly and make trying to use the ticketing system/KB pretty much dead in the water. I can't use label groups because they keep causing a PHP error and making 90% of the kbox inaccessible and require you to find a way to remove those labels when every section of the kbox attached to labels can't load. That took a lot of trial and error to figure out. Support wasn't able to help me fix that, luckily I was able to get it going on my own. Then I keep having my kbox fail to come back up from backups as well. It hangs during the boot up process. Just a laundry list of issues like that. I didn't really have any issues back with 5.5, most of these have started since 6.0. - gerane 5 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