Detect Devices Not Checking Into Intune with PowerShell · CloudEngineerHub
Detection & Remediation9 min read4 views
Detecting Devices Not Checking Into Intune with PowerShell
Find Windows devices that quietly stopped checking into Intune using local scheduled task and log evidence, and re-trigger their sync with a safe remediation script.
C
CloudEngineerHub Team
Published: September 6, 2026· Last Updated: September 28, 2026·9 min read
Every Intune admin eventually meets the quiet device: it exists in the admin center with a
green-ish "last sync" that is actually weeks old, it may still be logged in and patched
enough to look normal, but it has not pulled policy, run remediations, or reported app
status for far too long. Users rarely notice because the device keeps working, and the
management gap only becomes visible when a deployment reports 90% success and nobody can
explain the missing 10%.
Visual Walkthrough
The engine behind every “Detect with PowerShell” runbook on this site.
Exit 1 flips the device into the remediation queue for this package.
remediate
3
Remediation executes
Fix script runs silently as SYSTEM with a 5-minute budget.
verify
4
Re-run detection
The same detection script must now exit 0 — proof, not hope.
telemetry
5
Results report
Per-device outcome lands in Reports → Remediations for trend analysis.
6
Repeat on schedule
The loop continues — drift gets caught the day it appears.
Continuous cycle
Proactive Remediations — The Detect → Fix → Verify Loop. 1. Detection script runs: Scheduled (daily/hourly): exit 0 healthy, exit 1 unhealthy — nothing more. — 2. Verdict: unhealthy: Exit 1 flips the device into the remediation queue for this package. — 3. Remediation executes: Fix script runs silently as SYSTEM with a 5-minute budget. — 4. Re-run detection: The same detection script must now exit 0 — proof, not hope. — 5. Results report: Per-device outcome lands in Reports → Remediations for trend analysis. — 6. Repeat on schedule: The loop continues — drift gets caught the day it appears.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
The tricky part is that "not checking in" is a claim about the past, and the Intune portal
can only show you its side of the story. This article builds the device-side view with
PowerShell: the EnterpriseMgmt scheduled tasks that drive MDM sync, the last write time of
the Intune Management Extension log, and recent Windows Update history as a secondary
liveness signal. The detection script classifies the device against configurable age
thresholds, and a conservative remediation script re-triggers the sync task when the device
has gone quiet, without restarting services or deleting state.
Everything is designed for the environment your scripts actually run in: 64-bit Windows
PowerShell in SYSTEM context through Intune Scripts and Remediations, structured logging
to C:\ProgramData\Company\Logs, and exit codes that mean the same thing on every device.
Symptoms
Quiet devices usually announce themselves indirectly:
The admin center shows "Last sync" dates in weeks, or the device fails policy and app status reporting while users report nothing wrong.
Remediation packages report the device as "Not applicable" or the device never appears in script status views at all.
Win32 app assignments that shipped weeks ago still show "Waiting for install status" on specific devices.
Compliance reports include devices with stale evaluations, and conditional access decisions are being made on outdated signals.
On the device itself, no task under \Microsoft\Windows\EnterpriseMgmt\ has run recently when you check Task Scheduler history.
A useful confirmation: run a manual sync from the device (Settings → Accounts → Access
work or school → Info → Sync). If the admin center timestamp does not move, you have a real
check-in problem rather than a reporting delay.
Possible Causes
The device is asleep, offline, or rarely used
The most common cause is also the most boring: the device sits in a drawer or a home office
without network access. Scheduled tasks cannot run while the OS is off, and MDM push
notifications cannot wake a device that is unreachable.
The sync scheduled task is failing
The EnterpriseMgmt tasks created at enrollment can fail with non-zero LastTaskResult values
after broken upgrades, expired certificates, or corrupted enrollment state. A failing sync
task produces exactly the quiet-device pattern while everything else on the device looks
fine.
Enrollment state is partial or damaged
Devices with damaged MDM enrollment can still run tasks that fail silently, or lose their
enrollment artifacts entirely. Without EnterpriseMgmt task folders there is nothing left to
schedule, which is a distinct and more serious state than a stale run time.
Network path problems to the management endpoints
Proxy changes, firewall rule updates, or DNS issues can cut the management endpoints while
leaving general internet access intact. Users browse happily; the device cannot reach
Intune.
The device was reimaged or cloned
A clone that kept an old enrollment identity can sync as its source device, leaving the
clone's own record permanently quiet.
Detection Script
The script below is read-only and completes in seconds. It gathers three independent
liveness signals, compares the freshest one against configurable hour thresholds, and
classifies the device. When no EnterpriseMgmt artifacts exist at all, it says so with a
distinct exit code, because that is a different problem than staleness.
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
#Requires -RunAsAdministrator
[CmdletBinding()]
param(
[ValidateRange(1, 336)]
[int] $MaxSyncAgeHours = 72,
[ValidateRange(1, 336)]
[int] $MaxImeLogAgeHours = 72
)
Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
<#
.SYNOPSIS
Detection script: evaluates local Intune check-in health from scheduled
task run times, IME log recency, and Windows Update activity.
.DESCRIPTION
A device that checks into Intune runs its EnterpriseMgmt scheduled tasks
on a regular cadence (roughly every eight hours by default, plus push
triggered syncs). This script gathers:
1. The newest LastRunTime across \Microsoft\Windows\EnterpriseMgmt\*
tasks, and the LastTaskResult of the task behind it.
2. The last write time of the IME log, when the IME is installed.
3. The most recent Windows Update history entry via the COM update
session API - informational only.
This script NEVER changes the system. Exit 0 = check-in signals recent,
1 = check-in signals stale beyond thresholds, 2 = no EnterpriseMgmt
enrollment artifacts (cannot assess), 3 = unexpected error.
#>$logDir = 'C:\ProgramData\Company\Logs'$logFile = Join-Path $logDir'CheckInHealthDetection.log'$imeLogPath = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log'function Write-DetectionLog {
param([Parameter(Mandatory)][string] $Level, [Parameter(Mandatory)][string] $Message)
if (-not (Test-Path $logDir)) { New-Item -Path$logDir -ItemType Directory -Force | Out-Null }
"$([DateTime]::UtcNow.ToString('o')) [$Level] $Message" | Out-File -FilePath$logFile -Append -Encoding utf8
}
try {
Write-DetectionLog 'INFO'"Check-in health detection started. MaxSyncAgeHours=$MaxSyncAgeHours MaxImeLogAgeHours=$MaxImeLogAgeHours." # ---- Signal 1: newest EnterpriseMgmt sync task run ----$mgmtTasks = Get-ScheduledTask -TaskPath'\Microsoft\Windows\EnterpriseMgmt\*' -ErrorAction SilentlyContinue
if ($null -eq$mgmtTasks -or @($mgmtTasks).Count -eq0) {
Write-DetectionLog 'ERROR''No EnterpriseMgmt scheduled tasks found. Without enrollment artifacts, check-in health cannot be assessed locally.'
exit 2
}
$newestRun = [DateTime]::MinValue
$newestTask = 'unknown'$newestResult = $nullforeach ($taskin @($mgmtTasks)) {
$info = Get-ScheduledTaskInfo -TaskName$task.TaskName -TaskPath$task.TaskPath -ErrorAction SilentlyContinue
if ($null -ne$info -and$info.LastRunTime -gt$newestRun) {
$newestRun = $info.LastRunTime
$newestTask = "$($task.TaskPath)$($task.TaskName)"$newestResult = $info.LastTaskResult
}
}
$syncAgeHours = [math]::Round(((Get-Date) - $newestRun).TotalHours, 1)
Write-DetectionLog 'INFO'"Newest sync task run: $newestRun ($syncAgeHours hour(s) ago), task: $newestTask."if ($null -ne$newestResult) {
Write-DetectionLog 'INFO' ("Newest sync task LastTaskResult: {0} (hex {1}). Zero means success; 0x41301 means the task was last seen still running." -f$newestResult, ('0x{0:X}' -f$newestResult))
}
# ---- Signal 2: IME log recency ----$imeLogAgeHours = $nullif (Test-Path -LiteralPath$imeLogPath) {
$lastWrite = (Get-Item -LiteralPath$imeLogPath).LastWriteTime
$imeLogAgeHours = [math]::Round(((Get-Date) - $lastWrite).TotalHours, 1)
Write-DetectionLog 'INFO'"IME log last write: $lastWrite ($imeLogAgeHours hour(s) ago)."
}
else {
Write-DetectionLog 'INFO''IME log not present. The IME installs only when Win32/script content targets the device; treated as neutral here.'
}
# ---- Signal 3: Windows Update interaction (informational) ----try {
$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$history = $searcher.QueryHistory(0, 1)
if ($null -ne$history -and$history.Count -gt0) {
$lastEntry = $history.Item(0)
Write-DetectionLog 'INFO'"Most recent Windows Update history entry: $($lastEntry.Date) (result code $($lastEntry.ResultCode))."
}
else {
Write-DetectionLog 'INFO''Windows Update history is empty.'
}
[void][System.Runtime.InteropServices.Marshal]::ReleaseComObject($searcher)
[void][System.Runtime.InteropServices.Marshal]::ReleaseComObject($session)
}
catch {
Write-DetectionLog 'WARN'"Windows Update history unavailable: $($_.Exception.Message)"
}
# ---- Verdict ----$syncCutoff = (Get-Date).AddHours(-$MaxSyncAgeHours)
$stale = $false$reasons = @()
if ($newestRun -lt$syncCutoff) {
$stale = $true$reasons += "no EnterpriseMgmt sync task ran within $MaxSyncAgeHours hours"
}
if ($null -ne$imeLogAgeHours -and$imeLogAgeHours -gt$MaxImeLogAgeHours) {
$stale = $true$reasons += "the IME log has not been written within $MaxImeLogAgeHours hours"
}
if (-not $stale) {
Write-DetectionLog 'INFO''Check-in signals are recent. Device is checking into Intune on its normal cadence.'
exit 0
}
Write-DetectionLog 'ERROR'"Device appears to have stopped checking in: $($reasons -join '; ')."
exit 1
}
catch {
Write-DetectionLog 'ERROR'"Unexpected failure: $($_.Exception.Message)"
exit 3
}
finally {
Write-DetectionLog 'INFO''Check-in health detection finished.'
}
Detection Logic
EnterpriseMgmt task activity. The script enumerates tasks under
\Microsoft\Windows\EnterpriseMgmt\ and takes the newest LastRunTime across them, along
with the LastTaskResult of the task behind it. These tasks run on an enrollment-driven
cadence, so their freshest run time is the best local proxy for MDM check-in health.
IME log recency. When the Intune Management Extension is installed, its log's last
write time is a strong secondary signal: an agent that checks in writes log lines at
every cycle. A silent log alongside a silent task set confirms the quiet-device state;
a recent log write alongside stale task runs points at the scheduler instead.
Update history as context. The most recent Windows Update history entry from the
COM update session API is logged as context only. A device receiving updates is alive
even if its management sync is not, which changes where you investigate.
Classification. The freshest signal is compared against MaxSyncAgeHours (default
72, roughly matching the natural MDM cadence plus margin) and the IME log against
MaxImeLogAgeHours. Beyond threshold, the device exits 1. With no EnterpriseMgmt
artifacts at all, it exits 2, because that is an enrollment repair, not a sync nudge.
Every observation lands in C:\ProgramData\Company\Logs\CheckInHealthDetection.log with the
measured values, so the flagged device tells you exactly how stale each signal was.
Remediation Script
The remediation does one narrow thing: it re-triggers the EnterpriseMgmt sync task. If the
newest run is already inside the threshold it logs "already compliant" and exits 0. If the
task is stale, it starts it and verifies within a bounded window that the task accepted the
trigger and completed cleanly where it could. It never restarts services, never deletes
enrollment state, and never reboots; if the underlying cause is network or enrollment
damage, the sync will still fail and the next detection run will keep reporting that
honestly.
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
#Requires -RunAsAdministrator
[CmdletBinding()]
param(
[ValidateRange(1, 336)]
[int] $MaxSyncAgeHours = 72
)
Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
<#
.SYNOPSIS
Remediation script: re-triggers the EnterpriseMgmt sync scheduled task to
pull a quiet device back into its normal check-in cadence.
.DESCRIPTION
Scope of this script (deliberately conservative):
- Locates the sync tasks under \Microsoft\Windows\EnterpriseMgmt\<GUID>\.
- When the newest run is within the threshold, logs "already compliant"
and exits 0 (idempotency: nothing to do).
- Otherwise starts the sync task, then verifies within a bounded window
that the task accepted the trigger and, where it completes, returns
success (LastTaskResult 0).
The script does NOT restart services, does NOT delete task or enrollment
state, and does NOT reboot. If the device cannot check infor network or
enrollment reasons, the trigger will be accepted but sync will still
fail; detection on the next run will keep reporting that honestly.
#>$logDir = 'C:\ProgramData\Company\Logs'$logFile = Join-Path $logDir'CheckInSyncRemediation.log'function Write-RemediationLog {
param([Parameter(Mandatory)][string] $Level, [Parameter(Mandatory)][string] $Message)
if (-not (Test-Path $logDir)) { New-Item -Path$logDir -ItemType Directory -Force | Out-Null }
"$([DateTime]::UtcNow.ToString('o')) [$Level] $Message" | Out-File -FilePath$logFile -Append -Encoding utf8
}
try {
Write-RemediationLog 'INFO''Check-in remediation (sync task trigger) started.'$mgmtTasks = Get-ScheduledTask -TaskPath'\Microsoft\Windows\EnterpriseMgmt\*' -ErrorAction SilentlyContinue
if ($null -eq$mgmtTasks -or @($mgmtTasks).Count -eq0) {
Write-RemediationLog 'WARN''No EnterpriseMgmt scheduled tasks exist. Sync cannot be triggered because the enrollment artifacts are missing; repair enrollment first.'
exit 2
}
# ---- Idempotency gate: skip work when check-in is already recent ----$newestRun = [DateTime]::MinValue
$newestTask = $nullforeach ($taskin @($mgmtTasks)) {
$info = Get-ScheduledTaskInfo -TaskName$task.TaskName -TaskPath$task.TaskPath -ErrorAction SilentlyContinue
if ($null -ne$info -and$info.LastRunTime -gt$newestRun) {
$newestRun = $info.LastRunTime
$newestTask = $task
}
}
if ($newestRun -ge (Get-Date).AddHours(-$MaxSyncAgeHours)) {
Write-RemediationLog 'INFO'"Newest sync run is recent ($newestRun). Device already checking in - no action taken."
exit 0
}
# ---- Choose and start a triggerable sync task ----$syncTasks = @($mgmtTasks | Where-Object { $_.TaskName -like'Schedule*' -and$_.State -ne'Running' })
if ($syncTasks.Count -eq0) {
Write-RemediationLog 'WARN''No idle sync task found to trigger (tasks running or absent). Check task state in Task Scheduler and the DeviceManagement-Enterprise-Diagnostics-Provider Admin log.'
exit 1
}
$task = $syncTasks[0]
$beforeInfo = Get-ScheduledTaskInfo -TaskName$task.TaskName -TaskPath$task.TaskPath -ErrorAction SilentlyContinue
$beforeRun = [DateTime]::MinValue
if ($null -ne$beforeInfo) { $beforeRun = $beforeInfo.LastRunTime }
Write-RemediationLog 'INFO'"Triggering sync task '$($task.TaskName)' (newest run was $newestRun)."
Start-ScheduledTask -TaskName$task.TaskName -TaskPath$task.TaskPath -ErrorAction Stop
# ---- Verify the trigger was accepted ----$accepted = $false$deadline = (Get-Date).AddSeconds(60)
while ((Get-Date) -lt$deadline) {
Start-Sleep -Seconds5$stateCheck = Get-ScheduledTask -TaskName$task.TaskName -TaskPath$task.TaskPath -ErrorAction SilentlyContinue
$infoCheck = Get-ScheduledTaskInfo -TaskName$task.TaskName -TaskPath$task.TaskPath -ErrorAction SilentlyContinue
if ($null -ne$stateCheck -and$stateCheck.State -eq'Running') { $accepted = $true; break }
if ($null -ne$infoCheck -and$infoCheck.LastRunTime -gt$beforeRun) { $accepted = $true; break }
}
if (-not $accepted) {
Write-RemediationLog 'WARN''Sync task did not accept the trigger within 60 seconds. The task may be disabled or blocked; inspect it manually.'
exit 1
}
Write-RemediationLog 'INFO''Sync task accepted the trigger.' # ---- Where the run completes inside the window, confirm the result ----$resultCheck = Get-ScheduledTaskInfo -TaskName$task.TaskName -TaskPath$task.TaskPath -ErrorAction SilentlyContinue
$completionDeadline = (Get-Date).AddSeconds(120)
while ((Get-Date) -lt$completionDeadline) {
Start-Sleep -Seconds10$resultCheck = Get-ScheduledTaskInfo -TaskName$task.TaskName -TaskPath$task.TaskPath -ErrorAction SilentlyContinue
$stateCheck = Get-ScheduledTask -TaskName$task.TaskName -TaskPath$task.TaskPath -ErrorAction SilentlyContinue
if ($null -eq$stateCheck -or$stateCheck.State -ne'Running') { break }
}
if ($null -ne$resultCheck) {
if ($resultCheck.LastTaskResult -eq0) {
Write-RemediationLog 'INFO''Sync task completed with LastTaskResult 0. Check-in cycle executed.'
}
else {
Write-RemediationLog 'INFO' ("Sync task last result: {0} (hex {1}). Non-zero results need the DeviceManagement-Enterprise-Diagnostics-Provider Admin log for the underlying cause." -f$resultCheck.LastTaskResult, ('0x{0:X}' -f$resultCheck.LastTaskResult))
}
}
Write-RemediationLog 'INFO''Check-in remediation applied.'
exit 0
}
catch {
Write-RemediationLog 'ERROR'"Remediation failed: $($_.Exception.Message)"
exit 3
}
finally {
Write-RemediationLog 'INFO''Check-in remediation (sync task trigger) finished.'
}
That honesty matters: a sync trigger that fails repeatedly is diagnostic information, not
noise to suppress. The combination of "triggered but did not complete" plus the detection
log's evidence narrows the cause quickly.
Visual Walkthrough
The exact wire-level path a device takes into Intune management.
Interactive FlowMDM Enrollment — From Discovery to Fully Managed6/6
1
Enrollment discovery
Device resolves enrollment endpoints via DNS and the discovery service.
auth
2
Entra authentication
User or device credential validates; license and enrollment restrictions check.
enroll
3
MDM enrollment URI
Entra issues the MDM enrollment URL; device opens the enrollment session.
4
Certificate issuance
MS DMG provisioning cert (and later SCEP/NDES identities) lands in the store.
registered
5
Intune object created
Device record appears; primary user, ownership and groups attach.
6
Policies stream in
Compliance and configuration profiles apply on first sync.
MDM Enrollment — From Discovery to Fully Managed. 1. Enrollment discovery: Device resolves enrollment endpoints via DNS and the discovery service. — 2. Entra authentication: User or device credential validates; license and enrollment restrictions check. — 3. MDM enrollment URI: Entra issues the MDM enrollment URL; device opens the enrollment session. — 4. Certificate issuance: MS DMG provisioning cert (and later SCEP/NDES identities) lands in the store. — 5. Intune object created: Device record appears; primary user, ownership and groups attach. — 6. Policies stream in: Compliance and configuration profiles apply on first sync.
Deploying Through Intune
In the Microsoft Intune admin center, go to Devices → Scripts and remediations → + Add, platform Windows 10/11.
Name the package clearly, for example Remediate - Device check-in health, and describe the blast radius ("re-triggers the MDM sync task; changes nothing else").
Upload detect.ps1 on the Detection script tab with Run script in 64-bit PowerShell: Yes and Run this script using signed-on credentials: No.
Upload remediate.ps1 on the Remediation script tab with the same settings.
Set the schedule to Daily. Check-in drift is the failure mode this package watches, so daily detection is appropriate; the remediation only acts when the thresholds are exceeded.
Assign to your broadest Windows device group, but review the threshold parameters first. Fleet-wide deployment is the point of this one: the goal is to catch quiet devices wherever they are.
Notes for this package:
Thresholds are parameters: with a fleet that includes rarely-used kiosks or shared
devices, consider a second package with a longer MaxSyncAgeHours rather than loosening
the primary one.
Devices that exit 2 (no EnterpriseMgmt artifacts) need enrollment repair, not this
remediation; route them to your enrollment troubleshooting flow.
Exit Codes
Code
Meaning
0
Check-in signals recent (detection) — or the device was already within threshold / sync task re-triggered and completed (remediation)
1
Check-in signals stale beyond thresholds — sync trigger needed; remediation exit 1 means the task was started but did not complete cleanly
2
No EnterpriseMgmt enrollment artifacts found — cannot assess or fix locally; enrollment repair required
Each line is UTC-timestamped with a level and the measured evidence (task path, LastRunTime,
LastTaskResult, IME log age). Because the same thresholds run fleet-wide, the logs form a
consistent dataset you can review per device during triage.
Troubleshooting the Script
Every device in one ring flags exit 1. Check the ring's network path first: a proxy
or firewall change cutting the management endpoints silences an entire group at once.
The companion connectivity and DNS detection posts in this series cover that triage.
Remediation starts the task but LastTaskResult stays non-zero. Read the value from
the remediation log and cross-check the MDM enrollment certificate and enrollment state;
repeated task failures usually mean enrollment damage rather than a scheduling problem.
Exit 2 on devices you know are enrolled. EnterpriseMgmt task folders missing while
enrollment keys exist is a distinctive partial-enrollment state. Capture an MDM
diagnostic archive and treat it as an enrollment repair case.
Thresholds too tight for your fleet. Laptop fleets with weekend-off patterns are fine
at 72 hours; if a legitimate population trips the threshold weekly, raise the parameter
for that group rather than ignoring the signal.
No log file appears. The package never ran: check assignment, 64-bit enforcement,
and whether a conflicting policy changed the script context settings.
How to Validate the Fix
Pick a device that reports stale in the admin center. Run detect.ps1 manually in an
elevated 64-bit console; expect exit 1 with stale values in the log.
Run remediate.ps1; expect it to start the sync task and, when the device can reach
the service, exit 0 with LastTaskResult 0.
Refresh the device record in the admin center; the "Last sync" timestamp should move
within a few minutes of a successful task completion.
Re-run detection; expect exit 0.
Prove management end to end: assign a trivial policy change or app and confirm it
arrives on the now-healthy device.
Production Considerations
Execution context. Both scripts run as SYSTEM in 64-bit Windows PowerShell. The
EnterpriseMgmt task namespace is machine-scoped, so no user context is needed.
Idempotency. Detection is read-only; remediation re-triggers at most one scheduled
task and exits 0 on healthy devices. Safe on any schedule.
Side effects. A triggered sync pulls policy and reports status; that is the intended
effect. No services restart, no state is deleted, and no reboot occurs. Devices that
cannot reach the service will fail the sync, and that failure remains visible in the
logs and the next detection run.
Security. No credentials are embedded, and no state is modified beyond starting an
existing scheduled task. Have your PowerShell automation SME and security team review
the scripts and validate them in a test ring before broad rollout, consistent with your
script review and signing policy.
Interpretation discipline. Treat persistent exit 1 devices as a queue for root-cause
work, not as a nag to suppress. The remediation buys time; it does not fix networks or
broken enrollment.
How is this different from checking "Last sync" in the admin center?
The portal shows the service's view, which can lag or mislead when devices clone, reimage,
or sync under a different identity. The local evidence measures what the device itself did
and when, which catches those cases and gives you a per-device, per-signal breakdown.
Why 72 hours as the default threshold?
Intune devices naturally sync on a cadence of roughly every several hours when awake, with
push-triggered syncs in between. Seventy-two hours gives healthy laptops generous headroom
for weekends while still catching genuinely quiet devices within days. Tune it for your
fleet's actual usage patterns rather than treating it as a rule.
The sync task completes but the admin center timestamp still does not move. What does that mean?
A task that completes locally while the portal stays stale usually means the sync reached
something other than your tenant, a classic clone-identity problem, or a proxy returning
successful responses without reaching the service. Capture an MDM diagnostic archive and
compare the device identity in the archive with the portal record.
Comments
0No comments yet — be the first to share your thoughts.