Deploying a branded Self Service app

[smarley]

Hi everyone,

I'm new to working with the Casper suite, so I apologize if this turns out to be a simple question. I am currently in the process of trying to rebrand the Self Service app used at the company I work for (there are only a small number of Mac users, so this project is in its early stages). So far, I've been able to update the app with custom icons and a new name by modifying the info.plist file and have created a package for the newly branded version of the app, which I have deployed and tested on my own computers. However, since this is an environment where enrolled users already have the standard Self Service app installed on their machines, I wanted to know if anyone has recommendations on the best way to replace this with the new branded version of the app I've worked on. Should I be looking into creating a script which will detect and remove the older Self Service version or are there alternative solutions which you've found to work better?

Thanks in advance for any help or suggestions!

[emily · Accepted solution]

Removing the old one may be tricky… even if you have the DMG indexed it may not get all of the components. I'd probably recommend a script that trashes what's left of the old one, then a separate policy that installs the new one (and then flushes the user cache). There may be a more sophisticated way to accomplish it, but I just threw this in an "after" on the policy that uninstalled the old SS app.

#!/bin/bash

rm -Rf /Applications/Old Self Service.app

And then a second policy ran based on a smart group where that app wasn't installed and pushed the new version of the app on Check-in.

[spotter]

@emilykausalik][/url did a great presentation on this during the last JNUC... here is the link to the video

https://jamfnation.jamfsoftware.com/jnucEvent.html?eventId=87&view=video

I created a policy that would uninstall the current Self Service then install the new "Branded" Self Service app and flush the user cache. This process has worked really well for me and have only had a few instance that required special attention.

[emily · Accepted solution]

Removing the old one may be tricky… even if you have the DMG indexed it may not get all of the components. I'd probably recommend a script that trashes what's left of the old one, then a separate policy that installs the new one (and then flushes the user cache). There may be a more sophisticated way to accomplish it, but I just threw this in an "after" on the policy that uninstalled the old SS app.

#!/bin/bash

rm -Rf /Applications/Old Self Service.app

And then a second policy ran based on a smart group where that app wasn't installed and pushed the new version of the app on Check-in.

[Aaron · Accepted solution]

I have a single policy which installs the new Self Service and removes the old one in one hit.

What I do, is package up the new Self Service via Composer, push it out with a policy, and under Files and Processes fill in the "Search for File by Path" with "/Applications/Self Service.app" and tick the "Delete file if found" box (I also kill "Self Service" under "Search for Process", just in case). I name my Self Service slightly different, so your mileage will vary with this technique.

[smarley]

Thanks @Potter and @emilykausalik!

I ended up using the script you wrote above Emily and it worked great!

I am really new to scripting, but I ended up adding to the script you wrote so that I only need one script which runs after installing the branded Self Service app that kills the original Self Service process, removes it from the Applications folder, and then opens the new app. This might not be the best way of scripting this but it seemed to work well on my test machines so far:

#!/bin/sh
pkill -9 "Self Service"

rm -Rf /Applications/Self Service.app

open /Applications/New Self Service.app

Thanks again for your help and for the inspiration to try this out!

[adamcodega]

Don't forget to upvote the feature request.

[smarley]

Done @adamcodega!

[scottb]

Assuming you have to repeat this every time you get a new version of the JSS?
Thanks for the info on it - I'd like to offer this, but am hesitant as it would need to be rebuilt/distributed after every upgrade.

[adamcodega]

Yes, I've brought up the concern as well, but you won't have much problem using an old version of Self Service with a newer JSS. You can also script the changes to Self Service so it's fewer steps to make the changes.

[emily]

@boettchs][/url I only upgrade it after big version changes. When 9.6 came out I rebuilt and re-deployed but went up to 9.65 before re-deploying and it worked fine. Most of it is just a web interface anyway, so the app is pretty low profile on its own.

[scottb]

Thanks Wonder, er, @emilykausalik. I was not aware using older versions of SS would be advisable. So maybe it's worth a shot to see how this works.

[emily]

I ran 9.6 through to 9.65. I ran 9.4 through to the last 9.4 build, 9.5 through the last 9.5 build… and honestly it doesn't take all that long to make the updates and then deploy, it's just become part of my JSS update workflow. But every environment (and job) is different so not everyone will want to bother.