Self Service

New Contributor II

How do you make apps available to all Macs all the time? We have separate policies to install applications based off smart groups. What I would like is to allow users to reinstall these apps at their leisure. We have Self service enabled and for each of the policies already is there a way to do this without having to create separate policies just for self service?


Release Candidate Programs Tester

Unfortunately, no.

You'll have to create a policy for each application and make sure it's available in Self Service. Turn off all triggers so they don't deploy automatically. Scope it to all or your desired Smart Groups.

Create a new group called " Self Service" and just put them all in that group so you know the differences between your policies.

Valued Contributor II

Doing the above works but also creates a headache come updating that package.

A few years ago IBM showed their method which made alot of sense.

Every policy within self service or other methods do not contain a package or config. Instead, there's a master policy that is invoked by the event...

EG Self service we have "install firefox" and reinstall firefox. Those policies only trigger through the command jamf policy -event install_firefox
The polices within self service unless neede do not include a version number.

Come time to update the policy's package we update the install_firefox policy, thus insuring we only have to update one policy.

Valued Contributor

We don't push anything to our users (well, nothing over about 100KB, so just stuff like plist files or configuration profiles) since their internet connections could be anything from a 256Kbps satellite modem to a bureau in Africa with 2Mbps line shared by 10 people, to someone in NY or DC or Atlanta sharing our east coast OC192 (10Gbps - ::drool::). Because of that we do almost everything through Self Service. Let the users do the work based on their internet capabilities.

Now, this may seem like a lot, and it is when doing it for a new app. We have at least two, usually simple, smart groups for each individual application. An example here would be "SW - Handbrake" (Application Title Is and Application Version is 1.1.2) and "SW - Handbrake Out of Date" (Application Title Is and Application Version is not 1.1.2). Some have to be a bit more complicated and we've a large number of EAs for stuff that Jamf can't find a version number for (drivers for example). I use a prefix to all my smart groups so they're usually lumped together. "HW - 2016 MacBook Pros", "Dept - Engineering", "OS - 10.13", etc.

Then we have at least three self service policies.
– One is a clean install (scope is targeted to all machines, exceptions being any machine that is in either "SW - Handbrake" or "SW - Handbrake Out of Date"), the self service button says Install, and the icon is the app icon.
– One is a re-install (scope is targeted to all machines in "SW - Handbrake", exceptions being any machine that is in "SW - Handbrake Out of Date"), the self service button will say re-install, and we use a version of the app icon with a "Installed" banner across it to make it very obvious it's a reinstall. f63ce920f46e44f5b5a9445984552258
– And one is an update (scope is targeted to all machines in "SW - Handbrake Out of Date", exceptions being any machine that is in "SW - Handbrake"), the self service button says Update, and the icon is the app icon.

Some of those self-service policies may include scripts to delete or uninstall the existing installed app (or driver or plugin or...). And Jamf 10 made the button names a little 'wonky' because now there is a second button option for each self service policy, so adjust that secondary button label as needed so it's not to confusing.

With all that, users should only ever see one self service item per application. That should be a reinstall for anything they already have installed (so they can reinstall it as a troubleshooting measure), an upgrade when a new version is available, and an install for stuff we don't normally pre-install for them (Cyberduck for example).

