An Admin’s Guide to Mac Device Management
By N‑able
…Plug it in. Turn it on. What’s step 3?
Imagine the disarming chuckle of Jeff Goldblum here: “There’s no step 3.”
The point of the 1998 ad I’m riffing on was that Apple’s new iMac was so simple to use that connecting to the internet required just two steps.
Meanwhile, over here in reality, we know the inevitable third step is “everything else.” More specifically, configuring all the software and hardware to talk to one another, and opening a connection to the internet, preferably without letting the bad guys in.
In the case of the solitary iMac, both in the ’90s and now, configuring and personalizing the user experience is actually quite simple. It mostly consists of answering the questions and checking the preferred boxes as part of the setup routine that runs upon first boot. But what about when you’re in charge of setting up and onboarding a dozen customer Macs? 50? 100 or more?
I want to talk to your manager
The way I see it, you have three options for configuring your (or your client’s) Mac fleet.
The first method is to fire up each Mac, log in, change all the settings until they are the way you like them, then return the machine to its user.
Which—let’s be honest—is not a great option, is it?
One of the obvious advantages to having a remote management agent installed on those Macs is that they can be managed remotely. So your techs can log into machines wherever they are, make the necessary adjustments, then move on to the next one.
While this will save you on travel time when configuring your Mac fleet, there are options that will scale better.
Wir sind die roboter
If you’ve attended one of my bootcamps, you’ve heard me say, “If you do it more than twice, automate it.” I say it so often, I have a button that I’ve programmed to say it for me.
It should come as no surprise then that the first viable mass configuration method involves automation.
In the dark and distant past of roughly five years ago, it was still possible to create a bootable image from an already configured Mac and clone that onto the drive of a similar Mac. Even then, it wasn’t recommended, but it was possible. That kind of imaging has been dead for a while now, though. The next best alternative is an onboarding script.
All aboard!
When you’re setting up a new computer for yourself—migrating data and settings, installing all the apps you’ll need—you can take your time. You might even enjoy digging through the system preferences menus and checking the box on this one, unchecking the box on that one, or adjusting the sliders on the other. Adding in your network details, security settings, and default applications makes a generic machine feel more like your own. Fine, but do that on your own time.
Tweaking preferences and being picky about what you set up now and what you defer until later is not an option when you’re staring at a pile of new laptops that all need setting up.
If you already know what those preferences settings, parameters, and configurations need to be, script it. Just about anything you can do within system preferences, and even the preferences of most applications on a Mac, can be done at the command line. Which also means it can be put into a script.
A quick sidenote on MDM and profiles: even if you’re deploying an MDM to manage your clients’ Macs (which you really should), a standard setup script will still come in handy. Preferences set by configuration profile can’t easily be changed by the user. In matters of security and compliance, that’s an advantage. But for items that you want to remain flexible, use your script to set a standard default, and the user can still modify as necessary.
It takes just a handful of commands to make seemingly endless permutations of customization. The first of these is systemsetup. As implied by the name, this command lets you set the sort of preferences you might be asked for during the system setup process. To see what you can modify this way, type the command
sudo systemsetup -printcommands
This requires sudo, since it affects the whole system and not just one user.
It’s worth noting that the list of available options will include items of some importance not only to customizing the user’s environment but also to security compliance. Choices such as whether the computer wakes from sleep on network access, or how long the idle delay is before the display locks, are important considerations when auditing for CIS certification, for example.
Look through the list of the systemsetup commands and make a note of which options you’ll want to employ in your own onboarding script. More on how to do that later.
Propagating preferences properly
Whether they affect the whole system, one user, or even just a single application, preferences are generally recorded in .plist (property list) files. Plists are just XML files that contain key/value pairs. To read and set specific settings in a preference file—for example, the default order to sort file listings in the Finder—the command is “defaults.” To use it, you’ll need to know what file the preference is stored in (called a “domain” because of the reverse-DNS format they are named in), what key to change, and what values are allowed.
You can see what I mean if you type this in the Terminal:
defaults read com.apple.finder
That will deliver, most likely, 1,000 or more lines of utterly fascinating prose, including such potent quotables as:
ShowExternalHardDrivesOnDesktop = 1; ShowHardDrivesOnDesktop = 1; ShowMountedServersOnDesktop = 1;
Those terms almost sound like the labels for the checkboxes in the Finder’s preferences under “Show these items on the desktop.” Coincidence? Ah, no.
The defaults command can do more than read what the current settings are. It also can be used to write new settings, like so:
defaults write com.apple.finder ShowHardDrivesOnDesktop 0
The real trick with defaults is knowing which “domain” and which key to change. Apple may have a master database somewhere with all that information in it, but they’re not sharing. Luckily, defaults has a “find” option. If you know what you want to change but you’re not sure where that setting lives, you can explore with something like this:
defaults find "desktop picture"
Also, lucky for you, generations of Mac admins have walked this path before. Some of them survived the journey and have written down what they found along the way. While it’s not exhaustive, https://macos-defaults.com/ and other sites like it are good places to start.
Though it may not be the most current, one of the most thorough references I have found is the “dotfiles” of Mathias Bynens at https://mths.be/macos. Looking through the 950+ lines of commented defaults commands will give you some ideas, I hope, for your own script. And if not, there are about 8,800 forks of that project on GitHub to dig through for further inspiration.
I cover the mechanics of shell scripting in my Mac Automation bootcamps, but here’s the quick and dirty summary: Copy and paste the commands you want to run, one per line, into a text editor. Save as plain text. There is no step 3.
Kidding. Of course there is. You’ll have to work out deploying and running your script on each new machine as it comes online. But that’s what remote management is for.
© N‑able Solutions ULC and N‑able Technologies Ltd. All rights reserved.
This document is provided for informational purposes only and should not be relied upon as legal advice. N‑able makes no warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information contained herein.
The N-ABLE, N-CENTRAL, and other N‑able trademarks and logos are the exclusive property of N‑able Solutions ULC and N‑able Technologies Ltd. and may be common law marks, are registered, or are pending registration with the U.S. Patent and Trademark Office and with other countries. All other trademarks mentioned herein are used for identification purposes only and are trademarks (and may be registered trademarks) of their respective companies.