Intune - Swapping Managed Google Play Account with Devices enrolled in Device Administrator and AOSP
Hi All, My Intune environment is connected with an old-school gmail.com account - i access the managed store page by going to https://play.google.com/work to approved apps / etc. - This was an old solution that saw little to no use. We're now looking at requiring Intune enrollment on our android devices and it'll get a ton of use once we do that. I'd like to upgrade my account to an Android Enterprise account, but it looks like to do that I'll need to disconnect the Managed Google Play account from Intune. My understanding is that I will need to un-enroll all my android devices from the tenant before doing that. For personally owned devices with work profiles, that's not a problem - we only have 3 PoC users that I can unenroll. The only other two enrollment options we use are Device Administrator (For Yealink teams phones...) and AOSP (For.. newer.. Yealink teams phones). Will disconnecting Managed Google Play affect the enrollment of Device Administrator or AOSP? Thanks!
Common identifier between AMAPI & Require for setup app for validation
We are enrolling devices using AMAPI by generating a QR code with an assigned policy either for work profile or fully managed enrollment. During enrollment, the device prompts for a require for setup app, which, after configuration, returns RESULT_OK, marking the setup as complete and finalizing the device enrollment. Before returning RESULT_OK, To identify the enrolling device, the backend gets the device ID and enterprise ID from the Pub/Sub provisioning notification. The device ID (which matches the GSF ID) is then sent by the require for setup app to the backend for validation. This identifier is also used to enforce enrollment limits based on the enterprise license count. The Issue: Up to Android 14, retrieving the GSF ID was possible. However, in Android 15, it now returns null. Question: Is there an alternative identifier that can be used to identify the enrolling device—one that the backend can retrieve and that the setup app can also access during enrollment? Below is the information we receive from Pub/Sub when a device is enrolled: { "name": [*Hidden for privacy reasons] "managementMode": "PROFILE_OWNER", "state": "PROVISIONING", "enrollmentTime": "2025-04-04T06:17:02.751Z", "lastPolicySyncTime": "2025-04-04T06:17:02.817Z", "softwareInfo": { "androidVersion": "15", "androidDevicePolicyVersionCode": 10323580, "androidDevicePolicyVersionName": "128.32.3 (10323580)", "androidBuildNumber": "AP3A.240905.015.A2", "deviceKernelVersion": "5.15.149-android13-8-00010-gc2e0ba41ba85-ab12040008", "bootloaderVersion": "unknown", "androidBuildTime": "2025-03-11T13:26:50Z", "securityPatchLevel": "2025-03-01", "primaryLanguageCode": "en-IN", "deviceBuildSignature": "c9009d01ebf9f5d0302bc71b2fe9aa9a47a432bba17308a3111b75d7b2143456", "systemUpdateInfo": { "updateStatus": "UP_TO_DATE" } }, "hardwareInfo": { "brand": "Redmi", "hardware": "mt6835", "deviceBasebandVersion": "MOLY.NR17.R1.TC8.PR2.SP.V1.P51,MOLY.NR17.R1.TC8.PR2.SP.V1.P51", "manufacturer": "Xiaomi", "serialNumber": [*Hidden for privacy reasons] "model": "23124RN87I", "enterpriseSpecificId": [*Hidden for privacy reasons] }, "policyName": [*Hidden for privacy reasons] "memoryInfo": { "totalRam": "5865836544", "totalInternalStorage": "806965248" }, "userName": [*Hidden for privacy reasons] "enrollmentTokenName": [*Hidden for privacy reasons] "securityPosture": { }, "ownership": "PERSONALLY_OWNED" } *Updated by Community admin - removed due to privacy reasons 4 April
GSF ID not generated after device enrollment on Android 15
Hi everyone, We’re facing an issue with devices running Android 15 — after successfully enrolling them in our Android Enterprise setup (Device Owner / Fully Managed mode), the Google Services Framework (GSF) ID is not being generated. This issue did not occur on Android 13 or 14; the GSF ID was available immediately after enrollment. However, on Android 15, the GSF ID remains empty even after waiting and rebooting. We’ve already tried: Factory reset and re-enrollment Checking Google Play Services version Ensuring the device is connected to the internet Waiting for Play Store sync Despite that, the GSF ID is still missing. Could anyone confirm if there’s a known change in Android 15 related to GSF ID generation, or if additional permissions/configuration are required for enterprise-enrolled devices to obtain it? Any guidance or workaround would be greatly appreciated.
Android 15 Setup Wizard loops at “Accept Google Services” on Lenovo Tab M11 (TB311FU)
Hi all, I'm running into a blocking issue provisioning brand-new (and factory-reset) Lenovo Tab M11 - TB311FU devices on Android 15 with Android Management API (fully managed / dedicated, kiosk). On Android 14 everything worked fine with the exact same policy and enrollment flow. The issue only started after updating to Android 15. (this is my test device, i constantly factory reset it) Expected behavior: Standard QR (6-tap) provisioning to proceed past the “Accept Google Services” screen, install Android Device Policy, enroll to my enterprise, and apply the kiosk policy, install app, and done. What happens instead: After Wi-Fi and scanning the AMAPI QR token, Setup Wizard reaches “Accept Google Services”. Tapping Accept shows a spinner, then it returns to the same screen (loop). I simply cannot get past this point. If I reboot at this point, on the very first Welcome screen the device sometimes becomes unresponsive (neither 6-tap nor “Next” reacts) until I factory reset again. Is there a known Android 15 Setup Wizard issue that can cause a loop at “Accept Google Services” on Lenovo TB311FU? Any workarounds you'd recommend to get past the acceptance loop? When factory resetting, and setting up the tablet without scanning the qr code, i get past the Google Services no problem. When i install via qr-code on new fresh never used before tablets, that come pre-installed with Android 14, i don't have any issues. Same policy, same everything... except the Android version. Thanks in advance! /BIssues Intune and okta enrollment
Hi all, I could use some help or guidance from someone who has experience with using Okta as IDP and Intune as MDM. The problem: When going trough enrollment (COPE), the Intune login page shows up. When entering the email, it forwards to Okta as it should. But after verifying with Okta, you should get back to a Microsoft confirmation but instead it shows a page not found error. It used to work, nothing has changed as far as we know and the issue is present on devices ranging from Android 13 to 15, different brands but mostly Samsung. Apple and Windows enrollment work as expected, no issues there. I can't find any related logging details in Intune and lack the knowledge of Okta (will add a support ticket there as well). So i'm kind of lost as to what is happening. Where do I need to look for the return URL for example? There are multiple Azure enterprise apps but i'm not sure which one to check and don't want to mess to much with this. Thanks!
Tenant has been unbound from Google Play console (Intune)
Hey @Community, we have a strange issue with out MDM (Intune) - It seems like, the link between Intune and Google has broken. Trying to enroll new devices are failing with "Invalid code". Trying to add new applications via "Managed Google Play" fails also with the message "Tenant has been unbound from Google Play console". Intune-Support says, that we need to contact Google, but there is no option for creating a case. So we decided to write you here (and hopefully you can help us ;) ). We still have the access to the used Google-Account.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!DPC Extras issues
Hello, I hope you're doing well. I'm reaching out for assistance on an issue I'm experiencing with DPC extras on ZTE devices. Is there a method to implement DPC extras without using a QR code? It appears that even when configuring ZTE with DPC extras, some functionalities do not activate. Additionally, several design elements seem less than optimal. For instance, if you do not use a QR code before selecting the language—which, ideally, should be sourced from the DPC—there's an option presented to transfer data from another device. This option seems inappropriate for a company-owned device. Could this be improved? The next screen prompts a WiFi connection. Using a QR code skips this step, but users still need to manually confirm the WiFi connection. Could this be streamlined? Is it possible to enroll a device as an admin, reset it, and have the DPC extras from the QR code persist on the device until it connects to WiFi and verifies its management status? It seems everyone is adding devices to ZTE for security reasons, particularly for stolen devices, yet the reliance on QR codes adds unnecessary complexity. Could this process be made more user-friendly?
Bug? G-board removes additional languages post BYOD Enrollment?
We noticed a strange behaviour, If G-board has additional languages added apart from English like Polish or German, post enrolling into a work profile, the additional languages disappear from the keyboard. I was able to reproduce with Intune, WorkspaceOne and even TestDPC app. This is true even if no Device Restrictions are applied. It seems like a bug. Has anyone else seen this issue?
