Curious as to why they require smart groups only?
@thebrucecarter unfortunately there was an incompatibility between what I will call 'traditional code' and the 'new code' that App Installers uses which meant that at this time we were unable to use traditional static scoping mechanisms. We hope to address this in a future release of App installers.
Hey Justin, I installed 10.37 in my on-prem dev environment and everything seems to be working with the enabled Cloud Services Connection. However, I am getting mixed signals about this being available for on-prem customers once it leaves the "preview" phase. Do you know if this will be available to on-prem environments? If not, I think we need to get a feature request going as this would be extremely useful (I'm sure) to us who have on-prem environments.
@joelsenders App Installers is for Jamf Cloud subscription customers. Whilst today App Installer will work with a non Jamf Cloud instance, it is not supported. There will be some changes in a future iteration of App Installers that will rely on infrastructure that is only available in Jamf Cloud. Once that change is made, the feature will cease to work in an on prem environment.
@joelsenders App Installers is for Jamf Cloud subscription customers. Whilst today App Installer will work with a non Jamf Cloud instance, it is not supported. There will be some changes in a future iteration of App Installers that will rely on infrastructure that is only available in Jamf Cloud. Once that change is made, the feature will cease to work in an on prem environment.
Thanks, Justin. For anyone who is on-prem and interested in this, please upvote the feature request here: https://ideas.jamf.com/ideas/JN-I-25878
I don't understand why this isn't being implemented into the Patch Management section where we can control who gets what version of the app (Early Adopters vs All). With this new App Installers, you have a choice of all clients or all servers. This should have been combined in one location,
I agree, need release branching and control like basic dev, testing & production to stage and control releases.
@JustinC is there a concept of rollback with the app installer implementation? What if you dev did testing and it worked as expected but when put into production something "issue" or breaking a app workflow was discovered can you easily rollback to a working version of the application?
Hi @andrewsp. @joelsenders is correct. App Installers uses MDM instead of the Jamf Binary so the underlying behaviour is constrained by what we are able to do with MDM commands. There are a number of other significant architecture differences with App Installers, the packages not being hosted on a customer distribution point as one example, that prevent us from just combining the two feature areas into one. There will be more control over the deployment behaviour in a future release of App Installers.
@JustinC historically MDM hasn't always worked properly or as expected. I understand that Jamf is trying to future-proof with using MDM, but seems like it might be "wise" to cover your basis and allow the Jamf binary be a backup or plan-B when issues arise with the MDM implementation.
Are app Installers Only Available to Jamf Cloud Customers?
So, the App Installer implementation is stated only available to Jamf cloud subscription, but initially might work with on-premise subscriptions? Is there a technical reason why it will be only available to Jamf cloud customers? If there is a political or financial reason, seems like you could consider other options to allow the on-premise customers the ability to use it until their organization can consider moving to a Jamf Cloud implementation due to multiple reasons like issues with upload stability or automation with the installer package with Jamf Cloud, or security.
I have created a feature request, please vote it up if you need or would like it available to on-premise Jamf instances.
https://ideas.jamf.com/ideas/JN-I-25878
Since App Installers will not work for on-prem, couldn't you give everyone the ability to download the packages you build on what I assume is a CDN you manage. We would at least not need to go out and get the packages for the software to use them in Patch Management, like we currently do. I have a feature request open for this.
https://ideas.jamf.com/ideas/JN-I-25896
So, do the client Macs get the installers (Word, etc) directly from a Jamf distribution site or directly from the developer’s download site (ie: macadmins.software)? This is a question I’m going to get asked by infosec.
I think it’s a great move for apps which need to go to “all” devices as part of the COE or “core” apps. Can’t wait to see more apps added.
Hi @davidi4,
I haven't investigated, but since these are Modata (Now Jamf) I believe they are customized versions of the installer with uninstalling features? Would like Jamf to provide more details about the installers, if they are customized and how are they customized, etc.
@thebrucecarter unfortunately there was an incompatibility between what I will call 'traditional code' and the 'new code' that App Installers uses which meant that at this time we were unable to use traditional static scoping mechanisms. We hope to address this in a future release of App installers.
Hello @JustinC,
Curious whether this was brought up in the BETA program at all?
FWIW I have raised https://ideas.jamf.com/ideas/JN-I-25934 bit disappointed that this feature does not follow the scoping format of the rest of the UI, especially in terms of static groups (we use these as rollout/testing groups) but hoping this could be implemented in the near future.
So, do the client Macs get the installers (Word, etc) directly from a Jamf distribution site or directly from the developer’s download site (ie: macadmins.software)? This is a question I’m going to get asked by infosec.
I think it’s a great move for apps which need to go to “all” devices as part of the COE or “core” apps. Can’t wait to see more apps added.
@davidi4 The clients get the software from a Jamf hosted source. We ourselves only work on install media directly sourced from the vendor, not third party download sites. With Jamf Pro 10.38 we have added additional metadata to each title so that an admin can see a lot more information about the package. This includes the original source URL of the package.
Hi @davidi4,
I haven't investigated, but since these are Modata (Now Jamf) I believe they are customized versions of the installer with uninstalling features? Would like Jamf to provide more details about the installers, if they are customized and how are they customized, etc.
Hi @uurazzle 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. This will require us to repackage more titles than originally estimated to address these issues.
Hello @JustinC,
Curious whether this was brought up in the BETA program at all?
FWIW I have raised https://ideas.jamf.com/ideas/JN-I-25934 bit disappointed that this feature does not follow the scoping format of the rest of the UI, especially in terms of static groups (we use these as rollout/testing groups) but hoping this could be implemented in the near future.
@iestynd We were aware of the limitation during development however did not want to hold up the release of App Installers due to this limitation and instead made the decision to release it with Smart Group based scoping and will add traditional scoping when possible.
I agree, need release branching and control like basic dev, testing & production to stage and control releases.
@JustinC is there a concept of rollback with the app installer implementation? What if you dev did testing and it worked as expected but when put into production something "issue" or breaking a app workflow was discovered can you easily rollback to a working version of the application?
@uurazzle during all of the customer research that was done prior to and during the development of App Installers numerous workflow options were identified. We will be bringing more control options over the deployment behaviour in future releases of App Installers.
@uurazzle during all of the customer research that was done prior to and during the development of App Installers numerous workflow options were identified. We will be bringing more control options over the deployment behaviour in future releases of App Installers.
Does the current process do any QA on the installer does it install or security or virus QA process on the developer installers? I have seen many developer installers that incorrectly set permissions or do many bad installation processes. For example, AutoPKG, uses virus total to do VirusTotal. VirusTotalAnalyzer is an AutoPkg processor to query downloaded files from the VirusTotal database. Since Jamf ones Jamf Protect, maybe it can be updated and implemented to do a security audit of App Installers before they are released in production?
Hi @uurazzle 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. This will require us to repackage more titles than originally estimated to address these issues.
Hi @JustinC:
So, I believe previously Modata provided uninstallers with their service. Since you are just using developer installers, will you make uninstallers available in the future? Or is the Jamf Pro admin to depend & trust on developer uninstallers or scripts or build custom ones themselves?
Does the current process do any QA on the installer does it install or security or virus QA process on the developer installers? I have seen many developer installers that incorrectly set permissions or do many bad installation processes. For example, AutoPKG, uses virus total to do VirusTotal. VirusTotalAnalyzer is an AutoPkg processor to query downloaded files from the VirusTotal database. Since Jamf ones Jamf Protect, maybe it can be updated and implemented to do a security audit of App Installers before they are released in production?
@uurazzle we do a security scan on all media downloaded before they enter our build process. We also have Jamf Protect running on our build test environment so that we can check for malicious behaviour whilst the app is running (which a standard AV scan on downloaded media will not pick up).
Hey Justin, I installed 10.37 in my on-prem dev environment and everything seems to be working with the enabled Cloud Services Connection. However, I am getting mixed signals about this being available for on-prem customers once it leaves the "preview" phase. Do you know if this will be available to on-prem environments? If not, I think we need to get a feature request going as this would be extremely useful (I'm sure) to us who have on-prem environments.
Don't upgrade to 10.38 they took away app installers for on-prem.
So, do the client Macs get the installers (Word, etc) directly from a Jamf distribution site or directly from the developer’s download site (ie: macadmins.software)? This is a question I’m going to get asked by infosec.
I think it’s a great move for apps which need to go to “all” devices as part of the COE or “core” apps. Can’t wait to see more apps added.
Hi @davidi4 . The client Macs get the installers directly from a Jamf distribution site. We are getting the original source directly from the vendor website (not from any third party sources) and then doing some additional work to the package to make it work properly with App Installers. You can see all of the source information within the metadata field when configuring an App Installer deployment for a given software title. The source link is clickable if you want to download the original source media for your own testing/discovery purposes.
Don't upgrade to 10.38 they took away app installers for on-prem.
I wish that I had seen this earlier. :( I was using app installers previously. The release notes on 10.39 say "App Installer Enhancements" - I guess by that they mean removal if you're on prem. This is kind of a kick in the pants...
