A reliable device inventory: one endpoint, several objects, three automations

There’s a question that comes up again and again in device management, especially when Intune is meant to feed a reliable inventory: why does what the console shows never quite match what’s actually on desks? Microsoft keeps integrating pieces of the answer natively, little by little, but a good part of it still has to be automated by whoever runs the platform.

The starting point is a concept worth being pedantic about. A device (an endpoint; from here on, an object) can exist in more than one place at once, and those are different objects:

Registered in Entra ID. Someone used their corporate account on that device to reach a company resource: signed into Outlook, OneDrive, any Microsoft 365 app. That alone creates an object in the directory. It’s usually not a managed device.
In Entra ID and enrolled in Intune. Now there are two objects that synchronise with each other, but they remain two objects with two different jobs. Entra ID holds the identity: it’s where the object carries its group memberships. Intune holds the management: it’s where the object lives day to day and where groups are assigned to policies, scripts and applications.

Keep that split in mind and the failure modes become predictable.

The case that breaks the inventory

Reinstall Windows on a machine by hand. The objects in Entra ID and Intune both survive the reinstall. If the device is enrolled again, the old objects should be deleted from both places, and usually nobody does.

Worse: if the device lost its trust with Intune for whatever reason and gets re-enrolled, Intune creates a new object. Now the same physical endpoint exists two, three times in the console. Every count is wrong, every compliance percentage is diluted by ghosts, and any assignment that targets “all devices” is targeting machines that no longer exist.

Three automations that keep it honest

The routine

Deduplicate by serial number. A scheduled job groups Intune objects by serial and deletes all but the one with the most recent enrollment date. The serial is the only identity that survives a reinstall; the enrollment date says which object is the live one.
Clean up stale devices on a fixed cadence. Objects with no check-in or sign-in activity beyond a threshold get removed; 90 days is a sensible definition of stale, with anything shorter rejected because normal absence (holiday, sick leave) produces false positives. The Intune half is scripted in Invoke-IntuneStaleDeviceCleanup.ps1, which reports by default and separates retire from delete because they have very different blast radii. One thing must happen first, every time: back up the BitLocker recovery keys of every device in scope, because deleting the Entra object deletes the keys stored on it, and the day someone needs that key is not the day to discover this.
Align the primary user automatically. Depending on how a device was enrolled, the primary user is often wrong: enrollments done through a service account, or by a technician who skipped the manual step, leave the device assigned to nobody or to the wrong somebody. The fix has two halves. Get-IntuneDeviceUserDrift.ps1 reads, for every device, the last logged-on user, a field only exposed through Microsoft Graph beta, so this piece lives on the beta endpoint until Microsoft promotes it. A Logic App runs it daily and appends the result as a column in an Excel sheet, keeping three columns at most: today and the two days before. When the three columns agree on one user and that user is not the current primary user, the assignment is corrected with Set-IntuneDevicePrimaryUser.ps1, which reports without -Execute, like everything else. Three consistent days is the safeguard: one sign-in from a colleague or a technician must not reassign a machine.

What to keep before you delete

Two of the three automations delete things, and deletions in a directory are final. My recommendation is to pair them with a small storage layer (a Logic App or Azure Automation runbook writing to blob storage) that keeps three things:

The BitLocker recovery keys of every device in scope, if they are not already escrowed somewhere else. This is the prerequisite of the stale cleanup, not an optional extra.
A minimal record of every device removed: user if available, serial number if available, when and why. Not the whole object: just enough to answer “what happened to this machine?” months later without keeping personal data you no longer need.
A periodic export of the Intune configuration: policies, profiles, assignments. For backup and restore, the community module I used in production for years is John Seerden’s IntuneBackupAndRestore, credit where it is due. Its dependencies have since been retired, so check it still runs on your module versions before you rely on it; the point stands either way: a dated export, on a schedule, somewhere outside the tenant.

That last one earns its keep the day an auditor asks. “Can you show me the configuration as it was, and prove you could recover it?” is a standard question in a security audit (it came up in an ISO 27001 certification I was part of) and a dated export in blob storage is the difference between an answer and an action item.

The primary user matters more than it looks: it drives Company Portal self-service, user-based policy resolution, and every report that answers “whose machine is this?”. An inventory where the primary user is wrong is an inventory that can’t answer the one question people ask it most.