Unattended installation is the possibility to install an operating system without human interaction. Principally it is the same for Windows and Linux: An "answer file" which describes the configuration is provided as an input for the installer. These "answer files" provide any kind of setup options including how to partition disks and what packages/features to install.

Linux

To begin an unattended installation under Linux the system has to be booted with a special command which takes the “answer file”. The unattended file can be on a local hard drive or CD-ROM or in e remote location via NFS, HTTP, FTP. In case the file cannot be provide via the network, the boot media has to be prepared so that the file is available (i.e. create a bootable USB stick with the “answer file” on it. Generally it is pretty straight forward to create an “answer file” once you get yourself familiar with the syntax.

As there are a lot of different distribution and each of it may use it’s own installer, each distribution uses it’s own syntax, nomenclature and boot parameter. I compiled and overview of the most common distros below.

Fedora/CentOS/RedHat

RedHat and derivatives use Kickstart as their installer. At the boot prompt you have to specify the inst.ks= boot option and the location of the Kickstart file. Additional parameters like ip= may be required in case the Kickstart file is on a network location. More details to the boot parameters can be found here.

Additional information about how to create a Kickstart file and how to use it can be found on the projects pages:

• RedHat: Automatic Installation
• CentOS: Kickstart
• Fedora: Automatic Installation

In case you have a Red Hat Customer Portal account, you can use the Kickstart Configuration Tool

Debian, Ubuntu

Debian derivatives use the DebianInstaller or at least a modified version of it. In Debian’s term the unattended installation is referred as “preseeding” and supports three different methods:

• initrd
• network

The first one works with any installation method (CD/DVD Rom, netboot or hd-media) but requires the most preparation. Preseeding via local file location or network location can be used as alternative but requires access to the file. More information can be found here:

• Debian: Installation-Guide

SUSE/openSUSE

SUE and derivatives use Yast as their installer and AutoYaST for the unattended installation.

• OpenSuse: AutoYast

Windows

As I understand Windows does not support the injection of Answer files from a network location but the file Autounattend.xml has to be on the root of the boot media. Windows automatically searches for an answer file upon boot. Alternatively you can specify the answer file during installation by booting to the Windows Preinstallation Environment and running setup.exe with the /unattend: _filename_ option.

Answer files

In comparison to Linux, I find it very difficult to create answer files for Windows. Windows uses an XML-based format that contains setting definitions and values. The file is divided in different sections called “Configuration passes” and are used to specify different phases of the Windows Setup. More info to this can be found at MSDN:

• https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/how-configuration-passes-work

In the official MSDN page you can find more details on the different configuration parameters:

• https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/automate-windows-setup

To even make it more complex, you may end up having not only but 2 different configuration files: Unattend.xml and Autounattend.xml. According to the related TechNet site:

As a rule, only answer files named Unattend.xml are used. However, because some answer files include destructive actions such as disk partitioning, you must rename your Unattend.xml file to Autounattend.xml in the windowsPE and offlineServicing configuration passes.

Due to the more complex structure of answer files you shall use tools for that, the Windows System Image Manager (Windows SIM) - which is part of the Windows Assessment and Deployment Kit (Windows ADK). Once installed you can also have a look at some example provided with the Kit.

Windows System Image Manager (Windows SIM)

Windows® System Image Manager (Windows SIM) uses Windows image (.wim) files and catalog (.clg) files to display the available components and packages that can be added to an answer file (Unattend.xml). Windows images and catalog files contain configurable settings that you can modify after the component or package is added to an answer file.

Source: https://msdn.microsoft.com/en-us/windows/hardware/commercialize/customize/desktop/wsim/windows-image-files-and-catalog-files-overview

WIM files are compressed packages that contain a number of related files - more concretely it contains one or more compressed Windows images each of it with it’s own list of components, settings, and packages.

A catalog file is only used by Windows SIM and is a binary file that only includes the settings and packages of a Windows image.

More resources:

• Automate Windows Setup
• WSIM Technical Reference
• Windows Image Files and Catalogs
• Create WIMBoot Images