Apple iPad Air device failing to enroll through ABM with "failed to retrieve configuration" error. This error occurs while reaching Apple ABM for fetching MDM server enrollment details. When we checked console logs when enrolling the device we found following error: ​default 13:54:07.229022+1000 teslad Error: Error Domain=MCCloudConfigurationErrorDomain Code=34004 "The cloud configuration server is unavailable or busy." UserInfo={NSLocalizedDescription=The cloud configuration server is unavailable or busy., CloudConfigurationErrorType=CloudConfigurationFatalError} default 13:54:07.229120+1000 Setup Service completed default 13:54:07.230096+1000 Setup Could not retrieve cloud configuration. Error: <Error domain: MCCloudConfigErrorDomain, code 33001>\ Feedback raised along with screenshot and console logs as well : FB17785513. Please analyse this issue and reply back to us.

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

During MDM Automated Device Enrollment of Apple TV, the web view defined by configuration_web_url is not working. We are using the web view to display the usage policy for all devices. While the web view functions correctly for other devices, it is resulting in an error specifically for Apple TV. Could you please clarify whether Apple plans to implement support for this feature on Apple TV in the future or if it will not be supported? Referring to configuration_web_url in: https://developer.apple.com/documentation/devicemanagement/profile

I am using system_profiler command to check on the installed application list from mac device. **Terminal command to check installed java version - ** But while running /usr/sbin/system_profiler SPApplicationsDataType -xml , I cant able to find Java as an installed application. Is this a known issue or do we have any alternative workaround to fetch the same?

Issue - Safari application not fetched from system_profile command Use case - We are trying to get list of installed applications in the mac. For this we use System_profiler command to fetch the details list. It is working good, but the thing is , It doesnt fetch Safari app as an installed Application. Command used - **/usr/sbin/system_profiler SPApplicationsDataType** Can anyone suggest any other way to fetch the installed applications list from the mac , which includes all the apps (including safari app) and remains effective ?

