Tag: mac

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

Using Santa to block an .app

Acknowledgements

Special shoutout to @bur on the Mac Admins Slack for help with some command-line syntax.

Santa can be complicated, but doesn't need to be

Google has a project on GitHub called Santa, which is quite powerful and complicated. As the project's readme says, though: Documentation: This is currently limited..

I just wanted to do something simple: block an app, but I didn't see any straightforward documentation on how to do that. The closest I could find was the docs on certificate rules, but that was a bit incomplete.

So, first of all, something I was confused about at first was whether a configuration profile was necessary or not. It is not necessary. There are some default settings that just go by themselves. You need to configure settings only if you need to configure settings.

Blocking an app by certificate

If you have a blocking application rule, you can block by binary or by certificate. By binary may not be as helpful, because newer versions of an app will be a different binary. Let's say you want to block MacKeeper by certificate. (Install Santa first, so you can actually use it, including the santactl command.)

santactl fileinfo /Applications/MacKeeper.app --key "Signing Chain"
Signing Chain:
1. SHA-256 : 2df1460a9c76c4a63fa2d0d043fb0254f8fa69a99374f2a0b1e8eee885872614
SHA-1 : 2664b71c3db787226ff9715da4de32e9ad3e364f
Common Name : Developer ID Application: KROMTECH ALLIANCE CORP. (64424ZBYX5)
Organization : KROMTECH ALLIANCE CORP.
Organizational Unit : 64424ZBYX5
Valid From : 2013/10/14 04:00:13 -0700
Valid Until : 2018/10/15 04:00:13 -0700

2. SHA-256 : 7afc9d01a62f03a2de9637936d4afe68090d2de18d03f29c88cfb0b1ba63587f
SHA-1 : 3b166c3b7dc4b751c9fe2afab9135641e388e186
Common Name : Developer ID Certification Authority
Organization : Apple Inc.
Organizational Unit : Apple Certification Authority
Valid From : 2012/02/01 14:12:15 -0800
Valid Until : 2027/02/01 14:12:15 -0800

3. SHA-256 : b0b1730ecbc7ff4505142c49f1295e6eda6bcaed7e2c68c5be91b5a11001f024
SHA-1 : 611e5b662c593a08ff58d14ae22452d198df6c60
Common Name : Apple Root CA
Organization : Apple Inc.
Organizational Unit : Apple Certification Authority
Valid From : 2006/04/25 14:40:36 -0700
Valid Until : 2035/02/09 13:40:36 -0800

Then, add a block rule for it:

sudo santactl rule --blacklist --certificate --sha256 2df1460a9c76c4a63fa2d0d043fb0254f8fa69a99374f2a0b1e8eee885872614

You can always check on the other parameters by running

sudo santactl rule
which will output something like this:
No state specified

Usage: santactl rule [options]
One of:
--whitelist: add to whitelist
--blacklist: add to blacklist
--silent-blacklist: add to silent blacklist
--remove: remove existing rule
--check: check for an existing rule

One of:
--path {path}: path of binary/bundle to add/remove.
Will add the hash of the file currently at that path.
Does not work with --check. Use the fileinfo verb to check.
the rule state of a file.
--sha256 {sha256}: hash to add/remove/check

Optionally:
--certificate: add or check a certificate sha256 rule instead of binary
--message {message}: custom message

If you then try to run MacKeeper, you'll get a block message like this:

That's pretty much it. That isn't everything Santa can do. That's about the simplest thing you can do with Santa, but most of the documentation for Santa is about all of the other stuff you can do. I didn't see much about just how to simply block an .app, hence this blog post.

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.

Chrome Gmail unread messages not appearing in bold

We had a user whose unread emails were appearing as bold in Safari (with an ugly font) and not bold at all in Chrome (font looked okay), and we did some digging and found the solution was to enable the Arial Bold font in Font Book on the user's Mac, and it was all good.

Our best guess is that Safari couldn't find the font it wanted so substituted an ugly font but kept it bold, and Chrome couldn't find the font it wanted so substituted a decent-looking font but not bold.

Use the command-line to set a firmware password on macOS

