MacBook Air keyboard backlight disabled with a “do not enter” sign

Acknowledgements: Hat tip to my colleague Jerold for stumbling upon this fix.

We had a user come in with a MacBook Air whose keyboard backlight wouldn't turn on. If you pressed the F5 or F6 key to turn it up or down, there would be on-screen feedback but instead of a indicator bar showing it going up or down, there would be only a "do not enter" sign appearing.

We tried an SMC reset and an NVRAM reset, to no avail.

Finally, Jerold just thought "Why don't we plug it into an external monitor?" For some reason, that fixed it (even after unplugging it from the external monitor).

So if you run into this issue, that may not be a sure fix, but it's certainly something to try!

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

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.

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.

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