Guide to image creation

[#1]

I would like to query the community on a definitive guide to building Mac OS X images and perhaps how JAMF can make that process easier. I believe I can easily toss packages unto the backend of images but I am looking for the process that precedes that step.
What I hope can happen is that I toss a 10.6 install media (or latest build media) into some JAMF application, give it the local admin account I desire, then most of the settings and applications, then binds to AD/OD and Bobs my uncle. Conversely, I am cool with building an image with a new machine, update it fully, install Adobe junk, then make some application create an image of that machine in a fashion that can easily be deployed and have packages installed to.
So would someone please point me in the right direction and/or provide some best practices?

Thanks in advance.

[tlarkin]

There are many ways to accomplish the same goal. I don't put any user accounts in my image. I do all of that post image shell scripts. For my deployment I do following, in basic terms:

1) create one master image, with all default apps that every Mac should have period, compiled via instaDMG support in Casper 7

2) Package all extra specific packages for users, groups, departments and so forth

3) Create smart configurations based off my base compiled and add in the packages needed.

4) Image the client with an asr script to allow the compiled as a base

5) after imaging all specific packages (student, teacher, admin, etc) get applied

6) unit reboots, gets proper bind script (depending on location) and post image script which adds client side settings and configures and creates local admin accounts

that way I maintain everything separate. If I update the compiled image it doesn't affect the user accounts. If I want to change the local account passwords or usernames it doesn't affect the image. It really just depends on what you want to do. If you have the HD space on your servers you can just compile every configuration and be done with it, if you wanted to do so, and that wouldn't really be the wrong way of doing it.

[#3]

Tim,

You're on the right track here..

You can create a "base image" a couple different ways.

1.) You can install a base OS from the OEM DVD on a machine (preferably the
newest Mac hardware available to you..). Once you have that configured you
can then take an OS Snapshot with Composer. With this method you can setup
an admin account right in the base config before you take the snapshot.

2.) Create a .dmg from the OEM Install DVD using "Disk Utility", and then
uploading it into Casper Admin. (See page 135 in the Casper Manual). This
step is somewhat quicker as it cuts out the time of installing and
configuring a base setup. If you use this approach, you can setup the local
admin account with the "base config" you will configure in Casper Admin.

Once you have you're base configs set, just drop in any other apps/settings
you wish to deploy and life should be good!

-- Jason Weber
Certified Casper Administrator
Technology Support Cluster Specialist
Independent School District 196
jason.weber at district196.org

[talkingmoose]

I'm sure you won't get a "definitive" guide because no one solution fits
On 4/26/10 8:43 PM, "Tim Winningham" <winningham at math.ohio-state.edu> wrote:
all.

You can drop a Mac OS DVD .dmg into Casper and use that as-is (a la
InstaDMG). I suggest doing this as a first step no matter what because just
about everything else can take advantage of it.

You'll fall into one of these groups:

1. A few configurations and a few machines.
2. A lot of configurations and a few machines.
3. A few configurations and a lot of machines.
4. A lot of configurations and a lot of machines.

Creating compiled configurations is great where you have lots of machines
that share the same configuration. A compiled configuration is a monolithic
disk image with the OS, all applications, preferences, etc., that can be
block copied to a new machine. It's much faster than installing a
configuration that's not compiled. The trade-off is this takes more storage
space and it takes more time up-front to create. One change to the
configuration means having to re-compile.

Using non-compiled configurations is great where you have few machines
sharing the same configuration. You can quickly add an application or
preference file and image a new machine immediately. Because the OS is
installed rather than block-copied, this takes more time per machine. The
trade-off is this takes significantly less storage space and you can make
configuration changes quickly.

Adobe applications are a PITB but Casper has made them easier to install.
However, there's a gotcha. You cannot include them in a compiled
configuration. They must be installed after imaging. This is a limitation
imposed by Adobe's install method.

If you really want to take advantage of compiled configurations then you
could probably compile everything except the Adobe apps and then move that
compiled image into the Packages folder as a new "OS" image. Create a new
configuration with this compiled image (priority of "1") and the Adobe
applications after that. Casper takes care of creating an admin account for
you if you set it up properly in the configuration.

For our situation (a lot of configurations and a few machines), I create a
compiled image of our Restore partition and then image everything else using
non-compiled configurations.

One more best practice that I suggest: Make separate packages for a)
applications, b) application preferences and c.) application serial numbers.
This takes more up-front work but the result is that you can manage
different preferences per group, use less disk space and you can manage
multiple serial numbers. Again, this applies more to those who have a lot of
configurations.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492