KACE Product Support

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.

You can see a more recent video on the http://youtube.com/kboxbykace channel.

http://www.youtube.com/kboxbykace#p/c/084D50063A4510A5/6/PLQpkIQVCBg