Intune Endpoint Analytics Devices Missing Startup Performance Scores

#Current method: why devices go missing

The fastest route to an answer is to work from scope outwards: is the device Intune-managed, is it in the data collection scope, and has it restarted since collection began? Version-specific prerequisites and licensing for Endpoint Analytics are listed on the Microsoft Intune documentation; check that page once for your tenant before changing anything.

The usual current method is to open the startup performance report, see a short device count, and raise a ticket. That creates rework because the report only shows devices that have already sent data. A missing device is an absence of evidence, so the first job is to establish which layer is silent: enrolment, policy scope, or the device itself.

Assumptions: Windows devices are enrolled in Intune, you hold an Intune role able to read device and analytics settings, and you test on a pilot group first. These are assumptions to confirm, not facts about your estate.

#Improved workflow

Replace ad hoc ticketing with a fixed three-question triage. Each question consumes one input and produces one observable output.

1. Compare the managed Windows device list with the devices in the startup performance report. Output: a list of missing devices.
2. Check whether each missing device sits inside the group or scope that receives the data collection configuration. Output: in scope or out of scope.
3. For in-scope devices, check last check-in and whether the device has restarted since collection began. Output: healthy but waiting, or unhealthy.

The trade-off is a small upfront effort to build the comparison, in exchange for removing guesswork. Related reading on telemetry-driven work: telemetry-triggered remediation for slow boots.

#Implementation

Prerequisites: a pilot device group, read access to device records, and permission to edit the relevant configuration through change control.

1. Export the managed device list and the report list, then record the missing devices as your baseline. Expected evidence: a dated list.
2. Confirm each missing device is enrolled and checking in. A device that has not synced will not receive configuration; see the script for Intune devices that have not synced in N days. Stop if the device is not enrolled and resolve enrolment first.
3. Review the data collection configuration and its assignment. If the device is out of scope, add a small pilot group only. Expected evidence: the assignment lists the pilot group.
4. Sync the pilot devices and restart them so a startup is observed.
5. Wait for reporting, then re-run the comparison from step 1.

Stop condition: if pilot devices still do not report after a restart and a further check-in, stop widening scope and escalate to a human with the device records and assignment details. Do not assume a cause the evidence does not show.

#Guardrails

• Use least privilege: read-only roles for diagnosis, and a named role for assignment changes.
• Change one scope at a time and only for a pilot group before wider rollout.
• Record every change with a date and owner.
• Do not treat a missing score as a performance fault; it is a data gap.

#Validation

Success is observable: pilot devices appear in the startup performance report with a score after a restart. Compare against the baseline list from step 1. Silence after the documented waiting period means the diagnosis is not finished. Remember that reporting is not instant, so allow time before concluding failure, and check the documentation for the current timing.

#Common mistakes

• Symptom: only some devices missing. Likely cause: the assignment excludes them. Evidence: group membership. Fix: add to the pilot group.
• Symptom: device enrolled but silent. Likely cause: it has not synced or restarted. Evidence: last check-in date. Fix: sync and restart.
• Symptom: assuming a remediation script is the cause. Compare with remediation scripts that never run, which is a different failure.

#Recovery

If an assignment change causes unexpected side effects, remove the pilot group from the assignment, sync the devices and confirm the earlier state returns. Keep the exported baseline as the reference. Then re-run the comparison to confirm the estate matches the baseline.

#Measurable outcome

Baseline: the count of managed Windows devices absent from the report. Target: the missing count falls to devices with a documented, explained reason. Measure weekly with the same comparison. If the count does not fall after two cycles, escalate. No savings or percentage figures are claimed here, because none were supplied.

#Checklist: closing the startup performance data gap

• Baseline missing-device list saved.
• Enrolment and check-in confirmed per device.
• Assignment reviewed and pilot scope applied.
• Pilot devices restarted and re-compared.
• Rollback path recorded and tested.
• Unresolved devices escalated with evidence.

#Prerequisites and permissions in more detail

#

Roles and access to confirm before you start

Diagnosis needs only read access, so separate it from the change role. Ask your Intune administrator to confirm that the diagnosing engineer can read device records, group membership and configuration assignments, and that a different named person holds the right to edit assignments. Record both names in the change ticket. If the read-only role cannot see the analytics configuration at all, treat that as a permissions gap to be raised, not a reason to borrow a broader role.

#

Local access on the test device

For on-device evidence you need a local administrator session on one pilot machine, or a remote tool already approved by your organisation. Open an elevated PowerShell prompt only on pilot devices. Nothing in this section requires changes on the device; every command below reads state.

#Implementation detail for the comparison

#

Building the baseline with a repeatable export

Export both lists as CSV files and name them with the date, for example managed-devices-2025-01-14.csv and startup-report-2025-01-14.csv. Keep the same column used as the key in both files, preferably the device name together with the serial number, because names alone can be duplicated after reimaging. A simple comparison in PowerShell is:

