macOS command to add back Wi-Fi service

Acknowledgements: Hat tip to Eric Hemmeter on the MacAdmins Slack for this command.

If you want a command that will add back the Wi-Fi service if you deleted it and now want it back, here it is:

networksetup -createnetworkservice Wi-Fi en1
That's assuming the output of
networksetup -listallhardwareports
has a hardware port of Wi-Fi with its device being en1 (could be en0, for example).

Using Munki to manage Mac preferences with .mobileconfig profiles

You may sometimes script preferences using defaults write commands (don't edit the .plist files with a text editor directly). For example, you might change Munki client preferences using a command like:

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "https://subdomain.yourserver.com/munki_repo"
That's fine to do, but if you're actually managing Munki client preferences (not just for Munki-related settings but for other third-party or macOS settings), why not use Munki's built-in support for .mobileconfig profiles?

There are several methods to get or generate .mobileconfig profiles. I'm listing them below in order of preference from top recs to not-to-top recs.

Just finding existing profiles

Chances are if you want to manage a setting, someone else has also wanted at some point to manage that setting. site:github.com mobileconfig is a great Google search for finding those.

Using mcxToProfile to generate a profile

You can create .mobileconfig profiles from existing .plist preference files you already have on a sample client machine. Just download Tim Sutton's mcxToProfile.

Then you can run something like

./mcxToProfile --plist /Library/Preferences/ManagedInstalls.plist --identifier MunkiPrefs
and then you can hand-edit the resulting .mobileconfig file to get out anything extraneous (for example, if all you want to set is the SoftwareRepoURL).

Generating Profiles with Apple Configurator

Apple Configurator is another option.

Just click File and select New Profile.

Once you've selected everything you want to configure, click Save.

The code it produces is (like mcxToProfile's) clean and easy to edit. And, yes, you usually want to edit down .mobileconfig profiles to be only the things you actually want to manage. Omit (i.e., delete) anything that you want your users to be able to manage themselves.

Generating profiles with Profile Manager

If you're using Server.app, there's a built-in way to generate profiles.


I usually create a test device group with no actual devices in it.

Then, under Settings, select Edit.

Find the type of setting you want to edit (there are some generic settings and then others specific to iOS or macOS). and click Configure and check off all the stuff you want configured.

Then once you've closed out of the editing settings space, click Save for the whole device group. This will allow you to download the settings.

Click the Download button and select macOS.

Now we're getting to why I seldom use Profile Manager. It adds in a bunch of binary gobbledygook and shoves all of the tags together so it's not easy to read. So, yeah, you can use it... but not fun.

Update: Apparently, you can tidy up the XML fairly easily if you want. Thanks to Ian Vonesh for the tip.

Whichever method you use, though, you can just import the .mobileconfig directly into Munki and push it out to your clients (be sure to test for unexpected behavior first before moving to production).

Terminal command to see the Startup Disk in macOS

If you want to see what the current Startup Disk is on your macOS installation, you can certainly go to System Preferences > Startup Disk.

But if you want to use the terminal instead of the GUI, this command will return the current Startup Disk:

bless --getBoot
If a Startup Disk is set, you'll see something like this:
/dev/disk0s2
If no Startup Disk is set, you'll see this error message instead:
Can't access "efi-boot-device" NVRAM variable
or this one:
Could not interpret boot device as either network or disk
Can't interpet EFI boot device
And, yes, there's a typo in the error message (as of macOS 10.12.6, anyway). That should say Can't interpret instead of Can't interpet.

Use the command-line to set a firmware password on macOS

For extra security, you can add a firmware password to Macs, especially since Find My Mac is essentially useless (unlike for iPads, which have an activation lock preventing thieves from reactivating the iPad after a factory reset) and DEP-to-MDM enrollments for Macs can even be avoided by thieves if they're resourceful enough.

If you have a laptop with a firmware password, you need that password to boot from anything except the startup disk. Combine that with FileVault encryption, and a stolen Mac is pretty much useless. Doesn't mean that you'll necessarily get it back, but the likelihood is higher if the device is useless to thieves.

You can, of course, enable the firmware password via Recovery Mode, but it's easier to do it from the command line:

sudo firmwarepasswd -setpasswd
You'll be prompted for the new firmware password. Afterwards, you'll need to reboot the machine for the change to take effect. (Be sure to make sure you have an actual startup disk selected in System Preferences!)

There are two modes for a firmware password: command and full. By default, the firmware password mode will be command, which means you'll be prompted for the password only if you boot from something other than the startup disk. If, for some strange reason, you want the mode to be full, it would mean you'd be prompted for a firmware password at every boot, regardless of what you're booting to.

A few other commands you might find useful...

sudo firmwarepasswd -check
checks to see if the firmware password is set.
sudo firmwarepasswd -verify
allows you to verify you have the correct password (without rebooting).
sudo firmwarepasswd -delete
deletes the firmware password. You'll need the current one to delete it, of course.

If you want to script firmware password setting, someone wrote a fairly simple script that does it. There's also firmware password manager, which is a far more sophisticated way to manage firmware passwords.

Nota Bene: If you enable a firmware password, you can get into target disk mode by holding down the Alt/Option key at boot, typing in the firmware password, and then holding down the T key. However, you will be unable to boot into Safe Mode unless you delete the firmware password.

If you can’t change the system language on macOS…

In theory, you can change the system language through System Preferences on macOS.

I did find a couple of machines that came with the system language in a different one from what I wanted, and even when I changed the primary language back to English (and rebooted when prompted), the original language persisted.

After doing a bit of Google searching, I came across this gem, which points to the command-line tool that really makes the system language change stick:

sudo languagesetup

Updating MS Office dock icons from 2011 to 2016 using dockutil

Managing client machines while also giving your users freedom to customize their machines as they want can be a bit tricky. On the one hand, you want to automate things as much as possible so users don't have to be bothered with too many update prompts and other maintenance nuisances. On the other hand, you don't want to automate things in a way that will confuse your users.

Jamie (our Dir. of IT) and I had a discussion about moving people from Microsoft Office 2011 to Microsoft Office 2016 and what that would look like. We didn't want to just uninstall Office 2011 right away, especially since it's the only thing MathType will reliably work with (in February, 2016, Design Science announced compatibility with Office 2016 for Windows, with a note that compatibility with Office 2016 for Mac would be coming "soon"—still hasn't come over a year later, as of this writing). And, even though installing Office 2016 side by side with Office 2011 makes 2016 the default for Office files, we wanted to update the Dock icons, so people would launch Office 2016 applications instead of Office 2011 ones.

These were the situations we thought we'd encounter:

  1. User has MathType installed. If that's the case, we don't want to touch the Dock icons. We have only a handful of MathType users, and most of them have already installed Office 2016 (previously an optional install through Munki's Managed Software Center). Only one user asked about how to change the default application to be Office 2011's instead of Office 2016's.
  2. User has only Office 2016 icons in the Dock. Nothing to do in this scenario, because everything's cool already.
  3. User has a mix of Office 2016 and Office 2011 icons in the Dock. If both Word 2011 and Word 2016 are in the Dock, we're going to assume the user wants it that way, and we aren't going to mess with it. But if Excel 2011 and Excel 2016 are in the Dock but only Word 2011 is in the Dock, we want to switch that up to be Word 2016.
  4. User has only Office 2011 icons in the Dock. If this isn't a MathType user, let's switch these all up for Office 2016.
  5. User has no Office icons in the Dock. Leave it alone. If the user doesn't want shortcuts to Office, don't put any in there.

The tricky thing about changing up Office icons in the Dock is that dockutil goes by name or bundleid to add, and both the name and the bundleid is the same for Office 2011 and Office 2016 applications.

So I wrote up a script that checks based on the dockutil --list output to see if the Dock icon is for 2011 or not. It may not work exactly for your organization, but you can see the logic in there, and it's easily tweakable.

Can’t change Safari homepage in Sierra, even with no profiles managing homepage

So I came across something weird that's affected only my 10.12.4 clients (none of my 10.11.6 clients seem to be affected by this). Even though I have only one Safari profile enabled, which is set-once and doesn't manage the homepage, my 10.12.4 clients are unable to change the homepage in Safari manually. Whatever the homepage was is stuck like that. If you enter a new homepage in the Safari preferences, it will just not take and revert back to the old homepage once you hit Enter or click out of the address entry field.

The only workaround I've found for this is to delete all profiles (again, even though I don't have any profiles managing the Safari homepage):

sudo profiles -D
Are you sure you want to delete all configuration profiles? [y/n]:y
reboot the computer, and then reinstall (via Munki) all the previously installed profiles (yes, including the set-once profile for Safari that was installed before)... and then I'm able to change the homepage on the client manually. Very bizarre.

Also, after testing on a couple of other clients, there do seem to be situations in which the Safari profile was never set at all, and you still can't modify the homepage, even after deleting any other profiles and rebooting, and it's not account-specific either (freshly created account experiences it, too). It's a real head-scratcher.

Using startosinstall to install a macOS upgrade with Munki

Update: The instructions below will be obsolete once Munki 3 is released. More details on the Munki 3 implementation can be found on the Munki wiki.

createOSXinstallPkg is a great project for making an Apple macOS installer into a .pkg you can deploy with Munki.

Apple did some things to break that process for 10.12.4. People are in the process of finding workarounds for it.

One option is to use the built-in startosinstall tool that comes with the installer bundle.

If you import the bundle into Munki, you'll want to have both a preinstall_script and a postinstall_script.

The preinstall_script checks to make sure there aren't other updates pending, since startosinstall will run its own reboot independent of Munki. The pending updates should be 1 (it's the only 1) or 0 (it was part of a set of updates that did complete and then the pending updates cleared, and you're trying again):

#!/bin/bash

# Make sure there is only one pending update (this one)
pending_count=$(defaults read /Library/Preferences/ManagedInstalls PendingUpdateCount)

# If it's 1 or 0, we're good to go
if [ "$pending_count" == 1 ] || [ "$pending_count" == 0 ]; then

exit 0

else

# Otherwise, abort the installation
exit 1

fi
The postinstall_script does the actual install:
#!/bin/bash

sudo "/Applications/Install macOS Sierra.app/Contents/Resources/startosinstall" --applicationpath "/Applications/Install macOS Sierra.app" --agreetolicense --nointeraction
Just as you would with a normal OS upgrade item, you want the installs array to reflect the OS version (not the presence of the installer bundle in the /Applications folder), and you want to mark this as an Apple item. (Check the Munki wiki for more details about those two things.)

P.S. There is now a recommendation on the createOSXinstallPkg README to upgrade using 10.12.3 or investigate using startosinstall.

P.P.S It's possible, instead of my funky workaround with the preinstall_script, that you could use the --pidtosignal option instead with Munki. Here's an example using JAMF.

P.P.P.S. Looks as if Greg Neagle has started working on integrating startosinstall into Munki "natively"—yes!

Why you should use FileVault personal recovery keys instead of institutional recovery keys

In my previous blog posts on FileVault, I talked about or showed how to use an institutional recovery key for FileVault encryption:
Enabling FileVault Encryption for Client Macs
Setting up deferred FileVault encryption
Using a FileVault institutional recovery key to unlock an encrypted disk

But in exploring FileVault further, I've found it's much better to use personal recovery keys instead of a single institutional recovery key, and it's not for the reason you might think.

IRK not necessarily less secure than PRK

Yes, from a security standpoint, you could make the case that an institutional recovery key creates a single breach point (someone obtains that one recovery key and thus can decrypt all your institution's machines), but I don't think this makes personal recovery keys more secure necessarily. First of all, the personal recovery key itself can unlock a machine, but the institutional recovery key is used in combination with a password to unlock the keychain. Secondly, most likely you're storing your personal recovery keys all in one place—it may be a secure place, but it's also a single breach point. If you somehow access that one storage location (database, spreadsheet, whatever you're using to store the personal recovery keys), you have access to all the recovery keys for all the machines.

I suppose you could scatter the personal recovery keys in multiple storage locations. There is always an artistic (not scientific) balance between security and convenience, so that's up to you how you decide to store things. The point, though, is that an IRK is not necessarily less secure than a PRK.

You could make the case that with something like Crypt2 you at least have an audit trail of when recovery keys were accessed, and you can generate new ones, so personal recovery keys do have one small distinct security advantage.

IRK is less useful than a PRK, though

As I was rolling out encryption to our fleet using an institutional recovery key, I started to realize through testing (fortunately not through an actual emergency) how limited in functionality the institutional recovery key is compared to the personal recovery key.

First of all, unless you are physically in front of the machine or using ARD to remote into a virtual session, you cannot enable another FileVault user without storing the password for it in plain text. If you try to do so via SSH and the command-line, you'll be prompted for the password of an FV-enabled user or for the personal recovery key, so having the IRK doesn't help there.

That's not really the worst part. The worst part is that, as far as I can tell (based on Google searches, asking other Mac admins, and just trial and error), there is no way to reset a forgotten user password with just the institutional recovery key. You can unlock the encrypted volume and save the data, but you can't just say "Reset this user's password." You can, as a horribly long workaround, decrypt the drive, log in as another admin user, reset the other user's forgotten password, wait for the decryption to finish completely, and then re-encrypt. That can take a really long time.

But if you just use personal recovery keys, you can have the user try to log in three times, and she'll be prompted to enter the recovery key to reset the forgotten password, and then be prompted to enter a new password.

Wesley Whetstone has created a neat little pkg that can generate/regenerate personal recovery keys: fde-rekey.

Once you've switched that over, you can also remove the institutional recovery key (yes, it's possible to have both an IRK and a PRK). If you're using Munki, I wrote a nopkg that will remove the IRK after fde-rekey is installed.

Apple TV “the code is incorrect” error… when the code is correct!

We ran into a weird scenario where a user could not connect to Apple TV with a passcode. We tried all the usual troubleshooting stuff:

  • Does it work with another computer? Yes, it does.
  • Does it work with another user on the same computer? No, it doesn't.
  • Toggle Bluetooth? Makes no difference.
  • Reboot the AppleTV and the computer. No difference.
  • Double-check the key mapping is fine on the Mac itself. It is.
  • Try to connect to a different Apple TV. Same problem.
  • Is the time correct? Seems to be.
Ah, but that ended up being the problem (kudos to my colleague, Jerold, for finding this)—even though the time and date were technically "correct," we had to turn on location services and then set the time zone to be detected automatically in order for the Mac to connect to the Apple TV.

That's weird. It's weird because the time and date were definitely correct, and it's weird because other Macs do not have the time zone set to be detected automatically and are still able to connect to Apple TVs on campus.

But if you run into this issue where you're prompted for a passcode to connect to an Apple TV, and it keeps giving you the code is incorrect when you're absolutely sure you've typed the correct code, consider setting the time zone for automatic detection.