Create a .mobileconfig profile for a certificate

If you want to create .mobileconfig profile from a certificate (for example, to import into Munki), you can use Apple Configurator 2 to do so.

If you have your certificate already in your keychain, launch up Keychain and find the certificate you want to make into a .mobileconfig profile.

Right-click the certificate and select Export NAMEOFTHECERTIFICATE (export it as a .cer).

Then launch up Apple Configuration

Select File and then New Profile

Select Certificates and then Configure.

Find and select the certificate you exported earlier.

Select File and then Save.

Pick a filename for your .mobileconfig, which you can deploy however you want (as I previously mentioned, you can import this into a Munki repo).

When DEP nag won’t work but Setup Assistant will to enroll in your MDM

Other Considerations


The two-days-later update: after doing troubleshooting with our MDM, asking around to other Mac admins, Google searching, and creating an enterprise case with Apple, I finally got back a definitive answer from Apple, which is that this functionality is essentially broken in Sierra (10.12.6). They're saying it should be fixed in High Sierra beta (10.13.4 right now). It makes a lot of sense. Almost all of our fleet is 10.12.6 (as of this writing, anyway), and the few computers that did work were on 10.13.2 or 10.13.3 (so not beta but still working).

So there you go. Either use the workaround below or upgrade to 10.13 if you're having this issue.


We have a bunch of computers that refuse to get a DEP (Device Enrollment Program) nag, even though they get the DEP prompt using Setup Assistant.

I tried blowing out a bunch of files and folders by following the Reset an enrollment section of How to troubleshoot your DEP/MDM Enrollments (on the MicroMDM blog but with generic instructions that can work for any MDM). That worked, but it requires you to go through the Setup Assistant.

I tried creating two fresh (never booted) AutoDMG-created images—one that skips the Setup Assistant and one that doesn't. If I don't skip the Setup Assistant, it obviously works. Here's the weird thing, though: if I do skip the Setup Assistant, then running

