Decommissioning Windows Devices in Intune: Retire, Wipe, Cleanup

#Operational requirement

Hardware refreshes and leaver offboarding generate a recurring, unglamorous task: taking a Windows device out of active management without leaving orphaned objects behind. This is usually one of the first real production assignments handed to a new endpoint engineer — “decommission these fourteen laptops from the finance floor refresh” or “process this leaver’s device by Friday”. It looks trivial. It is not.

Get the sequencing wrong and you produce one of three production incidents. First: you issue a full Wipe against the wrong serial number and destroy a working device’s local data with no way to recover it, because Wipe is irreversible by design. Second: you Retire a device and remove it from Intune but forget to delete the Windows Autopilot device identity, so when that laptop is reimaged and handed to the next starter, Autopilot enrolment fails or silently reapplies the departed user’s old deployment profile. Third: you clean up Intune but leave the Entra ID device object and the hybrid on-prem AD computer object in place, which keeps a licence seat consumed and leaves a stale identity that a security audit will flag months later as an unaccounted-for endpoint.

This runbook walks a junior administrator through the correct decommission sequence: inventory and confirm, obtain change approval, execute the correct removal action (Retire versus Wipe), clean up the Autopilot identity, clean up Entra ID and any hybrid AD remnants, and produce verifiable evidence that the device is fully retired from every system of record. Follow it step by step; do not skip the confirmation steps because the ticket seems routine.

#Prerequisites and required permissions

• An Entra ID account assigned the Intune Administrator role, or a custom Intune RBAC role granting Managed Devices “Delete” and “Wipe” permissions.
• Entra ID Cloud Device Administrator role, or equivalent, to remove device objects.
• Microsoft Graph PowerShell SDK installed on your admin workstation:

Install-Module Microsoft.Graph -Scope CurrentUser

• Graph delegated scopes: DeviceManagementManagedDevices.PrivilegedOperations.All, DeviceManagementManagedDevices.ReadWrite.All, Device.ReadWrite.All, and DeviceManagementServiceConfig.ReadWrite.All for Autopilot identity deletion.
• An approved change record in your service management tool — bulk device wipe actions should never proceed on a verbal request alone.
• Confirmation that user data preservation, such as OneDrive Known Folder Move, has already completed, or an explicit written sign-off that no data preservation is required, for any device going through Wipe rather than Retire.
• Read access to your asset register so serial numbers can be cross-checked before any destructive action is issued.

#Step 1: Inventory and confirm device identity

Before touching anything, pull the exact managed device record and confirm you have the right hardware. Serial numbers and device names get transposed in spreadsheets constantly — this is the single most common cause of the “wrong device wiped” incident, and it is entirely preventable with one extra query.

1Connect-MgGraph -Scopes "DeviceManagementManagedDevices.PrivilegedOperations.All","DeviceManagementManagedDevices.ReadWrite.All","Device.ReadWrite.All"
2
3Get-MgDeviceManagementManagedDevice -Filter "deviceName eq 'FIN-LT-0231'" | Select-Object Id, DeviceName, SerialNumber, UserPrincipalName, ManagedDeviceOwnerType, EnrolledDateTime, LastSyncDateTime, ComplianceState

Expected result: a single device record returned with a serial number matching your asset register. Evidence to capture: export this record into the change ticket before proceeding. Checkpoint: if ManagedDeviceOwnerType shows personal, stop. BYOD devices go through a Retire, never a full Wipe, and require a separate consent conversation with the user.

#Step 2: Confirm data preservation

For corporate-owned devices going to full Wipe, verify OneDrive sync health for the assigned user, or obtain explicit written confirmation from the requesting manager that no data preservation is needed. Record the confirmation reference number in the ticket. This step exists because Wipe with keepUserData set to false is destructive, and Microsoft does not offer a recovery path from the managed-device side once the command has processed.

#Step 3: Raise and approve the change

Log a standard change with the device list, the action per device (Retire or Wipe), and a rollback plan attached. For batches larger than five devices, route the request through your change advisory board or equivalent lightweight approval. This is not because the technical risk is high; it is because the blast radius of a scripting mistake against the wrong device group is large enough to justify a second pair of eyes on the filter logic before execution.

#Step 4: Execute the correct removal action

Retire and Wipe are not interchangeable. Use the decision table below before issuing either command.

Issue the action via Graph:

1$deviceId = (Get-MgDeviceManagementManagedDevice -Filter "deviceName eq 'FIN-LT-0231'").Id
2
3# Wipe example
4Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$deviceId/wipe" -Body (@{ keepEnrollmentData = $false; keepUserData = $false } | ConvertTo-Json)
5
6# Retire example
7Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$deviceId/retire"