When a new version comes out we just package it up (if it's not already a usable pkg), upload it to the server, swap the old package in Jamf Admin with the new package, change the three Self Service policies to use the new package, and then change the smart groups to use the new version. Doing it in that order means that the self service polices will run the right version even if the user is clicking it because they had an even older version.

I just LOVE when I can use a script to do the install though. No need to package anything, just test the script to make sure it still works and change the version numbers in the smart groups.

Some scripts that I've started using include...
• Install Adobe Acrobat Reader
• Install Adobe Flash
• Install Chrome
• Install Firefox ESR
• Install Java 7
• Install Sierra
• Install Slack
• Install VLC

And we use the Featured category as the default category on launching self service, and important updates or new installs are marked as Featured to emphasize their importance (Security, functionality, or work mandated new app). Updates go in a category simply called "Updates". A category called "Installed" is where the reinstall policies could be found (in addition to being in other categories like Internet for browsers). Between the Search, putting stuff in multiple categories, and flagging important stuff as Featured we've tried to make it easy for our users to stay up to date.

We tell them they should check Self Service before they go on any assignments (never know when you'll go to a bombed out village in Syria and its too late to get that important update), and at least check self service once a week otherwise.

New Contributor II

What I ended up doing is modifying our current policies (prefixed with Deploy-) so that they are set up just for self service purposes. IE scoped them out to all computers, removed all triggers except a custom trigger, deploy_<appname>, and changed the frequency to ongoing. This makes the apps always available in self service. Next I created new policies (prefixed with Auto-) which will keep our automation in place. These policies are scoped to the smart groups for systems that do not have the apps, have a trigger for reoccurring check-in and a frequency of once per computer. All the Auto- policies do is call jamf policy -event deploy_<appname> which is what rderewianko suggested. Overall this seems to be working well and only requires us to maintain the Deploy- policies. Thank you all for your input!

New Contributor III

Saw this post and wanted to ask a question as I am trying to fully understand Self Service. I put a policy in there to run all Apple updates by script (softwareupdate -i -a). I want users to be able to run all updates at their convenience and it seems to work. However, on my test Macs, when I restore to a previous state, to begin testing again, that update script runs again on first check-in. I don't understand why it automatically runs when its only in Self Service with no triggers. I remove the test Mac from Jamf completely, remove Jamf Framework, restore to previous state, 12.12.x, re-enroll into Jamf using a different name. The Mac checks in, gets all the standard policies I have setup, but them I see the softwareupdate script run. I am obviously doing something wrong here. I want that Self Service policy to be available to all my Macs enrolled, all the time. If someone wants to update their Mac, they can at their convenience, then run it again a month or so later if needed. Does this make sense? Thanks

Legendary Contributor III

@tavaresj Have you double checked to make sure there are no other policies scoped to those Macs that might be getting triggered? Like something that uses the check-in trigger? Outside of that, check to make sure the Self Service policy has no triggers assigned to it. When setting up a Self Service policy, the Self Service app essentially becomes the trigger, so all the other triggers can and should be disabled, with the possible exception of the custom event trigger, which would only get called by a script or by someone in Terminal, but not by the computer on it's own.

If you've gone through all that and confirmed there aren't any other policies that could be doing this, and the one software update policy is only set for Self Service, and it's still happening, then there's something else going on. Because as you guessed, a Self Service only policy should not run on its own unless called by the Self Service application.

New Contributor III

@MM2270 I checked and there is no other policy scoped that would cause this. I restored my test Mac again, enrolled under a different name again, same process. Got all the other policies for standard enrollment, then the software updates hits it. I see it initiate in Terminal when i perform a check in. I scoped just that one test Mac to that Self Service Policy with no trigger. Had frequency as "ongoing" since I wanted it to always be available in self service. I also didn't realize there are no logs for Self Service Policies? Anyway, unless you see something I may have wrong, I'll put in a ticket and see what happens. I am going to test again, but have that policy shut off.

Legendary Contributor III

What exactly are you seeing that's making you think it's coming from Jamf? Is it possible the Mac is set to auto install updates in the Software Update settings?

As for logs, yes, Self Service policies have logs just like any other policy. You just can't necessarily tell from the log if the policy trigger was Self Service or something else, but they should be there.
OTOH, if any policy (not just Self Service ones) causes the Mac to restart before it can actually complete the policy and send back a log to Jamf Pro, then it does appear as if there is no log. It's just an issue when a reboot happens before it can actually finish running the policy. Perhaps that's what you're experiencing?

New Contributor III

@mm2270. Thanks for the response. I have tried this multiple times. Made sure any policy running softwareupdate is off. I even shut off the Self Service policy yet the system keeps getting updated. All my policies run, then you see at the end, softwarupdate runs and I can't pin down what is triggering it. It's driving me nuts. see below lol

Submitting log to
Executing Policy Install Rapid7 with PKG
Downloading Rapid_7.pkg...
Verifying package integrity...
Installing Rapid_7.pkg...
Successfully installed Rapid_7.pkg.
Submitting log to
Executing Policy Install Zoom
Downloading Zoom456_5666_1020.pkg...
Verifying package integrity...
Installing Zoom456_5666_1020.pkg...
Successfully installed Zoom456_5666_1020.pkg.
Submitting log to
Executing Policy Install Zscaler App (only on Laptops)
Downloading Zscaler-osx-
Verifying package integrity...
Installing Zscaler-osx-
Successfully installed Zscaler-osx-
Running command sudo -s open /tmp/Zscaler_installer/
Result of command:
The file /tmp/Zscaler_installer/ does not exist.
Submitting log to
Executing Policy Microsoft Office 2019 ver. 16.30.19101301 10/22/19
Downloading Microsoft_Office_16.30.19101301_BusinessPro_Installer.pkg...
Verifying package integrity...
Installing Microsoft_Office_16.30.19101301_BusinessPro_Installer.pkg...
Successfully installed Microsoft_Office_16.30.19101301_BusinessPro_Installer.pkg.
Installing all available Software Updates...

New Contributor II

I know this doesnt answer the why this is happening question you have but you can do this without a script. Just create a policy that has the payload "Files and Processes" then under "Execute Command" add the SoftwareUpdate -ia or SoftwareUpdate --all --install --restart (thats what I have for mine). Set the "Execution Frequency" to ongoing but do not select any triggers. Make sure you enable it for self service and give it a nice icon and description then scope it to everyone or just a group of users you want. I've attached some screenshots of my self service upgrade policy. Hopefully that helps some.