In starting to write a blog post on how to block and delay the latest macOS release, I realised that the subject of delaying updates via Managed Software Updates was probably worthy of its own post.
This its that post, see below the break for details.
Delay or defer?
Before we begin, some Apple documentation refers to delaying updates and also deferring.
So which is it?
Well, it’s both.
Throughout this post I’m going with deferring.
Managed Software Updates?
Since macOS 10.13, iOS 11.3 and tvOS 12.2, there has been an addition to the Restrictions payload which allows for a deferral to be added to when new software updates appear on devices.
This allows updates to be delayed from being offered to devices for up to 90 days.
How does it work?
The simplest way to see this profile in action is to deploy to a macOS device which has updates available.
For these examples, I have applied a 30 day deferral to a macOS device running 10.15.7 (19H2).
This would normally have the 10.15.7 (19H15) supplemental update being offered as well as macOS Big Sur.
But, with the profile deployed with the 30 day deferral in place we see the below in the Software Update preference pane:
To see what’s happening here, we need to inspect: /var/log/install.log after checking for updates via the Software Update preference pane or via:
Once ran, check /var/log/install.log for an entry like the below:
2020-11-14 21:11:26+00 exampleMac softwareupdated: SUScan: Using catalog https://swscan.apple.com/content/catalogs/others/index-10.15-10.14-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz
Soon after which we can should see entries like the below, if any update is being delayed:
2020-11-15 13:24:41+00 exampleMac softwareupdated: Using PostDate for deferral start date 2020-11-15 13:24:41+00 exampleMac softwareupdated: Product 001-79699 is deferred until 2020-12-12 18:00:08 +0000 2020-11-15 13:24:41+00 exampleMac softwareupdated: Using PostDate for deferral start date 2020-11-15 13:24:41+00 exampleMac softwareupdated: Product 001-73001 is deferred until 2020-12-05 18:13:06 +0000 2020-11-15 13:24:41+00 exampleMac softwareupdated: Found deferred update: 001-73001 2020-11-15 13:24:41+00 exampleMac softwareupdated: 2 updates found: 001-73001 (Deferred) | macOS Catalina 10.15.7 Supplemental Update 001-82587(R) | Safari 14.0.1
We can see from the output at the end that we have a deferred update:
001-73001 (Deferred) | macOS Catalina 10.15.7 Supplemental Update
The ID of the update is the ID at the start of the message, 001-73001.
If we take the Catalog URL found at the start of the Software Update run (https://swscan.apple.com/content/catalogs/others/index-10.15-10.14-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz), and paste that into Safari, we should be presented with a massive plist.
Within which we can search for the update via its ID, once the updates entry is found, we can get the PostDate key:
This shows that the update was posted 2020-11-05.
So with our 30 day deferral in place, this correlates with the messages in /var/log/install.log that state that the update is deferred until 2020-12-05.
If we then push a new profile with a shorter deferral in interval, which allows for updates to be installed and then load the Software Update presence pane we’ll see updates available:
Interestingly, in this instance Safari 14.0.1 is showing.
This did show in the log in the below as deferred:
2020-11-15 13:24:41+00 exampleMac softwareupdated: 2 updates found: 001-73001 (Deferred) | macOS Catalina 10.15.7 Supplemental Update 001-82587(R) | Safari 14.0.1
It seems like Software Update wants to only offer Safari 14.0.1 in conjunction with 10.15.7 supplemental.
However, the idea was to give an overall idea as to how this process works and how quick the changes can be made and then shown on macOS.
Apple have sometimes had a need to repost an update to the catalog, the most visible reasoning is when the one or more of their signing certificates have expired.
When republishing an update, the PostDate is updated to reflect the date that the update is reposted.
Which, would then the new date for the deferral and therefore pushing the installation date back on macOS.
To combat this, sometime during the past year or so Apple started to add a new key named DeferredSUEnablementDate for these reposted updates.
When this DeferredSUEnablementDate key is present, this seems to be considered instead of the PostDate key for software update deferrals.
For example, if we look at the Software Update catalog (https://swscan.apple.com/content/catalogs/others/index-10.15-10.14-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz) today, we can see that macOS 10.15.7’s update (001-51037) has both the below:
As such, the date present in the DeferredSUEnablementDate key is what will be used by Software Update to calculate deferrals.
If it wasn’t for this DeferredSUEnablementDate key, then the PostDate key would be used and then the deferral would be calculated from there.
The behaviour of the update deferrals has changed between macOS 10.13 – 10.15.6 and 10.15.7:
And, with macOS Big Sur we have an additional key:
So, this allows for non-OS Updates to be deferred inline with the OS Updates.
But what are these non-OS Updates?
Well, right now, I believe this is Safari alone.
My thinking here is that:
- The fact that the other deferred settings apply to items found within the Software Update catalog
- The key’s name containing the word “App”
- Lastly the fact that when you deploy a macOS 10.15+ device the only application found outside the read-only system volume is Safari.
Hope the above helps to demystify the Managed Updates process for macOS.
Likely this post will be tweaked, expanded and corrected over time. So might be worth checking back.