Recent discussions
Managed Configuration in Google Messages
Following Samsung's decision to start sunsetting Samsung Messages (and recommending Google Messages) on newer devices we are now evaluating GM across our estate. Devices are managed by Intune and we can see we can push App Config for RCS Messages and Archiving via the Config designer but after opening up GM I get the "Use Gemini" in my face. Currently we don't use Gemini on our devices - infact we remove it. I have found the option under Settings in GM to Hide the Gemini button but it would be good if we could push that config down with the App......searching round not found anything to date - any thoughts?
[Day 5] Community festival: I Tried Living Like It's 2005 for a Week
I Tried Living Like It's 2005 for a Week (And My Thumbs Still Hurt from T9 Texting) In which I attempted to survive seven days with flip phones, MapQuest printouts, and the soul-crushing realization that the Motorola RAZR was actually considered "cool". Twenty years ago, the Motorola RAZR was the height of mobile sophistication, MySpace let you rank your friends publicly (and cause lifelong trauma in the process), and if you wanted directions to somewhere then you printed them on actual paper and prayed you didn't miss a turn. No Uber, no YouTube music. no Instagram. Just you, your iPod with 5GB of storage, and a whole lot of patience. So naturally, I decided to torture myself by living like it's 2005 for an entire week. No smartphone. No modern conveniences. Just me and the technology available exactly twenty years ago, trying to navigate a world that has since become unrecognizable. What could possibly go wrong? Day 1: The Setup, Or "How I Learned to Stop Worrying and Love the Flip Phone" The first order of business: acquiring my 2005 tech arsenal. After scouring eBay and my old tech drawer, I assembled my kit: Motorola RAZR V3 (silver, because I have some dignity) iPod Nano 2GB (first generation, the one that scratched if you looked at it wrong) Canon PowerShot A520 (4 megapixels of pure photographic mediocrity) Dell Latitude D610 laptop running Windows XP (weighing approximately 47 pounds) A healthy sense of denial about what I'd gotten myself into The RAZR turned out to be simultaneously the best and worst thing about 2005. It was impossibly thin at 13.9mm - which felt like holding a credit card after using modern smartphones. The screen? A luxurious 2.2 inches of 176x220 pixel glory. For context, that's roughly the resolution of a potato. But here's what killed me: 5MB of storage. Not 5GB. Five. Megabytes. I could store maybe three low-res photos and a handful of text messages before the thing started wheezing. The Pixel in my drawer had 256GB. I was going from a spacious mansion to a storage unit. The setup process was actually refreshing in its simplicity. No app store. No cloud sync. No software updates. I charged it fully, and the battery indicator basically laughed at me—this thing would last four days on a single charge because it had approximately four things it could do: call, text, take terrible photos, and play a MIDI ringtone version of "Crazy Train." Day 2: The Great T9 Texting Disaster My morning started with me trying to text my friends that I'd arrived at the coffee shop. Simple message: "I'm here, where are you?" Twenty minutes later, I'd managed to produce: "I'n grrdr, wgrrr arr yoi?" Let me explain T9 predictive text for those blessed enough to have forgotten. You had a numeric keypad where each number corresponded to multiple letters (2=ABC, 3=DEF, etc.). T9 tried to predict which word you meant based on the sequence of numbers. To type "here," I pressed 4-3-7-3. Sometimes T9 guessed correctly. Sometimes it gave me "gerd." Sometimes it offered me "ifsf" and I questioned its commitment to the English language. The real chaos started when I tried to add punctuation. That required pressing 1 multiple times to cycle through options, and God help you if you overshot and had to cycle through ALL THE SYMBOLS AGAIN. My thumbs started cramping after the fifth text message. My friends thought I was having a stroke. One replied: "Are you okay? Should I call someone?" Another person just sent back: "???" And here's the thing that got me - each text cost me 10p because I didn't have a texting plan. By Day 2, I'd already spent £4.50 on text messages. I started making actual phone calls because they were cheaper. Like an animal. Day 3: Navigation Roulette, or "How I Got Lost Going out" I needed to drive a couple of towns over for a meeting. In 2025, I'd just tap the address into Google Maps and go. In 2005, I had to visit MapQuest on my desktop computer the night before, type in the address, print out six pages of turn-by-turn directions, and hope for the best. The printout told me things like "After 11 miles turn right onto Wilson Road" and "Continue for 0.5 miles." Very specific. Very confident. Completely useless the moment I missed turn #6 because a van blocked my view of the street sign. And that's when I discovered the fundamental problem with printed directions: they don't recalculate. Once you're off the route, you're just a confused person holding useless paper while your blood pressure climbs. The paper map was also particularly poor at showing the current congestion of the roads. Anyway I pulled into a petrol station and did something I hadn't done in fifteen years - I asked a stranger for directions. "Oh yeah, Wilson? You're gonna want to go back about two miles, hang a right at the big oak tree—you know, the one that looks kind of dead—then you'll see a small corner shop. No not that corner shop, the other one..." I arrived 47 minutes late to the meeting and was asked why I didn't text that I was running behind. I explained the T9 situation. She looked at me with pity generally reserved for injured animals. Day 4: The iTunes Sync Incident By Day 4, I was desperately bored with the 10 songs I'd initially loaded onto my iPod Nano. I wanted to add more music. This should be simple, right? Wrong. First, I had to find my laptop (all six pounds of it), wait for Windows XP to boot (about three minutes, accompanied by that start-up sound that definitely awoke dormant memories), open iTunes, and connect my iPod via the proprietary 30-pin cable. Then came the sync process. iTunes cheerfully informed me it would take 12 minutes to sync 15 new songs. Twelve minutes for 45MB of data! But wait - there's more! I'd forgotten about the tyranny of DRM-protected music. Half the songs I'd purchased from the iTunes Store in 2005 were locked with FairPlay protection. They would only play on authorized devices. I'd exceeded my authorization limit, so I had to deauthorize my old computer (which no longer exists) to authorize this Windows XP machine. This took another 20 minutes and required me to reset my Apple ID password because I'd long ago changed the security questions from "What's your favourite colour?" to something involving cryptocurrency and existential dread. I finally loaded the new songs. By this point, I'd burned an hour. In 2025, I could've discovered, downloaded, and listened to an entirely new album in YouTube music within two minutes. As I disconnected the iPod, iTunes asked if I wanted to update to iTunes 6.0. I clicked yes. It took 45 minutes and required a restart. I briefly considered violence. Day 5: The Social Media Vacuum This was the day I truly felt the isolation of 2005 technology. Facebook existed, but only for college students with .edu email addresses. I was not welcome. Instagram? Didn't exist. Twitter? Still a year away. TikTok? Might as well have asked for a teleporter. Reddit had just started but I hadn’t heard of it in 2005. This meant there was no passive social media consumption. No scrolling through feeds. No watching Stories. No seeing what everyone was having for lunch. And you know what? The silence was deafening. I found myself with something I hadn't experienced in years: boredom. Actual, crushing, what-do-I-do-with-my-hands boredom. So I did what people did in 2005 - I logged onto AIM (AOL Instant Messenger). Well I would have if the company hadn’t closed it in 2017! :( I did the next best thing and remembered it fondly! Oh, AIM. Sweet, chaotic AIM. I'd forgotten about the beauty of away messages, those little status updates where you'd post song lyrics, inside jokes, or cryptic messages designed to make your crush ask what was wrong. The AIM experience was oddly refreshing. Conversations were deliberate. You knew when someone was actively typing because you could see "ChunkyLover53 is typing..." at the bottom. No read receipts haunting you. No pressure to respond instantly. You were either online or you weren't. Simple. But here's what I'd forgotten: AIM only worked when you were sitting at your computer. No mobile version. No smartphone app. If I left my desk, I was unreachable. The untethered freedom was... actually kind of nice? I walked to get coffee and nobody could bother me. Revolutionary. Day 6: The Great Photo Upload Catastrophe I'd been dutifully taking photos all week with my Canon PowerShot A520—a 4-megapixel beast that required four AA batteries and could store maybe 200 photos on its 256MB SD card. The photos looked fine on the camera's 2-inch screen. Adorable, even. Then I uploaded them to my computer. They were... not good. They were "early 2000s Facebook profile picture" quality. Grainy. Poorly lit. Zero dynamic range. Every indoor shot looked like it was photographed during an eclipse. The 4-megapixel resolution meant any photo looked pixelated the moment you zoomed in even slightly. But the real torture was the upload process. I had to: Remove the SD card from the camera Find the SD card reader Plug it into the laptop's USB 2.0 port Wait for Windows XP to recognize the device (3 minutes) Navigate through folders to find the photos Copy them to my computer (5 minutes for 50 photos) Open each one in the default Windows Photo Viewer Cry softly Then, if I wanted to share them, I had to upload them to Flickr—which in 2005 was THE photo-sharing platform. The upload process took 15 minutes for 20 photos on my DSL connection. No instant sharing. No cloud sync. No automatic backup. Just manual labor and regret. My friend texted me (after I spent 10 minutes composing the message via T9): "Why do these photos look like they were taken with a microwave?" I couldn't even argue. Day 7: The Music Piracy Question I Won't Answer Let's talk about music acquisition in 2005, shall we? Legally, you had three options: Buy CDs for £15-18 each and rip them to your computer Buy individual songs from iTunes for £0.99 each (with DRM) Buy albums from iTunes for £9.99-14.99 (also with DRM) Illegally—and I'm not saying I did this, but statistically speaking, 1.7 million people were doing it daily—you could use LimeWire. LimeWire was the Wild West of file sharing. You searched for a song, downloaded it, and either got: The actual song A virus A different song mislabelled as your song A Bill Clinton speech Dial-up modem sounds All of the above The RIAA (Recording Industry Association of America) was actively suing college students for thousands of dollars. They'd settled about 2,500 cases by 2005, with average settlements around $3,000. People were genuinely terrified. But iTunes Store had sold 500 million songs by July 2005, proving there was a legal market. Of course, those songs were locked with DRM that prevented you from playing them on non-Apple devices, which felt like buying a book that could only be read in one specific chair. For this week, I legally purchased songs from iTunes and ripped CDs I already owned. My music budget for the week: £47.93. In 2025, I pay £12.99/month for YouTube Premium and have access to over 100 million songs. The math just doesn't math! The Final Tally: What I Learned After seven days in 2005, here's what nearly broke me: The Bad: T9 texting made me want to throw my phone into a lake Getting lost with printed directions was not "an adventure," it was torture Photo quality was potato-grade Music syncing was a multi-step nightmare Social isolation was real - no passive connection to friends Every single task required planning and patience The Surprisingly Good: Battery life on my RAZR was amazing (3 days!) Being unreachable while away from my desk was liberating AIM conversations felt more intentional and focused No social media scrolling meant I actually read two books The simplicity was calming - each device did one thing well The Expensive: Text messages: £12.50 Music purchases: £47.93 Petrol from getting lost repeatedly: £13.00 Replacement AA batteries for camera: £8.99 Therapy cost for T9-induced rage: £130.00 Total: £212.42 The Verdict: Would I go back to 2005 technology permanently? Absolutely not. The lack of real-time navigation alone nearly destroyed me, and I'm pretty sure my thumbs have early-onset arthritis from T9 texting. But here's the thing - there was something oddly peaceful about the intentionality of 2005 tech. Every action required thought. Every photo was deliberate. Every text message had to be worth the thumb cramping. You owned your music, your photos lived on your hard drive, and when you left your computer, you were truly disconnected. In 2025, we have infinite convenience and infinite distraction. Everything is instant, effortless, and cloud-synced. But we're also constantly reachable, endlessly scrolling, and tethered to devices that demand our attention 24/7. Maybe the sweet spot isn't 2005 or 2025 - it's somewhere in between. A world where we have modern convenience but 2005-era intentionality. Where we can use Google Maps but also occasionally put the phone down. Where we have YouTube Music but actually curate playlists instead of algorithmic recommendations. Where we're connected but not enslaved. Or maybe I'm just romanticizing the past because I'm getting old. Either way, I'm keeping my smartphone, my unlimited texting plan and Google Maps. My thumbs have suffered enough. Final note: The Motorola RAZR is now in a drawer next to my old iPod, my printed MapQuest directions, and a pile of AA batteries. The Dell laptop running Windows XP is on eBay listed as "vintage computing experience, very heavy, buyer pays shipping!" No flip phones were harmed in the making of this article. But several were definitely cursed at.
Forced Auto Install Issues
Since mid-November '25, forced auto install is not functional for our organization. Apps are loaded and installable as work apps but do not progress as an auto install from our policy. Has anyone experienced a similar issue? No policy changes, no SW updates on the MDM client. Functionality just stopped working.
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[Day 4] Managed Google Domains: What, why, and how to upgrade
What is a Managed Google Domain? In Android Enterprise land, a Managed Google Domain refers to using a Google-managed organisation (like Cloud Identity or Google Workspace) to create and manage the connection to an EMM (the bind), it sits in contrast with Managed Google Play accounts, which uses a “personal” Gmail account to manage enterprise devices and apps. In practical terms, it means Android management is tied to an organisation’s work domain (e.g. @company.com), managed through the Google Admin console, rather than being tied to a single @gmail.com account. This approach unifies Android management with other Google services (Workspace, Chrome, etc.) under one organisational account, and is not only the default approach for all newly-binding organisations, but recommended by Google as an upgrade for all existing managed Google Play accounts enterprises due to the benefits it provides to IT admins and employees. Historically, organisations (even those with Google Workspace) used a managed Google Play Accounts setup - essentially registering Android Enterprise with a Gmail account - arguably said Gmail account could be created under a domain by using an existing email address, but this isn’t foolproof. The EMM (Enterprise Mobility Management solution) would then create generic managed Google Play accounts on each device for app distribution, account management, and so on. This legacy method worked, but it meant the entire Android Enterprise bind was owned by a personal account. It also means for devices there was no user identity, so things like automatic provisioning of the Google suite of applications with a managed account wouldn’t happen, and if a user was to add a managed account, behaviour around the app store, data sync, and more would become a challenge. Look familiar? Now, Google has introduced a better way. Why Google has (mostly) moved away from Gmail-based accounts Using a personal Gmail to manage enterprise devices has been convenient, but it poses security and management risks. For one, a Gmail-based enterprise bind is outside your corporate identity control - security teams cringe at the idea that the keys to your mobile fleet are held by an unmanaged personal account. There’s no way to enforce corporate security policies (no mandatory SSO, no corporate-managed 2FA or security keys) on a personal Google account. It also creates a single point of failure: if a Gmail owner leaves the company or loses access, recovering the account (and therefore control of all devices) can be difficult. Google’s solution is the Managed Google Domain - essentially migrating Android Enterprise enrolment to a proper Google organisation owned by the business. This shifts control from a personal account to corporate-owned credentials, immediately strengthening security. IT admins (plural, as now there can be several!) can log in with their work email and leverage enterprise-grade protections like multi-factor authentication (MFA), security keys, and single sign-on. In short, it “severs the tie” to the personal account and brings Android management under your company’s identity and policies. Equally important, Google is future-proofing Android Enterprise with this change. The new domain-led approach, rolled out in 2024, eliminates previous limitations. For example, historically one Google account could only bind to one EMM at a time. Now, once your domain is verified, you can actually bind multiple EMMs (or multiple instances of an EMM) to the same organisation - useful for testing a new EMM or running production and sandbox environments simultaneously. It also lays the groundwork for deeper integration with Google’s AI and cross-device features that rely on full Google accounts. How to upgrade to a Managed Google Domain For organisations currently on the older managed Google Play accounts bind, upgrading is straightforward and free. Google offers a one-way migration path from the Play Accounts enterprise to a managed domain enterprise. You can initiate it either via your EMM console’s Managed Google Play iframe or through an EMM provider’s implementation of the respective APIs: Via EMM Console (Play iframe): In your EMM console, navigate to the Managed Google Play area (for example, the app approval section). Many consoles now display an “Upgrade for free” banner or button at the top of the embedded Play iframe if your Android Enterprise is currently bound with a Gmail account. Clicking this starts the upgrade flow. You’ll be asked to sign in with the current owner account (the Gmail that was used originally), then provide a work email to act as the new admin account for the Google domain. If your organisation already has a Google Workspace or Cloud Identity domain, you can log in with a super admin of that domain to bind the enterprise to it. (Don’t worry - the Android Enterprise enrolment will belong to the domain itself, not that individual admin account.) If you don’t have an existing Google domain, you can create a new Managed Google Domain on the fly using your work email’s domain. For example, if you enter it@company.com, Google will set up a Cloud Identity domain for “company.com”. You’ll verify your email address and later have the option to perform full domain verification (to unlock all features, e.g authenticate with Google, ChromeOS management, and more. Via EMM API: Some EMMs may provide their own “upgrade” prompt or process using Google’s direct APIs. The steps are essentially the same - the EMM triggers the creation or linkage to a Managed Google Domain, and you supply a corporate email domain to either link or create the Google admin account. Speak to your EMM vendor for details on how to achieve this. Log in or create an account Authorise the migration Do a little shimmy, you’re done. After a successful upgrade, your Android Enterprise is now managed in the Google Admin console (under Devices > Mobile & endpoints, etc.). Notably, you should no longer use the old Play console for enterprise settings - those settings move into the Admin console and your EMM interface. The migration is again one-way; you cannot revert back to a Gmail-based setup, so double-check that chosen domain! The good news is that all your enrolled devices and approved apps remain intact - the change is largely on the backend linkage, and it does not unenrol devices or remove apps in your EMM console. Key Benefits of Using a Managed Google Domain: recapped Upgrading to a managed domain unlocks a range of benefits for both IT administrators and end users: Stronger Security & Admin Control: Admins log in with work email addresses and managed identities, not consumer Gmail. This means you can enforce your usual security policies (company SSO, MFA, password rules) on these accounts. Google specifically highlights that this allows enterprise-grade authentication - you can require admin logins to use multi-factor auth, hardware security keys, etc. Account recovery is also simplified (the domain super admin can reset passwords or reassign admin roles as needed). No more worrying about a single person “owning” the enterprise—ownership now belongs to the organisation. Single Sign-On (SSO) and Microsoft Integration: If your company uses Microsoft 365/Azure AD for identity, Google has made the integration seamless. The sign-up process can work directly with Microsoft 365 accounts, automatically tying in your external Azure AD identity as the IdP for the Google domain. This means your users (and admins) can authenticate with their Microsoft corporate credentials to access managed Google Play and other Google services, without you having to manually configure a SAML SSO federation. Google essentially removes the extra SSO setup step when you use a Microsoft-managed domain during the bind. Multiple EMMs and Flexibility: A Managed Google Domain allows binding multiple EMM instances to your single organisation ID. Practically, this means you could have, say, your primary EMM and a test EMM environment both managing subsets of devices under the same Google enterprise. Or, if you are transitioning between EMM vendors, you can connect the new EMM without unbinding the old one, then migrate gradually. This was impossible in the old Gmail-based model. Unified Admin Console & Google Services: Once on a managed domain, you gain access to the Google Admin console for device management and more. Beyond just Android management, this opens the door to centrally manage other Google products. For example, your team could explore using Google Workspace apps, Google Chrome management, or even new AI tools like Google Gemini on Android, all managed from one place. Better Employee Onboarding: With a managed domain, users can enrol their devices using their corporate credentials (email/password or SSO) rather than a special code or dummy account. This makes the provisioning experience more intuitive - they log in with their company email during setup, which configures the work profile/device. It also means if they already use Google Workspace, their apps and data can populate seamlessly. Legacy Managed Play Accounts can still be leveraged I mean this in two ways.. First, not every organisation may be ready to move to a Managed Google Domain immediately, and that’s OK. Google isn’t shutting down the old method yet. If you don’t have a Google domain or aren’t in a position to use one, you can continue using the managed Google Play Accounts approach with a Gmail admin account - your EMM will keep generating the necessary managed play accounts on devices as it always has. Nothing stops your Android Enterprise deployment from functioning, and Google will allow maintaining the legacy binding for now. Secondly, even if you were to migrate to a Managed Google Domain, some devices and use cases simply don’t suit user authentication/association. EMMs that support it should offer a personal use option for dedicated devices that will still provision a managed Google Play account for dedicated, userless devices. That use case isn’t going anywhere with this change. So, should you upgrade to a Managed Google Domain? If you can - absolutely: all the newest features and integrations are being built with Managed Google Domains in mind. So while you won’t be left in the cold if you stick with the old Gmail-based bind today, you’ll be missing out on security improvements and future capabilities going forward. Toodles, Jason[Day 3] Dedicated to Dedicated: Non-negotiables for EMM/MDM in Rugged Android Deployments
Disclaimer: The following article captures the opinion of Matt Dermody, Senior Director of Enterprise Mobility at Manhattan Associates. The stances contained within are a reflection of Manhattan's specific focus on line-of-business Android devices, built on years of being "Dedicated to Dedicated." Background Manhattan Associates is a B2B software company specifically focused on best-in-class, line-of-business enterprise deployments of enterprise software such as Warehouse Management (WMS), Transportation Management (TMS), and Point-of-Sale (POS). These software deployments command high expectations of uptime and availability, and that ultimately encompasses the complete solution, including the mobile computers that the software runs on. Manhattan is dedicated to ensuring that our end customers have the best possible experience, and that involves ensuring that the dedicated devices running our software are also properly maintained and supported. Google defines a "dedicated device" as a company-owned device that is fully managed and locked down for a specific work purpose, often using a single app or a small set of apps. These devices are restricted from personal use and are used for business functions like point-of-sale systems, inventory scanners, or digital signage. Or in other words, all of the device types that Manhattan sells, deploys, and supports alongside our software solutions. In that sense, I guess it can be said that we are… Dedicated to Dedicated. Managing rugged, line-of-business Android devices is not the same as managing BYOD phones and laptops. These are mission-critical endpoints running specialized apps in warehouses, stores, yards, and DCs—downtime costs money and local IT is increasingly rare. Your EMM/MDM must control versions, files, firmware, and field support with precision. Anything less adds risk and operational drag. Situation Imagine having to explain to a CIO that a business-critical mobile app has automatically upgraded to a new version that breaks functionality, and there is no easy rollback available. Here is a preview of how that might look. That situation is all too common but can be prevented with the right EMM/MDM strategies. The mere thought of that possible situation keeps the Manhattan team up at night. We have spent years developing strategies to add predictability and stability into enterprise device deployments to prevent bad situations from ever happening. Philosophies & Strategies Here is a preview of some of the core philosophies surrounding Manhattan’s tailored approach to managing mission-critical device deployments. Some of these might be controversial, but these are the strategies that work for us. 1. App Distribution and Version Discipline Rigorous version control of enterprise apps—stage, canary, bulk rollout, and rollback—is a must. Rugged ops cannot afford “surprise” app updates or version creep. If you can’t downgrade quickly, you don’t control your risk surface. An EMM/MDM should offer direct installation of private APKs on fully managed devices. Auto-upgrades to the “latest only” through Managed Google Play can lead to instability and version drift. Look for a console that can deploy specific app builds to specific groups on your schedule. If your tool can’t install an APK directly onto devices, it’s the wrong tool for rugged. Period. You must target different versions/configs by environment—Stage, QA, Prod—often per site group. That includes app versions, config files, etc. 2. File Management for App and Scanner Configuration LoB apps often externalize key settings via JSON and similar external config files. For example, Zebra DataWedge uses .db files placed in a specific auto-import directory to control mission-critical scanner settings. Your EMM must place, update, and replace these files on demand and at scale—ideally without anyone touching a device. Emergency changes (host cutover, DNS rename, scanner tweak) should be a file push away, not an onsite scramble. 3. Remote Control and Log Retrieval Treat full-fidelity Remote Control as table stakes. Support must see what the user sees, drive the screen, and pull logs and files in one session. Anything “view only” or bolt-on only erodes speed to resolution. Relying on reports from the floor or grainy pictures of an error taken from another device are not sufficient tactics for troubleshooting mission-critical device deployments. When issues hit, you don’t want an insurance policy like Remote Control that can be used to quickly diagnose and test solutions; you want a tool. An EMM admin without Remote Control is effectively blind with their hands tied behind their back. 4. OEM-level Controls (Zebra/Honeywell) There are numerous configuration settings that enterprise-grade OEMs extend beyond the baseline Android Enterprise configuration APIs. These OEMs are generally years ahead of what is available in base Android from a configurability standpoint and often introduce configuration settings that may otherwise never arrive to the base OS. These granular configuration layers ultimately are what set enterprise-class devices apart from consumer-grade technology. It is therefore imperative that an EMM managing these devices has the capability to manage OEM configuration extension features directly. For Zebra, this involves execution of their MX XML, DataWedge behavior, button mapping, radios, and other rugged-specific controls—through native profiles or integrated mechanisms. OEMConfig is useful, especially for parity across EMMs, but you will hit practical limits in closed networks and with Play-dependent timing/visibility. OEMConfig is a lowest-common-denominator functionality that was designed as a bridge to enable limited AMAPI-aligned EMMs to manage OEM-level settings with the limited tools at their disposal. Your EMM should support both OEMConfig (at a bare minimum) and offer the flexibility of direct MX/file workflows so you’re not boxed in by the limitations of distributing device settings through a complex web of Google Play server infrastructure. Your EMM should offer the ability to manage settings directly on the devices it manages, without the added layers and black boxes of complexity. 5. Firmware and Security Patching Over-the-Air (OTA) upgrades are great, but only when the EMM admin is in complete control. Auto-upgrades from the OEM pushed out over the air can bring production to a halt when critical business functions break. At a bare minimum, they can bring a network to a standstill as large upgrades are forced through the ISP connection into the building or site. An EMM should therefore offer integrations with the OEM-specific OTA and/or firmware upgrade protocols to put the controls in the admins' hands. 6. Lockdown and Kiosk Modes Rugged devices should boot into the work, not into Android. Enforce kiosk/lockdown, strict app allow-lists, settings restrictions, and consistent UX across every DC and store. The EMM should offer configurability over what is displayed on the lockdown, including personalization and customization to offer links to additional items such as launching apps, toolbars, or script executions. 7. Enrollment that Fits the Reality of Rugged Use Android Enterprise Device Owner (AEDO) with a barcode-driven process (e.g., Zebra StageNow). It’s fast, repeatable, and minimizes user taps and mis-taps on the floor. Wi-Fi credentials can be encrypted in the barcode rather than shared haphazardly and manually entered by end users into the Setup Wizard. More granular control over initial network connectivity is also afforded as compared with the limited options available through DPC extras if using the designated AEDO QR method. Avoid Zero Touch Enrollment (ZTE) for rugged Wi-Fi-only devices. ZTE is not "Zero Touch" as it realistically pushes many touches (and possible errors) to end users. There is overhead and maintenance to unenroll and re-enroll devices into the portal as they go in and out of repair. Enterprise-grade devices are often covered under repair contracts due to the nature of the environments they’re used in. This means they are going in and out of repair relatively frequently, and ZTE portal management ends up causing more bottlenecks than the steps it’s otherwise designed to free up. StageNow barcode flows are fewer steps and far more reliable for DCs and stores. 8. Closed Networks and Offline Constraints Many rugged sites have limited or no access to Google services. Your EMM must support managed app configuration and device policies in ways that don’t depend on real-time Managed Play orchestration. If your only path is Play-mediated, you’ll struggle with timing, visibility, and outcomes. Look for an EMM that offers “offline” or standalone Managed Configuration support by reading and exposing the configuration schema of an uploaded Enterprise app. 9. Health Analytics, Drift Detection, and Scripting Device health analytics (compliance, connectivity, install status) are critical for early detection and fleet stability. Pair that with a scripting engine and policy-driven rules (e.g., automatic relocation, auto-heal) to keep devices in line without manual human intervention. 10. What to Deprioritize (and Why) BYOD-centric EMMs that can’t directly install private APKs, can’t push files, and don’t include Remote Control as a first-class capability will drag deployments and support. Many EMMs specifically lack the granular APK/file control, versioning/rollback discipline, and integrated Remote Control required for rugged Android in DCs and stores; workarounds add fragility and cost without closing the gaps. Bonus – Identity and SSO Newer EMMs are offering advanced capabilities around Identity Management and SSO across business apps. As enterprise-grade devices become more multi-purpose, more mobile apps are being installed, each often with its own separate login requirements. Over time, there will be increasing needs to supply SSO workflows on-device across these business apps and to offer a clean pathway to script and automate the cleanup of a prior user’s session across all apps as they log off and make way for the next user to log in. If in the EMM selection process today, look for an EMM that offers these capabilities. Even if those features are not needed today, it is almost certainly the next set of features enterprises will look for and need to adopt. The Quick Scorecard If you can’t answer “yes” to these with your selected EMM/MDM, you’re taking unnecessary risk: Can your EMM install a specific APK build directly to AEDO devices? Can you canary a new version to one site, schedule a 2 a.m. cutover, and roll back instantly if needed? Can you push a JSON config change and a DataWedge .db to 500 devices in under 10 minutes—no manual touches? Can support remotely control the screen and pull logs/files from the same session? Can you execute Zebra MX XML, enforce kiosk/lockdown, and set scanner behavior centrally across models? Can you deploy LifeGuard/.ZIP OS updates by group, with maintenance windows and rollback? Can you enroll with StageNow barcodes (AEDO) instead of relying on ZTE flows designed for non-rugged scenarios? Can you operate cleanly in sites with limited/blocked Google services, including offline managed config workflows? Bottom Line A capable rugged EMM/MDM gives you deterministic control over versions, files, firmware, and front-line support—at fleet scale and on your schedule. Prioritize direct APK delivery, file distribution, OEM-level controls, Remote Control, AEDO barcode enrollment, and firmware orchestration. Deprioritize BYOD-first tools and any workflow that forces you through black box Play timing or pushes enrollment burden to associates on the floor. I’d love to hear what the comments have to say. Am I way off base? Do you fundamentally disagree? Or were you nodding along as you read through this. Let me know below! Oh and "AI", forgot to mention the buzzword. Matt
AMAPI prepareEnvironment() failing with ApiLevelException on Android 8 despite using DEVICE_POLICY_CONTROLLER role
Hi everyone, I’m implementing a custom DPC (device owner) and integrating AMAPI locally on the device. On Android 8 / 8.1, calling: val request = PrepareEnvironmentRequest.builder() .setRoles( listOf( Role.builder() .setRoleType(Role.RoleType.DEVICE_POLICY_CONTROLLER) .build() ) ) .setAdmin(admin) .build() immediately fails with: com.google.android.managementapi.common.exceptions.ApiLevelException On Android 10 and above, I don't have this exception. According to the AMAPI documentation: If the device's SDK API level is insufficient for certain requested roles (this may be in addition to a general minimum API level requirement for the call itself).{@code Role.RoleType.DEVICE_POLICY_CONTROLLER} requires API level 23 or above. Any other roles require API level 28 or above. I am using the latest AMAPI client library: com.google.android.libraries.enterprise.amapi:amapi:1.7.0 Questions Is AMAPI (EnvironmentClient + Device Policy Controller role) still officially supported on Android 8/8.1? Any clarification on the real minimum supported API level for AMAPI prepareEnvironment() would be greatly appreciated, as the documentation suggests Android 8 should work, but the behavior indicates otherwise. Thanks!
Zero-Touch + Intune enrollment fails after Microsoft sign-in (redirects to portal.manager.microsoft.com)
Hi everyone, I’m experiencing an issue during Android Zero-Touch enrollment with Microsoft Intune. The process begins normally and progresses through all the expected steps: 1. Getting your phone ready 2. Checking info 3. “This device belongs to your organisation” 4. Setup your phone 5. Setting up your device 6. “This device isn’t private” 7. Google services 8. Updating device 9. Welcome to Chrome 10. Microsoft sign-in page The problem occurs AFTER I successfully sign in with my work account. Instead of continuing with Android Enterprise (intune) setup, the device opens this URL: **portal.manager.microsoft.com** This page shows “Page not found.” Immediately after that, the device shows: **“Can’t set up device. To finish setup, sign in to your work account.”** At this point the enrollment cannot continue. The device is assigned to a Zero-Touch configuration with the DPC: `com.google.android.apps.work.clouddpc` We also have a JSON configuration supplied from the Intune portal. Has anyone seen this behaviour before where enrollment fails right after Microsoft authentication and redirects to an incorrect URL? Is this likely related to the Zero-Touch configuration JSON, the DPC, or a known issue with Intune handover? Any guidance would be greatly appreciated. Thank you!
[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 Kris
