Forcing an Intune sync, and the three problems that look exactly like a sync failure

Sync in Intune has always meant slightly different things depending on where you pressed it. Service release 2607 changed that for Windows, and it changes how you should troubleshoot: the first question is no longer whether the device synced, it is what you are actually inventorying. Where you force Intune sync from now changes what comes back. On new hardware that inventory starts at enrolment, which is Autopilot device preparation.

What changed

The Sync device action in the admin centre now triggers a fuller synchronisation for Windows devices, spanning configuration policies, apps and scripts rather than a narrower subset. Microsoft calls it especially useful during troubleshooting, incident response and high-priority rollouts, which is a fair description of the three times anyone presses that button.

In the same release, the properties catalog gained the ability to collect Windows registry data. Both entries are dated in the Intune service release notes. You can define a device inventory policy that collects a single value, every value directly under a key, or the same value across subkeys under HKEY_LOCAL_MACHINE.

Three ways to force Intune sync, and which one you want

When a setting has not landed, ask which of these was pressed before assuming the policy is at fault. If none of them produce a result, the full diagnosis order is in Intune device not syncing. A user saying they synced and an admin saying they synced are describing different events. The same distinction matters when offboarding, because Intune wipe vs retire both wait for a check-in.

Forcing it from the device

When you need it done without asking the user to click anything, trigger the MDM push directly.

1# Triggers the MDM enrolment's own scheduled sync tasks. Run elevated.
2$enrollmentId = (Get-ScheduledTask -TaskPath "MicrosoftWindowsEnterpriseMgmt*" |
3                 Select-Object -First 1).TaskPath.Split('')[-2]
4
5if (-not $enrollmentId) {
6    Write-Warning 'No MDM enrolment found. Device is not Intune enrolled.'
7    return
8}
9
10Write-Host "Enrolment: $enrollmentId"
11
12# Schedule #3 is the push-triggered sync; running them all is harmless.
13Get-ScheduledTask -TaskPath "MicrosoftWindowsEnterpriseMgmt$enrollmentId" |
14    ForEach-Object {
15        Write-Host "Starting: $($_.TaskName)"
16        Start-ScheduledTask -TaskPath $_.TaskPath -TaskName $_.TaskName
17    }
18
19# Then watch the agent do the work.
20Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' `
21             -MaxEvents 20 |
22    Select-Object TimeCreated, Id, LevelDisplayName, Message |
23    Format-Table -Wrap

Triggering it for many devices from Graph

The admin centre action is fine for one device. For a ring, script it.

1Connect-MgGraph -Scopes 'DeviceManagementManagedDevices.PrivilegedOperations.All',
2                        'DeviceManagementManagedDevices.Read.All'
3
4# Narrow this. Syncing every Windows device at once is not a troubleshooting step.
5$devices = Get-MgDeviceManagementManagedDevice -All -Filter "operatingSystem eq 'Windows'" |
6           Where-Object { $_.LastSyncDateTime -lt (Get-Date).AddDays(-2) }
7
8Write-Host "Devices not synced in 48 hours: $($devices.Count)"
9
10foreach ($d in $devices) {
11    try {
12        Sync-MgDeviceManagementManagedDevice -ManagedDeviceId $d.Id -ErrorAction Stop
13        Write-Host "Queued: $($d.DeviceName)"
14    } catch {
15        Write-Warning "Failed: $($d.DeviceName). $($_.Exception.Message)"
16    }
17    Start-Sleep -Milliseconds 250   # be kind to the throttle
18}

Filtering on devices that have not checked in for two days is usually more informative than syncing the ones you were already looking at. The list itself is the finding.

When sync is not the problem

Pressing sync harder does not fix a policy that will never apply. Before you press it a third time, check the three things that look like sync failures and are not: an assignment that targets a group the device is not in, a policy conflict where two profiles set the same value differently, and a device registered for classic Autopilot ignoring a device preparation policy.

All three present identically. The device syncs successfully and the setting does not appear.

Driver deployment fails in exactly the same shape and is worth ruling out separately, because a driver update policy carries prerequisites and a scan cycle of its own. The five causes are set out in Intune driver updates not working.

And when you want the device’s actual state rather than a report of it, device query answers in near real time, but it sits behind a separate subscription and carries limits of its own. Those are set out in Intune Device Query limits and licensing.

Compliance status is the one thing a sync will not hurry, because it is reported back to Intune rather than pushed down to the device. Microsoft puts the full round trip at up to 24 hours, which is set out in why an Intune compliance policy still lags after a sync.

What I would do

Use the fuller admin centre sync when you have made a change and want it now. Use the device-side task trigger when you cannot reach the user. Use the Graph filter when you want to know how many devices are quietly not checking in, which is the question worth asking before any of the others.

And move your registry-reading remediation scripts into the properties catalog. A policy that reports a value is strictly better than a script that might.