Skip to main content

The following is a conversation between myself and Jamf, trying to get some more detailed information surround the Jamf Installer Preview. I hope this conversation is helpful to other admins who are exploring this new functionality.

Me:

I know that this feature is still in preview and more work is still being done before Jamf pulls it out of Preview.
I've been communicating with other Mac Admins within the MacAdmins Slack Community regarding app installers and there was a little bit of confusion regarding some of the backend processes of how Jamf App Installers are being pushed down to end-user systems.

I've read through the following links trying to dig deeper into app installers:
https://community.jamf.com/t5/jamf-pro/jamf-pro-10-37-is-now-available/td-p/261726
https://www.jamf.com/solutions/app-lifecycle-management/
https://www.modtitan.com/2022/03/in-weeds-with-app-installers-preview.html
https://www.jamf.com/blog/jamf-app-installers-faq/

So my question presently, is if Jamf can provide either an official or unofficial whitepaper-ish document that dives deeper into App Installers than the present documentation does? The Jamf Admin Guide, and the FAQ only touch the surface of things, but don't get into the technical "how is all of this actually working".
Outstanding questions among the community largely revolve around when an App Installer is sent down to a device, what is the expected behavior?
Taking Google Chrome as an example, will Chrome be forced to quit, without delay and warning, and hammer down the latest version?
Right now, it appears that App Installers do not care if an application is open, and pushes the update down regardless, as reported by other Mac Admins.
Is there logic built into the App installer process, or the InstallEnterpriseApplication MDM command to check for if an application is running and be told "do not install right now?"
Is there any validation checks to ensure installations do not fail for any reason?

For new system enrollments that are in scope, what is the order of operations for those new enrollments? Does App Installers push down applications based on the Enrollment Complete trigger, based on a system check-in or inventory, or some other factor? Is the App Installer feature something that Mac Admins can incorporate with something such as DEPNotify – and has Jamf thought through any of that?

If all of this can be passed on to the appropriate people and get some sort of response, again, even with an unofficial document/response with the answers, that would be much appreciated by myself and my team, as well as the greater MacAdmin Community.

Thank you,
Tony

Jamf Support:

After some research below are answers to your questions.

App Installers don't have any insight into whether the App is open or not, a command is deployed if it sees that it's needed for a particular device. In the MDM spec in Apple's doc, there are no additional keys for the install command to do different things. It's entirely up to the individual App developers to control what happens if an app is open when it receives an update command.

For the "enrollment complete", it's just based on regular inventory collection, when we collect inventory, do we see that the device is supposed to have something? If we do, we push out a command to install whatever it's missing.
Currently, we do not have any information on DEPNotify being integrated with App installers, please use this space to request/view any related feature request: https://ideas.jamf.com/


When encountering technical issues, please contact our Jamf technical support team during regular business hours using the details below. *If immediate assistance is needed please dial the hotline.

Very interesting. I myself have been testing out this feature and have found it to be inconsistent in how it pushes down the apps/updates. I created a Google Chrome deployment and noticed that it installed the app regardless of if Chrome was open or not. In the past, I have seen that Chrome needs to close in order for the install to occur. I had gotten around this by using a curl script to copy the new app to the Applications folder, which seems to have stopped working since Chrome v.100. It still doesn't seem to be consistent regarding how many it is successful on though. 

I then created another deployment for Acrobat, which doesn't appear to work at all. I don't see the InstallEnterpriseApplication command being sent to the computers in scope. 

 

A whitepaper on this feature would be very useful. 

Very interesting. I myself have been testing out this feature and have found it to be inconsistent in how it pushes down the apps/updates. I created a Google Chrome deployment and noticed that it installed the app regardless of if Chrome was open or not. In the past, I have seen that Chrome needs to close in order for the install to occur. I had gotten around this by using a curl script to copy the new app to the Applications folder, which seems to have stopped working since Chrome v.100. It still doesn't seem to be consistent regarding how many it is successful on though. 

I then created another deployment for Acrobat, which doesn't appear to work at all. I don't see the InstallEnterpriseApplication command being sent to the computers in scope. 

 

A whitepaper on this feature would be very useful. 


Yeah that's been the general consensus of the overall community especially regarding Chrome. But per Jamf's reply, it's wholly up to application vendors to update their apps to possibly change the behavior when the InstallEnterpriseApplication command is pushed down to the system with a new installation of an app. In my personal opinion this isn't much better than the previous Patch Management Functionality where I could at least alert a user in advance that an application is about to close in order to force down an update. 
Just having updates be forced down at random times throughout the day will lead to issues with my users, and trying to look up how each and every possible app performs when updates are pushed out is currently outside of my level of priority. So we will see how this goes and see what improvements are made. 

We've disabled Adobe Acrobat because from what I can tell, Jamf is pushing down the Base Application.pkg versus the Updater.pkg. When this is done, users are presented with a pop up message from Acrobat saying that the previous version of the application will be deleted in order for the new application to be installed. Users then have to approve that messaging. We do not like that at all. So specifically for Acrobat we are going to still depend on Patch Management as well as autoupdates from the Creative Cloud application. 

