Upgrading to High Sierra: “You may not install this volume because the computer is missing a firmware partition”

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

Parental Controls keeps blocking allowed apps

If macOS Parental Controls keep blocking allowed apps (both allowed through the checklist in System Preferences and through manually approving via password), deleting the account and recreating it may not be enough to fix the glitch. Instead, try recreating an account with a new name.

I've found Santa to block things more reliably (or not to block things you've allowed). You can block by certificate or (for Apple applications you'd need to do this), block by binary.

Preventing alarms from going off on MDM’ed iPads

If you have alarms set on iPads (either an actual alarm or an alarm from the "bedtime" portion of the Alarm app), you can't disable the alarm by blocking the app. All blocking the app does is prevent the user from launching up the app.

To prevent the alarm itself from going off, you have to block notifications from the Clock app.

CrashPlan 6.5 stuck on Connecting… and never times out

We had a couple of clients who would just never do an initial connection to CrashPlan after the upgrade from CrashPlan 4 to CrashPlan 6.5. But they would never time out or give an error message either.

Restarting the CrashPlan service didn't help. Restarting the computer didn't help. Uninstalling and reinstalling the client didn't help.

Turns out it if the detect-a-user script can't find a CP_USER_HOME, it will just keep trying to connect instead of erroring out. We modified our script, and now those clients are good (we did have to uninstall and reinstall the client after modifying the script, though).

P.S. Someone pointed out that I don't actually share the original or modified script. The point of this blog post isn't to say "Here's a script that works." There are lots of scripts that work. The point is more that if you're experiencing this issue ("connecting" and never timing out or providing an error message), you likely need to fix your script to output a CP_USER_HOME).

If munkiimport doesn’t generate an installer_item_hash in the pkginfo file

If you notice that running munkiimport on a .dmg doesn't result in an installer_item_hash generating, you might want to also run makepkginfo on that .dmg to double-check it's read-only:

makepkginfo /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg
WARNING: /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg is a writable disk image. Checksum verification is not supported.
WARNING: Consider converting /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg to a read-only diskimage.

“Grant access” problem when trying to open Word docs

If you're trying to open a Word doc, and it keeps saying you don't have permission (even when you own the document), asking you to grant access to the document, and then still not giving you access; then just quit out of Word completely, and then launch it up again. The document should open fine after that.

Failing Adobe Acrobat DC updates

Usually when new Acrobat updates come out, I can have clients pull them off the Munki server and install those updates automatically. Randomly, some clients will error out:

installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
installer:PHASE:Preparing for installation…
installer: Package name is Adobe Acrobat DC (18.011.20038)
installer:PHASE:Validating packages…
installer: Upgrading at base path /
installer:PHASE:Configuring the installation…
installer:PHASE:Writing files…
installer:PHASE:Running package scripts…
installer:PHASE:Preparing Adobe Acrobat DC (18.011.20038)…
installer:PHASE:Waiting for other installations to complete…
installer:PHASE:Preparing the disk…
At first I thought maybe having the update require a logout might fix that issue, but it doesn't. The only working solution I've found is to delete the Acrobat folder, run
sudo managedsoftwareupdate --auto
and then Munki will see that Acrobat is missing and install both Acrobat and the update just fine.

Not sure if there's a less involved way to fix that. And it seems to happen only for a few clients randomly.

When DEP nag won’t work but Setup Assistant will to enroll in your MDM

Other Considerations


The two-days-later update: after doing troubleshooting with our MDM, asking around to other Mac admins, Google searching, and creating an enterprise case with Apple, I finally got back a definitive answer from Apple, which is that this functionality is essentially broken in Sierra (10.12.6). They're saying it should be fixed in High Sierra beta (10.13.4 right now). It makes a lot of sense. Almost all of our fleet is 10.12.6 (as of this writing, anyway), and the few computers that did work were on 10.13.2 or 10.13.3 (so not beta but still working).

So there you go. Either use the workaround below or upgrade to 10.13 if you're having this issue.


We have a bunch of computers that refuse to get a DEP (Device Enrollment Program) nag, even though they get the DEP prompt using Setup Assistant.

I tried blowing out a bunch of files and folders by following the Reset an enrollment section of How to troubleshoot your DEP/MDM Enrollments (on the MicroMDM blog but with generic instructions that can work for any MDM). That worked, but it requires you to go through the Setup Assistant.

I tried creating two fresh (never booted) AutoDMG-created images—one that skips the Setup Assistant and one that doesn't. If I don't skip the Setup Assistant, it obviously works. Here's the weird thing, though: if I do skip the Setup Assistant, then running

sudo profiles -N
doesn't work (skips to the next line in the terminal) and
sudo /usr/libexec/mdmclient dep nag
either gives me this error:
[ERROR] Unable to get activation record: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.ManagedClient.cloudconfigurationd" UserInfo={NSDebugDescription=connection to service named com.apple.ManagedClient.cloudconfigurationd}
or spits back the activation record dictionary (but with no actual nag appearing):
Activation record: {
AllowPairing = 0;
AwaitDeviceConfigured = 0;
ConfigurationURL = "https://mymdmsenrollmentsurl.com/withabunchofotherstuffattheend";
IsMDMUnremovable = 1;
IsMandatory = 1;
IsSupervised = 1;
OrganizationAddress = "Our Address";
OrganizationEmail = "Our email";
OrganizationMagic = someidentifier;
OrganizationName = "Our organization name";
OrganizationPhone = Our organization phone;
SkipSetup = (
Now, if I actually just delete the /var/db/.AppleSetupDone file at this point and then go through the Setup Assistant, the Mac will DEP-enroll into the MDM.

So there is no network issue here (I've also tested there being no network issue on these devices by temporarily tethering them to my phone to go outside of our school's firewall—same issue).

So I really have no idea what's going on here. My MDM has all of the log information and all of my tests and insists it's not a problem on their end, but it's not the network, and it's not the image (again, a freshly created never-booted image).


So, as yet, I don't have a solution for this. Maybe I'm the only one experiencing this. I've asked around on the Mac Admins Slack, contacted my MDM directly, contacted our Apple rep directly, done a ton of Google searches. Seems a bit weird that it's just us with a never-booted image having issues on and off network.

There is good news, though. I don't have to do Setup Assistant for every single computer or do (much worse) a factory reset on each machine to DEP-enroll it (and, yes, we have a whole deployed fleet already that needs to be DEP-enrolled).

I found that if I take the ConfigurationURL from the activation record dictionary and just put that in Safari, it will download and try to install the MDM profile in a DEP way (not just in a non-DEP way).

So the only real missing piece is the actual notification that pops up. Notifications aren't blocked (again, on a never-booted AutoDMG-created image, why would they without some custom script explicitly doing so).

Update (18/02/08): At least one other person, using another MDM, has not found this to work. Safari just loads a blank page and doesn't download and install the enrollment profile. I'm using Mosyle, and this works for Mosyle at least, as of this writing.


If that works for you (putting the ConfigurationURL in Safari and installing the profile via System Preferences), you can try also automating the workaround by having the .mobileconfig delivered as a payload to /tmp and then running a script like this as a postinstall script:


# Install profile
/usr/bin/profiles -I -F "$3"/tmp/NAMEOFDEPPROFILE.mobileconfig
Had to run the separate profiles command because Munki will not support managing enrollment profiles.

Other Considerations

You don't have to use Safari to go to the ConfigurationURL, but it's handy to do so, because Safari, after downloading the enrollment profile, will just launch up System Preferences and try to install the profile. If you use another browser (e.g., Chrome), it will just download the profile, and you'll have to open it to get it to launch System Preferences to prompt for an install.

Yes, you can also just enroll in the MDM without using DEP, but Apple—with High Sierra's APFS default and the iMac Pro's secure boot—is moving more toward making macOS like iOS, so it's possible that DEP-enrolled devices may be treated differently or have different functionality from non-DEP-enrolled (but still MDM'ed) devices. Probably safest to do a DEP-enroll into the MDM.

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.

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.

Troubleshooting Munki failing to install Apple updates


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

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


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.