[Day 6] - Introducing a mobile first/only digital environment, Android-based.
In a rapidly changing industrial landscape, innovation now hinges on fully integrated mobility at the heart of digital tools. The transition from Windows to android devices is no longer simply about swipping devices; it requires rethinking the work environment itself, freeing it from the constraints of fixed workstations in favor of mobile, agile solutions grounded in real-world situations. With this in mind, our SMART MOBILITY project addresses the growing demand for efficient and secure mobile solutions in industrial environments as a first step. We have designed a secured work environment natively for smartphones, capable of covering all the daily tasks of a field worker. This comprehensive, fully mobile approach aims to replace PC use where it becomes cumbersome, providing a high-performance, sustainable alternative that better aligns with the expectations of new generations, who prioritize intuitive, mobile interfaces accessible in all circumstances. What's next : stay tuned :) it is only the beginning !đ Vincent Turquet Yann Roland
[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.[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 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.
[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 KrisDo 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
Restoring Data on a Fully Managed (Device Owner) Android Device During Enrollment
Hello everyone, Iâm testing the setup (enrollment) of a Device Owner / Fully Managed Android device, and Iâve run into a question about restoring data. When setting up a personal Android device, you typically get the option to sign in with a Google account and restore apps/data from a backup. However, when I try this on my test device with the fully managed (Device Owner) enrollment flow, it goes straight into the MDM provisioning process. I donât see the Google sign-in page or any option to restore data from my Google backup. My questions: Is this the expected behaviour for Device Owner (fully managed) setups? Are there any official guides or best practices for restoring user data in this scenario (if supported)? Thanks in advance for any guidance or documentation links!Share your deployment experiences with Android zero-touch enrollment
Hey everyone, In â5 Overlooked Benefits of Android Enterpriseâ, we touched on Android zero-touch enrollment, and itâs something many of you are actively using to streamline your device rollouts. For those in IT, Android zero-touch can be a powerful tool - see our handy guide to learn more. Itâs about getting devices to your users ready to go, automatically enrolling in your EMM and pulling down all the right policies as soon as they connect. That means less hands-on time for your team and a smoother experience for end-users. We know real-world deployments always have their nuances, but it would be great to hear about your deployment experiences using zero-touch enrollment: Did you overcome any unexpected hurdles? What was the scale of your deployment - a few devices for new joiners, or hundreds for a company-wide refresh? If you could share one key tip or best practice for someone looking to nail their next zero-touch deployment, what would it be? Weâre all here to learn from each otherâs stories, and your insights are super valuable. Iâm looking forward to reading your stories! Chat soon, EmilieWhat security threats do you experience the most?
Hey everyone, Stop what youâre doing - episode 2 of The Secure Element is out now! Tune in as Bigdogburrâ and Theresa Lanowitz, Chief Cybersecurity Evangelist at LevelBlue, dive into achieving cyber resilience in an era of boundaryless computing. Their discussion truly reinforced for me just how vital a holistic approach to securing all end-user computing is - from laptops to mobiles, and everything in between - especially with cyberattacks becoming so sophisticated. The role AI plays in crafting these increasingly targeted attacks was a real eye-opener! This episode got me thinking about the real-world threats weâre all facing. What are the kinds of cyber threats you are most confronted with? Cast your vote in the comment section below: Phishing / Quishing/ Smishing (Email, SMS, or QR code tricks) Deepfakes (Convincing fake video/ voice calls) Malicious apps (Apps designed to steal data/ compromise devices) Network attacks (Rogue or Spoofed Wi-Fi, man in the middle, etc.) Other (please share more details in the comments!) And share some wisdom! Do you have some tips on how to identify a cyber attack? If youâve been targeted, whatâs one key lesson learned that you think everyone should hear? Looking forward to reading your stories. Chat soon, EmilieWhat OS rel. your Android fleet is running ?
I'm just curious to know how other corporates doing OS patching. We at SAP only allow 2 latest OS versions which means today we only support Android 14/13. Our Android fleet is approx. 10 000 devices. Mixed Samsung and Google Pixel, no other manufacturers allowed. 70% of our Pixel devices running already Android 14 11% of our Samsung devices running already Android 14 How about yours?
