Intune Unlocked: what four sessions with Microsoft taught us about running Intune at MSP scale

Most MSPs don't struggle with Intune because they don't understand it. They struggle because every tenant got there differently. One customer enrolled devices through a legacy workflow that made sense three years ago. Another has Windows Hello disabled from an old support ticket nobody revisited. A third allows personal iOS devices because no one revisited platform restrictions after rollout. 

That's the gap Nerdio set out to close with Microsoft through Intune Unlocked, a four-part technical series for MSPs. Rolando Jimenez, technical trainer at Nerdio, joined Adam Atwell, Microsoft MVP and CTO/partner at Kite Technology Group, for four live sessions on enrollment, policy and compliance, application management, and AI governance. Microsoft's Intune documentation assumes one IT department managing one tenant. MSPs manage dozens, and enterprise-scale practices don't automatically translate down. 

All four sessions are available on demand. Here's what each covered, and why it matters if you're the one inheriting these tenants six months from now. 

Session one: enrollment done right 

Enrollment is where most MSPs win or lose with Intune, often before a single policy gets applied. Get it wrong, and every downstream decision, policy scope, security posture, support burden, inherits that mistake. 

Atwell spent most of the session on Windows Autopilot v2 and what's changed from v1. Setup time has dropped, but the bigger story is failure recovery. In v1, if an app failed to install before the user reached the desktop, the whole enrollment could stall out completely, sometimes eating an hour with no way to get that time back. In v2, apps and scripts install after the user reaches the desktop, so a failure just means troubleshooting one piece instead of starting over. Jimenez said that change alone has quieted a lot of the "autopilot doesn't even work" complaints he used to field constantly in workshops. 

The session also dug into platform restrictions that get configured instead of left at default, device limit increases for accounts doing mass enrollments, and a candid take on Windows Hello for Business. Atwell's team leaves it disabled during initial enrollment account login and lets compensating MFA controls carry authentication instead, since enforcing biometrics at that stage rarely earns its keep. 

The through-line: consistency is the product. When every device enters management the same way across every tenant, engineers stop comparing configs between customers and start doing higher-value work. 

Watch the full session 1 recording

Session two: policies and compliance at scale 

This is the session that exposes the gap between looking secure and being secure. Atwell put it plainly: a compliance policy without a corresponding conditional access policy isn't a security control. It's a report. 

He described a scenario more common than most MSPs would like to admit: a dashboard showing 97% compliance, presented to a client as proof of a secure environment, while noncompliant devices sat untouched in Exchange, SharePoint, and Teams. Nothing was actually blocking access. The compliance policy was doing its job; nobody had told conditional access to act on the result. 

Atwell's advice for MSPs just getting started: don't jump straight to blocking noncompliant devices on day one. Enabling every conditional access policy immediately on a new tenant tends to surface years of accumulated technical debt all at once, creating disruption for the customer and a flood of avoidable tickets for the MSP. A softer first step, requiring devices to simply be Entra-joined rather than fully compliant, gives customers room to remediate before access gets cut off. 

One detail worth flagging for anyone building these policies: a filter for devices rule, targeting Entra-joined, registered, or hybrid-joined devices, lets an MSP enforce secure sign-in behavior without requiring every device in a tenant to be fully compliant first. Atwell called it one of the more underused tools in the conditional access toolkit. 

Watch the full session 2 recording

Session three: app deployment at scale 

BYOD is already the environment MSPs are managing. Anyone treating it as a "future problem" is already behind. Contractors, field techs on personal phones, executives juggling three devices a day, full device management doesn't fit any of them, and this session addressed the ones that will never be enrolled in Intune. 

The centerpiece was mobile application management, distinct from mobile device management. MAM builds a container around specific apps, typically the Microsoft 365 suite, without requiring ownership of the entire device. Atwell walked through an iOS app protection policy in detail: whether corporate data can back up to iCloud (no), whether it can move between managed apps versus any app, whether users can save copies of work data to personal storage (restricted to OneDrive and SharePoint), and how cut/copy/paste boundaries get enforced between managed and unmanaged apps. 

He was candid about the tradeoffs, recalling how Kite Technology Group once blocked all inbound data to managed apps until users revolted over not being able to paste a web search into a work email. The fix: Allow data in; restrict data out. On Windows, the session covered deploying Microsoft 365 and Edge through the built-in configuration designer, pushing Store apps like VLC via the WinGet-based experience, and wrapping standalone EXEs into the intune.win format when a clean MSI isn't available, still one of the rougher edges of native Intune app management. 

Watch the full session 3 recording

Session four: AI governance and Copilot readiness

The final session tackled the newest, least standardized part of the stack: what happens when a customer starts asking about Microsoft 365 Copilot. Atwell was direct about where most MSPs currently stand, and it isn't far along. AI governance is new enough that many providers haven't figured out an approach, and plenty lack visibility into how AI is already being used inside customer environments. 

Copilot readiness got reframed as a data problem, not a licensing problem. Copilot doesn't generate new information; it surfaces whatever already exists across SharePoint, Teams, and Exchange, including years of oversharing and permission sprawl nobody's cleaned up. Atwell showed how Conditional Access extends into AI-specific risk signals: blocking high-risk agent identities, restricting agent-driven flows through Power Automate, and applying risk-based sign-in policies. That last control requires an Entra P2 license; the rest don't. 

He also walked through Purview sensitivity labels and DLP policies, building a HIPAA-focused DLP template live. His point: label the data first, then let auto-labeling policies apply based on DLP-style content matching, so a Social Security number or DEA number automatically triggers a "highly confidential" label. 

Devices, data, and identity form a triangle, and Intune, Entra, and Purview each cover a side of it. None were built specifically for AI. Together, though, they're the governance foundation that determines whether a customer is actually ready for it. 

Watch the full session 4 recording

Where this leaves MSPs

Enrollment brings a device into management. From there, compliance and Conditional Access keep it there safely, while app protection extends that same control to devices that will never be fully managed. Underneath all of it, governance determines whether the data is actually ready for AI to start touching it. Four separate projects, each reasonable on its own. One operational framework, and they compound, which is the difference between an MSP managing Intune and one managing it efficiently across every tenant in the book. 

If you want the full technical walkthroughs — the actual clicks, not just the recap — all four sessions are available on demand: Intune Unlocked: Technical training for MSPs by Microsoft and Nerdio.