I am not seeing the same issue, just upgraded and Self Service is working for me. Have you tried restarting tomcat?

Have tried restarting MYSQL, Tomcat, and restarting mac OS based server.

Did you shut tomcat down manually before you did the upgrade? i have experienced issues when I did an upgrade and did not manually shut tomcat down.

Saw that on both betas. Going to be testing 9.81 beta today looking for that in particular...

No, I used to do that, but haven't done that in some time since I haven't had any issues. Good reminder though. Considering rolling back...

Is it only the OS X side of Self Service? I am only testing iOS and it seems to be working fine on my end.

I update the JSS from 9.73 to 9.8...... I hope this update will be correct my enroll problem !!!!!

@ryan.dean - I only tested OS X in the betas - 10.10.5 and 10.11. Will try to look at iOS as well, but we don't support that yet so it's less of a priority...

JSS is a Windows 2k server, FWIW.

We don't use iOS and Casper together.. so couldn't tell you.

OK, the self service install correctely and automatically like a normal deploy..... For IOS 9 you must install JSS 9.8 or newer

Many thanks to all

I decided to downgrade and moved back to 9.7.3.

You could try clearing the System and User cache on the client machine you're testing with.

We're having the same issue. We manually stopped Tomcat before the upgrade and restarted the server and everything went smoothy. Downloading stuff from Self-Service fails though with no info in the client logs. Currently investigating.

JSS 9.8, Windows Server 2012, Java 8 Update 60.

So far it's pretty random. Works for some, not for others.

No luck here, anyone else?

Edit: Support case opened, reverting back to 9.73 is also an option.

The policies I was having issues with (went through two betas for 9.8) i deleted today and re-created. They now work in the new beta. Don't know if that will help anyone, but it sorted things out for my issues so far with SS.

Ouch. We're seeing the same, and 25% of our computers are no longer contacting the JSS either. Double ouch.

I saw the exact same error as the OP, but all of a sudden it started working again. I also noted that no text was shown in Self Service's progress window. It's as if the JSS answered properly. Do we need to change thread count or something to prevent this from happening?

@bollman None of my OS X 10.9.5 machines are contacting my JSS. Even after installing a quick add package via ARD.

@tinsun Looks like it's randomly starting to work again for us as well.

We are on hosted JSS...new installs via Imaging are not running all of our policies correctly, though are receiving MDM profiles. Self Service errors out when trying to run anything.

Right, found a solution!
While looking at the LaunchDaemons created by jamf, we found one "extra", that should not be there:
bash-3.2$ ls -al
-rw-r--r-- 1 root wheel 757 22 Sep 11:10 com.jamfsoftware.jamf.daemon.plist
-rwxr--r-- 1 root wheel 474 22 Sep 11:10 com.jamfsoftware.startupItem.plist
-rw-r--r-- 1 root admin 537 22 Sep 11:10 com.jamfsoftware.task.1.plist
-rw-r--r-- 1 root admin 565 18 Sep 11:49 com.jamfsoftware.task.checkForTasks.plist

The one called "checkForTasks" was still running, but contained a reference to the old location of the jamf binary. The LaunchDaemon had in it: manage, and -removeLaunchDaemon.
My analysis tells me that this is a thing from the update to 9.8 that got left behind. The jamf binary had to remove itself and add itself again, and this is the part that did that, but since it got left behind, it was blocking stuff. So, I unloaded the daemon, but that did not help. Deleted the daemon and restarted, no go. But, then, after running jamf manage again, Self Service was working perfectly again. The computer is also connecting to the JSS at scheduled intervals so everything seems to be working fine!

Now, how did this happen? We are suspecting that it has something to do with cases where we see the jamf daemon as "hung" and perhaps this created this situation, there was a running, but hung, jamf process which made the "self erase" fail and leave this behind.

Anyways, we have a solution, but it involes having access to the computer, either remotely or physically.

@bollman good call!

Again, I'm on a hosted JSS and experiencing the same thing.

So far I've seen this exact com.jamfsoftware.task.checkForTasks.plist path issue on any machine that was imaged using pre 9.8 Casper Imaging. A machine I just imaged using the updated 9.8 Casper Imaging did not have the erroneous LaunchDaemon.

EDIT: Tested order of operations to fix
1. Delete com.jamfsoftware.task.checkForTasks.plist manually
2. Run: sudo jamf manage
3. Restart
Result: Self Service works, policies pushed from JSS now work

Any thoughts on how to automate this? Not sure how it could be done from the JSS given all old machines are not pulling policies.

@jordanfleuriet Where is the location of com.jamfsoftware.task.checkForTasks.plist?

@eagleone -

/Library/LaunchDaemons/

OK...I'm still getting this issue on my upgraded machine (10.11 Beta). I also did not have the com.jamfsoftware.task.checkForTasks.plist launch damon.

I think that really, you folks are going to have to wait got JAMF to release 9.81/9.82 to get where you want to be with 10.11. Remember, it's a beta - and things can/will change and JAMF is chasing their tails until it's finalized. Without saying a lot, the 9.81 beta is working here for most of the stuff I had trouble with on 9.8 betas...