Fix Windows Autopilot Error 815: No Profile Assigned and No Default Profile Found

If a Windows Autopilot device fails during OOBE and the diagnostics page or event logs show error 815 with ZtdDeviceHasNoAssignedProfile - No profile assigned to the device, and no default profile found in the tenant., stop treating it like a generic network or TPM issue. Microsoft’s troubleshooting guidance is direct: Autopilot could not find any deployment profile for that device.

That makes error 815 a profile-assignment outage first. The hardware hash can be valid. The device can still be talking to the right tenant. Internet access can even be fine. But if no usable Autopilot profile is assigned, and no tenant-wide default profile can catch the device, the deployment has nowhere to go.

In practice, the repair is usually straightforward: assign the right profile, verify the assignment actually completes, confirm the device is in the intended Microsoft Entra group, and only then rerun the deployment.

Quick fix checklist

Use this order before you wipe another device:

1. Confirm the device really shows error 815 or ZtdDeviceHasNoAssignedProfile - No profile assigned to the device, and no default profile found in the tenant.
2. In Intune, open Devices > Windows > Windows enrollment > Devices and verify the device still exists in Windows Autopilot devices.
3. Check whether the device is assigned to a deployment profile directly or through group membership.
4. If the device should receive a specific profile, confirm it is in the correct Microsoft Entra security group.
5. If you expect fallback behavior, confirm a default Windows Autopilot profile actually exists and is targeted to all devices.
6. After assigning a profile, monitor Profile Status until it moves from Unassigned to Assigning to Assigned.
7. Open device properties and confirm Date assigned is populated.
8. Retry OOBE only after assignment is fully settled.

If the device shows 815, the fastest useful question is not “Did Wi-Fi drop?” It is “What Autopilot profile was this device supposed to receive, and why didn’t it get one?”

What error 815 actually means

Microsoft documents event 815 in the Windows Autopilot troubleshooting FAQ as:

ZtdDeviceHasNoAssignedProfile - No profile assigned to the device, and no default profile found in the tenant.

Microsoft’s explanation is the key part:

A Windows Autopilot profile wasn't found assigned to the device. Validate that a Windows Autopilot profile is assigned to the device.

That wording matters because it separates 815 from other Autopilot failures that look similar on the surface:

• 807 usually means the device is not properly registered in Autopilot.
• 809 means a profile reference existed, but the assigned profile was deleted.
• 815 means the service could not find any usable profile path at all.

So 815 is not usually a deleted-profile problem and not usually a TPM problem. It is most often an assignment-scope, group-membership, or default-profile gap.

Why admins usually create this failure

Error 815 often appears after routine cleanup or rollout changes, not after some dramatic backend outage.

1. The device was imported, but no profile ever targeted it

This is the cleanest version of 815. The hardware hash upload succeeded, the Autopilot record exists, but nobody assigned a deployment profile to the device or the group that contains it.

That can happen after:

• new device imports
• reseller uploads that finish before profile assignment is built
• pilot devices being moved to a different enrollment strategy
• a manual registration workflow that stopped after import

2. The device is in the wrong Microsoft Entra group

Many Autopilot environments rely on assigned or dynamic groups for profile targeting. On paper, the profile looks correct. In reality, the device is not in the group the profile is assigned to, so Autopilot has no matching profile to deliver.

Common causes include:

• dynamic membership rules that do not match the imported device yet
• technicians resetting devices before group evaluation finishes
• devices being moved between pilot and production groups too quickly
• admins assuming group membership changed because the portal change saved successfully

3. Teams assume a default profile exists when it does not

Microsoft’s profile guidance says that if a device is registered in Windows Autopilot and a specific profile is not assigned, it can receive the default Windows Autopilot profile. But that only helps if a default profile really exists and is targeted correctly.

A lot of shops assume they have a safety net here when they do not. Then a device misses its intended profile and there is no default path to catch it, which is exactly how 815 happens.

4. The device was redeployed before assignment finished

Microsoft tells admins to watch Profile Status change from Unassigned to Assigning to Assigned, and then verify that Date assigned is populated before deploying the device.

That timing matters. If you reset a device while assignment is still incomplete, you can create a field failure that looks random even though the root cause is simply that the assignment pipeline had not finished.

5. The device should not be in Autopilot at all

Microsoft also notes that if a device is registered in Windows Autopilot and no profile is assigned, the default profile applies when one exists. If the device should not go through Autopilot, the right fix is not to keep guessing at profiles. The right fix is to remove the Autopilot registration.

That scenario matters for reused devices, lab devices, and records that were imported for testing but never meant to stay in production.

Where to check first

Start in Intune, not on the endpoint.

In Intune admin center

Go here first:

Devices > Windows > Windows enrollment > Devices

For the affected Autopilot record, verify:

• the device still exists in Windows Autopilot devices
• the serial number matches the hardware in front of you
• Profile Status is not stuck at Unassigned
• a real deployment profile is assigned directly or through group scope
• Date assigned is populated once the status shows Assigned

Then review the profile side:

Devices > Windows > Windows enrollment > Deployment profiles

Check:

• whether the intended profile still exists
• whether it is assigned to the correct Microsoft Entra group
• whether a default profile is configured for all devices if you rely on fallback behavior
• whether multiple profiles could be competing for the same device

Microsoft’s profile documentation also warns that if a group is assigned to multiple Autopilot profiles, the oldest created applicable profile wins. That can create confusion when a team thinks a newer pilot profile should apply but an older profile still has scope.

On the device

