OSX ML TT Deployment

This document is intended for Apple internal and channel audiences, and is for training purposes only.
OS X Mountain Lion
Technical Training:
Deployment
Apple Inc.
2013 Apple Inc. All rights reserved.
Apple, the Apple logo, AirPort, Bonjour,
FileVault, Finder, FireWire, Mac, MacBook,
MacBook Air, Mac OS, Safari, and Spotlight are
trademarks of Apple Inc., registered in the U.S.
and other countries. Apple Remote Desktop is
a trademark of Apple Inc. Mac App Store is a
service mark of Apple Inc.
The absence of an Apple product or service
name or logo from this page does not
constitute a waiver of Apples trademark or
other intellectual property rights concerning
that name or logo.
Intel is a trademark of Intel Corp. in the U.S.
and other countries.
IOS is a trademark or registered trademark of
Cisco in the U.S. and other countries and is
used under license.
Java is a registered trademark of Oracle and/or
its affiliates.
UNIX is a registered trademark of The Open
Group in the U.S. and other countries.
OS X version 10.8 is an Open Brand UNIX 03
Registered Product.
Other company and product names
mentioned herein are trademarks of their
respective companies. Mention of third-party
products is for informational purposes only
and constitutes neither an endorsement nor a
recommendation. Apple assumes no
responsibility with regard to the performance
or use of these products. All understandings,
agreements, or warranties, if any, take place
directly between the vendors and the
prospective users. Every effort has been made
to ensure that the information in this
document is accurate. Apple is not responsible
for printing or clerical errors.
06-16-2013
This document is intended for Apple internal and channel audiences, and is for training purposes only.
Table of Contents
........................................................................... Introduction 1
............................................................................................... About this series 1
................................................. 1 Creating Installer Packages 2
............................................................................... About installer packages 2
............................................................................. Signing installer packages 3
..................................................................... Obtaining a Developer ID certificate 3
.............................................. Creating packages from the command line 5
........................... Using receipts to track installer package installations 6
............................. Creating installer packages with third-party utilities 7
...................................................... 2 Creating System Images 8
.................................................................................... Hands-off deployment 8
..................... Creating images with Disk Utility and the command line 8
............................................................................... Preparing a system for imaging 9
.............................................................. Removing unneeded LKDC information 9
......................................................................................... Removing .DS_Store files 11
.................................................................................. Removing other system files 11
......................................... Customizing the default User Template directory 12
................................................................................................. Self-removing scripts 12
......................................................................... Creating images with Disk Utility 14
.............................................. Creating a disk image from the command line 16
........................................... Creating images with System Image Utility 17
............................................................................................. NetInstall from Installer 17
......................................................................................... NetRestore from Installer 19
..................................................... Using NetRestore from a prepared volume 21
............................................................ Automations with System Image Utility 23
.................................................. Additional System Image Utility preferences 31
..................................................................................... Additional resources 31
........................................................................ 3 Deployment 32
.......................................................................................... Local deployment 32
................... Creating a bootable disk or volume from a NetInstall image 32
..................................................................................... Deploying with Disk Utility 34
............................................................................ Deploying with NetInstall 34
.......................................................................................... NetInstall considerations 35
.............................................................................. Configuring a NetInstall server 35
...................................................................................... Custom source NetRestore 38
Setting clients to boot from a network disk image using the bless
................................................................................................................... command 39
................................................................................. Using NetBoot DHCP helpers 39
.................................................................................................................. bootpd relay 40
................................................... Restoring with Apple Software Restore 41
............................................................... Unicast Apple Software Restore (ASR) 41
2013 Apple Inc. Apple confidentialfor internal and channel use only iii
........................................................ Multicast Apple Software Restore (mASR) 42
...................................................................... Minimal-touch deployments 44
............................................................ Third-party deployment solutions 45
.......................................... 4 Caching Software Downloads 46
................................................................................................. Requirements 46
................................................................... Managing the Caching service 47
...................... Comparing the Caching and Software Update services 49
.................................................................................................... Client configuration 49
.......................................................................................... Download management 49
........................................................................................................... Software cached 49
......................................................................................... When software is cached 50
2013 Apple Inc. Apple confidentialfor internal and channel use only iv
Introduction
This guide is designed to introduce the basic concepts and techniques for deploying
OS X Mountain Lion in commercial and government organizations. It provides an introduction to
the following topics:
Installation packages
Imaging
Deployment
Caching service
Note that this guide is not comprehensive. Each section provides just enough information to get
you started. After youve become comfortable with the steps provided, you can refer to the
Additional resources sections of the guide for more in depth reading.
About this series
This guide is one of a four-part series designed to help IT professionals who are evaluating and
deploying OS X Mountain Lion on Mac computers in commercial and government organizations.
The other guides in the series are:
OS X Technical Training: Integration
OS X Technical Training: Management
OS X Technical Training: Security
OS X Mountain Lion Technical Training: Deployment
2013 Apple Inc. Apple confidentialfor internal and channel use only 1
1 Creating Installer Packages
A common method for installing software is drag and drop, where the application and associated
files are copied from the distribution media to the target volume. Although this method is easy
and works well when the application files only need to be copied to one or two places in the file
system, its not the most flexible method of installing software on multiple computers.
In OS X, installer packages are a common means of delivering new software, software updates, or
collections of documents. Installer packages are, in effect, documents for the Installer application.
Each package includes the files to be installed, the target locations for each file, and the
information to be presented during the installation process.
An additional advantage to creating installer packages is that you can create customized images
with System Image Utility. In a later chapter, youll learn how you can create an image with
preinstalled software by combining the OS X Installer with installer packages.
About installer packages
Imaging often includes packaging software for distribution. OS X has a number of tools for
creating installation packages and distributing those packages.
Most application installers place files on an operating system. An installer package is a file, or a
bundle of files, with a .pkg extension. The package bundle contains an archive of files to install,
referred to as the payload. It also can contain scripts that perform specified actions (that can run
before or after the archive of files is placed into the destination that theyre bound for) and
information about how the operating system should interpret the installer. A package can also
include licensing documents and other information, as needed.
An installer package
Installer packages are very useful for installing and managing software. For example, application
developers often use packages to build installers for their software. Apple uses packages to
provide system or application upgrades using Software Update. Administrators often use
packages to deploy small changes to client systems, such as binding to a directory service.
An installer metapackage
A metapackage, which has a .mpkg file extension, is a set of packages thats distributed in one
structure. The metapackage typically provides a list of checkboxes that can be used to choose
which packages or components of a larger installation framework are installed.
To install a package, double-click its icon in the Finder. The Installer application opens and guides
you through the necessary steps of the installation. This approach is similar to any application or
installer that provides a dialog box interface in modern computing. You can also install packages
silently through the command line, with Apple Remote Desktop, or use third-party patch
management software solutions.
Many application installers come bundled as standard Apple packages. If an application installer
is already a package, you may not need to build your own packages. Vendors who distribute
packages often have a process for preparing a package for mass deployment (such as
instructions on embedding license keys). Contacting the vendor can often save valuable time,
minimize the amount of user input required to install a package, and avoid unintended
consequences.
Creating installers for different operating systems is a similar process. Therefore, if a member of
your team is already trained in creating installers for Microsoft Windows (that is, .msi or .mst
installers) or Linux, it should be easy for that person to quickly grasp the concepts needed to
build packages in OS X.
Signing installer packages
OS X Mountain Lion users have the option of turning on a security feature called Gatekeeper.
With Gatekeeper, users can choose to install software only from the Mac App Store and identified
developers. If your installer package isnt signed with a Developer ID certificate issued by Apple, it
wont open on systems that have Gatekeeper enabled.
To avoid this situation, you need to sign installer packages using a Developer ID certificate and
thoroughly test the end-user experience using a Gatekeeper-enabled system before you
distribute your installer package.
Obtaining a Developer ID certificate
Only Mac Developer Program members are eligible to request Developer ID certificates from
Apple and sign applications or installer packages using them.
When you enroll in the Mac Developer Program, you become the primary contact for Apple and
are asked to sign legal agreements. Regardless whether you enroll as an individual or company,
youre the team agent and responsible for creating Developer ID certificates. If you enroll as a
company, you can add individuals to your team, but only the team agent has permission to
create Developer ID certificates. Developer ID certificates are owned by the team and not an
individual.
To enroll in the Mac Developer Program, go to Apple Developer Program Enrollment at https://
developer.apple.com/programs/start/standard/ where youll be guided through the process of
enrolling. If you havent registered as an Apple Developer yet, you can do so when enrolling in
the Mac Developer Program. When youre prompted to select a program, select the Mac
Developer Program.
To create a Developer ID certificate:
1. In a web browser, go to https://developer.apple.com/account.
If you havent signed in already, youll need to sign in using a Mac Developer account.
2. Under Mac Apps, click Certificates.
This will display any Mac Developer certificates that have been delivered or are in the
process of being fulfilled.
3. Click the Add (+) button to add a Mac certificate.
4. Download and install the Worldwide Developer Relations Certificate Authority and
Developer ID Certificate Authority certificates located near the bottom of the page.
5. In the Distribution section, select Developer ID and click Continue.
6. Select Developer ID Installer and click Continue.
7. In the Finder, open Keychain Access (/Applications/Utilities).
8. Choose Keychain Access > Certificate Assistant > Request a Certificate From a Certificate
Authority.
9. In the Certificate Assistant window, enter the following information:
In the User Email Address field, enter your email address.

