Importing from Microsoft Remote Desktop 8 to Microsoft Remote Desktop 10 in macOS

Microsoft recently released a new version of Microsoft Remote Desktop for macOS, but the settings from the old version don't carry over automatically.

To import the old list of Windows machines to remote into, go to Connections and select Import from Microsoft Remote Desktop 8.

What to do if Safari refuses to launch

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.

Running

open /Applications/Safari.app
resulted in an error of
LSOpenURLsWithRole() failed with error -10699 for the file /Applications/Safari.app

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).

Using Munki’s force_install_after_date key to force items to install

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.

Once again, use sparingly, but you may need to use it, so it's good to know roughly what your users will see...

Troubleshooting Munki failing to install Apple updates

Problem

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).

Symptoms

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

Apple Software Update install of Security Update 2017-001-10.12.6: FAILED for unknown reason

Workarounds

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

softwareupdate -d -a
the newly downloaded update will install just fine via Managed Software Center.

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.

Factory-resetting a disabled iOS device

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).

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/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 askForPassword -bool TRUE
defaults write com.apple.screensaver 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:

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

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

# Desired hash output
desired_hash='MD5 (munkitools-3.1.0.3430.pkg) = 0afbe2fbe7cb81ff531834cba82f3a75'

# Go to the /tmp directory
/usr/bin/cd /tmp

# 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
md5_test=$(/sbin/md5 $munkitools)

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

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

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

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.

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.