Casper 9 Self Service issues/bug

[MChivers]

Wanted to reach out to see if anyone else is seeing this same thing. We have a test server of Casper 9.31. When attempting to queue items in Self Service anything set as "waiting" will fail and an error message will appear stating Self Service has encountered and error please try again in a few minutes. Even when you attempt to run the same installation or different that was not queued; they will fail. The only way to allow self service to allow installs again is to restart the machine then as long as you install item by item no issues. is anyone else having this same issue and if so, was there a fix you were able to use.
It seems if you are able to queue and they state waiting until the first is finished installing.

[#2]

I'm seeing similar behavior in Self Service 9.32. Seems like queuing multiple policies/upgrades etc just doesn't work reliably, though honestly I haven't tested very thoroughly yet.

[scottb]

Are you talking about launching Self Service and clicking install on a bunch of items?
Or a policy with more than one package in it?
What sort of DP - SMB, AFP?

[#4]

In my case, multiple installs of straight-up DMGs or PKG/MPKG (say Office update) from an AFP distribution. Letting a single install run and complete works as expected.

[scottb]

Yeah, I have that on all the 8.x versions we've run. Not on 9.xx yet but sorry that it still exists.
We had to tell techs to do one at a time and go to the next. Sometimes, I've seen it run multiples OK, but no rhyme or reason. Using all SMB DP's on Wintel servers.

[were_wulff]

@RPearce & @pete_c][/url

Have you guys taken a look through this thread yet? It seems to be a somewhat--commonish--issue with 9.3, though we have seen it as far back as 9.24, and that thread has a few different things that we can try to get it to stop.

We're still not sure what the root cause of it is, but seem to have the most success with removing /etc/crontab on affected machines for 9.3x JSSes, and relaunching Self Service.

In some cases, running sudo jamf enroll -prompt on the affected clients seems to take care of it as well, though that can be kind of a pain if there are a bunch of them that are doing it.

Are your affected machines running Mavericks? If they are, see if killing the "not responding" jamfAgent process gets it to kick off; if it does, please open up a case with your Technical Account Manager to let them know. We have a defect open for that jamfAgent process appearing to be hung and it's been bumped up to a higher priority as we're seeing it now start to affect things, whereas in the past, it seemed to be a mostly harmless 'incorrect reporting to Activity Monitor' issue. For reference, the defect ID for that issue is D-005179 and it is a Mavericks only issue (we don't see the behavior in 10.8 or older, it has to do with the jamfAgent using a function from the Process Manager API that was deprecated in 10.9
The offending bit of code is a GetProcessForPID(). After that method gets used, the jamfAgent gets flagged and the 'not responding' issue will start to occur.)

If you haven't yet opened up a case with your Technical Account Manager, I'd recommend doing so so we can keep things tracked and catalogued; if we need to get a defect opened up around the behavior, the more evidence we have, the better!

Amanda Wulff
JAMF Software Support

[#7]

@amanda.wulff Thanks for this info, I will take a closer look on a test machine later today.

[MChivers]

@amanda.wulff Thanks for the info. I ran sudo jamf enroll and the same issues occurred. I will open a support ticket with our Technical Account Manager