MathType formulas shrink after editing and saving them in Microsoft Word

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:

#!/bin/bash

# Doesn't work if the newer version is already there, so delete it
existing_word='/Applications/Microsoft Word.app'

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

/bin/rm "$existing_word"

fi

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

What I learned upgrading from MunkiReport 2 to MunkiReport 3

The setup for the old (version 2) MunkiReport was fairly simple. You essentially just downloaded the folder to your web server.

The setup for the new (version 3) MunkiReport has a bit more nuance to it. I had a lot of trouble setting it up, but thanks to some help from other Mac admins (special thanks to Rick Heil for getting me over the finish line), I was able to finally get it up and running.

Here are a few issues I ran into. Maybe if you're running into the same or similar issues, this list may help:

  • Ubuntu 16.04 doesn't have PHP 7.0.27 or higher, which the new version of MunkiReport requires, so I had to add it in with the appropriate PPA.
  • On a related note, once you add that PPA to your sources.list in Ubuntu, you get a whole ton of PHP versions available via apt: 7.0, 7.1, 7.2. It's best to make sure you have only version of PHP installed and remove all the rest. I'd recommend 7.2 at this point.
  • It's a good idea to start with the sqlite database just to eliminate MySQL connection issues as a possibility. That said, since the main MunkiReport 3 files don't live in the public-facing part of the web server, be especially mindful of this part of the wiki instructions: when using SQLite as backend (which is the default), check if the directory /app/db/ is writeable by the webserver.
  • If you're using AD or SAML authentication, move it up in the composer.json file from suggest to require and get rid of the description after the version number. For example, "adldap2/adldap2": "^8.0 Required for AD authentication" should change to "adldap2/adldap2": "^8.0" after being moved.
  • If you're running the composer command and get a [RuntimeException] The "--no-suggest" option does not exist. message, just ditch the --no-suggest part of the command.

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:%42.031690
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:%97.750000
installer:PHASE:Configuring the installation…
installer:%72.402678
installer:PHASE:Writing files…
installer:PHASE:Running package scripts…
installer:PHASE:Preparing Adobe Acrobat DC (18.011.20038)…
installer:%4.485919
installer:PHASE:Waiting for other installations to complete…
installer:STATUS:
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.