Inventory update error

what if you do

sudo jamf recon -verbose

from Terminal on the client machine itself?

@RobertHammen Just ran the command, output below:

Submitting data to https://<server>:8443/...

There was an error.

Invalid Message - The message could not be parsed.

I might suggest deleting the client from the JSS, and then re-enrolling (via Recon, QuickAdd, Enrollment URL, whatever works). Sounds like there may be something with the computer record in the JSS that is causing it to apparently reject the inventory update.

@RobertHammen tried removing the client computer from the JSS. Waited 30 mins so any cacheing clears, then re-enrolled with Casper Recon.

All looked fine until it tried to send the inventory to the JSS, then came back with this:

"Submitting data to https://<server>:8443/...

There was an error.

Invalid Message - The message could not be parsed."

The client got added to the JSS anyway but with a blank "" computer name. Manually added the name but still getting the same error when inventory checkin occurs.

Any ideas as this is the only computer with this issue?

Does the machine have a hardware serial number (System Information or Apple menu->About This Mac and click the OS version twice)?

Time zone/clock correct?

Are your devices MDM-enabled? Does this machine have an MDM profile?

sudo jamf manage
sudo jamf mdm

If not, or the above command fails:

sudo jamf removeFramework
sudo jamf enroll -prompt

If it still acts crazy, could try

sudo jamf removeFramework

And then re-enroll. Still issues, may want to try another OS (either boot from an external and enroll that OS, or wipe and reimage the computer).

@RobertHammen As it is only one computer with this issue, I might save time and simply re-image it.

Thanks for you suggestions, just don't have time to go through everything on one computer, too many other things going on.

Were you able to resolve this issue? I am having the same issue and this is the only machine doing it so far. I remimaged and that did not work for me.

Thanks!

@Slade037 No this has not been fixed. Like you have done, re-imaged the computer no change, removed from JSS then readded no change, tried to force inventory update and get the same error as above.

Even though it doesn't update the inventory everything else works via JSS for this computer.

Have manually added serial number and other info for this computer in JSS thinking that it might solve the issue but no change.

In inventory - > General tab, does "JSScomputer ID" show a device ID filled for the device in question?

Seeing this same error on one system running 10.10.1.

First I tried reinstalling the Quickadd package, no change. Then I ran a removeFramework on the client, deleted the entry from the JSS and then reinstalled the Quickadd. Still getting the same error upon Recon.

I have a machine with the exact same problem. It turns out that the computer's serial number is missing from the "About this Mac" panel. We need to get it re-serialized, but I'm hopeful that will fix the issue.

@dmw3 did you check the serial on the machine itself like @RobertHammen mentioned?

@dmw3 Do you have any custom items from the "Computer Inventory Collection" -> Software -> Applications section of the JSS?

We had issues with Yosemite machines collecting Inventory until we cleaned up the list of custom search paths.

Was working with JAMF support on this today. In our environment it is 10.9.5 machines and it started with 9.7. When I upgrade them to 10.10.3, problem goes away immediately.

I have one of my dev server that is completely clean. Literally only has the default daily inventory update policy.

When I unenroll the machine from the production JSS and to this dev JSS, problem still persists. When I revert that dev JSS to a VM snapshot when it was still completely clean but running 9.32 (I could literally go back to any specific version if I want before 9.7), and it recons fine. Go back to snapshot where the only thing that has changed is itw as upgraded to 9.7/9.72, it enrolls fine and does the first recon because the binary is still at 9.32 while its running. The moment the binary updates to 9.72 and you try to do a recon, it gets the parse error.

Upgrade the machine to 10.10.3? Goes away.

I was having this problem and found out that when we had hardware repairs, I believe it was a broken screen that was replaced by a non-Apple provider, the computer lost its serial number. I sent the computer in and had it re-serialized, it is working correctly. You might check your system profiler to see if it has a serial number there.

Yeah on ours they all have serial numbers. And its happened on a couple hundred machines.

I was receiving the Error "running recon: Invalid Message - The message could not be parsed."

I had tried re-enrolling and deleting the machine from the JSS without success.
This was on the only 10.10 machine we currently have in the JSS. It was running 10.10.3.

I resolved the issue by unchecking the "Collect last backup date/time for managed mobile devices that are synced to computers" from Computer Inventory Collection. jamf recon now submits data to the JSS without error.

So here is what I came up with. When looking through the logs Tomcat keeps complaining it can't parse the inventory submission from the client because of missing content in regards to ns2:reportedIP element in the XML being uploaded from the client.

When I look at all my problematic machines they all are missing the "Reported IP" address in inventory (they are blank).

When I downgrade the binary on the machine to an earlier version like 9.32, it submits inventory fine on that particular problematic machine and shows the reported IP address properly.

When I do a jamf recon -saveToForm to dump the recon xml into a file with both 9.32 where it works and 9.72 where it doesn't, the 9.32 xml file shows that it did create the ns2:reportedIP element, but the 9.72 one doesn't generate the reportedIP entry in the XML and the JSS log says that Tomcat failed to parse the message from the client because of that missing data.

