Finding 32-bit applications on Macs

In macOS 10.13 (High Sierra), Apple started warning users about 32-bit applications by saying those applications were "not optimized" for their Macs. The warnings continued in macOS 10.14 (Mojave). Starting with macOS 10.15 (Catalina), 32-bit applications will cease working altogether.

Hopefully, vendors still producing 32-bit applications for Macs will get their acts together and create 64-bit versions soon.

In the meantime, you might want to check your Macs for what 32-bit applications they have installed so you can pressure vendors to update their apps, start looking for 64-bit alternatives to those apps, or consider whether you even still need to use those apps.

Checking for 32-bit apps on an individual machine

I'm not sure how useful this would be to Mac admins, but you can check for 32-bit applications on a single machine by going to System

Then scroll down on the left side to find, under Software, Applications.

It might take a while for the list to load.

Once the list is loaded, you can sort by 64-bit (Intel), and then sort again, so all the No entries are at the top.

Checking for 32-bit apps for multiple machines via MunkiReport

If you're using Munki and MunkiReport, you can go to Listings > Applications to see which apps in your fleet are 64-bit or not.

If you want to query the MunkiReport database directly, you can also run

FROM applications
WHERE has64bit=0
ORDER BY name, path
and that will give you only distinct results. You could go distinct with name instead of path if you don't want the actual name of the app bundle but just the name of the app.


Thanks to eholtam and gmarnin on the MacAdmins Slack for pointing me to the right place in MunkiReport.


Reinstall macOS using installr

Now that Mac imaging is essentially dead and the new T2 chips make it more complicated to boot from external drives, reinstalling macOS to re-deploy a Mac can be a bit trickier.

installr is a tool to do a clean reinstall of macOS via recovery mode (and install additional packages, too, if you'd like).

The actual usage of installr is fairly straightforward and explained well in its README on GitHub.

Here are a couple additional notes from my own testing on a late 2014 Mac Mini, though...

Listen to the README on http vs. https

https is definitely not something you can rely on if you're using installr over the network. If you try to serve up the installr.dmg over https, and then attach it via recovery mode, you may get this as a response:

Usage: hdiutil attach [options] <image>
       hdiutil attach -help

One more step for FileVault-encrypted drives

Installr will prompt to erase the drive before installing macOS, but you installr won't see drives that are unmounted, so if the drive you're trying to reinstall macOS on is an encrypted drive, you'll either have to unlock/mount the drive first... or erase it first.

Once the drive is mounted, installr will recognize it (and prompt you to erase it again).

installr from USB not that much faster than over network

Using installr over USB (even from a portable SSD) doesn't make the re-installation process go much faster.

When I ran installr of http (over wireless), it took 4 minutes and 27 seconds from confirming erasure of the drive to the installer finishing and then needing to reboot to complete the installation.

When I ran installr off a USB portable SSD, it took 1 minute and 48 seconds from confirming erasure of the drive to the installer finishing and then needing to reboot to complete the installation.

So, it's a difference of less than 3 minutes. When you still have another 17 to complete the installation after that, 3 minutes is not a huge gain for choosing USB installr over http installr, but that small gain is something to consider when choosing how you decide to use installr in your own environment.

One huge advantage to using http is having the installr files or disk images in one place instead of a variety of USB drives. How you choose to use installr will greatly depend on the needs and means of your organization.

What the installr process looks like in Recovery Mode

To run installr, you might have to boot into Recovery Mode (especially on a T2 Mac), as opposed to running it from an external drive.

As I mentioned before, erasing the drive ahead of time isn't strictly necessary (it may be a FileVault-encrypted one), so if the drive is already mounted and isn't encrypted, you can skip launching Disk Utility.

If you did have to go through all that to erase the disk first, go ahead and Quit Disk Utility.

Go to Utilities > Terminal

In this example, we're running the http installr instead of the USB one, but either way, you're going to end up doing some version of


Once the first part of the installation process finishes, your Mac should automatically reboot and finish the rest of the installation of macOS.

Once it's done, you should be at the start of Setup Assistant.


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.


What’s the password for the guest account on macOS?

If you enabled the guest account on macOS, you probably want to have Display login window as be List of users (instead of Name and password).

That way, the guest sees the guest account is available and clicks on it, and then it logs into the guest account.

If, however, you do have Name and password, your guest will have to type guest in as the username. I thought you had to leave the password blank. Someone else in our office thought you had to type guest as the password. Turns out you can type anything you want in the password field, and it will let you in as guest, as long as the guest account is enabled and as long as you type in guest as the username.

That said, we have experienced the guest account not working at all on some machines (running 10.13.6) with the login window as Name and password. It doesn't seem to be consistent. Sometimes toggling guest off and back on will fix it. Other times, no. So, your mileage may vary.


Using Santa to block macOS upgrades

In the past, I'd used the fake installer approach to stop users from upgrading to the newest macOS version.

But with macOS 10.14 (Mojave), I started blocking using Santa (see Using Santa to block an .app for more details on general Santa use). It's likely this Santa-blocking approach also works for High Sierra and Sierra as well—I just haven't tested it on those.

Just download Mojave to your Mac, and then run

santactl fileinfo /Applications/Install\ macOS\ --key SHA-256
to get the hash to block.

Then run a modified version of this command (substituting in the actual SHA-256 hash for the placeholder) to add it to the Santa blacklist:

/usr/local/bin/santactl rule --blacklist --sha256 "actuallonghashyougotfromthepreviouscommand"

We were able to test this on two Mojave installers downloaded using two separate Apple IDs, so the binary seems to be the same regardless of which Apple ID is used to download it.

If a user then tries to run the Mojave installer, she or he will see a message like this:

Again, since it's based on the binary (and since you don't want to block by Apple certificate—which you may not be able to do anyway with Santa?—so you have to block by binary), you would have to create a new rule for every new macOS installer that comes out (10.14, 10.14.1, 10.14.2, 10.14.3... 10.15, 10.15.1... 10.16... and so on).