If you can collect local evidence, check whether the device downloaded Autopilot tenant data at all.

Microsoft documents that Autopilot profile settings received from the service are stored here:

HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot

Useful values include:

• CloudAssignedTenantDomain
• CloudAssignedTenantId
• IsAutopilotDisabled
• TenantMatched
• CloudAssignedOobeConfig

These values help you separate two different situations:

• the device never received usable Autopilot state
• the device reached the tenant, but no valid profile assignment path existed

Logs and PowerShell checks

Run these checks on one affected device after reproducing the issue.

Check the main Autopilot registry state

$path = 'HKLM:\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot'
Get-ItemProperty -Path $path -ErrorAction SilentlyContinue |
  Select-Object CloudAssignedTenantDomain, CloudAssignedTenantId, IsAutopilotDisabled, TenantMatched, CloudAssignedOobeConfig

Interpretation:

• If CloudAssignedTenantDomain is blank, the device may not have downloaded usable Autopilot state yet.
• If TenantMatched is 0, the sign-in tenant does not match the tenant the device is registered to.
• If IsAutopilotDisabled is 1, the device is either not functioning as an active Autopilot registration or the profile could not be downloaded because of connectivity, firewall, or timeout conditions.

Pull profile-related event evidence

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Where-Object {
    $_.Message -match '815|809|807|ZtdDeviceHasNoAssignedProfile|No profile assigned to the device'
  } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

If event 815 appears, focus on assignment coverage first. Do not burn hours on speculative TPM or ESP theory before you prove the profile path exists.

Confirm join state while you triage

dsregcmd /status

This does not fix 815 by itself, but it helps rule out side noise when someone claims the issue is really a tenant mismatch, wrong user, or half-finished join state.

Repair workflow that works in the field

Step 1: Decide whether the device should use Autopilot at all

If the record should not exist in Windows Autopilot, remove the registration and stop troubleshooting 815 as though it were a normal deployment profile issue.

If the device should stay in Autopilot, continue with assignment repair.

Step 2: Assign the intended deployment profile

Assign a real Windows Autopilot deployment profile to the device, either directly or through the Microsoft Entra group that contains it.

Be explicit here:

• user-driven versus self-deploying versus pre-provisioning
• pilot versus production profile
• cloud-native versus hybrid scenarios

A vague “some profile should catch it” approach is exactly how 815 survives repeat retries.

Step 3: Validate group membership if the profile is group-based

If the profile is assigned through a group, prove the device is actually in that group.

This is where many 815 incidents live. The profile is healthy. The device record is healthy. The tenant is healthy. The group targeting is not.

Step 4: Wait for assignment completion

This is the step most teams skip.

Microsoft’s assignment guidance says to monitor the Windows Autopilot devices list until the device moves through:

Unassigned -> Assigning -> Assigned

Then open the device properties and confirm:

Date assigned is populated

If Date assigned is still blank, treat the assignment as incomplete.

Step 5: Confirm whether a default profile should exist

If your operating model expects devices without a specific assignment to fall back safely, confirm that a default Windows Autopilot profile is actually configured and targeted to all devices.

If your operating model does not want a default profile, then 815 becomes a useful signal that assignment discipline is broken. In that case, the fix is not to add random fallback coverage. The fix is to repair the intended profile targeting model.

Step 6: Retry OOBE only after the assignment is stable

Once the device shows Assigned and Date assigned is populated, rerun the Autopilot deployment.

For stubborn lab or pilot records, admins often use this path:

1. verify the Autopilot device record is correct
2. assign the intended profile
3. confirm group membership if applicable
4. wait for full assignment completion
5. reset the device and retry

That order is boring, but it works far more reliably than repeated wipes with no assignment proof.

What not to do

Do not confuse 815 with 809

Both mention missing profiles, but the repair branch is different:

• 809 = the device points to a profile that was deleted
• 815 = the device has no usable profile assignment path and no default profile fallback

If you chase a deleted profile when the real problem is missing scope, you lose hours.

Do not redeploy while status still shows Unassigned or Assigning

If you rerun OOBE before the backend has finished assigning the device, you are testing impatience, not testing the fix.

Do not assume the default profile exists

A lot of teams think they have a default profile because they used to have one, because another admin mentioned one, or because one exists in a different tenant. Verify it.

Do not treat every Autopilot miss as a device-side problem

Error 815 is often created by admin-side targeting gaps. Reimaging the device does not repair a bad scope model.

Prevention

To avoid repeat 815 incidents:

• document which groups feed which Autopilot deployment profiles
• review dynamic membership rules after changing naming, import, or tag strategies
• use a small validation batch after new device imports before resetting large numbers of endpoints
• decide intentionally whether your tenant should rely on a default Autopilot profile
• require technicians to confirm Profile Status = Assigned and populated Date assigned before redeployment
• remove stale Autopilot registrations for devices that are no longer supposed to use Autopilot
• review overlapping profile assignments so older profiles do not quietly win conflicts

Error 815 is usually not dramatic. It is usually a process miss. That is good news because process misses are easier to fix permanently than mystery hardware failures.

Bottom line

Windows Autopilot error 815 means the device did not get a usable deployment profile, and no default tenant profile existed to catch it. Microsoft’s guidance points straight at assignment validation: confirm the Autopilot record, confirm the profile target, confirm the device is in scope, wait for Assigned plus Date assigned, and only then retry the deployment.

Once you treat 815 as an assignment-control problem instead of a generic OOBE failure, the fix path gets much shorter.