Skip to content
June 26, 2026 Senior (5+ years) Error Reference

Fix Windows Autopilot Error 809: Assigned Profile Does Not Exist

Troubleshoot Windows Autopilot error 809 when a deleted deployment profile leaves devices stuck without a valid assigned profile during OOBE.

Methodology

Practical guidance for working engineers, with a bias toward steps you can verify and repeat.

• What it covers: the exact problem, workflow, or decision
• What to verify: logs, settings, outcomes, or pass/fail checks
• What to avoid: risky changes without rollback or validation
• What to expect: prerequisites, caveats, and role fit

Updated: June 26, 2026

Fix Windows Autopilot Error 809: Assigned Profile Does Not Exist

If a Windows Autopilot device fails during OOBE and the diagnostics page or event logs show error 809 with ZtdDeviceHasNoAssignedProfile - Assigned profile does not exist, do not start with wipes, network resets, or TPM guesses. Microsoft’s own troubleshooting guidance is direct: this happens when the Autopilot deployment profile that used to be assigned to the device was deleted before the assignment was cleaned up.

That makes this a control-plane problem first. The device is usually still registered in Autopilot. It may still have the right hardware hash. It may even be reaching the service correctly. But the service-side profile reference is broken, so the device cannot continue with a usable deployment profile.

The practical fix is to assign a valid profile again, wait for the assignment to finish all the way through Profile Status = Assigned and Date assigned being populated, then retry the device. If you skip the waiting part, you can repair the admin portal and still reproduce the same field failure.

Quick fix checklist

Use this order before you reset another device:

  1. Confirm the device really shows error 809 or ZtdDeviceHasNoAssignedProfile - Assigned profile does not exist.
  2. In Intune, open Devices > Windows > Windows enrollment > Devices and verify the device still exists in Windows Autopilot devices.
  3. Check whether the originally assigned deployment profile was deleted, replaced, or moved to a different group.
  4. Assign a valid Autopilot deployment profile to the device or to the group that contains it.
  5. Wait until the device shows Profile Status = Assigned.
  6. Open device properties and confirm Date assigned is populated.
  7. If group-based assignment is used, make sure the device is actually in the expected Microsoft Entra group.
  8. Reset or rerun OOBE only after the assignment is fully settled.

If the device shows 809, the fastest useful question is not “Is Wi-Fi broken?” It is “What profile did this device think it had, and who deleted it?”

What error 809 actually means

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

ZtdDeviceHasNoAssignedProfile - Assigned profile does not exist.

Microsoft’s explanation is equally important:

The Windows Autopilot profile assigned to the device was deleted without first getting cleaned up.
Assign a different Windows Autopilot profile to the device and then attempt to re-enroll the device.

That wording matters because it separates 809 from nearby Autopilot failures:

  • 807 usually means the device is not properly registered in Autopilot.
  • 815 means no profile is assigned and no default profile can catch the device.
  • 809 means there was an assignment relationship, but the referenced profile is gone.

In other words, 809 is usually an admin-side lifecycle mistake, not a device-side enrollment mystery.

How admins usually create this outage

In production, error 809 often appears after one of these changes:

1. A profile was deleted during cleanup

This is the most common path. An admin removes an old user-driven, self-deploying, or pre-provisioning profile because it looks unused, but some devices are still assigned to it or haven’t finished consuming the assignment yet.

2. A pilot group was reworked too quickly

A device may move between groups while Autopilot profile assignment is still catching up. Microsoft notes that assignment timing depends on several moving parts, including:

  • Microsoft Entra group membership
  • membership rules
  • device hash state
  • Intune and Autopilot service processing
  • internet connectivity

That means a “fixed” group assignment in the portal is not proof the device is ready right now.

3. A replacement profile was created, but the device was redeployed too early

This is where teams lose time. The old profile gets deleted, a new one is assigned, and the device is wiped immediately. Microsoft explicitly says to watch the Profile Status column move from Unassigned to Assigning to Assigned, and then verify that Date assigned is populated. If you skip that validation, the next OOBE run can still fail.

4. Group conflicts or default-profile assumptions were misunderstood

Microsoft also documents that if multiple profiles target the same device, the oldest created applicable profile wins. If no specific profile is applicable and a default profile exists, the default profile can apply instead. That sounds helpful, but during cleanup it can confuse troubleshooting:

  • one admin expects a new profile to apply
  • another assumes the default profile will catch the device
  • the device still has stale assignment state from the deleted profile path

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 is still registered
  • the serial number matches the device in front of you
  • the Profile Status is not stuck at Unassigned or Assigning
  • the assigned profile is a real, existing profile
  • Date assigned is populated once the status shows Assigned

Then review the deployment profile side:

Devices > Windows > Windows enrollment > Deployment Profiles

Check:

  • whether the old profile was deleted recently
  • whether the replacement profile is assigned to the right device group
  • whether the profile type matches the intended scenario
  • whether group membership changes were made recently

On the device

If you can open the Autopilot diagnostics page or collect local evidence, check the profile-related state instead of only generic ESP screens.

