Unlinking Zero Touch Account from deleted Enterprise
Hi, we are currently trialing automatic device enrollment using a Zero Touch Account and baramundi Management Suite as our EMM solution. It all worked well, until I deleted the Android Enterprise account before unlinking it from our Zero Touch account. When I now try to create a new enterprise and link it to our Zero Touch account, it says that it's already linked and I can't proceed to the actual Zero Touch console within the iFrame in the EMM. Sadly I can't change the display language for the iframe. It says "Choose accounts to be linked" and the light grey part next to the checkbox says "already linked". I'm only presented the option to go back and choose another Google account. There doesn't appear to be an option on the web portal version of Zero Touch (https://enterprise.google.com/android/zero-touch/customers/) to unlink the enterprise either. When I try to delete the enterprise it warns me to unlink the Zero Touch account before proceeding and tells me that all enterprise related data will be deleted after 30 days. So my question is: Is there another way to unlink the enterprise from the Zero Touch Account or do I simply wait for 30 days and then the link is deleted automatically? Peter
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.
Play Store number of downloads counter
Hi all, Just had a question which might seem quite easy, but couldn't find the answer. I wonder how the number of downloads accompanying an application in the Play store compares to the number of downloads not done manually by a user, but downloads based on apps pushed from an EMM. For several applications, I see relatively low numbers of downloads in the Play store. Based on these low numbers, I can practically guarantee that downloads via Managed Google Play are not included here. In itself plausible, but I have not been able to read anywhere in documentation whether or not this is correct, can anyone confirm this. At the same time if MGP downloads do not count towards the number of downloads listed in the Play Store with the app, are MGP downloads counted separately somewhere? Thank you in advance, Tom
Is there an alternative way to perform the same function as UpdateApplication on Android 15?
Hi everyone, We are currently managing Samsung enterprise devices via Knox Manage under Android Enterprise DA mode (Device Admin) . Our in-house application previously used the UpdateApplication API to update itself silently without user interaction. This worked well under Android 14. However, after updating to Android 15, this API no longer functions. Based on the Samsung Knox SDK documentation, it appears that UpdateApplication is now restricted to Device Owner (DO) and Profile Owner (PO) apps. We have tried to assign all delegated scopes to our app via Knox Manage policy settings (Android Enterprise → App Restrictions → Delegated Scopes for Apps). Unfortunately, the API call still fails. ✅ What we’re looking for: - Is there any alternative methods that allows silent or managed updates of enterprise apps on Android 15, without being a DO/PO app? - Or is DO/PO elevation now the only viable path? - If so, is there an official onboarding flow or protocol to request DO/PO designation for an app via Knox Manage? Any guidance, references, or examples would be greatly appreciated. Thank you! — Environment: - Android 15 - Knox Manage (latest) - Samsung A9+ tablets - Device Admin mode
Impact of Intune's NFC restriction setting on IC card reading and Nearby Share
Hello, I'm managing Android Enterprise devices via Intune and would like to confirm the behavior of a specific device restriction setting related to NFC. ■ Device: AQUOS wish4 (Android), enrolled as a fully managed device ■ Policy applied: Device configuration profile with "Beam data using NFC (work-profile level)" set to Block ■ Policy configuration path in Intune Admin Center: Microsoft Intune Admin Center > Devices > Manage devices > Configuration Platform: Android Enterprise Profile type: Template > Device restrictions Configuration settings > General - Beam data using NFC (work-profile level): Block ○ Background and expectation: My understanding is that this setting is intended to block NFC-based data transfer (i.e., Android Beam) within the work profile. However, I initially assumed it might also block general NFC usage, such as reading contactless transit cards or using mobile wallet services. ○ Test scenario and results: After applying the policy to a fully managed AQUOS wish4 device, I observed the following: The NFC toggle remains available and functional under: Settings > Connection settings > More connection settings > NFC I installed an app that reads contactless transit cards used for public transportation (e.g., Suica or PASMO in Japan) and confirmed that it successfully retrieved the card balance via NFC ○ Interpretation: Based on this behavior, I suspect that the policy only affects the deprecated Android Beam feature, which used NFC for peer-to-peer file sharing. It does not block general NFC functionality such as card reading or mobile payments, nor does it impact newer sharing technologies like Nearby Share or Quick Share, which rely on Bluetooth and Wi-Fi Direct. ■ Questions: Is my understanding correct that "Beam data using NFC (work-profile level)" only restricts Android Beam functionality and does not affect general NFC usage? Is there a way to restrict Nearby Share / Quick Share on fully managed Android devices via Intune, or would that require a different configuration or approach? Any insights, documentation references, or shared experiences would be greatly appreciated. Thank you!
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" }
Android Enterprise BYOD not honoring auto-connect setting for WiFi
Hi, We have an issue in our tenant with BYOD device enrollment (Personally owned with Work Profile). We use Intune as EMM. We want to push a WiFi policy to our devices but we do not want to preconfigure auto-connection for our users. Our users must manually connect to the network. The problem is that this setting is not supported for BYOD in Intune, so we have no control over it. In addition, the default behaviour of the devices (tested in Realme, Xiaomi, Nokia, Google, Samsung phones) is that autoconnect is enabled by default. Even if the user disables it, next Intune sync enables it back. Finally, I checked the policy via graph API and I see that: "connectAutomatically": false, "connectWhenNetworkNameIsHidden": false, "wiFiSecurityType": "wpaEnterprise", Is this setting not honored by the OS? Is there anything we can do about it?
Barcode setup without ENROLLMENT_TOKEN
Hi We are preparing to enroll over 600 Zebra and Honeywell barcode scanners into Microsoft Intune. These devices are distributed across more than 250 locations and span over 35 distinct configuration profiles. To ensure a smooth rollout, especially for our non-technical users, we aim to automate the enrollment process as much as possible—minimizing manual input and reducing the risk of user errors, including Wi-Fi setup. Our intended workflow is for users to simply scan a QR code at the initial "Hi there" screen. This QR code should contain the necessary Wi-Fi configuration and trigger device provisioning via the Google Zero-Touch portal, bypassing the setup wizard entirely. However, when we generate a QR code using the following JSON configuration, the Wi-Fi settings are not being applied as expected. After the QR code is scanned, the device proceeds to the Wi-Fi setup screen, where users are required to manually enter the network configuration. According to Google’s documentation, the EXTRA_ENROLLMENT_TOKEN is optional. Is it possible to fully automate this step without including the token, or is it required in practice for the Wi-Fi configuration to be applied correctly? Any help would be much appreciated—thank you! { "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver", "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg", "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup", "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": { "android.app.extra.EXTRA_PROVISIONING_WIFI_SSID": "**SSID**", "android.app.extra.EXTRA_PROVISIONING_WIFI_PASSWORD": "**PASSWORD**", "android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE": "WPA", "com.google.android.apps.work.clouddpc.extra.EXTRA_PROVISIONING_SKIP_USER_CONSENT": true, "com.google.android.apps.work.clouddpc.extra.EXTRA_PROVISIONING_SKIP_USER_SETUP": true, "com.google.android.apps.work.clouddpc.extra.EXTRA_PROVISIONING_SKIP_ACCOUNT_SETUP": true, "com.google.android.apps.work.clouddpc.extra.PROVISIONING_SKIP_EDUCATION_SCREENS": true } }How to become an Android EMM partner
Now we have completed the development of the full management function of Android devices based on the Android Manange API. Now we hope to become a Google partner to promote our products. What should we do? Currently, we are trying to register at: https://www.androidenterprise.dev/s/. After clicking "Resume Onbording", we are asked to enter our email again, but we have never received it.
