Best Practice for Application Updates

[sh856531]

Hi all

When we build macOS devices we use DepNotify and Installomater to install around 10 standard applications including, Chrome, Office, iTerm, Docker and a few other things. We also allow a larger selection of applications to be installed using Installomater via Self Service

In order to manage updates we have a policy that checks a smart group for each application to see if it is on the latest version and if the smart group indicates the machine is behind, it calls installomater again to update the application

This is having limited success and I'm not sure why.

Could anyone advise on whether there is a defacto standard way to update applications that would meet the following criteria:
1. It should work for as many common applications as possible
2. It should not require users to do anything:
3. It should be able to guarantee that applications are updated within a handful of days of a security update being released
4. There should be minimal involvement from IT in having to package, script or otherwise manage specific updates

Thanks in advance

[patelsanjay]

Can you elaborate on what is not working with the setup you described?  Is Installomator failing to update apps when the computer enters the smart group scope? Are you seeing useful output in computer logs or in the Jamf policy logs? That might help narrow down what kinds of suggestions would be helpful.

[sh856531]

Hey - thanks for the reply

So the issue is essentially that the patch scores don't improve. We use Patch Management in Jamf to report on how many machines are on a given version and even applications like chrome can end up many versions behind.

I'm relatively new to supporting MacOS so I don't even know if the installomater approach is the correct one, hence the question.

Assuming that it is an ok way to go, could you advise on which logs specifically might contain clues as to why installomater isn't having much effect?

Many thanks

[mickgrant]

I think you might be making the patching process more complicated by using installomater to do the patching, but Jamf patch management to report the results based on smart groups.
There are too many moving pieces in your setup to pinpoint where/why machines are not patching.
Is there a reason you are using installomater to patch instead of the Jamf patch management tool?

[sh856531]

Hey - thanks for the reply.

So our end state is that we want to just have updates installed at all times, immedaitely and without any admin or user involvement. When I've looked at Jamf managing the patching, it seemed to be the case that you needed to manually upload packages for all sorts of software versions, which to me seemed crackers. 

I'm currently looking at the Jamf App Catalog thing to see if that is any better. It seems to be on paper but I'm not sure if it is going to have an issue given that we have scores of machines that have already had apps deployed using Installomater. I have had one machine successfully get firefox installed. I'm currently testing to see what App Catalog will do when I ask it to install an app on a machine that already has the app on.

At the end of the day, I just want a way to keep apps up to date and consistent with our ISO 27001 security policies 

[mickgrant · Accepted solution]

Have a look at https://github.com/autopkg/autopkg 
there is a GUI for it as well https://github.com/lindegroup/autopkgr
It plugs into Jamf patch management and is quite customisable 

[sh856531]

Thanks. - I'll check those out

[patelsanjay]

Just checking, so sorry if is too obvious - are your patching policies running an Inventory Update under the Maintenance section of the Policy?  Possible that youre machines are updating, but not submitting updated Application data to Jamf.

[sh856531]

Hey - thanks no need to apologise

The policy that runs installomater has an inventory update element so in theory it should pick up any changes. 

[patelsanjay]

Couple of other things that can trip you up - the DEBUG and BLOCKING_PROCESS_ACTION variables in the script can both result in the script running without making changes to the target application, depending on the choices. Definitely review your choices there - DEBUG should be 0 in production, but the blocking process action can get more complicated.

[sh856531]

Thank you - i'll take a closer look at the logs once I can get my hands on a "problem" machine