We are upgrading macOS (minor versions and potentially major versions) using a scripted approach:
Install the InstallAssistant package via installer
Trigger OS install via startosinstall
On MDM-managed assets, OS update policies appear to prohibit or interfere with the update flow. The update often fails with startosinstall reporting “Helper tool crashed…” during the “Preparing” phase.
Steps to Reproduce
On an MDM-enrolled Mac with OS update restriction/deferral policies applied, run:
sudo /usr/sbin/installer -pkg /Path/To/InstallAssistant.pkg -target / &&
echo 'MACOS_PASSWORD' | /Applications/Install\ macOS\ Sonoma.app/Contents/Resources/startosinstall
--agreetolicense
--forcequitapps
--stdinpass
--user MACOS_USER
Actual Result
Package installation reports success, but startosinstall fails during preparation with:
Standard Output
installer: Package name is macOS15.7_SoftwareUpdate
installer: Upgrading at base path /
installer: The upgrade was successful.
By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms.
If you do not agree, press CTRL-C and cancel this process immediately.
Preparing to run macOS Installer...
Preparing: 0.0%
Preparing: 0.1%
...
Preparing: 24.9%
Standard Error
Helper tool crashed...
notes.log
Install.log is also attached.
Questions for Apple / Ask:
We suspect this crash is caused by MDM OS update restrictions/policies.
We need Apple’s recommended method to perform macOS updates (minor + major) when MDM is present, especially in environments where update deferrals/restrictions may be configured.
Device Management
RSS for tagAllow administrators to securely and remotely configure enrolled devices using Device Management.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Background / Objective
We are currently developing a solution to centrally manage Apple OS updates (major and minor) across managed macOS devices. Before implementing at scale, we need Apple’s guidance on supported and future-proof update mechanisms under MDM.
Questions / Ask (Apple Guidance Requested)
Apple recommended method
What is Apple’s recommended approach to perform:
Minor updates (e.g., macOS X.Y → X.Z)
Major upgrades (e.g., Ventura → Sonoma) in an enterprise fleet?
Support boundary
Is macOS update management only supported via MDM (including any newer declarative workflows), or are local mechanisms (installer + command-line tooling) also considered supported for enterprise automation?
Use of startosinstall
Can we leverage the existing utility:
/Applications/Install macOS .app/Contents/Resources/startosinstall for automated upgrades in enterprise environments?
If yes, are there recommended flags/workflows Apple endorses for unattended or minimally interactive upgrades?
Long-term support / stability
Does startosinstall have any form of long-term support / stability guarantees across future macOS releases?
Are there any known deprecations planned (or guidance that customers should transition to MDM/DDM workflows)?
MDM interaction / interference
When using startosinstall, can MDM policies (software update deferrals/restrictions, update enforcement, etc.) interfere with or block the upgrade?
If interference is expected, what is the correct supported way to coordinate:
MDM software update settings
local startosinstall execution to avoid failures and ensure compliance?
What We Need From Apple (Desired Outcome)
A clear statement of recommended and supported update workflow(s) for enterprise managed macOS:
for minor updates
for major upgrades
Guidance on whether startosinstall is acceptable for long-term automation, or whether we should only use MDM/DDM-driven workflows.
Any best practices or reference documentation Apple recommends for implementing this safely and reliably.
I've been running the betas fine for a while, now, where do you want to go??
Topic:
Business & Education
SubTopic:
Device Management
We are currently working on a SCEP server implementation that operates in FIPS-approved mode. In this mode, RSA PKCS#1 v1.5 encryption is disallowed due to compliance requirements, and only FIPS-approved padding schemes such as RSA-OAEP are permitted.
However, we have observed that the SCEP client functionality on Apple devices currently does not support RSA-OAEP for CMS EnvelopedData decryption. This creates a challenge for us in ensuring FIPS compliance while maintaining compatibility with Apple devices during certificate enrollment through SCEP.
We would appreciate your guidance on the following:
Are there any alternative FIPS-approved encryption algorithms or configurations supported by Apple devices for SCEP CMS EnvelopedData decryption?
Is there any plan or timeline for future support of RSA-OAEP on Apple platforms for this use case?
Feedback raised along with sysdiagnose logs as well : FB17655410