I created a mobileconfig file on our self-developed MDM server and used Apple Configurator with a USB cable to prepare the device.
However, the profile installation failed and show the mdm payload is invalid must to be removed.
I suspect that the issue might be related to the CA (Certificate Authority) in the configuration, even though I have provided the ROOT SSL CA and the .p12 file.
What CA file should I include in the mobileconfig to resolve this issue?
using Apple Configurator to edit the mobileconfig file, but the MDM service is no longer displayed. How should I handle this
Device Management
RSS for tagAllow administrators to securely and remotely configure enrolled devices using Device Management.
Post
Replies
Boosts
Views
Activity
On devices running iOS 18+, when a web app kiosk policy is pushed via an MDM and the device is restarted. The touch screen doesn't respond on the device. So the device is currently in a brick state. Since we can't enter the password we can't get the logs from the device and it is even hard to recover the device. On restart the device isn't connecting to the internet so it isn't possible to remove the kiosk policy as well. This only happens on devices running iOS 18+ and with web app kiosk profile.
I have the following setup:
Managed domain (pdfforge.org)
Managed app (Dropbox) with Files app integration.
This can also occur with the following setup:
A custom browser is installed as managed (ex Firefox)
No managed domains
Managed app (Dropbox) with Files app integration.
Trying to upload a file from Dropbox in this managed domain by clicking on the Dropbox folder causes the folder to disappear and instead I am rerouted to the On My Phone directory.
On subsequent tries, sometimes the folder opens and I can see the files, but while scrolling the files disappear.
This makes it unable to upload any files from Dropbox to this managed domain.
If both the managed app and domains are not set up, then everything works normally.
Is this happening to everyone else? I also tried with Nextcloud and Google Drive.
We're implementing an MDM system and would like to know if we can get the type of CPU for an enrolled device, I know we can use IsAppleSilicon from the Device Information command but it would be good to know if it's an M1, M2, M3 etc.
We can implement a mapping of product name to CPU type, e.g. Mac16,1 has an M4 chip but this would mean ongoing maintenance that we'd prefer to avoid.
Is there a public web API (ideally first-party provided by Apple) that can be used to lookup details of a device by product name or similar?
Slightly related is the Declarative Device Management documentation for StatusDeviceModelMarketingName offers an alternative of:
use device.model.configuration-code to look up the marketing name through the web API
but doesn't mention which web API.
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
We have a development where we are MDM managing iOS devices and attempting to enforce mutual TLS for all interactions with the MDM. We are DEP provisionng an enrolment profile that utilises an ACME hardware attested Device Identity Certificate. All interactions with the MDM endpoints are correctly utilising the ACME certificate for the client mutual TLS handshake. The certificate has Client Authentication Extended Key Usage.
Behind the same API gateway and on the same SNI we are also serving paths to Enterprise application manifests and IPAs. We can see from the phone log and from packet traces the iOS device doesn't offer the Device Identity Certificate for client authentication when retrieving these URLs. We have also tried adding non ACME client certificates from the root trusted by the server to the initial profile with exactly the same outcome.
If we temporarily disable the mutualTLS we can see that the request for the manifest has a userAgent of
"com.apple.appstored/1.0 iOS/18.2 model/iPhone17,3 hwp/t8140 build/22C5125e (6; dt:329) AMS/1"
which is not the same as the mdm interactions. Is it actually possible to achieve mutualTLS to authenticate these downloads or is a different solution required ?
Any advice greatly appreciated.
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
Hello
We extend the program every year, but after we sent a request for extension we do not receive a response. Our program is ending 23 november and we really need to extend it. We created 2 requests, but we did not receive a response to them either. How can we speed up the decision?
Would it be possible to prevent deletion of specific apps on iOS devices using MDM.
We provide a MDM product.
In our product, payloads and properties which require supervision display those requirements.
Two properties forcePreserveESIMOnErase and allowWebDistributionAppInstallation of the restriction payload don’t require a supervised device according to the descriptions in Apple Developer Documentation.
However, in our observation, those properties seem to require it.
Are those OS bugs or documentation errors?
(In which category should I submit a feedback?)
Steps to reproduce
Prepare a supervised device (I used an iPhone 12 mini with iOS 18.1) and a configuration profile contains the following restrictions:
<!-- Does not require a supervised device -->
<key>allowDiagnosticSubmission</key>
<false/>
<!-- Requires a supervised device -->
<key>allowESIMModification</key>
<false/>
<!-- Does not require a supervised device according to its description -->
<key>allowWebDistributionAppInstallation</key>
<false/>
<!-- Does not require a supervised device according to its description -->
<key>forcePreserveESIMOnErase</key>
<true/>
Then,
Install the profile with Apple Configurator.
Confirm 4 restrictions are shown in Settings > General > VPN & Device Management > PayloadDisplayName > Restrictions.
Punch Settings > General > Transfer or Reset iPhone > Erase All Content and Settings, to unsupervise.
Install the profile with Apple Configurator. It cannot be installed automatically because the device was not supervised.
Manually install the downloaded profile.
Check Settings > General > VPN & Device Management > PayloadDisplayName > Restrictions.
Expected results
3 restrictions—allowDiagnosticSubmission, allowWebDistributionAppInstallation and forcePreserveESIMOnErase—are shown.
Actual results
Only one restriction—allowDiagnosticSubmission—is shown.
Appendix: Restriction keys and their restricted message shown in Settings
allowESIMModification: eSIM modification not allowed
forcePreserveESIMOnErase: Preserve eSIM on erase enforced
allowWebDistributionAppInstallation: Web app distribution not allowed
allowDiagnosticSubmission: Diagnostic submission not allowed
I’m looking for advice on implementing an Active Supervision Mode for enhanced parental control. My goal is to restrict access to both iOS system apps and third-party applications to create a safer and more tailored digital experience for my child.
Here’s what I’d like to achieve:
App Restrictions: Block specific apps (both iOS and third-party) and allow access only to approved ones.
Time Limits: Set daily usage limits for individual apps or app categories.
Content Filtering: Apply restrictions to block inappropriate content and age-inappropriate apps.
Remote Management: Manage these settings remotely from my device for added convenience.
Activity Monitoring: View app usage stats or receive alerts for policy violations.
I understand that Screen Time on iOS offers basic parental controls, but I’m exploring whether iOS supports more advanced capabilities natively or through additional configurations.
I’ve also heard that enrolling a device in Apple Business Manager (ABM) and linking it to an MDM (Mobile Device Management) solution might provide greater control. If this is a viable solution, could anyone provide guidance on:
Enrolling a personal or family-owned device into Apple Business Manager.
Linking an MDM for configuring app restrictions and monitoring usage.
Alternatively, if there are third-party parental control apps that work seamlessly with iOS to achieve these goals, I’d appreciate your recommendations!
Thanks in advance for your insights!
I’m looking for advice on implementing an Active Supervision Mode for enhanced parental control. My goal is to restrict access to both iOS system apps and third-party applications to create a safer and more tailored digital experience for my child.
Here’s what I’d like to achieve:
App Restrictions: Block specific apps (both iOS and third-party) and allow access only to approved ones.
Time Limits: Set daily usage limits for individual apps or app categories.
Content Filtering: Apply restrictions to block inappropriate content and age-inappropriate apps.
Remote Management: Manage these settings remotely from my device for added convenience.
Activity Monitoring: View app usage stats or receive alerts for policy violations.
I understand that Screen Time on iOS offers basic parental controls, but I’m exploring whether iOS supports more advanced capabilities natively or through additional configurations.
I’ve also heard that enrolling a device in Apple Business Manager (ABM) and linking it to an MDM (Mobile Device Management) solution might provide greater control. If this is a viable solution, could anyone provide guidance on:
Enrolling a personal or family-owned device into Apple Business Manager.
Linking an MDM for configuring app restrictions and monitoring usage.
Alternatively, if there are third-party parental control apps that work seamlessly with iOS to achieve these goals, I’d appreciate your recommendations!
Thanks in advance for your insights!
Hello everyone.
Until macOS 14.x Sonoma, the Configuration Profiles, were hosted in System Preferences / Privacy & Security / Profiles.
Now, in macOS 15.x, they are hosted in System Preferences / General / Device Management.
The thing is, we need to hide this panel since it shows the initial password of a LAPS account to any user.
I have seen that in developer.apple.com in the Profile-Specific Payload Keys section, the object SystemPreferences have been Deprecated, and these are the ones we used until now to lock this panel, so it does not work anymore.
So that only the objects Restrictions works, in which it does not show any to block the Device Management panel.
Does anyone know how to hide/lock the new Device Management panel in System Settings?
Thank you very much!
Translated with DeepL.com (free version)
Hello
Is there any official source from Apple listing all their models with their respective specs (mainly storage and device color)?
Third party open source exist, but it's incomplete, and we'd like to use an official source.
EG https://theapplewiki.com/wiki/Models
No "ML9C3" in that site.
We use a profile that delays the installation of the new system in order to test it earlier.
Well Sequoia works differently and fails with our system, the manufacturer tells us to talk to Apple.
Does anyone have any idea about this?
My MDM is Mosyle
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.
We are pushing some Chrome settings through Directory Services command line utility /usr/bin/dscl
/usr/bin/dscl /Local/Default -mcximport /Computers/local_computer chrome_settings.plist
/usr/bin/mcxrefresh -n root
These commands created com.google.Chrome.plist in /Library/Managed Preferences on previous macOS versions.
However on macOS 15.x Sequoia these commands intermittently fail to create the file in /Library/Managed Preferences though there is no error reported or any log entries that could indicate an error.
There could be other component on Sequoia that is preventing directory services tool to push the preferences but I am unable to locate it. It is not MDM because the machines are not enrolled (also have a setup where dscl and MDM both work).
This is happening on a clean macbook setup but I have never seen it happen on mac mini.
Anyone have an idea what could be interfering with directory services to complete its task of pushing managed settings? DDM?
I'm developing an ACME server to issue identity certificates to macOS/iOS devices for MDM attestation, following RFC 8555. Per RFC, the client creates an order, performs authorization, verifies the challenge, and finalizes the order by submitting a CSR to the CA.
In my setup, the CA sometimes takes longer to issue the certificate (around 50 seconds). According to RFC 8555, if certificate issuance isn’t complete after the /finalize call, the server should respond with an "order" object with a "processing" status. The client should then send a POST-as-GET request to the order resource (e.g., /order/<order_id>) to check the current state. If the CA still hasn’t issued the certificate, the server should return the order object with the same "processing" status and include a "Retry-After" header, indicating when the client should retry. The client is expected to poll the order resource at this specified interval with POST-as-GET requests.
However, it seems the Apple ACME client ignores the "Retry-After" header and instead returns the error: "Profile failed - Order status is processing, not yet valid" immediately upon the first poll response with "processing." Apple ACME client deviating from the RFC documentation.
Has anyone found a reliable solution to this issue? Or does Apple supports asynchronous order finalization?
Ref -https://datatracker.ietf.org/doc/html/rfc8555#:~:text=A%20request%20to%20finalize%20an%20order%20will%20result%20in%20error,to%20the%20%22certificate%22%20field%20of%20the%20order.%20%20Download%20the%0A%20%20%20%20%20%20certificate.
To work around this, I’m holding the /finalize call until the CA issues the certificate. This works when issuance is quick (under 20 seconds), but if it takes more than that , the client times out. Interestingly, the Apple ACME client’s timeout appears shorter than the usual 60-second URLSession default.
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!
Hello everyone, our company has an annual fee of $299 for an enterprise developer account, which is about to expire next month, but I submitted the renewal application, but after a month, I received an email that refused to renew the subscription. Is there any remedy for this? This account is very important to our company. Thank you