sudo profiles -N
doesn't work (skips to the next line in the terminal) and
sudo /usr/libexec/mdmclient dep nag
either gives me this error:
[ERROR] Unable to get activation record: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named" UserInfo={NSDebugDescription=connection to service named}
or spits back the activation record dictionary (but with no actual nag appearing):
Activation record: {
AllowPairing = 0;
AwaitDeviceConfigured = 0;
ConfigurationURL = "";
IsMDMUnremovable = 1;
IsMandatory = 1;
IsSupervised = 1;
OrganizationAddress = "Our Address";
OrganizationEmail = "Our email";
OrganizationMagic = someidentifier;
OrganizationName = "Our organization name";
OrganizationPhone = Our organization phone;
SkipSetup = (
Now, if I actually just delete the /var/db/.AppleSetupDone file at this point and then go through the Setup Assistant, the Mac will DEP-enroll into the MDM.

So there is no network issue here (I've also tested there being no network issue on these devices by temporarily tethering them to my phone to go outside of our school's firewall—same issue).

So I really have no idea what's going on here. My MDM has all of the log information and all of my tests and insists it's not a problem on their end, but it's not the network, and it's not the image (again, a freshly created never-booted image).


So, as yet, I don't have a solution for this. Maybe I'm the only one experiencing this. I've asked around on the Mac Admins Slack, contacted my MDM directly, contacted our Apple rep directly, done a ton of Google searches. Seems a bit weird that it's just us with a never-booted image having issues on and off network.

There is good news, though. I don't have to do Setup Assistant for every single computer or do (much worse) a factory reset on each machine to DEP-enroll it (and, yes, we have a whole deployed fleet already that needs to be DEP-enrolled).

I found that if I take the ConfigurationURL from the activation record dictionary and just put that in Safari, it will download and try to install the MDM profile in a DEP way (not just in a non-DEP way).

So the only real missing piece is the actual notification that pops up. Notifications aren't blocked (again, on a never-booted AutoDMG-created image, why would they without some custom script explicitly doing so).

Update (18/02/08): At least one other person, using another MDM, has not found this to work. Safari just loads a blank page and doesn't download and install the enrollment profile. I'm using Mosyle, and this works for Mosyle at least, as of this writing.


If that works for you (putting the ConfigurationURL in Safari and installing the profile via System Preferences), you can try also automating the workaround by having the .mobileconfig delivered as a payload to /tmp and then running a script like this as a postinstall script:


# Install profile
/usr/bin/profiles -I -F "$3"/tmp/NAMEOFDEPPROFILE.mobileconfig
Had to run the separate profiles command because Munki will not support managing enrollment profiles.

Other Considerations

You don't have to use Safari to go to the ConfigurationURL, but it's handy to do so, because Safari, after downloading the enrollment profile, will just launch up System Preferences and try to install the profile. If you use another browser (e.g., Chrome), it will just download the profile, and you'll have to open it to get it to launch System Preferences to prompt for an install.

Yes, you can also just enroll in the MDM without using DEP, but Apple—with High Sierra's APFS default and the iMac Pro's secure boot—is moving more toward making macOS like iOS, so it's possible that DEP-enrolled devices may be treated differently or have different functionality from non-DEP-enrolled (but still MDM'ed) devices. Probably safest to do a DEP-enroll into the MDM.

macOS client can’t download Apple updates

This is a really odd situation. I have one client machine that cannot download a particular Apple update. This is the error message that comes up:

softwareupdate -d -a
Software Update Tool

Finding available software

Error downloading Security Update 2017-002: The Internet connection appears to be offline.

Error downloading updates.
Here are two things that make this situation weird:
  1. The machine can contact any random website, including Apple's.
  2. The machine eventually could even download and install the Safari update from the Apple servers.
I haven't found a real solution to this yet, and it affects only one client, but I did find a workaround, which was to just use Reposado with it.

askForPassword and askForPasswordDelay in macOS 10.13 (High Sierra)

In macOS 10.12 (Sierra) and earlier, you could go to System Preferences > Security & Privacy > General > Require password ________ after sleep or screen saver begins, and that would populate the askForPassword and askForPasswordDelay keys in ~/Library/Preferences/ for the user.

In macOS 10.13 (High Sierra), setting that preference in the GUI will not make it appear in the relevant .plist file. However, setting the preference with

defaults write askForPassword -bool TRUE
defaults write askForPasswordDelay -int somenumber
will make the change reflect in the GUI, and setting a .mobileconfig profile will also override what's set in the GUI.

Oddly enough, Apple's own documentation makes it sound as if those two keys exist only in 10.13 and later:

Validate a FileVault recovery key using a .plist file

If you want to validate your FileVault recovery key from the terminal, you can do

sudo fdesetup validaterecovery
and then be prompted for the recovery key.

But what if you want to use a .plist to validate the recovery key instead of getting prompted for the key? This is where it's a bit counterintuitive, at least as far as I've tested on macOS 10.12.6 and 10.13.1.

When you enable FileVault using a command like

sudo fdesetup enable -outputplist > /PATH/TO/RECOVERYINFO.plist
it generates a .plist at RECOVERYINFO.plist with the recovery key and some other keys (EnabledDate, EnabledUser, HardwareUUID, LVUUID, RecoveryKey, and SerialNumber).

But if you try to validate the recovery using that .plist, the command will just hang.

The reason it hangs is it's looking for the Password key in the .plist instead of the RecoveryKey key (which is the one fdesetup generated!). From the the man page for fdesetup:

fdesetup validaterecovery -inputplist < /fvinput1-recoverykeyonly.plist
Gets the existing personal recovery key in the "Password" key value of the plist and returns
"true" if the recovery key appears to be valid

The Crypt project actually takes the RecoveryKey out and then temporarily creates a .plist with the Password key in order to validate.

So, yeah, if you're not using Crypt, you'd essentially have to do that—copy the RecoveryKey key to be a new Password key in order for this command to work:

sudo fdesetup validaterecovery -inputplist < /PATH/TO/RECOVERYINFO.plist

Dealing with third-party kernel extensions in macOS 10.13 (High Sierra)

If you upgrade to macOS High Sierra, third-party kernel extensions you had previously installed will be fine.

But if you didn't already have those installed and want to install them, you'll get an error like this:

There isn't a way to script that away—the user must actually click Allow.

Probably the most practical way to deal with this for large deployments is to make sure your client machines are all enrolled in an MDM.

The MDM doesn't have to do anything to the client or push any special profiles. The clients just have to be enrolled. If they're enrolled, there won't be a prompt to allow installation of third-party kexts.

Troubleshooting faded-looking icons in Managed Software Center on 10.13 clients

Update: Apparently, a real fix for this is on the way.

Acknowledgements: thanks to elios and bochoven on MacAdmins Slack for figuring out what was going on.

If the icons in your Munki repo looked fine on your 10.12 and 10.11 clients, and then a few of them suddenly look sort of faded (for example, Word and Excel in this screenshot) in 10.13 clients, it's apparently because of a change in the way 10.13's Safari webkit displays .png files missing the ColorSync profile in the Get Info context menu (you'll still see the ColorSync profile if you open the .png with the ColorSync Utility).

The simple fix is to do the following:

  1. Mount the Munki repo share using a Mac running macOS 10.13.
  2. Delete the offending icons from /PATH/TO/MUNKI/REPO/icons/
  3. Regenerate new icons with
    /usr/local/munki/iconimporter /PATH/TO/MUNKI/REPO

Note: Icons generated using MunkiAdmin or sips will be fine, too, even if generated using a machine running macOS 10.12.

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 ""
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. 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, 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:
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.