DecollaDecolla
Home › Setup guides › USB build speed: service the image once, every stick after is a fast copy
Setup guide · from scratch

USB build speed: service the image once, every stick after is a fast copy

The FIRST build with servicing options (language, updates, app-stripping) does real image surgery - expect roughly 35-90 minutes depending on options and hardware. The result is cached, so every later stick with the same inputs is a pure file copy, roughly 10-15 minutes. Cache and per-build logs stay on your machine only - licensed Windows never leaves it.

Decolla USB builder (image cache + build logs, on the build machine)
≈ 10 min
Windows — Autopilot & USB provisioning · step 5 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 build machine itself - the image cache and every build log live on it, under %LOCALAPPDATA%\Decolla, and never leave it.
  • The exact same Windows ISO file you built with last time - a different ISO file misses the cache and services in full again.
  • Your servicing choices settled before you begin (language, bake-in-updates, app-strip) - toggling any one of them is a fresh full-length build.
  • Spare disk space on the build machine for the cache, and the freedom to delete it later if you need the space back.
The steps
  1. Know what makes a first build slow: servicing (baking a language pack, Windows…
  2. Watch the elapsed clock: every progress line is stamped +hh:mm:ss since the build…
  3. When the first serviced build finishes it saves its work into the image cache -…
  4. Every later build with the SAME inputs (same ISO file, same language, same…
  5. Change ANY input - a different ISO, another language, toggling the updates or app-…
  6. Where the cache lives: %LOCALAPPDATA%\Decolla\ImageCache - one folder per input…
  7. Where the logs live: every build writes a full timestamped transcript to…
  8. Need the disk space back? The cache is safe to delete - the only cost is that the…
  9. Honest caveat: the 'bake in updates' download (~1 GB) happens once and is reused,…
0 of 9 done
Step 1. Know what makes a first build slow: servicing (baking a language pack, Windows updates, drivers or app-stripping INTO the image) mounts and rewrites the Windows install image. A language-only first build runs around 35-50 minutes; baking in updates adds a long recompression pass on top - budget up to ~90 minutes for a fully-loaded first build. Hardware matters.
Screenshot: The builder console mid-servicing ('Servicing a local copy of install.wim...') (captured during a live customer build — coming to this page)
Why: Servicing mounts and rewrites the Windows install image itself - that one-off surgery is the whole price of a native-language, pre-patched or app-stripped stick.
Watch for: Baking updates adds a long recompression pass on top of everything else - that is the stage that pushes a first build toward the ~90-minute end.
Don’t: Do NOT read 35-90 minutes as a fixed number - it is both servicing- and hardware-dependent, so a slow disk or CPU stretches it further.
If this step errors: Intune policies taking 8 hours? Check WNS first
Step 2. Watch the elapsed clock: every progress line is stamped +hh:mm:ss since the build started, so a long stage is visible at a glance - the build is not hung while stamped lines keep appearing.
Screenshot: Console lines showing the +hh:mm:ss elapsed prefix (captured during a live customer build — coming to this page)
Why: The elapsed stamp exists to tell a slow stage from a dead one - while fresh stamped lines keep appearing, the build is working, not frozen.
Watch for: That reassurance only holds while the stamps move - the same line sitting with no new stamp for a long stretch is the real hung signal.
Don’t: Do NOT cancel a build just because one stage is taking a while - a long stage is expected during servicing.
Step 3. When the first serviced build finishes it saves its work into the image cache - look for 'populating the image cache' and 'future builds with this ISO + language are COPY-ONLY' in the output.
Screenshot: The 'image cache populated' console line (captured during a live customer build — coming to this page)
Why: This line is the pay-off - the slow servicing you just waited through is banked, so the next stick with the same inputs skips all of it.
Watch for: The cache is only written when the serviced build actually FINISHES - kill it mid-servicing and nothing is banked, so the next build starts the surgery from scratch.
Step 4. Every later build with the SAME inputs (same ISO file, same language, same servicing choices) prints 'IMAGE CACHE HIT' and skips ALL the image surgery - the prepared image is simply copied onto the stick. Expect roughly 10-15 minutes end to end.
Screenshot: The 'IMAGE CACHE HIT' console line on a repeat build (captured during a live customer build — coming to this page)
Why: This is what the cache buys - one preparation feeds a whole batch, so a rollout of many sticks costs one servicing, not one each.
Watch for: 'Same inputs' is literal - the same ISO file, the same language, the same servicing choices; miss any one and you drop to a full service.
Step 5. Change ANY input - a different ISO, another language, toggling the updates or app-strip options - and it no longer matches the cache: that combination services in full once, then it too is cached.
Screenshot: A repeat build with changed options going the full-service route (captured during a live customer build — coming to this page)
Why: The cache keys on the entire input combination, so each new combination pays its own one-off servicing before it too joins the cache.
Watch for: Even a single toggle - app-strip on versus off - counts as a new combination and triggers a full-length service, not a copy.
Don’t: Do NOT vary the options stick-to-stick across one rollout - every variant is a fresh full build, so settle the choices before the batch.
Step 6. Where the cache lives: %LOCALAPPDATA%\Decolla\ImageCache - one folder per input combination, each with a small manifest.json naming the ISO and language it came from. LOCAL ONLY: the cached image IS licensed Windows, so Decolla never uploads it anywhere - it stays on your build machine.
Screenshot: File Explorer at %LOCALAPPDATA%\Decolla\ImageCache showing a cache folder + manifest.json (captured during a live customer build — coming to this page)
Why: Each folder's manifest.json names the ISO and language behind it - that is how you tell one cached combination from another before deleting anything.
Watch for: The cache is local to THIS build machine - run the builder on another PC and its cache is empty, so that machine pays the first-build servicing itself.
Don’t: Do NOT try to upload or share the cache - it IS licensed Windows, which is exactly why Decolla keeps it on your machine and off any server.
Step 7. Where the logs live: every build writes a full timestamped transcript to %LOCALAPPDATA%\Decolla\logs (usb-build-<date-time>.log). If a build fails or feels slow, open the newest log - the elapsed stamps show exactly where the time went.
Screenshot: The logs folder with usb-build-*.log files (captured during a live customer build — coming to this page)
Why: Every build leaves its own timestamped transcript, so a slow or failed build has a paper trail - the elapsed stamps inside point straight at the costly stage.
Watch for: Each build writes a NEW usb-build-<date-time>.log - sort by date-time and open the newest, or you will be reading a previous build's story.
Step 8. Need the disk space back? The cache is safe to delete - the only cost is that the next build services the image again from scratch.
Screenshot: Deleting an ImageCache folder (captured during a live customer build — coming to this page)
Why: The cache is purely a speed optimisation - nothing downstream depends on it, so reclaiming the space costs you time, never a working stick.
Watch for: Delete it and the very next build services in full again - so clear it after a rollout, not the night before one.
Step 9. Honest caveat: the 'bake in updates' download (~1 GB) happens once and is reused, but each month's NEW cumulative update is a new servicing input - the first build after a new update is a full-length one again.
Screenshot: The update-fetch step reporting a new month's cumulative update (captured during a live customer build — coming to this page)
Why: This is why a stick that copied in 15 minutes last month suddenly services in full - a new cumulative update is a fresh input the cache cannot match.
Watch for: The ~1 GB download is a one-off, but each month's new cumulative re-triggers the long build - that first slow build is by design, not a broken cache.
Don’t: Do NOT re-download the update hoping to dodge the wait - the long pass is the cumulative being baked into the image, not the download.
On a schedule: Each month's new cumulative update is a fresh servicing input - the first bake-in build after it is full-length again, then copy-only until the next month's update.

Put these on a schedule

StepRecurring action to diarise
Step 9Each month's new cumulative update is a fresh servicing input - the first bake-in build after it is full-length again, then copy-only until the next month's update.

If it goes wrong

The failures people actually hit on this process, each with the diagnosis and fix:

‹ Build a Decolla provisioning USB (Windows + build config + apps)How machines get their names (auto serial names + the first-logon rename pop-up) ›

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