Managed Clients are not auto-updating their binary since 9.81 upgrade

[ryan_s]

We have about 20% of our managed machines in our environment actively checking in with the JSS and seemingly attempting to run policies, but their binary is still a legacy version (9.63). We have had a few tickets raised to our Help Desk because these same users are receiving errors from Self Service when trying to pull policies; with some investigation it seems the computers think they are unmanaged (client-side) but the JSS seems to disagree, so these computers are sort of stuck in limbo. The JSS is working fine, many clients are working fine, but there is a good chunk of clients that are broken for no good reason.

From the client, Self Service reports v9.81, but a "jamf version" in Terminal reports 9.63

I have worked with JAMF support and haven't come up with any good solutions or a root cause, so I am hoping the community can help out. This is the best workaround I could come up with that SEEMS to fix it, but certainly not an easy deployment since we have to completely rip out Casper manually from all affected machines:

1. sudo jamf killall
2. sudo jamf removeframework
3. sudo rm -rf /usr//local/bin/jamf*

So if I just "removeframework" and then re-enroll a Mac, "jamf version" still displays 9.63 ... something in /usr/local/bin/jamf (new location) for whatever-reason is referencing the 9.63 binary?? So, the reason for step 3 is because running "which jamf" points to the old binary location (in sbin) so a "removeframework" only pulls out the legacy-jamf stuff but leaves part of the 9.81 binary/agent behind, assuming because the old binary has no idea that the new-stuff even existed so it leaves it there.

Also, oddly enough, if I run a "jamf policy" on an affected machine and output verbose, according to the output, the binary is successfully updated. However, as soon as the "policy" finishes, "jamf version" still reports 9.63 instead of 9.81... I have no idea why, aside from 9.63 "stuff" not being properly removed/cleaned upon upgrading the binary.

Has anyone else seen anything along these lines? There have been ~50 replies/ideas exchanged back and forth between JAMF support and myself with 2 tech's conclusions being "well just go manually unmanage and remanage all these affected machines I guess" ... my primary goal is to try and figure out a root cause as to why this is happening, and determine why the 9.81 binary upgrade is broken. I'm very happy to hear any other thoughts or ideas from you guys!

Thank you in advance!

[jyergatian]

We used recon to generate a new QuickAdd.pkg. As we come across Macs with issues since the upgrade to 9.81, we re-run the QuickAdd.pkg and that seems to solve it.

[colincorbin]

This may be useful to you:

https://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/

[DBrowning]

i found a similar issue with both 9.8 and 9.81. All we ended up doing was manually running sudo jamf policy and it would update the binary. that has seemed to work well for us.

[johnnasset]

Man, thought I was going crazy. This is happening to us as well. As we can't use a policy-based solution (clients aren't checking in), I'm not sure how to fix it. As stated, manually running jamf policy on the client works but we have a lot of laptops and finding the ones that need it via ARD is a pain.

[DBrowning]

yeah I was finding then in ARD and hoping they were still connecting to a similar IP that was last reported. But then just started emailing people directly asking them to run the command and if they didn't feel comfortable to reach out our helpdesk folks and they would do it.

[m_entholzner]

Have you checked if the "do_not_upgrade_jamf" key is set in /Library/Preferences/com.jamfsoftware.jamf.plist?
I have seen this binary upgrade error in my location too, removing the "do_not_upgrade_jamf" from the plist fixed it for me. I don't know why this key was set...

[AVmcclint]

Can you try making a QuickAdd package and use that to complete the upgrade like I did here?

[ryan_s]

Thank you for all the suggestions guys! I have been hoping to NOT have to leverage the end-users to install an enrollment package, but given the number of them and the lack of other options I may have to visit this possibility (I tried Recon's network scanner v9.81, but it just seems to crash for me...not sure why). Mind you, in most cases so far, simply re-enrolling or running "jamf policy" the machine does not fix the problem... as I mentioned something is holding on to the old 9.63 stuff, so right after re-enrolling/"policy", the binary still reports incorrectly as 9.63 vs 9.81

I like the CasperCheck stuff -- some is over my head (never had to create LaunchDaemons before for instance), but it sounds like a good solution to implement for the future!

[Senthil_kumar]

We used recon to generate a new QuickAdd.pkg. As we come across Macs with issues since the upgrade to 9.81, we re-run the QuickAdd.pkg and that seems to solve it. Now working AD username & password.