Special Note

Thanks to @elios (on Mac Admins Slack) for pointing out that this probably would not block the startosinstall binary from running. I was able to test and verify blocking the .app binary does not, in fact, block the startosinstall binary from running.

Also, by default, Santa will get the binary for InstallAssistant_springboard. If you want to be super aggressive, you might also want to block the InstallAssistant and InstallAssistant_plain binaries. Otherwise, the user can still run those two to get the GUI assistant to launch up.

So you really have to ask yourself how aggressively you want to block Mojave. Are you preventing users from just accidentally upgrading? Or do you want to prevent from upgrading even the most determined users who have admin privileges?

If you want to block startosinstall as well, you can do that. Just find (and subsequently block) the SHA-256 hash it:

santactl fileinfo /Applications/Install\ macOS\ --key SHA-256
santactl rule --blacklist --sha256 "actuallonghashyougotfromthepreviouscommand"
One advantage you get from not blocking startosinstall is that you can still block users from double-clicking to install Mojave but not have Santa try to block Munki from installing Mojave, even if you have the InstallAssistant_springboard blocked.

If you block startosinstall, then try to install the upgrade with Munki, you'll see it mount the .dmg, then stop. The log entries will look something like this:

### Beginning os installer session ###
Starting macOS upgrade...
Mounting disk image Install macOS Mojave-10.14.2.dmg
[Errno 1] Operation not permitted
Starting macOS install failed with return code 1
ERROR: ------------------------------------------------------------------------------
ERROR: [Errno 1] Operation not permitted
ERROR: ------------------------------------------------------------------------------
ERROR: Error starting macOS install: startosinstall failed with return code 1
### Ending os installer session ###


Using ffmpeg to trim video

No real tutorial here, just a link to a great resource on this via Stack Overflow:
Cutting the videos based on start and end time using ffmpeg

Cutting with ffmpeg takes a lot less longer than rendering out via iMovie, and it results in a similarly sized output file instead of a giant one

P.S. My boss just showed me how you can do this in Quicktime with Edit > Trim. Much easier!


Waiting for FileVault encryption to finish to install macOS updates

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.

For example, here's a machine that's on macOS 10.13.4.

softwareupdate can't find any updates.

And even if you try to manually install the 10.13.6 combo update, you get macOS High Sierra 10.13.6 Update can't be installed on this disk. This volume does not meet the requirements for this update.

And, yup—lo and behold! The FileVault encryption is still in progress. Once that's done, the 10.13.6 update should install just fine.


