⏳
Grace periodGive new devices time to check in
Set a 1 to 3 day grace period so a newly enrolled device isn't marked non-compliant before its first full policy sync completes.
Enrollment, Compliance, Apps, and Endpoint Security
A working reference for running Intune day to day: how a device actually gets enrolled, what makes it compliant, how configuration profiles and apps get delivered, and what to check first when a device won't provision or a deployment silently fails. Built from real deployment work, not the feature list.
Intune manages a device by first getting it trusted into Entra ID, then enrolling it into MDM so policy and apps can actually be delivered. The enrollment method you pick decides how much of that happens automatically versus how much a user has to do by hand.
| Method | Scenario | User effort |
|---|---|---|
| Windows Autopilot, user-driven | New or reset PC, user completes OOBE with their own credentials | Low, sign in once |
| Windows Autopilot, self-deploying | Kiosks and shared devices, no user sign-in needed at all | None |
| Autopilot pre-provisioning (white glove) | IT or a reseller does the heavy provisioning before the device reaches the end user | Very low, just a few final checks |
| Co-management | Existing SCCM-managed device, workloads gradually shifted to Intune | None, transparent to the user |
| BYOD / personal enrollment | Personal phone or laptop enrolling for app-level access only | Moderate, installs Company Portal, accepts management scope |
| Profile | Behavior |
|---|---|
| User-driven | Standard flow, device joins Entra ID as the signed-in user, most common for laptops shipped to employees |
| Self-deploying | No user interaction, device joins Entra ID as itself, used for kiosks and meeting room devices |
| Pre-provisioned (white glove) | Splits provisioning into a technician phase and a user phase, shortens what the end user has to wait through |
Assign the ring group before shipping the device, not after. A device sitting in the wrong ring on day one is much harder to fix once the end user is already working on it.
A compliance policy alone does nothing to sign-in behavior; it only produces a compliant or non-compliant label on the device. The label only matters once a Conditional Access policy actually checks it.
| Check | Platform | Why it matters |
|---|---|---|
| Require BitLocker / device encryption | Windows / iOS / Android | Data protection if the device is lost or stolen |
| Minimum OS version | All | Keeps out unpatched, end-of-support builds |
| Defender / antivirus active | Windows | Confirms real-time protection hasn't been disabled |
| Jailbreak or root detection | iOS / Android | Blocks devices with security controls bypassed |
| Password or PIN required | All | Baseline device-level access control |
Set a 1 to 3 day grace period so a newly enrolled device isn't marked non-compliant before its first full policy sync completes.
Configuration profiles are how device settings actually get pushed. Reach for the Settings Catalog for anything new; keep the older profile types only for the handful of cases they still cover better.
| Profile type | When to use |
|---|---|
| Settings Catalog | Default choice, searchable, most complete going forward |
| Administrative Templates | ADMX-backed settings not yet in the Settings Catalog, or migrating a known GPO setting directly |
| Custom (OMA-URI) | Brand-new CSP not yet exposed anywhere in the UI |
| Endpoint security baselines | Fast-start hardening defaults before fine-tuning individual settings |
| App configuration policies | Feeding settings into a managed app itself, not the OS (for example, Outlook mobile config) |
OMA-URI: ./Vendor/MSFT/Personalization/DesktopImageUrl Data type: String Value: https://yourcdn.com/wallpaper.jpg
OMA-URI: ./Vendor/MSFT/Policy/Config/Start/HideTaskViewButton Data type: Integer Value: 1
OMA-URI: ./Vendor/MSFT/Policy/Config/ApplicationManagement/DisableStoreOriginatedApps Data type: Integer Value: 1
App protection policies wrap data protection controls around a managed app (copy/paste restrictions, require PIN to open, selective wipe) without requiring the whole device to be enrolled. This is the right tool for BYOD phones where the user won't accept full device management, but still needs corporate email or Teams access.
Deployment type, assignment intent, and detection rules are the three things that decide whether an app install actually succeeds versus silently sits in "Pending" forever.
| Type | Format | Best for |
|---|---|---|
| Win32 app | .intunewin package built with the Win32 Content Prep Tool | Traditional EXE/MSI installers, most line-of-business apps |
| Line-of-business (LOB) | Raw MSI/APPX uploaded directly | Simple single-file installers with no custom detection needed |
| Microsoft Store app (new) | Reference to the Store catalog | Consumer and modern Store-distributed apps |
| Web link | Just a URL shortcut | Web apps that don't need a local install |
| Intent | Behavior |
|---|---|
| Required | Installs automatically, no user action needed |
| Available for enrolled devices | Shows in Company Portal, user chooses to install it |
| Uninstall | Removes the app from targeted devices |
msiexec /i "app.msi" /qn /norestart
Use a registry key, file version, or MSI product code, whichever is most reliable for that specific app. A bad detection rule is the single most common reason an app shows "Installed" when it isn't, or loops endlessly trying to reinstall.
| Code | Meaning |
|---|---|
| 0 | Success |
| 3010 | Success, reboot required |
| 1603 | Fatal error, check the MSI log |
| 1618 | Another install already in progress |
Autopilot's whole value is that a device can go straight from the box to fully configured without IT ever touching it. That only works if the hardware hash is registered and the right profile is assigned before the box gets opened.
Install-Script -Name Get-WindowsAutopilotInfo -Force Get-WindowsAutopilotInfo -OutputFile "C:\Temp\autopilot-hash.csv"
Devices > Enrollment > Windows Autopilot Deployment Program > Devices > Import. Most OEMs also register hashes directly at the reseller/manufacturer level, skipping this step entirely for new purchases.
Set a group tag at registration time (or via the reseller), then use a dynamic Entra ID group rule based on that tag to auto-assign the right Autopilot profile without manual per-device work.
| Setting | What it controls |
|---|---|
| Block device use until required apps install | Whether the user can skip past the ESP before critical apps land |
| Allow users to reset device if installation error occurs | Gives a self-service recovery path instead of a stuck screen and a help desk call |
| Timeout | How long ESP waits before showing an error, tune this to match your slowest typical app install, not the average |
Endpoint security profiles are Intune's curated, security-focused settings surface, split into categories that map closely to how a security team actually thinks about hardening.
| Category | Configures |
|---|---|
| Antivirus | Defender real-time protection, cloud-delivered protection, scan schedules, exclusions |
| Disk encryption | BitLocker method, recovery key escrow to Entra ID, startup authentication |
| Firewall | Domain/private/public profile rules, logging, inbound/outbound rules |
| Endpoint detection and response | Defender for Endpoint onboarding, sample submission, tamper protection |
| Attack surface reduction | ASR rules blocking common malware behaviors (Office macros spawning processes, credential theft, etc.) |
| Account protection | Windows Hello for Business, credential guard |
Endpoint Security > Microsoft Defender for Endpoint > enable the connector, then compliance policies can factor in the device's Defender risk score, not just local antivirus state.
Every ASR rule supports an audit-only mode that logs what would have been blocked without actually blocking it. Run in audit for at least a week before switching to Block, ASR rules have real false-positive potential against legitimate scripts and macros.
Fast commands for common Intune situations.
Sync-MgDeviceManagementManagedDevice -ManagedDeviceId $deviceId
Or locally: Settings > Accounts > Access work or school > Info > Sync.
Restart-Service -Name IntuneManagementExtension -Force
Use when Win32 app or script deployments are stuck pending. This restarts the local sync agent without a reboot.
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\ IntuneManagementExtension.log Win32AppInventory.log
Settings > Accounts > Access work or school > Info > Create report
Invoke-MgWipeDeviceManagementManagedDevice -ManagedDeviceId $deviceId Invoke-MgRetireDeviceManagementManagedDevice -ManagedDeviceId $deviceIdWipe returns the device to factory settings, retire only removes company data and management. Confirm which one before running it.
Get-MgDeviceManagementDeviceConfigurationDeviceStatus -DeviceConfigurationId $configId | Select-Object DeviceDisplayName, Status, LastReportedDateTime
Get-MgDeviceManagementManagedDevice -Filter "complianceState eq 'noncompliant'" | Select-Object DeviceName, UserPrincipalName, ComplianceState
The errors and symptoms that show up most often in the field, with the fastest verified fix for each.
| Symptom / code | Likely cause | Fix |
|---|---|---|
| 0x80180014 | Enrollment blocked by a device type restriction or the device limit per user has been reached | Check enrollment restrictions and per-user device limits in Intune |
| 0x87D1FDE8 | Sync failure, often policy conflict or a corrupted local MDM certificate | Re-sync; if it persists, check dsregcmd /status for a valid MDM enrollment token |
| Win32 app stuck on Pending | Intune Management Extension isn't running or hasn't picked up the assignment yet | Restart the IntuneManagementExtension service, check its log for the specific error |
| App installs but shows as failed in Intune | Detection rule doesn't match what actually got installed | Verify the detection rule against the real install path, registry key, or MSI product code |
| Device never receives any policy at all | Device isn't actually enrolled, or MDM auto-enrollment scope excludes the user | dsregcmd /status to confirm join state; check Entra ID Mobility (MDM) scope is set to include the user |
| Autopilot device skips ESP entirely or shows wrong profile | Hardware hash matched to the wrong deployment profile, or profile wasn't assigned before the device booted | Confirm the serial number's assigned profile in the Autopilot devices list before shipping |
| ESP times out on required apps | An app in the required list is genuinely failing, or the timeout is shorter than the slowest app's real install time | Check the specific app's install log first, only raise the timeout after confirming the app itself works |
| Compliance policy shows "Not applicable" | Policy platform doesn't match the device's actual OS, or the assignment doesn't include that device's group | Confirm platform and group assignment on the policy match the device exactly |