The problem
Every computer that enters or leaves a business needs preparation: install Windows, find and install drivers, run updates, restart, run more updates, restart again, then do the final preparation for the employee or buyer. Each stage needs attention. Do it often enough and it stops being "setup" and starts being a part-time job.
Michael knew deployment inside out — he'd been imaging machines for years. What he didn't have was the orchestration around it: something that could carry a machine through the whole sequence, across restarts, without someone babysitting it.
What was built
Working with AI as an implementation partner, he built self-contained USB deployment packages — command and PowerShell scripts that turn the whole sequence into one start:
- Plug in and boot. The USB workflow starts from the stick — no typing commands, no hunting for files.
- It finds the Windows image. The workflow locates the WIM image on the media and gets the installation underway.
- Drivers come along. It copies the driver packages and their controller, so the machine gets the right drivers for its hardware instead of whatever Windows guesses.
- Updates survive restarts. Persistent controllers keep update passes running across multiple reboots — the machine picks up where it left off instead of starting over.
- It checks its work. Device Manager gets checked for problem devices before the machine is handed over.
- Ready for the next person. The machine returns to Windows initial setup (OOBE) — the out-of-box experience the next user expects.
Along the way, the project also produced supporting pieces: Sysprep and unattended-answer variants for different preparation paths, a Hyper-V workflow for building cleaner images, and model-specific driver caching so repeat work on the same laptop families stopped being repeated browsing and installing.
What broke #1: the zero-update stall. One build stopped dead because its update-state file was empty — and the recovery logic itself had compatibility problems. The diagnosis led to a PowerShell 5.1-compatible repair and a dedicated recovery package. The record shows the workflow physically recovered, resumed at pass two, and completed setup. It's one of the clearest wins in the whole project: existing work was rescued instead of restarted.
What broke #2: the success screen that lied. A deployment showed a clean success message — and then a later installer failed because a required PowerShell component was missing from the package. The code worked; the packaging didn't. The final repair was never confirmed, which is exactly why it's here: a tool isn't portable just because it runs in the development folder. Packaging is its own engineering task, and it needs its own acceptance test.
Where it honestly stands
This is a working system with real recoveries behind it — not a demo. But the honest boundaries matter:
- Complete end-to-end verification of every path is still open. Some reviewed scripts were statically inspected but their physical execution wasn't confirmed as tested.
- Early packages explicitly excluded hardware QA and BIOS/firmware updates — the broader goal shouldn't be mistaken for what every version implemented.
- It's not a universally verified, production-ready release. It's a real tool, used on real machines, with known limits.
The takeaway. AI didn't invent the deployment knowledge — that was already there. It supplied the implementation capacity: orchestration, saved state, repeat execution, and complete-file packaging. The failures above are what made the system trustworthy, because each one got diagnosed instead of shrugged at.