Autopilot setup stopped. What should I check first?

The short answer

First identify the deployment flow and where setup stopped. Keep the observed error and time with the next evidence question. A timeout alone does not tell you which setting or application caused it.

Illustrative setup note · not a client result

“Setup timed out” is a starting point, not a diagnosis.

Observed: One setup reaches the ESP app stage and then times out.
Still unknown: The failing app or root cause. The last displayed item is not automatically the culprit.
Next check: Compare the exact phase and time with the authorized profile, report and tracked-app evidence.

An app may still be installing, or the evidence may be incomplete. Check the configured timeout and blocking behavior. This does not justify a wipe or disabling ESP.

Three checks that make the handoff useful

Identify the actual flow. Record whether an administrator confirms Windows Autopilot or Windows Autopilot device preparation, plus the deployment mode. If unknown, say so. ESP is also used in other enrollment contexts; seeing it alone does not establish Autopilot.
Capture the stopping point. Note the screen or stage, redacted error, observation time, last completed step and affected scope. Separate what the user saw from what an administrator confirmed.
Choose matching evidence. For ESP, the responsible administrator compares received settings with the apps or policies tracked at that stage. For device preparation, use its own deployment reporting, including application and script status. Agree the next check and its owner before changing the deployment.

Take something useful with you

Setup handoff worksheet

Use this when: You need to describe where device setup stopped.
Leave with: A concise observation, unknowns and the next evidence owner.

Download the blank worksheet (.txt)

Read or select the template here

WINHOVEN · SETUP HANDOFF WORKSHEET
Deployment flow and mode (administrator-confirmed / unknown):
Windows version/build:
Expected setup outcome:
Visible stage or screen:
Redacted error and observation time/time zone:
Last completed step:
Scope (one device / a subset / unknown):
Observed by user:
Confirmed by administrator:
Relevant evidence reference (keep privately):
Next evidence question:
Responsible owner:

Keep credentials, device/tenant identifiers, hardware hashes and raw logs out of a public inquiry.
Use the organization's approved channel for evidence. This note authorizes no reset or tenant change.

What this does not prove

A stage timeout is not a root cause, and completing setup does not prove every application or policy has applied. The worksheet collects no diagnostics and recommends no wipe, reset or bypass.

Need a working note for this problem? Prepare a question for the setup owner →

Planning a pilot instead?

Autopilot pilot evidence map

Compare evidence across working situations, rather than investigating one stopped setup. Leave with the next evidence question and an owner for each gap, not a rollout score.

Illustrative example, not a client result. An administrator has confirmed Windows Autopilot user-driven deployment for new starters who work remotely or at a branch. One remote setup reached the desktop; application usability and branch behavior remain unconfirmed.

Remote starter: Applicable: Yes. Evidence state: Evidence recorded. A dated desktop observation and private report reference exist, but application usability was not checked. Next owner/check: the app owner, not yet named here, confirms what evidence exists for the intended first-day task.
Branch starter: Applicable: Yes. Evidence state: Unknown. No confirmed record is available; this does not establish that a test never ran. Next owner/check: the deployment owner, not yet named here, checks the existing pilot evidence register.

Read the state, not a score

Evidence recorded means a dated observation and traceable reference, not a pass. Keep partial, failed or contradictory evidence visible.
Not yet tested requires the responsible owner to confirm that an applicable planned test was not performed.
Unknown means the relevant fact or evidence is unconfirmed, not failed. Record applicability separately; a confirmed nonapplicable case needs a reason.

The blank map covers remote setup, branch context, required application use and the existing support path. These are prompts, not an exhaustive test suite. The support-path row asks for an existing owner and escalation route, not a forced failure or recovery exercise.

Download the blank pilot evidence map

Read or select the pilot map here

WINHOVEN · AUTOPILOT PILOT EVIDENCE MAP
Purpose: compare existing evidence and gaps across chosen working situations.
This is an original Winhoven planning aid, not a required Microsoft test suite.
It does not establish readiness, representative coverage or approval to run tests.

Intended first-day user task and expected outcome:
Deployment flow and mode (administrator-confirmed / unknown):
Flow confirmation source and date:
App set/configuration version or private reference:
Observation window:
Evidence owner and approved private support location:

STATE KEY
Applicability: Yes / No (record the reason) / Unknown
Evidence recorded = dated observation + traceable reference, NOT a pass.
Keep failed, partial or contradictory observations with their limitations.
Not yet tested = responsible owner confirms an applicable planned test was not performed.
Do not infer Not yet tested from an empty worksheet.
Unknown = applicability, execution or evidence availability is not confirmed.
Missing evidence is not a failure; nonapplicable is not a pass.

1. REMOTE STARTER
Question: What was observed from initial setup through the expected usable desktop on the intended remote connection? Separate user observation from the matching administrator report.
Applicable: Yes / No (reason) / Unknown
Evidence state: Evidence recorded / Not yet tested / Unknown
Expected outcome:
Actual observation and limitations (or Unknown):
Private evidence reference, time/time zone and relevant context:
Next evidence question:
Named owner or Owner unknown:
Next authorized read-only check or approval needed:

2. BRANCH STARTER
Question: Is there evidence for the intended branch path? Keep context privately. Do not assume remote results apply or infer a network cause from different results.
Applicable: Yes / No (reason) / Unknown
Evidence state: Evidence recorded / Not yet tested / Unknown
Expected outcome:
Actual observation and limitations (or Unknown):
Private evidence reference, time/time zone and relevant context:
Next evidence question:
Named owner or Owner unknown:
Next authorized read-only check or approval needed:

3. REQUIRED APPLICATION
Question: Which intended first-day task was observed working? Keep setup/reporting or detection evidence separate from application usability. Installed alone does not answer this question.
Applicable: Yes / No (reason) / Unknown
Evidence state: Evidence recorded / Not yet tested / Unknown
Expected outcome:
Actual observation and limitations (or Unknown):
Private evidence reference, time/time zone and relevant context:
Next evidence question:
Named owner or Owner unknown:
Next authorized read-only check or approval needed:

4. SUPPORT HANDOFF IF SETUP STOPS
Question: Is an existing contact/escalation path recorded, with an owner able to review the exact flow, stage, time and approved evidence? Do not force a failure, wipe, recover or bypass setup for this row.
Applicable: Yes / No (reason) / Unknown
Evidence state: Evidence recorded / Not yet tested / Unknown
Expected outcome:
Actual observation and limitations (or Unknown):
Private evidence reference, time/time zone and relevant context:
Next evidence question:
Named owner or Owner unknown:
Next authorized read-only check or approval needed:

SUPPORT-PATH NOTE
For a documentation-only support-path row, record an actual owner/path or mark Unknown.
No artificial execution test is required. Not yet tested only describes a planned rehearsal
when its responsible owner confirms that it has not been performed.

Keep identifiers, hardware hashes and raw logs in your approved private support workspace.
These four prompts are not exhaustive. Do not infer the deployment flow from ESP alone.
A new test requires its own authorization. No device, access, policy or deployment change
is authorized by this note.

Winhoven’s original evidence-organizing aid, not Microsoft’s required pilot methodology. Complete it in your approved private workspace. A new test needs its own authorization; the map proves neither readiness nor representative coverage.