10.10 reporting back as 10.9.5? | JSS 9.6

[bvandepol]

My 10.10 clients aren't reporting back the correct version to the JSS. The version displayed is (still) 10.9.5

Both my JSS as jamf framework version are 9.6

[emily]

How often do your machines check in for inventory?

[bvandepol]

All machines have reported back several times since the upgrade (or fresh install). Manually initiating a recon and a/or policy update doesn't change anything either.

[bvandepol]

But @emilykausalik to answer your question, it's every 15 minutes.

[znilsson]

I'm also using JSS 9.6, and my clients are reporting 10.10 correctly.

Operating System:Mac OS X
Operating System Version:10.10.0
Operating System Build:14A389

I also have a smart group that is detecting them correctly, my criteria is just Operating System is like 10.10

I have Casper set to have the agents check in every 15 mins, but they only update inventory once per day, maybe inventory just hasn't been updated on those clients yet (as opposed to just checking in)?

[scottb]

FYI, we're still on 9.32 and Yosemite Macs show as 10.10.0.

Scott

[alexjdale]

We were seeing correct reporting back when we were on 9.23, and 9.52 is also working correctly.

[jgwatson]

I'm seeing this also. Running 9.6

[Johnny_Kim]

What machines are the 10.10 running?

If you have access to the machine, try running sudo jamf recon -verbose and look for the line "Locating hardware info..(Mac OS X ......)" and see what its reporting there.

I'm running JSS 9.52 and users who upgrade to 10.10 on early 2014 Macbook Air are showing correctly.

[jgwatson]

I can't test your suggestion just yet, but as a side note ARD is reporting correctly where the JSS isn't.

[kyle_jackson]

I'm also seeing this. even after doing a 'update inventory' with casper remote.

[bvandepol]

@kyle.jackson Have you looked at a verbose recon already? I see it just stops in the middle of the inventory collection process. No data is submitted to the JSS.

I've removed the framework and tried to re-enroll using a QuickAdd package. This fails as also.

10.9.5 clients do not show this behavior.

[#13]

What if you jamf removeFramework and then re-recon or re-enroll?

[bvandepol]

Same result @pete_c

Bs-MacBook-Pro:~ bvandepol$ sudo jamf enroll -prompt
JSS Username:******
JSS Password:
SSH Username:******
SSH Password:
Downloading required CA Certificate(s)...
This computer was successfully enrolled to the JSS with the following device certificate: "483410EC-DEFF-5A0C-87DC-4205D0796402"
Retrieving inventory preferences from https://jss.******.com:8443/...
Finding extension attributes...
Locating package receipts...
Locating applications...
Locating accounts...
Locating software updates...
Locating plugins...
Searching path: /Library/Internet Plug-Ins
Locating printers...
Locating hard drive information...
Searching path: /var/root
Searching path: /var/networkd
Searching path: /var/spool/cups
Searching path: /var/db/locationd
Searching path: /Library/WebServer
Searching path: /Users/Guest
Searching path: /Users/bvandepol
Locating hardware information (Mac OS X 10.10.0)...
Gathering application usage information...
Bs-MacBook-Pro:~ bvandepol$

It just 'ends'. In JSS the computer shows as "No Name" without any information.

[k3nz00]

Experiencing the same issue to, I've contacted JAMF regarding this, sounds like a bug in 9.6, I'm also noticing that I can't push configuration profiles.

[bvandepol]

Hi @k3nz00, i'm seeing the same here. I have to test if this also happens with upgraded systems. So far i've only seen it with clean installs of 10.10.
My 10.9.5 clients are behaving just normal.

[adhuston]

I to am seeing this behavior. We're currently on 9.52. What's interesting is that it seems to only be happening on computers that are upgraded from 10.9 to 10.10. We've got several freshly installed 10.10 machines that were not upgrades that are reporting back fine. They checkin and report inventory like normal. But that machines that are upgraded seem to be the problem. Removing the jamf framework and reenrolling doesn't seem to help. The jamf agent appears to be crashing when it's trying to collect inventory. Re-running the quick add package seems to fail at the point of recon as well. I've got an open case on the issue as well. Hope this gets fixed soon.

[elsmith]

So we were having this problem on 9.52, but decided to see if upgrading to 9.6 fixed it for us. It did not.

My machine was running 10.9.5 and was upgraded to 10.10 via the AppStore. After that, it would not update the inventory in Casper and I kept getting "Segmentation fault: 11" when it quit recon right in the middle. So I figured it might have something to do with the upgrade - I wiped and rebuilt the machine. It worked fine for a day, then started doing this again.

Here's a copy of what I see in terminal:

bash-3.2# jamf recon
Retrieving inventory preferences from https://casper..*:8443/...
Finding extension attributes...
Locating hard drive information...
Locating applications...
Locating package receipts...
Locating software updates...
Locating accounts...
Searching path: /Users
Locating hardware information (Mac OS X 10.10.0)...
Gathering application usage information...
Segmentation fault: 11
bash-3.2#

This is still happening with Casper 9.6.

[bvandepol · Accepted solution]

I have a workaround thanks to jamf support.

In my inventory collection, i have the path ~/ included. Apparently inventory collection in /private/ fails (known issue according to jamf)

I've deleted ~/ and ran recon, policy -> Success
Added /private/ and ran recon, policy -> Fail
Added ~/ and ran recon, policy -> Fail

I'm keeping this in place until there's a permanent fix.

[elsmith]

So I read your fix @bvandepol - we had it searching "/Users/" which I turned off. . . that fixed it. I want to hug you! :)

