As described, this only blocks macOS Installer Applications. Preventing users from using Software Updates can only be achieved with [Defer Apple OS Updates](https://kb.filewave.com/books/software-updates-apple/page/defer-apple-os-updates) and you should consider this because Software Update is capable or running the upgrade even with this solution in place.
Apple automatically instals the latest installer application on devices, allowing users to upgrade to the next major release of macOS. The following provides a method to prevent users from running the application, ensuring administrators have the required time to prepare the business.The provided Fileset includes an unaltered version of the Open Source Software [Pashua](https://www.bluem.net/en/projects/pashua/), which is licensed under the [3-Clause BSD License.](https://opensource.org/licenses/BSD-3-Clause)
## Information The attached Fileset prompts users with a message, including alternate languages. There is also allowance for control over which versions of macOS Installers are blocked. The only requirements are the following Filesets: - [mac0S - Block macOS Installer Pashua Daemon.fileset.zip](https://kb.filewave.com/attachments/252) If running macOS 13 or higher, this profile is also required. - [Profile - Block Notifications](https://kb.filewave.com/attachments/247)A requirement script is included to ensure the profile is installed first, before downloading and installing the blocker.
Optionally the following Custom Field may be used to monitor the quantity of times users attempt to upgrade devices: [macOSAppInstallerBlockAttempts.customfields.zip](https://kb.filewave.com/attachments/129)The above instals launchd services. Disassociation of the Fileset will unload these services as well as remove all files.
## Directions The Fileset is currently configured to block the 'Install macOS Ventrua.app' and future versions of macOS Installer App; it would actually also stop the Beta. Version control is managed by the plist file in usr > local > etc > block\_macos\_updates: ``` com.filewave.blockmacosinstaller_user.plist ``` Contents of the file: ```The script defines a version to block (and versions above) in the case that no plist file is found. This is set to 15, since this should never be the case and is a capture to prevent unwanted updates in this unexpected instance.
## Message Localisation When the installed service blocks the App, a message is reported to the user. Examples have been provided for English and German.  The language is determined by the first two characters from the following command: ``` $ defaults read -g AppleLanguages | awk -F "\"" '/\"/ {print $2; exit}' en-GB ``` As such en-GB, en-US, en-AU, etc will all result in an English version. Language template files are stored in the path: ``` /usr/local/etc/block_macos_updates/ ``` English and German respectively: - warning\_en.txt - warning\_de.txt Copy and edit the files appropriately for additional languages. ## Example to add French User has French language set: ``` $ defaults read -g AppleLanguages | awk -F "\"" '/\"/ {print $2; exit}' fr-FR ``` Based upon this, create a copy warning file (note the suffix '\_fr'): - warning\_fr.txt Edit '\*.title' and default message 'txt1.default' appropriately: ``` # Set window title *.title = Installation bloquée # Introductory text txt.type = text txt.default = macOS Installer Application txt.height = 100 txt.width = 310 txt.x = 100 txt.y = 120 txt1.type = text txt1.default = Cette version de macOS n'est pas prête pour l'environnement de production. Veuillez contacter le service informatique si nécessaire. txt1.height = 100 txt1.width = 310 txt1.x = 100 txt1.y = 50 img.type = image img.x = 20 img.y = 70 img.maxwidth = 64 img.path = /usr/local/etc/FileWave_Icon.png ```Text content will impact the view. Consider changing height, x and y values if the view does not appear as intended.
Upload and replace the 'img.path' as your own company logo for customisation.
## Logging The launchd scripts have additional logging which will be available in Apple's Console (Debug level Info). For example: [](https://kb.filewave.com/uploads/images/gallery/2023-09/1BoIBOfhvUMIjmwi-image.png) # Defer Apple OS Updates ## What Use Apple software update deferrals when you want a testing window before users can install new Apple updates themselves. The setting hides matching updates from the device's Software Update pane for the number of days you choose. ## When/Why This is useful when you want to validate a new Apple release before it reaches production devices. Apple allows up to 90 days of deferral. During that window the update is hidden from the user, but FileWave can still install it with MDM if you decide to move ahead.Deferral only affects what the user sees in Software Update. If you also need to stop users from launching full macOS installer apps, use [Fileset to block Apple Install macOS applications](https://kb.filewave.com/books/software-updates-apple/page/fileset-to-block-apple-install-macos-applications).
## How Create or edit an Apple configuration profile and add the **Restrictions** payload for the platform you manage. Searching for **defer** in the Profile Editor is the quickest way to jump to the relevant settings. ### iOS/iPadOS Enable **Defer software updates for** and choose a value from 1 to 90 days. [](https://kb.filewave.com/uploads/images/gallery/2023-07/It3olJSi91lsdzdL-image.png) ### macOS Current macOS payloads let you defer different update types separately: - **Defer major macOS updates for** to delay major upgrades. - **Defer macOS updates for** to delay minor OS updates. - **Defer app updates for** to delay non-OS software updates. For macOS versions earlier than 11.3, the **Defer macOS updates** value is used for all software updates. [](https://kb.filewave.com/uploads/images/gallery/2023-07/s2wv0qVv1Qo4aQlR-image.png) ### tvOS Enable **Defer software updates for** and choose the delay in days. [](https://kb.filewave.com/uploads/images/gallery/2023-07/SK55rHPQar5olDK6-image.png)A shorter initial defer period is usually easier to manage than jumping straight to 90 days. If testing slips, you can extend the delay without starting every profile at the maximum.
While an update is still inside its defer window, local tools such as System Settings / System Preferences and the `softwareupdate` command will not offer that update. MDM remains the supported way to install it during the deferral period.
## Digging Deeper The defer timer starts on Apple's release date for each individual update, not on the day you assign the profile. - **Update 1** is released on June 5. - With a 10-day defer window, users will not see **Update 1** until June 15. - **Update 2** is released on June 12. - With the same defer window, users will not see **Update 2** until June 22. - MDM can still push **Update 1** from June 5 onward, regardless of the defer period. - MDM can still push **Update 2** from June 12 onward, regardless of the defer period. ### Example Process With a 60-day defer policy, users will not see an update until day 60 after Apple publishes it. If Apple releases newer updates before that date, users may still see none of them until each one ages past its own defer window. FileWave can still send an MDM install command during the deferral period. That lets IT test and roll out a specific release before it becomes user-visible. Once the defer window expires, the update becomes visible to the user again. Deferral buys time for testing; it does not permanently hide updates. # Alternate macOS Software Update Method (Legacy) ### Description FileWave server automatically pulls OS Update Catalogs for computers and these are made available through the ‘[New Desktop Fileset](https://kb.filewave.com/books/filesets-payloads/page/filewave-fileset-types "Desktop Filesets")’. To prevent unwanted updates being installed on incorrect machines, we would recommend using the Software Update Desktop Filesets. As of December 13, 2017, we are aware of one particular issue (logged as engineering ticket FW-19993) that will prevent successful installation of certain macOS patch packages ("macOS 10.13.2 Update" and "iTunes" have been confirmed to be affected) using the recommended Software Update Assistant. As such, it may be necessary to create a manual fileset to deploy these updates. Directions The steps to follow are: - Pull the relevant installer down from Apple’s support site: [https://support.apple.com](https://support.apple.com) - Create an empty file set - Place the pkg within the fileset - Create an Activation Script to trigger the installation of the pkg - Create a test association - Once happy associate to only the clients that require the specific patch ### Example: Upgrading a 10.13.1 computer to 10.13.2 Download the delta ‘macOSUpd10.13.2.pkg’ from: [https://support.apple.com/kb/DL1946](https://support.apple.com/kb/DL1946) (Alternatively, download the combo updater from: [https://support.apple.com/kb/DL1944](https://support.apple.com/kb/DL1944)) Drop the pkg into an Empty Fileset. In this example we are going to use /private/var/tmp, as this directory is naturally cleaned out on a reboot. Change the verification to ‘Ignore at Verify’ Create the following script and add it as an [Activation Script](https://kb.filewave.com/books/filesets-payloads/page/fileset-scripts-overview "Fileset Scripts Overview"): ```bash #!/bin/bash # Edit the path/file to match the installer that you have downloaded installer -pkg /private/var/tmp/macOSUpd10.13.2.pkg -target / ``` Script should be set as: - Execute once when activated - Wait for execution > Infinite The fileset can now be associated to test machines. We would recommend testing on virtual machines, since once successfully updated you will no longer be able to test on that device if you wish to re-run the test. Once satisfied it is working as expected, you may now associate to a broader range of machines. # Apple MDM OS Software Updates ## What All MDM configured devices will report and receive Software Updates via MDM. This is the same for: - iOS - iPadOS - tvOS - macOS (Either Big Sur and above or earlier versions if the client is configured for MDM Software Updates) ## When/Why #### Before MDM The FileWave Server would pull the catalogue of all possible updates from Apple. This same catalogue would be delivered from the FileWave Server to each macOS client. After a Fileset containing the update was created and associated, the FileWave Client would use the Software Update process to install associated updates, which would be sent from the Server to the device. #### MDM MDM Software Updates work mostly like Apple VPP Filesets, in as much as FileWave does not store the update. Instead, the Fileset is a reference to the update on the App Store. Only updates reported as required from devices through MDM will show in the Software Update view.The 'Requested Only' tick box will only show those updates that are believed to be currently requested by devices. Each check-in from a device should update the list of appropriate updates for that device.
Apple catalogue updates take up storage on the server once the Fileset is created. MDM Filesets do not store the updates.
## How #### MDM Reporting When necessary, FileWave server will send an APNs to Apple requesting devices check-in. On doing so, the FileWave Server will respond with MDM commands, one of which being a request for ‘AvailableOSUpdate’. The device should reply with all possible appropriate updates. For example: If macOS 14.5 were the latest version, a device running 14.3.1 may request all of those between: - 14.4 - 14.4.1 - 14.5 Apple decide which prior updates will still be available. A device may be updated to any version requested, not just latest. #### Software Update View If not already visible in the Software Updates view, each reported update will be added. When an update is 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’ by right clicking and picking to **Create Fileset...** and then associated. These Filesets will work in FileWave just like any other Fileset as far as assigning them but they will be deployed via the MDM framework. [](https://kb.filewave.com/uploads/images/gallery/2025-03/5IDZ7XvWshoA9Brz-image.png) During the transition between MDM and Catalogue Software Updates, two macOS options will be present: - macOS - Apple Catalogue updates - macOS MDM - Apple MDM updatesAs of FileWave 15.4, only one macOS option will be present in the drop-down box. Apple Catalogues will no longer be available as standard.
#### Fileset Association Within the created Association is an 'Instal at' date/time. For MDM Software Updates, the command to trigger the request to install the update will only be added to the MDM Command Queue once this date/time has been reached. This is not an exact defined time, since APNs check-in request and device response may not be until a day/time after this. Additionally, other factors can impact the device's reaction to any such request, e.g. battery power.MDM Software Updates and **Background Security Improvements** are impacted by battery percentage of the device. Older Apple and FileWave material may still call these **Rapid Security Responses (RSR)**. If the device is not on charge, there is a minimum percentage required for the update to commence. Please see the chart below.
| Mac Notebook Type | ASU Battery Requirement | Background Security Improvements Battery Requirement |
| Mac with Apple silicon | 20% - Priority key set as High | 10% |
| Mac with Apple silicon | 50% - Priority key not set | |
| Intel Based Mac | 50% | 20% |
Apple's 2026 operating systems replaced Rapid Security Response with **Background Security Improvements**. FileWave 16.3.x supports this newer behavior. For older OS versions and older documentation, you may still see the RSR term.
#### DDM FileWave introduced additional software update features with version 15.4, in particular, Force Reboot through Apple's new DDM protocol. If the user has not actioned the update prior to this time, the device should then force this installation.'Activate files at' date/time, if not set, defaults to the time the association is created. The 'Activate files at' date/time in FileWave 15.4 is now a Force Reboot time. Alter this time if this is undesirable.
#### MDM Process Since FileWave does not deliver the update to devices, but a reference to the update on the App Store, devices must first fetch the update. Therefore, the installation process of an update is twofold, one to download the update and another to install the update. **Pending OS Version** is the OS version currently being installed for Apple devices using a DDM Software Update fileset. It is not simply the latest version being requested by the client. Once the scheduled installation time is reached, the device begins downloading and preparing the update, then sends the `softwareupdate.pending-version` status report. FileWave stores that reported value in the **Pending OS Version** inventory field. Since updates can be very large, there can naturally be some delay between the initial association and the actual installation.If the device were upgraded between the association being created and the device receiving the command to update, if the update is no longer appropriate, the device will silently ignore it.
macOS end user prompts [](https://kb.filewave.com/uploads/images/gallery/2025-03/dSotxd8WRWJuXTee-applemacos-softwareupdatenotification.png) iPadOS end user prompts| [](https://kb.filewave.com/uploads/images/gallery/2025-04/pAsxOhYC3QqQpHdG-managedsoftwareupdateipados.png) | [](https://kb.filewave.com/uploads/images/gallery/2025-04/U8YBQgV3hM2WVhVb-managedsoftwareupdateipados2.png) | [](https://kb.filewave.com/uploads/images/gallery/2025-04/0Q3Nnv4d2Rh5wnLC-managedsoftwareupdateipados3.png) |
FileWave now reports multiple updates for devices and all device types will also report iOSUpdate as a named update, where previously they would only report a dedicated updated, for example: iPadOSUpdate
## When/Why This feature allows upgrading an iPad running iPadOS 15.0.2 to iPadOS 15.1 while the most recent update might be 15.3, for example. This functionality is supported on iOS, tvOS, and iPadOS. #### Device Reports Historically, FileWave would receive the latest reported update from a device. For example, any compatible iPads running an iPadOS version of 15.0.2 or below would report the following where 15.3.1 is the latest available version: ```FileWave will update the Software Update view on every synchronisation with Apple. Only updates currently available should be reported. If Apple deprecate an update, this update should no longer show in the Software Update view. Cross reference this view with currently Created/Associated Filesets to ensure the updates are still current.
GDMF advantageously proposes all possible updates for each device, not just the last one, as can be seen in the below images. Device 'London-001' shows both iOSUpdate 15.5 and 15.4.1 as appropriate:  You can now follow the usual process : create Fileset, approve the update, associate the update for any currently available intermediate version. ### Considerations #### Reported Updates Note, not all updates are necessarily appropriate for all device types. For example, the current version of 15.5.1 at the time of writing was only appropriate for these device types. Of course, Apple may change this over time, but FileWave should list appropriate devices (as listed by Apple) for any given update. ``` { "ExpirationDate": "2022-08-23", "PostingDate": "2022-05-25", "ProductVersion": "15.5.1", "SupportedDevices": [ "AppleTV11,1", "AppleTV5,3", "AppleTV6,2", "AudioAccessory1,1", "AudioAccessory1,2", "AudioAccessory5,1" ] }, ``` #### Create Fileset FileWave now reports both GDMF and Client Reported updates. Consequence of creation: ##### Device Reported Updates Creating a Fileset, based upon those the devices report as requested, will only attempt to push this update whilst the device still requests this update. The consequence for any device not yet updated, when the next version is released, is this update Fileset will no longer be successful, since the device will no longer request this version. ##### GDMF Updates Creating a Fileset based upon a GDMF reported Fileset allows any displayed version to be pushed, regardless of the latest available version. This will only be true whilst Apple maintain this update online. Once Apple deprecate this update the matching Fileset will no longer be able to update any devices not yet upgraded. Below is the list of possible iOS 15 updates available at the time of writing. Notice that version 15 updates below 15.3 are no longer available, whilst a version of 14 is still available. **Example of Currently Available Updates** ``` "ProductVersion": "15.5.1", "ProductVersion": "15.5", "ProductVersion": "15.4.1", "ProductVersion": "15.4", "ProductVersion": "15.3.1", "ProductVersion": "15.3", "ProductVersion": "14.8.1" ```Avoid associating multiple appropriate updates. It is unclear in this instance what may occur and is possible one update will cancel the first ending in a situation where no update is actioned. If automatically deploying to devices is chosen, disable this before assigning a new association.
Consider using one method only, either the original reported version by device or GDMF. GDMF provides the greatest scope of control though and would probably be the better choice going forward in most environments.
## Related Content - [MDM Software Update Changes](https://kb.filewave.com/books/software-updates-apple/page/software-updates-in-the-age-of-macos-mdm-big-sur-v110-ios-15 "Software Updates in the age of macOS MDM (Big Sur v11.0+ / iOS 15+)") # Apple Background Security Improvements (formerly Rapid Security Response)Starting with FileWave 16.3.x, FileWave supports Apple's newer **Background Security Improvements** behavior. Older Apple documentation, older OS families, and older FileWave screenshots may still use the earlier **Rapid Security Response (RSR)** wording.
## What changed Rapid Security Response (RSR) was introduced by Apple in iOS 16, iPadOS 16, and macOS 13 as a way to deliver urgent security fixes between standard software updates. Starting with Apple's 2026 operating systems, Apple replaced that model with **Background Security Improvements**. This is not just a label change. Apple now documents Background Security Improvements as their own release type for lightweight security fixes that can be delivered without a full operating system update. In practice, that means you may still see the older RSR term in historical Apple material, older operating systems, older FileWave screenshots, and some low-level Apple management keys, while current Apple deployment guidance for newer OS versions uses Background Security Improvements. ## How they behave - They apply only to the latest supported minor operating system version, so delaying the base minor update also effectively delays the security improvement. - They don't follow the normal managed software update delay. - Some improvements require a device restart. On Mac, Safari-related content may become available to Safari sooner, but a restart is still required to make the content broadly available to the rest of the operating system. - Users can remove installed improvements unless management prevents removal. ## What device management can do Apple's software update framework still exposes controls for these releases. On supervised devices, MDM can control automatic installation behavior, block manual installation, block removal, and enforce a specific response using target OS and build values when Apple publishes one. FileWave inventory continues to use Apple's supplemental software update reporting for this family of releases. The relevant inventory fields are the supplemental version and supplemental build values reported by the device.These screenshots reflect the current FileWave 16.3.0 Profile Editor wording for both the iOS and macOS restrictions payloads. In each payload, the options now appear as **Allow Background Security Improvement installation** and **Allow Background Security Improvement removal**.
[](https://kb.filewave.com/uploads/images/gallery/2026-04/cIhMNYQnZ9xbT4T8-filewave-16-3-0-background-security-improvements-profile-editor.jpg) [](https://kb.filewave.com/uploads/images/gallery/2026-04/babv1vZrfj5u3OZc-filewave-16-3-0-background-security-improvements-profile-editor-macos.jpg) As of FileWave 15, there are two additional inventory items for Apple's supplemental security releases, both labeled as **Supplemental**: [](https://kb.filewave.com/uploads/images/gallery/2023-07/GwqLMFiStU4C4ivn-image.png) Supplemental Build Version typically shows a value only when a current supplemental security release is installed. After the device moves to a newer base OS version, or when there is no active supplemental security release for that version, these fields may be blank again. ## Related Content - [Background Security Improvements on Apple devices](https://support.apple.com/guide/deployment/background-security-improvements-dep93ff7ea78/web) - [About software updates for Apple devices](https://support.apple.com/guide/deployment/about-software-updates-depc4c80847a/web) - [Use device management to deploy software updates to Apple devices](https://support.apple.com/guide/deployment/device-management-deploy-software-updates-depafd2fad80/1/web/1.0) # macOS Erase and Install Fileset (Erase Optional) ## Description Upgrading macOS or performing an erase-and-install workflow both require a full macOS installer app. This Fileset is designed to support either case.Historically, these workflows were split across two KB articles. This newer Fileset can handle either option from one Fileset, and it also removes some older requirements, such as the hidden upgrade file in /var/db.
## Ingredients - Custom Field – "macos\_instal\_flag" - Full Apple macOS Installer App - Provided Recipe - Provided Custom Field ### Fileset:| ↓ macOS |
| [](https://kb.filewave.com/attachments/288) |
| ↓ macOS |
| [](https://kb.filewave.com/attachments/165) |
| **Full installer** Confirm the installer app is the 'Full' installer before continuing. If the app is relatively small e.g. 50MB, re-download the Install macOS Monterey.app. A full installer may be downloaded through Terminal on macOS 10.15+ devices. Example to download the 12.0 full installer to the Applications directory: ``` softwareupdate --fetch-full-installer --full-installer-version 12.0 ``` Typically Apple only provides the latest point release of each Major OS version: 10.13.6, 10.14.6, etc. For a full list of available updates, use the following command: ``` softwareupdate --list-full-installers ``` |
| **Requirement Script – statosinstall\_requirements.sh** Key values that require editing (in bold):  - api\_key – Copy a Token (base64) from a chosen FileWave Administrator's 'Application tokens' - local\_admin – username for a local admin on the target macOS device (Apple M1 only) | **Activation Script – startosinstal\_m1&intel.sh**Key values that require editing (in bold):  - admin\_pass – password for a local admin on the target macOS device (Apple M1 only) - local\_admin – username for the matching local admin as password on the target macOS device (Apple M1 only) - installer\_name – the name of the App added, e.g. 'Install macOS Big Sur', 'Install macOS Monterey' - api\_key – Copy a Token (base64) from a chosen FileWave Administrator's 'Application tokens' 'installer\_name' in Fileset is also set as REPLACE\_ME, but the value is left as 'Install macOS Monterey' as an example in the Fileset image. |
Consider making Smart Group associations based upon the Custom Field value
### Activation Create a Smart Group based upon macos\_instal\_flag value being either ERASE or INSTAL Set the associated Custom Field for a device to one of these two values depending upon the experience you would desire.Selecting a group of devices to associate and/or alter the Custom Field value, will action that new value for all devices currently within that group. The video shows an example of setting the Custom Field value as INSTAL, with the 2 devices within the macOS 10.13 group. Using a group in this way will have no impact on the Custom Field values for devices leaving or joining the group afterward.
Since it is likely a subsequent installation attempt will be desired upon failure (once the reason for failure has been addressed, e.g. not enough disk space), a Smart Group could be set with the Custom Field value of FAILED if desired. To re-run a failed attempt, after addressing the reason for the failure (e.g. freeing up disk space), reset the Custom Field value to the appropriate ERASE or INSTAL value and choose to 'Reinstall Fileset' ## Notes **Why does this Fileset use a Custom Field?** While the Fileset is associated, it may trigger the workflow again. After an erase, for example, the device no longer retains local state about the original installation attempt. Without another control, the device could try to repeat the workflow after it comes back. The Custom Field prevents repeat erase or upgrade attempts once the process is complete, and it also provides a simple way to track failures. By creating a FAILED value, devices can also report unsuccessful attempts automatically, which makes it easier to build queries or Smart Groups for follow-up. By setting the macOS Installer App as leave behind, if the installation has not been completed, but is no longer associated, this will ensure the installer remains on the device for subsequent attempts. Additionally, since Apple automatically removes the macOS Installer App after an upgrade, if the Fileset were still associated there would be no re-attempt to download the installer.Filesets that error will automatically re-attempt installation as standard. The requirement script is designed to report an exit code of 210 to overrule this. Even if the Requirement Script fails, it will report success and will neither continue download/activation nor will it re-attempt without intervention. In this case, the client will update the Custom Field instead to report the failure. The script log should show the output of the command. Example log message: **/usr/local/etc/macos\_instal.log** |main|CUSTOM|CLIENT|startosinstall\_requirements Exiting. Flag set as: In this example, the Custom Field Flag reported has no value. This should either mean the Custom Field is not associated with the device or the script has failed to read the value. If the latter, check the Environment Variables to ensure they are correct.
# Nudge for macOS Software Updates ## What Nudge is a tool designed for macOS Big Sur 11 and later. It is a multi-linguistic application offering custom user deferrals, strongly encouraging users to self update macOS. This macOS application helps users stay up-to-date with software updates and security patches. It is a lightweight and simple background task which periodically checks for updates. Based upon a pre-defined, minimum update configuration, on detection, the user is notified, requesting they update. Nudge can be downloaded from the following link, however this KB includes a Fileset to handle the installation of Nudge: [GitHub - macadmins/nudge: A tool for encouraging the installation of macOS security updates.](https://github.com/macadmins/nudge) ## When/Why Keeping software up-to-date is essential for any system's security and smooth functioning. However, it can be a daunting task to manually track software updates, especially when multiple software packages are installed on the device. That's where Nudge comes into the picture. It combines the automation of software update checking with manual user intervention to ensure devices remain up-to-date. With OS versions being kept current, Nudge helps avoid security vulnerabilities and malicious, unauthorised activity all whilst improving the system's overall performance, with OS features and bug fixes. All of which should maintain a better user experience with greater productivity.Note, for major software updates, an Administrator password may be required. In this case, an alternate approach to upgrade devices could be considered, as highlighted in the KB: [macOS Upgrades or Erasing](https://kb.filewave.com/books/software-updates-apple/page/macos-erase-and-install-fileset-erase-optional)
Prior to macOS 11, Software Updates could be installed either through Apple's legacy Software Update catalogues or using MDM. Consider using the legacy updates for these devices; Nudge should not be required in this instance.
## How Nudge has two main components for installation; - Installation PKG - Configuration file In this example, configuration will be defined using a JSON file. The provided Fileset includes: - Example Configuration - Scripted method of installation - Scripted removal when disassociated [Nudge Notifications.fileset.zip](https://kb.filewave.com/attachments/278) [](https://kb.filewave.com/uploads/images/gallery/2023-11/VlFbjYFvBjvjXYVZ-image.png) ### Scripts This example Fileset does not contain the installer. Instead, a script pulls the latest version from GitHub and instals that version. If a new version exists, the Fileset could be re-triggered with a reinstall Fileset, causing the software to update. The uninstaller contains the necessary lines of code to remove each item installed when disassociated ### Configuration As suggested above, in this example Fileset is a JSON for Nudge configuration. There are two lines to immediately consider: ``` "requiredInstallationDate": "2023-12-28T00:00:00Z", "requiredMinimumOSVersion": "12.7.1", ```| requiredInstallationDate | When reached the conditions of user notification are altered |
| requiredMinimumOSversion | If OS version is below this set value, the user will begin to receive notifications |
The frequency and handling of notifications both before and after the requiredInstallationDate are handled elsewhere within the JSON file. Unless otherwise noted, all other values are set as default.
Below is the contents of the included example JSON file:Note: Sometimes this tool is referred to as **super** or **superman**.
## When/Why Use S.U.P.E.R.M.A.N.? Keeping macOS devices up-to-date with the latest software updates and upgrades is crucial to ensure optimal performance, security, and compatibility. However, managing software updates across a large number of devices can be challenging, especially in organizations with diverse endpoint environments. Here's why you should consider using S.U.P.E.R.M.A.N.: - Streamlined Software Updates: S.U.P.E.R.M.A.N. simplifies the process of managing macOS software updates and upgrades. It ensures that all devices in the organization have the latest software versions, reducing the risk of security vulnerabilities and compatibility issues. - Automated Policy Enforcement: With S.U.P.E.R.M.A.N., administrators can define software update policies once and enforce them across all macOS devices automatically. This automation saves time and effort while ensuring consistency in software version deployment. - Recursive Messaging and Notification: S.U.P.E.R.M.A.N. leverages recursive messaging and notification capabilities to actively prompt users to initiate the update process. This feature encourages end-user participation in keeping their devices up-to-date, reducing potential delays in updates. - Optimal End-User Experience: By allowing users to initiate the update process, S.U.P.E.R.M.A.N. ensures that updates don't disrupt critical tasks. End-users can conveniently schedule updates during non-productive hours, minimizing interruptions to their workflow. - Enhanced Security and Compliance: Outdated software can expose endpoints to security risks. S.U.P.E.R.M.A.N. helps organizations maintain a secure environment by enforcing timely software updates, ensuring compliance with data protection regulations. ##### Mac Computers With Intel - macOS update and upgrade workflows validated on macOS 10.14 and later. Earlier versions of macOS may work, but have not been validated. - The `super` script must run with system (root) privileges, but otherwise no additional credentials or MDM service is required. ##### Mac Computers With Apple Silicon - The `super` script must run with system (root) privileges. - To enforce automatic macOS updates or upgrades without using an MDM requires providing `super` with the local credentials of an existing account. - If no credentials are provided to`super` then macOS updates and upgrades can not be enforced on Mac computers with Apple silicon. In this case `super` prompts the user to provide their local account password; [Apple Silicon Local Credentials · Macjutsu/super Wiki · GitHub](https://github.com/Macjutsu/super/wiki/Apple-Silicon-Local-Credentials)Prior to macOS 11, Software Updates were pulled from Apple's catalogue (not MDM App Store) through FileWave. To achieve this, the client will overwrite the current Software Update plist whilst running and then revert the file once done. This will likely conflict with any Super process, causing Super to fail if the two occur at the same time. You can however get around this.
There is a client setting that could be pushed with Superpref to disable non MDM updates, but easier still, if you disable Legacy Apple Software Updates entirely from the FileWave Central > Preferences > Software Updates tab. This will allow clients not request to attempt non-MDM checks anymore.[](https://kb.filewave.com/uploads/images/gallery/2023-07/ukGciRopzT2skFUh-softwareupdatepreferences.png)Worth noting, that every Model Update, Inventory, Verify, the fwcld client process overwrites this file, since it needs to report which updates are appropriate, so this isn't a case of they might only conflict if you have associated updates, this happens always if not disabled. ## How to Use S.U.P.E.R.M.A.N.? The script must run with system (root) privileges, if you create the Fileset and add the `super` script, it will be run at system (root) privileges just as any other script created in FileWave Filesets. [](https://kb.filewave.com/uploads/images/gallery/2023-07/Uky5HyLzCidsQd5J-screenshot-2023-07-19-at-14-56-48.png) Above is the completed Fileset ready for deployment. You may also download and review the Fileset here: [Superman.fileset.zip](https://kb.filewave.com/attachments/509)For macOS 10.13 (Ventura) and above you should also deploy: [Profile - Superman Managed Login Item.fileset.zip](https://kb.filewave.com/attachments/217)
The Fileset includes both an installation and uninstallation script. If you remove the Fileset from your devices, the uninstallation script will run, removing all content. Deployment and installation will be run silently. You may review the log file to troubleshoot or confirm that the installation has been completed. The main `super` workflow log is the super.log. This log is located at /Library/Management/super/logs/super.log as set by the `$superLOG` script parameter. When run from the command line, `super` also outputs the content of the super.log in real time. Example log below:[](https://kb.filewave.com/uploads/images/gallery/2023-07/Tg5ln333Ri3ar4Dc-screenshot-2023-07-19-at-3-45-27-pm.png) Once installed the end user will be prompted with your configured settings. Here is an example prompt with customized icon, and enforcing the non-system updates on a macOS Monterey device: [](https://kb.filewave.com/uploads/images/gallery/2023-07/3GXMI6gy35k3jYX7-screen-shot-2023-07-20-at-12-18-00-pm.png) ## New release of S.U.P.E.R.M.A.N. With `super` version 3.0, the default dialogs and notifications are handled by [IBM Notifier.app version 2.9.1](https://github.com/IBM/mac-ibm-notifications/releases/tag/v-2.9.1-b-96) and macOS upgrade workflows leverage [`erase-install.sh` version 27.3](https://github.com/grahampugh/erase-install/releases/tag/v27.3). If either of these items are not found on the local system they are automatically installed by `super` via direct download from GitHub. Staying up-to-date with the latest version of `super` can be managed with FileWave. Checking the version of `super`, use [Custom Fields](https://kb.filewave.com/books/custom-fields/page/custom-fields "Custom Fields") to check which version of `super` you have installed on your macOS devices. Below may you download, unzip and import the Custom Field for checking which version is installed: [Superman customfield.zip](https://kb.filewave.com/attachments/209 "Superman customfield.zip") [](https://kb.filewave.com/uploads/images/gallery/2023-07/pCWkCAQg0NWRG0s8-screenshot-2023-07-24-at-10-01-06.png) To update the Fileset and deploy the latest release of `super`, the use of [Fileset Revisions](https://kb.filewave.com/books/filesets-payloads/chapter/fileset-revisions "Fileset Revisions") works great for this Fileset. - Highlight your `super` Fileset, then double-click to open its contents. Select Manage Revisions and create a new Fileset Revision and choose to duplicate everything. - Replace the install\_super.sh with the newest version available from the web page: [Getting Started · Macjutsu/super Wiki · GitHub](https://github.com/Macjutsu/super/wiki/Getting-Started). Save and test deployment to a macOS device and use the custom field to verify latest version installed. [](https://kb.filewave.com/uploads/images/gallery/2023-07/AuOgBTSSrtCU9vpb-screenshot-2023-07-24-at-10-15-24.png) ## Customizing S.U.P.E.R.M.A.N. There are many options to customize your deployment. Displaying your customized icon for your organization, or setting up deferral dates or the amount of deferrals before software update requirement.When customizing the icon, be sure to copy your icon into a folder within the Fileset and specific the correct location path
| **Option parameter** | **Description** | |
| Allow macOS Upgrades | ||
| --allow-upgrade or -M | With this option enabled `super` leverages `erase-install.sh` to find compatible macOS upgrade versions. If a newer macOS upgrade is available then the `super` workflow attempts to download and install the upgrade. | |
| Target macOS Version | ||
| --target-upgrade=12 | With this option enabled `super` does not select any major macOS upgrades newer than the targeted version. For example, if you specified `--target-upgrade=12` then the `super` workflow never attempts to install upgrades to macOS 13 or newer. | |
| Allow macOS RSR | ||
| --allow-rsr-updates or -R | If this option is enable then the `super` workflow appears to the user as a normal macOS update. | |
| Enforce non-System Updates | ||
| --enforce-non-system-updates or -N | With this option enabled, if non-system Apple software updates are found, they are immediately downloaded and installed. | |
| Skip All Updates | ||
| --skip-updates or -S | Skip checking for, downloading, or installing any Apple software updates or upgrades, even if they are available. | |
| Display Customization | ||
| --display-icon=/path/icon.png | Location of the icon image, if the local path contains any special characters or spaces then you should surround the text with single `'` quotes. | |
| Deferral Behavior | ||
| --focus-defer=7200 | The number of seconds to defer automatically if the system is in user-enabled Focus/Do Not Disturb or when a process has requested that the display not go to sleep | |
| --menu-defer=300,1800,3600,7200 | Display a deferral time pop-up menu in the non-deadline update restart dialog that allows the user to override the default | |
| --Error-defer=7200 | The number of seconds to defer if `super` detects an error in the workflow | |
| --recheck-defer=86400 | The number of seconds to defer if no software updates are available or allowed. Enabling this option results in `super` acting as a permanent agent that checks for software updates on a regular basis. | |
| --delete-deferrals | This option can not be set via a MDM configuration profile. However, any other deferral options that are specified via a `super` MDM configuration profile remain in effect. | |
| Deferral Count Deadlines | ||
| --focus-count=5 | The maximum number of automatic deferrals allowed if the system is in user-enabled Focus/Do Not Disturb or when a process has requested that the display not go to sleep | |
| --soft-count=5 | The maximum number of user selected deferrals allowed before showing a soft deadline dialog | |
| --hard-count=5 | The maximum number of user selected deferrals allowed before the computer automatically restarts for updates without asking the user for approval | |
| Deferral Days Deadlines | ||
| --focus-days=3 | The maximum number of days that automatic deferrals are allowed if the system is in user-enabled Focus/Do Not Disturb or when a process has requested that the display not go to sleep | |
| --soft-days=5 | The maximum number of deferral days allowed before showing a soft deadline dialog. | |
| --hard-days=7 | The maximum number of days allowed before before the computer automatically restarts for updates without asking the user for approval. | |
| --zero-day=2022-09-01:12:00 | Instead of having the days deadline counter automatically select the day zero date, this option sets a specific date and time as day zero. | |
| Deferral Date Deadlines | ||
| --focus-date=2022-09-03:12:00 | The last date and time when automatic deferrals are allowed if the system is in user-enabled Focus/Do Not Disturb or when a process has requested that the display not go to sleep | |
| --soft-date=2022-09-05:12:00 | The last date and time before showing a soft deadline dialog. | |
| --hard-date=2022-09-07:12:00 | If this date and time have passed the computer automatically restarts for updates without asking the user for approval. | |
| Apple Silicon Local Credentials | ||
| \--local-account='labadmin' --local-password='ThisIs@Test' | An existing local (standard or admin) user account name and password with [volume ownership privileges](https://support.apple.com/guide/deployment/use-secure-and-bootstrap-tokens-dep24dbdcf9e) that can be used to authenticate the local `softwareupdate` command. |
Please note: Do not deploy the example .mobileconfig file, as this is an example for all options and contains conflicts with other settings that can cause errors if deployed as is.
Example options for the .mobileconfig listed below.