Expected result: HTTP 204 No Content on success. Evidence to capture: the response status, timestamp and device ID, pasted into the change ticket. Checkpoint: the action only processes when the device next checks in. If it has been offline more than ninety days, note this in the ticket and set a follow-up reminder rather than assuming completion.

#Step 5: Remove the Windows Autopilot device identity

This step is skipped constantly, and it is the reason reissued hardware breaks on the next starter’s first day. If the Autopilot identity remains registered, the next enrolment attempt either fails outright or silently reapplies the previous deployment profile and Enrollment Status Page settings.

1$autopilotDevice = Get-MgDeviceManagementWindowAutopilotDeviceIdentity -Filter "contains(serialNumber,'PF3XK912')"
2Remove-MgDeviceManagementWindowAutopilotDeviceIdentity -WindowsAutopilotDeviceIdentityId $autopilotDevice.Id

Expected result: the serial number no longer appears under Devices, Enrollment, Windows Autopilot Devices in the Intune admin centre. Evidence: a before-and-after screenshot of the Autopilot device list. Checkpoint: if the hardware was purchased through a reseller with Autopilot registration tied to the OEM, deletion here only removes the tenant assignment. The hardware hash itself may need re-registration on next enrolment, which is expected and not a fault.

#Step 6: Clean up Entra ID and hybrid AD remnants

Once the Intune object and Autopilot identity are gone, remove the corresponding Entra ID device object. If the estate is hybrid-joined, remove the on-prem AD computer object too, otherwise Entra Connect will resurrect a stale device record on the next sync cycle.

Get-MgDevice -Filter "displayName eq 'FIN-LT-0231'" | Remove-MgDevice

For hybrid environments, run the equivalent cleanup on-prem:

Remove-ADComputer -Identity "FIN-LT-0231" -Confirm:$false

Finally, unassign the Microsoft 365 licence from the associated user if this decommission is tied to a leaver, so the seat is reclaimed on the next billing cycle rather than left consumed indefinitely. Log this action separately, as licence reconciliation is often audited independently of device cleanup.

#Verification

• Intune admin centre: device no longer listed under Devices, All devices.
• Autopilot device list: serial number absent.
• Entra ID: a Get-MgDevice query for the device name returns no result.
• Hybrid AD, where applicable: computer object absent from the relevant organisational unit.
• Licence report: seat reassigned or returned to the available pool.
• Change ticket: closed with all screenshots and command output attached, referencing the original change record.

Cross-check the Entra ID audit log for the Delete device and Retire device events to confirm the actions were performed under your account and not duplicated by another administrator working the same batch. For recurring monthly refresh cycles, build a small dashboard query that lists devices marked for decommission against devices still appearing in Intune after seven days, so stalled offline devices surface automatically rather than being forgotten.

#Failure Modes

#Rollback

Retire actions can be cancelled before the device checks in again. If the device is still online and you catch the mistake immediately, issue a corrective enrolment sync and reassign the original configuration profiles and compliance policy from the appropriate Entra ID group; the device will re-baseline on its next sync without loss of MDM history if it never actually processed the retire.

Wipe actions cannot be rolled back once the device has processed the command. That is the entire point of Wipe. There is no vendor-supported reversal. Your rollback plan for a mistaken Wipe is: re-enrol the device through Autopilot or manual enrolment, reassign the user’s configuration profiles and app assignments from your baseline group, and restore any user data from the last known OneDrive or backup snapshot. Document the incident regardless of whether data was recoverable, and note the timestamp of the original mistaken command for the post-incident review.

If you deleted the wrong Autopilot identity, re-register the device using the hardware hash captured from Get-WindowsAutoPilotInfo, upload it via the Intune admin centre or partner portal, then reassign the correct deployment profile before returning the device to the field.

#Operational Summary

The deliverable for this task is a fully decommissioned device with no trace remaining in Intune, Autopilot, Entra ID or on-prem AD, and a closed change ticket carrying command output, timestamps and before-and-after screenshots as evidence. Practise the full sequence on a single test device in a lab tenant before running it against a production batch: create a test managed device object, run all six steps, and confirm all four systems of record show the device as gone. That one successful dry run, captured in your own notes, is what tells your manager you are ready to run this against a real hardware refresh without supervision.

Treat the Retire-versus-Wipe decision as a data-protection decision, not a technical one. The moment you issue a Wipe, the outcome is final, so the discipline in this runbook is entirely about verifying identity and intent before the irreversible step, not about the mechanics of the API call itself. A newly hired engineer who can run this sequence cleanly, with evidence, on the first attempt has demonstrated exactly the kind of careful, verifiable operational discipline that endpoint management teams depend on.