It’s 4:30 PM on a Friday. You’re trying to deploy a critical new Device config policy to a specific laptop, but when you type the hostname into the search bar to add the device to an Entra ID group, Microsoft Entra ID spits back three identical objects. Two are stale, one is active, and they all look exactly the same at first glance.
Then you look closer at your overall inventory. You’ve got corporate devices that haven’t checked in since the Clubs won the world series. Seriously, some of these records are dated 2016. Was Azure AD even a thing back then? (Spoiler: It was barely out of its infancy, and Microsoft Intune was still living in the Silverlight era.)
To top it all off, your old local Active Directory sync is blindly pumping ancient on-prem computer objects into the cloud like a broken pipe filling a basement.
It’s an absolute mess.
But look—I get it. You just got to the cloud, or maybe you’re still squarely on the journey. You’ve been running a million miles an hour just to handle the migration, lift-and-shift workloads, get users authenticated, and keep corporate assets running. Up until now, cleaning up stale objects hasn’t exactly been top of mind, let alone trying to write complex automation scripts to handle it. You’ve just been trying to keep the lights on and the helpdesk queue clear.
At some point, cleaning up the mess becomes less work than living with it. So you open the portals, start sorting through the duplicates, and finally decide it’s time to get rid of the junk.
Before you start clicking Delete and head out for the weekend, hold that thought. In the modern cloud era, a brute-force sweep can quickly turn into a Monday morning nightmare.
And with Microsoft continuing to introduce recovery features such as device restore and soft-delete capabilities, understanding exactly what you’re deleting—and why—has become just as important as deciding what to clean up in the first place.
The Two Halves of the Same Coin
When you shift from old-school on-prem management to the cloud, you have to realize you are now dealing with two entirely different control planes for your corporate Windows environment. They look at the world through totally different lenses:
| The Control Plane | What It Cares About | The Cleanup Goal |
|---|---|---|
| Microsoft Entra ID | Identity & Access: Is this device allowed to authenticate? Does it match our Conditional Access policies? | Remove the logical object so an old, decommissioned machine can no longer request access to corporate data. |
| Microsoft Intune | Management & Compliance: What apps are installed? Is the firewall on? Is it encrypted? | Remove the MDM enrollment and stop tracking a device that no longer exists, keeping your management inventory accurate and reducing administrative overhead. |
What about those ghosts —the objects that show up in Microsoft Entra ID but don’t have a corresponding record in Intune at all? They might be leftovers from an old staging process, machines where the Intune MDM enrollment failed, or objects synced from on-premises that never made the jump to cloud management.
If there’s no Intune object to worry about, you can just click Delete on that Entra object, right?
Not so fast.
Before you purge an “Entra-only” corporate device record, you have to verify how it got there.
If that device object is tied to an active Windows Autopilot registration, take a pause before deleting it.
An Autopilot device keeps its hardware hash registered separately from its Entra device object. In many environments, administrators intentionally retain Autopilot registrations so devices can be reset and redeployed in the future. Deleting the Entra object doesn’t remove the Autopilot registration.
Before removing an “Entra-only” device, determine whether the hardware is still in service, held as spare inventory, or expected to be redeployed through Autopilot. If the device is truly retired and leaving your environment permanently, removing the Autopilot registration should be part of the overall decommissioning process. If the hardware is expected to return to service later, retaining the Autopilot registration may be the better choice.
The key takeaway: understand the device’s lifecycle before deleting identities. Not every stale Entra object is safe to purge without verifying whether Autopilot is still involved.
Actions that you can take
Whether you are building your cleanup strategy entirely from scratch or trying to audit an existing process that might be missing the mark, here is how you baseline your corporate environment without triggering unintended side effects:
1. Adopt (or Enforce) a Consistent Device Decommissioning Process
Even if you are deleting objects manually in the portals for now, don’t approach device cleanup as a random series of clicks. Establish a documented process that validates every device’s lifecycle before removal:
- Autopilot: Verify whether the hardware should remain registered for future redeployment.
- Intune: Retire, wipe, or remove the management record as appropriate for the device lifecycle.
- Entra ID: Remove the device identity once you have confirmed it is no longer required for management, access, or provisioning purposes.
2. Turn On Native Intune Cleanup Rules (Your Easy Win)
If you don’t have custom automation built yet, use the built-in safety valves. Go to Tenant administration > Device cleanup rules in Intune and configure the service to automatically identify and clean up stale device records based on inactivity (typically 90 to 120 days).
Remember that these cleanup rules do not retire, wipe, or remove devices from Microsoft Entra ID—they primarily help reduce administrative clutter in the Intune portal and reporting experience.
Let Microsoft do the heavy lifting while you focus on the migration.
3. Audit Your Existing Scripts for the “Autopilot Blindspot”
If you already have custom Graph API or PowerShell cleanup scripts running, review them.
If your automation targets device resources based purely on approximateLastSignInDateTime without explicitly verifying whether the hardware is still intended for Autopilot-based redeployment, your script may be making lifecycle decisions without the full picture.
Autopilot registrations, Intune records, and Entra identities don’t always age out together.
4. Stop the Bleeding at the AD Sync Level
If you are running hybrid sync (Entra Connect) and syncing local AD to the cloud, a clean cloud starts on-premises.
Filter your sync scopes or clean up your local Active Directory OUs.
If a corporate object is dead on-prem, don’t let the sync engine keep breathing fake life into it in the cloud.
5. Track Assets by Serial, Not Object ID
Remember that a single physical machine can generate multiple Entra Device IDs if it is repeatedly re-registered or synced from AD, but it still represents the same physical asset.
Track your actual corporate assets by serial number and lifecycle records, not the ephemeral object ID shown in a cloud portal.
Next Week:
We break down The Zombie Endpoint and look at exactly how that hidden third identity layer can turn what appears to be a harmless stale device record into a troubleshooting rabbit hole during redeployment, enrollment, and recovery scenarios.
Leave a Reply