Installing a server OS, and the methods that scale

Why this matters

Installing an operating system by clicking through a setup wizard is fine for one server. It is slow, inconsistent and undocumented for ten, and impossible for a hundred. Every organisation that runs more than a handful of servers installs them by a method that repeats the same result every time.

This lesson covers the choice of what to install, the ways of getting the installer onto the hardware, the methods that remove the human from the process, and the work that turns a freshly installed machine into a server ready for production.

The lesson

Full desktop against core or minimal installs, and the attack surface each leaves

Server operating systems can be installed with or without a graphical desktop.

Windows Server offers two installation options. Desktop Experience includes the full graphical interface. Server Core has no desktop at all; the server is managed from the command line, PowerShell, or remotely with tools such as Windows Admin Center and the Remote Server Administration Tools. In current versions the choice is made at installation and cannot be changed afterwards without reinstalling.

Linux servers are normally installed as a minimal installation with no desktop environment, and managed over SSH.

The case for the minimal option is the attack surface: every installed component is something that can contain a vulnerability. A Server Core or minimal install has less code, so it needs fewer patches and fewer restarts, uses less memory and disk, and gives an attacker less to work with. The cost is that administrators must be comfortable managing it without a desktop. For most server roles, the minimal install is the better default; the full desktop is justified when an application genuinely requires it.

Installing from media, USB, virtual media and a PXE network boot

The installer has to reach the server somehow.

• Physical media, an installation DVD, still works on servers that have a drive, but few do now.
• A bootable USB drive is the usual choice when someone is standing at the server.
• Virtual media, from the out-of-band management lesson, attaches an installation ISO over the network through the management controller, so an administrator can install a server without being in the room.
• A PXE (Preboot Execution Environment) network boot installs with no media at all, and is the basis of large-scale deployment.

PXE works in stages. The server's network adapter firmware requests an address from DHCP; the DHCP response also tells it where to find a boot server and which boot file to load. The server downloads a small boot program, usually by TFTP, which then loads the installer. Deployment systems such as Windows Deployment Services, Microsoft's configuration managers, and Linux tools such as Foreman or Cobbler are built on this.

Whatever the method, some groundwork comes first: confirm the hardware is on the operating system's compatibility list, configure the RAID arrays, and have the storage controller driver ready if the installer does not include it, otherwise setup may find no disks to install on.

Unattended installs: answer files and kickstart

An unattended installation supplies every answer the installer would normally ask a person for, from a file prepared in advance: disk layout, edition, language and region, administrator password, network settings and more.

• Windows uses an answer file, typically named autounattend.xml, which can be built with the Windows System Image Manager.
• Red Hat and its derivatives use a kickstart file.
• Debian uses preseed, and Ubuntu Server uses its autoinstall format.

Combined with PXE, an answer file means a new server can be racked, powered on and left to install itself. The larger benefit is consistency. Every server built from the same file is configured the same way, and the file itself documents exactly how they were built. When it lives in version control alongside the organisation's scripts, a change to the standard build is a reviewed change to a file rather than a note someone may forget.

Images and clones, and generalising a machine before it is copied

A faster approach for identical servers is to build one reference machine exactly as required, capture it as an image, and deploy that image to every new server. Virtual machine templates work the same way, and a well-kept image, often called a golden image, is also updated and patched on a schedule so new servers do not start out months behind.

A copied machine carries the identity of the original, which causes trouble on a network. Windows machines have unique identifiers, and clones that share them can conflict in a domain and in management tools. So a Windows reference machine must be generalised with Sysprep before it is captured; Sysprep strips the machine-specific identity so each deployed copy creates its own on first boot.

Linux needs the same care in a different form. Before templating, clear the machine ID, the SSH host keys and the hostname, so every clone generates its own. Clones that share SSH host keys cannot be told apart by the clients connecting to them, which defeats the point of host keys.

The first hour after install: updates, name, time and licensing

A freshly installed server is not ready for production. The first hour turns it into one:

• Install updates. The installation media is out of date the day it is written, and a new server should not join the network missing months of security fixes.
• Set the hostname according to the organisation's naming convention, before anything else records the default name.
• Configure the network: a static address or a DHCP reservation, the right DNS servers and gateway. The next lesson covers this in detail.
• Set and synchronise the time with a reliable NTP source. This matters more than it looks: logs are useless for investigation if their clocks disagree, and Kerberos authentication in Active Directory fails when a machine's clock is more than five minutes out.
• Licence and activate the operating system. Windows Server must be activated, whether individually or through the organisation's volume activation service, and evaluation copies expire. Commercial Linux distributions need their subscriptions registered.
• Join the domain, if the server belongs to one, and apply the security baseline.
• Install the agents for monitoring, backup and security, so the server is watched and protected from its first day in service.
• Document the build: what was installed, the versions and the settings.