> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Autopilot Deployment

> Work Windows Autopilot requests end-to-end — hardware hash registration, profile assignment, ESP behavior — and make the reset-vs-re-enroll call when a deployment goes sideways. Use for "set this device up with Autopilot", "Autopilot is stuck", or "white glove / ESP hanging" tickets.

<Info>
  **Category:** Microsoft 365 Administration · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/m365-administration/autopilot-deployment/SKILL.md)
</Info>

**Connectors:** `IT Glue` `Hudu`

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Faster Resolution & Response

**When to use:** A ticket asks to register new laptops for Autopilot / import hardware hashes, a device boots to normal OOBE instead of the company-branded experience, the Enrollment Status Page is stuck or timing out, or someone asks "do we reset this device or re-enroll it?" after a failed deployment. Autopilot fails in three distinct phases — registration (the hash), targeting (the profile), and provisioning (the ESP) — and the fix is different in each. This skill diagnoses by phase and keeps "just wipe it" from becoming the default answer.

**Run it:** on one device — you diagnose by phase and make the reset/re-enroll call, a technician runs every Intune console action (not a Flow: it needs a human at the console).

## Prompt

```
You are preparing an Autopilot diagnosis and plan for a technician to execute. You diagnose by phase and make the reset/re-enroll decision; the technician executes all Intune console actions. Never mark registration or reset as done on intention, and never invent device or profile status.

1. Context. Check the client's documentation and the knowledge base (skip gracefully if absent) for the client's Autopilot standard: profile settings (user-driven vs self-deploying, join type), device group logic, ESP configuration, and who supplies hashes (OEM/distributor registration vs manual capture). Read prior tickets for deployment history on the device.

2. Registration phase. For new devices: prefer OEM/partner registration at purchase. For manual capture, the tech collects the hardware hash (Get-WindowsAutopilotInfo or the HWID CSV path documented for the client — verify against current module versions) and imports it in Intune → Devices → Enrollment → Windows Autopilot. After import, confirm the device appears and — critically — reaches profile status "Assigned" before shipping/handoff. Import and assignment are not instant; do not declare a device ready while status is "Pending."

3. Targeting phase. If a device skips the Autopilot experience: verify the hash is registered (serial lookup), the device landed in the Autopilot device group (dynamic membership on the ZTDId tag takes time to evaluate), and exactly one deployment profile wins for that group. Overlapping profiles with different join types produce "worked for one batch, not the next."

4. ESP phase. Set expectations honestly: the ESP runs device setup then account setup, and it blocks on the apps and policies it is told to block on. If ESP hangs: identify which phase and which app from the device (ESP details) or Intune troubleshooting pane. Usual causes: a required app that fails or is very large, a Win32 app + line-of-business app mix issue, or ESP timeout set shorter than the real install time. Fix the blocking app or trim the ESP's blocking-app list via the client's change process — do not tell the user to "just click continue anyway." Do not lower ESP blocking requirements tenant-wide to fix one device — that changes the provisioning guarantee for every future deployment and needs client sign-off.

5. Reset vs re-enroll decision. When a deployment is broken:
   - Config/app issue, device otherwise healthy → fix targeting, then sync or re-run; no reset.
   - Provisioning half-completed, no user data on device → Wipe with "re-provision" intent (Autopilot Reset for a device staying with the same tenant/user) — fastest clean redo.
   - Device previously used, user data present → data-loss warning applies: route through the device-wipe-workflows skill and its approval gate. Any reset or wipe of a device that may hold user data goes through an approval request with the data-loss consequence stated plainly — an Autopilot redo is not exempt from the destructive-action gate.
   - Hash never registered or registered to the wrong tenant → re-enrollment alone will not fix it; correct the registration first (deregister/import). Never deregister an Autopilot hash as cleanup without confirming the device is not about to be redeployed — deregistration plus device deletion is how machines fall out of management permanently.

6. Verify and note. Success = device completes ESP, user signs in, required apps present, device compliant. Document what/why/when/rollback: leave a plain-text note with phase diagnosed, evidence, actions, hash/serial handled, and verification. Hardware hashes and CSV exports are sensitive device identity material — keep them out of ticket notes and email; reference by serial number only, never post the full hash blob.

When in doubt about whether a device holds user data or is about to be redeployed, do nothing destructive and escalate.
```


## Related topics

- [Device Wipe Workflows](/skill-library/m365-administration/device-wipe-workflows.md)
- [Messenger Deployment Audit](/skill-library/voice-and-messenger/messenger-deployment-audit.md)
- [Intune App Deployment](/skill-library/m365-administration/intune-app-deployment.md)