Managed iOS/iPad devices are struck with no network under below conditions Enrolling a Supervised iOS device Send InstallProfile command with AppLock payload (https://developer.apple.com/documentation/devicemanagement/applock) Now when the above managed device loses network connection with MDM server due to unknown network issues - the device is out of contact with MDM server and device is locked. Since such AppLock payload installed devices are placed in remote locations, it becomes difficult for Admins to recover such devices with no network connectivity. The devices have to be brought in from remote location and recover them. Under such conditions, it would be better to allow the end user to change the Network configuration manually to reconnect the device with MDM server. This option can also be allowed only when the device can’t ping MDM server.

Hi Apple Community, I have been Testing with key allowAccountModification in macOS Restriction Payload and found some contrasting behavior In macOS 14, macOS 15.1 in both of the OS Version when allowAccountModification is set to False it restricts adding new Account in System Settings and this is expected behavior How ever things are contrasting and not going as expected in the below situation When macOS 14 Version has 2 profiles for Restriction Payload one with allowAccountModification set to False and another with allowAccountModification set to True it restricts adding Apple Account When macOS 15.1 Version has 2 profiles for Restriction Payload one with allowAccountModification set to False and another with allowAccountModification set to True it allows adding Apple Account I remember when restrictions payload keys are contrasting across different profile Apple Uses the most restrictive one among them. But in macOS 15.1 the behavior is unexpected. Is this a issue in 15.1 and is there any list of macOS versions which shows this unexpected behavior

Hi Apple Community, If a macOS Device is FileVault Encrypted, We are using the keys FDE_HasInstitutionalRecoveryKey, FDE_HasPersonalRecoveryKey from SecurityInfo to know the Device Encryption Type. But Some times rarely we get FDE_Enabled as true but both the above mentioned keys as false Also we get SecurityInfo Response patterns like these only if FileVault is enabled in Device with iCloud as option to unlock the disk Can we confirm this pattern or is there any way to know if device is encrypted with options other than Personal / Institutional Types <plist version="1.0"> <dict> <key>CommandUUID</key> <string>SecurityInfo</string> <key>SecurityInfo</key> <dict> ...... ...... ...... <key>FDE_Enabled</key> <true/> <key>FDE_HasInstitutionalRecoveryKey</key> <false/> <key>FDE_HasPersonalRecoveryKey</key> <false/> ...... ...... ...... <key>Status</key> <string>Acknowledged</string> <key>UDID</key> <string>..............</string> </dict> </plist>

Ref- https://support.apple.com/en-in/guide/deployment/dep3b4cf515/web When we deploy an Payload with identifier "com.apple.airprint" , It will add the deployed printer configurations to printers list in mac. Which additionally needs the mac user to add it from Settings -> Printers -> Add Printer -> (Deployed Printer Configuration will be listed here) Select the printer -> Click Add . Screenshot where user need to add it manually after profile association is attached below. Now the Printer is available to be used ,when an share option in any document is clicked. Why this flow requires multiple to and fro. Can it be able to deploy the printer straight to Printers available List instead of manually adding from the above screenshot

Dear Apple Team, As an MDM (Mobile Device Management) service provider, we are writing to bring attention to an issue that is affecting many of our customers who manage large fleets of iOS devices. Specifically, we have encountered challenges with the app update process via MDM, which is impacting both kiosk devices and non-kiosk devices in a variety of use cases. Issue 1: App Updates Delayed on Kiosk Devices Many of our customers are deploying kiosk devices that are used 24/7 independently with no attendants. In these cases, when an app update is sent through MDM via the installApplication command, the installation does not begin immediately. Instead, the update starts only after the device is locked. However, since these kiosk devices are running continuously, they are rarely locked, preventing the app update from occurring. To force the update, administrators need to manually remote lock or physically lock the device, which is a time-consuming process. This becomes even more challenging for devices like Apple TV, where remotely locking and unlocking the device to complete app updates is especially difficult, making it hard to keep the apps up to date in a timely manner. Issue 2: User Cancellations of Critical Updates on Non-Kiosk Devices In the case of non-kiosk devices, customers are encountering another challenge: when a critical update is pushed during business hours, users are often prompted to install the update. However, many users tend to cancel the update, leaving devices unpatched and potentially vulnerable. This behavior can delay the deployment of important security patches, which is a critical concern for organizations managing sensitive data or business-critical apps. Request for a Solution Our customers have expressed the need for a more reliable and forceful app update mechanism. Specifically, we are requesting the following features to improve the app update experience: Scheduled app updates: The ability to schedule app updates, similar to the way OS updates are handled. If the user does not install the update within a specified timeframe, the update should begin automatically or prompt the user with a stronger reminder. Force install option: A feature that would allow MDM administrators to force an app update immediately, without relying on user intervention. This would ensure that critical updates are installed promptly, improving security and system stability across all devices. These features are essential for many of our customers who rely on timely and consistent app updates to maintain security, functionality, and compliance across their managed devices. Without these options, they face challenges in ensuring devices are kept up-to-date, which can result in security vulnerabilities and operational disruptions. We kindly request that Apple consider adding these functionalities to improve the MDM app update process and provide a more reliable experience for both kiosk and non-kiosk device management. Thank you for your attention to this matter. We look forward to your feedback and any potential improvements in future iOS updates. Raised in the same manner as feedback: FB15910292

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.

I'm reaching out to discuss a significant issue related to how iOS handles app login sessions, particularly in the context of MDM (Mobile Device Management) and the Outlook app. In our organization, we use MDM to distribute applications, including Outlook, with certificate-based authentication for BYOD (Bring Your Own Device) devices. This setup allows users to log in seamlessly to their accounts. However, we've encountered a concerning behavior: when a user unenrolls from MDM, which automatically removes the distributed apps and certificates, they can later reinstall the app from the App Store and find themselves automatically logged back into their previous accounts without any authentication prompts. Here’s a detailed breakdown of the situation: Initial Installation: Users enroll their devices in MDM, which installs the necessary apps and certificates on those devices. Session Storage: After the initial login, the app stores the session locally on the device. App Deletion: When users un enroll their devices from MDM, it automatically removes the distributed apps and certificates. Reinstallation: Days or weeks later, when they reinstall the Outlook app from the App Store, they find themselves automatically logged back into their accounts. This behavior raises important concerns: Lack of Authentication: The app retaining user sessions even after deletion allows users to access their accounts without re-authentication, which could lead to potential unauthorized access and undermines the effectiveness of certificate-based authentication and two-factor authentication (2FA). Note: This issue is not limited to Outlook; we've observed similar behavior with many other apps. Need for a Solution - Given the implications of this behavior, we are looking for effective solutions to prevent it. Specifically, we need options within the MDM framework to: Restrict Session Retention: Implement settings that ensure any app deleted via MDM will lose all stored sessions and require re-authentication upon reinstallation. Default Settings for MDM-Distributed Apps: Ideally, this would be a default feature for all apps distributed through MDM, ensuring that user sessions are not retained after app deletion. Has anyone else experienced this issue? Are there any existing settings or workarounds within MDM platforms to mitigate this problem? Your insights and experiences would be invaluable as we navigate this challenge. Thank you!

Hi Apple Team , We have a. Bunch of macOS devices in our Fleet Which has MDM Passcode Payload Applied. We have observed a huge delay in unlocking the user account at login Screen after the Credentials are presented, Where as Removing the Passcode Payload makes the User to unlock their account at login Screen Immediately. Can someone help with this issue any OS Updates helps this ? Have Filed a FeedBack: FB15143190 (MDM Passcode Payload Causing Delay In Device Unlock) Also there is a Discussion reg this Passode Policy Issue

When syncing newly added or modified devices in the Apple Business Manager (ABM) portal using the POST request to https://mdmenrollment.apple.com/devices/sync, we are getting an issue when the ABM server account has more than 1000 devices. The response consistently includes 1000 devices, with the ‘more_to_follow’ flag always set to true and the ‘cursor’ value changing. However, subsequent ABM syncs for other devices result in duplicate devices being included in the response, and the ‘more_to_follow’ flag never becomes false. As more_to_follow is always true, we try to hit api continuously. Please refer this for sync API details which is causing issue: https://developer.apple.com/documentation/devicemanagement/sync_the_list_of_devices This issue appears to originate from the Apple ABM side. Any help would be of great use. Thanks in advance.

When making a GET request to the ABM Account API at https://mdmenrollment.apple.com/account, we receive a response that includes an org_email field. However, we’ve noticed that the value of org_email varies. Sometimes it corresponds to an account with the role of Administrator, while other times it comes from account with roles Device Enrolment Manager, Content Manager and People Manager. We seek clarification on the following points: Which roles determine the org_email sent in the response? Is the org_email coming in API response always same or does it change when we hit the APIs in multiple times. org_email in this response: https://developer.apple.com/documentation/devicemanagement/accountdetail