Apple plans on removing enterprise options for macOS Software Update

Careful on that link. It served up a Adobe Flash malware ad for me.

Ditto, also a pop-up window that my Symantec anti-virus license had expired. I had to quit out of Safari and restart :(

Sorry about that folks. I've submitted a support case with WordPress. I'm just using the free version of WordPress so it sucks this is happening. Try opening it up in a private window if possible to see if you get better results. I've reported the ads and hope they can resolve it on their end as well. It's a little hard to reproduce on my end consistently, but I do promise you the content in the post is not malicious.

Copy/Paste from this website :)

Apple plans on removing enterprise options for macOS software update

For sometime now, Apple has allowed IT administrators to manage updates for macOS. However in a very near future that may change unless other IT administrators start to provide feedback to Apple. This will be long but please read as now is a critical time to provide Apple feedback before WWDC (whenever that takes place) and the next major OS is released.

You’ve been able to manage software updates on macOS through an Apple Software Update Server (SUS) and/or softwareupdate​.

With a Software Update Server, you can manage which updates are made available to your Macs. This allows you to approve updates on your organization’s schedule and once the updates have been vetted. Reposado is the most popular software to achieve this at the moment since Apple removed that functionality for the macOS Server app.

With softwareupdate you can create scripted workflows to have updates installed in an automated fashion.

The ability to manage updates has worked pretty fine for about 10+ years. However things started to a change with softwareupdate when Apple released their first Mac with a T2 chip (the first iMac Pro released in December 2017). This resulted in them adding a new option for softwareupdate which would take the appropriate action on updates that required a shutdown instead of a restart.

Unfortunately, Apple made certain assumptions when updating softwareupdate and reworking their tooling/update process. They assume that all updates are essentially triggered when someone is logged in. For many reasons this is not a good assumption to make as some third party tools and/or patching workflows like to run at the login window.

In some scenarios, the softewareupdate command line tool would simply say it completed successfully, but not actually restart/shutdown because it wasn’t run with a logged in user. In other scenarios, if you downloaded software updates in advance, you only had a certain amount of time to install the updates before they “expired” which would mean you’d need to redownload the updates again. This has made working with softwareupdate a bit difficult and has resulted in some IT admins essentially creating workflows where they repeatedly prompt end-users to open up the Software Update preference pane to run updates. This is less than ideal in situations where computers are in shared environments such as computer labs or conference rooms. Is Apple suggesting that companies hire more IT administrators to walk around and manually update computers? Or are they suggesting that Macs have no place being used in shared environments?

With macOS 10.15, Apple silently announced that they are deprecating and removing the ability for IT administrators to point to an internal SUS catalog. For example, in 10.15 if you run:

softwareupdate --set-catalog you will get the message:

Changing the Software Update catalog is deprecated. The ability to specify a custom catalog will be removed in a future release of macOS.

It is unclear what future release that will be.

In 10.15.4, another interesting change has occurred: the ability to use --ignore to ignore updates through softwareupate will also be deprecated and removed.

And although the MDM documentation has not been updated, in the macOS 10.15.4, Apple is planning the following:

The forceDelayedSoftwareUpdates key in the Restrictions payload will now apply to major OS versions in addition to software updates.

This would be problematic for our environment for multiple reasons, two of which include: 1) we cannot just allow users to upgrade to the latest version of macOS without ensuring all third party software works and 2) it also implies that the previous version of macOS will no longer get security updates.

--set-catalog and it’s MDM equivalent has been used for many years by any organizations to point Macs at an internal software update server containing updates that they’ve approved and released on THEIR schedule. Apple will be making that impossible in a future OS release. Unfortunately, caching servers do not help control which updates can get released to Macs. Caching servers are useless for bandwidth savings.

Likewise, we’ve used the --ignore feature to temporarily block one or more specific updates until they were ready because they were causing computers to not boot properly or computers to crash (issues created by new firmware). Again, Apple will take that ability away in a future OS release.

We do not typically lag behind Apple updates. That is, we typically tend to support the latest Apple updates the same day and only take action to ignore an update when we notice that there are widely reported problems that are effecting us internally due to the latest update Apple has released causing issues.

As a simple aside, Apple’s quality control on their updates in recent years has left a lot to be desired. A few years ago, they released an update that broke Ethernet on Macs. But more recently, they’ve released updates that have caused:

kernel panics on some Macs waking up from sleep, some Macs to freeze when using hardware accelerated video, kernel panics when using the FaceTime camera, and some Macs to suffer data loss!

If you’ve been managing updates in your computer, you may have been spared some of the pain with these updates.

