Questions about default action...and more

[okschl]

Hello @mpanighetti and thanks for this great work.

I don't necessarily have any issue(s) yet but rather have a few questions to gain a better understanding.

1. What is the default action when the dialog box pops up and user ignores it? Where in the script can you control that?
2. Is there a way to have script still execute download/install within working hours and reboot after working hours? The reason for this is because in out environment, users tend to not have your machines active enough after working hours for anything that takes time, such as updates to occur.
3. With the behavior of "if updates requires restart, install all...i.e. 'softwareupdate -ia'...", would this in turn upgrade a system say of macos 12.x.x to macos version 13.x.x?
4. Regarding ARM systems, is there a way to pass credentials to say a common local admin account on all systems to "softwareupdate -i --stdinpass --user "?
5. In terms of uninstalling? What is the best way to go about in doing it in case we run into some issue(s)? Is there a guide for how to create the uninstall script using the 'preinstall'?

Thanks in advance for your feedback.

[mpanighetti]

1. If the user ignores an install/defer prompt, it will default to Defer after a timeout period (which can be set as a configuration profile key). jamfHelper presents a timeout with button options as the same exit code as if the user clicked the default button, so setting the default to Defer prevents any unintentional automatic installations before the deferral period has ended. Defer button behavior is controlled here. Just modified the script comments #98 to better indicate the shared causes for that return value.
2. As currently written, the script does not separate install and restart actions, and this is not recommended, as modern macOS has a requirement to restart or shut down immediately as part of the install workflow depending on the update. This is noted in a script comment here. Note that if the deferral deadline passes, the script will switch to enforcement mode the next time it runs, even if during business hours.
3. We found a bug in softwareupdate where it would report a major version as a delta update (as is happening with the Ventura upgrade as of macOS 12.3.0) even if the update was deferred, so I added a workaround that excluded that update from the list that gets parsed to determine if any updates are required. That workaround is noted here. That said, if the system happens to need another update requiring a restart, then it's possible that --install --all would include the Ventura update. This isn't something I've tested much since I've been moving devices to Ventura as quickly as possible, so I'd be curious about the script behavior if you want to experiment with this, but that said, this framework was always intended to facilitate enforcing security updates in a timely manner, so I don't think there would be much justification to engineer solutions to stay behind a major version for most folks who use this script.
4. The script as written does not currently prompt the user for a password, instead leaving it to macOS to provide those prompts in a more secure and trusted manner than the option I'd have with native macOS solutions, which would be an AppleScript prompt.
5. The preinstall script could be run as a standalone uninstaller, and I've written a similar one for my own use. You'd probably want to remove the ${3} prefixes from the file paths since those are specifically Installer environment variables for the target boot disk path.

Hope that all helps!

[okschl]

• If the user ignores an install/defer prompt, it will default to Defer after a timeout period (which can be set as a configuration profile key). jamfHelper presents a timeout with button options as the same exit code as if the user clicked the default button, so setting the default to Defer prevents any unintentional automatic installations before the deferral period has ended. Defer button behavior is controlled here. Just modified the script comments updated workflow version requirements, added power adapter note to alerts #98 to better indicate the shared causes for that return value.
• As currently written, the script does not separate install and restart actions, and this is not recommended, as modern macOS has a requirement to restart or shut down immediately as part of the install workflow depending on the update. This is noted in a script comment here. Note that if the deferral deadline passes, the script will switch to enforcement mode the next time it runs, even if during business hours.
• We found a bug in softwareupdate where it would report a major version as a delta update (as is happening with the Ventura upgrade as of macOS 12.3.0) even if the update was deferred, so I added a workaround that excluded that update from the list that gets parsed to determine if any updates are required. That workaround is noted here. That said, if the system happens to need another update requiring a restart, then it's possible that --install --all would include the Ventura update. This isn't something I've tested much since I've been moving devices to Ventura as quickly as possible, so I'd be curious about the script behavior if you want to experiment with this, but that said, this framework was always intended to facilitate enforcing security updates in a timely manner, so I don't think there would be much justification to engineer solutions to stay behind a major version for most folks who use this script.
• The script as written does not currently prompt the user for a password, instead leaving it to macOS to provide those prompts in a more secure and trusted manner than the option I'd have with native macOS solutions, which would be an AppleScript prompt.
• The preinstall script could be run as a standalone uninstaller, and I've written a similar one for my own use. You'd probably want to remove the ${3} prefixes from the file paths since those are specifically Installer environment variables for the target boot disk path.

Thanks for your feedback! I really appreciate it!

We will indeed test the macos 12/13 scenarios. We have some teams that use quite a few legacy apps that is almost always not compatible with newer version of the os.