Deploying Munki with Mosyle MDM

Acknowledgements: This is a slightly modified workflow based on one proposed by Taz on MacAdmins Slack. Thanks, Taz!

You can use Mosyle to install Munki.


Switch to the macOS platform (if you're not already in there).


Then, click on Management.


Scroll down to and then click on Custom Commands.


Click Add new profile.


Name it whatever you want (e.g., Install Munki), and then put in a modified version of this code:

#!/bin/bash

# See if it's already been installed
if [[ ! -a '/Applications/Managed Software Center.app' ]]; then

   # Name of .pkg
   munkitools='munkitools-3.3.1.3537.pkg'

   # Desired hash output
   desired_hash='MD5 (munkitools-3.3.1.3537.pkg) = 208a04093704dd8039b89dfa671cbd8f'

   # Go to the /tmp directory
   cd /tmp

   # Download the latest Munki tools .pkg
   /usr/bin/curl -L -O https://github.com/munki/munki/releases/download/v3.3.1/"$munkitools"

   # Make sure the hosting server hasn't been compromised and/or the download isn't corrupted
   md5_test=$(/sbin/md5 $munkitools)

   if [[ "$md5_test" == "$desired_hash" ]]; then

      # Install the Munki tools .pkg
      /usr/sbin/installer -allowUntrusted -pkg /tmp/"$munkitools" -target /

      # Add in basic auth info
      /usr/bin/defaults write /private/var/root/Library/Preferences/ManagedInstalls AdditionalHttpHeaders -array "Authorization: Basic BASICAUTHCODE"

      # Wait until the setup assistant is done...
      until [ -f "/var/db/.AppleSetupDone" ]; do

         # If it's not done yet, wait 2 seconds to check again
         sleep 2

      done

      # Now that setup assistant is done, reboot the machine, since Munki requires a reboot after installation
      /sbin/shutdown -r now

   fi

fi

Assign this profile to whatever devices or groups you want, and then click Save.

Any other Munki preferences (e.g., SoftwareRepoURL) you'll want to deploy in a .mobileconfig profile. More details in Importing custom .mobileconfig profiles into Mosyle MDM.

P.S. I haven't done extensive testing on this, but you may be able to deploy Munki as a .pkg and not as a custom command that downloads the .pkg. You'll have to host it somewhere yourself (and Mosyle does not like the redirect URLs, so you'll legit have to host it), but you may want to try Management > Management Profiles > Install App > Add new profile. Then, under Installation source, pick Enterprise app, and then put in the URL of the hosted Munki installer .pkg.

To change the icon, just get a .png of whatever icon you want. Here's an example of how to generate that:

sips -s format png /Applications/Managed\ Software\ Center.app/Contents/Resources/Managed\ Software\ Center.icns --out MSC.png

Only caveat is that that won't work for scripting basic authentication.

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.

LockDown Browser in iOS crashes immediately after launch

If LockDown Browser on your iPad opens and immediately crashes, the way to fix it is to uninstall and reinstall the app. Swiping away the app, updating the app, updating iOS, doing a home-power reset all do not fix this issue (at least not at the time of this writing).

Importing custom .mobileconfig profiles into Mosyle MDM

Acknowledgements: Full credit to Tom Case on the MacAdmins Slack for this tip.

It's not immediately obvious that you can import custom .mobileconfig profiles into Mosyle MDM, but apparently you can if you go to Management > Certificates > (click on profile or add new one) > Select the file.

Those can be any .mobileconfig files—they do not have to be actual certificates.

Printopia Pro and “login not accepted” message

If you use pycreateuserpkg to create a user or change its password, that will work great... except with Printopia Pro, which will prompt for a local admin username and password, and your local admin username and password will not work, and you'll get a login not accepted error message instead.

Deleting and re-adding the local admin account using the GUI (System Preferences > Users & Groups). You'll have to use the terminal to delete the user and then re-add (through the GUI is fine for this second part).

Then Printopia Pro will launch up just fine and not prompt you for a username or password.

Escaping an apostrophe on a PowerSchool custom page variable

Acknowledgements: Thanks to Roger Sprik on the PowerSchool forums for this tip.

I have a custom page that uses the last name field:

~([05]Last_Name)
The only problem with that is if the last name has an apostrophe in it, that can lead to unexpected stuff when used in jQuery.

Apparently, you can strip out the variable to show only the letters and numbers:

~([05]Last_Name;keep_ascii=48-57,65-90,97-122)

Chrome Gmail unread messages not appearing in bold

We had a user whose unread emails were appearing as bold in Safari (with an ugly font) and not bold at all in Chrome (font looked okay), and we did some digging and found the solution was to enable the Arial Bold font in Font Book on the user's Mac, and it was all good.

Our best guess is that Safari couldn't find the font it wanted so substituted an ugly font but kept it bold, and Chrome couldn't find the font it wanted so substituted a decent-looking font but not bold.

When you can’t draw, erase, or highlight in Notability on iOS

A user wasn't able to draw (with a finger) using the pen tool in Notability. Highlighting and erasing were also not working (just seemed to move the note about in Notability).

We worked with the user on the usual troubleshooting steps (kill the app, do the home–power button reset, make sure iOS and Notability are both updated) to no avail.

The solution that ended up working—double-checking the notes were all backed up, and the uninstalling the app... and reinstalling the app.