Unattended Installation and Deployment

What is it?

This roadmap plans hands-off installation for fleets and virtual machines: an answer.ini file that answers every installer question, an unattended mode that runs the installer without a screen, sysprep.exe to generalize a machine before imaging, an OEM customization folder, imagex.exe to capture and apply system images, a PXE and TFTP network boot server, VM provisioning scripts and an enterprise deployment guide. None of its eight sections has shipped, and it depends on an installer that does not exist yet either.

How does it work?

Today. There is no installer to automate. src/installer/ holds only a placeholder, and the release ISO built by build-iso.sh carries the boot partition only, so it boots the kernel but installs nothing (see Installer and ISO Build). Developers start virtual machines with the launchers in scripts/machines/, such as run-qemu-kvm.sh and run-vbox.sh, which boot a prebuilt disk image rather than provisioning a fresh install. The boot handoff already has a cmdline field in boot_info.h, which section 1 plans to use for an answer=<path> token.

Planned design.

1. Answer file. An INI file found from the kernel command line, the install media root or the Registry, covering disk, partitions, locale, user, network, OEM and packages.
2. Unattended mode. When an answer file is present, the installer skips every dialog, runs the same disk, format, copy and first-boot steps, and writes setup.log.
3. sysprep. sysprep.exe /generalize gives the machine a new identity (a 96-bit machine SID from the CSPRNG), clears host name, credentials and logs, and seals it for first-boot setup.
4. OEM and images. A $OEM$ folder adds drivers, Registry entries, branding and packages; imagex.exe captures a system into a .iim image with single-instance file storage and applies it back.
5. Network boot and VMs. A TFTP server with a DHCP proxy for PXE clients, and scripts that provision QEMU, Hyper-V and CI machines from an answer file.

flowchart LR
    A[answer.ini] --> U[unattended installer]
    U --> F[first boot]
    F --> S[sysprep /generalize]
    S --> C[imagex /capture]
    C --> P[PXE or VM deploy]

What are its interfaces?

How do I use it?

Nothing in this roadmap can be used yet. To boot the current image in a virtual machine, follow Boot Artifacts: Build, Verify, Write or the launcher table in the Machine Launcher and Debug Profile Matrix.

Who owns what?

The installer pipeline itself (disk selection, partitioning, formatting, file copy, boot entry) belongs to the Installer and ISO Build roadmap (10-platform-services/TODO-11); this file only drives it without a UI and must not re-specify it. First-boot setup belongs to the System Restore, Recovery and Observability roadmap's section 5. The machine matrix page names section 7 here as the owner of provisioning templates, and the release QA roadmap reuses a CI answer file from that section for its virtual machine certification runs.

What is not implemented yet?

• Answer File Format and INI Parser
• Unattended Install Mode, which needs the installer first
• sysprep.exe
• OEM Customization
• WIM and Image Capture
• Network Boot (PXE and TFTP Server)
• VM Provisioning Templates
• Enterprise Deployment Guide

How does it compare with Windows 11 and Linux?

Windows uses unattend.xml, sysprep, $OEM$ folders, WIM images managed with DISM and network deployment through Windows Deployment Services. Linux distributions use Kickstart, preseed or AutoYaST answer files, virt-sysprep or cloud-init to generalize, disk images or Clonezilla to capture, and dnsmasq with iPXE to boot over the network. The Impossible OS plan keeps the Windows shape with a simpler INI answer file and a native image format, and ships the provisioning scripts for QEMU and Hyper-V alongside it.

See also

• Unattended Installation and Deployment roadmap
• Installer and ISO Build
• Boot Artifacts: Build, Verify, Write
• Machine Launcher and Debug Profile Matrix