Self Service has Encountered a Problem

[tuinte]

Hey, JAMFnation!

I've been getting a seemingly random Self Service error on about 10% of our machines. First saw it in production but have had a few immediately after imaging as well.

The app itself does this:
external image link
Console's giving me this:

external image link

"01. Refresh Page" is the policy selected in Self Service (it's just an Update Inventory), but if I'm getting that error on one Self Service item, I'm getting it on all of them. Waiting a minute doesn't seem to get me anywhere. Removing the framework and deleting the item in the JSS, then re-Reconing doesn't resolve either.

All that happens, but Casper Remote and policies not run out of Self Service (i.e., recurring check-in) work fine. Weird, right?

Any ideas?

Thanks for any help!

Michael

EDIT: JSS is 9.24, all machines 10.8.5

[sprattp]

I have also started seeing this, although only on a few computers, in my case restarting seems to have fixed this issue

[irishrose0312]

Rebooting has not helped the issue with the two that I have run across. Still have not figured this out.

[elliotjordan]

I'm also having this problem. Investigating today, and will follow up if I find a fix.

[rderewianko]

I've seen this with 9.3 and have an open support case on it:
ref:_00D80cOw4._500C0YrdJI:ref

We ended up going back to 9.25 for the time being.

It happens for us on new enrolls, new machines being imaged.

[njwinter]

I'm seeing this when trying to install a cached copy of Mac OS X 10.9.
JSS: 9.3
Target machine: 10.8.5

[esoeast]

We were able to take the Self Service app from an upgraded machine (we upgraded from 9.22 to 9.3) and it seems to be working.

Seems to be only happening with newly imaged machines and looks to be more like a corrupt binary issue (ruling out lib issue because the copied app seems to work).

EDIT: The 9.2x Self Service works until the next time it contacts the JSS. After that it is back to the same issue.

[elliotjordan]

We temporarily resolved this by turning off certificate-based enrollment, then re-enrolling the problem computers.

[were_wulff]

Hey @elliotjordan ,

That makes me a bit curious about something.

Would you mind going into your JSS and taking a look at the following things:

1) System Settings >> Activation Code. Does the Organization Name have any special characters, especially a comma?

2) Global Management >> JSS URL. Does the JSS URL for Enrollment Using Built-in SCEP and iPCU have anything filled out?

If so, we could try removing any special characters, and removing that second URL, regenerating the Tomcat certificate, and restarting Tomcat to see if that clears it up.

Thanks!

Amanda Wulff
JAMF Software Support

[elliot-p]

[duplicate]

[elliotjordan]

Hi @amanda.wulff][/url,

1) Yes, we do have a comma in the Organization Name.
2) No, that field is blank. (We only manage Macs, not iOS devices.)

I'll see if we can remove that comma and regenerate the Tomcat cert. Thanks!

Elliot

[were_wulff]

@elliotjordan ,

Removing that may take care of a few things, as we do currently have an open defect (D-006702) there; the behavior that we tend to see, if there is a comma in the organization name, we see the following:

- On clients, when trying to enroll/re-enroll: "There was an error. Unknown Error - An unknown error has occurred"

- In the JAMFSoftwareServer.log: "Error processing communication content - java.lang.NullPointerException"

The notes from our dev team mention that the following characters, in addition to commas, can cause the issue: " < > ;

Thanks!

Amanda Wulff
JAMF Software Support

[spowell01]

Were getting the same exact error on a single machine as of today. Machine is at 10.9.2 and JSS 9.24..I tried to re-enroll the machine as well as copy a working self service from a good machine.

We do not have a comma in our org name either....anyone get a final solution on this? Think it would be solved in 9.3?

[johnklimeck]

I have un-enrolled and re-enrolled, and the error message goes away.

This is on a newly imaged Mac, makes no sense. Should not be happening.

Please fix.

thx,

John K

[btaitt]

@amanda.wulff ,

We've started to encounter the same issue (9.31) on a few computers and seemingly all of our newly imaged computers.

Our organization name does not have any special characters and we do not have anything filled out in the "JSS URL for Enrollment Using Built-in SCEP and iPCU" field.

[were_wulff]

@btaitt ,

I’d recommend opening up a case with your Technical Account Manager for this one.

We’d want to send over the following files to get started:

From an affected client (OS version of the client may help here as well, so be sure to include that in the e-mail):

- jamf.log
- system.log

From the server:

- JAMFSoftwareServer.log

If any of the files (or the combined sizes of the files) are over 10MB, we’ll need to zip them up so they’re under 10MB, otherwise our mail server will reject the message.

If zipping them up doesn’t make them smaller than 10MB, go ahead and open a case anyway and just ask your Technical Account Manager to send instructions on how to use our file transfer appliance to get them sent over.

Thanks!

Amanda Wulff
JAMF Software Support

[Chris_Hafner]

Hello again Amanda. We're also seeing an increase with this issue (only since 9.3, though we are now on 9.31). I'll go ahead and open a ticket with my account manager, though I may give her a small breather as she's going through other issues for me at the moment ;-)

[Macintosh_HD]

I had this issue in one of the Macs and I ran this to fix the issue: sudo jamf enroll -prompt

[Chris_Hafner]

It's a mixed bag in my experience. It's easily solvable... manually, which is a huge pain when you're talking about hundreds of computers!

[were_wulff]

Hey all,

@robinsonjo came across this little fix that seems to help out in cases of Self Service crashing AND in cases of computers that won’t automatically run policies on triggers when they’re supposed to (there is usually an error in the jamf.log, around the time of enrollment, about a failure to create the Launch Agent):

Try blowing away the crontab contained in /etc on affected clients.

What he found was that there was a check for task cron job contained inside it that kept running sudo jamf manage every minute in a loop that was, for all intents and purposes, infinite so long as the computer was powered on.

We’ve seen this resolve the seemingly random Self Service crashes as well as solve issues where computers appear to enroll but won’t run any policies on automatic triggers or throw errors about being unable to create launch agents in the jamf.log.

Thanks,

Amanda Wulff
JAMF Software Support

[corbinmharris]

Having this issue with just one MBP in a remote office. I removed all the JAMF related components, restarted and then ran Recon from the Mac (as well as remotely).

sudo jamf enroll -prompt does not resolve the issue and not sure what to look for in /etc - there is not a"crontab" file present in /etc.

Thanks!

Corbin

[were_wulff]

Hey all,

Out of curiosity, do any of you have the CrashPlanPROePlug-in bundle configured for your environment?

Amanda Wulff
JAMF Software Support

[hendersong]

Having the same issue with a new Mac. Have completed all the steps and the issue persist.

As of right now only one Mac is having this issue and hoping no others start...

[Chris_Hafner]

Sorry to hear that. A LOT has changed since this post was last updated. Could you give a broader description of your environment and your issue? Also, what are you seeing specifically and what have you tried and what were the results?

[kayc]

I was able to fix this issue by running "sudo jamf manage" in the terminal on the affected machine.