My environment has been using Jamf for about 6 months and we initially installed a custom branded version of self service 9.98 through a computer policy. I am now wanting to upgrade this to the automatically deployed version of self service 10 that can be branded through the jamf console instead of having to be deployed as a custom package. I have poked around in the console to try and figure out how to do this without success. I was hoping that someone here could help me with this.
I assume you disabled the automatic push of Self Service to enrolled devices. You can find that in Management Settings > Computer Management > Self Service. There's a checkbox there labeled "Install Automatically" for the Self Service.app. My guess is that's disabled right now since you pushed out a custom version. If you enable that again, it should push out the new v10 version and overwrite the one you have on systems now.
I recently just pushed v10 of SS to my environment, like you, replacing a "customized" version of SS v9.x (custom icons, etc. etc.).
My testing revealed that I had to first remove the old SS, then install the new version. In one policy, I have a script that runs "before" the install of v10, that removes the old one.
If I simply overwrote the old version, the app froze. My guess is that you can't just replace it because v10 is a newly written app, and conflicts in the coding will make things slide sideways.
Also, get your hands some VM software (I use VMWare), load up a macOS VM, manage it with JAMF, and you can run all sorts of tests on it.
@jchin-ro it likely won't update if there is a preexisting version, you might need to initiate removal via script that also runs
jamf manage to kick this off.
One thing to keep in mind is that, at least in my testing on 10.4, the icon branding would only initialize after the app was launched and user logged in for the first time (which is why we kept customizing + packaging, as the oob workflow adds confusion to documentation)
It might also be worth to check whether the clients have the 'do_not_upgrade_jamf' flag set, and delete it if set. We had quite a few clients that had set this at some stage. The annoying thing is that even re-enrolling the devices does not clear the flag. To get rid of it you either delete it explicitly, or completely remove the framework - which is a bit of overkill.
@jchin-ro : to check for the 'do_not_upgrade_jamf' flag run "/usr/bin/defaults read /Library/Preferences/com.jamfsoftware.jamf.plist do_not_upgrade_jamf". Under normal conditions you will get the error "The domain/default pair of (/Library/Preferences/com.jamfsoftware.jamf.plist, do_not_upgrade_jamf) does not exist".
We have introduced an extension attribute and a smart group for this, allowing us to inform our users and give them the option to reset this via the Self-Service - which of course only works if the client uses a current version of the jamf binary 😞
We don't set the flag to false or zero, we just delete the entry completely by running "/usr/bin/defaults delete /Library/Preferences/com.jamfsoftware.jamf.plist do_not_upgrade_jamf".
I found out that Jamf Pro (hosted by Jamf Cloud) is still on 10.10.1 while the Patch Management is already showing 10.11.1, so that is why it shows none of them running the latest version. I guess once Jamf Pro upgrades to 10.11.1, then Self-Service will also update. Guess Jamf needs to make that information more clearly available in their site.
I found out that Jamf Pro (hosted by Jamf Cloud) is still on 10.10.1 while the Patch Management is already showing 10.11.1, so that is why it shows none of them running the latest version.
@jchin-ro I am running into the same problem with updating self service 10.33.0 using jamf cloud. I have received notification that a new version of self service was available. Clients are not auto updating, and jamf pro is currently at 10.32.2. Has a work-around been identified or do you continue to wait until jamf pro is updated.