Microsoft recently released a new version of Microsoft Remote Desktop for macOS, but the settings from the old version don't carry over automatically.
So a user came in with Safari not able to launch.
At first I thought perhaps the user account was corrupted, but I logged in as another user, and the issue persisted. Not launching and crashing. Just not launching at all. The dock icon didn't even bounce.
Because of System Integrity Protection, you can't actually just copy the /Applications/Safari.app from another machine.
But it turns out reinstalling Safari works (the link in there is for El Capitan—I reinstalled it for Sierra).
Keeping machines up to date can be a challenge. Munki tries to make this as seamless as possible, especially if you mark certain items as unattended installs (Munki will try to install those items in the background and not even bother the user).
But some updates require a logout or a reboot, and users generally don't like to log out or reboot often, particularly if they have laptops (as opposed to desktops). So pending updates can sit there for days, weeks, months, even over a year, unless you force the user to install the items.
I wouldn't recommend using the force_install_after_date option very often, but it can be very handy, particularly if there are critical updates that need to get to users.
And even though Munki itself will attempt to notify users of forced updates, you may want to accompany those built-in warnings with warnings of your own (via email, in person, etc.).
At the final countdown, the screenshots below are examples of what your users will see. Every time there's an OK button in the Managed Software Center, your user has the option to close Managed Software Center for a short time, but then MSC will just pop back up again soon. At the very last dialogue, the user will have no choice but to install the pending install item.
If you see Apple updates (that require a reboot) not installing properly via Munki, it may be because the downloaded update is stale somehow. Not really 100% sure on how this works, since I've seen this fail even on a "stale" update downloaded the same day (not weeks ago).
When you log out to update, you'll see Munki's progress bar over the login screen window, and it will look for a split second as if it's trying to install the pending Apple update but then move on almost immediately to requiring a reboot.
Then, if you check the logs at /Library/Managed Installs/Logs/Install.log, you'll see something like
You could create a script (run from its own Launch Daemon or as part of a Munki run) to clear old updates from the /Library/Updates folder periodically (though, again, I saw this happen even with a recently downloaded update).
I've found that if you run
This is tricky, because it's not technically a Munki issue (Munki just uses Apple's built-in softwareupdate to install Apple software updates), but clearly there's some flaw in invoking the software update mechanism.
A user came in with a disabled iPhone (too many password attempts) and couldn't factory reset it. We tried to get it into DFU mode, but we couldn't easily.
Turns out, if you just plug it into a computer that has Apple Configurator 2 installed, you can use Configurator to restore the device (without having to hold any buttons on the device—particularly helpful if some of the buttons are broken/finicky).
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/com.apple.screensaver.plist 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 com.apple.screensaver askForPasswordDelay -int somenumber
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.
# Name of .pkg
# Desired hash output
desired_hash='MD5 (munkitools-220.127.116.1130.pkg) = 0afbe2fbe7cb81ff531834cba82f3a75'
# Go to the /tmp directory
# Download the latest Munki tools .pkg
/usr/bin/curl -L -O https://github.com/munki/munki/releases/download/v3.1.0/"$munkitools"
# Make sure the hosting server hasn't been compromised and/or the download isn't corrupted
if [[ "$md5_test" == "$desired_hash" ]]; then
# Install the Munki tools .pkg
/usr/sbin/installer -allowUntrusted -pkg /tmp/munkitools-18.104.22.16830.pkg -target /
# Add in basic auth info
/usr/bin/defaults write "$3"/private/var/root/Library/Preferences/ManagedInstalls AdditionalHttpHeaders -array "Authorization: Basic BASICAUTHCODE"
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.
If you want to validate your FileVault recovery key from the terminal, you can do
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
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
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:
If you upgrade to macOS High Sierra, third-party kernel extensions you had previously installed will be fine.
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.
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:
- Mount the Munki repo share using a Mac running macOS 10.13.
- Delete the offending icons from /PATH/TO/MUNKI/REPO/icons/
- 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.