Are all of these devices checking in ok? I've just checked with one of our setups and all 600 devices are on the correct version.

You could try manually deploying via a policy, although it might need a bit of testing as I'm not sure at what point the actual binary would be replaced. You don't want them to lose contact with the JSS.

The underlying issue sounds more network related though.

Yup. Here's an example

Computer Name:SBA2347
Last Inventory Update:Today at 12:37 PM
Last Check-in:Today at 2:00 PM
IP Address:10.10.120.116
Reported IP Address:10.10.120.116
jamf binary Version:9.12

So totally checking in and updating inventory right. But yet that JAMF binary is super out of date.

I've found that executing a "jamf policy" will update machines which are out of date. Not sure why they arent updating on check-in...

In addition to sudo jamf policy, please add the --verbose flag... so: [code]sudo jamf policy --verbose[/code]

I've seen where if the clock skew is enforced ( in /computerSecurity.html ), that a client will not update if off by the declared time.

3054gwyatt:~ q$ sudo jamf policy --verbose

WARNING: Improper use of the sudo command could lead to data loss
or the deletion of important system files. Please double-check your
typing when using sudo. Type "man sudo" for more information.

To proceed, enter your password, or type Ctrl-C to abort.

Password:
Checking for policies triggered by "recurring check-in"...
Not upgrading jamf binary. do_not_upgrade_jamf is set to true in /Library/Preferences/com.jamfsoftware.jamf.plist verbose: Found 1 matching policies.
Executing Policy Remove Guest Network... verbose: Copying script to temp directory... verbose: Determining script type...
Running script RemoveGuest.sh...
Script exit code: 0
Script result: /Library/Application Support/JAMF/tmp/RemoveGuest.sh: line 18: [: ==: unary operator expected

verbose: Removing local copy...
Submitting log to https://casper.saes.org:8443/
3054gwyatt:~ q$

Soooo I wonder why that flag is set to true?

But editing that plist and removing that key, then running jamf policy did the trick.

A different machine has a different issue.

SBA2296:~ q$ sudo jamf policy -verbose

There was an error.

*** -[__NSArrayI objectAtIndex:]: index 1 beyond bounds [0 .. 0]
SBA2296:~ q$

But this machine still recons.

To further add. Doing recon from the terminal doesn't fix it. Doing recon from the Recon app does seem to fix it.

Hey @boberito !

I'm seeing this recently going from 9.81 > 9.91, and haven't figured out the cause as to WHY it's been happening in the first place.

My environment is somewhat large, and I'm not about to go and edit everyone's plist. :-)