Integrating DetectX Swift with Munki

If you like DetectX Swift and want to integrate it with Munki, this is how I did it. Hat tip to Zack McCauley for doing the heavy lifting, which I'm now building on. I'd recommend you read his blog post first.

So instead of having an Outset script or separate Launch Agent, I decided to put the DetectX Swift scan as part of the Munki run (specifically a script in the postflight.d directory (if you put it in a preflight, it will be a blocking application that will prevent DetectX Swift from doing an unattended install upgrade) that MunkiReport creates):

It's best to use a separate Launch Daemon (example here), because the scan can sometimes take over a minute, and MunkiReport scripts will time out after ten seconds.


# Run a DetectX Swift scan
/Applications/Utilities/DetectX\\ Swift search -aj /usr/local/munki/preflight.d/cache/detectx.json

Outside of MunkiReport (but connecting to the MunkiReport MySQL database), I have a script that generates a Python list of files that DetectX Swift has flagged as "issues":

$query="SELECT issues FROM detectx WHERE numberofissues > 0";
$result=mysqli_query($YOURDATABASECONNECTION, $query);
   // Create an array to store the results
      // Create an array based on a semi-colon delimiter
      $smaller_issues=explode(";", $row['issues']);
      foreach($smaller_issues AS $smaller_issue){
          if((trim($smaller_issue)!='') AND (!in_array($smaller_issue, $larger_issues))){
            array_push($larger_issues, $smaller_issue);

   // End fetching results

      echo '<p>okay_to_delete = [ ';
         echo '\'' . $larger_issues[$counter] . '\',<br />';   
      echo '\'' . $larger_issues[$counter] . '\' ]</p>';
   // End checking there are elements in larger issues (there should be)

// End checking there are any issues

And finally I have a nopkg to do the actual cleaning of the issues DetectX flagged.

So why even have an array of okay-to-delete things?

Well, DetectX Swift has command-line options to scan, but it (at least as of this writing) does not have the option to command-line remove things, presumably so someone has a chance to review the things removed before actually removing them. Also, since it's just forcefully removing things (yes, I know about using shutil to remove, but I've run into weird situations in which that doesn't work consistently, so I'm using a subprocess to invoke rm instead), it's probably a good idea for at least one human to review things before they get removed.

The nopkg also copies the .json to /var/log (with a datetime stamp in the name) before removing anything.


Use docklib to manage macOS docks

docklib instead of dockutil

I have a few posts about using dockutil to manage the macOS dock. dockutil is still a valid and working project, but I'm starting to migrate my scripts to docklib instead.

Installing docklib

The installation instructions for docklib say you can put the file in the same directory as the scripts that invoke it or you can put it "in your Python path." I'd recommend just grabbing the docklib .pkg from the releases page or using the AutoPkg docklib recipes to download it. The .pkg puts in /Library/Python/2.7/site-packages/

Using docklib with Outset

docklib can be used in an Outset login-once or login-every script. There is no need to explicitly put in a delay to wait for the initial dock to appear before running your script. There is also no need, if you're specifying a dock (rather than modifying an existing one) to remove the default applications Apple puts on the dock. If you're specifying a dock, just say what you want to add. Use this suggested template:

import os
from docklib import Dock
tech_dock = [
   '/Applications/Managed Software',
dock = Dock()
dock.items['persistent-apps'] = []
for item in tech_dock:
   if os.path.exists(item):
      item = dock.makeDockAppEntry(item)

Checking if an item exists before removing/adding via docklib?

Here's an example of checking for something's existence on the right side of the dock before adding it. To check on the left side, it's a very similar process, except you just replace


For example, this will add Microsoft Word only if it's not in the dock already:

from docklib import Dock
dock = Dock()
if dock.findExistingLabel('Microsoft Word', section='persistent-apps') == -1:
   item = dock.makeDockAppEntry('/Applications/Microsoft')

If you add an item using docklib that already exists in the dock, a second instance of it will be added to the dock, so you definitely should check for the existence of the item first.

However, if you want to remove an item, just use the standard removal procedure:

from docklib import Dock
dock = Dock()
dock.removeDockEntry('Microsoft Word')
If the item isn't in the dock when you try to remove it, docklib won't give any error or warning.


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