Hello all, We have built our own MDM solution as we plan to support quite a few devices running iOS. Manual activation is running fine and devices are checking in. We have setup ABM with Device management service setup and linked to our MDM. We have added reseller via Apple customer number and purchased devices are showing in ABM. We have setup default management service assignment as well. When we are setting up a device it gives an error: Remote Management The configuration for your iPhone could not be downloaded from . cancelled Error in the device log is as follows: Jun 11 14:16:36 iPhone Setup(DMCUtilities)[626] : <DMCHTTPRequestor: 0x84cfd7d40> cannot accept the authentication method NSURLAuthenticationMethodClientCertificate Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Task <663D2346-4B73-4DB2-A134-B1A7DC58E70B>.<1> auth completion disp=2 cred=0x0 Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Task <663D2346-4B73-4DB2-A134-B1A7DC58E70B>.<1> summary for task failure {transaction_duration_ms=285, response_status=-1, connection=7, reused=1, reused_after_ms=0, request_start_ms=0, request_duration_ms=0, response_start_ms=0, response_duration_ms=0, request_bytes=0, request_throughput_kbps=0, response_bytes=0, response_throughput_kbps=0, cache_hit=false} Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Connection 7: TLS Client Certificates encountered error 1:89 Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Task <663D2346-4B73-4DB2-A134-B1A7DC58E70B>.<1> finished with error [-999] Error Domain=NSURLErrorDomain Code=-999 UserInfo={NSErrorFailingURLStringKey=, NSErrorFailingURLKey=, _NSURLErrorRelatedURLSessionTaskErrorKey=, _NSURLErrorFailingURLSessionTaskErrorKey=, NSLocalizedDescription=} Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Connection 7: encountered error(1:89) Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Connection 7: cleaning up Jun 11 14:16:36 iPhone Setup(CFNetwork)[626] : Connection 7: summary for unused connection {protocol="http/1.1", domain_lookup_duration_ms=0, connect_duration_ms=0, secure_connection_duration_ms=0, private_relay=false, idle_duration_ms=0} Jun 11 14:16:36 iPhone Setup(DMCUtilities)[626] : <DMCHTTPRequestor: 0x84cfd7d40> failed to communicate with the MDM server. Error: NSURLError:Desc : cancelled Domain : NSURLErrorDomain Code : -999 Extra info: { NSErrorFailingURLKey = "https://mdm.domainname/enroll"; NSErrorFailingURLStringKey = "https://mdm.domainname/enroll"; "_NSURLErrorFailingURLSessionTaskErrorKey" = "LocalDataTask <663D2346-4B73-4DB2-A134-B1A7DC58E70B>.<1>"; "_NSURLErrorRelatedURLSessionTaskErrorKey" = ( "LocalDataTask <663D2346-4B73-4DB2-A134-B1A7DC58E70B>.<1>" ); }

On iOS 26, if in "Single App Mode", the device gets stuck on the lock screen. Devices are configured in SAM (kiosk mode), without a PIN requirement. Since updating to iPadOS 26, every single device that locks (goes to sleep) becomes completely unresponsive at the lock screen. Touch input does not work. The only way to regain access is to reboot the device, which will boot to the SAM app, but then lock again if it goes to sleep. Related discussion in the public forums.

After applying the MDM camera restriction on iOS 26.1 beta 2, the camera availability status is reported incorrectly. After applying the MDM camera restriction [UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypeCamera] return YES

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!

Hello, I have a system, which is able to execute bash/zsh scripts on a set of machines. The default behaviour is that the signature of the script is checked on the machine, which is executing it, and in case if it is not signed properly, the system rejects the execution. An own certificate has to be created for signing the scripts, which means that the certificate has to be installed and marked as trusted on the target machines (which are executing the script). I've been using : "/usr/bin/security add-trusted-cert ..." command to install the certificate on the machines as trusted. Since macOS Big Sur, the above command was prompting the local user for admin credentials. To avoid this, Apple suggested to use the following command to temporarily disable and re-enable the confirmation dialog : 1.: /usr/bin/security authorizationdb write com.apple.trust-settings.admin allow 2.: /usr/bin/security authorizationdb write com.apple.trust-settings.admin admin Now with the release of macOS Sequoia, the above command : "/usr/bin/security authorizationdb write com.apple.trust-settings.admin allow" does not work any more. It gives the following output : NO (-60005) I have the following questions : 1.: Could you please suggest an alternative way for IT administrators to install certificates on their machines, without any user confirmation? 2.: Could you please suggest how the same could be achieved using a bash/zsh script? In which context could the above commands : "/usr/bin/security authorizationdb write com.apple.trust-settings.admin allow" and "/usr/bin/security authorizationdb write com.apple.trust-settings.admin admin" still work? Thank you for your help in advance!

ABM has introduced a target date for moving a device from one MDM server to a new one. However, there's nothing in the API for setting that when you use the API to move MDM server Am I missing something or does it just not exist? Thanks Caroline

We are implementing the Return to Service (RTS) with App Preservation flow. During testing, we were able to successfully fetch the Bootstrap Token as part of the ADE enrollment process. However, when attempting to initiate the Return to Service command with App Preservation enabled, the following error was returned: [ { "ErrorCode": 12089, "ErrorDomain": "MDMErrorDomain", "LocalizedDescription": "Could not erase device.", "USEnglishDescription": "Could not erase device." }, { "ErrorCode": 66002, "ErrorDomain": "MDMBootstrapTokenErrorDomain", "LocalizedDescription": "Failed to generate LAContext for bootstrap token", "USEnglishDescription": "Failed to generate LAContext for bootstrap token" } ] Below is the sample request (with dummy data). The actual request contained valid values in all fields: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Command</key> <dict> <key>RequestType</key> <string>EraseDevice</string> <key>ReturnToService</key> <dict> <key>Enabled</key> <true /> <key>WiFiProfileData</key> <data>WiFiProfileData</data> <key>BootstrapToken</key> <data>BootstrapTokenValue</data> <key>MDMProfileData</key> <data>MDM Profile Data</data> </dict> </dict> <key>CommandUUID</key> <string>3670</string> </dict> </plist>

On a supervised device running iOS 18 without any AirDrop restrictions applied, when a profile with allowListedAppBundleIDs restriction key is installed, the AirDrop sound plays. But still the accept prompt does not appear, making it impossible to accept files. The prompt works as expected on iOS 18 devices to which the allowListedAppBundleIDs restriction is not installed. This issue occurs only on supervised iOS 18 devices to which the allowListedAppBundleIDs restriction is being applied. Device must be in iOS 18 version > Install the (allowListedAppBundleIDs restriction) profile with the device > Try to AirDrop files to the managed device. The expected result is that the accept prompt must pop up but it does not appear. This issue is occurring irrespective of any Whitelisted bundle ID being added to the allowListedAppBundleIDs restriction profile. Have attached a few Whitelisted bundle ID here com.talentlms.talentlms.ios.beta, com.maxaccel.safetrack, com.manageengine.mdm.iosagent, com.apple.weather, com.apple.mobilenotes, gov.dot.phmsa.erg2, com.apple.calculator, com.manageengine.mdm.iosagent, com.apple.webapp, com.apple.CoreCDPUI.localSecretPrompt etc. Have raised a Feedback request (FB15709399) with sysdiagnose logs and a short video on the issue.

There could be a case where-in multiple transparent proxies might exist in the system (for ex., Cisco AnyConnect, GlobalProtect, etc). We want to know if there is a way to order transparent proxies so that the desired transparent proxy gets the request first. During our research, we found a resource which talks about ordering transparent proxies through MDM. https://developer.apple.com/documentation/devicemanagement/vpn/transparentproxy Using this reference, we tried to create a profile and push it through JAMF. Below is the profile that we created and pushed with JAMF. Property List - &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;TransparentProxy&lt;/key&gt; &lt;array&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.paloaltonetworks.GlobalProtect.client.extension&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;1&lt;/string&gt; &lt;/dict&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.cisco.anyconnect.macos.acsockext&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;2&lt;/string&gt; &lt;/dict&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.mydomain.transparentproxy&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;3&lt;/string&gt; &lt;/dict&gt; &lt;/array&gt; We are not sure if this is the right way to create the profile, though JAMF is not throwing any error while pushing this profile. We see this profile on the local machine as "/Library/Managed Preferences/com.apple.networking.vpn-transparent-list.plist". Is there a way to know if the profile took effect and the order of transparent proxies has changed. Thanks in advance.

We’ve run into what looks like a gap in how forceAirDropUnmanaged is enforced on iOS devices. Setup: Device: iOS 17.x (unsupervised, enrolled in MDM) MDM Restriction: forceAirDropUnmanaged = true Managed Open-In restriction also applied (block unmanaged destinations). Verified: from a managed app, the AirDrop icon is hidden in the share sheet. This part works as expected. Issue: When two iOS devices are brought close together, the proximity-initiated AirDrop / NameDrop flow still allows transfer of photos, videos, or files between devices. In this path, forceAirDropUnmanaged does not appear to apply, even though the same restriction works correctly in the standard sharing pane. What I’d expect: If forceAirDropUnmanaged is enabled, all AirDrop transfer paths (including proximity/NameDrop) should be treated as unmanaged, and thus blocked when “Managed Open-In to unmanaged destinations” is restricted. What I observe instead: Share sheet → AirDrop hidden ✅ Proximity/NameDrop → transfer still possible ❌ Questions for Apple / Community: Is this a known limitation or expected behavior? Is there a different restriction key (or combination) that also covers proximity-based AirDrop? If not currently supported, should this be filed as Feedback (FB) to request alignment between share sheet AirDrop and NameDrop enforcement? This behaviour introduces a compliance gap for organisations relying on MDM to control data exfiltration on unsupervised or user-enrolled devices. Any clarification or guidance would be greatly appreciated.

We’re running into a problem when deploying certain .pkg installers via MDM on macOS 15 and above. The installation fails with the following error message: “The app is running and we don’t have the context to quit it, failing install.” Context: The .pkg is being pushed through an MDM solution (not installed manually). This happens consistently across multiple macOS 15+ devices. The target app is often already running when the MDM tries to install the update. Unlike a manual installation, the MDM does not appear to have the ability to quit the running app before proceeding. Questions: Is this a known change in macOS 15 where MDM-delivered installs no longer have permission to terminate apps during package installation? Are there recommended best practices for handling app updates via .pkg through MDM in this scenario? Has anyone implemented a workaround—such as pre-install scripts, user notifications, or policies to quit the app before running the installer—that works reliably on macOS 15? Is Apple planning to update MDM behavior or installer APIs to address this, or should admins expect to handle quitting apps entirely outside of the MDM installation process? Any insights from Apple engineers or other developers/admins who have encountered this would be really helpful.