Mac Image Deployment

We almost always use DeployStudio. Sometimes it's handy to use Carbon Copy Cloner to backup to an external drive before installing a new OS.

See Also

• MacImaging for creating the image to be deployed

Terms

• ARD - Apple Remote Desktop
• nbi - net boot install directory - bootstrap
• dmg - Apple Disk Images are disk image files commonly used by the Mac OS X operating system. Apple disk images allow secure password protection as well as file compression and hence serves both security and file distribution functions; they are most commonly used to distribute software over the Internet.
• DS - DeployStudio
• Masters - collection of distribution images.

Deploy Studio

There are two ways to install an image via Deploy Studio. It can be initiated from the client (that will access a remote Deploy Studio server), or from a Deploy Studio server that has appropriate permissions. Common to both approaches, is images on a Deploy Studio server.

The NetBoot server (which we usually run on the same machine as Deploy Studio) should be turned on and the preferred NetBoot image set (see below) selected as "Default" in NetBoot service -- Server Admin → NetBoot → Images.

Image Naming Conventions

Image filenames, on a Deploy Studio server, are of the form:

/DS/Masters/HFS/Creator_PartitionName_CreateTime.i386.{hfs,recovery}.dmg

• HFS - is specific to Macs. In principle it can also specify other architectures such as NTFS, FAT, DEV, PC, .... Mac images are automatically placed in the HFS directory. Windows images are placed in the NTFS directory.
• Creator is the hostname of the machine that created the image, e.g. "imac000" from "imac000.student.cs".
• CreateTime is the time of image creation, of the form YY.MM.DD_HH.MM, e.g. 14.05.12_14.13
• "recovery" is for a recovery partition (which we always want), and "hfs" is for the main partition.

For example, as of 2014-05-12 the two needed images for an installation are named

imac000_MacintoshHD1_14.05.12_14.13.i386.hfs.dmg
imac000_MacintoshHD1_14.05.12_14.13.i386.recovery.dmg

See below for knowing which image to pick for a specific OS version. We have been assuming that the same image will work on both an iMac and a Mac Mini.

Client Side Initiation

Client Selects a Boot Server

The first step of imaging is to contact a Netboot Server, from which a boot program (NBI — Net Boot Image) will be downloaded. If the Netboot Server is not on the same subnet as the machine being imaged, it's necessary to configure the machine to know the network address of the server. That is done with the `bless` command, e.g. In general this short version:

sudo bless --netboot --server bsdp://ip.address.here --nextonly

should tell your Mac to boot from the default NetBoot set available from the NetBoot server. The long version is (should all be one line):

sudo bless --netboot \
   --booter tftp://ip.address.here/NetBoot/NetBootSP0/NetBoot-Set-Name-Here.nbi/i386/booter \
   --kernel tftp://ip.address.here/NetBoot/NetBootSP0/NetBoot-Set-Name-Here.nbi/i386/mach.macosx \
   --kernelcache tftp://ip.address.here/NetBoot/NetBootSP0/NetBoot-Set-Name-Here.nbi/i386/x86_64/kernelcache \
   --options "rp=nfs:ip.address.here:/private/tftpboot/NetBoot/NetBootSP0:NetBoot-Set-Name-Here.nbi/NetInstall.sparseimage" \
   --nextonly

In our case we can use:

ip.address.here	129.97.51.14	the IP address of the NetBoot server (mutsu.student.cs in this example)
NetBoot-Set-Name-Here	DSR-1092	the "1092" refers to Mac OS X 10.9.2

The NBI's are built (by Deploy Studio) on the architecture that we intend to deploy to. The --nextonly switch does the bless only for the next boot. That avoids the problem of rebooting over and over if the arguments to the `bless` command are wrong.

Also note that you can use HTTP hosted images with the extended syntax as well (rp=http://...). The nice thing about that is that the kernel/cache and booter can live on whatever server is running tftp, while the images can sit on another server running http. This allows for easy load balancing. First on the server end, you need to change the Netboot service protocol from NFS to HTTP. Also NetBoot support is available for OS X VMs in VMWare Fusion's Technology Preview which means we can NetBoot virtual machine images.

If your machine is on the same network as the NetBoot server, the machine can then be netbooted by selecting the appropriate NBI by holding OPTION (a.k.a. ALT) to access the boot menu on startup (if a firmware password exists, it will have to be entered). On Macs with older firmware, the NBIs may not appear under this menu. In this case, the machine would have to be booted into a copy of OS X (either an already installed volume, recovery partition or installer DVD/USB) and the Startup Disk would have to be changed to the appropiate NBI.

The boot servers usually aren't configured to allow a remote image install. To change this, login to the server (via a regular Apple login), start "Server Preferences" (in /Applications if not in the Dock), and select/start NetBoot.

Troubleshooting

1. If you're not finding any servers when you think you should, then you can reset the PRAM to factory defaults, and then do the `bless` command (see http://support.apple.com/kb/ht1379). We haven't seen the need for this recently.
2. If there are read errors on the disk, reboot to the recovery partition (use the option key while booting), start DiskUtility, and erase the OS (Macintosh HD) partition and/or do a partition repair.
3. When Apple introduced the fusion drive it caused a particular error in image deployment with DeployStudio. This link explains the problem and offers a resolution. http://pivotallabs.com/a-deploystudio-workflow-for-late-2012-imacs/

Client Installs the Image

If there is no firmware password, holding down the "N" key while rebooting will cause it to NetBoot. That will result in an answer from the first available server. Our servers are all configured to use DeployStudio.

If there is a firmware password, use the Option key instead of "N", which will allow entry of the password, and selection from the possible boot sources. A boot source can be either from a local device, or a remote server (which we configure to answer via DeployStudio).

The firmware password is recorded in the usual place. Note: When attempting to deploy multiple systems simultaneously, a bolt heavy enough to hold down the "N" key might be used. Select a boot source, and it will download the NBI which will then download the partition images that were configured in the NBI (typically by Deploy Studio).

When a choice of NetBoot servers is offered, the names are not the names of the machines offering the service (see Netboot Servers), rather they are configurable names, typically of the form

DSR-<version>

E.g. "DSR-1092", for a 10.9.2 version of the OS. We sometimes have do names that include the servers, of the form:

DSR-<version>-<server>

E.g. "DSR-1085-EmpireMutsu".

An NBI built by Deploy Studio can present "workflows", which are separately present on the server. They are specified before the disk is rewritten. Typical choices are:

• select (a different) server for the disk image
• build a master image
• specify which partitions will be affected
• select a meta-package that installs specific applications
• ...

some of which are not relevant for an image installation.

Once the appropriate workflow has been selected, hit the "Run" button (top left corner). Multiple workflows can be run. Deploy Studio also has pre-flight and post-flight (i.e. before and after image installation) activities, that are configured separately from workflows (which can invoke specific pre and post actions).

Our preferred/default workflow will erase the first available disk. This is a problem with: 1.) fusion drives since it erases the SSD portion of the combined drive and tries to install on the first available drive - namely the SSD drive, and 2.) MacMultiBoot which uses different partitions.

