Read the error as an ownership clue
Two common Autopilot import failures are useful because they narrow the investigation:
| Signal | What it usually means | Start here |
|---|---|---|
| ZtdDeviceAlreadyAssigned (806) | The hardware identity is already represented by an Autopilot registration. | Search the current tenant and verify whether the existing record is expected. |
| ZtdDeviceAssignedToOtherTenant (808) | The device identity is associated with a different tenant. | Confirm transfer history, reseller/OEM involvement, and prior ownership. |
| Duplicate rows before upload | The same serial or hardware hash appears more than once in the prepared file. | Deduplicate the batch before investigating tenant state. |
1. Eliminate a file-level duplicate
Before changing tenant records, prove that the conflict is not self-inflicted. Compare normalized serial numbers and full hardware hashes across the batch. Remove exact duplicate rows. If the same serial appears with different hashes—or the same hash appears against different serials—stop and return to the source data instead of choosing a row arbitrarily.
Keep the original files unchanged. Perform cleanup on a working copy and record which source files contributed each row. That evidence matters when the device has passed through multiple technicians, customers, or tenants.
2. Search the current tenant
In the Intune admin center, open the Windows Autopilot devices view and search for the serial number. Do not limit the investigation to the ordinary managed-device list; an Autopilot registration and an enrolled Intune device are related but distinct records.
When you find a matching Autopilot device, verify:
- The serial number and model align with the physical device.
- The group tag and assigned profile reflect the current deployment.
- The record belongs to the intended customer and tenant.
- No active deployment, reset, reassignment, or support case depends on it.
- You have authorization to remove and re-register it.
3. Delete only the obsolete Autopilot registration
If the record is confirmed obsolete, Microsoft’s documented recovery path is to delete the Windows Autopilot device record and allow time for deletion to complete before importing again. Treat this as a controlled change. Capture the current record details first, note the reason for removal, and avoid making the deletion while the endpoint is in an active provisioning workflow.
4. Handle an other-tenant assignment
If no matching Autopilot record exists in the tenant you control, the device can still be registered elsewhere. This commonly surfaces after resale, lease return, refurbishment, customer migration, reseller registration, or an incomplete offboarding process.
The cleanest resolution is for the previous organization or registering partner to remove the device from its tenant. When that route is unavailable, Microsoft’s current troubleshooting guidance says support may need to remove the record. Prepare the device CSV that produces the error and proof of ownership such as an invoice or bill of sale. Preserve case notes and the serial number throughout the escalation.
5. Re-import carefully
- Wait for the prior deletion or support action to propagate.
- Use a freshly validated CSV containing the single affected device.
- Confirm you are signed into the intended tenant.
- Import the record and monitor its registration state.
- Verify the resulting group tag, profile assignment, and expected tenant ownership before expanding the batch.
Repeated rapid imports rarely help. If the backend has not completed deletion, retries add noise without changing ownership state.
Evidence worth keeping
- Original and cleaned CSV files.
- Serial number, manufacturer, model, and collected hardware identity.
- Screenshot or export of the import error and timestamp.
- Current tenant ID and customer context.
- Existing Autopilot record details before deletion.
- Purchase, transfer, or lease-return documentation when another tenant may be involved.
- Microsoft support request and final resolution.