Best practices in 2015: Managing settings in Mac OS X & iOS

To continue our best practices series for 2015, this time around I’d like to describe the methods for settings management.

This is focusing on the central management of settings for the Mac OS such as the login window layout, and for installed applications such as Microsoft Word or GarageBand although also includes iOS.

Why manage settings?

For some people reading this, you may wonder why you need to manage device settings at all. There are scenarios where you might not want to do this. If you are working on your own and are using a Mac, any settings you configure would be applied directly to the OS via System Preferences, etc., or within the preferences screens of the apps you use.
If you are responsible for multiple devices, from 3-4 to thousands, you will be interested (albeit from differing perspectives) in controlling certain settings from a single administrative point.
In an education scenario, there are often labs of shared computers that have lots of different people logging in. As the classes are time constrained, it is important that each new user logging in is able to launch the application relevant to their lesson with the minimum of steps.
You don’t want the user to launch Microsoft Word and have it present them with a series of questions about joining customer improvement programs and whether or not to automatically update. You just want to load the app so they can get to work. To achieve this, you need a way to manage the settings.
In a business scenario, device deployments are generally one-to-one so refining the individual app settings can be less important. You may, however, want to ensure that certain security settings are enabled, and stay enabled. Enforcing options such as GateKeeper, FileVault, and screensaver passwords and making sure that users either can’t switch them off is important.

What methods should you use to manage settings?

To configure most of the settings in Mac OS X, there are two core techniques, shell command / scripts and configuration profiles. It can be argued that it shouldn’t matter what technique you use as long as you achieve your goal, but it’s worth noting that most settings will be significantly easier to configure with one or the other.
You may notice that I am not discussing the tools you use to deploy these settings. These will be mentioned a little later on, so for the moment we are focusing on the underlying core techniques.

Why aren’t we including MCX / Workgroup Manager / Open Directory in this article?

We have been in a bit of a transition period over the past few years from something called MCX to MDM and configuration profiles. If you visit a school that had Macs installed 3-4 years ago you will typically find an Apple server running Open Directory (which holds the management settings) and Workgroup Manager (an app that lets you configure the settings).
Apple has been pushing the use of configuration profiles since the release of 10.7 (Lion) and has now dropped support for Workgroup Manager so it is safe to say if you are working out how to manage settings in 2015 (or later), you won’t be using Open Directory and its associated tools.
The last reason is the lack of iOS support. It is becoming increasingly important to control the settings for all Apple devices, which is the key reason Apple have replaced Workgroup Manager with Profile Manager.

Features you need to include when implementing your management system

There are a few features you need to think about including when you are looking to manage settings on your Apple devices.

  • Ability to switch them on and off – You will want the ability to switch these settings on, but you should try to pick a mechanism that will allow you to switch them back off should you need to
  • An ability to push the settings at any point – Where possible, pick a method that allows you to push the settings, not just at the point of initial configuration, but to already deployed devices
  • An ability to adjust the settings after deployment – You may need to adjust the settings once they have been deployed so try and make sure the method you are using can do this
  • An ability to exclude the devices from the scope – You will likely deploy the settings to groups of devices. Make sure you have the ability exclude devices from the scope (and thereby remove the settings) should it be needed
  • An ability to check the success / failure status – You will need to know that your settings have been successfully deployed, or re-deploy if there is an error with some devices.

It’s not always possible to include all of these features with some types of settings but on the whole if you can tick all of these boxes it will be useful later on.

Manage settings with terminal commands

One very popular method to control Mac OS X settings is to use terminal commands. There are lots of examples in the previous blog post “Creating your first boot script”. You can either run individual commands or (as in the first boot example) group a collection of commands into a shell script and push it to your clients. Reversing or adjusting the settings post-deployment would be a case of pushing the altered scripts to the necessary machines.
There are, of course, a few drawbacks with this approach:

  • This is for Mac OS X only
  • In many cases, this is a harder skill to learn (compared to GUI configuration profile tools)

A note about preference caching in OS X

Some of you will have heard of preference caching in OS X. This feature, introduced in newer OS X releases, caches settings stored in preference files. This can interfere with tools that edit preference files directly like the defaults command.
This being said, there are lots of terminal commands that are still very useful, and difficult to replace with other methods, such as enabling Apple Remote Desktop, sysadminctl to create user accounts and systemsetup to set NTP server details.

Getting your terminal commands & scripts deployed

Once you have the commands written into a script, you will need a way to deploy them. Depending on the site, we normally use either the Casper Suite from JAMF Software, which can trigger scripts at login, logout, start-up, recurring check-ins (to name a few), or we use payload free packages (Apple installer packages that run a pre or post install script). With a payload free package you can use other tools like Munki or Apple Remote Desktop as a deployment tool.

Configuration Profiles

The second option for managing settings is to use configuration profiles. These are specifically formatted XML files that contain (amongst other things) a settings payload that can control settings in OS X and iOS. Many popular MDM services like Meraki and Casper have the ability to create and deploy configuration profiles using a simple GUI interface.
A nice feature of configuration profiles is the ability to control custom preference settings in OS X. As they are XML files, you can create them in plain text editors, loaded with the settings you need to enforce. In some MDM products, you are able to upload your customised preference files directly from OS X and have them convert into configuration profiles ready to deploy.
Configuration Profiles are also able to avoid the issues experienced by preference caching.

Getting your configuration profiles deployed

When we have created our set of configuration profiles, we again either use Casper’s built-in MDM functionality or the new abilities built-in to Munki to install them.
You can use most MDM services to deploy the profiles, just bear in mind that some simpler services like SimpleMDM and the free version of Meraki don’t support custom profiles.


For anyone tasked with managing groups of Macs, large or small, getting to grips with settings management is a must. If it is something you’re considering, I would recommend either terminal commands or configuration profiles.
If you’re looking at using defaults commands (or similar), see if it’s possible with a custom configuration profile to avoid issues with OS X preference caching.