if you upgrade that machine to 10.10.3 in my environment, it starts generating the right xml without the missing reportedIP addresses and can inventory normally as well. So definitely some wonkiness with the binary with one of its upgrades (IN MY ENVIRONMENT AT LEAST)

I would check your machines to see if they are missing a reported IP address. Might be worth exploring.

@chriscollins , I'm seeing the same thing you are, Reported IP Address is blank. I downgraded my problem machines to the 9.65 binary to see if I could get them to recon, and it did work. I tested some of these machines in my dev and prod environment and they both see the same behavior.

I am seeing this on one machine which is on 10.10.3 but is reporting 10.10. When I ssh into the machine the command "ioreg -l | grep IOPlatformSerialNumber" does not return a serial. No other commands to pull the serial return a serial, so I think we probably have the culprit here, at least in my case.

We got to the bottom of it in my environment.

The /Library/Preferences/SystemConfiguration/preferences.plist which contains networking information for the various interfaces has some kind of issue. If you would attempt to use networksetup -getinfo on a particular network interface/service, you should get the IP address, etc. But what we were getting was the below:

$ networksetup -getinfo Ethernet
There is no ip info to display for Ethernet.

Doesn't matter if its a Thunderbolt Ethernet interface, Wi-fi, etc, it would just keep returning "There is no ip info to display for Ethernet."

So here is where it gets interesting: According to support, in one of the recent jamf binary updates, they changed the method for collecting the reported IP address from the client from using ifconfig, to using networksetup -getinfo, so if there is something wrong with that .plist file, it returns that "no ip info to display" string of text that the jamf binary doesn't understand, it chokes on trying to write it to the XML it is going to submit to the JSS for inventory and so it decides not to include that XML element in the data being submitted, but the JSS expects it, chokes on parsing the submitted data because that reportedIP element is missing, and then throws the parsing error, and makes everybody sad.

Renaming or deleting the /Library/Preferences/SystemConfiguration/preferences.plist file forces the machine to rebuild it on restart, and after that, when you run the command you get:

$ networksetup -getinfo "Ethernet"
DHCP Configuration
IP address: 10.56.4.93
Subnet mask: 255.255.252.0
Router: 10.56.4.1
Client ID:
IPv6: Automatic
IPv6 IP address: none
IPv6 Router: none
Ethernet Address: 00:3e:e1:c2:32:d1

And then doing a jamf recon magically works again and everybody is happy.

The reason why upgrading to 10.10.3 was "fixing" this issue for me is the Yosemite upgrade process automatically recreates this file (which also explains why users lose their built in Cisco VPN settings when they upgrade if they aren't deployed via a config profile and were manually set up, since that data is also in /Library/Preferences/SystemConfiguration/preferences.plist"

So I am going to write up a feature request in a bit that asks that when jamf makes major procedural changes in how the jamf binary collects data, it would be useful for them to document that, so like in this case, if they switch to using networksetup -getinfo, we know that that command uses the /Library/Preferences/SystemConfiguration/preferences.plist file and then it gives support and customers a place to look to solve that problem much quicker when they see that running the same command the jamf binary is running gives unexpected results, and you can quickly go from there and trace it down.

I'll add a link to that in a bit and hopefully it will get some support.

I'm also seeing this issue with Casper 9.65 on a specific OS X 10.10.3 client, which happens to have serial number missing. One of our desktop techs forgot to re-serialize MBAir logic board replacement via AST.

AST is the current tool for re-serializing CPU/MLB repairs. Eventually the BlankBoard Serializer tool, which @dmw3 links to, will no longer work for newer Mac models ( > mid/late 2013 Mac models?).

Thank you very much @chriscollins for posting this information. I was at least able to get my problematic Mac's to work once the preferences.plist file was removed and recreated via reboot. This is definitely a pain to do to about 100 computers, but it has to be done.

I know this is a long shot, but maybe somebody will be helped by it. I've had this exact error for over 2 years with one computer in my environment. The computer would enroll properly and communicate with the JSS until the user would migrate all of his data to it. I went through support, tried everything in this thread (and others), and could never figure this computer out, so it was the black sheep of my JSS. Today I came across something when doing some SIP research for something else and decided to look into /usr/local. The computer had an old MySQL database installed on it from a previous migration going back to 10.6 that was causing the error message. As soon as I removed all the "remnants" of that MySQL installation the computer enrolled properly and is now checking in and updating like the other 2500 machines in the JSS. Not saying that this was THE fix of all fixes, but it's something to check out if you're getting this error on a machine with migrated data.

Hi Everyone,

I wanted to let people know what worked for me on this. I attempted essentially the same steps. Unenrolled and re-enrolled the device in questions with the same results. I checked serial numbers and id's to ensure all information was there and propagating to JSS.

@mrowell Pointed out a step to remove to collect data on last backups. This seemed to stop the message for my machines in question. As for the cause, is still unknown on my end.