Making updates to installed apps visible in Self Service

I use the same packages that I'm using to push updates, but scope it to a smart group that is made of of machines WITH the application where version IS NOT <current>. Basically same approach as regular pushes, but in Self Service.

From my experience though, most users will never update this way. I'll make things available to my test group via SS, but if they don't install, they get the push with the production group.

@Taylor.Armstrong Good to know. Could you expound on your "they get the push with the production group" statement?

We basically run on a weekly release schedule - push updates out to a test group, give them a week to test, and then the following week the update goes to all remaining "Production" systems via a standard "install" policy. I used to scope the "Production Install" only to production systems. After realizing how few of my "test" users actually ever installed the updates via the Self Service app, now I scope "Production" to all systems not on the latest version. Otherwise my "test" boxes were often the most out-of-date when IT Sec ran their scans.

We use the same approach as @Taylor.Armstrong.

Most of the software in our JSS has a smart group associated with it. For example, I have a smart group called Fetch v5.7.5 installed. I create a Self Service policy called Fetch v5.7.5 Update and scope it to all computers, excluding those in the Fetch v5.7.5 installed smart group.

If the software is installed on the machine, the policy does not appear in Self Service.

When it comes time to update the software (new version comes out), I either create a new smart group with the updated version, or just edit the current smart group, depending if I still need the older version advertised.

Hope that helps!

One other thing to look into, if you haven't already is AutoPKG. Most of the .jss recipes out there will automatically create the smart groups, and policies for you, and present the software via the Self Service app. As I said - my experience was that Self Service wasn't being used enough, so I just go and tweak the policies to push the apps out to all machines after the test period instead of excluding the test group.

So in essence, for every "managed" software title, we have two policies, and two smart groups: One for test, and one for production. AutoPKG takes care of most of the test groups and policies, you just need to make yourself some sort of checklist or otherwise make sure you stay on top of manually updating the production package versions for the smart groups, updating the package version in the policy, and flushing logs, each time.