What do you prefer: Image creation methodologies.

I've been doing a bit of a mix. I usually make my Base OS from InstaDMG, but I layer the Apple Updates in using configurations in Casper Admin. I then compile my Base OS and have smart configurations based on that with additional components.

The only thing I still use the Golden Master style of imaging is when I create new NetBoot images. Mostly because of the quirkiness of getting MCX to apply to a NetBoot image that will only startup once to be used for troubleshooting and imaging computers.

My preference for the longest time has been to use InstaDMG to build an up to date flat image with all current patches in place into a disk image that has never been booted, avoiding the "cruft" as Miles Leacy puts it in his writeup of InstaDMG:
https://jamfnation.jamfsoftware.com/discussion.html?id=502
While the grouped folders and compilation of python scripts in InstaDMG are less sophisticated than a dedicated set of binaries in the JAMF tools, I had better luck early on with InstaDMG so have stuck with it.

When I started using InstaDMG I put those images directly into the JSS, and kept moving forward. I had some bad luck with using compiled JAMF workflows to build an updated, clean, never-booted image, so never really got a good handle on it.

I found interest recently in the compiled JAMF workflows again, and am curious as to what the wealth of experience here in this forum has to say on the matter.

in my current gig, i use instadmg to bake a base, then apply the rest with policy via casper.

in the past, i used a combination of instadmg/deploystudio and munki. if all you need is the thin imaging approach, you can cut out instadmg/composer and just stick to casper policies or munki to bring your hosts into a managed state.

i don't recommend the "golden master" method, as it's way too much work. keep it modular, and you can use a range of different tools to deploy.

We only build a base image once a year, and then we deploy it via various compiled configs to all of our machines every year.

We use the 'Golden Mater' as it's always worked well for us with little effort. I don't think it takes very long at all, but I guess I am working on other things while the OS does the initial install/combo update, etc.

What I like about making sure that a base has only OS and the config has the rest of the Apple updates is that you have a very good idea of what Apple updates you've applied beyond the OS by just looking at your configurations.

I'll probably move to just putting the InstallESD directly into Casper Admin and using the third method. I mostly use InstaDMG to create a base because I'm used to it.

What makes creating a base so easy these days is that InstallESD.dmg for 10.7 (and presumably 10.8) come directly from Apple and are updated on the App Store very quickly after a combo update comes out. This removes a lot of the QA I had to do with using an InstaDMG build train and combo updates.

i put the installesd.dmg file into casper admin. i don't compile anything- apple patches are installed as individual packages during imaging along with everything else that's part of my SOE. That way I can replace any patches with new versions without having to re-compile a base image.

2b - Compiled Image via JAMF Config using InstallESD
https://jamfnation.jamfsoftware.com/discussion.html?id=3841

By doing it from InstallESD, you'll get;
1. Recovery partition created automatically.
2. Fresh never booted image ready to deploy to any model.
3. No need to install and capture images (saves a lot of time!!!)
4. Clean image - assurance of getting a fresh image every time.
5. Easy to maintain.
6. Fully modular approach.

Most people putting the InstallESD.dmg into Casper Admin seem to compile the image (or part of it) as a matter of course- is this purely for the speed that block copying gives you or is there some other benefit?
I ask because I'm still in development, so I'm making frequent changes to my image and skipping the compile step after each tweak saves me appreciable amounts of time. I appear to get the same results from my builds whether I compile them or not- the only difference is the time it takes to lay the image down onto the machine.

I just switched from 1. to 2. this year and couldn't be happier. I love how the image InstaDMG outputs has never been logged into. The peace of mind of knowing there's 0% chance of a human having touched the image and done something wrong or forgotten to include a step is well worth the learning curve of InstaDMG.

I would really like to see InstallESD solution in Casper base image creation instructions.

I agree with Kurt. I used to do golden master but now I listen to the community and tried InstaDMG. I couldnt be happier with it :)

I'm a big fan of 2c variant as so:
InstaDMG + DeployStudio (typically using a meta-workflow)

Here's why, in order of priority:

InstaDMG
No justification needed. (bonus: 10.8-ready)

Rapid turnaround for small tweaks
DS affords a huge deal of flexibility and, since it's never monolithic (beyond the InstaDMG base, which for myself currently only includes Apple's own updates, full stop), the turnaround time for an image update is a bare minimum. New version of Flash? Replace the pkg in the thirty-some-odd-module pkgcore workflow, which is called by my production build meta-workflows. One change. One minute. Unaltered pkg straight from Adobe, pulled from Install Flash.app.

The power of the One

"I'm a big believer in 'the One'." -Rich Trouton, PSU MacAdmins 2011 modular deployment session (different context, but the same goal--that being simplicity)

I've got a lot of image deployments taking place every day, rarely by me, and sometimes by people who barely touch Macs. Since my org keeps it simple for those resources with only one NetBoot environment with a full OS (for tasks like full-disk backups to some NAS share before imaging, troubleshooting via DiskWarrior, etc.), we pop DSRuntime into the NBI and have it launch at login, and prompt for Kerberos credentials.

They select the only workflow that's visible to them and that fires off some logic which chooses the appropriate meta-workflow.

One NetBoot image. One workflow. Simple. And beyond being good UX--and perhaps more importantly--the less expertise required of the hands-and-feet carrying out these tasks, the more of a raise the sysadmin can justify.

(Of course depending on your org's size/needs and IT structure, this might not be a priority, or may even fly in the face of your org's priorities.)

Speedy deployment
GigE at the desks (should you image at desks) or imaging points (if not)? I haven't found anything that from bare metal to fully-deployed-and-configured faster. NetRestore would beat it, but that's not modular. NetInstall is, but that'd move away from my "the One" Netboot environment.

