This chapter will show you how to select a system imaging technique that meets your deployment needs, integrate advanced Mac OS X managed preferences with your system image, create a cloned system image using Disk Utility, create basic network disk images using System Image Utility, and build a modular NetRestore image using System Image Utility.

For many deployments, the best solution is a unified system disk image, which involves creating an ideal system, saving it
to a disk image, and then deploying that system to all your computers. A unified system image requires a significant time
investment up front, but it saves a great deal of time in the long run. Computers with identical configurations are much easier
to manage; the fewer the differences between your deployed systems, the more uniform their performance and the less time spent
diagnosing problems, updating software, and reconfiguring hardware.

A unified system image also greatly accelerates the deployment process for any deployment larger than a dozen computers. Once
you have fully configured, tested, and created a custom system image on one computer, it can take as little as five minutes
to copy it to another machine. Compare this with the time needed to deploy the system individually on every computer, and
it’s easy to see the benefit of a deployable system disk image. In this chapter you will learn two general methods for creating
deployable system disk images: cloning from a model system and building a modular system.

Understanding System Image Creation

Before starting the process of creating a system image, you must consider your deployment requirements: what software and
configuration settings will be part of your system image? Consider your users, your systems, and the limitations of identical-system
deployment on multiple computers. You also need to consider which of the two image creation methodologies will best suit your
needs and abilities. The choices you make while planning your system image will affect every computer on which this system
is deployed.

Defining System Image Requirements

When identifying all the specific items and configuration settings that you want to include in your system image, you must
take into consideration the requirements of your users, the technical requirements of your systems, and the limitations of
deploying an identical system on multiple computers.

User Requirements

Your primary focus when developing system image requirements should be on maximizing system usability, for both users and
administrators. In some cases your target audience or usage policies may require tighter system control. This is often the
case when users are inexperienced or cannot be trusted to manage any part of their systems. In this scenario you would limit
application access and lock down as many system configuration settings as possible. You would also want to make things easy
for the user by preconfiguring any system setting you can. In scenarios where you will be performing a significant amount
of client management, you should incorporate directory services–based managed preferences.

More Info

Implementing managed preferences is detailed later in the “Integrating with Managed Preferences” section of this chapter.

In professional or creative environments, you may not need to be as restrictive in the application or settings, but you should
still make sure to prepare the system based on the users’ needs; for instance, install third-party applications and peripheral
drivers for inclusion with your system image.

No matter the level of your users, your system image should be as fully configured as possible, with both Apple and third-party
software installed and updated, any necessary support files such as third-party drivers and fonts installed, and any systemwide
configuration settings implemented. Note, though, that many settings are not well suited to deployment via a unified system
image—more on this topic later in this section.

More Info

Common system customizations often included with system images are covered in the “Customizing System Configuration” section later in this chapter.

Computer-Specific System Requirements

Before you create your system image, you must determine which version of Mac OS X you intend to use. A major administrative
advantage of using Mac OS X v10.6 and Mac OS X Server v10.6 is that they include all the hardware drivers necessary to work
with any Mac that meets the minimum system requirements, allowing you to build a single system image that can work on any
Mac.

Although creating a unified system image for computers that support Mac OS X v10.6 is simple, creating a system image for
brand-new Macs can present a significant problem. In many cases, because the release of new Mac computers is not in sync with
the release of the retail version of Mac OS X, a custom intermediate version of Mac OS X is created just to support the new
hardware. However, new Macs cannot run versions of Mac OS X released prior to their introduction—that is, the oldest version
of Mac OS X supported by a new Mac computer is the version that it ships with from the factory.

Thus, a previously created system image will not work on new Mac computers, and you will have to create a new system image
based on the version of Mac OS X that shipped with the new Macs. Further, these custom intermediate versions of Mac OS X may
technically work with older Mac computers, but they are not officially supported by Apple to do so, presenting a problem when
you are trying to build a single unified system image.

More Info

You can find out which version of the Mac OS shipped with your Mac in Knowledge Base article HT1159, “Mac OS X versions (builds)
included with Intel-based Macs.”

Fortunately, every general Mac OS X version update includes support for all Mac computers introduced prior to the update.
For example, if you were to acquire new Macs that were introduced this week, the next general update of Mac OS X will include
support for those new Macs and will support older hardware as well. Therefore, if you can wait to build your system image until you can
base it on the next general update for Mac OS X, you can create a single system image for all your Macs. If you can’t wait
that long, you will need to create a separate system image just for your new Macs.

It’s important to note that custom intermediate versions of Mac OS X for new computers do not use different version numbers
from the general releases. They do, however, have different build numbers, which can be identified by clicking once on the
version number from the About This Mac window.

