Imaged Mac has "at reboot" scripts interrupted by Jamf.app upgrade?

[CCNapier]

Hi folks,

I've got a curious problem. My scripts, part of a configuration used at image time, seem to get cut off half way through. I think this is to do with the jamf.app doing an upgrade when the Mac boots for the first time (and seemingly while the script is running). The script works normally if called at any other time after imaging.

JSS version 10.1.1-t1513360285
However, the imaging.app simply shows as 101.1 - autocaspernbi reports a minor version difference, but is happy to build the nbi. There is no higher version available to me it seems.

I assume that an older jamf binary is in this "older" imaging.app that nbi uses, which then gets upgraded as soon as the image is delivered and booted up for the first time.

So, at least to troubleshoot this issue, can I somehow get the upgrade to be delayed? The upgrade is automatic so I'm assuming no? Should I create a quickpackage and add to the configuration? Or is there another imaging.app that I can download somewhere?

For reference, the script calls a custom trigger, and that policy runs more scripts but the trigger seems to quit while the other scripts are still running. Normally it should wait to the end of all scripts in the policy - and it does when the script is run any other time, so I'm certain it's not a script issue.

Thanks

[CCNapier]

Created quickpackage from recon added into configuration (before reboot) still has the jamf.app upgrading. I'm assuming that the recon app is also "older" like the imaging app appears to be...

Going to stick a big delay into script to see if that helps. If the policy isn't triggered until after the upgrade is complete, this might work...

[CCNapier]

yes, a delay in calling the policy trigger works. This supports my theory that the jamf upgrade is killing the policy trigger (as it would if the binary is removed/updated whilst in use). I might stick a support call in to get recon and imaging apps up to same level as JSS... This works around for now though. So far anyway.

[gachowski · Accepted solution]

We do this before

# to prevent JSS policies from running 
Sudo launchctl unload /Library/LaunchDaemons/com.jamfsoftware.task.1.plist

and after

# to re-enable JSS policies to run.
Sudo launchctl load /Library/LaunchDaemons/com.jamfsoftware.task.1.plist

[CCNapier]

Nice. A sleep might not wait long enough (unless I put a crazy time) if it's a slower older machine, so this looks good.

Thanks