The NetBoot service is most commonly used to provide a temporary operating system. In this article you will learn how to further accelerate the system
deployment process by providing a network-based operating system for
your client computers using the NetBoot service.
Since its inception, Mac OS X Server has included the ability to provide
full network-based operating systems to Mac clients using NetBoot. The
obvious advantage of NetBoot is that you can provide a unified operating
system to all your deployed Macs without having to use a physical
delivery mechanism such as optical media or external drives.
However,
although you could choose to always use an entirely network-based
operating system, this can be an inefficient use of your resources and
doesn’t provide optimal performance. After all, every Mac ships with
a relatively large and fast internal hard drive, which will nearly always
provide greater performance than even the most robust, and expensive,
network and NetBoot infrastructure.
The NetBoot service is most commonly used to provide a temporary operating system
that can facilitate your deployment workflow. Because the Apple installation and system
restore tools cannot replace a running system, the first step in most system deployment
scenarios is to start the destination Mac from another system volume so you can install
or restore the computer’s local system.
The NetBoot system fills this role spectacularly by
allowing you to configure a custom system, available from your network, that can perform
your entire deployment workflow entirely automated or with very little user interaction.
In this article you first will learn how the NetBoot technology works so that you can
properly configure this service in your environment. You will then learn how to set up
the NetBoot service from a Mac OS X Server and create a simple NetBoot system image.
Finally, you will learn how to create a workflow-generated NetBoot system image. This
new NetBoot feature, introduced with Mac OS X v10.5, allows you to create customized
and automated deployment systems.
About the NetBoot Service
The NetBoot service essentially allows you to boot a Mac computer via the network using
a system image hosted on another computer running Mac OS X Server. Multiple network
clients can use the system image simultaneously, allowing you to deliver an identical operating
system to all the computers you choose on your network, thus providing an ideal
platform for system deployment tasks.
NetBoot vs. NetInstall
To use the NetBoot service, you must create NetBoot system images that contain
Mac OS X or Mac OS X Server system software. A server running the NetBoot service can
host two primary types of system images:
- A standard NetBoot image provides a typical computing experience, as the Mac operates
nearly identically to a local-booted Mac OS X client or server. Although this is an
ideal configuration for systems that will remain booed from the NetBoot image, it is
not generally used for deployment purposes.
- A NetInstall image, on the other hand, starts up using a modified version of
Mac OS X that has been optimized for deployment purposes. A NetInstall image
allows you to perform a fresh installation of the operating system (much like when
you install from the Mac OS X installation media) or restore a configured system.
Further, Mac OS X v10.5 introduces workflow-generated NetInstall images that can
perform a variety of automated deployment tasks.
Although these two types of images differ in the way they are used and in the manner in
which they start up a client Mac, they are both still essentially a “NetBoot image.” The
fundamental architecture of a NetInstall image is no different from that of a standard
NetBoot image; a NetInstall image is simply a NetBoot image that has been specifically
created for deployment use. In fact, you can create a custom NetBoot image that performs
any type of administration or deployment task that you desire.
The NetBoot administration tools all recognize a distinction between NetBoot and
NetInstall images to make it easier for the user to identify each image’s primary purpose.
From a technical perspective, however, the only substantive difference between the two is
how they handle shadow files.
|