Have you ran into the issue where Jamf Patch Management and Installomator disagree which version is "latest"? For example, at the time of writing this (11/4/24) Jamf sees Webex 44.10.1.31028 as most recent but when you download Webex via Installomator's URL for Webex it downloads 44.8.0.30404 (https://github.com/Installomator/Installomator/blob/main/fragments/labels/webex.sh). The result is an endless loop of the user being prompted to update Webex since Installomator is incapable of installing 40.10.x.
Hey Ryan, thanks for taking the time to read and comment!
Yes, I've had this issue with an app or two over the time I've been using it. Like you, I've just updated the link manually until the next Installomator release, and check to see if that issue has been resolved.
It's not perfect, unfortunately. But for the amount of time it saves, I can live with these annoyances.
I finally got around to this on my to-do list, and it appears that you do still need a second group. Nothing has changed, unfortunately.
When you try to scope the update policy, you still receive the error: "Policy scope cannot be based on a smart computer group that uses the "latest version" criteria".
Hey Manoel, thanks for reading and taking the time to ask a question. When I originally wrote this, you were unable to actually scope a policy in Jamf if the criteria of the smart group was based on “Patch Reporting”. So, you had to make another group to get around this. I’ve just checked, and this no longer seems to be the case. I’ll update this post once I’m back in the office.
I'm seeing an issue (so far just testing this with Chrome) where the 'Update Available' Smart Group differs in group membership numbers from the 'Patch Policy' Smart Group. They should be 1:1. Patch Policy group has ~100 computers more than the Update Available Group. They're both setup how you did yours, but seem out of sync. I also didn't see you mention putting a recon / update inventory at the end of the patch policy. Isn't it needed so that the group memberships stay accurate? Thanks! Really liking Installomator, just trying to dial it in.
Hey Brad, thanks for taking the time to read one of my posts! I'm glad it's been helpful so far.
That's an excellent point about the recon/update inventory. That certainly would result in some inconsistent numbers, like you've said.
I guess this could depend on how often you have the machines do their inventory check in. I have the one in Jamf configured to run once a day, but also have another policy to do the same at login. As a result, my groups are likely to update pretty regularly.
Having the script run in the background on a machine, and it sees there's no update available, has very little impact on machine performance. Whereas, a full inventory on some Intel devices can be noticeable for up to a minute (not so on the M1/M2's that I've seen).
That's a great question. Thankfully, I've only got a few apps that aren't in Patch Management right now. I've created an auto-update policy that runs weekly/monthly against a smart group with that app installed, rather than checking for the version installed.
It may result in a script running for a few seconds when it doesn't need to, but I can live with that.
We absolutely do! I set the “BLOCKING_PROCESS_ACTION” to “tell_user”. The description of this is:
“- tell_user
#. User will be showed a notification about the important update,
# but user is only allowed to quit and continue, and then we
# ask the app to quit.”
It's a soft “this is going to happen”. If there's no user logged in at the time, it will just get on with it. There are more forceful options available :).
Have you ran into the issue where Jamf Patch Management and Installomator disagree which version is "latest"? For example, at the time of writing this (11/4/24) Jamf sees Webex 44.10.1.31028 as most recent but when you download Webex via Installomator's URL for Webex it downloads 44.8.0.30404 (https://github.com/Installomator/Installomator/blob/main/fragments/labels/webex.sh). The result is an endless loop of the user being prompted to update Webex since Installomator is incapable of installing 40.10.x.
At least for Webex the fix at the moment seems to be to update its URL manually in the script: https://github.com/Installomator/Installomator/pull/1965/files
But I am curious if you have ran into this issue before and how you resolved it.
Hey Ryan, thanks for taking the time to read and comment!
Yes, I've had this issue with an app or two over the time I've been using it. Like you, I've just updated the link manually until the next Installomator release, and check to see if that issue has been resolved.
It's not perfect, unfortunately. But for the amount of time it saves, I can live with these annoyances.
Hi, really cool post. I had a question: what is the reason for having 2 groups with the same content instead of just one?
Hey!
I finally got around to this on my to-do list, and it appears that you do still need a second group. Nothing has changed, unfortunately.
When you try to scope the update policy, you still receive the error: "Policy scope cannot be based on a smart computer group that uses the "latest version" criteria".
We're going to have to keep using 2 groups!
Hey Manoel, thanks for reading and taking the time to ask a question. When I originally wrote this, you were unable to actually scope a policy in Jamf if the criteria of the smart group was based on “Patch Reporting”. So, you had to make another group to get around this. I’ve just checked, and this no longer seems to be the case. I’ll update this post once I’m back in the office.
Thank you!
Update Edit: Nope, we still need 2 groups.
I'm seeing an issue (so far just testing this with Chrome) where the 'Update Available' Smart Group differs in group membership numbers from the 'Patch Policy' Smart Group. They should be 1:1. Patch Policy group has ~100 computers more than the Update Available Group. They're both setup how you did yours, but seem out of sync. I also didn't see you mention putting a recon / update inventory at the end of the patch policy. Isn't it needed so that the group memberships stay accurate? Thanks! Really liking Installomator, just trying to dial it in.
Hey Brad, thanks for taking the time to read one of my posts! I'm glad it's been helpful so far.
That's an excellent point about the recon/update inventory. That certainly would result in some inconsistent numbers, like you've said.
I guess this could depend on how often you have the machines do their inventory check in. I have the one in Jamf configured to run once a day, but also have another policy to do the same at login. As a result, my groups are likely to update pretty regularly.
Having the script run in the background on a machine, and it sees there's no update available, has very little impact on machine performance. Whereas, a full inventory on some Intel devices can be noticeable for up to a minute (not so on the M1/M2's that I've seen).
I'm sure I recall reading somewhere, or was possibly told during the Jamf kickstart, that you wouldn't want to use that too regularly. That may not be the case any more? Certainly no mention of it here, anyway: https://learn.jamf.com/bundle/jamf-pro-documentation-10.44.0/page/Computer_Inventory_Collection.html
Maybe as browsers update so often, it could be worth having an update on these to ensure the groups stay in sync better. I'll give it a bash.
Do let me know what you go with, be it another policy to pull inventory more often, or using it on the update policies!
Nice Post!
How are you handling the apps which arnt in Jamf Patch Management for updates?
Hey Tom, thanks for reading!
That's a great question. Thankfully, I've only got a few apps that aren't in Patch Management right now. I've created an auto-update policy that runs weekly/monthly against a smart group with that app installed, rather than checking for the version installed.
It may result in a script running for a few seconds when it doesn't need to, but I can live with that.
I've also been trying to make use of Jamf's Title Editor: https://docs.jamf.com/title-editor/documentation/Logging_in_to_Title_Editor.html - But I haven't managed to get it working for the app I'm testing with. This is most likely a "me" issue! :)
Thanks for the reply!
Yeah same here, only have a dozen or so which arnt available and pretty much came to the same conclusion just to scope and run once a week.
Yeah i dont think its just you, i thought 'how hard can it be' but getting it to work seems alot more finicky than i would have liked.
If you ever crack it, let me know! :)
Thanks! that's really helpful.
May I ask, do you follow the same workflow for web-browsers? How do you get users to quit?
Hi James, thanks for taking the time to comment.
We absolutely do! I set the “BLOCKING_PROCESS_ACTION” to “tell_user”. The description of this is:
“- tell_user
#. User will be showed a notification about the important update,
# but user is only allowed to quit and continue, and then we
# ask the app to quit.”
It's a soft “this is going to happen”. If there's no user logged in at the time, it will just get on with it. There are more forceful options available :).
I hope that helps!