Excuse me if this has already been asked. I did a search and could not find anything related.
As part of our Jamf deployment, we use a few policies to push software out to our Mac's at enrollment time. We also automatically install Self Service.
We added some of the same software packages to the Self Service portal incase a user has to reinstall, etc. What I noticed is that if I go into Self Service, it lists those same software packages as "Install", rather than "Open" or "Reinstall". The software that is associated with the App-store (setup through JSS) shows "open", which makes sense.
Does anyone know if there is a way to get an association of the non-app store installed software with that of the listings in the Self Service? Does Self Service use package receipts as its mechanism after one clicks the initial install button to know if a device already installed that self-service item? If yes, are the receipts unique per software, or instance? I'm thinking if its per software, I can just capture all of the receipts, and install them on any device in an enrollment policy to properly update what the self service buttons say.
@dfriedlander I think it's just a state indicator in the policy so if you have somethings set to Ongoing for the Execution Frequency the user can tell it's been run before. What I prefer to do is have a Smart Group to indicate if the payload of the Policy is installed, and use that Smart Group as a Scope Exclusion for the Policy so that the user does not see the item in Self Service if it's already installed.
@sdagley I see what you did there. I just changed the scope for exclusion on one of my policies (and I had it installed) and it disappeared from Self Service.
Not a bad alternative if no one out there knows if there is a way for it know the same software was already installed and say "Open" instead.
Thanks for the tip.
@dfriedlander You could have another Policy with Ongoing as the Execution Frequency that had the same Self Service name as the installation Policy and Scope it to a Smart Group that indicated the app you were interested in was installed and both Before and After Initiation labels read Open and the only payload in the Policy was a Files and Process with an Execute Command to launch the app (you would have to craft a command that launched it as the logged user since the Execute Command is run as root so it might be better to write a script to do that and you could re-use it in other policies)
Old thread I know, but still... See if this makes sense...
We have our MS Office install policy setup with the Trigger of Enrollment Complete with Execution Frequency set to Ongoing. We also show it in Self Service where it will show Reinstall properly after having been installed after Enrollment Complete. Setting the Execution Frequency to Ongoing (rather than our original thought of Once Per Computer) allow us to utilize the Reinstall option in Self Service for troubleshooting app problems. We can remotely trash any of the apps that are problematic and just reinstall. I'm assuming that if it's the very same policy then Self Service is smart enough to know if it's already been successfully run in order to show the Reinstall option.
Speaking of reinstalling, we're also thinking about creating Self Service policies specifically for troubleshooting of high priority apps (like Office) which include scripting to first "uninstall" or just trash the apps prior to (re)installing, to eliminate the need for remote control and admin credentials. We discovered that updated Office apps don't get replaced if you reinstall a previous version (i.e. 16.30 vs 16.50).