In the Common Name field, create a name for your private key (for example, Chris Doe Dev
Key).
Select the Saved to disk option.
10. Click Continue to complete the Certificate Signing Request (CSR) generating process.
11. Specify where to save the CSR and click Save.
12. Click Done to close the Certificate Assistant.
13. Back in your web browser, in the About Creating a Certificate Signing Request (CSR) page,
click Continue.
14. Click Choose File, locate the CSR you just created, and click Choose.
15. Click Generate.
Youll be notified when the certificate has been created.
16. Click Continue.
The Certificate Assistant lists your certificate name with its expiration date.
17. Select your Developer ID Installer certificate.
18. The entry expands to display the certificate details and buttons.
19. Click Download.
20. In the Finder, double-click the downloaded certificate (.cer) file to install it in Keychain.
Creating packages from the command line
Creating packages from the command line can become complex very quickly.
To create an installer package from the command line:
pkgbuild --identifier pkg-identifier --version pkg-version --sign
identity --component component-path package-output-path
The pkg-identifier is a unique identifier for the package, pkg-version is the version
number for the package, identity is the full name of your Developer ID Installer certificate,
component-path is the path to the file to be packaged, and package-output-path is the
destination of the package.
The pkg-identifier option specifies a unique identifier for this package. The name must be
unique, so use your domain name in reverse dot notationalso known as a Java-style package
name. For example, com.apple is for packages developed by Apple or com.pretendco for
packages developed by PretendCo. Follow this with a name for the package (for example,
com.pretendco.TrafficManager identifies a package named Traffic Manager developed by
PretendCo).
Use pkg-version to specify a version for the package. Packages with the same identifier are
compared using this version to determine if the package is an upgrade or downgrade. If you
dont specify a version, a default of zero is assumed, but this may prevent proper upgrade/
downgrade checking. While testing your packages, be sure to increase the version number each
time you test a build, otherwise the Installer will appear to function correctly, but your files wont
be installed.
For example, the following creates a package of the Traffic Manager application:
pkgbuild --identifier com.pretendco.TrafficManager --version 1
--sign "Developer ID Installer: Pretendco" --component
"/Applications/Traffic Manager"
"~/Desktop/Traffic Manager Installer.pkg"
Note: It may seem trivial to create an installer package for a single file when the user can simply
drag a file into its proper location. However, when youre creating images with System Image
Utility and you want to add a file during the image creation process, youll need to use an
installer package to do so.
To sign an existing installer package:
If you have an existing installer package, use the productsign command to sign the package.
1. Open Terminal.
2. At the prompt, enter:
productsign --sign identity packagepath signedpackagepath
The identity is the full name of your Developer ID Installer certificate, packagepath is the
path to the package to be signed, and signedpackagepath is the path where the signed
package will be created.
For example, the following signs a package on the desktop with the Pretendco certificate:
productsign --sign "Developer ID Installer: Pretendco"
"~/Desktop/Company Forms.pkg" "~/Desktop/Company Forms_signed.pkg"
Using receipts to track installer package installations
During installation, Installer creates a receipt that contains the packages resources and a list of
the files, permissions on the file with the file size, and a checksum. Note that the receipt doesnt
actually contain the files that are installed, so receipt files are small.
For a list of the receipts for all installed packages in the receipts database, enter the following
command in Terminal:
pkgutil --pkgs
The following illustration shows the tail end of the output from the pkgutil --pkgs
command:
You can see the last entry is for the Traffic Manager installer package created earlier in this guide.
Note that the entry lists the package ID and not the packages filename.
When Installer is installing a package, it uses the existence of a receipt to determine whether to
install or upgrade. If a receipt exists, and version information exists in the software being
installed, Installer can skip some files that dont need to be upgraded. Installer also executes the
preupgrade and postupgrade scripts instead of the preinstall and postinstall scripts that run
during an install.
The pkgutil command can also list the files installed by a specific package. For example, enter
the following to list the files installed by the TrafficManager.pkg:
pkgutil --files com.pretendco.pkg.TrafficManager
Remember that an application is actually a bundle of files, so the file list can be surprisingly
lengthy.
Creating installer packages with third-party utilities
A number of third-party products have compelling features for creating installer packages. These
include:
Composer, from JAMF softwarehttp://www.jamfsoftware.com
With Composer, you can inspect a computer and create a package of each application thats
been installed on that system, thus offering a smooth transition from monolithic imaging
environments to package-based imaging environments.
InstallEase, from Absolute Softwarehttp://www.absolute.com
With InstallEase, a simple snapshot-based package generation tool for OS X, you can create
installer packages with minimal effort.
Iceberg and Packageshttp://s.sudre.free.fr/Software.html
Iceberg and Packages (under the BSD license), provide additional interface options for the
implementation of pre- and post-flight scripts, as well as features specifically used for
metapackage management.
2 Creating System Images
The first step in deploying OS X to one or more Mac computers is to create a system image. This
chapter covers the basics of creating images that can be deployed using the deployment
methods covered in the next chapter.
There are two primary methods for creating deployable system images: duplicating a
preconfigured Mac, or building an image by combining an existing disk image or installer and
installer packages.
A disk image (.dmg file) is a file that looks and acts like a mountable disk or volume. In this
chapter, youll learn how to use Disk Utility and hdiutil to create deployable boot images.
A network boot image (.nbi folder), also referred to as a network disk image, is an image that starts
up the client computer long enough to install software from the image. The client can then start
up from its own hard disk. The primary tool for creating installation images is System Image
Utility.
Boot images and installation images are disk images. The main difference is that a .dmg file is a
proper disk image and a .nbi folder is a bootable network volume (which contains a .dmg disk
image file).
Hands-off deployment
Before you start creating system images, ask yourself the following: Do I really need to create,
manage, and deploy system images and software?
The traditional method for deploying computers is to create system images and copy the images
to every computer in the organization. While this creates consistency in system configuration, it
places a burden on an IT organization to maintain a set of images, making sure they contain the
latest OS updates and application versions.
Now, with the easy-to-use configuration assistant and the Mac App Store, you may find that a
hands-off approach to deploying new computers might be appropriate. Instead of deploying an
OS image, you can deliver new computers directly to the users and allow them to perform the
initial configuration by downloading the software that they needeither from an internal
website or the Mac App Store. Users are familiar with this approach since its what they already
do with their home computers.
For more information, refer to the Apple technical white paper Supporting Mac Users: The Self-
Support Model available at http://training.apple.com/pdf/wp_self_support.pdf.
Creating images with Disk Utility and the command line
Creating Apple Software Restore (ASR) images based on a prepared volume is the standard
practice for OS X Mountain Lion. Almost all imaging tools (System Image Utility, Disk Utility, and
hdiutil) support this method, but ASR has several advantages.
Creating a deployment image from a configured Mac is quick and easy. Its also a process well-
practiced and understood by the Mac system administrator community.
However, there are a few issues that may complicate imaging from prepared volumes for
ongoing deployments. One such issue is that when creating an image from a preconfigured Mac,
you must take care to remove or reset key system features and files. Failure to do so may cause
issues with networking and authentication on the deployed computers. System Image Utility
performs these tasks automatically, but if you image with other tools they may require manual
intervention per image. In addition, monolithic images created in this way are difficult to
maintain, update, and audit.
This chapter includes sections that cover the proper creation of ASR images from a configured
Mac.
Preparing a system for imaging
A computer used for imaging should be perfect. It should contain all the files you want to
deploy, but no system history nor any machine-specific data. To build an image like this youll
want to remove machine-specific data and any information specific to the user account used
during setup.
A number of tasks need to be automated after an image has been deployed. Rebuilding the
Local Key Distribution Center (LKDC), binding to a directory service, and renaming a computer
are all tasks that need to happen within the image or following the deployment of a computer.
These tasks are easily automated but require a bit of scripting, command-line savvy, or both. The
following sections set the stage for automating some of these tasks.
ByHost settings are set based on the MAC address or UUID of the computer. This makes it difficult
to place certain items in an image and have them deployed to local workstations. ByHost settings
can be installed by using a postimaging script or by using LoginHooks so that theyre run at first
login. Examples of ByHost settings include Bluetooth and Screensaver.
Removing unneeded LKDC information
Every Mac computer runs as a Kerberos LKDC to protect peer-to-peer communications.
Additionally, when administrators access information on servers while testing images or
downloading software, Kerberos information can be saved to the system and this information
gets imaged to all clients created from the base image. Therefore, when youre imaging, clear out
appropriate Kerberos informationsuch as the LKDC database, keys, Ticket Granting Tickets
(TGTs), and service principalsunless youre using System Image Utility, which performs these
tasks for you.
Managing Kerberos is an important aspect to many Mac environments. Apple has provided Ticket
Viewer, a graphical interface to access and manage Kerberos data on a system. You can access
Ticket Viewer through Keychain Access, or directly in /System/Library/CoreServices/.
Note: You only need to remove LKDC information if you use Disk Utility or hdiutil to create an
image of an OS X computer. If you use System Image Utility, these steps are performed
automatically as part of the NetRestore image creation process.
To review and delete Kerberos tickets:
1. Open Keychain Access (located in /Applications/Utilities).
2. To view the Kerberos keys and principals, choose Keychain Access > Ticket Viewer.
This opens the Ticket Viewer application, where administrators can view tickets for users and
cached passwords, renew tickets, obtain more information on a ticket, and remove existing
tickets. When imaging a system, use the Ticket Viewer application to delete all existing
tickets that are listed (if any).
To list Kerberos tickets and principals from the command line use the klist command. To
delete those tickets use the kdestroy command.
The local KDC always has a SHA1 hash that should be unique to each client system. To
function, the local KDC requires a certificate that is generated for
com.apple.kerberos.kdc on all Mac computers during the setup of the local KDC.
Having multiple systems with the same name and same key can cause problems, therefore,
delete the information prior to imaging or as part of system imaging.
3. To delete the local KDC certificates, open Keychain Access (located in
/Applications/Utilities), then click the System keychain in the Keychains list.
4. Find and delete the com.apple.kerberos.kdc certificate. Also, delete the public key and
private key generated from that certificate.
To delete the local KDC certificates from the command line, open Terminal from
/Applications/Utilities and run the following command as root (using sudo), which simply
removes the local KDC database:
sudo rm -r /var/db/krb5kdc
As a postflight task/script during imaging, rebuild the local KDC to encrypt peer-to-peer traffic. To
do this, run the configureLocalKDC Perl script located in /usr/libexec. The
configureLocalKDC script rebuilds the local KDC database, including the
com.apple.kerberos.kdc certificate, private key, and public key that make up the required
SHA1 hash.
Removing .DS_Store files
Remove the .DS_Store files from a system prior to imaging, because this information can be
localized and therefore cause problems on target clients. Removing all .DS_Store files from a
Mac while its booted in target disk mode is one way to do this (if done on a booted system,
some files will be regenerated).
Note: You only need to do this if you use Disk Utility or hdiutil to create an image of an OS X
computer. If you use System Image Utility, these steps are performed automatically as part of the
NetRestore image creation process.
To delete all .DS_Store files from a system:
1. Open Terminal (located in /Applications/Utilities).
sudo find . -name *.DS_Store -type f -exec rm {} \;
The above command uses find to execute an rm (or remove) of all files whose name matches
*.DS_Store (identified using the -type f portion of the command). To see a listing of the
files that are removed, place a -print in the command.
Removing other system files
There are many other cache files to remove to mitigate problems on images. Although a number
of third-party solutions remove cache files, when youre imaging from a prepared volume, you
should perform these tasks to make sure that stale data is not pushed out onto client computers.
Removing these files can also help reduce the size of your overall image. For example, the /var/
vm/sleepimage file is typically 2 to 4GB in size and will be recreated on clients at startup time.
The following are some commands for removing unneeded items from your image (assuming
the name of the hard drive is Macintosh HD, and that the client is booted to target disk mode
and attached to the client where the commands are being run):
sudo rm /Volumes/Macintosh\ HD/var/db/BootCache.playlist
sudo rm /Volumes/Macintosh\ HD/var/db/volinfo.database
sudo rm /Volumes/Macintosh\ HD/System/Library/Extensions.kextcache
sudo rm /Volumes/Macintosh\ HD/System/Library/Extensions.mkext
sudo rm -rf /Volumes/Macintosh\ HD/var/vm/*
sudo rm /Volumes/Macintosh\ HD/.Trashes*
Note: Also consider removing the .DS_Store folder from the root of the volume.
Customizing the default User Template directory
New user accounts are created with a set of predefined characteristics. These include folder
hierarchy, preference files, a predefined background, startup scripts that automatically set up
applications, and other items. You can customize these with scripts for each setting, or you can
base them on a customized default user template.
OS X Mountain Lion provides a default user template that you can customize so that each newly
created account on a local system is populated with information placed into the default User
Template directory. This means that even after imaging, all new local user accounts are created
with the default settings configured as part of the user template.
To customize the default User Template directory:
1. Set up an account with the required settings and options.
3. Use the cd command to change your working directory to the /System/Library/User
Template/Non_localized folder using the following command:
cd /System/Library/User\ Template/Non_localized
The default files and folders that make up new home directories are here. Add a file or
directory to any of these folders and its automatically copied to each new users home folder
on the system.
You could set up an entire account for this purpose and use it to create the user template.
4. First, back up the original directory tree to protect against unwanted corruption using the cp
command as follows:
cp -R /System/Library/User\ Template/Non_localized
/System/Library/User\ Template/English.lproj.old
5. After youve backed up the original directory tree, copy a new directory to the old location. If
youre using a local account called Default as your template user, for example, use cp again,
as follows:
cp -R /Users/Default /System/Library/User\ Template/Non_localized
When a new user is created, all data prepopulated from the Default User Template is in the
new users home directory.
Note: Files stored in the Non_localized folder will be copied into all new home directories.
The User Template directory also contains directories with the .lproj extension for localized
versions of files. For example, if you wanted to include a file just for Japanese home
directories, you would store it in the Japanese.lproj directory.
Self-removing scripts
Many of the scripts used with mass deployment need to be removed from a system following
mass deployment. Typically, this is because the scripts might contain a directory services
administrative password, local administrative password, or environment-specific information. A
shell script can remove itself, which means you can put trusted information into the script
without it being exposed unnecessarily. However, always keep in mind that the script may not
complete, and you should limit the scope of the trusted information added into these scripts
where possible.
When working with scripts, a variety of methods can invoke them and perform tasks. This section
explains how to take a script and remove it after it has run and how to wait for an event to occur
prior to starting the script, which provides more flexibility with scripting.
The easiest way to remove a script when its finished running is to add a line to the end of the
script to delete the file. To do this, use the srm command, which is a secure version of the rm
command. To delete a script called selfdestruct.sh, at the end of the file called
selfdestruct.sh, use srm along with the $0 option afterward, as follows:
/usr/bin/srm $0 selfdestruct.sh
Note: Use absolute file paths in scripts when possible.
After the script is finished running the rest of the tasks that come before the line with srm, it will
remove the script. If you have exposure to Linux-based operating systems, you might be tempted
to place files that you want to run automatically into the /etc/rc.local (which is no longer
supported as of OS X Leopard) or rc.common directories, but never use these locations unless
you have a very specific need to do so.
Another way to achieve the same result, but with more flexibility, is to use launchd. By creating
a LaunchDaemon or a LaunchAgent, youll be able to pass more information into the script and
trust that no matter which user logs into the host, the required script is run. After the contents of
the script have been completed, remove both the script that is invoked by your launchd item
and the launchd item itself.
To create a launchd item that starts an application on startup, use the following keys in a
property list file (.plist) that is placed in the /System/Library/LaunchAgents or /System/Library/
LaunchDaemons directories. This file should be named with a convention that makes sense for
your organization (for example, com.pretendco.bindscript).
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" \
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>BIND</string>
<key>ProgramArguments</key>
<array>
<string>/script_dir/bind.sh</string>
</array>
<key>OnDemand</key>
<false/>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
In the above keys, you can set the string for Label to whatever you want your launchd item to
be referred to at a later date. The ProgramArguments array will launch a series of scripts, although
here it uses a single shell script located in the /script_dir/bind.sh directory. The RunAtLoad key is
set to true, which tells the script to launch when the system starts up. At the end of the bind.sh
script is a line to srm the launchd item and then reboot the host, which self-destructs the script.
To manually launch the script for testing, use the launchctl command. To start the script that
has been built throughout this example, use the following command:
launchctl load -w /System/Library/LaunchDaemons/com.pretendco.bindscript
To stop the script if there are problems with it, substitute load with unload in the above
command. If you use an if/then statement in a shell script, you can unload a launchd item prior
to deleting it, ensuring it is not still in use prior to a reboot.
Creating images with Disk Utility
An image is a representation of a computer and its related information including the kernel, file
systems, libraries, and programs at a given point in time. A disk image is a representation of the
file system itself, typically captured while offline to create a complete image of the system. For
the purposes of this document, an image is either:
A single .dmg file that stores a monolithic representation of a Mac that can be copied in full to
other Mac computers, or a creation of packages that make up a modular representation of
that .dmg file
A Mac that can be copied in an object-oriented fashion to other Mac computers
You can deploy images directly (for example, through target disk mode or from one disk to
another) or over a network (for example, using NetInstall, NetRestore, or a third-party product).
This section is not about how to deploy, but simply about creating an image itself. Creating an
image of a hard drive and copying that image to another hard drive is a basic operation included
in every copy of OS X.
Many options exist for imaging Mac computers. This section describes how to use Disk Utility
found in /Applications/Utilities to create an image of a hard drive.
To create an image of a system with Disk Utility:
1. Build the perfect system image. First, install the operating system and required software, and
configure the various settings.
2. Restart the system in target disk mode (by holding down the T key during the startup
process).
3. Connect the image source computer to an image creation computer and make sure that the
hard drive mounts.
4. Select the volume, and choose File > Get Info (or press Command-I).
5. Make sure that the Ignore ownership on this volume checkbox is not selected.
6. Open Disk Utility (located in /Applications/Utilities/).
7. Choose File > New > Disk Image from Folder.
The Select Folder to Image dialog selects the volume from which to create the image.
8. Select the name of the hard drive of the prepared client (which should be booted into target
disk mode).
9. Click the Image button.
10. In the New Image from Folder window, enter a name for the image. In this example, its
named Pretendco Image.
11. Use the Where menu to define where to create the image on the system.
12. From the Encryption menu, choose none.
13. Click Save to create the image.
Wait for the image to complete (the time required depends on the size of the image and
media speeds for both the source and destination).
14. After the image is complete, unmount and remove the hard drive you used as the source of
the image.
15. In Disk Utility, choose Images > Scan Image for Restore.
16. Select the previously created image.
Creating a disk image from the command line
You can use Apple Software Restore (ASR) to create images from a disk. This example shows how
to create an image from the command line, which gives you maximum granularity in terms of
control and information about whats going on behind the scenes.
To use Apple Software Restore to create a disk image:
You can use the hdiutil command to burn, create, expand, and verify disk images. This section
uses the hdiutil command to create the image .dmg file by invoking the create verb.
1. Mount a drive called MACOSX with an image of a clean OS X Mountain Lion installation onto
your computer and create an image of it. Name the image MtLionImage and put it in the
Desktop folder.
The following command shows a simple way to create the .dmg file:
hdiutil create -srcfolder /Volumes/MACOSX ~/Desktop/MtLionImage.dmg
2. Use the following command to have the asr utility scan the image:
asr imagescan --source ~/Desktop/MtLionImage.dmg
In this example, asr is used with the imagescan verb to calculate the checksums of the
contents of the image file and store them in the image. These checksums are used to make
sure that restores occur properly. The -imagescan verb also reorders files so that the image
can be deployed in a multicast fashion. You can use --filechecksum and --nostream
options with the imagescan verb to calculate checksums on a per-file basis and bypass
reordering of the files, respectively.
Note: By default, Disk Utility creates an image up to 256GB. To create a larger image, set
some defaults before using Disk Utility or hdiutil. You can set these with the following
command:
defaults write com.apple.frameworks.diskimages \
hfsplus-stretch-parameters -dict \
hfsplus-stretch-threshold 524288 \
hfsplus-stretch-allocation-block-size 4096 \
hfsplus-stretch-allocation-file-size 16777216
Using the above command, you can create an image on a volume up to 512GB.
Creating images with System Image Utility
Traditionally, Disk Utility was used to create OS X system images. While Disk Utility is still capable
of creating images, you must properly prepare the systems prior to imaging. In addition, Disk
Utility doesnt include the OS X Restore partition as part of the imaging process.
System Image Utility is used to create network boot images. Its included with all OS X Mountain
Lion computers at /System/Library/CoreServices. Unlike Disk Utility, System Image Utility takes
care of image preparation while it creates the image. In addition, System Image Utility
automatically creates the OS X Restore partition.
With System Image Utility, you can create and customize three types of network disk images:
NetBootBoots a client computer to an operating system located on a server. This is done in
a completely diskless boot environment or by leveraging a disk in the client to cache the
operating system.
NetInstallCreates a customized operating system installer that runs over a network. You may
define customizations to the installation process with easy-to-use Automator actions that
perform tasks before or after the OS X installation process. In an environment where
customizations have been used, NetInstall users are presented with the same user interface as
if they were using the OS X installer on the local drive. Examples of customizations include
repartitioning hard drives, using predefined operating system installation choices, binding
systems to directory services, renaming client systems, and installing additional software
packages.
NetRestoreImages clients using a prebuilt image (referred to in this guide as a prepared
disk) with block copy Apple Software Restore (ASR). You have several options to create
NetRestore sets including imaging an existing OS X computer, creating an image
programmatically with a custom package set, and allowing for the arbitrary sourcing of ASR
images (that is, choosing an image located on a web server, Apple file server, or using multicast
ASR). With NetRestore, a single boot image can be prepopulated with predefined choices, or
clients can browse for multicast ASR streams using Apples Bonjour browsing technology.
Although System Image Utility was designed to create images that are restored over the network
(as youll see in the Deployment chapter), network disk images can be used to restore systems
locally as well.
NetInstall from Installer
In OS X Server, NetInstall deploys a bare-metal installation to client systems. NetInstall takes the
logic and options built into the OS X Mountain Lion installer and moves it into a vehicle that can
be used on networked client computers.
To create a NetInstall image with System Image Utility:
1. Download OS X Mountain Lion from the Mac App Store (do not install OS X or restart upon
completion).
An application named Install OS X Mountain Lion will be placed in the
/Applications directory.
2. If the OS X Mountain Lion installer opens, quit it.
3. Open System Image Utility (located in /System/Library/CoreServices).
4. From the Sources list on the left, select Install OS X Mountain Lion.
5. Select NetInstall Image. This tells the image, when NetBoot loads it, to install an operating
system.
6. Click Continue.
7. Enter a name and description for the image.
8. For images hosted by multiple NetBoot servers, select the Image will be served from more
than one server checkbox.
9. Click Create.
10. Read the Software Licensing Agreement, and click Agree.
11. Enter a filename and choose a location for the image.
If you need to browse for a location, click the disclosure button to the right of the Save As
field.
12. Click Save.
13. Enter an administrative password for the computer thats generating the image.
14. Once the process is complete, move the image into the /Library/NetBoot/NetBootSP0
directory on a computer hosting the NetInstall service. The newly created NetInstall image is
now available in the NetInstall section within the Server app.
Note: The next chapter covers configuring the NetInstall service in OS X Server.
NetRestore from Installer
With NetRestore, a tool included in OS X Server, administrators can create operating system
images and automations for those images, and then deploy them via block-copy ASR. As with
NetBoot and NetInstall, use System Image Utility to create an image, and then share it for system
imaging.
This section covers how to use System Image Utility and an OS X Mountain Lion installer to
create a bare-metal image for use with NetRestore.
To create a NetRestore image with System Image Utility:
1. Download OS X Mountain Lion from the Mac App Store (do not install OS X or restart upon
completion).
An application named Install OS X Mountain Lion will be placed in the
/Applications directory.
2. If the OS X Mountain Lion installer opens, quit it.
Because the Install OS X Mountain Lion installer is in the Applications directory, the initial
System Image Utility window provides the option to create a network disk image.
4. Select NetRestore Image and click Continue.
6. For images hosted by multiple NetRestore servers, select the Image will be served from
more than one server checkbox.
7. Enter the names and password that will be used to create the administrator account on the
system once it has been restored:
Name: Enter the full administrator account name.

Short Name: Enter the short name for the administrator account.
Password and Verify: Enter and verify the password for the administrator account.
8. Click Create.
9. Read the Software License Agreement, and click Agree.
If you need to browse for a location, click the disclosure triangle to the right of the Save As
field.
11. Click Save.
12. Enter an administrative password for the computer thats generating the image.
directory on a computer hosting the NetInstall service. The newly created network boot
image is now available in the NetInstall section within the Server app.
Using NetRestore from a prepared volume
NetRestore creates operating system images and automations for those images, and deploys
them using block-copy ASR. As with NetBoot and NetInstall, System Image Utility creates an
image and shares it to facilitate system imaging.
In OS X Server, NetRestore pushes out a fully populated image, which can include applications,
settings, and tools. Because the image is populated with all of this, the monolithic image first
needs to be created from a volume thats been prepared, or installed, with all of those assets. In
this type of environment, the prepared volume is typically one of the only steps in your imaging
scheme (often followed by binding to a directory service).
This section explains how to use System Image Utility to create a NetRestore image on a volume
thats been prepared with all of the OS X Mountain Lion settings and applications (referred to as
the prepared volume). In this example, the prepared volume is called Client. After creating the
image, you can still add automations as post-flight tasks within System Image Utility.
To create a NetRestore image from a prepared volume with System Image Utility:
1. Start the computer with the prepared volume in target disk mode (hold down the T key until
the FireWire or Thunderbolt icon appears).
2. Use a FireWire or Thunderbolt cable to connect the computer with the prepared volume to
the computer with Mountain Lion installed.
Because you have a prepared boot volume inserted, the initial System Image Utility window
provides the option to create a network disk image.
4. For the purpose of this example, select NetRestore Image.
5. Click Continue.
7. For images hosted by multiple NetRestore servers, select the Image will be served from
more than one server checkbox.
8. Click Create.
If you need to browse for a location, click the disclosure triangle to the right of the Save As
field.
11. Click Save.
12. Enter an administrative password for the host being used to generate the image.
directory on a computer hosting the NetInstall service. The newly created network boot
image is now available in the NetInstall section within the Server app.
Automations with System Image Utility
Administrators often need to perform additional tasks, or automations, after the initial image is
built. If the imaging environment is modular (package based), most of the logic is built into post-
flight tasks. If the image is comprised of a single .dmg and the environment is huge, you can run
a postflight package to bind all the clients that the package is run on to a directory service,
automating one more task. Drives can be partitioned prior to installation or repaired afterward.
NetInstall and NetRestore can handle all these tasks.
This section shows how to use System Image Utility to provide NetInstall and NetRestore imaging
environments with additional logic to be leveraged in common automations, thus streamlining
installation tasks.
To image OS X and automate tasks with System Image Utility:
2. From the lower-left corner of the window, click the Add (+) button.
3. Choose Create New Workflow.
The Automator Library appears next to the System Image Utility window.
The default workflow in System Image Utility is populated with Define Image Source and
Create Image steps. All workflows that create network disk images must contain these two
steps.
5. Remove the initial workflow steps to start with a blank slate.
6. From the Automator Library, drag the Define Image Source action into the workflow.
7. Choose the image you want to use as the source for your workflow. This can be the Install OS
X Mountain Lion installer, a prepared image, or a preinstalled volume.
8. From the Automator Library, drag the Filter Computer Models action into the workflow,
which will connect to the Define Image Source item above it. Note that if an item doesnt
interconnect with the item above or below it, the workflow fails.
9. Use the Filter Computer Models item to set which computers will run the image. The default
setting is to include all computer models. A selected checkbox enables that computer model
to start up using your defined image source.
To set up a workflow item that partitions the target disk:
1. From the Automator Library, drag the Partition Disk action into the workflow.
2. From the partitions pop-up menu, choose the number of partitions and enter a name for
each.
3. Select the Partition the disk containing volume checkbox to limit which disks will be
repartitioned. This feature helps reduce the dangers associated with repartitioning a drive,
like overwriting external drives, jump drives, or computers that arent ready to be imaged.
The checkbox labeled Display confirmation dialog before partitioning is another feature
that helps decrease the risk of erasing user data. However, note that both this and the
previous step can stop the imaging process, which may be an issue if youre trying to install
hundreds or thousands of systems. Use both partitioning options as needed.
4. Choose the format for the drives. In most cases, the default settingMac OS Extended
(Journaled)is fine.
5. Choose the minimum size for each partition. This is a sanity check so the tool doesnt try to
image 40GB to a 10GB drive and partition a chunk away for other tasks.
Its better if the imaging process fails early, because it keeps troubleshooting imaging issues
to a minimum allowing mass deployment staff to move onto imaging the next host.
To set up a workflow item that adds a user account:
You need a local administrator account to log in to imaged computers after theyre set up (for
troubleshooting, software updates, Apple Remote Desktop, and so on).
1. From the Automator Library, drag the Add User Account action into the workflow.
2. Provide a user name, short name, and password for this account and click the Allow user to
administer the computer checkbox.
3. To create multiple accounts, drag a new Add User Account item into the workflow.
To set up a workflow item that sets the computer name:
Every computer, whether using OS X, Microsoft Windows, or Linux, needs a unique name on the
network. Use the Apply System Configuration Settings action to rename the system following
imaging.
1. From the Automator Library, drag the Apply System Configuration Settings action into the
workflow.
2. Select the Generate unique Computer Names starting with checkbox and enter the prefix
that imaged systems will use. Each system will begin the host name with that prefix (such as
Marketing-1, Marketing-2, and so on).
3. Alternatively, you can pull the information from a file by selecting the Apple Computer
Name and Local Hostname settings from a file checkbox.
If the computer running System Image Utility has been bound to a directory service like Open
Directory, Active Directory, eDirectory, or some other directory service, select the Connect
computers to directory servers checkbox. This feature adds the imaged system to the directory
service as a post-installation task.
Note: Most directory services require unique entries for each computer, so the binding state
before imaging wont carry through to the image unless this option is selected or a custom script
is used to bind.
For prepared images, select the Change ByHost preferences to match client after install
checkbox.
To add additional software to a System Image Utility workflow:
The most powerful feature of the Automator Library is the ability to install packages. The Add
Packages action is useful if you have software that comes distributed as a package, such as
software updates downloaded from Apples Support website. However, if you know how to
create your own packages, and more specifically use shell scripting to automate tasks, the Add
Packages action is most beneficial to you and will help you further automate your installation
process.
Note: Software installers added to System Image Utility must be in standard installer packages
(.pkg) format.
1. From the Automator Library, drag the Add Packages and Post-Install Scripts action into your
workflow.
2. Click the Add (+) button to add your software packages to the action.
Note: When you add multiple packages and scripts to a workflow, they install or run in the order
listed in the Add Packages and Post-Install Scripts workflow item.
To add a configuration profile to a System Image Utility workflow:
With System Image Utility, you can add configuration profiles to your NetInstall and NetRestore
workflows. By adding profiles, you can preconfigure the Mac for a number of settings and
services.
You can then create configuration profiles with the OS X Server Profile Manager service.
1. From the Automator Library, drag the Add Configuration Profiles action into your workflow.
2. Drag and drop, or use the Add (+) button, to add your configuration profiles to the action.
Note: If your workflow has packages and scripts that rely on a certificate thats installed by a
configuration profile, make sure the configuration profiles are installed in the workflow
before the packages and scripts.
To configure the Enable Automated Installation workflow action:
Use the Enable Automated Installation action to set the options for automated (unattended)
client installations. This action is only valid when creating NetInstall or NetRestore images.
1. From the Automator Library, drag the Enable Automated Installation action into your
workflow.
2. Determine how you want the target volume to be selected. This is the volume that the
image will be installed on.
The Selected by user option permits users to select which volume on their client computer
to install the image on.
The Named option permits you to set the volume without interaction from the user by
entering the name of the target volume.
3. To erase the target volume before the image is installed, select the Erase before installing
checkbox.
Warning: Using the Erase option removes all data from the target volume. Back up all data
before using this option.
4. From the Main Language pop-up menu, choose the image language.
To create an image from your workflow (now that its complete):
Before your workflow is finished, you need to include the Create Image step.
1. From the Automator Library, drag the Create Image action into the bottom of your workflow.
2. Select the type of image youre creating, then enter a name and location. (This example uses
the default path for a NetInstall volume that will be added to the NetBoot options /Library/
NetBoot/NetBootSP0).
3. For Image Index, enter a unique number. If the image will be hosted on a single server, the
index value should be between 1 and 4095. If the image will be hosted on multiple servers
to provide load balancing, the value should be 4096 or greater.
4. Enter a description of your image. The description can list the automations and filters you
added for easy identification.
5. Click Save before you click Run so you can load the workflow from other systems or version
workflows, if necessary.
6. Click Run.
The image is created in the target destination and is ready to test from clients.
Additional System Image Utility preferences
System Image Utility has several advanced preference settings. You can access these settings with
the defaults command in a Terminal session.
You can use several advanced settings to fine-tune the operation of System Image Utility. All of
the advanced settings except addlNetBootMbytes are boolean values.
asr_blockCopyVolume causes System Image Utility to create a NetRestore image using a
device block copy instead of a volume file copy. Although this isnt best for creating production
images, it can dramatically reduce the time needed to create test images. The default setting is
off.
asr_displayCountdown causes a 30-second countdown to be displayed before imaging
begins. This can be a useful safety measure when you use it along with an automated
deployment image. The default setting is off.
asr_retainOriginalVolumeName controls whether the NetRestore volume retains the
original volume name when deployed. The default setting is on.
consumeSuppliedImage causes System Image Utility to use a supplied disk image when
creating a NetRestore volume rather than copying it first. The default setting is off.
addlNetBootMbytes is an integer value that represents, in megabytes, the amount of
padding to add to a NetBoot image for free space. The default is 400.
To set advanced preferences for System Image Utility:
1. Open a Terminal window.
2. Use the defaults command to set the preference you want. For example, to set the
asr_blockCopyVolume preference to true, use the following command:
defaults write ~/Library/Preferences/
com.apple.server.SystemImageUtility asr_blockCopyVolume -bool 'true'
To disable this setting, set the key to false with the following command:
defaults write ~/Library/Preferences/
com.apple.server.SystemImageUtility asr_blockCopyVolume -bool 'false'
3. Exit the Terminal session and relaunch System Image Utility.
Additional resources
For more information, refer to the following resources:
Supporting Mac Users: The Self-Support Modelhttp://training.apple.com/pdf/
wp_self_support.pdf
Imaging the MacBook Air: Leveraging Thunderbolthttp://images.apple.com/education/docs/
Apple-ThunderboltWhitePaper.pdf
3 Deployment
After youve generated images and customized the automations to go into those images, the
next step is to deploy them. The simplest form of deployment is to locally apply an image from
one Mac to another, via USB or FireWire. This process can be cumbersome, so additional
techniques are introduced here to help streamline the process toward enabling a one- or zero-
touch deployment.
Local deployment
Local image deployment is the simplest form of deployment for Mac computers. By taking
advantage of native tools such as Apple Software Restore, Disk Utility, and target disk mode,
administrators can quickly and easily test deployment images using direct connections between
computers without the need to move images to production or test servers.
Local imaging techniques, however, dont scale well and arent suitable for deploying a large
number of Mac computers in most environments. Local deployment is typically most suitable for
test environments when ironing out details about how the larger scale deployment process will
work.
Creating a bootable disk or volume from a NetInstall image
Not all Mac computers have a fast Ethernet link to a server. You can still use your NetInstall
environment to push images to these sites; however, instead of using NetBoot or NetInstall, you
can use USB or FireWire volumes or a DVD.
This section explains how to use NetInstall to create a bootable hard drive that automatically
installs a client system. Because most images are now over 6GB, use an 8GB USB stick or external
USB or FireWire drive that has more storage for imaging purposes. Before you do this, define a
NetInstall workflow.
To use NetInstall to create a bootable disk or volume:
1. Locate a NetInstall image.
3. Drag the NetInstall.dmg file from the .nbi folder into the Disk Utility sidebar.
4. Select the NetInstall.dmg file.
5. Choose Images > Scan Image for Restore.
Note: If the image is a read/write image, youll get an invalid arguments error. To correct this
error, use the Convert command from the Images menu to convert the image into a read-
only image before scanning for restore.
6. After the image is scanned for restore, select the NetInstall disk image in Disk Utility and click
the Restore tab.
7. Drag the icon for the external drive from the list to the Destination field.
8. Click Restore.
9. After the NetInstall image has been restored onto the external drive, connect it to a Mac that
can be erased.
10. Boot the Mac and hold down the Option key to make the newly created volume appear as a
selection.
11. Select the local NetInstall volume to begin the NetInstall process using the local drive as the
installation source instead of a network drive.
Deploying with Disk Utility
This section explains how to use Disk Utility to copy an image from one hard drive to another.
To deploy an image with Disk Utility:
2. Select the destination (or target) drive and click Restore. Drag the image file from the Finder
into the Source field, or click the Image button to browse to the image you want to use.
3. Drag the volume you want to restore to into the Destination field.
Note: The destination is erased, speeding up the restoration process.
4. Click Restore to initiate the restore.
Deploying with NetInstall
The NetBoot, NetInstall, and NetRestore features of OS X Server offer you alternatives for
managing the operating system and application software that your Macintosh clients (or even
other servers) require to start and do their work. Instead of going from computer to computer to
install the operating system and application software from CDs, you can prepare an installation
image that installs on each computer when it starts up. You can also choose to not install
software and have client computers start up (or boot) from an image stored on the server. (In
some cases, clients dont even need their own hard disk.)
With NetBoot and NetInstall, your client computers can start from a standardized Mac OS X
configuration suited to specific tasks. Because the client computers start from the same image,
you can quickly update the operating system for users by updating a single boot image.
You can set up multiple NetBoot or NetInstall images to suit the needs of groups of clients or you
can provide copies of the same image on multiple NetBoot servers to distribute the client startup
load. You can also use a NetRestore image to quickly restore a volume.
NetInstall considerations
All systems supported by OS X Mountain Lion can use NetBoot to start from an OS X Mountain
Lion network disk image.
You must install the latest firmware updates on all client computers. Firmware updates are
available from the Apple Support website: www.apple.com/support/.
NetInstall is supported only over physical Ethernet connections. Using AirPort wireless
technology to boot clients using a network disk image isnt supported by Apple and is
discouraged.
Configuring a NetInstall server
NetInstall and NetRestore both rely on NetBoot to boot an operating environment that frees the
internal drive for an operating system image or upgrade. NetBoot boots a Mac computer to an
operating system stored within an installation image hosted on a NetInstall server.
An OS X Server can act as a NetInstall server and is covered in this section. The instructions
assume youve already installed and are running OS X Server on an OS X Mountain Lion
computer.
To configure a NetInstall server:
1. Open the Server app (located in /Applications/).
2. From the Server list on the left, select the server on which you want to configure the
NetBoot and NetInstall/NetRestore services.
3. From the Services list, select NetInstall.
4. Click the Settings tab.
5. Click the Edit button to the right of Enable NetInstall on.
6. Make sure at least one network port is selected.
Note: You should not provide NetBoot services over any ports other than gigabit Ethernet
ports in modern environments.
7. Click OK.
8. Click the Edit Storage Settings button.
9. In the entry for the volume on which you want to store the NetInstall images and client
data, choose Images & Client Data from the pop-up menu.
10. Click OK.
11. Place the network disk images you created earlier in the
/Library/NetBoot/NetBootSP0 directory of the volume you just selected.
12. Click the Images tab.
13. Select the image you want to use.
14. From the Action pop-up menu, choose Edit Image Settings.
15. Select the Make available over checkbox.
16. Choose the protocol over which you want to make the image available.
17. Click Done.
18. If this is your first image, you may want to set this image as the default. If so, select the image
and choose Use as Default Boot Image from the Action pop-up menu.
19. To start the NetInstall service, click the on/off switch in the upper-right corner.
20. To test booting a system to the image, start up the client while holding down the N key, or
use the Startup Disk in System Preferences on the client to select an image from the NetBoot
server you just set up.
Custom source NetRestore
After youve created a network disk image and enabled it on a NetInstall server, there are a few
methods you can use to have client computers boot using the image.
Start up using the N key:
You can use the N key to start up any supported client computer from a NetInstall disk image.
With this method, the client computer uses the Boot Service Discovery Protocol (BSDP) to locate
a NetInstall server and starts up from the servers default disk image. If multiple servers are
present, the client starts up from the default image of the first server to respond.
When you use the N key to boot using the default NetInstall image, your computer remembers
what server and image was used. The next time you hold down the N key at startup, your
computer attempts to use the same server and image, even if that image is no longer specified
as the default image. Holding down Option-N during startup causes the computer to boot using
the current default image.
To boot using a specific network disk image:
If your NetInstall server is hosting multiple images or you have set up multiple servers, you can
use the Startup Disk in System Preferences to select a specific boot image to use.
1. Choose System Preferences from the Apple menu.
2. Click Startup Disk.
3. Click the name of the network boot image created for NetRestore.
4. Click Restart.
The computer is booted into the NetRestore environment, where youll see the icon for
System Image Utility.
5. Click the image you want to restore, then click Continue. Alternatively, you can type the path
to the image in the field provided (if that option was selected when you created the NetBoot
set).
Setting clients to boot from a network disk image using the bless command
To boot a client system to your NetInstall server, simply hold down the N key to boot the default
image off the first server, or use the Option key to enable you to select a server. You can also use
the Startup Disk pane in System Preferences to select which NetBoot server to boot to, if the
client can find the NetBoot server using standard broadcast traffic.
You can also specify an IP address to boot to using the command line. This is made possible with
the bless command in OS X, which tells a system where to look for the folder it should boot
from. You can use the bless command to specify which volume or folder to boot from, but also
to define a network volume that a client should boot from, as is the case with NetBoot.
For the purposes of this example, the IP of the NetBoot server is 10.0.9.2 and the client is on the
same subnet as the server, booting through Dynamic Host Configuration Protocol (DHCP). You
can simply transpose this IP address for that of your environment if you cannot duplicate the
setup used here.
To use the bless command to define a NetBoot volume that resides on a server:
2. Use the command bless without any arguments to get comfortable with the syntax youll
be using and the available options. After youre comfortable, run the following command:
bless --netboot --server bdsp://10.0.9.2
The options used in the above command are --netboot, which invokes NetBoot mode, and
--server, which specifies the IP address (or DNS name) that NetBoot mode will look for
instead of relying on a discovery protocol for this information. Notice that you also defined
the server as a URL, telling the system that bdsp will be used in front of the server name. This
is because you can use the --booter option with NetBoot mode, so you can specify the tftp
server for NetBoot along with the nfs or afp location of your NetInstall .dmg file.
3. After you run it, use the following command to make sure that the command worked:
bless --info 10.0.9.2
Using bless you can directly target a NetBoot server, even if that server is in a different
subnet from the client system.
4. If the correct information appears, you have now set the active boot volume to the IP
address in question. For more information on using the bless command, see the man page
for bless by running the following command:
man bless
Using NetBoot DHCP helpers
NetBoot service uses an Apple-developed protocol based on DHCP known as Boot Service
Discovery Protocol (BSDP). This protocol provides a way to discover NetBoot servers on a
network.
NetBoot can cause problems on certain networks, as can any other network or discovery
protocol. To determine quickly whether NetBoot will work on your server, enable DHCP on a
NetBoot server, connect a crossover cable to a client computer, and start up the client while
holding down the N key. Then try the same process when running through your switches. If
NetBoot works when directly connected, and it doesnt work when it goes through your
organizations switching and routing infrastructure, its likely a problem with your infrastructure.
There are a number of ways to avoid infrastructure problems to enable NetBoot service. Chief
among them is to set up your router for BSDP. One way to do this is to enable User Datagram
Protocol (UDP) forwarding to forward all UDP packets for BSDP to the NetBoot server in
question, which would allow that server to host as many NetBoot environments as you want. This
is not unlike if you currently use your router for forwarding all DHCP traffic, no matter which
subnet it is sourced on, to a specified server.
If this isnt an option, you can also look to DHCP, which allows for a number of extensions. With
these extensions, you can provide a number of options with DHCP in addition to the standard IP
address and subnet mask that are common in DHCP leases. These include options like DNS
servers, NIS servers, SMTP servers, and so on. For more on DHCP extensions, go to: http://
www.ietf.org/rfc/rfc2132.txt.
DHCP supports a number of standard services but also has options for vendors to leverage. BSDP
is one such vendor extension, developed by Apple. DHCP options include option 41, also known
as vendor-specific information, and option 60, also known as the vendor class identifier.
Each router and DHCP server is different. However, this should help you investigate whats
required to enable and configure DHCP helper addresses on your routers to accommodate
NetBoot server discovery across subnets.
bootpd relay
DHCP is required for NetBoot. Many environments will already have DHCP servers on each
segment, Virtual LAN (VLAN), or a subnet of the network where a Mac might try to initiate
NetBoot. If you can see a NetBoot server in the Startup Disk pane in System Preferences, but you
cant initiate a NetBoot session into that server by booting while holding down the N key, you
might need to establish a bootpd relay for BSDP and its parent DHCP.
This section covers how to configure a Mac running OS X Mountain Lion to provide a bootpd
relay agent to enable NetInstall server discovery across subnets.
To edit the bootpd.plist file on the system to act as the relay:
pico /etc/bootpd.plist
3. Find the section of the file that indicates the following:
<key>relay_enabled</key>
<false/>
<key>relay_ip_list</key>
<array/>
4. Edit the <false/> value for the relay_enabled key so that it reads <true/>.
5. Replace the <array/> empty array for relay_ip_list with the NetBoot server IP address, as
follows:
<array>
<string>192.168.210.1</string>
</array>
The resultant section of the file should appear as follows:
<key>relay_enabled</key>
<true/>
<key>relay_ip_list</key>
<array>
<string>192.168.210.1</string>
</array>
6. After youve configured the parameters, load the bootps LaunchDaemon as follows:
launchctl load -w /System/Library/LaunchDaemons/bootps.plist
7. Now you can start the bootpd process with launchctl as follows:
launchctl start com.apple.bootpd
Restoring with Apple Software Restore
Even without OS X Server, you can image Mac computers across the network. You can use the
same utility that you use for creating images, Apple Software Restore (ASR), for deploying the
same images across the network. ASR allows for both multicast and unicast restores when the
source image is accessed over a network. Both operations can be performed by any Mac
computer, and neither operation requires a computer with OS X Mountain Lion Server, although
OS X Server does make the task simpler with NetRestore.
Unicast Apple Software Restore (ASR)
In a unicast restore, each Mac target establishes a separate connection to the server hosting the
image and begins to copy it. Although you can use Apples Disk Utility to create and restore
images, it can be beneficial to do so programmatically as well. Alternatively, you could use the
following command to perform the imaging:
sudo asr restore --source /Users/USERNAME/Desktop/OS\ X\
\ Mountain\ Lion\ Image.dmg --target Mac\ OS\ X/ -erase
The above command uses the restore verb, defines the --source and --target settings, and
uses the -erase checkbox.
Rather than using direct attached storage, such as FireWire, you can use asr to restore images
from a file hosted by http. To do this, place the image on a web server, then use a command
similar to the following (for this example, the fully qualified domain name, or FQDN, of the web
server is mywebserver.pretendco.com and the name of the image is myimage.dmg):
sudo asr restore --source http://mywebserver.pretendco.com/myimage.dmg --
target /Volumes/Mac\ OS\ X/ -erase
In the above command, the source is defined with the URL that it would be accessible using
http. The file was renamed myimage.dmg to make it friendlier to http requests. Defining the -
erase option speeds up the restoration and makes the image blessed (bootable).
This still assumes that the source Mac is being booted into target disk mode because you cant
lay down the image on top of a running operating system.
Multicast Apple Software Restore (mASR)
Unicast restores have a major drawback in that they rely heavily on the servers resources to
determine how many systems can be restored all at once. However, as with many multicast
protocols, multicast Apple Software Restore (mASR) broadcasts the disk image as a stream. The
mASR server plays the stream onto the network, similar to how a song is played on the radio. Mac
computers connect to the stream and copy the image block by block. Streams are looped, and if
a Mac connects to the stream midway through the stream, it completes the current loop from
where it joined and retrieves the remaining data on the next loop.
Because data is streamed to all client systems, performance on the mASR servers is not affected
when more client systems are added.
To set up a multicast Apple Software Restore environment:
The first task in setting up a multicast ASR environment is to set up the server. To do so, use the
same command line utility that was used previously: asr. The asr command will need a
configuration plist file that contains the following information:
Multicast AddressThis is the multicast address for the data stream.
Data RateThis is the desired data rate in bytes per second. On average, the
stream will go slightly slower than this speed, but will never exceed it.
1. Set up the plist file. For these purposes, use a filename of asrsetup.plist in the folder
/asrconfig (which has been chosen arbitrarily). Create the directory using the following
command:
mkdir /asrconfig
2. Use the defaults command to populate the file with the settings that were planned for
earlier:
defaults write /asrconfig/asrsetup.plist "Data Rate" -int 10000000
defaults write /asrconfig/asrsetup.plist "Multicast Address"
192.168.0.2
You can also provide other optional information in the asrsetup.plist configuration file. You
can define the Client Data Rate, which is the slowest rate a client can operate at without
running into errors. The DNS Service Discovery is defined as a -bool for boolean, and
defines whether the ASR server should use Bonjour. Loop Suspend is an integer that limits
the number of times an image is streamed without any clients using it before stopping the
ASR server and waiting for new clients. You can customize Multicast TTL and port as well,
although its rare for them to be changed from their default settings.
3. After youve set up your .plist file, take an image (in the form of a .dmg file) and move it into
the /asrconfig directory.
4. Start up the ASR server with the following command:
sudo asr -server /asrconfig/asrsetup.plist -source /asrconfig/
myimage.dmg
5. Now that you have a functional ASR server, tell a client to look to the server for connectivity.
This is fairly straightforward in either Disk Utility or with the command line. In the following
example, the source computer is myasrserver.pretendco.com and the image is called
myimage:
sudo asr restore --source asr://myasrserver.pretendco.com/myimage.dmg
--target /Volumes/Mac\ OS\ X/ -eraseCreating NetRestore NetBoot Sets
To create a NetBoot set for NetRestore using System Image Utility:
As mentioned earlier, you can use the NetBoot service in OS X Server to assist in restoring Mac
computers with ASR. This section describes how to create a minimal NetRestore image that
allows you to predefine, manually enter, or browse for source locations of ASR images (for
example, file, URL, and so on), when theyre accessible with Bonjour.
2. Click the Add (+) button in the lower-left corner of the window.
3. Choose Create New Workflow.
4. Read the software license agreement, and click Agree.
5. In the window that shows the NetRestore options, click the Close (x) button for the Define
Image Source and Create Image steps to remove them and leave the area empty.
6. From the Automator Library, drag the Define NetRestore Source action to the workflow
screen.
7. Click the Add (+) button within the Define NetRestore Source action and enter the path
where the .dmg is located.
8. In the Enable browsing for section, select the ASR multicast streams checkbox if you want
to see a list of all available ASR multicast streams.
9. To search for other NetRestore sources from the network (such as http), select the Other
NetRestore sources checkbox.
10. To allow users to manually provide a path to a .dmg, select the Allow manual source entry
checkbox.
11. From the Automator Library, drag the Create Image action into the workflow, below the
Define NetRestore Source area.
12. Leave Type set to NetRestore, and enter the names for the image and the network disk.
13. Enter a description to help keep track of NetBoot sets; and an image index, which is a unique
identifier you havent used for a NetBoot set.
14. Click Save, and save the workflow with a name that you can easily find later.
15. Click Run, and wait for the NetBoot set for NetRestore to complete. The time this process
requires depends on the size of the NetBoot set and speed of the volumes to which the
NetBoot set is being written.
Minimal-touch deployments
By following Apples best practices, you can achieve minimal touch, or even zero- touch
deployments with OS X. There are three main components to a minimal-touch deployment.
Deployment imaging. The first step of any deployment (and especially with a minimal-touch
deployment) is the development of a good deployment image. A deployment image should
contain as few customizations as possible to protect it from constant revisions and make it as
business-unit agnostic as possible. Ideally, it only contains OS X, local settings, and keystone
applications. Keystone applications are software packages installed on 100 percent of the Mac
computers in your organization.
Directory services. By fully utilizing directory services, you gain centralized control over user
identities and user data and provide for the delivery of a cohesive management policy
framework. You should build a script that binds the Mac to your directory service into your
deployment image.
Client management. Using a client management system completes the minimal-touch
deployment, and you should build this client management agent into your deployment
image. On initial startup, the Mac contacts the client management suite and uploads its
inventory information. At this point, any unit-specific software is provisioned, along with any
update deltas that exist for the current deployment image. With most client management
suites, optional applications are delivered to users Mac computers via self-service software
tools.
When you use this type of workflow in conjunction with having systems imaged at the factory
(or by an Apple Authorized Reseller) before they arrive at your location, you can achieve a zero-
touch deployment.
Third-party deployment solutions
The following is a partial list of third-party solutions for OS X deployment:
DeployStudio http://www.deploystudio.com
JAMFs Casper Suitehttp://www.jamfsoftware.com
Absolute Managehttp://www.absolute.com
KACEhttp://www.kace.com
LANDeskhttp://www.landesk.com
FileWavehttp://www.filewave.com
For more information about deploying Mac computers, refer to the following resources:
Other services section, OS X Server: Advanced Administrationhttp://help.apple.com/
advancedserveradmin/mac/10.8/
OS X Education Deployment Guidehttp://www.apple.com/education/resources/information-
technology.html
4 Caching Software Downloads
The Caching service speeds up the download of software purchased through iTunes and the Mac
App Store. The software thats cached includes software updates, purchased apps, and books.
Without any configuration, OS X computers are able to take advantage of a Caching server. When
you set up a Caching server, the server registers its public IP address with Apple. When the Mac
App Store or iTunes apps on OS X computers that share the same public IP address make
download requests, the client computers are automatically redirected to the local Caching
server. When a client computer leaves the network, such as when a MacBook is taken home, it
reverts back to getting software directly from Apple.
Requirements
The Caching server supports clients with OS X v10.8.2 or later and requires that clients share the
same public IP address behind a NAT. If you have more than one Caching server on your
network, clients automatically select the right server.
The following figure is an example of a single subnet with a Caching server:
If your network has multiple subnets that share the same public IP address, the subnets can take
advantage of the Caching server. For example, the following figure shows a network with two
subnets sharing a single Caching server:
You can get the best performance from your Caching server by connecting it to your network
using Ethernet. The Caching server can serve hundreds of clients concurrently, saturating a
Gigabit Ethernet port. Therefore, in most small- to medium-scale deployments, the performance
bottleneck is usually the bandwidth of your local network. To determine if your server hardware
is your performance bottleneck when a large number of clients are accessing the server
simultaneously, check the Processor Usage graph in the Stats pane. If the processor usage is
constantly at or near the maximum, you may want to add additional Caching servers to distribute
your clients caching requests across multiple servers. Also, if your server is in an environment
where clients download a wide variety of large amounts of content, be sure to set the cache size
limit high enough. This prevents the Caching server from deleting cached data frequently, which
may cause the redownloading of the same content at the expense of more Internet bandwidth
consumption.
Managing the Caching service
The default location for cached content is the boot volume. You can choose an alternate location
and specify how much of the volume is used by the service.
As the Caching server gets request for content to be downloaded and cached, more of your disk
space is used to store the cached content. When the disk space of the cached content reaches
the maximum you specified in the Caching pane, or when the available space on the volume
reaches 25GB, the Caching server deletes the least recently used cached content to make space
for the next request.
To start the Caching service:
1. Open the Server app (located in /Applications/).
2. From the Services list on the left, click Caching.
3. Click the on/off switch to turn on the Caching service.
At this point and without any additional configuration, the Caching service will start to cache the
Mac App Store and iTunes downloads.
To select a volume for caching:
1. In the Caching pane, click Edit.
2. Select a storage volume.
3. Click Use Selected Volume.
To delete all cached content:
1. If you want to delete all cached content, click Reset in the Caching pane.
2. If youre sure you want to proceed, click Reset again.
To set cache size:
In the Caching pane, use the slider to adjust the caching limit.
Comparing the Caching and Software Update services
The Software Update server and the Caching server both provide updates to software installed
on Mac clients. However, the following are key differences between these services:
The Software Update server caches only updates; the Caching server can cache both updates
and purchases from the Mac App Store.
With the Software Update server, you need to manually configure clients to only use a specific
software update server; with the Caching server, no client configuration is required. Clients
automatically access the available Caching server on the network theyre currently on, making
it mobile-client friendly. For example, when a client is at work, it can use the Caching server at
work, and when the same client is at home, it can use another Caching server at
home automatically.
The Software Update server downloads and caches all available updates when it first starts up;
the Caching server downloads and caches software based on client requests.
The Software Update server provides client management functionality, such as the ability for
administrators to restrict which updates can be seen and downloaded by clients; the Caching
server doesnt provide any client management functionality.
If you need client management functionality, use the Software Update server. Also, if you
configure your client to use the Software Update server, it takes precedence and the client
cannot use the Caching server for software updates.
Important: The Caching server and Software Update server can coexist on the same server, but
they dont share cached content, which may result in additional disk space being used.
Client configuration
In order to access your Software Update server, the Software Update preferences on your client
computers need to be configured to direct them to the server. This is typically done through
managed preferences in Workgroup Manager or configuration profiles, but can also be done by
modifying the preferences directly.
No client configuration on your part is required with the Caching service. On a regular basis, a
Caching server registers itself and its public IP address with Apples software servers. When client
devices attempt to access Apples servers, the devices are automatically directed to the Caching
server associated with your public IP address.
Download management
With the Software Update service, you can select which updates are available to the client
computers. This is useful for organizations that want to restrict access to new software until it has
been tested for compatibility.
The Caching service doesnt provide any control over software availability.
Note that client computers that are configured to use your Software Update server dont access a
Caching server for software updates. They do, however, still use the Caching server for other
downloads, such as app purchases.
Software cached
Both services cache Apple-provided software updates, however, the Caching service also caches
other content downloaded using iTunes or the Mac App Store, such as apps and books.
Note that currently iOS doesnt access a Caching server. The server caches OS X apps and books
downloaded using iTunes on a Mac or Windows computer.
When software is cached
With the Software Update service, all updates are downloaded in advance of client computers
requesting them, usually when the Software Update service is turned on, and as additional
updates become available afterwards.
With the Caching service, software is downloaded and cached as client computers request it. The
first computer to request an app experiences a longer download time. All computers requesting
the same app afterwards experience faster downloading as they get the app from the Caching
server.
For more information about setting up and configuring the Caching service:
OS X Server: Advanced configuration of the Caching servicehttp://support.apple.com/kb/
HT5590
Caching Content from Apple, OS X Server Essentials: Using and Supporting OS X Server on
Mountain Lion, Peachpit Press

OSX ML TT Deployment

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

OSX ML TT Deployment

Hochgeladen von

Copyright:

Verfügbare Formate

This document is intended for Apple internal and channel audiences, and is for training purposes only.

In the User Email Address field, enter your email address.

Name: Enter the full administrator account name.

Das könnte Ihnen auch gefallen