A laptop comes back from a leaver. You open the Intune admin center, find the device, and hit Delete. The row disappears. Job done, inventory clean, ticket closed.
Six weeks later that same chassis is reissued to a new starter. It boots, reaches the out-of-box experience, and fails. Somewhere in your tenant, two records you never touched are still describing a device that no longer exists.
One Windows Autopilot device is three separate records. The Autopilot registration, the Intune managed device, and the Microsoft Entra ID device object each live in a different service. Microsoft states that completely removing a device from a tenant requires all three records to be deleted, in a specific order. Deleting one does not reliably delete the others, and Intune device clean-up rules only hide records rather than removing them from Entra ID. The companion script reads all three collections through Microsoft Graph. It joins them on serial number and device id, then reports every record that exists in one service but not the others.
The problem: one device, three records, no single delete button
Most admins learn device retirement as a single action. You delete the device from whichever blade you happened to have open, and you assume the platform cleans up behind you.
It does not. Microsoft says so directly in the manual registration article. "Completely removing a device from a tenant requires the device records in Intune, Microsoft Entra ID, and Windows Autopilot to all be deleted."
Three records. Three services. Three deletion paths. And the portal gives you no view that shows all three side by side.
The first trap is that two of those records live in the same admin center, in two lists that look almost identical. Microsoft calls this out explicitly, because people search the wrong list and conclude the device is gone.
The second trap is the failure mode. Stale objects rarely fail loudly at deletion time. They fail weeks later, on the next provisioning attempt, in a way that looks like an Autopilot bug.
Microsoft documents these specific symptoms of leftover records:
- Error
0x80180014when re-enrolling a device that was previously provisioned in self-deploying or pre-provisioning mode. Microsoft's stated cause is that "the device record created by Intune must be deleted" before the device can be reused. - Event ID 807,
ZtdDeviceIsNotRegistered, when the Autopilot registration is gone but the device still expects one. - Import error
ZtdDeviceAlreadyAssigned, raised when the uploaded hardware hash matches a device that is already registered to the tenant. - A join type that shows as Microsoft Entra registered instead of Microsoft Entra joined. Microsoft's fix here is unambiguous: delete the existing objects in Intune, Entra ID, and Windows Autopilot, then re-register.
Why it happens: three lifecycles joined by two soft keys
A single delete does not cascade because these are three genuinely independent objects. Three services own them, and Microsoft Graph exposes them as three different resources.
| Record | Graph resource and path | What it actually holds |
|---|---|---|
| Autopilot registration | windowsAutopilotDeviceIdentity at /deviceManagement/windowsAutopilotDeviceIdentities | Hardware identity, serial number, product key, group tag, purchase order identifier, enrollment state, assigned user |
| Intune managed device | managedDevice at /deviceManagement/managedDevices | The mobile device management enrollment: compliance state, last sync time, management agent, enrollment profile name, primary user |
| Entra ID device object | device at /devices | The directory identity: trust type, account enabled, registration date, group membership, BitLocker keys, Windows Hello for Business keys |
Each record is created at a different moment. The Autopilot registration is created when the hardware hash is uploaded. Microsoft documents that "when a Windows Autopilot device is registered, it automatically creates a Microsoft Entra object." The Intune managed device only appears when the device actually enrols.
What links them is not a database relationship. It is a pair of string properties that each service stores about the others.
| Join | Property on the left | Property on the right |
|---|---|---|
| Autopilot to Intune | windowsAutopilotDeviceIdentity.managedDeviceId | managedDevice.id |
| Autopilot to Entra ID | windowsAutopilotDeviceIdentity.azureActiveDirectoryDeviceId | device.deviceId |
| Intune to Entra ID | managedDevice.azureADDeviceId | device.deviceId |
| Fallback for all three | windowsAutopilotDeviceIdentity.serialNumber | managedDevice.serialNumber |
These are copies of an identifier, not enforced references. Nothing stops the record on one side from being deleted while the pointer on the other side keeps pointing at it. That is exactly what an orphan is.
azureActiveDirectoryDeviceId on the Autopilot resource as "to be deprecated". It is still the property returned in the v1.0 response today, so the join still works. Build your tooling so that swapping the join key is a one-line change, not a rewrite.There is a fourth identifier worth knowing, because it is how Entra ID remembers that an object was ever an Autopilot device. Microsoft refers to it as the ZTDID, short for zero touch deployment identifier. It rides in the Entra device object's physicalIds collection.
Microsoft's stale-device guidance is explicit about what happens when you delete an Entra object that had a ZTDID and then try to reuse the device:
- User-driven deployments without pre-provisioning create a new Entra device, "but isn't be tagged with the ZTDID".
- Self-deploying mode deployments fail, because an associated Entra device cannot be found. Microsoft describes this as a deliberate security mechanism, and says the failure "indicates a ZTDID mismatch".
- Pre-provisioning deployments fail for the same reason, because they use the self-deploying code path underneath.
physicalIds as "For internal use only." Use it to find suspicious objects, never as the sole basis for a deletion decision. Confirm by serial number in the portal before anyone deletes anything.What each delete actually does
This is the table nobody publishes, and it is the whole point of the post.
| What you clicked | What it removes | What it leaves behind |
|---|---|---|
| Delete in Intune (Devices > All devices) | The managedDevice record. For Windows this always triggers a Retire command | The Autopilot registration and the Entra ID device object |
| Delete in the Windows Autopilot devices blade | The windowsAutopilotDeviceIdentity registration | Depends on enrolment history. Microsoft states that for a device that is or was enrolled in mobile device management, "removing the Windows Autopilot registration doesn't automatically delete the Microsoft Entra device object" |
| Delete device in Microsoft Partner Center | Only the Autopilot registration | Everything else. Microsoft states it does not unenrol the device from Intune and does not disjoin it from Entra ID |
| Intune device clean-up rule | Nothing. It hides records from the portal and reports | All three records. Microsoft states "Devices hidden from Intune aren't removed from Microsoft Entra ID" |
That last row generates orphans quietly and at scale. Clean-up rules accept a value between 30 and 270 days, run on a schedule, and trigger no action on the device. A device vanishes from your Intune reporting while its Entra object and its Autopilot registration sit untouched.
The client-side view of the same problem
The three records live in the cloud, but the device keeps its own copy of what it thinks it belongs to. When a re-enrolment fails, this key tells you whether the device believes it is registered at all.
| Value | What it tells you during an orphan investigation |
|---|---|
CloudAssignedTenantDomain | The Entra tenant the device is registered with. Microsoft documents that if the device is not registered with Windows Autopilot, this value is blank |
CloudAssignedTenantId | The tenant GUID matching that domain. Also blank when the device is not registered |
AadTenantId | The tenant GUID of the user who signed in. A mismatch against the assigned tenant produces an error for the user |
TenantMatched | Set to 1 when the user's tenant matches the registration tenant. If 0, the user is shown an error and forced to start over |
IsAutopilotDisabled | Set to 1 when the device is not registered with Autopilot. Can also mean the profile could not be downloaded because of network or firewall problems |
CloudAssignedOobeConfig | A bitmap of which Autopilot out-of-box settings were configured |
The event log surface
Autopilot writes its own log. When you are chasing a device that will not re-provision, this channel tells you which of the three records the device could not find.
| Event ID | Type | What it means for a three-object investigation |
|---|---|---|
| 100 | Warning | Autopilot policy not found. Usually temporary while the profile downloads |
| 153 | Info | State changed, normally ProfileState_Unknown to ProfileState_Available. The registration was found |
| 161 | Info | The Autopilot profile downloaded successfully |
| 163 | Info | Download not required, the device is already provisioned. A profile is cached locally. Clean or reset to change this |
| 807 | Error | ZtdDeviceIsNotRegistered. Validate that the hardware hash is uploaded and a profile is assigned. The classic missing-registration signature |
| 809 | Error | ZtdDeviceHasNoAssignedProfile, assigned profile does not exist. The profile was deleted without cleanup. Assign another and retry |
| 815 | Error | ZtdDeviceHasNoAssignedProfile, no profile assigned and no default profile in the tenant |
| 908 | Error | SerialNumberMismatch or ProductKeyIdMismatch. The recorded serial or product key does not match the hardware. Re-register, then re-enrol |
How to verify: read all three collections and join them yourself
Verification comes before deletion, always. You want to know which of the three records exists before anyone clicks anything.
Step 1: check the Autopilot registration
- Sign in to the Microsoft Intune admin center.
- Select Devices in the left pane.
- Under By platform, select Windows.
- Under Device onboarding, select Enrollment.
- Under Windows Autopilot, select Devices.
- Use Search by serial number to find the device.
- Select Sync, then Refresh, if the list looks out of date.
Step 2: check the Intune managed device
- In the same admin center, select Devices > All devices.
- Search for the device name, or filter by serial number.
- Open the device and note the Serial number shown on the properties page.
Step 3: check the Entra ID device object
- Open the Microsoft Entra admin center.
- Go to Devices > All devices.
- Search by device name, and check the Activity column.
- Note the Join type, which drives what you do at the end of the process.
The Activity column is the property Microsoft calls the activity timestamp, exposed in Graph as approximateLastSignInDateTime. Microsoft is specific that it is not an audit trail. It is only re-evaluated when the delta exceeds 14 days, with a plus or minus 5 day variance. Microsoft therefore warns against treating a timestamp younger than 21 days as an indicator of staleness.
dsregcmd /status. Do not go looking for an administrative template.The same question can be asked of the registry, which is useful when you only have a remote session and no portal access.
Step 4: audit the whole tenant at once
Checking one device is fine for a ticket. Finding the orphans you do not know about needs a tenant-wide join, and that means Microsoft Graph.
Three collections, three least-privilege read scopes. Every one of these is documented on the relevant Graph reference page.
| Collection | Endpoint | Least-privilege read scope |
|---|---|---|
| Autopilot registrations | GET /deviceManagement/windowsAutopilotDeviceIdentities | DeviceManagementServiceConfig.Read.All |
| Intune managed devices | GET /deviceManagement/managedDevices | DeviceManagementManagedDevices.Read.All |
| Entra ID device objects | GET /devices | Device.Read.All |
The companion script does exactly that, then reports six classes of finding.
| Code | What it means | Typical cause |
|---|---|---|
AP-NO-INTUNE | Autopilot registration claims an Intune enrolment that no longer exists | Someone deleted the Intune record and stopped there |
AP-NO-ENTRA | Autopilot names an Entra device id with no matching directory object | The Entra object was hand-deleted. Self-deploying and pre-provisioning will fail |
INTUNE-NO-ENTRA | Intune record names an Entra device id with no matching object | Entra cleanup ran without retiring in Intune first. Conditional Access has nothing to evaluate |
ENTRA-NO-INTUNE | Entra thinks the object is managed, but Intune has no record | A device clean-up rule hid the Intune record, or it was deleted directly |
ENTRA-NO-AP | Entra object carries a ZTDID but no Autopilot registration matches | Deregistered from Autopilot while the directory object stayed. Dynamic groups keyed on ZTDID still catch it |
AP-NEVER-SEEN | Registered, enrollmentState of notContacted, never contacted the service | Normal for stock on a shelf. Suspicious for hardware you believe is deployed |
-MinimumRecords floor. An empty collection would make every record in the other two services look orphaned, so it exits 1 rather than printing a reassuring zero.The fix: the documented order, and cleaning up what you already have
There is one documented order. Microsoft states that skipping steps or removing records out of order "can result in orphaned records or unrecoverable devices."
Step 1: delete from Intune first
- Sign in to the Microsoft Intune admin center.
- Select Devices, then under By platform select Windows.
- Find the device under Device name and select it.
- Note the Serial number on the properties screen.
- Select Delete in the toolbar.
- Select Yes to confirm.
Step 2: deregister from Windows Autopilot
- Confirm step 1 completed.
- Go to Devices > Windows, then under Device onboarding select Enrollment.
- Under Windows Autopilot, select Devices.
- Find the device using Search by serial number.
- Select the checkbox next to the device.
- Open the … menu on that row. If Unassign user is available, select it and confirm with OK.
- With the device still selected, choose Delete in the toolbar and confirm with Yes.
- Select Sync to accelerate the process, then Refresh every few minutes until the device disappears.
Step 3: do nothing in Entra ID, unless the join type says otherwise
| Join type | What Microsoft says to do |
|---|---|
| Microsoft Entra joined | No additional steps are required after deregistering through Intune. "Avoid manually deleting the device from Microsoft Entra ID, as this can cause unexpected issues" |
| Microsoft Entra hybrid joined | Delete the computer object from on-premises Active Directory Domain Services so it is not resynced. No further Intune or Autopilot action is needed, and again avoid manually deleting from Entra ID |
How long to wait
Microsoft says the deregistration process "might take some time" and that selecting Sync accelerates it. For imports it says the sync "might take several minutes." No fixed propagation figure is published for the deregistration path, so treat any specific number you see quoted elsewhere as folklore. Poll with Refresh and confirm by absence.
Working through the orphans you already have
Reverse-engineering a clean state from a messy one is not the same as retiring a device correctly. Handle each finding class differently.
AP-NO-INTUNEandAP-NEVER-SEEN: decide whether the hardware still exists. If it is gone, deregister from Autopilot using step 2 above. If it is on a shelf, leave the registration alone.ENTRA-NO-INTUNE: check whether a clean-up rule merely hid the Intune record. Microsoft notes hidden devices can reappear if they check in before the device certificate expires, so do not assume the enrolment is dead.ENTRA-NO-AP: the directory object outlived its registration. Confirm by serial number, then follow the stale-device process: disable for a grace period first, delete only afterwards.AP-NO-ENTRAandINTUNE-NO-ENTRA: this is the painful class. The anchor object is missing. Expect self-deploying and pre-provisioning failures, and expect to delete and reimport the Autopilot registration to recreate the object.
accountEnabled to false, wait out a documented grace period, and only then delete. Cloud Device Administrator or Intune Administrator is enough to make that change.Proof it worked: the same audit, run twice
The only honest proof is a before-and-after from the same tenant-wide join. Run the script, do the cleanup, run it again.
That combination is the textbook AP-NO-INTUNE orphan. Autopilot still reports the device as enrolled, because the enrolment state on the registration record is a stored value rather than a live lookup. The Intune record it points at is gone.
Verified community deep-dives
| Author | Article | Why it is relevant here |
|---|---|---|
| Peter van der Woude | Using device clean-up rules in Microsoft Intune | States directly that clean-up rules do not affect device objects in Microsoft Entra, and that they hide rather than delete |
| Rudy Ooms | Autopilot for pre-provisioned deployment and the lost Azure/Entra Ad Join | Walks a real case where a device looked joined in the portal but was not, and removing the directory object while keeping the Autopilot registration restored the join |
References
- Windows Autopilot registration overview — Microsoft Learn. Deregister a device, the documented order, and what happens to the Entra device object afterwards.
- Manually register devices with Windows Autopilot — Microsoft Learn. The three-record statement, and the registration failure codes.
- How to manage stale devices in Microsoft Entra ID — Microsoft Learn. ZTDID consequences, system-managed devices, BitLocker keys, disable-before-delete.
- Automatically hide devices with cleanup rules — Microsoft Intune. The 30 to 270 day range, and the note that hidden devices are not removed from Entra ID.
- Device action: Delete — Microsoft Intune. What Delete triggers per platform, and the daily tenant limit.
- Windows Autopilot troubleshooting FAQ — Microsoft Learn. Event IDs, the diagnostics registry key, error 0x80180014, and the Entra anchor object.
- windowsAutopilotDeviceIdentity resource type — Microsoft Graph v1.0.
- managedDevice resource type — Microsoft Graph v1.0.
- device resource type — Microsoft Graph v1.0.
- List devices — Microsoft Graph v1.0. Least-privilege permission is
Device.Read.All.
Download it from Imran76Awan/Windows-Autopilot-Scripts — no sign-in required. It is read-only: it reports and never changes a device or anything in Intune. Validate it in your own environment before relying on the output.