May 05, 2014 Only with the next update to OS X, usually a point release (that is, 10.9.x), are the two versions of OS X (the retail one, available on the Mac App Store, and the modified one that the new Mac uses) “merged” back together into one unified version. Apr 06, 2015 Recent releases of Mac OS X have made it even easier to. Although AD and command support in OS X make. On managed devices and push enterprise apps and ebooks to Mac computers. Apr 06, 2015 Recent releases of Mac OS X have made it even easier to. Although AD and command support in OS X make. On managed devices and push enterprise apps and ebooks to Mac.
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.
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.
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.
Os Deployment Software
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.
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.
For larger sites I would look at http://www.deploystudio.com/ this is best setup with an OS X server for netbooting (a tiny bit like PXE boot) and deployment over the network. However you can setup as disk based solution but it maybe easier for a non Mac tech to use something like Carbon Cloner (www.bombich.com) which is really easy
With Macs you generally dont have to worry about drivers and platform specific software. Providing you are using an OS that shipped at the same time or later than the hardware was manufactured it will contain everything required
Mac Os X Deployment Tools For Enterprise 10
So if you have an iMac from 2016 you can install 10.12 onto it and ostensibly use the same image as another later 2017 iMac. Of course the correct thing to do is make a master per hardware type, thin install and then drop the apps etc you need onto it...