Looking for guidance

[mconners]

Hello Everyone,

I have been searching here and the web for some answers to a puzzling problem.

Our JSS is on version 9.98. Most if not all of our student Macs have been re-imaged using macOS 10.12.5 or 10.12.6, depending on when we imaged. The binary that would have been installed is 9.98.

We have been seeing randomly, Macs that ARE checking in but NOT updating their inventory even though they are set to update daily.

When we open terminal and run recon, terminal freezes. If we open self service, self service freezes to run. Even when we restart the computer, the binary freezes after a period of time. In most cases, our student Macs can be imaged over and the communication will work afterwards. This is more difficult for employee computers.

We can run sudo killall jamf and this will "unfreeze" in some cases.

I have installed a quick add package on some to various degrees of success.

At this point, I am looking for guidance on what to try next. I have a case open with jamf support.

If anyone has thoughts or a possible work around, I am all ears and eyes on this. I am trying to prevent a melt down the first day of school when things aren't communicating as they should.

Thank you in advance...

[ftiff]

Hi,

I would look at the Extension Attributes that you configured. If one of them freezes, the recon will freeze. Try to execute them on an affected computer.

Let us know how it goes

[mconners]

Thank you @ftiff I appreciate the response. I have to ask, I have borrowed from JAMF Nation various extension attributes. I was under the understanding that the extension attributes are on the JSS side for pulling in additional information such as JAVA version and so forth. Are you saying one of these attributes in the JSS could cause the communication to fail on the client side?

[mm2270]

Well, all Extension Attributes (script ones anyway) get pulled down to the Mac and run locally to gather the relevant information, and then the results are uploaded back up to the computer record in the JSS. So while the EAs themselves live in the JSS, each Mac must run them all locally against itself to get the info each EA is gathering. Sometimes those EAs can be slow or cause delays if they are malformed in some way.

Also, are you capturing things like Application Usage data and/or calculating home folder sizes? Those can also be slow and cause problems with recons. What I'd do is systematically turn off some of the inventory collection items. Another one to look at it is if you are grabbing Apple Software Updates. Turn off items one at a time and see if those Macs can start submitting inventory again. There may be one item in the collection that is causing this to happen.

[mconners]

Thank you @mm2270 this is very helpful. I can certainly check into this. Crazy thing though, if one Mac is behaving this way, wouldn't we anticipate that other computers of the same model and hardware act the same way?

My JAMF support call did find an error in our JSS server log and she is thinking there might be a problem with this that must get resolved first. There could be a correlation between the error and the Macs not updating inventory.

Thanks for the insights though, this is very helpful. I will narrow down the list of EAs and see if this helps us out.

[mm2270]

@mconners I forgot to mention in my post above, but something else to try is running recon in verbose mode on machines that are getting stuck. It may reveal what point in the inventory collection they are getting hung on.

sudo jamf recon -verbose

[tlarkin]

I'd also recommend just running a sudo jamf policy from the Terminal as it will test certificate based authentication to your JSS web apps. I have seen issues where devices will check in but not run or submit anything because of the do_not_upgrade key being flagged in a jamf plist file. No idea if this is your issue or not, but it is something I would try.

I would imagine if your extension attributes where the issue it would be more of a constant issue versus intermittent since those run on every single Mac regardless at reocn. However, I have seen stranger things then that so it could be possible.

[mconners]

Thank you @tlarkin you information was good to have, unfortunately when I ran the sudo jamf policy, I get the response, This policy trigger is already being run as root with some numbers after it. I am guess, this number is the policy ID.

After this didn't run, I tried again, the sudo jamf recon -verbose and it hangs right after the message, The JSS is available. It's great it finds the JSS, but nothing else happens.

I agree with your assessment the the EA piece would be more wide spread.

[rhyde]

@mconners Did you ever get this resolved? Running into the exact same thing on Jamf 10.10.1.

[mconners]

Hello @rhyde I don't recall the specifics on what we found to be honest. I would check to verify the MDM capability is set to Yes and not No. In one of our situations late in 2018, we had a number of Macs where for some reason, they switched over to No. There wasn't a thing we could do about that but to wipe and re-image these that showed up this way. If this doesn't help, I would check in with Jamf support.

You could also try to reinstall the quick add package to see if this repairs the binary.