macOS Big Sur: Please do not apply enforcedSoftwareUpdateDelay to major OS updates

Moving forward, software updates across all platforms can only be delayed for 90 days. You can find more details in the WWDC session: "Discover AppleSeed for IT and Managed Software Updates" - https://developer.apple.com/wwdc20/10138

In macOS Big Sur, major and minor updates can be deferred by Configuration Profile Restrictions payload using the same preference key: enforcedSoftwareUpdateDelay (Documented here: https://developer.apple.com/documentation/devicemanagement/restrictions)

This would be problematic for our environment for multiple reasons, three of which include:
1) we cannot just allow users to upgrade to the latest major version of macOS without ensuring all third party software works.
2) we do not want to delay minor updates in most cases, but if we did use this preference key then minor updates would be delayed simply because we're trying to delay the major version of macOS.
3) it also implies that the previous version of macOS will no longer get security updates.

We want to allow users to install minor software updates like 10.16.1 for 10.16.2, but not allow them to upgrade to the latest major OS (e.g. 10.17).

We want our OS to have some support for at least security updates after it has been superseded by another major OS release. In many instances, many software vendors provide extended support (or long term support) for some major software releases. I'm not asking that Apple support OS updates indefinitely on older operating systems. But at least one year would be sufficient to ensure a smooth transition to the newest release.

My feedback here would be to have two separate preference keys to achieve different purposes to allow us to distinguish annual major releases from regular minor software updates when creating a delay:
  • enforcedSoftwareUpdateDelay which applies to minor software updates as it previously in 10.15. This can continue to be limited to 90 days as is today.

  • enforcedMajorSoftwareUpdateDelay which applies to major OS updates to prevent new versions of macOS from being advertised on managed computers. Sets how many days to delay a software update on the device. With this restriction in place, the user doesn't see a software update until the specified number of days after the software update release date. This should be limited to 365 days.

We'd also like to request that the enforcement for major OS updates supports a delay longer than the 90 day maximum. Again, unlike a minor release, it could take significantly longer to adopt a new macOS release. I suggest a 365 day maximum instead which provides a year for organization to transition to the new major OS release.

The goal as a business is that we would also like to control how long we can ignore the major OS updates/upgrades and 90 days may not be sufficient. But we also don't want to ignore minor OS updates at the same time leaving our computers vulnerable. Although we typically make every effort possible to support the latest major version of macOS on day 1 release, in some cases, that's simply not possible due to third party incompatibility issues and/or outstanding major OS issues that Apple has not addressed (and may not address in some cases until the next major release).

If you are impacted by this, I sincerely suggest you supply feedback to Apple at https://feedbackassistant.apple.com/.

If you haven't already, please join AppleSeed https://appleseed.apple.com/ and supply feedback to Apple.
Post not yet marked as solved Up vote post of bp8 Down vote post of bp8
1.3k views

Answers

This one is absolutely a necessity for supporting enterprise clients.
While it would be great for day-one or even day-90 readiness, it's just not always feasible. Too many hats, too many hurdles.
Please give us control over all software updates from MDM!

We usually have a lot of issues every year with Antivirus agents. We can’t have Macs not receiving Security Updates because deferring a major upgrade implies deferring all updates... I know, we can change the antivirus for something else but companies take a lot of decisions and those take time...
Please file feedback and reach out to your extended Apple support contacts. The installation team is aware of this request and values your feedback.
Since it took almost one year to get Catalina stable enough to deploy (10.15.5) 90 days are way to short. Apple needs to rethink this strategy or amplify the development and hire more programmers that do the testing, not rely on the users to find the bugs.
This is an issue for us as well. Some of our managed devices are in labs and because of timescales we tend to deploy the current OS in Aug. The new OS releases in Sep but we cannot upgrade during the academic year so must wait until the following Aug. It's vital that we can install point releases to ensure security during the year.

I completely agree with the proposal from the OP. Split the deferrals into major & minor releases. This would allow point releases to be installed swiftly (after testing) and major releases to be deferred until we could upgrade the labs during the defined point in the academic year.

Our service relies on software being consistent (aside from security fixes etc) as course notes are tailored to an agreed software deployment.

Personally I 'd prefer to be running the latest OS sooner but Apple's release schedule does not work well with the academic year.
We had to delay recommending Catalina due to incompatibility with widely used scientific software (SPSS, MathType), and our on premises backup solution (IBM Spectrum Protect), all of which took more than 90 days to reach compatibility. This pattern was not unique to Catalina and I would be surprised if it is any different with Big Sur. If our long-time users of software such as SPSS lost access due to enforced updates, they would have no option but to switch to an operating system that offered more granular control (Windows or Linux).
I have filed feedback on this with both the Feedback Assistant and via our AppleCare Enterprise Agreement. This most definitely needs to be two separate MDM payloads, one for normal point updates, and one for major version macOS updates. Based on the response that I have received, Apple knows that this needs to be separated. Keep filing that feedback!