Casper Suite not talking to JSS

bajones
Contributor II

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.

1 ACCEPTED SOLUTION

Kprice
New Contributor III

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.

View solution in original post

27 REPLIES 27

vadanx
Contributor

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.

Andrew

Chris_Hafner
Valued Contributor II

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)

bajones
Contributor II
  1. Issue persists after re-entering address, as well as opening the applications after clearing their plists and keychain entry for the stored username.
  2. Same issue on another mac
  3. Web portal works fine
  4. Connection to JSS via binary works fine, too
  5. 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
  6. 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.

vadanx
Contributor

Just to clarify, when you sign in to the JSS you can view Inventory and see Policies? (so no issue with the SQL or Tomcats comms with it?)

Have you tried reinstalling the JSS?

Andrew

bajones
Contributor II

Yes, policies and inventory are working, so no Tomcat or MySQL issues are apparent. I have run the 9.1 installer again to troubleshoot.

jmercier
Contributor II

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...

Kprice
New Contributor III

@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.

bajones
Contributor II

No updates yet. I will post when I find anything out.

irod87
New Contributor

I'm currently experiencing this with Casper Remote after the upgrade to version 9.

bajones
Contributor II

Still no resolution from support. Is it only affecting Remote for you? Admin and Imaging work fine?

Kprice
New Contributor III

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.

Bendelaat
New Contributor II

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?

Executing Policy Update Inventory...
Running Recon...
Retrieving inventory preferences from https://imperio.ice.local:8443/...
Locating accounts...
Searching path: /Applications
Locating package receipts...
Gathering application usage information...
Locating printers...
Locating software updates...
Locating plugins...
Error running recon: Connection failure: "The host imperio.ice.local is not accessible."

Chris_Hafner
Valued Contributor II

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.

Bendelaat
New Contributor II

i had the problem with Remote as well. yesterday i upgraded the Casper admin in preparation for JDS deployment. now remote works fine.

hope this helps for you guys as well.

jmercier
Contributor II

for myself... its admin and remote... but mainly admin i can't open

nessts
Valued Contributor II

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

Kprice
New Contributor III

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.

bajones
Contributor II

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.

irod87
New Contributor

"Wingding Like" question mark before one of the machine names in Inventory."

I found this in my inventory. Corrected it and now Casper Remote will load. Thanks for the tip.

dmw3
Contributor III

Is there a list of illegal characters for Casper?

I know that sometimes what is an illegal character for one app maybe ok with another.

Kprice
New Contributor III

@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

stevehahn
Contributor

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?

bajones
Contributor II

@stevehahn Check package/script names and descriptions. My issue was caused by a bad character in the info section of a script.

stevehahn
Contributor

Success--I found a "bad" character in one of our package descriptions; removed it and I'm in. Thanks everyone!

davidacland
Honored Contributor II

Hi,

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.

dmw3
Contributor III

@davidacland I had the same thing happen yesterday building a new server for the master JDS, a reinstall of the JDS app actually resolved the issue.

It may not be the same but worth trying.

sumit_batra
New Contributor

Hi All,

I am getting similar error in my environment. When ever try to connect to Casper Admin or Imaging it says :"The server did not responded with any information. Please check the server information."

Any clues how to proceed further.

Thanks
Sumit