Separation of Church and State
I never really liked church, and I'm not what you'd call religious, but I'll go to hell if there is one because I'll drag my kids there so they stay in line when nobody's watching.

I'd love to scare the hell out of 'em some other way, but "Church it is!" says the wife, who rules my life. She won't give me what I married her for if I disobey. (Hint: my "wife" is actually my boss, and I "married" him for the money. I'll admit it. And when he reads this, I'll be sleeping on the couch.)

JSS is church. My Macs go to church every 15 minutes. The church didn't hand out their SSN or their birth certificate. If the church did, it'd take more time; it'd want to baptize it first.

DeployStudio's a bit different. It gives babies all their paper bits before the afterbirth is even wiped clean (e.g. before a user folder's ever created, in my case anyway). And its parents--the techs deploying the systems, in case my rambling's left you lost--can't even touch the thing until that's all wrapped up, in a nice lil blankey and cap, courtesy of DS's Finalize.app and the inability to get loginwindow until it's alllll done. Don't. Touch. theBaby. Not yet.

That boot chime? ...the one after Finalize.app and ds_finalize.sh do their thing? That's the baby's cry after Dr. DS sucks the amniotic fluid out of a Mac's fans and smacks its raw aluminum ass. Here Mom, now you can hold it.

Its papers? /var/log/ds_finalize.log, perhaps mailed to MacEng at first (true) boot, or better yet, shot off to a repo that's scraped for errors, to weed out only the papers worth checking out. Straight to the dictator they'd go. (I'd rather be a dictator than a priest. And if you think this post is long, you should read the subtext!)

Plus, if I need to reorganize the government, I don't need to worry about interrupting the Pope, his Bishops, et al. They've got their services to worry about--2,000 parishioners, every15. (read: when you compile a new configuration, watch how hard your JSS gets slammed in terms of network traffic from the sole Mac you're running Casper Admin on. I sure hope those going to their every15 church can still nom on their christybits.)

Transparency
If I need to hand it off, it's as straight-forward as my module components' (mostly pkgs, a couple scripts) names and, if necessary, associated sharepoint documents, are.

And after calling my boss my wife, I'll probably need to hand it off soon.

At least he's not Catholic.

For all of you InstaDMG fans, how are you handling the recovery partition?

if people need the recovery partition, i have a self service policy adds one via apple's recovery partition update. the pkg dumps the update dmg to /tmp, then uses the enclosed tools to create the slice, and cleans up after itself.

the post flight is here: https://gist.github.com/2769796

@thisisdave, That was the best thing I have ever read regarding JAMF or software deployment. I'd like to sign up to receive your newsletter.

Dave, that was rather compelling.

I'm thinking that if you held a seminar at the local convention center, that I'd be chugging your juice, buying the uniform and handing you my checkbook with a glassy eyed nod on the way out the door!

I use a Robert Hammen-style thin imaging setup for new employee machines.

Lab computers get a golden master reimage once a year (it's fast, uncomplicated, and effectively captures every setting I need). Then at winter break, they get a JSS-drive update (new software as required, adjusted settings, etc.).

I'm bumping this since it seems like a pretty good discussion and I'm stuck at a fork in the road.

We're moving from a monolithic image with everything baked in to more dynamic, build on site, imaging process as we transition from OS X 10.7 to 10.8. We have a variety of hardware types (Airs, MBP's, mini's, iMacs, Mac Pros) all from a variety of years and there's a variety of each on each segment. Everything that JAMF wants me to do says to package a recovery partition for our FileVault 2 use, but using the InstallESD.dmg file does all the dirty work for me and does it relatively quickly.

I just wanted to throw my 2¢ into this and get some feedback from others regarding their workflows. Everybody seems to be doing something different, but is everyone really packaging out a recovery partition for every single model you've got floating around? This could be leading into another, new, thread, but it seems like this discussion was right up the alley that I am standing in.

InstaDMG automatically creates the recovery partition no messing about with configs or scripts to create a recovery partition in Casper admin.

Grab the never booted dmg and chuck it in Casper admin, add to configs and that's it.

I listened to guys here about InstaDMG and I'm really glad I did. It made me feel embarrassed that I did monolithic imaging for so long.

You don't need to create recovery partition packages for each model, just each OS. I use Greg Neagle's method:

http://managingosx.wordpress.com/2012/08/15/creating-recovery-partitions/

If I have to re-image a machine, I have a config that drops the OS on, then the apps, and finally I drop on the correct recovery partition. It's worked like a charm every time I've used it.

Don't have to do anything if you use InstaDMG. Sorry but no contest ;)

We create our image once a year and then lock it down, update afterwards during the year

1. install the OS on an external booted drive,
2. do basic modifications, apply all current apple updates, create local accounts and setup basic settings, remove any unwanted apps or desktop pictures etc, as little editing as possible
3. create a base image using Composer, test
4. create all the extra additions via packages, drivers, growl, web browsers, media apps, utilities, java, flash, all the core apps such as office, CS6, and test all packages individually, create scripts to apply modifications as required and test 5, Create different configurations with the base os and different packages and scripts, printers, directory bindings etc, then test, then do Compiled Configurations as its much much faster to deploy

The image is then locked and never recompiled.

During the year apply any new patches, software updates etc via Post Imaging polices (via a script in the image that at reboot checks for polices with the tripper "ReImage"

Also create smart groups for computers without certain updates, and then create policies to install these updates when missing.

My point was just that you could use Greg's tool to keep one or two different recovery partition fixes on hand instead of doing one for each model.

Besides, you've been around here long enough Tim to know I'm a huge fan of InstaDMG. ;-)

sure do Steve :)

Thanks for that i will check out Gregs tool. Its always good to learn something new ;)