Binary not upgrading

[jack_bishop]

On several machines, I've gotten this message when doing a policy run:

Not upgrading jamf binary. do_not_upgrade_jamf is set to true in /Library/Preferences/com.jamfsoftware.jamf.plist

This particular OS is 10.10.5 and the JSS is version 9.92. Deleting the key/value pair fixes it. Am I the only one seeing this?

Also, what is the best way to sniff out these machines? Thanks in advance.

Jack

[mm2270]

I forgot what ends up setting that value in the plist, but it shouldn't be getting in there on its own I don't think. Somehow that value is being applied to the plist, so you may need to do some digging to see if it was previously set on those machines from a past admin (if it wasn't you) or maybe they were once on an older revision?

As for detecting it, you could build an EA, assuming the older binary on the Macs isn't also preventing them from submitting inventory of course.

#!/bin/bash

do_not_upgrade_val=$(defaults read /Library/Preferences/com.jamfsoftware.jamf.plist do_not_upgrade_jamf 2>/dev/null)

if [ "$do_not_upgrade_val" ]; then
      echo "<result>Do Not Upgrade Set</result>"
else
      echo "<result>Not Set</result>"
fi

[jack_bishop]

I was avoiding the EA route, but I think I found something. I found a new (to me) smart group criteria called 'jamf binary version'. I set it to not current and found way more machines than I should have. I'm off to see how that gets set. I certainly didn't do it and I'm the only one the would.

Anyone know how do_not_upgrade_jamf gets set?

[mm2270 · Accepted solution]

I did a search here using the term "do_not_upgrade_jamf" and it came back with a number of hits, mostly other threads and posts of people having a similar issue. See the results here: https://jamfnation.jamfsoftware.com/search.html?q=do_not_upgrade_jamf

Included in the results is one of the JAMF KB articles: Preventing the jamf binary from Updating, but it only discusses how to set that using defaults, which it doesn't sound like you did. Hmm. Mystery.

[jack_bishop]

Yeah, it's weird. Sound like it's time for a support chat. Thanks.

[bentoms]

@jack_bishop IIRC, this might have been set with a JSS update.. Maybe 9.8?

The EA posted by @mm2270 should correct.

[were_wulff]

Hey all,

We are aware of this issue, and have it filed under PI-000365. It’s listed as fixed, so it should not be an issue going forward.

With PI-000365 we were seeing that the do_not_upgrade_jamf flag was unexpectedly being set to true on some machines and, as of 9.8, if the binary doesn’t match the JSS version policies won’t run. This usually meant that we’d see what appeared to be random behavior in which certain computers just stopped running policies, and the underlying cause was PI-000365 (and that do_not_upgrade_jamf flag being set to true).

A couple of ways to detect machines that had this happen have already been listed in this thread, so there’s no need for me to repeat them a second time.

Once the affected computers are identified, we can run the following command either on the affected computer directly or using an SSH session:

defaults write /Library/Preferences/com.jamfsoftware.jamf.plist do_not_upgrade_jamf 0

After it’s set correctly again, the binary should upgrade the next time those computers check in (or you can just force a check in by running a Recon) and they should start working normally again.

If, after that, the binary is still not upgraded on some computers, please get in touch with your Technical Account Manager to dig into it a bit more and find out what’s going on.

Thanks!
Amanda Wulff
JAMF Support

[lisacherie]

Found a client with a 9.91 binary in this state.

• Attempts to checkin (though policies don't run)
• Recon doesn't happen as policy doesn't run, so EA is not an option.
• Attempt to change the value in the jamf plist via config profile has been unsuccessful in testing

Any other non manual options others have used to attempt to fix this?

[chriscollins]

Silly idea @lisacherie but if as @amanda.wulff says, a recon ( with extension attributes) will run even if policies won't, couldn't you just have the EA which the jamf binary runs as root just run the defaults command and fix the issue, then next check in it would upgrade itself (assuming the issue isn't preventing recons from being run)?

[lisacherie]

@chriscollins running a recon means getting physical or ssh access to the client. Recons initiated by policy are not happening.

Obtaining access to the affected clients is the problem.

[musat]

as of 9.8, if the binary doesn’t match the JSS version policies won’t run.

This really got in the way of fixing the issue. I currently have ~900 machines in my "JAMF Binary not Current" group. I had a policy created that would fix this as it came up. Of course, now that policy isn't running. And I don't have any current IP address for all of these systems.I am getting to just doing a network scan Recon to reenroll everything.

So my thought is: 1. Delete all of these non-current Macs from our JSS
2. Run a Recon that skips IPs in the JSS database
3. Repeat the Recon at various times during the day to catch Macs that aren't logged in.

At this point it doesn't seem like there is any other option available, aside from a purely manual process of going to every Mac and seeing if it is current.

[dan-snelson]

@musat My current understanding of this issue is that re-enrolling will NOT modify the .plist to allow the binary to upgrade.

You may want to try a payload-free package with the following as a post-install script:

/usr/bin/defaults delete /Library/Preferences/com.jamfsoftware.jamf do_not_upgrade_jamf

/usr/local/bin/jamf policy -verbose

It will have to be delivered out-of-band from the JSS; do you have access to these machines via ARD?

(We had our users self-install the package which we posted to a ServiceNow Knowledge Base article.)

[sepiemoini]

Looks like PI-000365 was addressed with today's v9.97 release :)

[PI-000365] Fixed an issue where the "do_not_upgrade_jamf" flag was being set to true on some machines.

[sepiemoini]

Howdy, all! I created an EA as @mm2270 outlined for everyone and then scoped a new policy to those with "Do Not Upgrade Set." The policy contained a modified plist file that I created from removing the line containing "do_not_upgrade_jamf" from the /Library/Preferences/com.jamfsoftware.jamf.plist file. Once modified, I created a DMG of this file using Composer. I made sure FUT and FEU was checked when uploading it to Casper Admin and used this in the policy. This did the trick for me!