Installomator Smart Group

[userjamf]

Hello everyone,

I would like to implement Installomator to manage the installation and updates of the applications I use, in order to streamline the process and avoid the repetitive task of manually searching for each package for every application.

I watched the Patch That App Up (By Using Installomator) session presented at JNUC 2023. In the video, it is recommended to create a smart group based on the "Patch Reporting" criterion to identify devices running a version older than the latest available. Additionally, it is advised to create a second group containing the members of the first one, as Jamf does not allow targeting a group directly based on the "latest version" criterion.

Is this still the best method today? Do you have alternative approaches to suggest?

[lewis814]

Yes, creating a smart group based on 'Patch Reporting' and then nesting it in a secound group for targeting is still a solid approach. It ensures accurate targeting without relying directly on 'latest version' criteria. another option is using extension attributes to track app versions, combined with smart groups for more flexibility. If you’re managing a large number of apps, leveraging API scripts with Installomator can also streamline the process. Hope this helps!

[userjamf]

Thanks for your answer!

If I use Installomator for applications available in the Self Service, how can I ensure that, once the application has been installed by the user, it will then be correctly updated via my rule ? Have you ever done it ?

[Pdallison]

With the self service option I like to use the installomators builtin reporting script. They use swift dialog to show enduser the what is downloading and once its done the scripts runs a Jamf recon command.

https://github.com/Installomator/Installomator/tree/main/MDM/Jamf

[userjamf]

Is it possible to show an example with screenshots, for example ?

[Pdallison]

I suggest pushing the swift dialog out first to your test computers first then to your environment. 

[Pdallison]

Hey checking to see how your installomator set up is going

[userjamf]

I want the updates to be installed silently, without any notifications. However, the problem is that if the application is open, the update cannot proceed. That's why I considered applying the rule at startup. But some users have applications that launch automatically at startup, and for those whose applications don’t launch, there’s always a delay before the update is applied. If the user opens the application in the meantime, it affects the user experience because the update won’t happen immediately.

 

[Pdallison]

I had this issues with Chrome. We use a secondary script to "Quit Chrome Nice". THe user is prompted to quit chrome within 5 MIn or chrome will be force quit. 

[userjamf]

Would it be possible to create a rule for updating an application by using the Installomator script twice with the same application name ?

In the first case, a priority before is configured and the parameter BLOCKING_PROCESS_ACTION=silent_fail is specified.

If this step fails, the second script takes over. This time, a notification is displayed to inform the user of the update, while leaving the choice to the user with the BLOCKING_PROCESS_ACTION=prompt_user parameter.

[Pdallison]

You should be able to use both parameters in the same script without doubling up. Or you can set one installomater script in self service and have one run as a policy on its own.

[userjamf]

Yes, absolutely, but I don't know why it doesn't work for some applications.

With Firefox, everything works fine, but with Teams, for example, the application updates and closes without displaying a dialogue box. In another case, as with Zotero, nothing seems to happen until we manually close the application and relaunch it. Only then do we see that it has been updated.

Example for Teams