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

What do you see when you run a:

sudo jamf recon

?

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

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

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

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

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 :)

@rbeaton thanks for the detailed response.

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

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

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

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

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?

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.

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

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!