Reporting, Remediations & Day-2 Operations
Microsoft Intune · Endpoint Analytics · Remediations · Operations · SMB · 2026
Most Intune projects fail quietly after deployment — not because the configuration is wrong, but because nobody builds an operational rhythm to keep it healthy. Parts 1 through 5 built the environment: devices enrolled, compliant, configured, stocked with software, hardened and defended. That is the foundation. The organisations that get lasting value from it are the ones that follow through — the right reports checked at the right frequency, small fixes automated so they never become tickets, and a clear picture of the estate's health at any point in time.
This final part covers the reports that matter and when to read them, Endpoint Analytics as a signal for device experience problems before users complain, Remediations as an automation layer that silently fixes recurring issues, and the weekly/monthly/quarterly habits that keep a well-built Intune environment from slowly drifting out of control.
WIN-BitLocker-SMB-Baseline-v1) and a version increment on every significant change is significantly easier to hand over, audit, or troubleshoot 18 months later than one that was built fast without documentation discipline.The reports that matter — and when to read them
Intune surfaces dozens of reports. Most of them are useful for investigation but not for routine monitoring. The three below are the ones an SMB admin should build into a regular check — everything else is for when something is already wrong.
| Report | Path in Intune | What to look for | Frequency |
|---|---|---|---|
| Device compliance | Devices → Monitor → Device compliance | Non-compliant count. Any device that has been Non-compliant for more than 24 hours needs investigation — either a genuine issue or a stale check-in. | Weekly |
| Device configuration | Devices → Monitor → Device configuration | Conflict and Error counts by profile. A profile with a growing conflict count often means a new policy overlapped with it — investigate before it spreads. | Weekly |
| App install status | Apps → Monitor → App install status | Failed deployments. A Required app with a non-zero failure count on enrolled devices needs attention — users may be missing critical software silently. | Weekly |
| Windows Update compliance | Reports → Windows updates → Windows 10 and later update rings | Devices not receiving quality updates within your deadline window. A device that is 30+ days behind on patches is a security gap, not just an operational one. | Monthly |
| Defender for Business alerts | security.microsoft.com → Incidents & alerts | Any active Medium or High severity alert. Low alerts can batch to weekly review; anything above that warrants same-day attention. | Daily (Medium/High), Weekly (Low) |
Endpoint Analytics
Endpoint Analytics is a reporting layer within Intune that measures the user experience of managed devices — not whether they are compliant, but whether they are actually performing well for the people using them. It is found at Reports → Endpoint analytics.
The overall score (0–100) aggregates five sub-scores. Each sub-score benchmarks your environment against other organisations using Intune. More useful than the scores themselves are the per-device breakdowns — which specific devices are dragging a score down and why.
| Score | What it measures | Actionable signal |
|---|---|---|
| Startup performance | Time from power-on to a responsive desktop, broken down by boot time, sign-in time, and Group Policy/profile load time | Devices consistently in the bottom percentile for boot time often have too many startup items, slow storage, or an undersized RAM configuration. The breakdown identifies where the time is actually going. |
| App reliability | Application crash and hang rates across managed devices | An app with a high crash rate fleet-wide often has a compatibility issue with a Windows update or a specific hardware configuration. Identify the pattern before it generates helpdesk volume. |
| Work from anywhere | Whether devices meet Microsoft's recommended configuration for remote work — cloud identity, Intune management, cloud-managed updates, cloud-delivered protection | Devices with a low score are often partially managed — enrolled in Intune but missing cloud-delivered protection or not fully Entra joined. Use as an audit list. |
| Battery health | Estimated battery remaining capacity vs original capacity (requires Windows 11 or Windows 10 21H2+) | Devices below 50% battery health are candidates for battery replacement before the user complains of short runtime. A proactive replacement costs less than an emergency swap during a meeting. |
| Recommended software | Adoption of Windows 11, Microsoft 365 Apps, and Autopatch across managed devices | Use as a migration progress tracker — how many devices are still on Windows 10, how many have not yet received the M365 Apps deployment. |
Remediations — automated detect-and-fix
Remediations (found at Devices → Scripts and remediations → Remediations) are pairs of PowerShell scripts — a detection script and a remediation script — that Intune runs on a schedule on managed devices. The detection script checks whether a condition is met. If it returns exit code 1 (issue found), Intune runs the remediation script to fix it. If it returns exit code 0 (all good), Intune does nothing. The cycle repeats on every run according to the schedule you configure.
The practical use case is anything that is either too granular to configure via a Settings Catalog profile, or that needs to be re-checked and re-applied over time rather than set once. Common examples include: ensuring the Windows time service is running and syncing correctly, confirming a specific registry value is set after a third-party application modifies it, clearing application caches that accumulate and cause performance issues, and verifying that a local admin account does not exist on the device.
Detection and remediation script structure
Every Remediation follows the same contract:
- Detection script returns exit 0 → device is compliant, no remediation runs, Intune reports "Without issues"
- Detection script returns exit 1 → issue detected, Intune runs the remediation script and reports "With issues"
- Remediation script runs and succeeds → Intune reports "Remediated" on the next detection cycle
- Remediation script runs and fails → Intune reports "Remediation failed" — check the script output in the device status view
Write-Output produces — one clear result line is far easier to scan across a fleet than verbose console output. Write statements like "Time service healthy" or "Time drift excessive: 45s" rather than dumping full diagnostic text. The goal is a status column you can read at a glance across 100 devices.
Worked example: Windows Time Service health check
Devices with a drifted system clock cause Kerberos authentication failures, certificate errors, and — relevant to this series — compliance check failures where the timestamp does not match the server. The Windows Time service (w32tm) should be running, set to sync with a reliable source, and not drifted beyond a few seconds. This is simple enough to check manually once; automated with a Remediation, it self-heals on any device where the service gets stopped or misconfigured.
time.windows.com directly. In environments with a local NTP server or strict firewall rules, replace the target with your internal time source or remove the drift check and monitor only service status.
# Returns exit 0 (healthy) or exit 1 (issue detected)
try {
$svc = Get-Service -Name 'w32time' -ErrorAction Stop
if ($svc.Status -ne 'Running') {
Write-Output "w32tm service not running: $($svc.Status)"
exit 1
}
# Check time drift — warn if > 30 seconds off
$drift = (w32tm /stripchart /computer:time.windows.com /samples:1 /dataonly 2>&1 |
Select-String '\+' | Select-Object -Last 1).ToString()
if ($drift -match '\+(\d+\.\d+)') {
$seconds = [double]$Matches[1]
if ($seconds -gt 30) {
Write-Output "Time drift excessive: ${seconds}s"
exit 1
}
}
Write-Output "Time service healthy"
exit 0
}
catch {
Write-Output "Detection error: $_"
exit 1
}# Runs only when detection returns exit 1
try {
# Ensure service is set to automatic and running
Set-Service -Name 'w32time' -StartupType Automatic
Start-Service -Name 'w32time' -ErrorAction Stop
# Re-register and force sync
w32tm /unregister | Out-Null
w32tm /register | Out-Null
w32tm /resync /force | Out-Null
Write-Output "Time service restarted and synced"
exit 0
}
catch {
Write-Output "Remediation failed: $_"
exit 1
}WIN-Remediation-TimeService-v1. Upload the detection script and remediation script separately. Set Run script in 64-bit PowerShell to Yes. Set Run this script using logged-on credentials to No (runs as SYSTEM).Operational rhythm
The goal is not to spend hours in the Intune portal every week. The goal is a consistent, lightweight check that catches drift before it becomes an incident. The tasks below are sized for a single IT admin managing an SMB estate of 20–200 devices.
Long-term hygiene — keeping the environment maintainable
Intune environments do not suddenly become unmaintainable — they drift there gradually. A policy created without a description. A group named "Test2-Final" that became permanent. A Remediation that no one remembers writing. The following habits cost almost nothing to adopt at the start and pay significant dividends when you are troubleshooting an issue at 17:45 on a Friday.
Naming conventions
Adopt a consistent pattern and use it for every object in Intune: profiles, baselines, groups, remediations, apps. A pattern like [Platform]-[Type]-[Scope]-[Version] — for example WIN-Compliance-SMB-Baseline-v1 or WIN-Remediation-TimeService-v1 — is readable in list views, filterable, and self-documenting. When you update a policy significantly, increment the version rather than editing in place. This preserves the history of what changed and when.
Descriptions on everything
Every policy, profile, group, and Remediation in Intune has a Description field. Fill it in. At minimum: what the policy does, the date it was created, and the reason it exists. Future-you and your colleagues will read this description when troubleshooting a conflict six months from now. "Created 2026-03-15 — enforces BitLocker silent encryption per SMB security baseline. See IT Wiki / Intune for full rationale." takes 30 seconds to write and saves hours later.
Test before fleet
Every policy change — whether a new profile, a Remediation update, or a baseline version migration — should be assigned to a pilot group of 2–5 devices before expanding to the full fleet. The pilot group should include at least one device with a non-standard configuration (an older machine, a device with more software installed, a device used by a power user). Issues that appear in the pilot group rarely appear fleet-wide. Issues that appear fleet-wide are always harder to roll back.
Document your deviations
Whenever you override a baseline setting, exclude a device from a policy, or make an exception to a compliance rule, write it down. A short internal page or even a comments column in a spreadsheet is enough. Undocumented exceptions accumulate and eventually become the source of security gaps that nobody can explain — because the person who created the exception left two years ago.
Series completion checklist
This checklist consolidates the key deliverables across all six parts. A fully built SMB Intune environment has everything below in place.
-
Part 1 — Tenant configured, devices enrolled MDM authority set, automatic enrolment enabled, four device/user groups created, first Windows device enrolled and verified with
dsregcmd /status. -
Part 2 — Compliance enforced, Conditional Access active Windows compliance policy with four baseline settings, tenant toggle set to Not compliant, CA policy moved from Report-only to Enabled after validation.
-
Part 3 — Five configuration profiles deployed BitLocker (recovery key escrowed), Windows Hello for Business (PIN active, NgcSet: YES), OneDrive KFM (folders redirected), Edge hardening, Windows Update rings (pilot + production).
-
Part 4 — Software deployed via Intune Company Portal on all devices, M365 Apps deployed to licensed users (Monthly Enterprise Channel, 64-bit), at least one Win32 app packaged and deployed with a version-pinned detection rule.
-
Part 5 — Hardened and defended Windows Security Baseline deployed, M365 Apps and Edge baselines deployed (after conflict check), Defender connector active, devices onboarded to Defender EDR, ASR rules in Audit mode with review scheduled.
-
Part 6 — Operational rhythm established Weekly/monthly/quarterly check schedule documented. At least one Remediation deployed and validated. Endpoint Analytics reviewed. Naming conventions in use across all policies.
-
Operational documentation updated and ready for handover Policy names, group assignments, exceptions, and Remediation purpose recorded in an internal document or IT wiki. Anyone inheriting this environment can understand what each object does, why it exists, and what has been intentionally excluded — without needing to ask.