Most Intune deployments that go wrong don’t go wrong because of a bad policy setting.
They go wrong because of decisions made in the first week — how groups were structured, how profiles were named, how compliance was scoped — that nobody questioned until six months later when everything is a mess and you’re untangling it under pressure.
This guide covers the structural decisions that matter before you touch a single policy. We’ve seen what happens when these get skipped. It’s not pretty.
1. Confirm your MDM authority first
Where: Intune admin centre → Tenant administration → Tenant status
Before anything else, confirm your MDM authority is set to Intune.
If you’re in a co-management scenario with Configuration Manager, document the workload split clearly — which workloads sit in Intune, which stay in SCCM. This is not a decision to leave ambiguous. Ambiguous workload splits cause policy conflicts that are genuinely hard to debug because the symptoms look like policy misconfiguration when the real issue is ownership overlap.
The decision: cloud-only Intune, or co-managed with SCCM? Make the call, document it, tell everyone involved. Everything else flows from this.
2. Naming conventions
This sounds like admin overhead. It isn’t.
Six months into a deployment, you will be looking at a list of configuration profiles named “Policy1”, “New Policy – Copy”, “Test”, and “BitLocker (old)”. You will not remember what any of them do or which devices they target. This is not hypothetical — we have inherited tenants in exactly this state.
Use a consistent format from day one:
[Platform]-[Scope]-[Purpose]-[Version]
Examples:
WIN-ALL-BitLocker-v1WIN-CORP-DefenderAV-v2iOS-BYOD-AppProtection-v1MAC-ALL-FileVault-v1
Platform prefixes: WIN / iOS / MAC / ANDROID
Scope: ALL (every device of that type), CORP (corporate-owned), BYOD (personal devices)
Version: increment when you make a breaking change, not when you tweak a setting
Apply this to configuration profiles, compliance policies, app assignments, and enrollment profiles. Every single one. The 10 minutes it takes to think about naming on day one saves hours of confusion later.
3. Group design
Groups are how Intune targets everything — policies, apps, enrollment profiles, update rings. Poor group design is the most common structural problem we see in inherited tenants.
The rule: use dynamic groups wherever possible. Static groups require someone to manually add and remove members. Dynamic groups self-manage based on Entra ID attributes. In a tenant with hundreds of devices and staff turnover, static groups drift. Dynamic groups don’t.
Device group structure that works:
Intune - All Devices (dynamic: all enrolled devices)
├── Intune - Windows Devices (dynamic: deviceOSType eq "Windows")
│ ├── Intune - Windows Corporate (dynamic: deviceOwnership eq "Company")
│ └── Intune - Windows BYOD (dynamic: deviceOwnership eq "Personal")
├── Intune - iOS Devices (dynamic: deviceOSType eq "iPhone")
├── Intune - macOS Devices (dynamic: deviceOSType eq "Mac")
└── Intune - Android Devices (dynamic: deviceOSType eq "Android")
User group structure:
Intune - All Users (dynamic: all licensed users)
├── Intune - Pilot Users (static: your test group, 10-20 people)
└── Intune - Excluded Users (static: service accounts, break-glass, kiosk devices)
Two rules that matter most:
Never target the built-in “All Users” or “All Devices” groups for anything you wouldn’t want on literally every object in the tenant. These groups include service accounts, external guests, and shared devices. We have seen Defender for Endpoint onboarding policies accidentally target a shared reception kiosk because someone used “All Devices” without thinking.
Always create an exclusion group. Add it as an exclusion to every compliance policy. Put service accounts, kiosk devices, and shared devices in it from day one. You will add more later.
4. Enrollment profiles
Your enrollment profile determines what happens when a device first connects to Intune. Get this right and devices arrive in the correct state without anyone touching them manually. Get it wrong and you’re reimaging devices.
Windows Autopilot:
Two profiles minimum — user-driven and self-deploying.
- User-driven: standard for corporate laptops. User goes through OOBE, authenticates with their M365 account, device provisions automatically.
- Self-deploying: for kiosk devices and shared machines. No user interaction. Device provisions without anyone signing in during setup.
Name them clearly: WIN-CORP-Autopilot-UserDriven-v1 and WIN-CORP-Autopilot-SelfDeploy-v1.
iOS/iPadOS:
- Corporate devices → Automated Device Enrollment (ADE) via Apple Business Manager. Full MDM control.
- BYOD → User Enrollment. Limited management scope, respects the personal/work separation iOS enforces.
Do not enrol personal iOS devices via standard Device Enrollment (full MDM). Users will push back and they’re right to. App Protection Policies handle BYOD iOS without needing device enrolment.
Android:
- Corporate devices → Android Enterprise fully managed (COBO) or dedicated (kiosk).
- BYOD → Android Enterprise work profile. Corporate apps and data sit in an isolated work container.
Don’t use legacy Device Administrator enrolment for anything new. It’s deprecated, it’s being removed, and it gives you less control than Android Enterprise anyway.
5. Compliance policies
Compliance policies define what a “compliant” device looks like. A device that fails compliance can be blocked from corporate resources via Conditional Access — but only if you’ve wired up that connection.
This is the most common gap we see: compliance policies exist, everything is reporting, but Conditional Access doesn’t reference compliance state. The result is compliance is purely informational. Non-compliant devices still get full access. Intune is consuming licence spend while providing no actual security gate.
Minimum compliance baselines:
Windows:
- OS minimum version (set to what you actually support — don’t set it so high that half your estate is immediately non-compliant)
- BitLocker: Required
- Secure Boot: Required
- Code integrity: Required
- Defender Antivirus: Required
- Firewall: Required
iOS:
- OS minimum version
- Jailbreak detection: Block
- Device threat level: Secured or Low (if using Defender for Endpoint mobile)
macOS:
- OS minimum version
- FileVault: Required
- Firewall: Required
- Gatekeeper: App Store and identified developers
Non-compliance grace period: set 7 days before blocking kicks in. This gives users time to resolve issues without being locked out on day one. Skip this and your helpdesk gets hammered on the first morning.
After creating compliance policies, create the Conditional Access policy that enforces them. Compliance without enforcement is just a report.
6. Configuration profiles
A few rules that save significant pain later:
One purpose per profile. Don’t bundle BitLocker settings and Defender settings into the same profile. When something needs changing, you want to update one profile without risking unrelated settings. We’ve seen admins afraid to touch a profile because it controls ten different things and nobody’s sure what’s safe to change.
Use the Settings Catalog, not Templates. Templates are being deprecated. Settings Catalog gives you more granular control and is where Microsoft is investing. Any new profile you create should use Settings Catalog.
Build in this order:
- Security baseline (start with the Microsoft-provided baseline, customise from there)
- BitLocker / FileVault
- Defender for Endpoint onboarding
- Windows Update rings
- Network (Wi-Fi, VPN if needed)
- Device restrictions
Don’t try to build everything at once. Stand up the security baseline and Defender onboarding first, validate they work in your pilot group, then layer the rest.
7. App deployment
Four assignment types in Intune. Using the wrong one causes either silent failures or users being unexpectedly blocked.
Required — deploys silently, no user interaction. Use for security tools, endpoint agents, business-critical software that must be present on every device.
Available — appears in Company Portal, user installs on demand. Use for optional productivity apps.
Uninstall — removes the app. Test in pilot first, always. We have seen Uninstall assignments accidentally target the wrong group and remove business-critical software from production devices.
Available for enrolled devices — Company Portal only, for managed devices.
The mistake everyone makes: assigning everything as Required to All Devices. Scope Required assignments tightly. A device that’s trying to install 30 Required apps simultaneously will be slow, will generate helpdesk calls, and will be harder to troubleshoot when something fails.
For Microsoft 365 Apps, use the native Microsoft 365 Apps deployment type in Intune. Don’t package it as a Win32 app — you’ll miss out on channel management and update controls that come with the native type.
8. Windows Update rings
Update rings control when devices receive Windows quality and feature updates. You need three rings minimum.
Pilot ring: your IT team and volunteer early adopters. Gets updates immediately. Catches issues before they reach the wider estate.
Broad ring: the majority of devices. 7–14 day deferral for quality updates after Pilot has validated them.
Deferred ring: critical systems, VIP users, devices that need extra stability. 21–28 day deferral.
For Feature Updates (major Windows versions), use a separate Feature Update profile with explicit version targeting. Don’t let feature updates ride on the same timeline as quality updates — they carry more risk and need separate validation.
Pre-deployment checklist
Run through this before you go live with anything:
| # | Item | Done? |
|---|
| 1 | MDM authority confirmed | ☐ |
| 2 | Naming convention documented and agreed | ☐ |
| 3 | Dynamic device and user groups created and tested | ☐ |
| 4 | Exclusion group created, added to all compliance policies | ☐ |
| 5 | Enrollment profiles configured per platform | ☐ |
| 6 | Compliance policies created for each platform | ☐ |
| 7 | Conditional Access linked to compliance state | ☐ |
| 8 | Non-compliance grace period set | ☐ |
| 9 | Configuration profiles built (one purpose per profile) | ☐ |
| 10 | App assignments scoped correctly, not targeting All Devices | ☐ |
| 11 | Update rings configured (Pilot / Broad / Deferred) | ☐ |
| 12 | Everything tested in pilot group before broad rollout | ☐ |
If you’re taking over an existing tenant rather than starting fresh, run through this list against what’s already there. The gaps are almost always in items 4, 7, and 10.
Related reading