10.9.2 update completes, but still reporting 10.9.1

dpertschi
Valued Contributor

JSS 8.73, no SUS, pushing 10.9.2 combo update from JSS.

Two out of three of my pilot machines are still reporting as OS 10.9.1 after successfully receiving the update and updating inventory. The machines are confirmed updated.

Is it just me, again?

13 REPLIES 13

nessts
Valued Contributor II

did you put the new MBP retina image on a non MBP retina? I can confirm that if you but the 13" 10.9 MBPr image on a regular MBP it will not get updated by the 10.9.2 combo

tuinte
Contributor III

If I'm reading it right, the machines themselves are reporting 10.9.2 (i.e., they were updated), but the JSS is still reporting 10.9.1? Is this correct, dpertschi?

Not applicable

The updated machines have to restart after installing the 10.9.2 update, and then recon back to the JSS.

mm2270
Legendary Contributor III

Yep, we combat this issue by also deploying a small pkg that drops a LaunchDaemon and script on the Mac after it finishes installing the OS update. We call it post_install_recon. Basically the script checks to see if the JSS is available and if so, does a full recon of the Mac, then unloads the Daemon, deletes the Daemon and deletes the script (itself) The LaunchDaemon is set to RunAtLoad and with a 5 minute start interval. If the JSS is not available, i.e, if the Mac hasn't reconnected to the network when it runs, it just exits the scripts and runs again in 5 minutes. Keeps doing that until it successfully reckons the Mac.

We had to do this because we found that after a system update it could take hours before the Mac would submit new inventory and the inventory would be off for awhile., Using this method also allows us to NOT have a collect Inventory done at the end of the policy which speeds things up a bit, especially if its being run from Self Service.

dpertschi
Valued Contributor

@nessts - no imaging, factory OS's
@tuinte - yes, machine does indeed have the update applied, JSS record has not updated.
@pete_c - That's probably it. My install policy is updating inventory and rebooting. But not triggering another recon after reboot. Thanks.

Josh_Smith
Contributor III

@mm2270 That sounds really slick, any chance you can share the post_install_recon LaunchDaemon and script?

mm2270
Legendary Contributor III

@Josh.Smith, I can't necessarily share it in full here, but I can outline how it works.

If you're not familiar with creating LaunchDaemons, or even if you are, I suggest getting a copy of LaunchControl (you can find it here in the 3rd party software section) The older version of Lingon, which is still out there also would work.
Here is a genericized version of the plist for the LaunchDaemon-

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.org.postrecon</string>
    <key>Program</key>
    <string>**/Library/Scripts/ORG/postinstall_recon.sh**</string>
    <key>RunAtLoad</key>
    <false/>
    <key>StartInterval</key>
    <integer>300</integer>
</dict>
</plist>

Note that the bolded path to the .sh script could really be set to anywhere you want, but should match wherever you deploy the script to.
The StartInterval as I mentioned is set to 300 seconds, or 5 minutes.

As for the script, basically it first runs a jamf checkJSSConnection -retry 2. The script then uses a simple if/then/else block. It checks the exit status of that command.
If '0', or successful,
then run a jamf recon,
unload the LaunchDaemon with launchctl,
delete the LaunchDaemon,
and delete itself all as part of the cleanup.
else if the result of the jamf checkJSSConnection is not 0, simply exit and wait another 5 minutes to run again.

Once the LaunchDaemon and script are together, place them in the correct locations and package them up in the packaging tool of your choice and add to your policy. There's no need to script anything to load the LaunchDaemon after installation since the reboot takes care of that. Just get them into the right place and once the reboot happens, it takes over.

Hopefully that gives you enough to go on. As a side note, we used to use jamf log in the script but found that if the jss wasn't available, oddly, the jamf log command would still exit 0, which doesn't make any sense to me, but that's what we were finding. So in essence, it would think the JSS was available and move on to the rest of the script, failing the recon of course, but deleting everything anyway.

Josh_Smith
Contributor III

@mm2270 - That is great, thanks Mike.

Josh_Smith
Contributor III

This is working for me but I am having trouble deleting the LaunchDaemon.

It appears when I unload the LaunchDaemon my script stops running at that point. I have searched quite a bit and I haven't found anyone describing this behavior. Here are a couple of the things I have tried, none successful:

  • Using AbandonProcessGroup to try to prevent the LaunchDaemon from killing the script
  • Using the ProgramArguments key instead of the Program key, based on some working examples I saw. It didn't make any difference
  • launchctl stop/unload/remove in different combinations

LaunchDaemon:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.mylabel</string>
    <key>ProgramArguments</key>
    <array>
    <string>/mypath/myscript.sh</string>
    </array>
    <key>RunAtLoad</key>
    <false/>
    <key>StartInterval</key>
    <integer>300</integer>
</dict>
</plist>

Script:

launchctl unload com.mylabel   #script stops executing here
rm "/Library/LaunchDaemons/com.mylabel.plist"

What does work is just deleting the LaunchDaemon without unloading it first, but it seems like a bad practice. Any ideas?

dpertschi
Valued Contributor

I must be loosing my mind (hey this ain't so bad)...

I thought that one of the more recent releases of the JSS introduced an option to defer an inventory update (recon) to the next reboot, instead of immediately after the policy runs.

Josh_Smith
Contributor III

@dpertschi That is very good to know....that would solve the issue. We have plans to update to the current JSS version....but right now are still on 8.73.

dpertschi
Valued Contributor

Well, that's where the mind loosing bit comes in.
I'm on 8.73 also, but have a 9.52 JSS in the lab and I can't find that feature. Really thought I had heard it mentioned for 9.5...

mm2270
Legendary Contributor III

I think you may be thinking of this Feature Request, which was implemented in 9.4:
https://jamfnation.jamfsoftware.com/featureRequest.html?id=618
While that helps with normal policies, I don't think it holds a recon until after a reboot to my knowledge.