Android COPE Devices randomly wiping
Hello, Recently our COPE profile in ZT is not functioning. The device will go through the enrollment, it gets registered correctly in our tenant (Entra/Intune) and we can get to the home screen just fine. However, after some time the device will receive the following notification: “Your organization has set up this device to be managed by your organization. If this is an error, contact your device’s provider. All data on the device will be deleted. Your device will automatically reset in 2 hour.” The config in ZT and the one in Intune match (token is correct and the DPC extras are fine). This profile was working up until 2 weeks ago. We’re stumped. We recreated a different COPE profiles with the required DPC extras as per Microsoft’s documentation, tried removing compliance policies and device configurations to make it a plain profile. No luck, still receives the reset notification. Phones tested: Samsung A15, Samsung A16 all running the latest Android 16OS with the latest security patch. Any help would be appreciated, thank you!
Organization Has Reached Its Usage Limits" Error with 0 Devices - Troubleshooting Guide
I'm developing a custom MDM solution using Google Android Management API. Successfully created enterprise enterprises/LC02x32bm6 with work email domain, but getting: "Can't set up device. Your organization has reached its usage limits." Key Details: Enterprise created successfully via API Enrollment token generated successfully 0 devices currently enrolled Cloud Console shows 0% API quota usage Billing account linked to project GET /api/enterprise/callback → Returns enterpriseName POST /api/enterprise/enrollment-token → Returns enrollment token Device enrollment → ❌ "Usage limits" error Has anyone encountered this "usage limits" error with 0 devices? Android Management API usage is 0%. Any insights appreciated! Happy to share code snippets or API responses if helpful.
Update: Device Enrollment Limits - OU Level
Hi everyone, Back in November, we introduced the Device Enrollment Limits TT, designed to help admins better manage ChromeOS license consumption by setting enrollment caps at the Organizational Unit (OU) level. Since then, the feature has continued to evolve, so I wanted to share a quick update with what’s changed. A quick recap LimitOU (Device Enrollment Limits) allows IT Admins to set specific device enrollment caps at the Organizational Unit (OU) level. This prevents a single OU from exhausting the organization's total license pool. What’s new? Delegated admin support - Originally a Superadmin-only tool during the Q3 2025 Trusted Tester (TT) phase, the feature now supports delegated permissions. The Help Center for the TT has been updated accordingly. Granular control - Admins can now manage enrollment limits without requiring full system-wide administrative privileges. Allowlist Requirement: Due to the complexity of the Admin Console integration, the feature requires manual enablement for specific customer domains so members can just respond to the post and request to be added to this trusted tester if they wish. How to Apply Once more, if you are an administrator and would like to be included in this Trusted Tester program to try out Device Enrollment Limits and provide valuable feedback, please simply post a comment below to express your interest!
Issue with Android Enterprise provisioning: afw#identifier invalid and Play Protect blocking app during QR enrollment
We are an organization using a third-party MDM / Device Policy Controller (DPC) solution to manage our Android Enterprise devices. The DPC application is published on Google Play and has been working for managed provisioning. Recently, we started facing issues during Android Enterprise enrollment, and we are seeking guidance on the correct and supported setup. Issues observed 1. afw#identifier enrollment When attempting enrollment using afw#<identifier>, the setup fails with errors such as invalid token, wrong setup, or unable to continue enrollment. This previously worked and now fails consistently, even though the DPC remains published on Google Play. 2. QR code–based provisioning When using QR code provisioning, the device completes initial setup but then Google Play Protect shows “App blocked by Play Protect” for the DPC. The DPC app is Play-approved and not sideloaded by end users. We have already submitted a Play Protect appeal through the official appeal form. 3. Distribution method For QR provisioning, the DPC APK is currently hosted on our own HTTPS server, and the QR includes: Device Admin component SHA-256 signature checksum Secure download location Despite this, Play Protect flags the app after provisioning. Clarifications we are seeking Are there recent changes or requirements for afw#identifier enrollment that could cause invalid token or setup errors? Does Play Protect apply additional checks during QR-based provisioning, even for Play-approved DPC apps? Is using a self-hosted APK download location still supported for Device Owner provisioning, or is Managed Google Play / Zero-Touch enrollment now required? Is there a supported way to allowlist or whitelist a legitimate enterprise DPC app so it is not blocked during provisioning? Are there recommended best practices for third-party MDM providers or enterprise customers to avoid Play Protect blocks during enrollment? We are not attempting to bypass Play Protect or supported security mechanisms. We want to ensure our Android Enterprise setup follows current Google-recommended practices and understand the correct approach going forward. Any guidance or clarification from the community or product experts would be appreciated.
Enable third-party Android mobile management
Hey Android Enterprise community, I'm trying to understand what the "Enable third-party Android mobile management" checkbox in Google Admin does. How does this affect situations where multiple Android Enterprises are bound to multiple EMM solutions? Will both Android Enterprise continue working if they are bound to different EMM solutions, even if only one is selected on the screen above? If I use the Enrollment token link method to provision a device and have no users in my Google Workspace, will switching the EMM provider in the dropdown below the checkbox have any effect? Also, does Authenticate Using Google affect provisioning if there are no users in Google Workspace? Thanks, Marko
ZTE Enrollment Profiles Issue
Greetings everyone! New day, new challenge. I’ve received a number of Zebra tablets. We already use ZTE, which works fine, but as you know it assigns devices to a single profile based on the serial number. The issue is: These tablets (same model) will be used for many different purposes, and I don’t think it’s efficient to take each device out of the box, read the serial number, and manually assign it to a different ZTE profile. I could easily end up managing 200 different profiles. So my question is: Is there a way to let the device choose which group or category it should belong to during enrollment? For example, during setup the device could ask the user which category it belongs to and based on that selection it would automatically join the correct group and receive the appropriate configuration. Is this possible? Or am I dreaming? 😄 Has anyone faced this issue and found a good solution? Thanks in advance!
Intune Migrate Managed Google Play Account to Managed Google Domain
Hi there, I’m looking for clarification on Microsoft's recent update about upgrading tenants from a Managed Google Play account to a Managed Google Domain account in Intune. Intune Android Enterprise Update We have 130+ Android Enterprise devices enrolled in Intune with an old Gmail account we dont have direct access to. Our Intune connection was originally set up using this account back in 2023. Now we have the option to "Upgrade" our account but we need to understand the risks before we proceed. Microsoft says that we can continue managing devices under the new Entra‑linked Managed Google Domain account without deprecating the old method, and without device impact. Is the migration fully in‑place and non-disruptive? Meaning: No need to retire devices No re-enrollment No break in Managed Google Play sync No loss of approved apps or assignments Is this migration guaranteed to perform an in-place transition of the administrative account without: Breaking the existing Android Enterprise binding Generating a new enterprise ID Requiring any user/device actions Interrupting app delivery or policy deployment? Any advice from someone who has already completed the upgrade would be great! Thank you in advance for any clarification.
