We are managing VPP license switching operations using Apple's VPP Manage Licenses API. License information is managed by matching the “clientUserIdStr” data with the VPP account ID information managed on the server side. We received an inquiry stating that a VPP license did not activate despite the activation process being performed. Upon checking the API results, the update API returned a success status during execution. However, the “clientUserIdStr” information was missing from the license information field in the response of the information retrieval API. We kindly request your guidance on the reason why the “clientUserIdStr” information is missing when retrieving license information, and the steps to ensure this information is reliably returned. VPPAccoountId:0123456789abcdef0123456789abcdef adamIdStr:521974902 *Some details have been altered from the actual data to protect personal information.

how can i generate MDM Push Certificate for my own MDM server. Please guide me on that.

Hi Team, As per this documentation Handling NotNow Status Responses | Apple Developer Documentation, the last command that is delivered to the device on a connection should be the one that the device reported NotNow so that the device will automatically retry when it is ready to consume commands. Our question is it possible to have a fixed command which we can try at the end once all commands are tried and if device has reported NotNow for any of the commands. E.g. If there were 3 commands delivered to the device one by one SSO profile (com.apple.sso ) was delivered and device reported NotNow VPN profile (com.apple.vpn.managed) was delivered and the device reported NotNow DeviceInformation command was delivered and the device reported Acknowledged. As there were NotNow responses earlier, can we try a certificate profile(com.apple.security.pkcs1), with a dummy certificate payload, to ensure that the last command delivered to the device in this connection is responded with NotNow. Questions: Can we use a fixed command e.g. certificate profile(com.apple.security.pkcs1) as in above example to ensure the last command delivered to the device has NotNow response. Or is it better to try one of the commands which the device reported NotNow earlier. As in above example should we try the SSO or VPN profile at step 4 instead of the certificate profile? Following up to above, when a device reports NotNow for any profile installation command, can we say it will always report NotNow for certificate profile(com.apple.security.pkcs1) as well for all iOS and MacOS devices?

Hello, I'm working in the team with 70 i(Pad)OS test devices running 24/7, and 40 of them are iOS 18 or 26. The problem is: for enterprise apps to be tested (signed with ADEP inhouse profile) the devices over iOS 18 require Enterprise App developers to be allowed at least once with physical control on-device after reboot, which is quite burdensome because we put all the devices in the restricted area, supposed to be used from the remote. Devices are logged into Apple ID for the prevention of Activation Lock but no preparation nor management via MDM over Apple Configurator 2. Is there any binary, tool, app that can check (letting us allow devices for those developers would be even better) if the Enterprise App developer(s) are allowed for the device via terminal or VNC?

I've account access level of developer. I want to create app specific password but go through the account but could not get any option to do so. Can somebody help me on this. Thanks in advance.

As we know, we can't add restrictions payload in the mobileconfig when registing the device. We are developing MDM by ourselfs, met some trouble. Please help.

We are using an app created with the Apple Developer Enterprise Program within our company. Every year, we recreate and distribute the app in conjunction with the renewal of the provisioning profile. Currently, there are cases where an app that expired in September 2025 is still running, which is causing problems. What could be the cause of this? The app operates on a VPN, but Apple domains are accessible.

Hi, I developed a Platform Single Sign-On extension and a corresponding extension for my IdP, which is Keycloak based. The code for both projects are here: https://github.com/unioslo/keycloak-psso-extension and https://github.com/unioslo/weblogin-mac-sso-extension I realized that, when using the Secure Enclave as the AuthenticationMethod, and according to Apple's documentation, the Extension doesn’t obtain fresh ID Tokens when they expire if the refresh token is still valid. When using password as the Authentication Method, it fetches new ID tokens when they expire, without prompting the user for credentials, by using the refresh token. My suggestion is that the same behavior should be implemented for Secure Enclave keys. The thing here is that usually, on OIDC flows, the ID/Access tokens are short-lived. It would make sense for the extension to provide fresh ID tokens. It doesn’t seem to make sense for me that, when using passwords, the extension would fetch these tokens, and not when having the Secure Enclave key. By not doing this, Apple almost forces the developer of an extension to fetch new ID tokens themselves, which doens’t make sense when it clearly provides fresh tokens when using passwords. It almost forces the developers to either implement that logic themselves, or to issue longer tokens, which is not so nice. How so you deal with this? Do you simply use the refresh token as an authentication token, or do you do some sort of manual refresh on the extension?

