I've reached out to support, but in the meantime I'll present the issue to the Nation. I'm experiencing an issue where none of my Casper applications can communicate properly with the JSS, even when logging in with the local account vs AD account. Casper Remote reports "Could not parse data from JSS" and Casper Admin reports "The server located at https://JSS:8443/ did not respond with valid information. Please check the server information and try again."
This is after an upgrade from 8.71 to 9.1 and I am running the 9.1 applications locally on my computer.
Best answer by Kprice
OK My issue has just been resolved with the help of Support. I somehow overlooked (my bad) that there was a "Wingding Like" question mark before one of the machine names in Inventory. This was an older machine that was enrolled via Quick Add package through ARD. Not even sure how the special character would have got there. Removed the character and with Supports advice Ran SQL commands; update jamfsoftware.computers set computer_name="SN-QP81509AXxx" where computer_id=903; update jamfsoftware.computers_denormalized set computer_name="SN-QP81509AXxx" where computer_id=903;
Remote is back in business. Hope this helps others.
Hold alt when launching a Casper app and retry the JSS address? Does the Casper Suite work from another Mac? Can you jump on the web portal at https://JSS:8443? Or can you communicate with the jamf agent? (sudo jamf checkJSSConnection, or sudo jamf manage?)
Just wondering if it's just the Casper Suite instance or not.
I'm wondering the same thing. If the JSS and Casper apps are working properly everywhere else it may just be a simple DNS issue. Can you recon from your machine (Almost the same as vadanx's question: (sudo jamf recon -verbose)
Issue persists after re-entering address, as well as opening the applications after clearing their plists and keychain entry for the stored username.
Same issue on another mac
Web portal works fine
Connection to JSS via binary works fine, too
sudo jamf recon works, although I am getting the same CRUD error (as described on a few other JAMF Nation threads) on a few machines
Issue persists regardless of entering FQDN or IP address of JSS
The default port is still 8443 for the applications, right? I'm pretty sure that didn't change with 9.x.
I appreciate the assistance, everyone. It looks like the applications can successfully authenticate with the JSS because if I enter bad credentials it gives me that error instead of the ones I originally described. It seems the applications don't like the response they're getting from the JSS.
i had the same issue a while ago... and jamf support told me to stick with 8.71 while they were looking at that... i was hopping for 9.1 to fix that...
@bajones Any updates? I have similar issue, but just seems to be affecting Casper Remote. It was all working fine after the 9 and 9.01 updates. Out of nowhere, Remote is throwing up "Could not parse data from the JSS." Same from different machines and different users.
Just Remote here. Admin and Imaging work fine.
I have a Support Case open but no resolution yet. Things we've checked and tried.
Of coarse reinstalling the JSS.
Made sure that there were no invalid characters in Package info that would be flagging us. All appeared fine.
We truncated the database. No such luck. They asked for a copy of the Database to finger through and will advise of the next steps.
I'm seeing this as well. Also see an occasional "connection failure" when running update inventory policy. Wile next time it runs just fine. Anyone seeing this to?
Oddly I am seeing these errors sporadically as well. They don't seem to affect much other than the recon process in question but I haven't had the time to jump into the logs on those given the profile issues I'm trying to sort out as well.
what we have been doing is remove the com.jamf* stuff in Library/Caches and Library/Preferences then it will connect one time. just repeat every time you need to startup those apps. And actually i don't remember if it helped with Remote... so i just tested and it does not help with remote, but Admin will start. I am on 9.11
OK My issue has just been resolved with the help of Support. I somehow overlooked (my bad) that there was a "Wingding Like" question mark before one of the machine names in Inventory. This was an older machine that was enrolled via Quick Add package through ARD. Not even sure how the special character would have got there. Removed the character and with Supports advice Ran SQL commands; update jamfsoftware.computers set computer_name="SN-QP81509AXxx" where computer_id=903; update jamfsoftware.computers_denormalized set computer_name="SN-QP81509AXxx" where computer_id=903;
Remote is back in business. Hope this helps others.
Support just resolved my issue as well. Looks like it was an illegal character in the description of one of our scripts. Luckily it was an old script that was no longer needed, so deleting it was not a problem.
EDIT: I marked Kprice's answer as the correct one due to identifying an illegal character as the cause. The command that was referenced was not applicable to me as I was able to delete the offending script via the JSS web portal. The important part is locating the offending character and dealing with it appropriately.
@bajones That is correct. "The important part is locating the offending character and dealing with it appropriately."
I mostly just ran the commands at Jamfs request. The issue seemed to resolve right after the removal.
@dmw3 I don't think it's out of the norm. I was going so crazy with it that I had removed everything that I could. Pretty much all but the periods for file extensions. Lol
I'm having this same problem in my test environment. I've combed through the inventory and don't see any weird characters in the computer names... is there somewhere else I should be looking?
Sorry for digging up an old thread. Just thought I'd note that I've had this issue again this week on a clean 9.72 JSS install. Very little in it, 1 script, a few packages, 1 printer and 4 clients. Worked ok for the morning, then Casper remote wouldn't connect, followed by Imaging, Recon & Admin.
Deleted the webapp, copied in a new .war file and restarted tomcat and it started working again.
Pretty weird, will pass it on to JAMF support so they are aware.
