Managing modern macOS with old tricks
First, this one is a bit long. Just letting you know that up front. I actually made it shorter than originally intended because it was getting really dense in technical details and example Plists and I don’t think you came here to read a novel. If you did want the novel, I’m sorry to disappoint you. Add a comment and I’ll consider revisiting the very detailed example instructions I had in mind when I started writing. Anyway, let's get to it.
---
Fundamentally, managing macOS involves making decisions that define the user experience. Many of those decisions focus on what the user is allowed to do by defining restrictions. That's important stuff, because macOS is a consumer focused product and the choices Apple offers consumers for their user experience are often incompatible with the requirements of a school or business use.
We have MDM | DDM to bridge most of those gaps, so we can define configurations on our managed Macs that meet business requirements without degrading the user experience. Well, hopefully.
In olden times, before configuration profiles and MDM, Mac admins used Managed Client X (MCX) to define preferences for an almost ridiculous amount of settings. The best thing about MCX was its ability to set a preferred configuration without making it a required configuration. It did that using a tiered policy for setting preferences using 3 options: Once, Often, and Always.
If you set the preference Once, it would be applied one time and could be immediately changed by the user to their own preference. The user preference would then persist.
If you set it Often, the preference would be applied on user login. The user could change the setting while in an active session, but the preference would be reapplied from MCX on next login.
If you set it Always, the preference would be forced and users would be unable to make changes.
There's a lot more to MCX than that, but the concept of how settings were applied is our focus here, because Configuration Profiles apply settings Always. There is no other option. If a profile is applied to macOS that defines a setting, it will be forced and users will be unable to change it*.
*I'm speaking broadly here. Bugs happen.
That's a lot of background to say this: configuration profiles are great if you need to set it and forget it, but they suck for setting a preferred (aka optional) configuration. Defining optional settings requires something other than configuration profiles. There are lots of user experience settings a Mac admin might want to define that are meant to be helpful, but aren’t required.
Want to onboard new users who are coming from Windows, and you'd like to automatically enable Secondary Click on their Magic Mouse so their interaction with the mouse is familiar? Want to disable "Natural" scrolling on the mouse because it's an abomination that Apple insists on enabling by default?
How about setting up a custom Dock so your business apps that are installed during enrollment are easily accessible out of the box?
Even if those things could be done using configuration profiles, would you want to prevent users from changing them if their preferences differ? Probably not. Most importantly, applying preferred settings before the user logs in for the first time is critical to providing a seamless experience. As a user, there’s almost nothing worse than getting to the Desktop in macOS for the first time only to have a post setup provisioning tool take over and start changing things in front of you before you can even start using the Mac.
So, how do you define preferred settings for your deployment in a seamless way? You use an old school method from the NetBoot days paired with some MDM methodology to get an out of box experience that configures your settings without forcing a user to keep them.
macOS creates user home folders from a template defined by the content in /System/Library/User Template and its localization subdirectories. The various localization folders — and the very handy Non_localized folder that applies to all localizations — each have a /Library/Preferences subdirectory that contains predefined preferences applied automagically™ to every new user created on the Mac. With a bit of packaging and Automated Device Enrollment, we can affect the out of box experience and ensure that a brand new, first user account gets our preferred settings without forcing them.
First, you need to get your Plist(s) assembled. Creating or Modifying Plists is a post unto itself (and I may even write one), so I won't get into that here. Let's just pretend you've already figured out which Plist(s) control the settings you want to define. How do you get them into the User Template so they will be applied for your new users?
You need to package them into an Installer package. Packaging is also a topic unto itself, but MacAdmins 2024 had a pretty good primer you can watch here.
Your package needs to install your Plist file(s) into
/System/Library/User Template/{localization folder}/Library/Preferences.I strongly encourage you to use the
Non_localizeddirectory as your {localization folder} choice (e.g./System/Library/User Template/Non_localized/Library/Preferences) since it will apply to all localizations.Permissions should be rw-r--r-- root wheel for all files you install.
Once you have your package created (and you test it to ensure it puts files where you expect, and you confirm a new user account has the expected settings on creation), you'll add it to your MDM so it can be installed during Automated Device Enrollment. If your MDM is Jamf Pro, you add your package as an Enrollment Package in a PreStage Enrollment. For Workspace One, you create a Bootstrap package. Other MDMs may offer similar options; I'm not linking to them because I don't know their terminology and I don't feel like tracking down their documentation links. I use Jamf, and I am familiar enough with WS One to quickly find their documentation link, so that's what you get as examples. If your MDM doesn't have this capability, ask your vendor why not.
When you’ve added your package and configured your MDM to install it during Automated Device Enrollment, it will install before the first user account is created, ensuring the user gets your preferred settings when their home folder is created from the template. If there's a setting defined in a Plist file, anywhere in the User's Library, you can predefine it with this method and control the initial experience. Using this approach, you can get a consistent out of box user experience that a user can modify to match their own preferences.
In other words, you can set preferences Once using MDM.