Security Update 2020-002 for macOS Mojave

[gabester]

What is the best practice method of deploying SecUpd*.pkgs through Jamf when not using Apple's Software Update functionality? Does anyone have any tips on how to successfully install Mojave's SecUpd2020-002Mojave.pkg from the downloaded DMG when deploying it directly with JAMF? I know that's not Apple's preferred way, but currently it behaves unpleasantly with how I configured the Jamf package as requiring a reboot and the "reboot if package requires it" option set in the install policy... the screen freezes for a minute or more, and then the multiple reboot hell begins ASSUMING users didn't brick their Macs already when they saw the frozen screen by holding down the power button. Is anyone else seeing this behavior? (Yes, I know we should be installing with Apple's native software updates, but we just can't do that at the moment, and the idea of deploying updates remotely right now when they have a pretty high incidence - 5% of our fleet or so - of generating downed users/Macs fills this admin with trepidation.)

These are the issues we face:

1. The security update seems to hang the Mac for about a minute just before it reboots. This could cause users to do silly things that lead to bricked devices which are especially to be avoided right now!
2. The security update returns a "failed" result to the JAMF policy which makes it hard for me to know what's happening in the fleet... even though it usually has succeeded by looking at the build version on the failed Mac after it inventories into JAMF again.
3. In our case FileVault can also be a sticking point... It USUALLY seems to do the authenticated reboot properly without prompting the user for additional inputs, but not in every case, resulting in some users suffering longer-than-normal downtimes as they walk away from their updating Mac only to return and see it sitting on a FileVault prompt (or powered off because it sat too long.)

[chrisleed]

So I am seeing similar issues with reboots failing while trying to install this update.

We just had a machine that would not install this update, it would boot to recovery mode startup disk selector instead of starting the update and nothing other than reboot could be triggered. T

We finally got it to install on one of our machines by running the authenticated restart command (sudo fdesetup authrestart) after triggering the update when the jamf restart prompt appears.

Have you seen any luck at your organization in fixing this in other ways?

[Jalves]

If you are relying on video conferencing currently, This update specifically has been giving us some trouble and we have disabled it for the time being. Slack Channel Info about the issue below.

Video Conference Freezing Issue

[gabester]

@Jalves Thanks for bringing this to my attention but I don't think we're experiencing these issues which seem to mostly affect Intel HD 6000 graphics, and predominantly through Zoom? No I'm more talking about running the security update as a package cached from jamf (not downloaded to the clients through Apple's software update functions) - I've dealt with #1 by just dropping a set of jamfHelper dialogs including a fullscreen just before the update applies to disguise the apparent hang. #2 is reportedly a known issue due to the way the Apple updater restarts the Mac. #3 is (barely) acceptably fallout in my organization. Bigger issue is that, since there's no immediate inventory update when all my users are remote, their next checkin over VPN results in the update trying again... And a good fraction of the updates are actually failing (not just logging failed in the policy) with the error message:

Installation failed. The installer reported: installer: Package name is Security Update 2020-002 installer: Upgrading at base path / installer: The upgrade failed.

Other Macs get a slightly different error:

Installation failed. The installer reported: installer: Package name is SU_TITLE installer: Certificate used to sign package is not trusted. Use -allowUntrusted to override.

However the clock is correct and the package checksums as correct, so I'm at a loss to explain why it would not like the cert wrapper in some cases.