You can deploy a configuration profile through your MDM on supervised devices to delay updates. A supervised device is configured a device that has been enrolled through Apple Business Manager/Apple School Manager. This presents two obvious problems:

Unfortunately, both programs are not available in all countries that sell Apple devices. Depending on when and where you’ve purchased your Macs, they may not be in either Apple Business Manager/Apple School Manager. And unlike iOS devices that can be enrolled into Apple Business Manager/Apple School Manager through Apple Configurator, you cannot do that with Macs. And if Apple were to offer that ability for Macs, it would most likely limit it to only those Macs with T2 chip.

Here are the two preferences you need to manage with a configuration profile:

Preference: forceDelayedSoftwareUpdates Type: boolean Description: If true, delays user visibility of software updates. In macOS, seed build updates are allowed, without delay. Requires a supervised device. Available in iOS 11.3 and later, macOS 10.13 and later, and tvOS 12.2 and later. Default: false

and

Preference: enforcedSoftwareUpdateDelay Type: integer Description: 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. Requires a supervised device. Available in iOS 11.3 and later, macOS 10.13.4 and later, and tvOS 12.2 and later. Default: 30 Minimum: 1 Maximum: 90

You can also set macOS to do automatic updates through a configuration profile. However, in my experience, the automatic update mechanism has resulted in a much lower percentage of our Macs getting updated versus prompting users to perform updates or forcing the update on computers that may not be in use.

If I think about the implications of these deprecation notices in 10.15 and you look at how software updates behave on iOS, it’s hard to avoid this conclusion:
macOS 10.16 will be distributed via Apple Software Update and previous methods to control the availability of these major updates will no longer work. You will be able to use MDM to delay it up to 90 days (no longer), but only if you delay all other updates 90 days as well.

The only other possible option is to completely disable Apple Software Update checks, which means getting zero security updates — like those for MRT and XProtect.

If my interpretation is correct here, Apple seems to have decided that its own schedule is far more important than the schedule of any organization that has chosen to use Mac computers. We are not 100% in control of when we can move to new macOS releases — often we must wait for third-party vendors to release their own updates and also confirm that Apple does not introduce new bugs in their own updates.

It will be a major business disruption if our Macs are forced to upgrade to macOS 10.16 (or another future release) on Apple’s schedule and not ours. Existing mechanisms for controlling and managing these updates have worked well for us for at least ten years. Apple is taking these mechanisms away without providing for adequate functional replacements.

Completely turning off Apple software updates to avoid these forced OS updates will leave our Macs missing other important security updates. This is obviously not an option for any organization that is security conscious.

More specifically:

You cannot block specific updates or major OS version advertisements like you can with an internal Software Update Server or through the use of softwareupdate --ignore. Keep in mind that for many organizations, macOS is not the main productivity tool, 3rd party apps are and we have to respect their requirements, too. Updates are removed from the Apple SUS catalog when new updates come out which resets the delay clock. Historically for the past few years, Apple has released updates about every 2 months. If delays set for 90 days, the Mac will never get any updates. How is that better? I would also like to point out that this would make the preference key forceDelayedSoftwareUpdates rather useless for most organizations. This means if we delay updates for 90 days to avoid macOS 10.15.4, by the time the next update is released (e.g. 10.15.5), it will have already been replaced and 10.15.4 will no longer be available from Apple’s Software Update catalog. This means we cannot install 10.15.4 through normal software update mechanisms (Software Update pref pane) because Apple has stopped publishing it. In fact, we would only be left with having to download the 10.15.4 combo update package and deploying that through software management tools which is less than ideal given all the intricacies involved with updates nowadays (e.g. firmware updates, restarting vs shutting down, etc.). This new model of delaying updates should keep old updates in the SUS catalog for and extended time and not remove them right away. Give us a chance to roll out what was being tested. Cannot target specific updates to specific computers or groups. Different groups have different workflows. Being forced to latest has its drawbacks if it’s not fully tested and vetted. See all the issues I’ve linked to earlier that were introduced by Apple updates. Lack of full installer for complete workflow testing. Need full installer EVERY build for Apple Business Manager/Apple School Manager workflow testing. Once a new OS is released, that is now the environment you get from internet recovery. We need to verify that OS works from scratch and we can’t do that without full installer.

I’d like to make some suggestions to Apple to potentially address a concern we currently have in terms of the software update process as a system administrator.

1. IT administrators want the ability to block specific updates and approve them when ready so that users can download them straight from Apple. However when it comes to major OS updates/upgrades, we want to completely block them until our organization is completely ready to have that deployed without having arbitrary time limitations of 90 days. One way to achieve this could be by limiting the ability to use custom Software Update Servers via a configuration profile on Macs under User Approved MDM.

