Recent discussions
Device screen sensitivity
Hello AE community, Our users encounter screen sensitivity issue while using a screen proctection on their devices, Device impacted is Samsung A9+, There is a setting to enhance screen sensitivity but it is not manageable thought Ivanti NMDM, or Knox Service Plugin. We also use Bluebird devices, for this manufacturer, sensitity setting is manageable using their OEM Config app. Is there another method to manage this setting ? Should i make a FER (Feature Enhancement Request) to Samsung directly ? Regards Batlac
Set up a new Android Enterprise domain in Intune/EMM when an old-style Google Account is still connected
Hi, I have a situation similar to this older discussion - situation as follows: My EMM is MS Intune. Managed Goole Play Store was set up in April 2024 before the new method of creating Android Enterprise admin accounts on a managed Google domain - using a normal Gmail account This Gmail/Google account was forcibly deleted in the last month, presumably for inactivity, as the first linked discussion describes. Only the final termination email was ever sent to the recovery email, no other warnings were received. Recovery was not possible (it just said that no recovery methods were set up, even though there was a recovery email - hence the warnings...!) and now the account shows as nonexistent rather than potentially recoverable, although it's less than the quoted 30 days that recovery is available. I have seen (Community Manager) Lizzie's helpful posts and advice from a couple of years ago, including this article describing the potential for having support migrate the EMM bind from one account to another. However, I don't yet have another account to migrate to, since I would be moving from an old Gmail account to a new managed domain account - which I don't yet have, as I can't sign up as a 'new customer' to Android Enterprise within Intune, because the old bind still exists, and I haven't found anything to tell me how to sign up other than going through the EMM. I want to keep the old bind active so it doesn't break existing devices, even though I think that's what's stopping me signing up to Android Enterprise in the new way. Removing this existing orphaned bind will break everything, and Lizzie's info in other posts has suggested that the bind will stay mostly-working if left alone, whereas removing it will trigger retirement of all devices. MS/Intune support don't seem to be aware of the possibility of contacting Google support to migrate a bind, but even if they were, I don't yet know what to tell them (as I have no new destination account, of course). They just advise me that it will need a new account and re-enrolment of all devices, which I'm hoping to avoid. I know this is convoluted, but that's why I was hoping for help. Is there a way to get a new Android Enterprise admin account set up, using the new managed domain method, without breaking the existing bind - and then to migrate the bind across? Thanks Dev
Enable third party EMM (Intune)
So I am trying to enable Managed Google Play in Intune to use for Android device management. We already have a managed Google domain, but we have device management turned off. To my knowledge we only use it for Workplace. When I try to enable managed google play in Intune I get two different error messages Any ideas or tips of what we need to enable or open up in the Google admin console to enable third party EMM? Does the account I am using to enable managed google play have to be a google super admin or something?
Android Enterprise Partner Application/Quota Status
Hi, We own and manage an asset management solution used by various clients. Recently (in the last 12 months) we have implemented an MDM/EMM type of solution that uses the Android Management API to enrol/register devices and assist clients with their asset management processes and managing risk through the Android Management API. Now, from an Android Management API perspective, we understand the permissible usage policies and believe we do comply with the requirement. When we originally started the endeavour, the quota on how many device can be registered was a default of 500 devices. We recently noted when some clients try to enrol/register devices, that during the set up process on their devices, that it states that they have reached the usage capacity limits. When we checked the project(s) associated with the clients, most have between 200 - 380 devices enrolled/registered which is below the 500 device qouta. More recently, we noted that the Android Management API permissible usage policies were changed/updated on 29 October 2025 from a default of 500 devices to having to request an initial quota of 500. This means that that enterprises or projects we have recently set up would fail. We submit a request for a quota increase on earlier projects and a request for an initial quota on a new project. This was more than a week, or 7 working days, ago. We also submit an application to become and Android Enterprise Partner on the 12th of November 2025 which we received a response with additional questions about two days later which we responded to promptly. The challenge here is managing client expectations and frustrations in not being able to enroll/register and additional devices, with one client looking to enrol/register over 5000 devices and another prospective client having over 15000 devices. Is there any way we can see the progress on the quota increase/initial quota requests and progress of the partner application or whether there is any other questions or concerns we can remediate to move forward? Its been a challenging week trying to manage our frustrated clients and really want to use the Android Management API and Android Enterprise much more in the future but the limitations are prohibiting us from doing so. Any assistance or perhaps someone we can contact would be appreciated.Do certifications matter when researching new devices?
Hey everyone, Episode 3 of The Secure Element went live last month! Bigdogburr (our go-to security expert) sat down with Brian Wood from Google’s Device Security and Privacy team to unpack how devices get approved for use in the US federal government. Spoiler: it’s not simple! From government-approved labs running tests, to annual re-certifications, to the role of NIAP (National Information Assurance Partnership) — there’s a lot going on behind the scenes to make sure devices are truly secure and trustworthy. When you’re looking at new devices, do you pay attention to security certifications or accreditations? If so, what certifications are you most interested in your region? Or do you focus on something else entirely? Let me know your thoughts below — I’d love to hear how you approach this! Chat soon, Emilie
Issues with use of Personal Digital Certificates on Android Devices Managed via Google Workspace MDM
Hello everyone, I’m reaching out from my company as we have encountered an issue with the installation and use of personal digital certificates issued by FNMT (Spain) on Android devices managed through Google Workspace MDM. The certificates install correctly, but apps that should use them (e.g., for Wi-Fi authentication or access to internal services) do not detect or recognize these certificates. We have tested on unmanaged Android devices, and the certificates work fine there, so it seems related to Google Workspace MDM management. We’ve confirmed with the certification authority (FNMT) that their certificates comply with standards. Google mentioned that MDM should not block certificates unless there is a policy configured to do so. However, this problem seems to persist regardless. Additionally, other companies have reported similar issues with personal certificates issued by different certification authorities, which suggests a possible systemic incompatibility or configuration issue within the Google Workspace MDM environment affecting the proper functioning of these certificates. Has anyone else experienced this? Are there known workarounds or configuration tips that could help? Any insights or advice would be greatly appreciated. Thanks in advance! Francisco
SCEP Certificate Fails with Multiple Root CAs on COPE/COBO (Works on BYOD)
Hi everyone, We're running into a certificate issue with our Android Enterprise deployment and hoping someone here has encountered something similar or can point us in the right direction. We're using Microsoft Intune as our MDM solution with COPE and COBO enrolled devices. This affects all Android devices regardless of manufacturer, including Google Pixel devices running Android 16 with the latest security patch. The devices use SCEP certificates for Wi-Fi authentication. In early September, we rolled out new Root CAs via Intune. These new Root CAs are used for creating SCEP profiles for Wi-Fi authentication. The devices now have both the old, still valid Root CA and the new Root CA installed. The problem occurs when a device tries to obtain a new SCEP certificate issued by the new Root CA. In this case, the Android device attempts to verify the certificate chain using the old Root CA, which fails because the certificate was issued by the new Root CA. As soon as the old Root CA is removed from the device via MDM, the certificate verification works as expected. Interestingly, the entire process works without any problems on Android devices with personal enrollment (BYOD). We've tested creating a new SCEP profile, but unfortunately that didn't help. Only removing the old Root CA solved the problem. The issue now also occurs with BYOD devices as well. Has anyone dealt with a similar situation during a Root CA migration on Android Enterprise devices? We're trying to understand why COPE and COBO devices behave differently than BYOD devices in this scenario, and whether there's a configuration we're missing that would allow both Root CAs to coexist properly during our transition period. Thanks in advance for any help you can provide.
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.