[bvandepol]

Response from JAMF support

Hi, Awesome, that output looks normal now! For reference, the Defect ID number is D-007915, and we only discovered and filed it yesterday. Our QA team will be reviewing it and working with Dev to get a fix in place. Until they do that, we will not have a possible timeline on the release that will fix it. We are sorry for the inconvenience, but glad that a work around was possible for you.

[adhuston]

Fixed it for me as well. I was searching /Users/ for WebEx productivity tools. Removed that and 8 more 10.10 machines submitted inventory.

[jgwatson]

Are you changing this setting under Computer Management > Computer Inventory Collection > Path?

New to this part of the JSS.

Thanks

[elsmith]

@jgwatson - Yes it would be under Computer Management > Computer Inventory Collection > Software > Applications and there should be a "delete" button next to any custom entries. There are two "built-in" as well. I deleted our custom ones and that fixed the issue for us.

Hope this helps!!

[were_wulff]

Hey all,

If you take a look through the system.log of an affected client, do you see any .crash files for the jamf binary being generated?

If you do, please don't post them here, as they can contain identifying information; instead, if you haven't already got a case open with your Technical Account Manager, please get one going and send that .crash file as part of it.
You can get a case started by either giving Support a call, by e-mailing support@jamfsoftware.com (it will go to your TAM's case queue), or by using the My Support section of JAMF Nation.

The more info we can get to look into D-007915, the better, after all! :)

Thanks!
Amanda Wulff
JAMF Software Support

[emily]

I had a machine that I imaged with 10.10.0, so it was a fresh inventory record, that reported from enrollment on that it was 10.9.5. Weird. I do have my inventory collection looking for something in /Library/Application Support/ so I'm going to remove that inventory collection and see if it reports correctly. (I just built myself an EA for what I'm looking for to get around needing the inventory collection to dig for it).

[asims9]

Deleting the custom entires fixed it here as well! Thank you.

[emily]

I can confirm that my machine that was reporting incorrectly is now reporting the correct OS after removing the custom entry in the inventory collection.

[iJake]

I just had to do this on our system as well.

[aurica]

Same issue with 10.10 and 9.25, except I had to remove a custom path from the Plug-Ins collection.

[jaziz]

This issue still exists in 9.61. Removing /Users/ from the Application inventory scan solved it for us.

[aamjohns]

@bvandepol,
Wow. This has been a problem for me for a long time. Thank you for posting this information.

[sacomsto]

After reading this thread and removing all custom paths, the problem still existed (9.61 JSS). I grabbed a screen shot of the various inventory items we were collecting and then disabled (unchecked) all of them. BOOM. The recon finished perfectly. I then started rechecking the settings one by one and re-running a recon. The following option caused inventory collection to fail on my 10.10.1 machine.

Collect last backup date/time for managed mobile devices that are synced to computers

I was also able to add back our custom /Users/ path on the Application inventory scan as well.

[emily]

I'm seeing that, in relation to this issue, I have machines that are checking in to the JSS but not sending inventory updates. I've tried re-enrolling and that doesn't help either. We don't have that "Collect last backup date/time" thing enabled, but I'll try disabling and re-enabling the other inventory collection options and see if it's hanging somewhere (good catch, @sacomsto).

[adhuston]

Appears to have been addressed by the latest update to the JSS, version 9.62, according to the release notes. Anyone gotten a chance to check it out and see if this helped?

[spotter]

I just updated my JSS to version 9.62 and can confirm the issue I was seeing with Inventory Policy not being able to search /Users/ is now fixed...

[dvasquez]

I can also say that scoping of departments and has been fixed with the 9.62 update. I was unable to add them to scope in policy. For some reason in 9.61 they disappeared. Same with Departments. (Ops sorry if this was unrelated).

[bvandepol]

I can confirm here that updating to 9.62 solved this issue.