Autopilot hash import stuck at Syncing: why the device never gets its profile

Most admins treat an Autopilot hash import stuck at Syncing as a slow upload: wait, refresh, then delete the record and push the CSV again. A row that says Syncing is not a registered device, and a second upload just puts a second request into the same failure.

These are the three places we check, in order, when a tenant we assess has hashes that never turn into a profile at OOBE.

Is it the service? An active Autopilot import incident

Before touching the CSV, open Microsoft 365 admin center > Health > Service health and look at Intune advisories and incidents. On Sep 29–30, incident IT1483380 had hash imports stuck processing, group tags not persisting, and devices not finding their profile. Admins on r/Intune described Get-WindowsAutopilotInfo -Online looping, then returning "Error 509", with the portal showing "Syncing 1 Windows Autopilot devices." Microsoft doesn't document what Error 509 means for Autopilot, so don't build a fix around it. Read it as "check the service and the import result."

What breaks it:

• Service health first. If an Autopilot or Intune import incident is open, stop. Every re-upload during an incident is another record to clean up later.
• Import one device, not the batch. Once the incident clears, a one-row CSV tells you whether the service is processing again.
• Write down the timestamp. You'll need it when you match the import against the device record.

Is it the import? The registration error Microsoft documents

When the service is healthy, the import result tells you more than the Syncing label does. Microsoft Learn's manual registration page lists the failures: ZtdDeviceAlreadyAssigned (the hash is already registered somewhere), ZtdDeviceAssignedToAnotherTenant (another tenant owns it, so a reseller or the previous owner has to deregister it), and StorageError (a service-side storage problem; try again later).

What breaks it:

• Open Devices > Windows > Enrollment > Devices (Windows Autopilot), filter by serial number, and read the import status before you delete anything.
• Match the error to Learn's table. The other-tenant error needs the owning tenant or the OEM to deregister. Re-uploading won't clear it.
• Check the serial in the record. If the serial is wrong or truncated (one Oct 9 thread showed a serial of "n" after a convert-to-Autopilot), recapture the hash on the device. Don't edit the CSV by hand.

Is it the assignment? Registered, but no profile

Sometimes the import really did work. The device shows as registered and still reaches OOBE with the standard consumer screens. Learn's troubleshooting FAQ is plain about this: the device downloads a profile only when one is assigned to it. That depends on the group tag, a dynamic group rule that reads it (device.devicePhysicalIds -any (_ -eq "[OrderID]:TAG")), and the profile's assignment status. When OOBE says "provisioning information could not be located," it's usually this step, not the import.

What breaks it:

• Group tag saved? During the incident, tags didn't persist. Re-check the tag on the record, not in your CSV.
• Dynamic group membership. Confirm the device object is actually in the group. Dynamic group processing isn't instant, and Microsoft doesn't publish an SLA for it, so check membership instead of waiting a set time.
• Profile status. The Autopilot device record should show the assigned profile. If it shows unassigned, the device will run consumer OOBE every time.

What "good" looks like: the five-move baseline

1. Check Service health for an Intune or Autopilot import incident before any upload.
2. Import one row and read its status and any registration error on the device record.
3. Resolve the documented error (already assigned, other tenant, storage) using Learn's table, not a guess.
4. Verify the group tag, dynamic group membership, and assigned profile on the record before OOBE.
5. Make one change, then re-test OOBE. Don't loop on delete and re-upload.

None of this needs new licensing. All of it is visible in the Intune admin center and Service health.

If hashes keep sitting at Syncing, or the device reaches OOBE with no Autopilot profile after the import "worked," our Windows Autopilot Consulting Assess path names the broken registration step before you upload the same CSV again.

The uncomfortable question

If your last three Autopilot devices needed a second upload, do you know which step failed: the service, the import, or the assignment? Or did the second upload just happen to land after the problem cleared? Pull the Autopilot device records and the Service health history for those dates. That's where the answer is.