Yeah that's been the general consensus of the overall community especially regarding Chrome. But per Jamf's reply, it's wholly up to application vendors to update their apps to possibly change the behavior when the InstallEnterpriseApplication command is pushed down to the system with a new installation of an app. In my personal opinion this isn't much better than the previous Patch Management Functionality where I could at least alert a user in advance that an application is about to close in order to force down an update. 
Just having updates be forced down at random times throughout the day will lead to issues with my users, and trying to look up how each and every possible app performs when updates are pushed out is currently outside of my level of priority. So we will see how this goes and see what improvements are made. 

We've disabled Adobe Acrobat because from what I can tell, Jamf is pushing down the Base Application.pkg versus the Updater.pkg. When this is done, users are presented with a pop up message from Acrobat saying that the previous version of the application will be deleted in order for the new application to be installed. Users then have to approve that messaging. We do not like that at all. So specifically for Acrobat we are going to still depend on Patch Management as well as autoupdates from the Creative Cloud application. 


I take what I said back about the Acrobat deployment. It worked, but only after I closed the application. I did not see the command come through while the app was running. So, there does seem to be some difference in installing with app running vs. not running. I see this could be very useful to use, but we need a bit more control over the options and potentially some user interaction features. Sucks it's going to be restricted to Cloud subs though, many of us are stuck on on-prem because of Fedramp. 

thanks for the info.. I guess I did not expect much more then it acting like app store apps which seemingly do what they want as well. Guess I have always thought  there should be options to force close or wait till application closes on the deployments and being able to set maintenance period would be nice as well. 

Hi everyone. To provide a little more info, the installers cache on the end user Mac and then attempt to install once they are fully downloaded. The expected behaviour of what happens if the app is running to this point has been dependent on how the installer was constructed by the original software vendor. We were trying to use the original vendor packages as much as possible and were only repackaging if the original installers were either not available in a .pkg format and/or were not available as a universal installer. I provide a little more information about this here https://www.jamf.com/blog/jamf-app-installers-faq/

Unfortunately many vendor installer packages have some 'quirks' when they are deployed via the InstallEnterpriseApplication MDM command versus standard GUI or CLI methods, the Acrobat issue above is one such example. This will require us to repackage more titles than originally estimated to address these issues though this should provide a more consistent user experience. We have been doing a lot of work on addressing these behaviours and should be rolling out changes to the packages over the coming weeks. We are also still doing a lot of refinement on how the install process is triggered, versions compared and installation status recorded. Once this work is completed I hope to get some more technical documentation produced that will hopefully address more of the questions being asked in this (and other) threads.

Hi everyone. To provide a little more info, the installers cache on the end user Mac and then attempt to install once they are fully downloaded. The expected behaviour of what happens if the app is running to this point has been dependent on how the installer was constructed by the original software vendor. We were trying to use the original vendor packages as much as possible and were only repackaging if the original installers were either not available in a .pkg format and/or were not available as a universal installer. I provide a little more information about this here https://www.jamf.com/blog/jamf-app-installers-faq/

Unfortunately many vendor installer packages have some 'quirks' when they are deployed via the InstallEnterpriseApplication MDM command versus standard GUI or CLI methods, the Acrobat issue above is one such example. This will require us to repackage more titles than originally estimated to address these issues though this should provide a more consistent user experience. We have been doing a lot of work on addressing these behaviours and should be rolling out changes to the packages over the coming weeks. We are also still doing a lot of refinement on how the install process is triggered, versions compared and installation status recorded. Once this work is completed I hope to get some more technical documentation produced that will hopefully address more of the questions being asked in this (and other) threads.


Thanks for the additional info 

Something else I would like to see is logging for App Installers. I've been doing some very small scale testing and I can't tell if an app has installed or not - especially since it doesn't take inventory after installs. The only way I can verify an installation is if I get hands-on with the computer and get Info on the App.

@AVmcclint Yeah, that'd be nice. Even something in the History and logs section. One way I am reviewing if it installed the update is by having Patch Management Statuses set up on my Dashboard. You'll see the numbers trickle up. 

Something else I would like to see is logging for App Installers. I've been doing some very small scale testing and I can't tell if an app has installed or not - especially since it doesn't take inventory after installs. The only way I can verify an installation is if I get hands-on with the computer and get Info on the App.


@AVmcclint  and @mvu we have just introduced App Installers status reporting in Jamf Pro 10.40. I cover the new reporting capabilities in this blog post https://www.jamf.com/blog/app-installers-whats-new/

I have successfully setup several App Installer rules for maintenance and patching in our environment.  I attempted to set up OneDrive today and am getting the message "Unqualified for App Installer" for ALL the machines I manage.  How can I tell what the "qualifications" are so I can troubleshoot why this one doesn't work and all the others seem to?

Terms & ConditionsCookie settings