@nigelmarrion When you say "a couple of JAMF file shares" can you elaborate on how they are setup ?

I saw something similar happen to us once before, but I can't really remember the details now. I don't recall the JSS version nor exactly how we resolved it :-/
But like Ben, I'm wondering about your file shares. Are these scripts being physically uploaded into your CasperShare thru Casper Admin.app, or are you adding them directly into the JSS db? In the former case, there could be an issue with any syncing process you have going between them. If its the latter, the scripts should be available immediately to any clients since they are contained in the database.

I think in our case I might have deleted and re-added the script, which creates a new ID even though its the exact same content and name, and that resolved it, but I can't truly recall now.

Assuming your DP is up to date, this happens if a previous script execution was interrupted while it was being run. When you re-run the policy later, the jamf binary will not copy a newer version of the script from your DP, it will run the older cached copy it had stored in /Library/Application Support/JAMF/tmp. You will need to delete that file so it will get a fresh copy from the DP.

I don't know when the jamf binary normally flushes that /tmp folder or why it uses the cached version instead of copying a fresh one every time, I assume it's a bug (we see this on 9.63).

@bentoms @alexjdale @mm2270

I am running a 9.32 JSS on Linux with 2 SMB File shares in 2 locations so I believe that my scripts are held in the JSS database centrally. This morning I found 4 more machines have run the policy overnight with the old version of the script rather than the new one. These machines were active during the day yesterday and would have been part of the scope for the original run of the script (I flushed the logs when I made my changes to the script) so they may have already run the policy once already but the policy history doesn't show logs in the history once they are flushed (bit of a shame that).

It would help to understand when the jamf binary downloads the copy of the script it wants to use. I know that the policy command runs with a random 15 minute interval but if it downloads the scripts first then sets a 15 minute delay that would make more sense to work out why its not using the newest scripts.

I will try deleting and recreating the script to make sure it uses the newer version from now as suggested. And will be more careful when assuming that the scripts in the JSS database are the ones that are being run..

Ok I have found the issue when I went to recreate the script and add it to the policy as suggested by @mm2270

The policy ran the script and also did an inventory update so that the extension attributes I created to display results were populated. The script was set to run "after" so the inventory was running before the script ran and wasn't displaying the hokey results until I cleared the log and ran it again, when it would collect the results left behind by the older script then run the newer script. Thats why on the next run, the results appeared to be correct.

Thanks for the assistance and I can go back to trusting the way the scripts are running - just learnt a valuable lesson I won't forget in a hurry.