9.4 Known Issues

Is there an easy way to make this into a policy?
rm -r ~/Library/Caches/com.jamfsoftware.selfservice/
If I put this into a policy "as is", it will clear the Self Service cache of the management account, right?
And I want it to clear the Self Service cache of all the logged in users I scope to..

I tried something similar the first time I ran the policy to push the new app out, but it didn't work. It may have to be something like:

#!/bin/bash

# find current user
currentUser=`ls -l /dev/console | cut -d " " -f 4`

# remove selfservice cache in current user's user cache
rm -r /Users/$currentUser/Library/Caches/com.jamfsoftware.selfservice/

Or whatever (not the best at scripting on the fly, but I think you'll have to find out the current user before this will work).

You could try something like this to clear it out from all visible user accounts (UID 501 and up)

#!/bin/bash

while read USER; do
    rm -R /Users/$USER/Library/Caches/com.jamfsoftware.selfservice/* 2>/dev/null
done < <(dscl . list /Users UniqueID | awk '$2 > 500 {print $1}')

I would say Casper in general ref to 9.x simply have too many defects to be a working solution and version 9.4 just add insult to injury. It’s a real same JAMF’s can’t get the bare bones working before adding new features…?

This may sound negative, but when you spent hours trying to get things working… only to find out there are more defects.

Sadly our 9.4 upgrade went horribly wrong. The install process seemed to go ok, but then one of our admins noticed 2/3 of our policies had "disappeared." When we tried to revert the update and restore the database to the archive we created before starting we got a number of errors. Long story short we had to change max_allowed_packet to get the database to even restore. We are working with JAMF to try to figure out why our policies disappeared, but don't have an answer yet. In contrast our upgrade on our development server went very well.

We decided to move from 8.73 to 9.32 instead of to 9.4 due to existing defects and potential new defects. The upgrade went well, and we will continue testing 9.4x in our test environment. We did have to clear the Self Service cache to get our custom background back.

Got off the phone with our TAM and he informed me that theres an known issue with the clients CPU being pegged cause by the binaries which in turn drains the battery.

Hi everyone,

I've got a dev JSS server and even tho I delete Macintosh HD ? Users ? ~ ? Library ? Caches ? com.jamfsoftware.selfservice the self service is still defaulting back to the JAMF branding.

Was working fine under 9.32 and the required files are still in the same location on the server, so any suggestions?

Anyone trying 9.51? Sorry, I don't mean to hijack this 9.4 thread. :D

I'm running 9.5.1 in production. So far so good. Wondering about anything in specific?

I'm on 9.51 and my JSS Mac Mini servers are on 10.9.5. I found that for some reason with this build + this OS that the permissions on the files cause display problems. I've fixed this by going up to the ROOT folder within Tomcat web apps and applying it's permissions to all enclosed items. Once I did that, everything was displaying correctly.

You'll also need to note that any time you upgrade the JSS, you have to replace the custom imagery. It all gets written over when you do a JSS upgrade.

Interesting. My box's are running 10.9.4 so I'll keep a close eye out for this one.

At JAMF's request, I created a feature request since the 'enable ethernet adapter' issue still exists, at least in my testing with 9.65 and 10.10. I think it makes sense as something that should be built into the product.

https://jamfnation.jamfsoftware.com/featureRequest.html?id=3482