Hello together, I'm currently trying to implement a simple way to use the new LOM commands for our new mac infrastructure. My MDM sollution is a custom instance of MicroMDM. MDM profiles are working fine, but when I send a https://developer.apple.com/documentation/devicemanagement/lom_device_request_command with any command (Reset, PowerON, PowerOFF), then it doesn't reset/restart/start the target Mac. Host X has a device profile and host Y a controller profile. Host/Mac Y = fe80::YYYY:YYYY:YYYY:8608 Host/Mac X = fe80::XX:XXXX:XXXX:cfab Now, if I send a LOM request for Mac Y to reset Mac X, I get the error "Address already in use" on Mac X (logs via log stream) log stream (private logs) And wireshark on Mac X shows there is traffic, but MacX does not respond to anything, not even tcp syn packages. This error is really weird, because there are no special ports running on that mac and I don't know what Port lightsoutmanagementd tries to listen to. lsof | grep LISTEN | grep -i ipv6 launchd 1 root 7u IPv6 0x457f571ac3303fd7 0t0 TCP *:ssh (LISTEN) launchd 1 root 11u IPv6 0x457f571ac33015d7 0t0 TCP *:rfb (LISTEN) launchd 1 root 27u IPv6 0x457f571ac3303fd7 0t0 TCP *:ssh (LISTEN) lightsout 112 root 4u IPv6 0x457f571ac3302ad7 0t0 TCP *:55555 (LISTEN) kdc 143 root 5u IPv6 0x457f571ac33023d7 0t0 TCP *:kerberos (LISTEN) screensha 403 root fp.u IPv6 0x457f571ac33015d7 0t0 TCP *:rfb (LISTEN) (fileport=0x2103) screensha 403 root 3u IPv6 0x457f571ac33015d7 0t0 TCP *:rfb (LISTEN) ARDAgent 535 devops 9u IPv6 0x457f571ac33031d7 0t0 TCP *:net-assistant (LISTEN) Did anyone have the same problem, or maybe can hint me in the right direction? I currently don't have a clue, what I can do next.

We've disabled FUS through a config profile, but users can still access FUS by enabling the MenuBar/Control Center icons. My org would like to prevent access to FUS so I've created a config profile. But the profile doesn't seem to work. Anyone have any ideas what I'm missing, or is this an OS bug? <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadDisplayName</key> <string>macOS - Tahoe - Disable Fast User Switching Control Center</string> <key>PayloadIdentifier</key> <string>com.myorg.fast-user-switching</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadScope</key> <string>System</string> <key>PayloadUUID</key> <string>f1a2b3c4-d5e6-7890-abcd-ef1234567890</string> <key>PayloadVersion</key> <integer>1</integer> <key>TargetDevmyorgType</key> <integer>5</integer> <key>PayloadContent</key> <array> <dict> <key>PayloadType</key> <string>com.apple.controlcenter</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>com.apple.controlcenter.57EBEF9E-E568-411E-AE27-500AD98C94F4</string> <key>PayloadUUID</key> <string>f1a2b3c4-d5e6-7890-abcd-ef1234567890</string> <key>UserSwitcher</key> <integer>8</integer> </dict> <dict> <key>PayloadType</key> <string>.GlobalPreferences</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>.GlobalPreferences.71DE1486-60BC-4CB9-890D-AD50A772890D</string> <key>PayloadUUID</key> <string>c5234012-e0sw-2066-6fl8-3bd5p8125op7</string> <key>MultipleSessionEnabled</key> false/> </dict> </array> </dict> </plist>

