Recent discussions
[Day 2] Mission Intune : When Migration Becomes a Mission (Almost) Impossible
Good Morning Everyone 🕵️ Deep within the digital infrastructure, a high-stakes mission is being prepped. Five mobility experts have been deployed to solve a massive puzzle: migrating tens of thousands of smartphones to Microsoft Intune. The Goal: Ensure a fluid, secure, and uninterrupted transition for thousands of users. The Battlefront: A complex landscape filled with legacy policies, mixed configurations, and strict deadlines. It’s a race against the clock where one wrong move could start a domino effect. From scripts to security protocols—nothing is left to chance. Failure is not an option. Following Broadcom’s acquisition of VMware in 2023, the Workspace ONE product is now owned by Omnissa. Broadcom’s commercial strategy, which has influenced its spin-off companies, had become highly aggressive toward all customers. Consequently, we have decided to migrate the management of our Android and iOS tertiary fleet to Microsoft Intune.. While we are familiar with Intune, several limitations should be noted: Reporting: Intune offers basic reporting through Microsoft Endpoint Manager and Power BI integration, but lacks the advanced, customizable dashboards available in Workspace ONE. Deployment Performance: Application and configuration deployments can be slow, with status updates often delayed due to Intune’s reliance on periodic device check-ins rather than real-time communication. iOS Management: Intune provides full functionality only for devices enrolled via Apple Business Manager (ABM). Non-ABM devices have restricted supervision capabilities, limiting advanced configuration and app deployment. Error Handling: Intune does not display granular error codes in its console. Troubleshooting often requires log collection from the device or use of Microsoft Support tools, increasing diagnostic complexity. Conditional Access & Compliance: Intune integrates tightly with Azure AD for conditional access policies, which is a strength, but requires additional configuration and licensing for advanced scenarios. App Protection Policies: Strong for Microsoft 365 apps, but less flexible for third-party apps compared to Workspace ONE. Migration Strategy Overview The project aims to migrate the entire mobile fleet—a few tens of thousands Android and some iOs devices—between September 2023 and December 2024. Cybersecurity requirements mandate a shift from COBO (with personal Google accounts allowed) to COPE, reinforcing corporate control and reducing exposure to security risks. Key Challenges Technical Constraints: Devices incompatible with Android 13 require hardware replacement. For most employees, migration involves full device reset and Intune re-enrollment—a complex, time-consuming process. Security Limitations: Backup tools cannot be authorized, increasing the risk of data loss and user errors. A recurring issue is failure to remove Microsoft Authenticator configurations, creating significant support overhead. Performance Impact: The Samsung Galaxy A32, previously adequate under COBO, performs poorly under COPE, affecting user experience. Status and Strategic Decision By June 2024, progress is far below target. To mitigate operational disruption and support overload, the strategy shifts: forced migrations are discontinued. Migration now occurs only during: Hardware replacement (obsolescence, failure, or breakage) Voluntary device reset This approach prioritizes stability and resource optimization while maintaining compliance with security standards. We’ve been with Intune for almost two years, we make do with it and we are hardly surprised anymore when something doesn’t work. If you have any questions, don't hesitate to reach out via the comments below Kris47Views3likes2CommentsUnable to register device using Google Services Framework Android ID - Page unresponsive
I am unable to register a new device utilizing the Google Services Framework Android ID. Upon entering the ID and clicking the register button, the page is unresponsive. I have tested this on multiple browsers (Chrome, Brave, Firefox) with extensions disabled, but the issue persists. The page simply does not react.fx3ti17 hours agoNew member14Views0likes0Comments[Day 1] Mobile Devices With a Sixth Sense: What Android Can Learn From Detection Dogs
Good afternoon everyone! Intro Alongside my passion for Android, which I’ve also made my profession, I spend a lot of my personal time working on scent detection training with dogs. Over the years I’ve trained my own dogs to search for items such as data carriers, phones, cannabis, and most recently one on cash. I wanted to participate in the festival because I had to skip the opportunity last year. But to contribute meaningfully, I wanted to create something that connects both worlds, Android and my other interests. This article is the result of that cross-pollination. The article is just a different perspective to discuss, a thought I had and a look in to what I think could be a good future. Android & detection / search dogs Enterprise mobility is still too often reduced to policies, profiles, and compliance checkboxes. A device shows compliant, an app is locked down, and the job seems done. But anyone who has worked with a well-trained detection dog knows that control is only half the story. The real value comes from analyzing behavior and context, and the ability to anticipate on what’s coming. Fun fact: Our nose, and a dogs nose, contain olfactory receptors, nerve cells that detect odor molecules, which is what we use to recognize a scent. An average human has around 2 to 6 million of those. A dog’s nose has around 250-300 million. They are capable of detecting so much more scents than we do. A detection dog doesn’t just smell an object. It smells the contents, the ingredients of what it’s made of and It detects deviations. It recognizes not only what is present, but also when a situation doesn’t match the pattern it expects. If something has disturbed the soil, it will recognize that. And as a handler you should be able to read to signals and act on it. If you want to go right, and the dog is showing that it recognizes a scent on the left, you should really go left and trust the signals your dog is sending you. As a dog handler I’m trusting my dog to make the right decisions, I just follow and guide the dog where needed. Lift him to higher grounds, or maybe mark areas of extra interest that I can see and I’ve been told to search. Its teamwork. Devices as Sensors Imagine a device that doesn’t only enforce policy but also understands what normal looks like in its environment. Not only checking whether something is allowed, but noticing when something is unexpected. A phone that has spent months connected only to Wi-Fi inside the warehouse but suddenly appears on 4G at two in the morning in another city, that may not be a direct policy violation, but it is something you and I would ask questions about. Any detection dog would pause, tilt its head, and quietly signal that something’s off. The ingredients to make devices smarter already exist. Smartphones capture motion, location, battery patterns, network behavior, app usage, and user interaction. Individually these are datapoints, but together they form a pattern, just like scent particles form a track for example. The interesting part is: the hardware has been ready for years. What we lack is interpretation. Fun fact: Did you know that when a dog is searching/sniffing, it can inhale and exhale up to 300 times per minute? If we would do this, we will start hyperventilating within seconds. I think Android could evolve in the same direction by learning baselines of enterprise-normal rather than relying solely on static policies. Once a baseline exists, devices can flag changes proactively, early before things escalate. An example Consider a warehouse worker scanning goods along the same aisle, during the same shift, using the same three apps every day. Android sees that, learns it, and identifies it as normal. But one Monday everything is different: roaming is active, a new route is taken, unfamiliar apps are running. Instead of asking only is this allowed?, the device could ask is this unusual?, should I report this?, is this risk or intentional deviation? As an IT admin, you could check those signals and take appropriate action. But maybe we want Android Enterprise to take their own actions up to a certain degree? This isn’t just security, it also improves stability, efficiency and less downtime. Combine all these and you might even have an employee who is actually happy with the work IT is doing. Instead of being the team who keeps blocking things, you become the IT admin that makes the devices just work when they need to. Closing note I am aware of different MDM’s providing such solutions such as WS1 and Knox Asset intelligence. But I think it could and should be so much better than that. It should be part of core Android OS, present for everyone, not just the one who can afford it but also the smaller companies with less budget. It shouldn’t be depending on a third party whether or not this works. Android Enterprise has matured. Policies are essential, but they’re not the finish line. The real opportunity lies in devices that understand normal, and detect subtle deviations before users even notice. Maybe it’s time our Android fleets developed a sense of intuition. Maybe it's time for Android fleets to develop their own sixth sense like a detection dog that quietly sits, nose raised, because it notices something no one else does yet.Michel2 days agoLevel 4.0: Ice Cream Sandwich120Views9likes9CommentsDevice 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 BatlacBatlac4 days agoLevel 1.6: Donut19Views0likes0CommentsI haven't been able to access this job profile for two hours. Someone please tell me.
Hi emrekacmaz057​ Thank you for your message and welcome to the customer community! I have translated your message - see your original post below - to make it easier for English speaking community members to respond. Original title: 'İki sAattir su iş profiline giremedim . Biriniz anlatın lütfen' Translation: 'I haven't been able to access this job profile for two hours. Someone please tell me.' Thank you, Emilieemrekacmaz0576 days agoLevel 1.5: Cupcake19Views0likes1CommentAMAPI prepareEnvironment() randomly throws SecurityException right after enrollment — persists until device reboot
Hello everyone, I am implementing a custom Device Policy Controller (DPC) (device owner mode) and integrating the Android Management API (AMAPI) locally on the device using: EnvironmentClient.prepareEnvironment() AccountSetupClient.startAccountSetup() Both calls happen directly after device enrollment, inside a flow that starts within minutes after provisioning. Most of the time, everything works perfectly. However, randomly, prepareEnvironment() fails immediately after enrollment with: java.lang.SecurityException: Permission denied to call Android Device Policy app. And once this error happens, all subsequent calls to AMAPI continue to fail with the same exception — until the device is rebooted. After reboot, AMAPI works normally again. Sometimes onboarding works the first time, sometimes not, with no changes in our code or provisioning steps. We consistently see repeated Google Play Services / Dynamite module errors whenever the failure occurs: Invalid module.yaml info for apk: split_GoogleCertificates_installtime.apk DynamiteModule: Failed to load remote module: Failed to get module context GoogleCertificates: Failed to get Google certificates from remote DynamiteModule: LoadingException: Remote load failed. No local fallback found. Followed by AMAPI denying our DPC: Permission denied to call Android Device Policy app. java.lang.SecurityException: Permission denied to call Android Device Policy app. This state persists indefinitely until the next device reboot. I test on my Samsung Galaxy Tab A8 (SM-X200) We rely on AMAPI to complete Managed Google Play provisioning right after enrollment, and this intermittent failure is blocking many devices until they are rebooted. Any insights, known issues, or best practices from Google engineers or EMM partners would be extremely helpful. Thank you!Christophe6 days agoLevel 1.5: Cupcake34Views0likes1CommentEnable ADB debugging is grayed out - This setting is managed by your administrator
This issue was documented in 2021 but with no solution. My Chromebook is managed by my company and I am the manager. But Google tries to find the managed option to unlock for this to work in the administration interface for more than 15 days without success. By the way there are thousands of options in the admin interface it could be a clever feature to number them. If you are in front of the same issue please add your comments to this post. I hope that Google support will succeed to solve the issue soon because I developed my first app for Android on my Chromebook with Android Studio and I was able to download it to my phone before these 15 days.85Views0likes7CommentsREQUIRE_ENTRY flag not working as expected
Hello, I am working on a Mobile Device Management system and just received a bug report about the Require Entry option when resetting a password. Since I set the Require Entry option I expect that the device does not accept any new password changes until I unlocked it at least once with the new credentials. This did not work. I was able to change the password numerous times over the Google API without logging in once. In your documentation here: https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/issueCommand#ResetPasswordFlag it' s outlined that the flag should force the device to not accept any other password changes over the Google API by admins until the user has entered the new password. REQUIRE_ENTRY Don't allow other admins to change the password again until the user has entered it. I traced the issue through my software and checked all requests. My initial request to Google services looks like this. { "type":"RESET_PASSWORD", "resetPasswordFlags":[ "REQUIRE_ENTRY" ], "newPassword":"111111" } Here is clearly observable that the REQUIRE_ENTRY flag is sent to Google. Furthermore Google also includes the flag in it's response. { "name":"RouterSuccess", "code":200, "message":"OK", "data":{ "name":"enterprises/LC01zoikuz/devices/33c202b53a9b800c/operations/1764168989992", "metadata":{ "@type":"type.googleapis.comgoogle.android.devicemanagement.v1.Command", "type":"RESET_PASSWORD", "createTime":"2025-11-26T14:56:29.992Z", "duration":"600s", "newPassword":"111111", "resetPasswordFlags":[ "REQUIRE_ENTRY" ], "userName":"enterprises/LC01zoikuz/users/107976853558892540833" } } } So I assume that my API calls are working fine. Now I started to look into the adb logs of my device. I sent two reset password commands, one with the Require Entry option enabled and one without. I grepped the logs for "password" as a keyword and compared the results with a tool. Those are the logs of my request with Require Entry enabled: 11-26 10:16:45.367 2770 6955 I SDPLog : Reset password with token for user 0 11-26 10:16:45.654 1301 8837 I keystore2: system/security/keystore2/src/security_level.rs:829 - In import_key. 1000, Some("synthetic_password_293151ba28441a0d") 11-26 10:16:45.654 1301 8837 I keystore2: system/security/keystore2/src/security_level.rs:832 - synthetic password changed : 1000 11-26 10:16:45.655 1301 8837 I keystore2: system/security/keystore2/src/database.rs:2158 - In store_new_key "synthetic_password_293151ba28441a0d", uid=103, cert=false, cert_chain=false rebound=false 11-26 10:16:45.672 2770 6955 I SyntheticPasswordCrypto: Deleted SP protector key synthetic_password_a94cb138ecf734eb 11-26 10:16:46.071 2770 6955 I PasswordPolicy: isExternalStorageForFailedPasswordsWipeExcluded() : no admin enforce password policy. 11-26 10:16:46.091 6382 24694 I clouddpc: [PolicyUpdaterImpl.java:fromCache:214] From cache started [passwordPolicies, passwordRequirements, encryptionPolicy] forceComplianceReport: false 11-26 10:16:46.091 6382 24694 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: RequestPolicyUpdateFromCache details: [policyKeys=[passwordPolicies, passwordRequirements, encryptionPolicy], forceComplianceReport=false] metadata: [isNetworkConnected=true] 11-26 10:16:46.091 6382 7741 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: PolicyUpdateStarted details: [policyKeys=[encryptionPolicy, passwordPolicies, passwordRequirements], forceComplianceReport=false] metadata: [isNetworkConnected=true] 11-26 10:16:46.092 6382 7741 I clouddpc: [PolicyUpdaterImpl.java:reApplyAndExecuteCompliance:597] Updating policies: [encryptionPolicy, passwordPolicies, passwordRequirements] from cache with force report: false reportApps: false 11-26 10:16:46.096 6382 7741 I clouddpc: [PasswordRequirementsHandler.kt:apply:79] passwordPolicies is set, ignoring passwordRequirements 11-26 10:16:46.112 6382 7741 I clouddpc: [DefaultPasswordUtils.java:setPasswordRelatedPolicy:129] Applying password quality (server enum value): 65536 with scope: 0 11-26 10:16:46.113 6382 7741 I clouddpc: [PasswordPoliciesHandler.kt:applyResetPasswordToken$java_com_google_android_apps_work_clouddpc_base_policy_handlers_handlers:384] Reset password token already active 11-26 10:16:46.153 6382 7741 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: PolicyReapplied details: [policyKeys=[encryptionPolicy, passwordPolicies, passwordRequirements]] metadata: [isNetworkConnected=true] And these are the logs without Require Entry activated: 11-26 10:17:14.229 2770 4719 I SDPLog : Reset password with token for user 0 11-26 10:17:14.517 1301 8837 I keystore2: system/security/keystore2/src/security_level.rs:829 - In import_key. 1000, Some("synthetic_password_89ec84ca283671b1") 11-26 10:17:14.517 1301 8837 I keystore2: system/security/keystore2/src/security_level.rs:832 - synthetic password changed : 1000 11-26 10:17:14.518 1301 8837 I keystore2: system/security/keystore2/src/database.rs:2158 - In store_new_key "synthetic_password_89ec84ca283671b1", uid=103, cert=false, cert_chain=false rebound=false 11-26 10:17:14.536 2770 4719 I SyntheticPasswordCrypto: Deleted SP protector key synthetic_password_293151ba28441a0d 11-26 10:17:14.935 2770 4719 I PasswordPolicy: isExternalStorageForFailedPasswordsWipeExcluded() : no admin enforce password policy. 11-26 10:17:14.953 6382 24694 I clouddpc: [PolicyUpdaterImpl.java:fromCache:214] From cache started [passwordPolicies, passwordRequirements, encryptionPolicy] forceComplianceReport: false 11-26 10:17:14.954 6382 24694 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: RequestPolicyUpdateFromCache details: [policyKeys=[passwordPolicies, passwordRequirements, encryptionPolicy], forceComplianceReport=false] metadata: [isNetworkConnected=true] 11-26 10:17:14.954 6382 7741 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: PolicyUpdateStarted details: [policyKeys=[encryptionPolicy, passwordPolicies, passwordRequirements], forceComplianceReport=false] metadata: [isNetworkConnected=true] 11-26 10:17:14.955 6382 7741 I clouddpc: [PolicyUpdaterImpl.java:reApplyAndExecuteCompliance:597] Updating policies: [encryptionPolicy, passwordPolicies, passwordRequirements] from cache with force report: false reportApps: false 11-26 10:17:14.958 6382 7741 I clouddpc: [PasswordRequirementsHandler.kt:apply:79] passwordPolicies is set, ignoring passwordRequirements 11-26 10:17:14.974 6382 7741 I clouddpc: [DefaultPasswordUtils.java:setPasswordRelatedPolicy:129] Applying password quality (server enum value): 65536 with scope: 0 11-26 10:17:14.975 6382 7741 I clouddpc: [PasswordPoliciesHandler.kt:applyResetPasswordToken$java_com_google_android_apps_work_clouddpc_base_policy_handlers_handlers:384] Reset password token already active 11-26 10:17:15.012 6382 7741 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: PolicyReapplied details: [policyKeys=[encryptionPolicy, passwordPolicies, passwordRequirements]] metadata: [isNetworkConnected=true] I compared both results but were not able to detect any differences on the device. Thank you and best regards lennartsplennartsp6 days agoLevel 1.5: Cupcake55Views1like1CommentNo accounts found Zero touch
as per : ZTE Portal - no account found | Android Enterprise and ChromeOS Customer Communities - 4093 I'm an admin of a Google workspace instance, let's call it Acme, LLC. This is Google Workspace Business Plus I'm an admin (not owner) of a Android Zero Touch instance, with the ability to make changes to: Configs Devices Users Resellers, etc I've logged into Workspace.google.com for Acme, Inc. Gone to Devices, Mobile & Endpoints, Settings, Enrollment, Manage Zero Touch devices, Link, log in using AZTE user and get the rather lovely: MDM is set to advanced, by the wayPabloMDM8 days agoLevel 1.6: Donut51Views0likes4CommentsAndroid Exchange Sync Problems: Contacts and Calendar Not Updating
Hello, I manage a fleet of more than 1,000 Samsung Android devices using Omnissa Workspace One (AirWatch), devices are enrolled in COPE. We use Gmail, Google Calendar, and the native Samsung Contacts app in the work profile, all synchronized through an Exchange ActiveSync connector. Since Wednesday, November 26th, we have been experiencing synchronization issues: - Contacts and calendar events saved on Exchange disappear after some time. - The Calendar app eventually shows an “Unauthorized Action” error and refuses to open. - Gmail continues to sync emails normally. The issue occurs randomly (sometimes after one hour, sometimes longer). Clearing Gmail’s app data and signing in again temporarily resolves the problem, but the issue always comes back. We've tryied uninstalling and reinstalling the app through our MDM but we can only do it user by user and we're not sure about it fixing the issue. We have no means to "rollback" Gmail's version to an older one through our MDM, i've tryied uninstalling recent updates on one of my test phones, it's seems stable for the moment. We noticed that Gmail received an update recently, and a couple of other fleet managers have reported the same problem since that update on Play store's comments. Have you identified any bug or recent change in Gmail that could affect Exchange/ActiveSync synchronization? Thank you in advance for your assistance.Axel_ch8 days agoLevel 1.5: Cupcake131Views0likes5Comments
Explore other customer resources
Help Center
Explore step-by-step how-to guides.
Solutions Directory
Find solutions and partners.
Website
Discover more about Android's features.