Zero Touch Enrollment Network Specifications
Hello! I'm looking for information regarding the network specifications for the Zero Touch Enrollment as well as any phone-home network requests. Are there any logs we can pull from ZTE or the Android device during enrollment? The reason I'm asking: We have thousands of devices that have been enrolled in SOTI MobiControl over the last few years, and about 1000 of these were enrolled via ZTE. We've had no issues with this until early March. I can't find a rhyme or reason for this, but certain devices that were successfully enrolled, configured by an MDM, QC'd, boxed up, shipped to the end user, and then powered on will get the message below before the eSIM is activated. These are Honeywell CT47 devices with dual SIM cards (1 physical Nano SIM and 1 eSIM). The device above was added to ZTE using the IMEI number over a month ago and was successfully enrolled, but when powered on later and connected to Wi-Fi, it reset itself before the eSIM could be activated. This issue is only happening to devices that are factory reset while on-site and connected to the Wi-Fi only. My best guess is that the Wi-Fi network is blocking something during the enrollment process, as this reset issue is not happening on devices that have been enrolled and working for months. Thanks for your time!
Restoring Data on a Fully Managed (Device Owner) Android Device During Enrollment
Hello everyone, I’m testing the setup (enrollment) of a Device Owner / Fully Managed Android device, and I’ve run into a question about restoring data. When setting up a personal Android device, you typically get the option to sign in with a Google account and restore apps/data from a backup. However, when I try this on my test device with the fully managed (Device Owner) enrollment flow, it goes straight into the MDM provisioning process. I don’t see the Google sign-in page or any option to restore data from my Google backup. My questions: Is this the expected behaviour for Device Owner (fully managed) setups? Are there any official guides or best practices for restoring user data in this scenario (if supported)? Thanks in advance for any guidance or documentation links!
Enrollment failing - Could not update Webview
We have reports of devices no longer being able to enroll. Our policy has a FORCE_INSTALL of Android Webview (com.google.android.webview), with a minimum version set to 593815300. Reproduced here with an Acer ACTAB10KB24. If I remove the minimum version requirement, I can enroll the device, and also update the webview to 139.0.7258.158. Why isn't the configuration with minimumVersionCode set working? We have previously enrolled many of these, but from our logs the latest successful enrollment was on the 16th of August (2025).
Custom app installation with AMAPI
Thanks to the keen eye of jasonbayton for spotting this update in the documentation: https://developers.google.com/android/management/manage-custom-apps The lack of this feature has been a key reason I've avoided any AMAPI based EMM (looking at you Intune!) for fully managed device deployments. This is certainly a welcome enhancement to AMAPI and one that I'm honestly surprised Google delivered on. I think I can finally see the writing on the wall that Custom DPC will eventually now die given that AMAPI is finally catching up. I still need file system push and pull for it to truly be a replacement but this is a major step in the right direction. What are the community thoughts on the matter?
Need explaination of following feature implementation for AER -3.19. Application track management
I have implemented the following feature and I can set application track from my emm console but not understand what to show for validation or how it will further works after set app track info. Thanks in advance.
