Using the personal recovery key to unlock/reset a user password on a FileVault-encrypted Mac

In a previous blog post, I wrote about Why you should use FileVault personal recovery keys instead of institutional recovery keys.

If you have a personal recovery key, this is how you can use it to unlock a FileVault-encrypted machine that's been reboot (useful for organizations that doesn't have their local admin accounts as FileVault-enabled ones) or how you can use it to reset a user's forgotten password. The steps for both procedures are very similar and differ only at the very end.

When you boot up the Mac and get to the FileVault prompt for the user, click the question mark button next to the password field.

Then, click the arrow next to If you forgot your password, you can reset it using your Recovery Key.

You'll then be prompted to enter your recovery key.

Go ahead and enter the recovery key when prompted. It won't be the one you see in the screenshot. It'll be one that you have escrowed somewhere (Crypt Server, your MDM, MunkiReport, etc.). And, don't worry—that recovery key is for a VM'ed Mac, and I rotated the key to be a new one anyway.

Wait for macOS to boot up.

At this point, the procedures for "unlock a machine that you want to reboot but don't know the user password to" and for "user has forgotten her password and needs a new one" diverge.

If the user has forgotten her password, have her simply enter a new password, verify it, and then click Reset Password.

If you just wanted to unlock the encrypted computer so you can log into another account (e.g., local admin that isn't a FileVault-enabled user), click Cancel, and you can log into another account on the computer.


Google Forms preview gives “resource unavailable” error message

We had a situation in which someone created a Google Form and the preview for it would always come up with a resource unavailable error.

This wouldn't happen for any other form. And it wouldn't happen on another computer.

Clearing the cache didn't fix it, but clearing just Google cookies did fix it.

Something definitely worth trying, since most of the results for this indicate a problem with the Google Docs service being down and nothing to do with cookies being corrupted.


Let’s Encrypt certificate “expired” even though it’s not?

One of our servers (Ubuntu 18.04 with Nginx) is using Let's Encrypt's certbot to renew its SSL certificate regularly via script. Recently, it reported in web browsers as having an expired certificate. When I ran

certbot renew

it showed as having the certificate set to expire months from now.

Just on a lark, I rebooted the server, and then it was fine, and the web browsers showed the new certificate. Usually, a reboot isn't necessary. I'm not sure why it was all of a sudden this time. But just FYI: if you're using Let's Encrypt to renew your site's certificate, and it's definitely renewed but randomly not showing that way to client machines, try a reboot.


Dealing with iCloud accounts on DEP-enrolled iOS devices

I'm not sure how many other schools deal with this, but we found out something rather curious the other day, and it's been confirmed by Mosyle (our MDM) and a couple of folks on the MacAdmins Slack.

My understanding was that a DEP-enrolled MDM'ed iOS device would not allow an iCloud account (regular Apple ID, not a managed Apple ID) to be locked to it. In other words, you can sign in with an iCloud account, but anyone can just sign out of it without a password. That behavior would totally make sense (after all, it's not your device—it's the organization's, and it's a supervised device).

Apparently, that's not actually the case at all.

If you sign in with an iCloud account, you cannot remove the account without getting the password to the iCloud account or wiping the device.

One additional weird piece to this is that even though you can't sign out of the iCloud account without a password, you don't actually need the activation lock bypass code after a device wipe. It just re-enrolls in the MDM via DEP. So the iCloud account is locked to the device (until you wipe it), but the device itself isn't activation locked.

That may be fine if you're in a school-owned one-to-one iPad program: Student shows up first day of school, gets a DEP-enrolled iPad, signs into her iCloud account, uses it the whole year, and then the school's tech department wipes it at the end of the school year.

However, we have at the moment a one-to-one bring-your-own-iPad program, and so the school-owned iPads are for special temporary uses (in carts for certain academic programs, as short-term loaners in certain circumstances). So allowing students to sign in with iCloud accounts can be really inconvenient.

The only options we have are:

  • Let people sign into their iCloud accounts and then track them down later to remove their accounts. (A lot of tracking down of people.)
  • Pre-emptively sign into a generic iCloud account to prevent others from signing into their own iCloud accounts. (A lot of manual labor.)
  • Preventing all account sign-ins via MDM restriction. (This also shuts down the ability for people to sign into Mail or Google Apps, though, so it's a non-starter.).
  • Wipe the device every time there's a lock.
Right now, it's looking as if the last option is the least worst option. Not sure how many other schools are in this sort of situation, but until Apple changes the MDM spec, that's what we have to deal with.


Word 2016 in Windows printing embedded images zoomed in and cropped

One Windows user ran into an issue in which embedded images in a Word document would appear fine in the print preview but then would print zoomed in and cropped. In other words, the area on the printed document where the image should be is the same size as the image should be but only part of the image is printed inside that area but zoomed in and pixelated.

In this situation, saving to PDF would allow the user to print it properly.

Someone else online had a similar situation and was able to fix it by adjusting the dpi of the original images.

Turns out the fix was even easier than that: the documents had been created in an older version of Word, and they were saved as .doc files. Once the user saved them as .docx, everything printed just fine.


iTunes 12.8 on 10.13.6 not seeing iOS devices

If iTunes 12.8 on macOS High Sierra isn't seeing iOS devices, you may get a prompt to install software to see the iOS device, and then the installation may seem to take a while. For example, you may see this for a long time (over 20 minutes):

And even this might stay for a few minutes:

Once that's installed, it should work. If you don't see that prompt on one machine but do see it on another, you can grab the installer from /Library/Updates/041-14491 and install that manually.


iPhone cookie error when adding a Google account

If you are on iOS 12.0.1 and getting a you've reached this page because we have detected that cookies are disabled in your browser error message every time you try to add a Google account to Mail—and you're certain that cookies in Safari are indeed not blocked—update iOS (to 12.1, as of this writing), and that message will go away, and you can go ahead and add Google accounts.


Getting osTicket to schedule ticket creation from emails

If you go to Admin Panel > Emails > Settings > Incoming Emails, right now (as of release 1.10.4—the latest stable release as of this writing), you'll see something called Fetch on auto-cron, which isn't super useful, because it will fetch emails only if an agent is logged into osTicket.

There is an external scheduler option. Unfortunately (again, as of 1.10.4), that Using External Task Scheduler link is broken. I believe it's supposed to go to RECURRING TASKS SCHEDULER (CRON JOB).

There, you see on a *nix system, you're supposed to put in a cron job of

*/5 * * * * nobody /path/to/php /path/to/api/cron.php
but that didn't work for me on Ubuntu 16.04.5 (Xenial). If I ran the command
sudo /path/to/php /path/to/api/cron.php
manually, it would fetch the emails and create a ticket. And, even when a ticket wasn't automatically created, I could still see in /var/log/syslog the cron job actually having been run.

I even tried changing the user to root instead of nobody (but if you create a cron job using

sudo crontab -e
it runs as root anyway... not really sure what nobody is supposed to do there.

It didn't work until I substituted in this line instead:

5 * * * * /usr/bin/php /path/to/api/cron.php
Now, again, I don't really know what that nobody was supposed to do. According to the Ubuntu community docs, having the username in there is supposed to run it as that user, but when I had nobody or even root as the specified user, the command would run, but no ticket would be created.

I had to leave out the user altogether. Also, again according to the Ubuntu community docs, you should be able to put an */# in front of the four asterisks to run it every # minutes, but I found the command executed properly if I just put a single number in there.

Any cron job experts out there who can explain this, I'd love to learn more of the nuances of how this all works (or doesn't work)?


MathType formulas shrink after editing and saving them in Microsoft Word

March 2019 Update: WIRIS has now announced a workaround for randomly resized equations. I don't know for sure that that's exactly the same problem as the shrinking formulas, but it could be. Definitely worth checking out if you're experiencing this issue.

One teacher had an issue in MathType that involved saved formulas in a Word doc shrinking after editing and saving them again (even if the edit involved no actual changes).

The weird thing is that we tried with another user on the same machine with the same document and couldn't replicate the behavior, so it seemed to be tied to the user profile, but then later, with a fresh user profile, the issue still seemed to persist. So maybe that was a weird anomaly (it not shrinking)?

I did a bit more digging and Googling and came across this answer from WIRIS:

This is an issue with Retina displays, so that's one possible workaround: if you have a non-Retina display, use that when inserting or editing equations. The equations will be fine if merely viewed or printed when using a Retina display, but when you insert or edit one is when the sizing issue happens.

As Charles suggested in an earlier reply, "Consider reverting to Version 16.15." This is, in fact, Microsoft's recommendation as well. The answer on an earlier question in the Microsoft Community answers forum describes how to do that.

"[F]ine if merely viewed or printed" means, as far as I can tell, if you have already existing formulas that haven't been edited.

We tried reverting to 16.15, and that seemed to fix the issue.

For Munki users trying to downgrade Word to address this particular MathType issue, this is what worked for us:

  • Import Word 2016 (version 16.15).
  • Get the installs array of the binary at /Applications/Microsoft Word/Contents/MacOS/Microsoft Word, and put that in the pkginfo.
  • Modify the pkginfo to also change the version to be higher than 16.16. For us, 16.16.18091015 was sufficient for the change to take hold.
  • Create a new catalog called mathtype, and make that the only catalog for this pkginfo.
  • Put in a preinstall_script that checks for the existence of /Applications/Microsoft Word, and deletes it if necessary. If you don't do this, Munki will install 16.15, but it won't actually replace 16.16.
  • Add the mathtype catalog to the relevant manifest(s) you want to have this downgraded version of Word. Put this catalog before production, testing, or any of the other regular catalogs you have (more details on why).

Example of the preinstall_script:


# Doesn't work if the newer version is already there, so delete it

if [[ -a "$existing_word" ]]; then

/bin/rm "$existing_word"


This downgrade procedure is modeled after the general approach to downgrading via Munki, outlined on the wiki.

P.S. The shrinking MathType formula problem persists in Word 16.17 (Word 2019).


Images not loading in Gmail canned responses

Do you use images in canned responses in Gmail? Did you notice your images suddenly showing up as blank boxes (both in the composition and in the actual sent message)?

Well, there's a fix for that. Use the new Gmail instead of the old Gmail:

Your images should now load (you do not need to re-create your old canned responses).