Server Side Initiation

Use the "DeployStudio Admin" utility on a server (in /Applications/Utilities).

Importing Computer Names from Apple Remote Desktop

Computer names for all Macs listed in ARD can be easily exported and imported into the DeployStudio repository, eliminating the need for the Deploy Studio setnames.sh script (which required all of the MAC addresses as input!). This proves very handy since the computer names are the stripped out MAC addresses and are used to create Active Directory computer accounts.

In ARD, select the "All Computers" list, click "File", "Export List". This will create a saved .plist which can be saved and imported to the DS repository (/DS/Databases/ByHost) Open DS Admin and click "Computers" in left pane, then click "Server" on top and "Import", choose the .plist export from ARD This will populate the Computers table with all computer names from ARD. Now a post-restoration task can be added to the workflow to change the computer name with the information from the database.

To Be Continued

Post Flight Installation

We have some things to change on each machine after it has a running OS (for example a script that change the time, print queues, visible Applications, and AD binding).

Security Updates

We can optionally cause (security) updates to happen, to handle updates that occurred between the time the image was created and when it was installed.

Accounts

We build our images to have at least one administrative account. For historical reasons we're using "cscfadm", instead of "cscf-adm" and "cscf-op". "cscfadm" can become administrator.

A Mac can optionally provide accounts via Active Directory. We do this for the teaching, and some ISG and/or administrative Macs. TBD: describe how to know For some non-teaching Macs, we provide local accounts.

AD Bind

This is done via ARD to run a script that is stored on empire.student.cs in /USERS/cscf-adm/Documentation/scripts/imacscript to either unbind or bind a machine to the AD. This is usually done remotely, by ARD running on a nearby laptop, with the binding script configured as an ARD "task". Some AD binding context can be found here: http://my.safaribooksonline.com/book/operating-systems-and-server-administration/mac-os-x/9780321591067/configuring-mac-os-x-to-log-in-using-active-directory/ch04lev2sec9 We currently use a modification of this DS bind script (modified from original by Bombich) http://deploystudio.wikispaces.com/ad-bind-login.sh AD binding is now part of the workflow for DeployStudio. Procedures and information can be found here: http://www.deploystudio.com/Downloads/Extras/DeployStudio_Guide_2.0.pdf

ARD can do this for multiple machines simultaneously, so in a lab setup, it's most efficient to do this step after imaging the entire lab. ARD can search a subnet for machines, which avoids the need to name each machine in a lab.

New Approach

The new location for the program, to be kept on all workstations, is /home/cscfadm/Applications/mac-bind-ad as described in ST #95442 It is intended to be run by a Deploy Studio workflow, although it can be run (by root) at any time (even if the machine is already bound). It will ask for a password for the account that has permissions to modify the CS-Teaching Active Directory.

Local Accounts

Only an administrative account is installed on the lab client image. This allows admins to login and modify settings on the client.

Other Methods and Tools

ASR (Apple Software Restore)

This can be used manually, from the workstation console. It is present on all machines (typically /usr/sbin/asr). It is used by Deploy Studio (at least). ASR copies a disk image to the local disk, from one of a:

• local disk
• remote HTTP(s) server
• remote multicast (via an "asr://" URL)

It can download to a file or disk volume. It can act as a multicast server. It can prepare a disk image for distribution. Is leveraged by DeployStudio

Disk Utility

The graphical "Disk Utility.app" (as opposed to the `diskutil` command), can "restore" a disk partition or disk image. It can do this via directly connecting the imaged and imaging machines. And it claims to be able to do it from a WWW server. * Does it use ASR ?

An External Drive

This is a specific case of using Disk Utility, with a drive rather than an entire being the source.

Carbon Copy Cloner

This looks to be a functional subset of Disk Utility. It too does disk to disk copies. We have an older copy, prior to it requiring a purchase. It's possible that it copies files, rather than blocks, and thus is slower than Disk Utility.

Bootable USB

If all else fails use a bootable USB memory stick to install a base image and then copy needed packages from the DeployStudio server once the base image has been installed. Use these steps in MacBootableUSB to create the USB key