Setup guide · from scratch
Choose the USB / offline build options in the cockpit (Deploy plan)
The Deploy-plan screen's 'USB / offline build' card decides how your provisioning stick behaves: Standalone vs Autopilot-prep, Wi-Fi, debloat (remove consumer apps), bake in the latest Windows update, and which disk the stick erases. You set them once here; they flow into the downloaded plan and the builder obeys them without asking again.
≈ 5 min
Windows — Autopilot & USB provisioning · step 2 of 12 · ≈ 5 min‹ PreviousNext ›
Do these first — this guide assumes you already have:
- A Decolla cockpit build open at the Deploy plan screen.
The Decolla way — skip the clicks.
Every step below can be done by hand. Or connect your Microsoft tenant to Decolla once, and Decolla performs this for you over Microsoft Graph in your own tenant — then hands back a verified result you can see and roll back per item. It also puts the fundamentals this step depends on in place — the target group, the licence allocation — so a build is never blocked half-way by a missing dependency.
⏱ By hand: about 5 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
Before you start
- A build already worked through to the cockpit's Deploy plan screen - the 'USB / offline build' card only appears there.
- A firm decision on the mode: Standalone (fully offline, known local admin login) or Autopilot-prep (Entra-join + Intune-enrol) - they diverge on naming, admin and encryption.
- Confidence about the target machines' disk layout, so you know whether disk 0 really is the system disk before you touch Target disk.
- The profile language the machines should display (shown on the card), ideally with a Windows ISO already downloaded natively in it.
The steps
- In the cockpit, work through your build to the Deploy plan screen (the dry-run…
- Pick the mode. 'Standalone' = fully offline: no OOBE screens, the machine finishes…
- ...or pick 'Autopilot-prep' if the device should Entra-join and Intune-enrol: the…
- Tick 'Debloat - remove consumer apps' to remove Xbox, Solitaire, Bing news and…
- Tick 'Bake in the latest Windows update' if machines should boot pre-patched.…
- Set 'Target disk' - the disk Windows Setup WIPES and installs to on the target…
- Language: nothing to pick here - it follows your profile language (shown on the…
- There is no Save button - every change autosaves into the profile the moment you…
- Click 'Download plan (JSON)' in the footer. The downloaded client profile carries…
- Feed that profile to the USB builder - the double-click Decolla USB Builder or New-…
0 of 10 done
Step 1. In the cockpit, work through your build to the Deploy plan screen (the dry-run summary). Below the steps table sits the 'USB / offline build (provisioning stick)' card - these choices flow into the downloaded build plan and the stick builder obeys them.
Screenshot: Deploy plan screen scrolled to the 'USB / offline build' card (captured during a live customer build — coming to this page)
Why: The card lives on the Deploy plan screen because these choices ride inside the plan you download - set them anywhere else and they would have nothing to attach to.
Watch for: It sits below the steps table, so you have to scroll past the dry-run summary to reach it - easy to miss and leave on defaults.
Don’t: Do NOT go looking for it earlier in the build - the card appears only on this Deploy plan (dry-run) screen.
Step 2. Pick the mode. 'Standalone' = fully offline: no OOBE screens, the machine finishes ready with a known local admin login. Because an offline build has nowhere to escrow a BitLocker recovery key, automatic device encryption is blocked - enable BitLocker deliberately after enrolment.
Screenshot: 'Standalone' radio selected on the card (captured during a live customer build — coming to this page)
Why: Standalone finishes at a working desktop with a known local admin login and no cloud dependency - right when there is no Entra/Intune, or no network at first boot.
Watch for: An offline build has nowhere to escrow a BitLocker recovery key, so automatic device encryption is blocked - a Standalone machine boots unencrypted until you act.
Don’t: Do NOT assume the disk is protected - enable BitLocker deliberately after enrolment and keep the recovery key somewhere you can reach it.
If this step errors: Intune policies taking 8 hours? Check WNS first
Step 3. ...or pick 'Autopilot-prep' if the device should Entra-join and Intune-enrol: the OOBE sign-in screens stay visible on purpose, and naming, admin accounts and encryption are left to Autopilot/Intune.
Screenshot: 'Autopilot-prep' radio selected on the card (captured during a live customer build — coming to this page)
Why: The OOBE sign-in screens are left up on purpose so the device can Entra-join and Intune-enrol - that hand-off is the whole point of the mode.
Watch for: Naming, admin accounts and encryption are all deferred to Autopilot/Intune - if those profiles and policies are not ready, the device lands half-configured.
Don’t: Do NOT also set a device name or local admin here expecting them to stick - in this mode Intune owns them and the stick-side choices are ignored.
If this step errors: Autopilot dynamic group lag: apps missing during ESP
If this step errors: Autopilot ESP stuck at Account Setup: causes and fixes
Step 4. Tick 'Debloat - remove consumer apps' to remove Xbox, Solitaire, Bing news and similar from the image. The blocklist is guarded - the Store, security and business apps are protected - and the removals survive Windows feature updates.
Screenshot: 'Debloat - remove consumer apps' checkbox ticked (captured during a live customer build — coming to this page)
Why: Stripping Xbox, Solitaire, Bing news and the like out of the image means they never install in the first place - cleaner than uninstalling them later.
Watch for: The blocklist is guarded - the Store, security and business apps are protected, so this will not reach anything off that fixed list.
Don’t: Do NOT rely on this to remove one specific app you happen to dislike - it works from a fixed, guarded blocklist, not a free pick-list.
Step 5. Tick 'Bake in the latest Windows update' if machines should boot pre-patched. Honest trade-off: it downloads ~1 GB once and makes the FIRST build considerably longer (see the build-speed guide); later sticks reuse the cached result.
Screenshot: 'Bake in the latest Windows update' checkbox (captured during a live customer build — coming to this page)
Why: Baking the latest cumulative update into the image means machines boot already patched, instead of grinding through Windows Update at first logon.
Watch for: It downloads ~1 GB and makes the FIRST build considerably longer - the console will sit on servicing for a while; that is expected, not a hang.
Don’t: Do NOT tick this for a single throwaway test stick - the one-off first-build cost is not worth it for something you will discard.
On a schedule: Each new monthly cumulative update is a fresh servicing input - the first build after one lands is full-length again, even though later sticks reuse the cache.
Step 6. Set 'Target disk' - the disk Windows Setup WIPES and installs to on the target machine. 0 (the first disk) is right for almost everyone; only change it if a machine's data disk enumerates before its system disk.
Screenshot: Target disk number field with the ERASE warning note (captured during a live customer build — coming to this page)
Why: Target disk names the disk Windows Setup wipes and installs onto - it is how the builder knows where the OS goes on a machine with more than one drive.
Watch for: Only a machine whose data disk enumerates before its system disk needs anything other than 0 - and the number you set is the one that gets ERASED.
Don’t: Do NOT change this speculatively - move off 0 only once you have confirmed the enumeration order, or you will wipe the wrong drive.
Step 7. Language: nothing to pick here - it follows your profile language (shown on the card) and language packs slipstream automatically if the media needs them. Best result: download the Windows ISO natively in that language so nothing needs injecting.
Screenshot: The card's language note showing the profile language (captured during a live customer build — coming to this page)
Why: There is nothing to choose because the display language simply follows your profile - one source of truth, so the stick cannot drift from the cockpit.
Watch for: If the media does not already contain the profile language, packs are slipstreamed in automatically - it works, but it is extra work native-language media would not need.
Don’t: Do NOT grab whatever ISO is nearest and lean on slipstreaming - download the Windows ISO natively in the profile language so nothing needs injecting.
Step 8. There is no Save button - every change autosaves into the profile the moment you make it (watch the Autosaved status).
Screenshot: The Autosaved status after changing an option (captured during a live customer build — coming to this page)
Why: There is no Save button because every change is written into the profile the instant you make it - nothing to remember, nothing to lose.
Watch for: Watch the Autosaved status to confirm a change took - a mis-click is saved just as instantly as a deliberate one.
Step 9. Click 'Download plan (JSON)' in the footer. The downloaded client profile carries your usbBuild choices inside it.
Screenshot: 'Download plan (JSON)' button in the footer (captured during a live customer build — coming to this page)
Why: The downloaded client profile is what carries your usbBuild choices to the builder - the card's settings travel inside this file, not separately.
Watch for: Re-download the plan after any later change to the card - an older JSON left on disk still carries the old choices.
Don’t: Do NOT feed the builder a stale plan from an earlier session - the choices are frozen into the file at download time.
Step 10. Feed that profile to the USB builder - the double-click Decolla USB Builder or New-ProvisioningStick.ps1. The builder reads the mode, app-strip and target-disk choices straight from the profile; an explicit command-line option still wins if you need a one-off override.
Screenshot: The builder's console echoing 'Provisioning mode' + 'Debloat = ON (from the profile)' (captured during a live customer build — coming to this page)
Why: The builder reads mode, app-strip and target-disk straight from the profile, so the cockpit stays the single place you make these decisions.
Watch for: An explicit command-line option still wins over the profile - handy for a one-off, but a stray flag can silently override the card you set.
Don’t: Do NOT re-answer these choices at the builder unless you mean to override - a command-line option beats what is in the file.
Put these on a schedule
| Step | Recurring action to diarise |
|---|---|
| Step 5 | Each new monthly cumulative update is a fresh servicing input - the first build after one lands is full-length again, even though later sticks reuse the cache. |
If it goes wrong
The failures people actually hit on this process, each with the diagnosis and fix:
- Autopilot dynamic group lag: apps missing during ESP — Autopilot devices join dynamic groups minutes to hours late, so the ESP runs before apps are assigned. Why the ZTDId rule lags and how to fix it.
- Autopilot ESP stuck at Account Setup: causes and fixes — Why Autopilot's Enrollment Status Page hangs at Account Setup, how the Intune Management Extension tracks ESP state, and how to diagnose and unstick it.
- Intune policies taking 8 hours? Check WNS first — Intune delivers policy changes in minutes via WNS; the 8-hour sync is only a safety net. If WNS is blocked at the firewall, here's how to fix it.
‹ Before you build a provisioning USB - kit, space, time and downloadsBuild a provisioning USB with a double-click (Decolla USB Builder) ›
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access