All MDM configured devices will report and receive Software Updates via MDM. This is the same for:
mac0S (Either Big Sur and above or earlier versions if the client is configured for MDM Software Updates)
Unlike the old macOS catalogues, no updates will show until at least one device has reported an update as required. Once this has happened, that update will remain visible in the Software Updates view
When necessary, FileWave server will send an APNs request to devices, causing any receiving device to check-in. On check-in, the FileWave Server will send an ‘AvailabeOSUpdate’ request to devices. This should trigger the device to report back to the server all possible updates for that device. If not already visible in the Software Updates view, each reported update will be added, but for all possible updates, when selected, the list of devices reporting the update as required will be displayed. From this same view, the desired update may be used to ‘Create Fileset’ and then associated
Due to macOS updates being available either by the old catalogue method or MDM, there are two options in the Software Update listings. For MDM updates, select the ‘macOS MDM’ updates option.
As an example, imagine version 15.6.1 was the latest iOS version and the device were running 15.5. The versions the device may report as appropriate could be:
Any one of these updates could be associated to the device, allowing the device to be either updated to the latest version or an intermediate version.
Creation of the Fileset is nothing more than data to inform the device which update it should update to.
To instal an update via MDM involves a command to be sent to the device twice ‘ScheduleOSUpdate’
The first time the command is sent it will inform the device to download the update. Once acknowledged, periodically the FileWave Server will send additional APNs requests with the intent to send OSUpdateStatus commands; this command should establish the current percentage downloaded.
When the download is 100% complete, the ‘ScheduleOSUpdate’ command is resent. This time the device will commence/schedule the actual instal of the update once acknowledged.
Updates will still need to be considered appropriate by the device on receipt of the update. For example, if the device had reported an update were required and the association were made, if the user had updated the device between these two events, then this update Fileset would no longer be necessary on receipt.
This process also relies upon the updates still being available from Apple. In the same way, if an update were associated, but between these two events Apple pulled the update from their servers, then again the update would not actually be triggered on the device.
If the update is no longer required, the device silently ignores the update, there is no report back from the device to suggest this has happened.
Taking the above example, if the device were running iOS 15.5 and reported the same list of updates, consider the following:
Fileset pushed to update all devices to 15.5.1
All devices update
Next check-in, devices will no longer report 15.5.1 as required
Software Update view will still show the 15.5.1 update, but it will no longer show where ‘Requested Only’ is selected
During the process, if some devices have completed the update, but not others, the update will still show in the ‘Requested Only’ view, but when highlighted, any devices that have subsequently checked-in and sent an inventory for a newer ‘AvailableOSUpdate’ command, those devices will no longer be seen in the list of reported devices for that update.