Part 1 walked through the four management profiles[cite: 2]. Now, let’s talk about how you actually get a phone into one of them[cite: 2]. Android offers five real enrollment paths, and they aren’t one-size-fits-all[cite: 2]. Pick the wrong one for your setup, and you’ll easily turn a quick five-minute unboxing into an entire afternoon of manual tweaking per phone[cite: 2]. ...
If you’re coming over from the Windows side of Intune, Android feels like a whole different beast on day one — because it is[cite: 1]. Windows management pretty much assumes one device, one main user, and one company owning the hardware[cite: 1]. Android, on the other hand, has to handle personal phones, shared devices, front-desk kiosks, and fully corporate-owned hardware all under the same MDM umbrella — sometimes even within the same tenant[cite: 1]. Before you start enrolling anything, you really need to map out your setup, or you’ll be spending the next few months untangling enrollment decisions[cite: 1]. ...
Five parts down, and we’re wrapping up the series with the stuff that rarely makes it into official docs — the actual quirks and gotchas you only learn by running into them firsthand[cite: 5]. If you’ve been following along from Part 1, this final piece will save you a ton of headaches down the road[cite: 5]. ...
Four parts in, you’ve got devices enrolled (Parts 1–3) and apps deployed (Part 4)[cite: 4]. This is where everything turns into a solid security posture rather than just a collection of working settings[cite: 4] — covering compliance policy design, how to actually choose between MAM and MDM, and the Android-specific Conditional Access quirks that love to trip up Windows admins[cite: 4]. ...
Once your devices are enrolled using the methods from Part 2, the next immediate job is getting the right apps onto them — and locking down the wrong ones. On Windows, you might be used to pushing .msi or .win32 packages through Intune. On Android Enterprise, app management runs through a completely different pipeline: Managed Google Play. ...
Part 2 named Zero Touch as the enrollment method that actually scales[cite: 3]. Let’s break down what’s actually happening under the hood[cite: 3]. “The device just configures itself” sounds like magic until you see the plumbing — but once you understand it, you’ll actually know how to troubleshoot it when something goes sideways[cite: 3]. ...
Everything covered so far in this series works the same way regardless of company size — the mechanics of enrollment, compliance, Conditional Access, app deployment, and baselines don’t change because the org is a non-profit. What changes is the constraints: a much thinner budget, often a very small IT team (sometimes exactly one person wearing every hat), and a board that reasonably wants to know why any dollar isn’t going toward the mission. This post is about running Intune well inside those constraints, drawn from real lean-IT-shop experience rather than enterprise assumptions. ...
Every part of this series so far has been about building capability into Intune — enrollment, compliance, access control, apps, baselines. This last one is about the flip side: everything that makes Intune powerful for administration makes it equally powerful for whoever manages to compromise the administrative layer. Whoever controls Intune can push scripts, alter configurations, and remotely wipe devices across an entire fleet in one coordinated action — and in March 2026, that stopped being a theoretical concern. ...
Part 3 ended on a deliberately uncomfortable note: a compliance policy by itself doesn’t block anything. It grades a device and moves on. This post is the other half of that pairing — Conditional Access is the piece that actually turns “this device is noncompliant” into “this device doesn’t get in.” ...
Here’s an uncomfortable fact about compliance policies that a lot of tenants learn the hard way: a compliance policy, on its own, doesn’t block anything. It evaluates a device against a set of rules and labels it Compliant or Not Compliant — that’s it. Nothing downstream actually happens unless something else is watching that label and acting on it. Get this wrong and you can have a fully built-out compliance policy that’s pure checkbox theater, catching real problems and doing absolutely nothing about them. ...