Setup guide · from scratch
Build a Decolla provisioning USB (Windows + build config + apps)
Make ONE bootable stick that installs Windows unattended, applies the build config, and installs the apps offline. You supply the customer's own LICENSED Windows ISO (we never redistribute Windows) and a plain 16 GB+ USB. BEST: download the ISO in your profile's LANGUAGE (Windows 11 ships in 38 languages - e.g. English UK) so the media natively matches: zero prompts, nothing to inject. Fallback: the builder can slipstream the language pack (~143 MB, auto-fetched) into the image - but NOT on 25H2 (26200) media, where offline language injection has a known Microsoft defect. The image can also be serviced offline: latest Windows update baked in, per-model drivers injected, consumer apps stripped (guarded blocklist). Pick the mode in the cockpit: Standalone (fully offline, known admin login) or Autopilot-prep (OOBE stays so the device Entra-joins and Intune-enrols). The build is silent + guarded; boot-test on a spare machine (it wipes the target's disk).
≈ 20 min
Windows — Autopilot & USB provisioning · step 4 of 12 · ≈ 20 min‹ PreviousNext ›
Do these first — this guide assumes you already have:
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 20 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
Before you start
- The customer's own LICENSED Windows ISO, downloaded in your profile's language (for the UK, the 'English International' en-GB ISO) - and note the full path to the .iso.
- A plain, unencrypted USB stick of 16 GB or more - not a hardware-encrypted one, and not a stick holding anything you care about (the whole stick is erased).
- The client-config .json for the profile you are building, to hand to New-ProvisioningStick.ps1.
- A spare target machine to boot-test on, plus its one-time boot-menu key (Dell F12 / HP F9 / Lenovo F12) - the build wipes disk 0.
The steps
- Get the customer's LICENSED Windows ISO for THEIR COUNTRY. Decolla never hosts…
- Get a PLAIN, unencrypted USB stick, 16 GB or larger. A hardware-encrypted stick…
- On a Windows machine, open an ELEVATED PowerShell: right-click Start > Terminal…
- Generate the payload from a client-config (or chosen profile) and DRY-RUN the…
- Read the dry-run: it mounts the ISO, reports the install-image size + whether the…
- When the plan looks right, BUILD it (this ERASES the USB): Build-…
- At the safety prompt it shows the disk it AUTO-DETECTED (number, name, size) and…
- It repartitions the USB (a <=30 GB FAT32 boot partition), copies the Windows media,…
- Boot the TARGET machine from the stick: power on, open the one-time boot menu (Dell…
- Windows installs UNATTENDED and in your profile's language. RECOMMENDED: use the…
- After install, Decolla auto-runs the payload (as SYSTEM, before first sign-in): it…
- It reboots to a configured, app-loaded machine (renamed to your device-prefix +…
- Optional image servicing (set in the cockpit's 'USB / offline build' card or via…
- Choose the OOBE mode per profile: STANDALONE (fully offline - no OOBE screens,…
0 of 14 done
Step 1. Get the customer's LICENSED Windows ISO for THEIR COUNTRY. Decolla never hosts Windows - the customer produces it via Microsoft's Media Creation Tool, their Volume Licensing, or the Microsoft download. For UK: use the 'English International' ISO (it contains en-GB display + the language features). For US: the 'English (United States)' ISO. Note the full path to the .iso.
Screenshot: Microsoft software-download page / the .iso in the Downloads folder (captured during a live customer build — coming to this page)
Why: The ISO is the raw material - download it in your profile's language and the media matches natively, with nothing to inject afterwards.
Watch for: For the UK, 'English International' carries the en-GB display; plain 'English' is US and can never show en-GB - pick the International one.
Don’t: Do NOT wait for Decolla to supply Windows - it never hosts it; the customer produces the ISO themselves via the Media Creation Tool, Volume Licensing or the Microsoft download.
Step 2. Get a PLAIN, unencrypted USB stick, 16 GB or larger. A hardware-encrypted stick (e.g. Kingston DataTraveler Locker+) will NOT work - it has a fixed CD-ROM partition. Insert it and note its drive letter (e.g. F:).
Screenshot: File Explorer showing the USB drive + its letter (captured during a live customer build — coming to this page)
Watch for: A hardware-encrypted stick (e.g. Kingston DataTraveler Locker+) presents a fixed CD-ROM partition and will NOT build - use a plain one.
Don’t: Do NOT use a stick holding files you care about - the ENTIRE stick is erased at build time.
Step 3. On a Windows machine, open an ELEVATED PowerShell: right-click Start > Terminal (Admin) / Windows PowerShell (Admin).
Screenshot: The Win+X menu with 'Terminal (Admin)' highlighted (captured during a live customer build — coming to this page)
Why: Formatting a USB and rewriting a Windows image both need administrator rights - a normal PowerShell window cannot do either.
Watch for: It must be an ELEVATED window (Terminal/Windows PowerShell Admin) - an ordinary one will fail partway, not at the start.
Step 4. Generate the payload from a client-config (or chosen profile) and DRY-RUN the build: New-ProvisioningStick.ps1 -ClientConfigPath <client-config.json> -PayloadDir $env:USERPROFILE\Desktop\Payload -IsoPath <the .iso> (add -SkipIngest for a config-only stick, or omit it to also ingest the apps from winget).
Screenshot: PowerShell showing the New-ProvisioningStick dry-run output (captured during a live customer build — coming to this page)
Why: The dry-run builds the payload and rehearses the entire build without touching the stick - the plan appears before anything is erased.
Watch for: -SkipIngest makes a config-only stick; omit it to also pull the apps from winget - decide which you want before you run.
Don’t: Do NOT jump straight to -Execute - the dry-run is where language and build-config problems surface with nothing erased yet.
If this step errors: ESP stuck on apps? Don't mix Win32 and MSI LOB in Intune
Step 5. Read the dry-run: it mounts the ISO, reports the install-image size + whether the WIM will be split for FAT32, validates the build-config, and WARNS if the media lacks your display language (a US ISO cannot show en-GB - swap to the English-International ISO if you need UK display).
Screenshot: Dry-run PLAN + 'media UI language(s)' line (captured during a live customer build — coming to this page)
Why: This is your go/no-go read: it validates the build-config and warns you before you commit, not after.
Watch for: A US ISO cannot show en-GB - if the 'media UI language(s)' line is missing yours, swap to the English-International ISO now, before you build.
Step 6. When the plan looks right, BUILD it (this ERASES the USB): Build-ProvisioningUSB.ps1 -IsoPath <the .iso> -PayloadDir $env:USERPROFILE\Desktop\Payload -UsbDrive <letter:> -Execute
Screenshot: The -Execute command (captured during a live customer build — coming to this page)
Don’t: Do NOT run -Execute until the dry-run plan read correctly - this is the command that actually erases the USB.
Step 7. At the safety prompt it shows the disk it AUTO-DETECTED (number, name, size) and what is currently on it. Check it is the right stick, then type exactly: ERASE <disk number> (e.g. 'ERASE 1'). Anything else aborts with nothing touched. Drive letters shuffle on every re-plug, so the builder finds the USB itself - never hard-code a letter.
Screenshot: The type-the-drive-letter confirm prompt (captured during a live customer build — coming to this page)
Why: The stop exists because drive letters shuffle on every re-plug - you confirm the physical disk the builder detected, not a letter that may have moved.
Watch for: Read back the disk number, name and size and check it is your stick - anything other than 'ERASE <number>' (e.g. 'ERASE 1') aborts with nothing touched.
Don’t: Do NOT hard-code a drive letter anywhere - after a re-plug it can point at a different device; let the builder find the USB itself.
Step 8. It repartitions the USB (a <=30 GB FAT32 boot partition), copies the Windows media, splits the install image into <4 GB parts if needed, lays down the auto-exec payload + autounattend.xml, and VERIFIES the payload landed. It finishes with 'USB READY'.
Screenshot: 'USB READY at <letter>:' line (captured during a live customer build — coming to this page)
Why: The boot partition must be FAT32 (capped at ~30 GB), so any install image over 4 GB is split into parts - that is how a large image still fits a FAT32 stick.
Don’t: Do NOT pull the stick before 'USB READY' - the closing step verifies the payload actually landed on it.
Step 9. Boot the TARGET machine from the stick: power on, open the one-time boot menu (Dell F12 / HP F9 or Esc / Lenovo F12 / generic Esc or F10) and pick the 'UEFI: <your USB>' entry. WARNING: this wipes the target machine's primary disk (disk 0).
Screenshot: Firmware boot menu with the UEFI USB entry (captured during a live customer build — coming to this page)
Watch for: Choose the entry that names your USB and begins 'UEFI:' - that is the one this build expects.
Don’t: Do NOT boot-test on a machine whose data matters - this wipes the target's primary disk (disk 0).
Step 10. Windows installs UNATTENDED and in your profile's language. RECOMMENDED: use the native-language ISO (downloaded per country/language) so the media matches the profile outright. If a language was slipstreamed instead, the builder verified the media's language manifest (sources\lang.ini) before shipping - note slipstreaming is NOT supported on 25H2 (26200) media (known Microsoft defect).
Screenshot: Windows Setup 'Installing Windows' progress (captured during a live customer build — coming to this page)
Why: Native-language media matches the profile outright - nothing is injected, so nothing can go wrong with the display language at install time.
Watch for: Offline language injection has a known Microsoft defect on 25H2 (26200) media - there, use a natively-downloaded language ISO, not a slipstreamed pack.
Step 11. After install, Decolla auto-runs the payload (as SYSTEM, before first sign-in): it applies the build config (device name, timezone, hardening, managed local admin) and installs the ingested apps offline from the stick. Logs land at C:\Decolla\provisioning.log and C:\Decolla\setupcomplete.log on the target.
Screenshot: First boot / the C:\Decolla logs (captured during a live customer build — coming to this page)
Why: Running as SYSTEM before first sign-in is what lets it rename, harden and install apps with no user present and no network.
Watch for: Apps install offline from the stick - whatever you ingested is all it has; there is no internet fallback at this stage. Check C:\Decolla\provisioning.log if anything is missing.
If this step errors: Autopilot dynamic group lag: apps missing during ESP
If this step errors: Intune Win32 install fails: SYSTEM vs user context
Step 12. It reboots to a configured, app-loaded machine (renamed to your device-prefix + serial). Optionally register the device into Autopilot/Intune afterwards to let cloud policy take over. Keep the stick's autounattend.xml private - it contains a temporary setup-account password.
Screenshot: The finished, renamed desktop (captured during a live customer build — coming to this page)
Don’t: Do NOT pass the built stick around freely - its autounattend.xml holds a temporary setup-account password; keep it private.
Step 13. Optional image servicing (set in the cockpit's 'USB / offline build' card or via -UpdateDir/-DriverDir/-DebloatListPath): bake in the latest Windows cumulative update (boots pre-patched), inject a per-model driver pack (capture one with New-DriverPack.ps1 on a known-good machine - storage/NIC drivers also go into Setup itself), and debloat (remove consumer apps: Xbox, Solitaire, Bing...) with the guarded blocklist - removals survive feature updates, and the Store/winget/security stack is hard-protected.
Screenshot: The cockpit Deploy-plan screen's 'USB / offline build' card with the mode radio + checkboxes. (captured during a live customer build — coming to this page)
Why: Servicing bakes updates, drivers and app-stripping INTO the image, so the machine boots already patched, driver-complete and clean - no post-install catch-up.
Watch for: Capture a per-model driver pack ON a known-good machine of that model with New-DriverPack.ps1 - and storage/NIC drivers must also go into Setup itself, or Windows may not see the disk.
On a schedule: 'The latest cumulative update' means this month's - a fresh one ships every month, so re-bake periodically to keep new sticks fully patched.
Step 14. Choose the OOBE mode per profile: STANDALONE (fully offline - no OOBE screens, machine ready with a known local admin login; automatic BitLocker is blocked because there is nowhere to escrow a recovery key offline) or AUTOPILOT-PREP (OOBE stays visible so the device Entra-joins and Autopilot/Intune enrols; naming, admin and encryption are left to Intune).
Screenshot: OOBE Entra sign-in screen on an autopilot-prep build vs the desktop on a standalone build. (captured during a live customer build — coming to this page)
Why: The mode decides who owns the finished device - you, with a known local admin and no cloud; or Entra/Intune, which then owns naming, admin and encryption.
Watch for: On Standalone, automatic BitLocker is blocked - an offline build has nowhere to escrow a recovery key, so turn encryption on deliberately after enrolment.
Put these on a schedule
| Step | Recurring action to diarise |
|---|---|
| Step 13 | 'The latest cumulative update' means this month's - a fresh one ships every month, so re-bake periodically to keep new sticks fully patched. |
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.
- Intune Win32 install fails: SYSTEM vs user context — Why a Win32 app installs manually but fails from Intune: SYSTEM vs user context, HKCU and %APPDATA% traps, and how to pre-test with PsExec -s.
- ESP stuck on apps? Don't mix Win32 and MSI LOB in Intune — Win32 and MSI LOB apps contend for msiexec during ESP, stalling Autopilot builds invisibly. Why it happens and how standardising on Win32 fixes it.
‹ Build a provisioning USB with a double-click (Decolla USB Builder)USB build speed: service the image once, every stick after is a fast copy ›
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