2. Macs should have two separate preference keys to achieve different purposes when it comes to delaying advertisement of major and minor OS updates:

   forceDelayedSoftwareUpdates should apply to minor software updates as it previously did prior to 10.15.4. forceDelayedMajorUpdates should apply to major OS updates to prevent new versions of macOS from being advertised on managed computers. This should be a Boolean value where True means major OS updates are not advertised at all and False means they are advertised. 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.

3. It would be great if we can force users to upgrade by 1) a certain date and/or 2) to defer updates X amount of times before they are forced to install that update. We would like users to be able to set hours in which they should not be interrupted for these updates to be performed. Microsoft seems to have figured this out with Windows 10 and you can set active hours where you are not interrupted. This would allow IT administrators to force Macs to be running the latest version without having to introduce custom prompts. Currently, we make use of “automatic updates” in macOS and the percentage of computers that actually update automatically is quite low even on computers without any third party software. This has caused us to rely on running software that nags the end user to update since so many of them ignore the prompts by the notification center and the automatic update process does not work most of the time.

4. We would like to have the ability to push out a configuration profile that would allow us to specify updates (either by name or product id) that should be ignored. This would provide us the functionality that we used to have with --ignore for which there has not been an adequate replacement in MDM. Delaying updates for X days is not the same as ignoring a specific update. An alternative suggestion to accomplish this request would be to allow IT administrators to push out a configuration profile with the Privacy Preferences Policy Control payload that would allow us to whitelist management tools that can run softwareupdate and therefore allow only managed devices to --ignore updates. This would prevent malicious actors from ignoring macOS updates if that’s the concern from Apple’s end.

5. We would like to be able to point to a custom update catalog via MDM where the catalog would essentially provide a list of all updates that are approved to be installed and those updates that are deprecated as chosen by the IT administrator. To ensure that the catalog is coming from a valid source, I am proposing that it be published by the MDM server and that the updates come directly from Apple (or content caching servers). This would allow supervised devices to get only the approved updates and that the updates have not been altered (since they are coming from Apple). Because we cannot control the Apple Software Update Server, this would also mean that Apple would have to perpetually host updates and not remove them (or at least retain them for a long time). The MDM server would sync periodically with Apple’s Software Update service to determine when new updates are released and allow the Mac admin to approve or deny the update.
   Apple can mark the updates as “deprecated” on their own public catalogs that consumers/unmanaged/unsupervised computers rely on, but on supervised computers the MDM provided catalog would take over in this situation as to what updates are approved and available for computers to install.

6. If Apple insists on making major management features rely on devices being supervised then they should allow IT administrators an option for Macs to be enrolled into Apple Business Manager/Apple School Manager through Apple Configurator similar to how you can do so for iOS devices today.

If you’re reading this, you’re either an IT administrator or someone working from Apple. If you’re an IT administrator, I’d implore you to provide Apple feedback. You are a part of the Apple Business Manager/Apple School Manager program you can register for the AppleSeed program and provide Apple feedback! If you have an Apple Enterprise Support, open up a support case.

If you work at Apple and are reading this, I’d implore you to reach out to IT administrators and listen to the feedback here. We try to support Apple devices in our organizations so long as there are management options. However, taking away options to manage updates on Macs and potentially causing productivity issues would quickly make companies re-evaluate whether to continue Macs. It is possible to achieve some of the security goals you want without making it impossible for IT administrators to manage updates.

This is a bad move, I created a ticket with Apple support.

Since it's Read Only Friday, take the time to submit that feedback folks!

Does anyone have ideas to work around this for the time being? As soon as our Mojave computers were patched with "Security Update 2020-003" the ignore for macOS Catalina was ignored and multiple users opened tickets asking if they should update. We also have it listed as restricted software which stops the process but the notification still pops up.

A few options:
1. Upgrade to 10.15.
2. Communicate to users that they should ignore the notification to upgrade.

Regardless of which option you choose above, provide feedback to Apple.

For now it's communicate we're not doing X update yet, and set the installer in Restricted Software.

I love how Apple assumes everyone can just upgrade when the new update is out, or wait just 90 days. We're STILL waiting for a vendor of some custom software we can't replace to update for 64-bit compatibility. Yep, 10.15.5 is out, and no Catalina for us. At this point 10.16 will be announced before we get a working 64-bit compatible version. And it's not like we didn't warn them when the first hints came out years ago. Damnit. >:(