Casper Image (Composer) vs Mac Disk Utility (New Image)

[lee_smith]

Hello Community,

I am new to Casper and this community. Our primary engineer accepted a position with another company and I have taken his position.

We are gearing up for summer projects and I am currently building a Mac OS X image. His instructions suggested we use the Mac Disk Utility instead of Composer to build the image. I am curious as to why.

I look forward to hearing from you all.

[Josh_Smith]

I think the majority of admins here would say that neither of those options are ideal. Imaging is a broad topic with many possible solutions, a great place to start is with this presentation from last year's JAMF Nation User Conference (JNUC): Unwrap the Imaging Enigma

[Sandy]

Hi Lee!
Welcome to the Nation :)
For another perspective:
I use Composer for all packaging and image creation tasks and for our needs, everything works!
Mine is a K12 environment with 1800+ workstations from 2010 and newer, and about 2300 iPads.
I use net boot for re-imaging student computers, and have shifted over to a "no wipe" layered buildup for new OSX devices.
Sandy

[dpertschi]

Do you NEED a fully configured and updated, snap-shot-in-time, single file, old fashioned fat disk image? If yes (and there might be a few fringe use cases that this is still reasonable) then use Composer. It's got some basic built-in logic to ignore and omit some junk, Preferences > Exclusion List.

If that's not required, do some goggling on thin imaging.
- Get a copy of AutoDMG to create a base agnostic image from the "retail" App Store OS installer
- Get a copy of CreateUser to create a package of your preferred local admin account
- Get a script or package that suppresses iCloud and Diagnostiscs popups

In Casper create a new imaging Configuration, add those items and your ready to start adding in additional packages and scripts that will define your desired result (image).

There's a lot missing here, it's a huge subject, but you'll learn fast under the gun.

[davidacland]

Between the two I would say Composer would be a better choice, as it a bit more designed for creating OS deployment images. Disk Utility is more of a generic tool for creating disk images for any purpose.

That being said, if you're starting to learn a process for creating deployment builds, I would also endorse a thin deployment system. Once you get the hang of it its much more beneficial compared to monolithic imaging.

[bpavlov]

You have a great opportunity here to really learn best practices. Question everything your predecessor did (not because he may have done things wrong, but just to find out if things can be done better).

+1 for @dpertschi 's suggestions.

Except I would argue to not use imaging configs and let Casper deploy the software on first boot! This is what I'm working towards. It doesn't make sense to maintain not only policies but also imaging configurations each time you upload a package. But you'll figure out what you want to spend your time on and how to make things more efficient as you get more familiar.

Also this blog is a good resource. And in particular this post will point you to some of the more popular tools out there: https://derflounder.wordpress.com/2015/02/04/free-tools-for-the-budget-minded-mac-admin/

[Sysops]

oops, wrong account

[htse]

you should also consider that it could just be a personal preference slant more than a technical reason. Previous experiences, outdated issues, personal preference…

[bentoms]

@lee.smith welcome!

Just to add my 2pence worth, I've blogged my imaging workflow

I'm guessing your colleague was preferring Disk Utility over Composer due to the Recovery Partition. But that's resolved with Composer 9.7 & Composer will also do some maintenance tasks on the captured OS.dmg too. So I'd give composer the nod.

[Chris_Hafner]

Yep, situation + preference. I'm a composer fan. Mostly because there are a number of things I need to do to a booted OS before distribution for imaging (performance) considerations. However, some find it a bit more consistent to use never booted OSs (Such as those created with AutoDMG) and then script any specifics before adding packages. User/Management accounts and recovery partition distro are pretty easy now-a-days.

[RobertHammen]

I love the modularity of the AutoDMG approach... if you spend a lot of time manually managing/changing settings on a base OS, you'll save yourself so much time if you can make those changes via packages/scripts. Modular is the way to go, again, assuming you're doing traditional imaging. Thin imaging (leaving the OS that ships on a new machine, and just enrolling/installing software/changing settings) is another great approach. Depends on your environment and your needs.

[lee_smith]

Thank you all for your responses. Gives me a lot to think about and learn.

Thank you!