A boot image is a type of disk image. When it is transferred onto a boot device it allows the associated hardware to boot. This usually includes the operating system, utilities and diagnostics, as well as boot and data recovery information. It also includes those "applications" used organization-wide. A specialized image for a particular type of user or department is called typically a departmental boot image. Building such an image can take days or weeks, and involve complex decisions about licensing and permissions - including which passwords to store in the boot image and which to require users to type in - and requires experts in software integration to do. However, once built, the boot image can be simply copied onto devices, patched within reasonable limits, and remains disposable in case of any problems. This is possible because unlike other hard drive images, pure boot images contain no mission-critical data. By definition a pure boot image contains no data that cannot be reproduced from configurations or off-the-shelf executables. In particular end-user data is not part of a boot image, although some operating systems require that a copy of user preferences or configuration files be kept within the boot image itself, e.g. Microsoft Windowsregistry. Utilities like Norton Ghost keep a backup copy of the boot image, for quick re-imaging in the event of a problem, thus avoiding the need to diagnose a specific problem with a specific machine.
Some virtual machine infrastructure can directly import and export a boot image for direct installation to "bare metal", i.e. a disk. This is the standard technique for OEMs to install identical copies of an operating system on many identical machines: The boot image is created as a virtual machine and then exported, or created on one disk and then copied via a boot image control infrastructure that also makes virtual machine copies. The VMware vCenter Converter for instance lets users "convert physical machines to virtual machines - for free" as part of that company's suite of products to make images easier to back up and manage. Equivalents exist for Xen and other VM systems.
Goals
By keeping the boot image entirely separate and disposable, and mandating boot image control, organizations seek to keep their total cost of operations low. Often such organizations look at uptime as a service. One goal of boot image control is to minimize the number of boot images used by an organization to reduce support costs. It includes at least:
Specifying the machine hardware to minimize unneeded machine diversity and minimize the resultant number of boot images.
Upgrading new machine specifications at low additional cost ensures that they will remain useful long past their normal life. Extending the life of desktop machines will reduce the incursion of off-spec machines later in the life-cycle, improving standardization, reducing support costs, minimizing e-waste.
Organizing the network so that boot images can be efficiently supported, independent of data. Data must not be dependent on boot devices. Use networks to store data on secure servers.
Hardware acceptance testing on each new machine confirms that it is fit for use in a standardized boot image environment.
Boot image installation to ensure that only supportable standardized boot images are used.
Desktop system recovery tools and procedures for failed desktop units. These would use backup copies of a boot image created with utilities such as Norton Ghost. In a large organization with many compatible machines, rapid recovery by replacing with a backup boot image may only take a few minutes, with considerable cost savings.
Data backup and recovery procedures ensure data is stored in the right place so that it can be recovered promptly in crisis situations.
Installing services for the disabled with a single boot image in a manner that is ubiquitous and cost effective, meeting the needs of all staff regardless of disability, with available technology services.
Telework and secure off-site system access procedures.
Facilitating worker transfer by changing boots or authorizations instead of moving machines.
Using thin clients for off-spec machines to eliminate the need for special boot images.
Many organizations use thin clients for applications which require high security, involve unreliable users or repurpose older machines for continued use. A cascading strategy involves re-imaging older, off-spec machines to thin client boot images so that they may continue in use for some less demanding or more access-controlled applications.
