Skip to main content
Answer

The server that Casper Remote received data from does not appear to be a valid

  • February 21, 2012
  • 10 replies
  • 46 views
J
Forum|alt.badge.img+7

Getting this error when trying to load Casper Remote

"The server that Casper Remote received data from does not appear to be a valid JSS.

Please verify the address and try again."

All our computers that use casper Remote are getting this error now. Casper Admin and the JSS both are working fine, but nobody can launch Casper Remote.

JSS 8.43 - Has anyone seen this before/can offer any assistance?

Regards
John

Best answer by jszaszvari

In regards to my above issue, Support said that it is a known bug in Casper 8.4

To Resolve the issue i had to run the following :

(I dont take responsibility if this breaks anything, This was a workaround for our specific issue, Ensure that you are having the same issue before you go deleting the reported ip addresses)

UPDATE computers SET last_reported_ip="";

ALTER table computers CHANGE last_reported_ip last_reported_ip varchar(40) NOT NULL DEFAULT '';

ALTER table computers CHANGE last_ip last_ip varchar(40) NOT NULL DEFAULT '';

After running those queries against the jamfsoftware database, Casper remote is now working again.

    10 replies

    J
    Forum|alt.badge.img+7
    • jszaszvari
    • Author
    • Employee
    • February 21, 2012

    If it helps In the JAMFSoftwareServer.log file i see this when we launch casper remote

    "2012-02-21 15:12:34,170 [WARN ] [JSSUtils ] - Encoding exception:java.lang.NullPointerException
    2012-02-21 15:12:34,170 [ERROR] [CasperXML ] - XML exception:java.lang.NullPointerException
    "

    J
    Forum|alt.badge.img+7
    • jszaszvari
    • Author
    • Employee
    • February 21, 2012

    Just looking through the Tomcat logs, I get this every time i try to start Casper Remote

    21/02/2012 4:02:33 PM org.apache.catalina.core.StandardWrapperValve invoke
    SEVERE: Servlet.service() for servlet [remoteController] in context with path [] threw exception
    java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in escape (%) pattern - For input string: " T" at java.net.URLDecoder.decode(URLDecoder.java:192)

    All of a sudden casper remote starts sending illegal hex chars?

    Any help appreciated.

    Regards
    John

    A
    Forum|alt.badge.img+6
    • Apfelpom
    • Contributor
    • February 21, 2012

    Hi John,

    I have the same issue since approx. two hours. Recon is not able to communicate with the JSS. I first thought it's a license issue (I have a couple of clients more than licensed) but even erasing some didn't help.

    On the client side Console.app is displaying:

    21.02.12 14:25:18,701 Recon: [ERROR] -[JAMFAuthenticationWindowController loadFields] (line:179)
 --> Error reading from keychain: The specified item could not be found in the keychain.

    I'm also running 8.43 and since today I had no problems with Recon.

    If I run sudo jamf recon on one client, this error appears:

    ...
Finding Extension Attributes...
Locating Mobile Device records...
Submitting data to https://myjss-replacement-url:8443//...
There was an error submitting the computer to the JSS. Here is what the JSS reported back:



<?xml version="1.0" encoding="UTF-8"?>
<jamfServlet version="8.43" server="Apache Tomcat/7.0.12">
<institution>Arts & Others Communication GmbH</institution>
<epoch>1329833415</epoch>

        <response>Bad username or password</response>

<sessionLastError></sessionLastError>
</jamfServlet>

    BTW: I stopped/started/reboot Tomcat/the JSS several times but it didn't help.

    Thanks for any assistance.

    Yann

    J
    Forum|alt.badge.img+7
    • jszaszvari
    • Author
    • Employee
    • February 21, 2012

    Yann,

    Is that from a 10.7 Client?

    If so, try a "sudo jamf enroll" on the machine you are running recon from.

    The invalid username and password error is usually becasuse the Management account that casper thinks it should be using for the machine is incorrect. Ensure the management account is correct then run a 'sudo jamf enroll'

    John

    J
    Forum|alt.badge.img+7
    • jszaszvari
    • Author
    • Employee
    • Answer
    • February 21, 2012

    In regards to my above issue, Support said that it is a known bug in Casper 8.4

    To Resolve the issue i had to run the following :

    (I dont take responsibility if this breaks anything, This was a workaround for our specific issue, Ensure that you are having the same issue before you go deleting the reported ip addresses)

    UPDATE computers SET last_reported_ip="";

ALTER table computers CHANGE last_reported_ip last_reported_ip varchar(40) NOT NULL DEFAULT '';

ALTER table computers CHANGE last_ip last_ip varchar(40) NOT NULL DEFAULT '';

    After running those queries against the jamfsoftware database, Casper remote is now working again.

    A
    Forum|alt.badge.img+6
    • Apfelpom
    • Contributor
    • February 21, 2012

    John, Thanks.

    The Recon is from a 10.7.3 client. Running sudo jamf enroll will end in the same error when the client wants to write it recon-data in the JSS.

    Because I don't know where to enter the changes you described (I suppose in the database?) I think it's better I'd contact JAMF-support myself.

    Just curious that we both ran in the same "bug"?

    Yann

    J
    Forum|alt.badge.img+7
    • jszaszvari
    • Author
    • Employee
    • February 21, 2012

    I'm not actually sure its the same issue here, Although it could be.

    I suggest giving support a call, because it requires a direct DB modification and support are probably best to walk you through that.

    L
    Forum|alt.badge.img+3
    • Lagogiannis
    • New Contributor
    • February 22, 2012

    I had the same problem today, which started after I tried to use Recon to scan an entire subnet and add workstations to the JSS. About 20 workstations were added but did not report any data to the JSS (only mac addresses were registered ).

    I tried restarting Tomcat, the server, the database fix as well as reenrolling the lion workstation via the terminal with no luck.

    What fixed it in the end was to delete (from the JSS web interface) all the workstations added via the method above and restart all services. Re-adding the workstations by pushing a quickadd package via ARD worked fine.

    Not a high tech solution, I know and I am still not sure why this happened. I'll assume a bug in v8.4 and hope for a fix.

    Yannis

    L
    Forum|alt.badge.img+19
    • lisacherie
    • Valued Contributor
    • March 16, 2012

    John,

    Thanks for sharing!

    I hit this problem today in my new job...

    A
    Forum|alt.badge.img+6
    • Apfelpom
    • Contributor
    • March 21, 2012

    Hi John, hi all,

    after a couple of week of intense email exchange with the JAMF support (thanks!) we solved the bad username password issue which appeared at the end of jamf enroll -prompt or jamf recon.

    I also had the database issue and the SQL-queries solved a problem where the JSS stopped communicate with clients.

    But the error was still there, on single machine. The result of enroll and recon was always the bad username or password error. I cloned the boot OS on an external drive, started from there and was kindly surprised, that enroll and recon worked with this disk.

    So I booted the machine from the internal drive, held the Shift-Key and... the machine enrolled with jamf enroll -prompt... Seems to have been a cache issue.

    Sorry for the weird solution/hint, I would love to be more precise regarding the source of the error. But it would be worse the trick if a client is spinning around that way in the future.

    Thanks,

    Yann

    Terms & ConditionsCookie settingsAccessibility statement