problematic re-enrollment following smartphone reset under Android 15
Hey Everyone, Since a couple of weeks, we are encountering a problem with the re-enrollment of devices that have moved to Android 15. our employees arrive on the next screen : I reproduced the incident under the following conditions : Step 1 , the device is enrolled on Omnissa WSP1 in COBO with personnal Google Account Step 2 , for some reasons, the device is erased (example : 10 errors code) Step 3 , the profil in KME or Zero Touch is Microsoft Intune & no more Omnissa Step 4 , It seems that the KME or ZERO Touch verification did not happen at the right time. Step 5 , our employees have to proove the use of the device like a personal device ! We didn't encounter this problem for devices in Android 13 or 14. The devices i used : Motorola g54 5G Android 15 V1TDS35H.83-20-5-5 security patch : 1 july 2025 Samsung A35 - SM-A356B Android 15 AP3A.240905.015.A2.A356BXXS5BYF3 security patch : 1 july 2025 We have several thousand devices left to migrate to Microsoft Intune, this new enrollment behavior is unacceptable for 100% company devices. Our fleet is fully managed in KME or Zero Touch. Can you investigate this incident? Chris
Share your deployment experiences with Android zero-touch enrollment
Hey everyone, In ‘5 Overlooked Benefits of Android Enterprise’, we touched on Android zero-touch enrollment, and it’s something many of you are actively using to streamline your device rollouts. For those in IT, Android zero-touch can be a powerful tool - see our handy guide to learn more. It’s about getting devices to your users ready to go, automatically enrolling in your EMM and pulling down all the right policies as soon as they connect. That means less hands-on time for your team and a smoother experience for end-users. We know real-world deployments always have their nuances, but it would be great to hear about your deployment experiences using zero-touch enrollment: Did you overcome any unexpected hurdles? What was the scale of your deployment - a few devices for new joiners, or hundreds for a company-wide refresh? If you could share one key tip or best practice for someone looking to nail their next zero-touch deployment, what would it be? We’re all here to learn from each other’s stories, and your insights are super valuable. I’m looking forward to reading your stories! Chat soon, Emilie
SCEP and EAP/TLS
Hi Team, I'm so sorry to ask this but it is expected that whenever I select the SSID of a Wi-Fi network that contains a SCEP and EAP/TLS configuration, it will show a popup example below? The policy for SCEP and EAP/TLS are already being configured by third-party MDM and we just assume that we don't need to do this manually on each devices.
Intune - Android Enrollment Default Profile
Hi, We’ve noticed that our Android devices are no longer enrolling automatically, which is resulting in the default profile being applied from the auto-created policy in the Google Zero-Touch customer portal. I’ve reviewed the portal settings, and the correct profile is still assigned by default. This process previously worked as expected. Many thanks, Joe.
Zero Touch Portal - Error Message
Hi Team, I have created a new configuration item and linked it to Microsoft Intune token. Then I have decided to remove the Intune token configuration before removing the configuration file from Zero touch (which I dont think it should matter). Then I went to remove the configuration item from Zero touch and was getting a strange error message, see below. Now I'm left with a configuration item in Zero touch that I can't remove. Can someone please help or reach out, that would be great. Also, let me know if there is anything else you require from my end.Android Enterprise partner registration, portal error
Hi, we are in the process to finish our partner registration. But the step on "Enter a D-U-N-S® number for your organization" fails, with an pop-up error of: Something went wrong! If this problem persists, please contact support. DUNS number is correct. Does the portal have an issue? Thanks
AMAPI Provisioning Stuck on Registration Screen
I'm facing an issue with AMAPI device provisioning. I created a policy, generated a token, built a QR code, and scanned it on a tablet. The device successfully got added under my enterprise (I verified this using the API). However, for the past 2–3 days, while the QR code scanning works, the device gets stuck on the registration screen with a large circular loader for at least 15–20 minutes. After that, I get an option to factory reset the device. Even after the failure message, when I run my script to check for new devices, I can see that the failed device appears under my enterprise. The device's state from the AMAPI response is PROVISIONING. Despite being stuck on the failed screen, I tested sending commands to the device (like reboot and wipe), and surprisingly, they work. This has left me very confused if the device setup failed, how are commands still working? Initially, I thought it might be a device-specific issue, but I tried it on another device (which was never enrolled before), and I’m seeing the same behavior. For reference, here's the structure of the QR payload I’m using: { "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": { "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "20Characters" }, "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver", "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup", "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg" }