Hi Apple Community, We are using Automted Device Enrollment to Enroll macOS Devices and we used to Create AutoAdmin, PrimaryAccount using the Command Account Configuration . As a Part of Primary Account Creation while testing we see that BootStrap Token is Escrowed to MDM, and SecureToken is Created to Primary Account. The Primary Account user will enable FileVault as part of our process. As Tested internally, we seen that SecureToken is escrowed to AutoAdmin only when BootStrapToken is escrowed to MDM By device and AutoAdmin logs in then. That too After FileVault Unlock Since we Sendout the Laptop to users to setup themselves there are no chances of AutoAdmin Login to occur. And it defeats the purpose of having the AutoAdmin Account in emergency situation to login into it from Login Window. Can someone confirm if this behavior is expected and what are the expectation and recommendations from Apple on when to use AutoAdmin Account. Is there any other ways to use AutoAdmin directly from LoginWindow Before To FileVault Disk Unlock

Hi everyone, I'm running an Apple MDM service and encountering an issue where a number of devices stop receiving MDM push commands within 10 days of profile installation, even though everything appears to be set up correctly. Environment: MDM profile is installed and verified (status: OK, result: SUCCESS) Devices are cellular-enabled with no connectivity issues APNs certificate is valid (thousands of other devices are communicating normally) The command being sent to devices is DeviceInformationCommand No "NotNow" response or any check-in received from the affected devices for over a week Issue: We send DeviceInformationCommand to devices to retrieve device information and update the last communication timestamp. However, a subset of devices simply stop responding to this command within 10 days of profile installation. The last communication date is not being updated, and no response — not even a "NotNow" — is coming back from these devices. Since other devices on the same MDM setup are working fine, I've ruled out APNs certificate expiration and general server-side issues. Questions: Are there any known management points or configuration settings that could cause a device to silently stop receiving DeviceInformationCommand shortly after enrollment? What diagnostic steps would you recommend to identify the root cause on the device or server side? Are there any known bugs or reported issues related to this behavior in recent iOS versions? Is there any way to recover the MDM communication without requiring the user to re-enroll? Any insights or suggestions would be greatly appreciated. Thank you!

How can we receive the iPadOS 18.6.1 update on an iPad? We have configured the MDM update days policy to receive recent, but not the latest, iPadOS updates; however, we are only able to get versions 18.6.2 and 18.6. Is the availability of iPadOS updates dependent on the iPad's region? Thank you in advance for your assistance.

Hi everyone, I’m sharing this because I’ve been stuck with this issue for over two weeks, and I still haven’t found a solution — or received a meaningful response from Apple Support. A yellow banner has appeared on my account saying: “The Apple Developer Program License Agreement has been updated and needs to be reviewed.” But here’s the problem: I’ve already accepted the latest agreement long ago. When I log into both: App Store Connect Developer Portal …there’s no new agreement to accept, no prompt, no button — absolutely nothing new. The yellow banner simply refuses to go away, and it's preventing updates. I’ve already: Cleared cache & cookies Tried Safari, Chrome, Firefox Logged in from different devices/networks Verified that I am the Account Holder Reported the issue via Apple Developer Support (more than a week ago) Despite clearly stating the urgency of the matter, I’ve received no fix and no timeline. This is beginning to feel like developers’ time — especially for those who depend on timely releases — isn’t being taken seriously. So I’m writing here to ask: 🔹 Has anyone else encountered this same issue recently? 🔹 Is there any known workaround or fix? I’d appreciate any help or shared experience. Thank you.