1$managed = Import-Csv .\managed-devices.csv
2$report  = Import-Csv .\startup-report.csv
3$missing = $managed | Where-Object { $_.SerialNumber -notin $report.SerialNumber }
4$missing | Export-Csv .\missing-baseline.csv -NoTypeInformation

Adjust the column names to match your exports. Check that the row counts of the three files add up before trusting the result: managed devices, matched devices and missing devices. A mismatch usually means blank serial numbers or a filter applied to one export only.

#

Collecting on-device evidence

On a pilot device that is missing from the report, gather these read-only facts and paste them into the ticket:

1(Get-CimInstance Win32_OperatingSystem).LastBootUpTime
2dsregcmd /status
3Get-Service | Where-Object { $_.DisplayName -like '*Intune*' }

The first shows whether a restart has occurred since you applied the assignment. The second shows join and management state; read the output as presented and do not infer fields it does not show. The third confirms whether the management extension service is present and running. Record the output exactly rather than summarising it.

#Expected evidence at each stage

• After export: two dated files and a third file listing the missing devices, with row counts noted.
• After scope review: a screenshot or exported record showing the assignment, group name and the date it was read.
• After pilot restart: a boot time later than the assignment change, for each pilot device.
• After the waiting period: a fresh report export in which pilot devices appear, or a dated note that they do not.

Evidence should be attributable: who collected it, from which console or device, and when. Evidence without a timestamp cannot be compared against the baseline.

#Monitoring while the pilot runs

#

What to watch daily

Check three things each working day during the pilot: the count of pilot devices that have appeared in the report, the last check-in time for each pilot device, and whether any pilot user has reported an unexpected change. Keep a small table with one row per device and one column per day. A device that never changes state across several days is more informative than one that changes late.

#

Separating a slow device from a silent one

A device that is switched off, asleep or away from the network will look identical to a misconfigured one in the report. Before escalating, confirm the owner and the usual working pattern. A laptop that has been off since the assignment change has not failed; it has not yet had the chance to report. Note this in the ticket as healthy but waiting, in line with your triage outputs.

#Realistic failure symptoms and how to read them

• Whole pilot group absent after a restart and a further check-in. Suspect the assignment itself, such as the wrong group, or a group that does not contain the devices. Compare the group member list with the pilot list line by line.
• One device absent while the rest of the pilot appears. Suspect that device: a stale record, a duplicate record after reimaging, or a device that has not restarted. Search the managed list for two entries with the same serial number.
• Devices appear then disappear from later exports. Suspect differing export filters or a changed assignment. Re-export using the same filters and compare the files rather than relying on memory.
• Device shows recent check-in but no score. The management channel is working, so look at whether a startup has been observed since collection began, and at the documentation for any waiting period.
• Users report slow startup yet the device has no score. Treat the complaint and the missing score as separate issues. Do not use the complaint as proof of the data gap or the reverse.

If a symptom does not match any of these, record it verbatim and escalate; do not force it into the nearest category.

#Change-control records

#

What the change record should contain

• Reason for change, referencing the baseline missing-device file.
• Exact group added to the assignment and its member count at the time.
• Name of the approver and the person who made the change.
• Planned start time, the planned waiting period, and the agreed review date.
• Rollback steps, written before the change is made.
• Outcome: pilot devices reporting, not reporting, or deferred, with the evidence files attached.

#

Closing the record

Close the record only after the post-pilot comparison has been attached. If scope is later widened, open a new record rather than extending the pilot one, so that each widening has its own approval and rollback path.

#Escalation thresholds

Define thresholds before starting, so that escalation is a rule and not a judgement made under pressure. A workable set, to be adapted to your own service levels:

1. Escalate to the Intune administrator: any pilot device that is enrolled, has checked in, has restarted since the change, and still does not report after the documented waiting period.
2. Escalate to the service owner: the missing count does not fall after two weekly measurements, which matches the measurable outcome already set.
3. Escalate immediately: any pilot user reports loss of access, a failed sign-in or a change in device behaviour after the assignment change. Begin rollback first, then escalate.
4. Escalate to the vendor support route: only after the evidence set is complete and an internal administrator has confirmed the assignment and enrolment are correct.

Each escalation should carry the baseline file, the assignment record, the on-device output and a one-paragraph timeline.

#Safe rollback actions

#

Order of operations

1. Pause any further assignment changes and tell the pilot users that a restart may be requested.
2. Remove only the pilot group from the assignment. Do not delete the configuration itself, because that destroys the reference you need for later comparison.
3. Sync the pilot devices and confirm check-in times are later than the removal.
4. Export the assignment again and compare it with the pre-change record. They should match.
5. Record the rollback in the change record with time, person and evidence.

#

What not to do during rollback

• Do not remove devices from the tenant to force a fresh state; that changes enrolment, which is a separate problem.
• Do not edit several assignments at once, because you will lose the ability to say which change caused which effect.
• Do not run unreviewed scripts on user devices to repair state.

After rollback, keep the pilot group intact and idle so that the test can be repeated once the cause has been identified.

Next safe decision: widen scope only when the pilot group reports reliably.