Software Update Requirements

You should strive to build your system image using the latest versions of your selected software. To do this, you’ll need
to collect and keep track of all the necessary software update installers that you’ll apply when building your system image.

NOTE

Although in most cases it’s best to deploy the latest versions of software, only with thorough testing can you verify this.

First you need to determine and acquire the latest version updates for Apple software. Apple’s downloads website, www.apple.com/downloads/, lists all the latest updates and can be searched and browsed so you can locate and then download specific Apple software
updates. However, it may not seem obvious which Apple updates are needed; for this reason you can open Software Update from
the Apple menu.

Apple Software Update will compare your Mac’s current installed software with the latest versions available from Apple. Obviously,
you should run this on one of your test deployment systems to verify exactly which updates are necessary. The Mac OS X v10.6
version of Software Update no longer allows you to download updates without installing them. Thus, if you want to acquire
the updates for later installation or deployment, you will have to do so from Apple’s downloads website.

NOTE

Avoid using “delta” or single-point Mac OS X updates for your system images. You’ll get better results and spend less time
installing by using the Mac OS X “combo” updates. These updates not only contain all previous delta updates, they also contain
all previous system security updates.

You should also verify that you are using the latest versions of third-party applications and drivers. Many third-party products
feature a built-in automatic update system that will check online for updates. However, few of these third-party update systems
will allow you to download the individual update installer so that you can later use it to build your system image. Again,
in this case, visit the software developer’s website to download the individual update installers.

Limitations of a Unified System Image

You should include as many configured settings as possible with your system image so you don’t have to spend time setting
these items on each individual computer. However, there are many settings that you should not, or cannot, deploy with the
same configuration to every computer.

For example, in most cases, user-specific settings should not be included with your system image. Computer-specific settings
also should not be configured on the system image. For instance, a unique IP address and network name needs to be set for
every Mac. Both user- and computer-specific settings are best handled using dedicated client management tools and techniques.

In deploying a Mac OS X Server system image, your primary goal will be to strike a balance between what you can safely configure
as part of the generic server system image and what settings you must leave for after deployment.

More Info

Chapter 6, “Postimaging Deployment Considerations,” deals specifically with managing settings that are best handled after
deploying your system image.

Choosing a System Image Methodology

When using the tools built into Mac OS X to create a deployable system disk image, you have a choice between two different
methodologies: cloned system images and modular system images.

With a cloned system image, you first set up a model computer that is configured with all the software and settings you intend to deploy. Then you create
a duplicate copy of the system volume saved to a disk image that has been specially prepared for deployment.

The modular system image methodology, a newer method, requires a bit more work up front, but it has several advantages over the older method and is
the Apple-recommended best practice. With this method you build a fresh system by installing a series of installation packages
to a sparse disk image. The installations include the full Mac OS X system, any software updates, any additional Apple software,
any third-party software, and any custom installation packages that you have created to set up your system image. This sparse
image is then converted to a disk image that has been prepared for deployment.

Cloned System Image Pros and Cons

Con—Requires that the model computer be purged of any unnecessary or troublesome files

Con—Prone to issues if model not properly “cleaned”

Con—Prone to more issues when deploying to different models

Con—Increased workload when creating multiple system images

Con—Increased workload when it’s time to update system images

Con—New system images are never consistent with prior images

Con—Difficult to document and audit system image configurations

Con—Increased workload to test system image modifications

Modular System Image Pros and Cons

Pro—System images are clean because they have never been booted.

Pro—System images have no model-specific settings.

Pro—Apple updates won’t interfere with your customizations because they are always applied before your customizations.

Pro—Your workload is lighter when creating multiple system images that require unique software and configurations.

Pro—Your workload is decreased when it’s time to update system images.

Pro—Multiple and updated system images are perfectly consistent for similar items every single time.

Pro—All configurations are easily documented and easily audited.

Pro—Testing of updates and image modifications are simpler.

Pro—System image creation process is automated.

Pro—It’s easy to integrate modular system images with system maintenance workflows and third-party deployment tools.

Con—Workflow is more difficult for novice administrators.

Con—You must create custom installation packages for some third-party items and any configuration settings.

Con—You will spend more time creating an initial system image.

The cloned system image methodology requires less effort up front, and you can get your first image set up quickly. However,
in the long run you’ll have to spend much more time fixing bugs, updating software, and adding modifications than with a modular
system image. The modular system image methodology requires more initial effort to properly configure your first system image,
but maintaining your systems will be much easier because you’ll be able to build new modular images with additional items
and updated software.