Defer Apple OS Updates
What
Apple allow users to update devices themselves, however it may be desired to delay an update, perhaps due to some incompatibility that is not yet resolved.
When/Why
When Apple release updates, devices report these updates to the users of the device; allowing them to trigger that update as soon as they desire. Apple provide a method to ‘Defer’ updates. Updates deferred will no longer be visible to the user, may be deferred up to a maximum of 90 days, yet MDM may still push updates during the deferred timeframe.
As described, this only blocks users from using Software Updates. Preventing users from using a macOS Installer Applications can be achieved with Fileset to block Apple Install macOS applications
How
The method of deferral varies between macOS and mobile devices, but both are pushed using a Configuration Profile.
iOS/iPadOS
macOS
On recent macOS versions, the restriction may not apply to major updates like OS updates. Major OS updates can be hidden using the --ignore option of softwareupdate command line tool. For instance, Catalina upgrade can be made hidden by running:
softwareupdate --ignore "macOS Catalina"
softwareupdate --reset-ignored
These commands can be sent to your devices using scripts within filesets.
tvOS
Consider a recommended workflow where a defer time frame is less than maximum. This would give the option to amend the policy to a greater amount where the deadline is not met. Remember to lower the defer period, on completion of the additional testing and deployment, back to the lower chosen value.
When updates are deferred, no local tools may be used to view or instal updates released in a time frame less than the deferred period. This not only includes System Preferences, but also the 'softwareupdate' command line tool. MDM is the only method of deployment whilst an update is still in its deferred time frame.
Digging Deeper
Deferring Examples
Deferment duration commences on the release date of each update. For example, with a defer period of 10 days:
- appleOS 1.1 released June 5th
- User will not be able to see appleOS 1.1 update until 15th June
- appleOS 1.2 released June 12th
- Users will not be able to see appleOS 1.2 update until 22rd June
- MDM may push out appleOS 1.1. from June 5th onwards, regardless of the deferred period
- MDM may push out appleOS 1.2. from June 12th onwards, regardless of the deferred period
Example Process
Consider a 60 day defer policy. Within 60 days after an update is released, it will not be available to the user. Once 60 days have passed, the update will show in Software Updates and the user may instal the update. It is possible that during that 60 day period an update is released to supersede the original. As long as Apple do not deprecate the former, it should still be available for deployment to devices.
In the example, 10.15.2 and 10.15.3 were released prior to 10.15.1 reaching its 60 day policy restriction. As such none of the 10.15 updates will be available to the end user. During the 60 day time frame, an MDM command may be sent to the device to instal the update; as indicated on day 50 of the example. In this instance, the command to instal 10.15.1 was sent. If not deprecated, a 10.15.1 notification should be presented to the user to instal the update.
60 days from an updates release, the policy lapses and the user is notified of the update, regardless; any devices that had not yet received the 10.15.1 deployment would then notify the user. If testing has not been completed and the 60 day policy lapses, as seen with 10.15.2, then the user will still be notified that the update exists; day 80, 60 days after day 20 when 10.15.2 was released.
It is therefore possible to be testing multiple versions of updates, prior to release to users. However, it is not possible to prevent the users from seeing those updates once the deferred period has been exceeded.