Twelvetide, Day 5: Replace a Legacy Practice

This is the fifth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Version Control”)

If you have been doing Apple Administration for a few years or more, you will appreciate how quickly the environment is changing. The amazing rise and popularity of iPhones and iPads ahve forced Apple and Apple admins to revisit many aspects of management. Not only has Apple drastically advanced the MDM spec (though I would still argue it is far from complete) but Apple administrators have developed and publized many new practices.


It is not that long ago that “monolithic” or “golden master” imaging was the most common practice to preload Mac with the OS, applications and configurations. However, there are many issues with this setup as it is very hard to prepare and even harder to manage and update once it is deployed. Apple likes to introduce new hardware with specific OS builds, and you would have to re-build your entire image for new Macs.

The next step is what I call “thick imaging” (the names for Imaging are not used consistently among Apple admins). This involves build a large monolithic image with tools such as AutoDMG, CasperImaging or FileWave Lightning. This will create a never booted, hardware independent (except for those pesky new macs with new specific OS builds) image. Getting the process to build this “thick image” with scripts, configuration profiles and package installers can be very tedious. However, once you have the workflow. You can re-create new images after a software update quite easily. When you use target disk mode over Thunderbolt or USB3 you can re-image huge images very, very quickly. Use this practice when you need to be able to re-image machines fast, like in a classroom or laptop loaner setting.

Next more advanced step is “thin imaging”. Here an admin will lay down the base OS and install the client software and configuration needed to connect to a management system. (Munki, Jamf Pro, Filewave, etc.) Then the management system takes over and installs all necessary configuration and applications or provides them as optional installations to the user.

You can either find a way to install the management client on the existing OS (Target Disk Mode, Recovery HD) or create a base OS (like thick imaging, but just the management client settings) and lay that down with NetInstall or disk-to-disk imaging.

Finally, with MDM and Apple’s Device Enrollment Programm (DEP) you can give up on ‘imaging’ entirely. When a Mac enrolls into an MDM service, client software for a management system can be installed and take over more installations and configurations from there. When a device is registered with DEP at purchase it will be enrolled with your MDM automatically at first boot and after every clean re-install.

This is likely the way Apple wants to move the macOS management strategy in the future. It is after all the only option with iOS.

Other Legacy Practices

Local MCX

It used to be a great trick to put enforced configuration settings (MCX) into the local directory (where the local users are stored). At the time this solution was introduced it solved a few problems for which there was no other solution. Now, Configuration Profiles, wether pushed from an MDM or installed locally solve those problems. You should be moving all settings that can be managed to Configuration Profiles. And you should file bugs with Apple for those settings that cannot be managed with Profiles.

Login Hooks

While login hooks still work with macOS Sierra they have been deprecated for a while now. The modern supported alternative is to use Launch Agents. Thankfully, you do not have to re-invent the wheel and build launchd property lists for everything, but you can use outset instead.

Capturing Files for Installer Packages from Disk

Composer encourages this practice by default. However, there are many pitfalls with this. When you can, you should install or build packages directly from the disk image or archive downloaded. Capturing files should be a last resort for truly horrible installers, not a common practice.

You can read more about building proper installers in my book “Packaging for Apple Administrators” is on sale!

Leave a Reply

Your email address will not be published. Required fields are marked *