10.10.3 Update By Any Other Method Than App Store - BROKEN

One option would be to use Munki for Apple updates. The latest version handles the combo update correctly.

Yeah, I'd love to move to Munki or Resposado. We are all ASUS on Minis for now.

Not too difficult to use Munki for just Apple updates. https://github.com/munki/munki/wiki/Apple-Software-Updates-With-Munki

Unfortunately we wont be making the move soon, so I'm hoping that JAMF can come up with a solution. I wonder if grabbing the separate install packages from ASUS and playing with the order in a policy will get me somewhere...

We added a reboot script to the end of the software update policy.

shutdown -r now

Seems to be successful for a workaround for now.

ooo cool! I'll give that a try.

Well that looks like it worked when used on a SUS policy pushed from the JSS at check-in! I'll test using Self Service tomorrow and report back! Thanks!!

We are also seeing this.
Unsure why we have to force a reboot as we never had to do that with previous updates...

The "shutdown -r now" method always works compared to the hit and miss "Reboot Immediately"

In the years I have been using Casper I have never seen "Reboot Immediately" work correctly.

We deployed updates to our Technicians last night. This has given us mixed results. Shutdown now will definitely restart the computer. The problem is the system will not update the policy to inform JSS that the policy completed. Thus sticking the computer into a reboot loop and re-running the policy at check-in every time.

To fix that problem we added in the recon command and excluded 10.10.3 systems from the policy so that the reboot loop would stop.

We aren't very happy with the results and the massive amount of work arounds required for this update. We are delaying the update until JAMF/Apple figure out whats broken.

Yeah I am definitely not seeing a log for policy completion on the SUS based update policy, though it does seem to restart now. We are testing the 10.10.3 combo via Self Service with the "shutdown -r now" command.

You could try using the following in the script instead:

/sbin/shutdown -r +2
exit 0

This should start the reboot sequence with a 2 minute delay and push it to the background, then exit the script, which would allow the policy to close out and upload a log to the JSS about it completing as well as a full recon. Usually inventory submission doesn't require more than 2 minutes (hopefully). You may be able to reduce that to +1 instead of +2 (1 minute delay versus 2 minutes) if you have a light recon process that completes pretty quickly.

EDIT: Ampersand isn't needed, so I removed it.

Nice I'll try that out as well.

Yea we tried +1 before giving up. Sometimes the script wouldn't execute. The update was just too inconsistent.

We have been having good luck with tacking on "/sbin/shutdown -r +1" to the Files & Processes section, but for the Combo and Self Service initiated SUS install. We end up with logs on both counts, a successfully rebooted machine, and 10.10.3 with working Recovery Drive. We are going to let fly soon after excluding 10.10 machines which are not 10.10.3 from any/all SUS push policies.

I concur with @dgreening 's advice. On some systems I do see that it tries to issue a reboot after my shutdown command already kicked in. In any case, it doesn't matter.
Do we think this is completely an Apple problem with the combo update?

Not sure if it's the OS update, the firmware updater embedded into the OS update package, or the Recovery update, but another +1 to including the /sbin/shutdown -r +1 at the end of your update policy.

I have had the same experience with 10.10.3 on Casper 9.71. Has anyone tried on 9.72 yet?

Same problem here, we are using Repasodo for our SUS server. I can confirm it does appear to be something with the combo update, machines installing the standard 10.10.3 update don't seem to be having this issue. Just appears to be something with the combo update. Haven't tried 9.72 yet though.

So a bit more interesting information. This is happening in my thin imaging script. The last thing that happens is the jamf recon command is called in the script before the script reboots the computer. It appears to be getting hung when it's trying to update inventory. Is anyone else updating inventory after the upgrade? Is this the point that you guys are seeing this happen?

Just got confirmation of an open defect for the issue. Let's hope it's fixed soon.

I was able to work around this issue:

• Downloaded 10.10.3 ComboUpdate, copied installer .pkg to Casper Admin.
• Created smart computer group for OS 10.10.2 or lower
• Smart group is scope for two scripts: 1 - (recurring/once per computer) to cache installer and configured restart options: no user = immediate; user = restart (we allow user to delay 60 min.) 2 - (at log out/once per computer) to run cached installer. Restart options configured: no user = immediate; user = restart.

Maybe not the most elegant deployment but it has worked well for us. I am testing this same method with 10.10.4 ComboUpdate