The first time I enforced Intune compliance policies across all enrolled devices at once, we got two weeks of the same helpdesk ticket: "I can't access my work email." The devices weren't broken. The policy was doing exactly what I'd configured it to do. The problem was that I'd given users zero warning that access would be restricted, hadn't briefed the helpdesk team on what to look for, and had skipped the report-only phase that would have shown me how many devices were already failing compliance before I pulled the trigger.
The second time I did an Intune rollout (a different org, roughly 40 endpoints), compliance-related tickets in the two weeks after enforcement dropped by roughly half compared to that first attempt. The Intune configuration itself wasn't dramatically different. The sequence and the communication plan were.
What Microsoft Intune Actually Does
Intune is Microsoft's mobile device and application management platform, part of the Microsoft 365 licensing stack and administered from intune.microsoft.com. It pushes three types of configuration to enrolled devices: compliance policies (rules a device must meet to be considered healthy), configuration profiles (settings applied to the device directly: Wi-Fi credentials, VPN setup, email account configuration), and application management (what apps can be installed, what corporate data can leave a managed app).
The compliance piece is where the helpdesk tickets come from. When you link Intune to Conditional Access in Entra ID, the combination becomes the gatekeeper for M365 services. A device that falls out of compliance (say, BitLocker is off, or the OS is below your minimum version) gets flagged. If your Conditional Access policy requires a compliant device, that device loses access to Exchange Online, SharePoint, Teams, and the rest of the suite until it passes again. The block is instantaneous. The user's experience is: "Everything was fine, now nothing works."
The Compliance Baseline I Set First
Before enrolling a single device, I configure four compliance policies in the Intune admin center. These are the policies that matter most and generate the most ticket risk if you skip them or misconfigure them:
- Minimum OS version. For Windows, I require 22H2 or later. For iOS, 16 or later. For Android, 11 or later. Older OS versions have unpatched vulnerabilities that the rest of your stack cannot fully compensate for. This policy also surfaces devices that haven't been updated in months, which is worth knowing regardless of enforcement.
- Device encryption required. BitLocker on Windows, device encryption on iOS and Android. No exceptions. This is the policy most likely to generate the "BitLocker says compliant but Intune disagrees" ticket (covered below).
- Screen lock required with a minimum PIN or password. This catches personal devices that are enrolled but have never had a lock screen configured. On managed corporate devices, this is usually already set via Group Policy. On BYOD devices, it often isn't.
- Microsoft Defender active with threat definitions current. On Windows, this is built in. On mobile, I use Defender for Endpoint. The policy checks that Defender is running and that the definitions are not stale beyond a threshold you configure (I use 3 days).
The critical step with all four: set them to "report only" before you enforce anything. Report-only mode runs the compliance evaluation and flags which devices would fail, without actually blocking access. In my experience, roughly a quarter to a third of devices in any org fail at least one of these four checks before the first enforcement. That number will surprise you. You want to see it and fix the straightforward failures (outdated OS, missing Defender update) before enforcement, not after.
The Enrollment Sequence That Prevents Chaos
Enrollment order matters as much as policy configuration. Enrolling everyone at once is how you generate a week of helpdesk tickets on day one.
IT team first. Everyone on the IT team enrolls their own devices in the first wave. You will hit every edge case (personal macOS laptops used for work, legacy Windows builds, corporate Android devices that have never been near an MDM) before it affects a single end user. Fix everything that surfaces before you move on.
Pilot group next. Pick 5 to 10 percent of willing early adopters from different departments. These are the people who tend to be in the same meeting as the CTO when their laptop stops working. You want to identify that risk in a controlled group, not in a full rollout. Run the pilot for at least a week, resolve every issue that comes up, and confirm that your helpdesk protocol works before widening the scope.
Department waves after that. One department at a time, with a one to two week gap between each. Finance, operations, and customer-facing teams tend to have the most BYOD devices and the most varied device states, so I usually save those for the second half of the rollout.
The Communication Plan That Most Teams Skip
Three emails before enforcement. This is the step that accounts for the largest share of tickets in a poorly executed rollout, and the easiest to fix.
Email 1, two weeks before enforcement: "What is Intune and why are we deploying it." Four to five sentences. Explain what Intune does (checks that devices meet the org's security baseline), what it does not do (it cannot see personal files, photos, or messages on a device), what devices are in scope, and what the enrollment deadline is.
Email 2, one week before: Step-by-step enrollment instructions. Include screenshots. Link to your helpdesk or a self-service knowledge base article. Be explicit about which devices need to be enrolled: corporate laptops, yes; personal phones used to access company email, yes (and explain why); the old work laptop sitting in a drawer, not necessarily.
Email 3, 48 hours before enforcement: "Access to Microsoft 365 will be restricted starting [specific date and time] for devices that are not enrolled and compliant." Short, clear, and specific. Include the helpdesk contact and a direct link to enrollment instructions.
Brief the helpdesk team on the enforcement date before you send email 1. They should know what is coming and what the three most common Intune tickets look like, not find out when the tickets start arriving.
The Three Tickets You Will Still Get
Even with a clean rollout, some tickets will come in. These three cover almost all of the Intune-related helpdesk volume in my experience:
"I enrolled my device but I still cannot access my email."
Compliance evaluation is not instantaneous. After enrollment, Intune runs a sync cycle to evaluate the device against your policies. This typically takes 15 to 20 minutes but can take longer on a slow network connection or if the device is simultaneously running a Defender definition update in the background.
Resolution: In the Intune admin center, navigate to Devices, find the user's device, and click Sync. This pushes an immediate evaluation request. If the device is compliant, access restores within a few minutes after the sync completes. Tell the user to restart the affected app (Outlook, Teams, etc.) after you've confirmed the sync ran successfully.
"BitLocker is turned on but Intune says the device is not compliant for encryption."
This one catches IT teams off guard. Intune's encryption compliance check does not just verify that BitLocker is running. It also checks whether the BitLocker recovery key is escrowed to Entra ID. If BitLocker was enabled before the device was enrolled in Intune (common on corporate laptops imaged before the Intune rollout), the recovery key may be stored locally or backed up to on-premises Active Directory rather than Entra ID. The compliance evaluation sees no key in Entra and flags the device as non-compliant, even though BitLocker is fully active.
Resolution: Confirm BitLocker is running with manage-bde -status in an elevated command prompt. Then rotate the recovery key to Entra ID by running the following in an elevated PowerShell prompt:
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId (Get-BitLockerVolume -MountPoint "C:").KeyProtector[1].KeyProtectorId
After the key is escrowed, trigger a manual sync in the Intune portal. Compliance status updates within a few minutes.
"My personal phone is blocked from company email."
This surfaces when a Conditional Access policy requires an Intune-compliant device and the user's personal phone was never enrolled. The phone was working fine before enforcement because CA wasn't checking device compliance. Now it is.
There are two paths depending on your BYOD policy. If you want personal phones to access company email with minimal management overhead, the better approach is App Protection Policies (MAM without MDM enrollment). These policies govern corporate data at the app level (what can be copied out of Outlook, whether a PIN is required to open the app) without enrolling the device itself into Intune. If you've already told users they must enroll personal phones, guide them through the Company Portal enrollment process on their device.
The choice between MAM and MDM for personal devices is worth making explicitly before enforcement, not at the helpdesk during a ticket. Document the decision and make sure the pre-enforcement emails reflect it clearly.
What the Second Rollout Looked Like
With the enrollment sequence and the three-email communication plan in place, compliance-related helpdesk tickets in the two weeks after enforcement were roughly half what they'd been in the first rollout. The tickets we did get were almost entirely the three types above, and the helpdesk team could resolve each one from a single reference page without escalating to me.
The Intune configuration didn't change much between the two deployments. The sequencing, the report-only phase, and the communication did. Those three things are where most of the avoidable ticket volume comes from, and none of them require any additional licensing or tooling. They just require doing them in the right order.
If you're planning an Intune rollout or working through a compliance enforcement issue in your M365 tenant, drop me a line. Happy to review your current policy setup and point out where the ticket risk usually sits.
Comments