Configuring Mac Settings: MDM, Configuration Profiles, or Scripting?

When it comes to managing Mac computers, there are several ways IT teams can configure their settings remotely. 

The first and best way is to use an MDM solution (such as Kandji). If your MDM solution has a box you can check or some other simple way to implement a setting you want to manage, that’s the best way to do it.

However, that might not be an option. Your MDM solution might not support every setting that's available via the MDM protocol. Or the setting you want to change might not be included in that protocol, so no MDM solution could configure them. (The best way to determine if a setting is configurable by MDM is to check out Apple’s Device Management documentation.)

In those cases, you have a couple of alternatives. For settings that are covered by the MDM protocol but aren't available (yet) in your MDM solution, you can create and deploy a custom configuration profile. If that isn’t an option, you can roll up your sleeves and write a script that uses the defaults command.

While these two workflows have some similarities, they function in different ways. Here’s how they compare, how they differ, and when and how you can use each.

Configuration Profiles (.mobileconfig)

Configuration profiles contain settings and store information. In fact, when you adjust endpoint settings in your MDM solution, it creates and deploys configuration profiles to make those changes happen.  Unlike plists, config profiles can configure iPhone, iPad, and Apple TV devices as well as Mac computers. 

When such profiles are applied to a system, the settings they configure are locked and cannot be changed by the user. This is helpful when you need to make sure of specific settings on endpoints, regardless of what users do—to meet security compliance requirements, for example. 

You can create or edit custom configuration profiles with specialized apps such as Apple Configurator or iMazing Profile Editor, or using a general-purpose code editor. That work does require some fluency in the mobileconfig format and detailed knowledge of the settings you want to enforce.

While configuration profiles can be manually installed, they are more commonly pushed out via MDM. (Here's how to deliver them in Kandji.) This allows for easy deployment to large numbers of devices all at once, reducing configuration time for the administrator.

Scripting with defaults

The other option is scripting—or, more accurately, writing scripts that edit property list files (more commonly referred to as plists) using the defaults command. Many settings for macOS, as well as for many apps, are managed by plists. 

One advantage of property lists is that they can be written and rewritten indefinitely. This means admins can use them to preconfigure settings for devices but still allow the user to change those settings themselves later. That flexibility can be an advantage or disadvantage. Sometimes, you want users to have that kind of control. But for other settings—such as those that configure security features—you really don’t.

Also, plists don’t always take effect immediately; if you’re pushing out a critical setting, config profiles are better.

When trying to configure a particular setting via script, you first need to determine which plist file contains the key you need to set or change. 

You can start by simply searching for the file manually: Most often, it will be in the ~/Library/Preferences folder. Another common location is ~/Library/Containers/[name of app]/Data/Library/Preferences. In many cases, the name of the plist file will tell you which settings it controls. One thing to keep in mind is that an application might store settings in other locations (such as   ~/Library/Application Support) and not in plist format at all.

Sometimes looking for the file where an application stores its settings can be like looking for a needle in a haystack. To make your life easier, you can use the File System Events (FSEvents) system built into macOS: When you change the setting on a test Mac, FSEvents will record the files that changed. You can then target those files for editing. Alternatives: Do a quick Google search, or consult a handy webpage such as the macOS defaults list.

Once you’ve identified the plist file to be changed and its location, you (or your script) can use the defaults command-line tool to edit it. Using defaults doesn’t just edit the property list file. It also informs the macOS preference system that something has changed. If you don’t use defaults,  the system might not pick up your changes, or it might overwrite them.

Before you deploy a script that edits a plist file using defaults, make sure you check the commands first on a test Mac, to be sure it does what you want. Once you've done so, then you can roll that defaults command into your script. (If you need a refresher on that process, check out our guide to Mac shell scripts.) You can then deliver that script via MDM to run on endpoints. (Here's how to deploy custom scripts in Kandji.)

Plist vs. Configuration Profiles

As an illustration of these two workflows, let’s take an example of a setting that you might want to configure: the homepage that will open whenever the user launches Safari on macOS. 

You could set it locally on the device using the defaults command:

defaults write com.apple.Safari.SandboxBroker Homepage https://www.kandji.io

That would update the file com.apple.Safari.SandboxBroker with a new dictionary key specifying that URL as the homepage: 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Homepage</key>
    <string>https://www.kandji.io</string>
  </dict>
</plist>

Because you edited the plist, the user could still change that homepage setting in Safari itself (Safari > Preferences > General).

Alternatively, you could create a configuration profile. In this example, that file would look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>PayloadContent</key>
    <array>
      <dict>
        <key>PayloadType</key>
        <string>com.apple.Safari</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PayloadIdentifier</key>
        <string>com.example.setsafarihomepage</string>
        <key>PayloadUUID</key>
        <string>UNIQUE-IDENTIFIER-FOR-THE-PAYLOAD</string>
        <key>PayloadDisplayName</key>
        <string>Safari Home Page</string>
        <key>PayloadEnabled</key>
        <true/>
        <key>PayloadContent</key>
        <dict>
          <key>HomePage</key>
          <string>https://www.kandji.io</string>
        </dict>
      </dict>
    </array>
    <key>PayloadOrganization</key>
    <string>Example Organization</string>
    <key>PayloadIdentifier</key>
    <string>com.example.setsafarihomepageprofile</string>
    <key>PayloadUUID</key>
    <string>UNIQUE-IDENTIFIER-FOR-THE-PROFILE</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadDisplayName</key>
    <string>Safari Home Page Profile</string>
    <key>PayloadDescription</key>
    <string>This profile sets the home page in Safari.</string>
    <key>PayloadRemovalDisallowed</key>
    <false/>
  </dict>
</plist>

You’ll note that the specific key dictating the homepage is identical in the plist and the mobileconfig file: 

<dict>
  <key>HomePage</key>
  <string>https://www.kandji.io</string>
</dict>

The main difference, then, is in the kind of access users have to the setting. If you sent that configuration profile, and the user tried to reset it in Safari, they’d see that the Homepage field in Settings was already filled in, and it would be uneditable.

Choosing the Right Workflow

There was a time when configuring each and every setting for the end user was common. (We’re looking at you, User Template directory!) This meant a ton of extra work for administrators. Worse, those settings were often broken by each new OS update. 

Today, while admins still want to configure some settings for users, the generally accepted best practice is to configure only those that are truly necessary. For example, while configuring security is obviously imperative, you don’t really need to set the size of everyone’s desktop icons. Just because you can, doesn't mean you should. 

And while you might want to have completely consistent configurations on every computer in the organization, you need to give users some leeway. Consider, for example, that some users prefer light mode over dark for accessibility reasons. Consider whether the setting you’re deploying might make them less productive.

The three workflows we listed at the outset—using MDM, configuration profiles, and the defaults command—serve these needs in different ways. 

As we said up top, using your MDM solution is the best way to remotely configure device settings on your Mac fleet. After that, customized configuration profiles are great for managing settings you can’t configure in your MDM platform. And there’s always scripting if you need to work on settings that aren’t manageable any other way. 

Mac admins will always have a compelling interest in managing certain settings on Mac endpoints. Understanding what these different workflows can do will make it easier to strike the right balance between the needs of the organization and its users.

About Kandji

Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.