Hello, this may not be the correct place to ask this question so I apologize in advance if this is the case. I am currently running into two specifc issues while continuing to implement the app.managed configuration which are quite frustrating and I will detail them below Unlike MDM where an application could be "reinstalled", by sending an install application command down for the same app DM does not have a similar mechanism which causes some issues as (while inconsistent) devices do not always respect the configuration sent down, and will not begin downloading VPP applications. They can be seen in the configuration when checking under VPN & Device Management but they do not return on a status report, alternatively and app will "install" but will have a cloud symbol next to it requiring a download (which I believe would be impossible on supervised devices without apple accounts/have restricted apple accounts associated to them). These apps are also reported incorrectly, as they return a managed response while being inaccessible. Both of these issues are solved by removing and reinstall applications (occasionally). Is there any easier way to trigger a re-install or is this the only way to trigger this? The Version element that can be optionally sent down does not seem to work (or if it does, does so inconsistently). A device will very happily download the application initially with the version element present, though when we detect an updated external ID from the VPP program and send down an updated configuration devices behave unexpectedly. Some have ignored it, some have responded back that a download has begun (with no download taking place and the application clearly still being the initial installed version as can be see in the apps page) or it just works, but there is not consistency. I realize a new UpdateBehavior object has been added to possibly handle this, but it is only supported in iOS 26 and above and there are plenty of people who do not have phones that can upgrade that far. Are there alternative ways to enforce an application update other than uninstalling and reinstalling the application without the version (or will sending down a config without a version after one was originally pinned force it to update to latest?) Kind Regards

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

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.

I have come across this Hideable attribute for managed apps, introduced in iOS 18.1, and I've encountered some behavior that seems to contradict the official documentation. According to Apple's documentation for app.managed.yaml, setting the Hideable key to false under the Attributes section should prevent a user from hiding the app. The documentation explicitly states: If false, the system prevents the user from hiding the app. It doesn't affect the user's ability to leave it in the App Library, while removing it from the Home Screen. I have configured this in my app.managed.yaml and successfully applied the profile to my test device via our MDM server. However, I am still able to hide the application from both the Home Screen and the App Library. Here are the steps I'm taking to hide the app: Long-press the app icon on Home Screen Select "Require Touch ID" Select "Hide and Require Touch ID" Authenticate using Touch ID Select "Hide App" After these steps, the app is no longer visible on the Home Screen or in the App Library, which is contrary to the behavior described in the documentation for when Hideable is set to false. My question is: Is this a known issue or a potential bug in iOS 18.1? Or, is there an additional configuration profile or a specific device supervision requirement that I might be missing to enforce this restriction correctly? Any clarification would be greatly appreciated! Thank you!

We are experiencing an issue with Apple Business Manager (ABM) synchronization that is blocking our device management workflow. Issue Description: During the ABM sync process in our MDM, we receive the error: "ABM Terms and Conditions not signed." What We’ve Checked: Logged into the ABM portal as the Administrator and confirmed that the latest Terms and Conditions. Attempted to renew the ABM token on our existing server, but the same error message continues to appear in MDM. Tried creating a brand new ABM server integration, which also fails with the same error. We checked with our MDM provider and they shared the logs, response received from ABM. It says T_C_NOT_SIGNED. But we have already accepted all the new Terms in ABM. We would appreciate any help in resolving this issue or guidance on what steps to take next.

The profile expiration date is approaching, and no amount of inquiries will solve it. Create a new profile Download a new profile from Xcode Press archive, press Distribute App, press Enterprise, and distribute Invalid expiration date in profile of summary of review app.ipa content I've tried everything that comes out by Googleing profiles, such as regenerating profiles, erasing caches, updating Xcode, updating macOS, deleting existing profile information, etc. Expiration date different from the expiration date of the profile created in that menu is displayed. The expiration date of the profile I created is December 8, 2026, and the previous certificate is January 22, 2026. However, the profile information of the generated ipa is February 12, 2026. So I can't distribute this app because I'm scared, and the expiration date is coming up. Users should have a period of time to update. Get me a novice developer who's choking up.