Microsoft documents that Autopilot profile settings downloaded 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 “device never got any Autopilot state” from “device is talking to the tenant but the profile relationship is broken.”

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.
  • If TenantMatched is 0, the sign-in tenant does not match the tenant the device is registered to.
  • If IsAutopilotDisabled is 1, the device may not currently be functioning as an active Autopilot registration or failed to download the profile because of connectivity or timeout conditions.
Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Where-Object {
    $_.Message -match '809|815|807|ZtdDeviceHasNoAssignedProfile|Assigned profile does not exist'
  } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

If event 809 appears, keep the repair focused on profile assignment. Do not lump it into a generic “Autopilot sometimes fails” bucket.

Confirm join state while you triage

dsregcmd /status

This does not prove the profile is healthy, but it helps rule out side noise when someone claims the issue is caused by a tenant mismatch or partial registration path.

Repair workflow that works in the field

Step 1: Reassign a valid deployment profile

In Intune, assign a real Autopilot deployment profile to the device or to the group that contains the device.

If the old profile was deleted, do not try to recover the deleted object logically in your head. Create or choose the profile you actually want going forward, then verify the assignment path end to end.

Step 2: Wait for assignment completion

This is the step teams skip.

Microsoft’s profile-assignment guidance says to monitor the device in Windows Autopilot devices until the Profile Status changes:

Unassigned -> Assigning -> Assigned

Then open the device properties and confirm:

Date assigned is populated

If Date assigned is blank, the assignment is not done enough for a clean redeployment decision.

Step 3: Validate group membership if using dynamic or assigned groups

If the profile is not assigned directly to a device but through group membership, verify the device is actually in the target Microsoft Entra group.

This is where pilot changes and cleanup work collide. A profile can be correct on paper while the device hash, group evaluation, or import timing still leaves the device effectively unassigned.

Step 4: Check whether a default profile is helping or hurting

Microsoft documents that devices registered in Autopilot but lacking a specific assigned profile can receive the default Windows Autopilot profile if one exists.

That can be helpful, but it can also create false confidence. If you expect a kiosk or self-deploying configuration and the device quietly falls toward a different default profile, your next symptom might change instead of disappear.

So verify the exact profile name and type the device is meant to receive. Do not assume “some profile is better than none.”

Step 5: Reset and retry only after assignment is stable

Once the profile is assigned and visible in Intune with a populated Date assigned, rerun the Autopilot deployment.

For stubborn records, many admins also use a cleanup-and-reregister path on test devices:

  1. delete the stale Intune device object if appropriate
  2. confirm the Autopilot device record is correct
  3. make sure the device is assigned to the intended profile
  4. wait for assignment completion
  5. reset the device and retry

Use that path carefully in production so you do not create fresh identity confusion while chasing the original issue.

What not to do

Do not delete and recreate profiles without checking assignment state

If you repeatedly delete profiles during cleanup, you can turn one 809 device into a wider pilot outage.

Do not redeploy while status still shows Assigning

This is one of the biggest avoidable mistakes. The admin portal looks fixed, but the backend assignment is not finished.

Do not confuse 809 with 815

Both reference missing profiles, but they are not the same repair:

  • 809 = the assigned profile reference points to a profile that no longer exists.
  • 815 = no usable profile is assigned, and no default profile is available.

The branch matters because 809 usually sends you looking for a deleted or replaced profile object, while 815 often sends you toward assignment scope and default-profile coverage.

Do not spend hours on network-only troubleshooting if 809 is already proven

Network issues can block Autopilot, but Microsoft already gives you the direct meaning of 809. Once you have it, the burden is on the profile assignment path first.

Prevention

To avoid repeat 809 incidents:

  • treat Autopilot profile deletion as a controlled change, not casual cleanup
  • export or document which groups and device sets a profile serves before deleting it
  • replace profiles first, then validate assignment, then retire the old profile
  • wait for Assigned plus populated Date assigned before wipe-and-redeploy actions
  • use a small pilot group when changing profile strategy
  • keep a runbook that distinguishes 807, 809, and 815 so technicians do not use one fix for all three

If your team regularly swaps Autopilot profiles for pilots, kiosks, hybrid scenarios, or naming updates, this control matters more than the one-time fix. Most 809 incidents are created by admin timing, not by bad hardware.

Conclusion

Windows Autopilot error 809 is usually a precise signal, not a vague enrollment failure. Microsoft’s guidance ties it to a deleted deployment profile that was still assigned to the device path. The working repair is to assign a valid profile, wait until Profile Status reaches Assigned, confirm Date assigned, and only then retry the device.

If you treat 809 like a generic OOBE failure, you waste time on wipes and endpoint troubleshooting. If you treat it like a broken profile reference in Intune, the fix usually becomes straightforward.

Sources

  • Microsoft Learn: Windows Autopilot troubleshooting FAQ
  • Microsoft Learn: Configure Windows Autopilot profiles
  • Microsoft Learn: Windows Autopilot known issues
  • Microsoft Learn: Windows Autopilot troubleshooting FAQ for OOBE
Was this helpful?

Comments

Comments are coming soon. Have feedback? Reach out via the About page.