Machines Checking in but not getting 9.11 binary

I'm seeing a similar issue with 9.2

Yes I have seen this as well my machine checks in Casper frequently but does not update from 8.72 to 9.2 I have to re-run quick add

Yes I have seen this as well my machine checks in Casper frequently but does not update from 8.72 to 9.2 I have to re-run quick add

When I find these hangers on I usually discover that they've somehow gotten the impression that they are no longer allowed to update the jamf binary. You can discover this by running the following command.

jamf policy --verbose

If that's the case, try this:

/usr/bin/defaults write /Library/Preferences/com.jamfsoftware.jamf do_not_upgrade_jamf -bool false

Then you should be able to manage them AND get the latest binary on there. This was you don't have to lose all the data you have on the unit by running recon again.

Yeah I had this happen to me during 9.64 where a chunk of machines changed that file so when 9.65 came out, even when using recon or a user being logged in as jamf suggested for the other bug, it still wouldn't upgrade to 9.65 because of my machines having this preference file set.

I ended up just doing an extension attribute that reports if that key is in the preference file, which dumps it into a smart group which has a policy scoped to it to set the key to false, and then basically within 30 minutes it rights itself.

Hmm, was that a different issue than the major defect with 9.64 that caused it to be pulled and replaced with 9.65?

https://jamfnation.jamfsoftware.com/article.html?id=391

@RobbertHammen Yep. The bug about not running policies, upgrading the binary, etc when a user wasn't logged in when I followed JAMFs recommendation using recon.app with it set to copy the binary via scp, or just waiting till a user was logged in WOULD work but when doing the recon way on some clients that were at 9.64, it wouldn't do the binary update and I would see in the log that it didn't donit because the main JAMF plist on the machine had the do_not_upgrade_jamf key was set to true. Since the machines were all at 9.64 it had to have happened after 9.64 was deployed and there's no way I would have set that key (by default that key doesn't even exist in that plist) and I didn't even know it exists before. So to automate a fix I did it the way above. I contacted my TAM But they didn't have much of an idea of why it happened but since I fixed it myself they closed it out. I did have a couple older machines that had like 9.3 that was the same thing but this was a sudden change of a lot of machines with 9.64.

I had something similar happen once back in the v7 or early v8 days, where I didn't have a valid SSL cert but the flag got set to require one (meaning all clients became unreachable until I fixed the pref). You aren't doing anything with jamf -createConf? I think my problem was not explicitly declaring not the require SSL, which seemed like a poor choice for a default behavior...