Possible MI bug or just an annoyance Steps to reproduce issue/bug:

  1. View a Managed Installation that has at least 1 # Machines software deployment failed
  2. The ‘Max Attempts’ has to be set greater than 2
  3. Click on the ‘Show All’ which will display all the clients that still need deployments as well as those that have failed.
  4. After clicking ‘Show All’, scroll down to see those clients that the deployment failed.
  5. The screen will show – Not Installed (X of X attempts) – this is typical
  6. Now, change anything on the screen – managed action, max attempts, deploy order, even adding labels or adding/removing a clients.
  7. Now save the changes and view the MI again
  8. After saving the changes, all those clients that the deployment failed will now be reset to install again up to your Max Attempts. Depending on how many failed the first time, that could be a lot of wasted LAN/WAN traffic.
Now, along these same lines – if I have 20 client deployment failures and I find out why the deployments failed for 10 of the 20 – how do I have KACE just redeploy to those 10 without resetting the entire MI? Could this be done on the Inventory screen of each client?

Or better yet – after clicking ‘Show All’ a ‘checkbox’ is beside each client so I can choose from the 20 that will be deployed to again. The checkbox view would look similar to the Inventory View.

This area of KACE and the MI process is very cumbersome.

Thanks, Dave[/align]
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


An MI should always be associated with a software inventory item that the kbox can detect as being installed on that machine. For some reason, if the software cannot be detected properly, then you should use a custom inventory field to represent that software item and associate the MI to that. Installing the software on a test machine and then having it check-in will demonstrate how the software is detected in inventory by the kbox.

An MI that is associated with a software iventory item that is listed as installed will not be re-installed. An MI will only re-attempt an install on a machine that does not list that s/w item in it's inventory. It will try 3 times. By modifying an MI you do reset the counter to 0. In your example, it would effectively only redeploy to the 10 machines that are outstanding.

While this is an old video this demonstrates this concept in use still today.

Another way to skin this cat (that can help in other areas):
While scripts do have a verify step to help determine if the script needs to be run it would be even better for bandwidth limited situations if the script and its payload did not get sent to a machine that does not need it.

Since you might have similar types of actions that you want to accomplish via scripting you should consider creating a filter that is evaluated based on the inventory of the machines.
This filter is a dynamic label that represents a subset of your original machine population that do not yet have the software (or script or whatever). Then in the script (or MI) you choose the label based on that filter as the target of the script. That way the script does not deploy itself and it's dependencies (attachments) to machines that do not need it.

Lastly, I think I understand the enhancement request and encourage all customers who have ideas to open tickets so that an enhancement is logged.
Answered 02/16/2010 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
You can see a more recent video on the http://youtube.com/kboxbykace channel.

Answered 02/22/2010 by: jkatkace
Purple Belt

Please log in to comment