Recon - There was an Error. Message Has No Content.

mjames
Contributor

Hi All,

We are having problems with reconning systems with casper at the moment. When we attempt to recon from a system using the "sudo jamf recon" command in terminal we get a result saying "There was an error. Message has no content"

Casper shows that the system checked in, but did not update inventory.

When we use the Recon App we are also seeing an error - I have attached a screen shot of the message.a4888430969e4df4836d269a79f2d183

We are using Casper 9.61 and our system displaying the fault are a split between Mac OS X 10.9.5 and Mac OS X 10.10.0

Any help would be greatly appreciated.

1 ACCEPTED SOLUTION

mjames
Contributor

We have solved the issue.

It was an Extension Attribute that was not feeding back a result, and it seems Recon did not like the no result showing up. It was a similar error to the no IP described in the thread @dmw3 linked us to.

We have fixed the attribute and everything is working fine now.

View solution in original post

16 REPLIES 16

chriscollins
Valued Contributor

What do you see when you run a:

sudo jamf recon

?

ItsMe_Sean
Contributor

Hi @chriscollins

The following is what we see when a recon is attempted via terminal;

Retrieving inventory preferences from https://casper.myserver.com:8443/... Finding extension attributes... Locating accounts... Locating applications... Locating package receipts... Searching path: /Applications Locating hard drive information... Locating printers... Locating hardware information (Mac OS X 10.10.3)... Gathering application usage information... Submitting data to https://casper.myserver.com:8443/... There was an error. Message has no content

dmw3
Contributor III

@mjames We are having the same issue but for only one computer. See this thread https://jamfnation.jamfsoftware.com/discussion.html?id=13582

rbeaton
New Contributor

@dmw3 thanks for that thread. We'll look into the IP info suggestion of @chriscollins in the morning.

mjames
Contributor

@dmw3 Thanks for the thread.. but no luck.

I have tried the following this morning.

  • networksetup -getinfo Wi-Fi - it displayed the correct information, and when I check ns2:reportedIP in the XML dump from recon, it reads with the correct IP.
  • ioreg -l | grep IOPlatformSerialNumber displayed the correct serial number
  • Deleting the /Library/Preferences/SystemConfiguration/preferences.plist made no difference

So I guess I need to keep looking.

mjames
Contributor

We have solved the issue.

It was an Extension Attribute that was not feeding back a result, and it seems Recon did not like the no result showing up. It was a similar error to the no IP described in the thread @dmw3 linked us to.

We have fixed the attribute and everything is working fine now.

rbeaton
New Contributor

Some detail incase someone else experiences the same issue...

The JAMFSoftwareServer.log was checked and the error noted was :

2015-05-20 15:08:36,706 [ERROR] [Tomcat-5020] [JAMFHttpServlet ] - The JSS received an error (javax.xml.bind.UnmarshalException - with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 33659; cvc-complex-type.2.4.b: The content of element 'ns2:osx' is not complete. One of '{"http://www.jamfsoftware.com/JAMFMessage":value, "http://www.jamfsoftware.com/JAMFMessage":script}' is expected.]) for a request made by device: null

Looking into the output of a "sudo jamf recon -saveFormTo ." file (formatted nicely) we see:

<ns2:osx xsi:type="ns2:ExtensionAttributeOsx"><ns2:id>15</ns2:id><ns2:name>AStatus</ns2:name></ns2:osx>

noticing this is different from all others which have a format of:

<ns2:osx xsi:type="ns2:ExtensionAttributeOsx"><ns2:id>10</ns2:id><ns2:name>BStatus</ns2:name><ns2:value>Disabled</ns2:value></ns2:osx>

Extension attribute 15 (the bad one) is populated from a database query on the client. It turns out under certain circumstances that one of the database fields gets populated with binary data and that cannot be written to the JSS. That is why the ns2:value key disappears and recon borks.

Thanks to the community for helping point us towards the answer :)

bentoms
Release Candidate Programs Tester

@rbeaton thanks for the detailed response.

dmw3
Contributor III

@mjames @rbeaton Thanks for the info. So how did you resolve this issue, working by myself down south.

mjames are coming to X-World in Sydney? If so maybe we can catch up.

Macintosh_HD
New Contributor

@mjames I had the same issue with a Mac Book Pro which had a logic board replacement. The Apple tech forgot to serialize the logic board. 8)

mjames
Contributor

@JavierArzaga We have seen that too - this was a different problem though. It was because of bad data being read by an extension attribute, and upsetting the whole apple cart.

Macintosh_HD
New Contributor

@mjames I had to fix an extended attributed as well and it's good to know how this issue occurs. In short, anything that jamf recon binary collects can potentially create this issue.

Thanks!

johncasper
New Contributor

Hi @rbeaton ,

"...Looking into the output of a "sudo jamf recon -saveFormTo ." file (formatted nicely) ..."... When I opened the file , it's all conjoin together. Would like to find out how do you see it formatted nicely?

pcrandom
Contributor

Sorry to bump an old thread. We're running into a similar issue with just one managed Mac (that we known of). The error is "The message could not be parsed." like in the thread linked to by @dmw3 above, though since that thread is already marked as solved and is longer to wade through, I thought I'd comment here instead. (Edit: I didn't realize this thread was also marked as solved.)

I believe I'm running into the same issue as @chriscollins was back then, where networksetup -getinfo Wi-Fi gives an error "There is no ip info to display for Wi-Fi". I noticed in JSS that the Reported IP field is blank for the system in question, and outputting the recon form I noticed that the inventory is missing the <ns2:reportedIP></ns2:reportedIP> information (the entire key, not just the value) that's present in other inventories on systems that don't have the error. (Incidentally, we have another Mac in the environment with a blank "Reported IP Address" but it's not currently online for me to run a "sudo jamf recon -saveFormTo" on.)

I think the solution is to delete the /Library/Preferences/SystemConfiguration/preferences.plist file, but this is for a VIP who travels a lot and has a lot of network devices. I deleted the .plist on my own system to see what would happen, and while my wireless networks remained intact (the .plist didn't list that info, so I was pretty sure it would be fine in that regard), I did notice it reset my service order, which is also no big deal. Just curious if there's anything else I should be aware of before deleting the .plist. I'll make a backup and can also revert to the .old version too.

chriscollins
Valued Contributor

@pcrandom If you use any built in VPN connection it will delete those, and it will reset your computer names to blank. So you'll need to reset the computer name and hostnames for the machine.

pcrandom
Contributor

Thanks for coming back and commenting @chriscollins. That explains why my hostname changed this week. I couldn't figure it out. Though it didn't blank it, it changed it to "iMac". We don't use built-in VPN, and I'll assume (but will test to verify) that it won't affect Cisco VPN profiles, but it's good to know!