Setup guide · from scratch
Build a provisioning USB with a double-click (Decolla USB Builder)
The no-command-line way to build a provisioning stick: double-click the builder, pick your Windows ISO and client profile in two pop-ups, answer two yes/no questions, set the admin password, and type ERASE at the one deliberate safety stop. It ends with a USB READY pop-up showing the login for the machines it builds.
≈ 10 min
Windows — Autopilot & USB provisioning · step 3 of 12 · ≈ 10 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 10 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
Before you start
- The customer's licensed Windows ISO, downloaded in the language the machines should run - a US 'English' ISO cannot show UK display.
- The client profile .json from the cockpit - the same one you last built with, if you are repeating a client.
- A plain, unencrypted USB stick of 16 GB or more, holding nothing you care about - the whole stick is erased.
- Admin rights on the build PC (it asks to elevate) and a readable local admin password to set for the machines this stick builds.
The steps
- Get three things ready: the customer's LICENSED Windows ISO (download it in the…
- Double-click Decolla-USB-Builder.exe. Keep it in the Decolla toolchain folder it…
- Accept the Windows administrator prompt - the builder elevates itself (formatting a…
- First pop-up: pick the Windows ISO. It opens in your Downloads folder the first…
- Second pop-up: pick the client profile (the client-config .json from the cockpit).…
- Question 1: 'Bake in the latest Windows update so machines boot fully patched?' Yes…
- Question 2 (interactive/TEST builds only - a cockpit profile carries your choice…
- Set the local admin password for the machines this stick builds. A readable…
- Watch the console window that stays open - every line carries the elapsed time. The…
- Wait for the 'USB READY' pop-up - it repeats the login for the built machines…
- If the build reports a problem instead, the pop-up gives the exit code - the…
0 of 11 done
Step 1. Get three things ready: the customer's LICENSED Windows ISO (download it in the LANGUAGE the machines should use - Decolla never redistributes Windows), the client profile .json downloaded from the cockpit, and a PLAIN unencrypted USB stick of 16 GB or more, plugged in.
Screenshot: Downloads folder showing the .iso + client profile .json, USB inserted (captured during a live customer build — coming to this page)
Why: These three are the only inputs the builder cannot conjure for you - the two pop-ups ask for the ISO and the profile, and the stick is what gets written. Line them up first and the build runs without pausing to hunt.
Watch for: The ISO's language is fixed at download - a US 'English' ISO cannot show UK display, so fetch the one your machines should actually run.
Don’t: Do NOT bring an encrypted or hardware-locked stick - the instruction calls for a plain, unencrypted one the builder can repartition.
Step 2. Double-click Decolla-USB-Builder.exe. Keep it in the Decolla toolchain folder it shipped in - it calls the scripts that sit beside it.
Screenshot: The toolchain folder with Decolla-USB-Builder.exe highlighted (captured during a live customer build — coming to this page)
Why: The .exe is just the front door - the real work is the scripts sitting beside it in the toolchain folder, which is why it has to stay put.
Don’t: Do NOT copy the .exe off on its own to the Desktop - away from its folder it loses the scripts it drives and cannot build.
Step 3. Accept the Windows administrator prompt - the builder elevates itself (formatting a USB and servicing a Windows image need admin).
Screenshot: The UAC elevation prompt (captured during a live customer build — coming to this page)
Why: Formatting the stick and rewriting the Windows image are both admin-only jobs - without the elevation the build cannot touch either.
Don’t: Do NOT decline the prompt - a build without admin rights stops before it can format anything.
Step 4. First pop-up: pick the Windows ISO. It opens in your Downloads folder the first time and remembers the folder for next time.
Screenshot: The 'pick the Windows ISO' file dialog (captured during a live customer build — coming to this page)
Why: This is where the ISO you prepared goes in - it opens at Downloads the first time because that is usually where the ISO landed.
Watch for: On repeat builds it reopens the last folder you picked an ISO from, not always Downloads - glance at the path before you choose.
Step 5. Second pop-up: pick the client profile (the client-config .json from the cockpit). It remembers the last profile you used, so repeat builds are two clicks.
Screenshot: The 'pick the client profile' file dialog with the last profile pre-selected (captured during a live customer build — coming to this page)
Why: The profile carries your cockpit choices into the build - it is precisely why the debloat question two steps on is skipped on a real profile.
Watch for: It pre-selects the last profile you used - a gift for the same client, a trap for a different one, so check the filename before you click.
Step 6. Question 1: 'Bake in the latest Windows update so machines boot fully patched?' Yes downloads about 1 GB ONCE - later builds reuse it and the image cache. If the download fails, the build carries on WITHOUT baked-in updates (Windows Update patches later) and tells you so.
Screenshot: The bake-in-updates Yes/No question box (captured during a live customer build — coming to this page)
Why: Baking updates means the machine is patched the moment it boots rather than after its first sync - worth it where first-boot networking is uncertain.
Watch for: A 'Yes' here is what makes the FIRST build long - the ~1 GB download and servicing pass happen now, and only once.
Don’t: Do NOT read a failed update download as a failed build - it carries on unpatched, tells you so, and Windows Update fills the gap later.
On a schedule: Windows ships a fresh cumulative update roughly monthly - once a newer one exists 'the latest' has moved on, so the first build after it downloads and bakes again instead of reusing the cache.
Step 7. Question 2 (interactive/TEST builds only - a cockpit profile carries your choice and the builder does not ask): 'Debloat - remove consumer apps (Xbox, Solitaire, Bing news...)?' Safe to say Yes - the Store, security and business apps are protected.
Screenshot: The strip-consumer-apps Yes/No question box (captured during a live customer build — coming to this page)
Why: This question only shows on a test/interactive build - a real cockpit profile already carries your debloat choice, so on production builds you will not see it.
Watch for: If you expected this prompt and it never came, that is correct - it means you picked a real profile earlier, which answered it for you.
Don’t: Do NOT hesitate over 'Yes' fearing it strips something vital - the Store, security and business apps are protected from the blocklist.
If this step errors: ESP stuck on apps? Don't mix Win32 and MSI LOB in Intune
Step 8. Set the local admin password for the machines this stick builds. A readable suggestion is pre-filled - you will type this at their login screen later, so keep it readable.
Screenshot: The admin password box with the pre-filled suggestion (redact it) (captured during a live customer build — coming to this page)
Why: This one password is the login for every machine the stick builds - the same credential lands on all of them, so it is the one you must not lose.
Don’t: Do NOT paste in something cryptic you cannot read back - you type this by hand at each machine's login screen, where there is no copy-paste.
Step 9. Watch the console window that stays open - every line carries the elapsed time. The build is silent apart from ONE deliberate stop: it shows the USB it auto-detected (disk number, name, size, and what is currently on it). Check it is the right stick, then type exactly: ERASE <disk number>. Anything else aborts with nothing touched.
Screenshot: The console at the typed-ERASE confirmation showing the detected disk (captured during a live customer build — coming to this page)
Why: This is the single safety gate in an otherwise hands-off build - it shows the disk it found and what is on it so you can catch a wrong-stick mistake before a byte is written.
Watch for: The elapsed stamp on every line is your 'still working' signal - a long quiet stage is the image being serviced, not a hang.
Don’t: Do NOT type the ERASE line on autopilot - it wipes the whole disk you name, so match its number, name and size to your stick first. Anything mistyped simply aborts, untouched.
If this step errors: Autopilot dynamic group lag: apps missing during ESP
Step 10. Wait for the 'USB READY' pop-up - it repeats the login for the built machines (Admin / your password). Boot the target machine from the stick via its one-time boot menu (Dell F12 / HP F9 or Esc / Lenovo F12).
Screenshot: The USB READY pop-up with the login line (redact the password) (captured during a live customer build — coming to this page)
Why: The pop-up repeats the Admin login on purpose - your last chance to note it before you walk to the target machine, where you will need it.
Watch for: The boot key differs by brand and is a one-time menu, not BIOS - tap it as the machine powers on (Dell F12, HP F9 or Esc, Lenovo F12).
Don’t: Do NOT drop into full BIOS setup for this - it is the one-time boot menu you want, a different key on each brand.
Step 11. If the build reports a problem instead, the pop-up gives the exit code - the console plus the log in %LOCALAPPDATA%\Decolla\logs show exactly where it stopped.
Screenshot: The problem pop-up + the logs folder (captured during a live customer build — coming to this page)
Why: A failed build is not a dead end - the pop-up's exit code and the timestamped log pin the exact stage it stopped at.
Watch for: The newest file in %LOCALAPPDATA%\Decolla\logs is the one to open - the real reason sits there, not on the pop-up.
Don’t: Do NOT wipe the stick and start over before reading it - you will only hit the same wall.
Put these on a schedule
| Step | Recurring action to diarise |
|---|---|
| Step 6 | Windows ships a fresh cumulative update roughly monthly - once a newer one exists 'the latest' has moved on, so the first build after it downloads and bakes again instead of reusing 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.
- 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.
‹ Choose the USB / offline build options in the cockpit (Deploy plan)Build a Decolla provisioning USB (Windows + build config + apps) ›
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