I am trying to correctly manage about 20 Mac, iPhones and PC inside a Wi-Fi network built through System Settings > Sharing > Internet Sharing To achieve this task I defined a complete configuration file: /etc/bootpd.plist which is used by /usr/libexec/InternetSharing. But every time /usr/libexec/InternetSharing is starting the file /etc/bootpd.plist is overwritten by another file and my configuration is thus fully lost. How to set a correct /etc/bootps.plist file and avoid its total overwrite by /usr/libexec/InternetSharing? Is it necessary to write this bootpd.plist in some other directory for /usr/libexec/InternetSharing to load it without destroying it? I got the same configuration total erase on macOS Big Sur and Sequoia.

Hello, I am trying to authenticate to the Apple Business Manager API to retrieve device information and ingest it into ServiceNow. I am following the documentation here. The first step is to create an API account and download the private key used to create a JWT client assertion. The guide linked above gives a python script to create a client assertion. Below the first python script, the following description is given for the "kid" variable: "The value is your keyId that returns when you upload a public key." This is the first time that a public key, rather than a private key, is referenced. Where is the public key supposed to be uploaded? Later in the guide, a public key is referenced again, in the section describing the client_id Request parameter: "(Required) You receive your clientId when you upload a public key." I have tried to create a client assertion using the keyId that is associated with the API account. When I try to request an access token, however, I also get an "invalid_client" error back. I am wondering if I'm using the wrong values for both key_id and client_id due to not creating and uploading a public key. Any help would be appreciated, thanks!

Hi, I’m testing the ClearPasscode MDM command: https://developer.apple.com/documentation/devicemanagement/clear-passcode-command Question: If a user enters the passcode incorrectly multiple times and the device becomes temporarily locked (e.g., “Try again in X minutes”) or reaches “Security Lockout”, can ClearPasscode still be executed successfully while the device is in that state? {'ErrorCode': 5013, 35708 'ErrorDomain': 'MCPasscodeErrorDomain', 35709 'LocalizedDescription': '\xe3\x81\x93...x89', 35710 'USEnglishDescription': 'The passcode cannot be cleared (-1)'} If it depends on conditions (e.g., supervised vs. user enrollment, availability of UnlockToken, network/check-in state), could you clarify which conditions are required? Thank you.

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.

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??

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

Hello everyone, I am looking for technical clarification regarding potential rate limits when automating frequent iOS device resets. In my workflow, I need to reset test devices multiple times per day using the EraseDevice MDM command, often combined with the ReturnToService flag for automated setup. I understand that after a full reset, the device undertakes several critical steps to become operational again, including device activation, system app installation, MDM re-enrollment, and subsequent validation of developer certificates for internally distributed apps. Based on Apple’s documentation and my own observations, I am aware of the following domains being involved in these processes: Device Activation: albert.apple.com, gs.apple.com, captive.apple.com, humb.apple.com, static.ips.apple.com, sq-device.apple.com, tbsc.apple.com, time*.apple.com System App Installation: *.itunes.apple.com, *.apps.apple.com, *.mzstatic.com MDM Enrollment: Communication with Apple ADE servers followed by the MDM server. Developer Certificate Validation: ppq.apple.com, ocsp.apple.com, crl.apple.com My primary question is: Are there any rate limits imposed by Apple’s servers on these specific processes when performed frequently on the exact same device within a short timeframe (e.g., multiple times per day)? Specifically, could anyone provide information regarding potential limits for: Device activation requests? System app downloads post-activation? Automated Device Enrollment checks and subsequent MDM enrollments? Developer certificate validation requests? Additionally, is the list of domains above comprehensive for these processes, or are there other key endpoints involved that I should be aware of regarding potential rate limiting? Understanding these limitations is crucial for ensuring the reliability of automated device management workflows. Thank you for any insights!

We are moving to Apple Business Store for our b2b customers. On the "residential" apple store side there is testflight. What process would one test an app we provide to a b2b customer when using apple business store publishing? (I don't see any sort of test flight for apple business)

We are having issues working with bypass codes the server creates when initiating Activation Lock through MDM. We are able to use the device-generated bypass codes without issue. When using the end point to request activation lock as specified in https://developer.apple.com/documentation/devicemanagement/creating-and-using-bypass-codes/ we get a 200 response. But when using the endpoint to bypass the activation lock, we get a 404 response. If we try to manually input the activation lock bypass code, it also does not work. Both of these methods work with the device-generated bypass codes. Just to clarify when testing the server generated codes, we ensured that we did not test the device-generated codes. All of this was tested on iOS devices. Created feedback ticket FB21365819 with device specific details.

It seems like every time an IOS update is installed, the camera app file formats get reset to defaults. This setting is not available to manage at the MDM level. Many people need the the most compatible settings for the purpose of file sharing. So, now we have nearly 1,000 devices with a complete mix of photo and video formats. And IT has wasted MANY hours converting files for people. Feature Request: Please either stop resetting the camera app file formats or allow us to manage those settings at the MDM level. Respectfully, Robert