If you notice you can't install new macOS updates on a Mac, it could be that it's still in the process of FileVault encrypting.
If you try to upgrade to High Sierra (macOS 10.13) and get You may not install this volume because the computer is missing a firmware partition when trying to select your drive to upgrade, it may be because you're upgrading on an OWC drive.
If you're using Munki, the error may appear in your /Library/Managed Installs/Logs/Install.log as Starting macOS install: FAILED: startosinstall failed with return code 243.
Previously, you'd have to physically swap back the OEM drive, and then put the OWC drive back again, but now OWC has its own firmware updater tool that fixes the problem:
Aura SSDs: Firmware Update (beta).
Why do you need Team IDs?
Beginning with macOS 10.13 (High Sierra), Apple is now blocking kernel extensions unless you, in recovery mode (or recovery mode–like environment), change the policy on the machine itself or use an MDM profile to approve certain KEXTs by Team ID.
How do you find these Team IDs, though?
One way is to install the KEXTs on a 10.13 machine, user approve them, and then check the sqlite database to see what the Team IDs are:
SELECT * FROM kext_policy;
Here's an example of some of the output you might see:
You can use Control-D to exit the sqlite3 session.
Acknowledgements: Got commands from Enabling Kernel Extensions in High Sierra
Another way is to run this command on an existing bundle from the vendor:
For example, if you run
This approach can be helpful in fringe cases (you just need the Team ID and not the bundle ID, which may be the case, and the KEXT you're looking for has an associated bundle you can run codesign on.
Acknowledgements: Got command from MunkiReport-PHP extensions module
Isn't there a list somewhere of all these Team IDs?
There is a list, actually. There's a spreadsheet that a bunch of Mac admins are sharing with each other. Unfortunately, at this point, it's a spreadsheet that anyone with the link can edit, so I wouldn't really count on that. At this point, I don't see anything malicious in there (and I haven't verified every single Team ID, of course), but I would probably play it safe and just get the Team IDs yourself. Chances are that you'll have to do it only once or twice a year at the most.
Update: Apparently 10.13.4 just breaks this completely (defaults write commands won't do anything any more). Thanks to tristan on the MacAdmins Slack for pointing this out.
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
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.