David Acland, Head of Amsys Consultancy, describes the 4 primary Mac deployment methods, including: - Monolithic (traditional) imaging - Modular imaging (base OS image + packages and settings)\ - Thin imaging (just packages and settings) - User self-service

1. amsys.co.uk http://www.amsys.co.uk/2014/blog/4-mac-in-the-enterprise-deployment-techniques/#.VIbPumSsVUE
4 “Mac in the enterprise” deployment techniques
David Acland
Posted by: On Wednesday, December 3rd, 2014 - Blog
There are a number of ways you can deploy Mac OS X. The tools and
techniques used have evolved rapidly over the past few years. In this blog post I
will summarize each deployment technique, explain our view on scenarios where
you would use one over another and how new options such as DEP have moved
things along.
The main methods we will discuss are:
Monolithic (traditional) imaging
Modular imaging (base OS image + packages and settings)
Thin imaging (just packages and settings)
User self-service
1. Monolithic (traditional) Imaging
This method has been around for some time. Back in the heyday of NetRestore, this was the cool new way to
deploy Macs (iOS didn’t exist!). You would get your hands on a model Mac, typically the highest spec that had the
most hardware features, install all of the software packages you needed and configure machine level settings,
such as the Login Window layout and sharing preferences.
Once you were happy with the setup, you would create a disk image of the hard drive using hdiutil, disk utility or
another tool, scan the image for block restoration and then deploy it to the rest of the Macs that you needed to set
up. The end result was a set of identically configured Macs so from that perspective it was a working process.
The downside, however, is when you either spot a problem with the configuration or an update is released just as
you finish. I had lots of situations where I would spot a minor imperfection in the image, meaning hours of work to
deploy the image to the model Mac, correct the flaw, and then create a new image.
Each time I did this, the chance of unwittingly introducing a new flaw was high. Updates being released just as
you finished rolling out the image happened a lot as well. There was nothing worse than creating your great new
10.2.3 OS X image with everything just as you need it, only for Apple to release the 10.2.4 update the next day.
This obviously brings up a flaw with the patch management processes, which were often non-existent.
We could, of course, add in a software update server to handle the Apple updates but what about Office,
database apps, Silverlight, Flash, etc.?
In many cases, organisations just froze in time. They deployed their image, and that was it until the hardware was
due to be refreshed. Good from a change management point of view, not good from a functionality or security
standpoint.
2. Modular Imaging (base OS image + packages and settings)
Modular imaging has also been around for a while, although adoption has been slower. The basic idea is to
separate out each part of your intended build into a base OS (with any necessary updates), the applications the
users need, and finally any settings you would like to be configured from the start. Each aspect of the final build is
stored as either a package installer or a script that would run when the target Mac first boots.

2. There are three key benefits to this approach:
It’s easier to update or fix one part of a build than recreate the whole thing
It’s easier to update part of the build if a patch for a particular bit of software is released
You can create multiple “workflows” without having to store multiple monolithic images
For these reasons, you would assume this would always be the preferred method over monolithic imaging. So
why has adoption been slow?
The first (and probably the main) reason is an increase in technical difficulty. When you’re creating a monolithic
image you can ‘see’ what you are doing, it’s just like setting up a normal Mac and then taking a snapshot of its
state. With modular imaging, you have to learn a few new skills including scripting and software packaging.
The second reason is that it’s newer. There are some techs out there that know how to create a monolithic image
and are happy with the results. And, from a time investment perspective, they don’t want to spend time learning a
new way to achieve the same goal.
At Amsys, we switched to modular imaging a few years ago and saw the benefits almost immediately. Once we
had worked out how to package some of the trickier apps and some of the scripts that were needed we could
create customised builds for our clients in much less time.
3. Thin Imaging (just packages and settings)
Thin imaging is one of the newest techniques. It is quite similar to modular imaging, just without an OS. The
assumption here is that Macs from Apple come with a perfectly good, pre-installed OS, so why spend time wiping
it, only to put the same thing back on the machine before adding the apps and settings.
With thin imaging, you take a Mac out of the box and run a workflow that installs the apps you have packaged and
adds any settings that you need.
Some of the benefits for thin imaging are:
Time saved as you aren’t capturing / packaging a base OS
Time saved as you aren’t deploying an entire OS
You are less likely to introduce issues by replacing the OS (incorrect hardware extensions, etc.)
With this style of imaging, there are some other added benefits. For example, you can take a machine that has
already been set up by the user and deploy your company apps and configuration to it. As you’re not wiping the
drive there isn’t a risk of upsetting the user by deleting all of their data!
A potential negative, however, is the lack of a proper “imaging” option. “Re-imaging” has long been seen as a
way to eradicate problems from machines as it can return them to a known working state. As thin imaging only
adds to the target machine, it wouldn’t be a suitable option for removing a pre-existing problem.
This being said; thin imaging and modular imaging can co-exist together. At Amsys, we quite often setup both
options. Once we have created a modular imaging workflow that can lay down an OS, it is only a few minutes
work to create a separate workflow that performs all the same actions, just without a base operating system.
If the option of erasing the machines is a requirement, but you’d rather not “re-image” in the traditional sense, you
can create an OS X installation package using a tool like createOSXinstallPkg. This script generates a package
that can be installed as part of your thin imaging workflow, but performs a standard OS X installation. If you
include a step to erase the target drive before installing, the result will be very similar to a modular build.

3. 4. User self-service
The final deployment method I would like to talk about is user self-service. The first three methods I have
described are quite similar. Some of the tools and techniques are different, but the underlying processes are the
same, as are the results.
User self-service takes a different approach entirely and simply provides a mechanism for the user to install the
apps and settings they need. Some organisations I have worked with that have very large numbers of Macs
(usually over 1,000 devices) are using this method. It could be that it took that quantity of machines to force them
to think of more efficient ways to get the machines out to the users.
One of the major benefits is the lack of IT involvement. The IT team need to ensure that the catalog of packages
and settings are tested and functional, and that there is a simple way to present these to the users (such as JAMF
Software’s Self Service), but once this is done, the user only needs to enrol their device, launch the app and
choose what they need.
This can be extremely handy if a user is in a remote location. If they have a major hardware breakdown, they can
go to their nearest Apple Store, buy a new Mac, enrol with the management system and open up Self Service to
get going. No IT involvement needed.
With Apple’s DEP ( Device Enrollment Program) now, the users don’t even need to enrol. They unbox their new
Mac, complete the setup assistant and they are ready to go.
Conclusion
There are some projects we have been working on recently that I simply couldn’t imagine finishing without some
of the newer deployment methods. Tools like Casper and Munki have created some new and interesting
workflows that are really helping to reduce the manual effort needed to deploy large numbers of machines
consistently.
While monolithic imaging is rarely used, I couldn’t really say that any one of the other techniques described are
the best, it really just depends on the scale of the deployment project, the location of the devices and users and
what you want from the final setup.

4. If you are thinking about deploying a new fleet of Macs or iOS devices and require Apple consultancy or advice,
please contact our expert team today. Call 0208 660 9999 or email support@amsys.co.uk.
Share this post online: