OS/Security updates reboot before policy logs complete/fail

dpertschi
Valued Contributor

Not a new problem, but one I've not found a graceful solution for. This applies to those of us installing packages, and not calling softwareupdate cli.

The OS incremental updates and security update packages include a post-flight reboot script. When deployed from a policy the machine will abruptly reboot to the installer and be on its merry way.

The result is positive, updates applied; however the policy is never updated with a complete/fail status. And the computer record policy log doesn't even show that the policy ran, (because it ended abruptly).

Anyone worked around this while installing these packages?

3 REPLIES 3

dpertschi
Valued Contributor

mm2270
Legendary Contributor III

Yeah, this will become a bigger and bigger issue as time goes on and Apple moves firmly into these style of updates away from what they used to do.

The only thing I can think of doing is caching the update to the machine, and then kicking it off with a LaunchDaemon or some other script where it fires the update in a delayed manner, and then exits so it can upload a Jamf policy log. You will at least get a log saying it "Completed", but that doesn't mean it actually worked of course. If after it kicks off the update it fails for some reason, you won't know that from the Jamf Pro policy log, only by looking at inventory data later.
So it's not ideal, but I can't think of any other way to do it, unless you just have faith in the Apple update process and don't rely on the policy logs. πŸ™

Maybe someone else has or has come up with a better method.

bartlomiejsojka
Contributor
Contributor

You could try with these two policies:

  1. Ongoing with a custom trigger to cache that update installer.
  2. Once per computer, on recurring check–in and startup, with just a single script with this flow:
    if update applied (verify by build or package receipt)
        if cached installer exists, remove it
        recon (to clear cached package receipt if it happened to be updated in the meantime)
        exit 0 (this will report a Completed on startup after reboot)
    else 
        if installer is not cached, trigger the first policy to cache it
        ensure the user is logged in (in case of the startup trigger, otherwise wait)
        install the update with the installer
        exit $? (if it is 0 the script will never reach this line due to a reboot)
    You can easily make the script universal for all your update installers, thanks to script parameters.

Should work πŸ‘πŸΌ