For extra security, you can add a firmware password to Macs, especially since Find My Mac is essentially useless (unlike for iPads, which have an activation lock preventing thieves from reactivating the iPad after a factory reset) and DEP-to-MDM enrollments for Macs can even be avoided by thieves if they're resourceful enough.

If you have a laptop with a firmware password, you need that password to boot from anything except the startup disk. Combine that with FileVault encryption, and a stolen Mac is pretty much useless. Doesn't mean that you'll necessarily get it back, but the likelihood is higher if the device is useless to thieves.

You can, of course, enable the firmware password via Recovery Mode, but it's easier to do it from the command line:

sudo firmwarepasswd -setpasswd
You'll be prompted for the new firmware password. Afterwards, you'll need to reboot the machine for the change to take effect. (Be sure to make sure you have an actual startup disk selected in System Preferences!)

There are two modes for a firmware password: command and full. By default, the firmware password mode will be command, which means you'll be prompted for the password only if you boot from something other than the startup disk. If, for some strange reason, you want the mode to be full, it would mean you'd be prompted for a firmware password at every boot, regardless of what you're booting to.

A few other commands you might find useful...

sudo firmwarepasswd -check
checks to see if the firmware password is set.
sudo firmwarepasswd -verify
allows you to verify you have the correct password (without rebooting).
sudo firmwarepasswd -delete
deletes the firmware password. You'll need the current one to delete it, of course.

If you want to script firmware password setting, someone wrote a fairly simple script that does it. There's also firmware password manager, which is a far more sophisticated way to manage firmware passwords.

Nota Bene: If you enable a firmware password, you can get into target disk mode by holding down the Alt/Option key at boot, typing in the firmware password, and then holding down the T key. However, you will be unable to boot into Safe Mode unless you delete the firmware password.

Script AutoPkg trust verification and trust update process

Starting with version 1, AutoPkg began evaluating trust info for recipes, so you could see what changes were made to a recipe (if changes were made) and then accept the changes if you wanted to. Here is what the typical trust verification workflow looks like.

Whether running a list of recipes via script or via AutoPkgr schedule, I'd occasionally get error'ed recipes when trust was broken, have to manually run

autopkg verify-trust-info -vv NAMEOFRECIPE
and then, after review, run
autopkg update-trust-info NAMEOFRECIPE
and then run the recipe after updating the trust info:
autopkg run -v NAMEOFRECIPE
So I thought I'd take a stab at scripting the whole process. Basically my script updates all the repos (to see if there are changes), verifies trust info on each of the recipes in the recipe list, and then prompts the user to review changes and approve them or not, before running all the approved or unchanged recipes.

It's still in the early testing phase, but it seems to work so far....

Capturing new FileMaker Pro updates for macOS

For older FileMaker Pro versions, there used to be downloadable updates on the FileMaker website, but starting with FileMaker Pro 15, they decided to have FileMaker updates on macOS go through FileMaker itself:

As you can see here, they expect your user to have admin privileges. If you're managing Macs (through Munki, for example), you may not give your users admin privileges or you may (even if your users have admin privileges) not want to bother with them running the updater themselves.

For some reason, Windows users get separate update installers. None for the macOS users, though, but we can be a bit tricky in capturing the installer.

First, find a Mac that you're not doing a silent install of FileMaker Pro on. Do a regular manual install on that one Mac and make sure you have AI_DISABLEUPDATENOTIFY=0 in your Assisted Install.txt file.

Then, on this test Mac, launch up FileMaker Pro.

Under Help, select Check for Updates....

Click Download Update

This is key here: do not click Install Update. Don't click Cancel either. Do not click anything. Just leave this dialogue up for now.

Open up /var/log/install.log and search for caches.

That should show you the location of the downloaded installer.

Go to that location and find the .pkg file. You can import that into Munki (or whatever you use to manage updates to your Mac fleet).

Fixing a broken MDM on OS X Server with Profile Manager

If you're getting errors like Websites are turned off. An administrator can turn them on using the Server application or the configuration for your ipad could not be downloaded invalid profile, try Reset Apache In OS X Server To Factory Defaults and then turn Websites and Profile Manager back on.